Then you are working on encoded compressed low quality video which you then have to encode and compress again.
If you do it in camera then it works with the raw highest quality video and it only gets compressed once.
True regarding the compression passes. But does the Novatek do image processing / smoothing / noise reduction prior to cropping? We're always going to be bound by the Novatek's H.264 encoding algorithm, but I don't know much about its implementation in the Git2 (or the Git2's design of image processing). What I do know is the resultant H.264 files are 420 colour space so it's throwing stuff away.
Does the Git2's implementation of its Novatek crop each frame, apply image processing and encodes, or does it apply processing then crop then encode? Subtle differences, but would be useful to know.
I crank my bit rate to maximum and it results in ~35 Mbit videos. At that kind of rate, my bet is they're going to be almost perceptually lossless and indistinguishable from the source video. The IMX206 is notionally 16 mpix but it's only 7.77 mm (diagonally).
Personally I think I'd go for preserving 100% original optical resolution then, when I do another encode pass, do it at at sufficiently high a rate (>=50 mbit) so as to be transparent. I can crop with high quality software algorithms, apply image enhancement that looks much better than what the Novatek can muster then encode and store as Lagarith or similar lossless codec. Alternatively for H.264 archival, CRF 15 with some minor tuning is usually great.
From what I've seen of the cropped images out of the Git2, they sacrifice too much image clarity when cropped to be worth it (it's why I disabled the Gyro). I'd prefer being able to throw pixels away with an undo function
Is having more of the image to work with worth a small (if any?) loss in quality when cropping in software? For dashcammers, having the wider FOV by default could be more useful in a litigation situation.
Six of one, half a dozen of the other...