Editing video files produced by my Garmin dashcam is sometimes really annoying. Not only it splits every darn trip into 60 second chunks forcing you to edit bunch of small files, but it will also occasionally produce video with the first frame completely black. At least that's how it looks in Vegas Movie Studio 15 and, while annoying, was easy enough to remove. In DaVinci Resolve these videos would have a few seconds worth of corrupted data and that's a bigger problem.
As I'm moving most of my video editing to Resolve due to it's cross-platform capabilities, I decided to figure it out. One way to see what's going on with MP4 is by looking at video file in MediaInfo.
The first confusing thing was that MP4 contained only streams with ID 2 and 3. What happened to stream with ID 1 is anybody's guess. The second source of confusion was that all streams combined amounted to smidgen over 60 MB. The whole video file was more than 70 MB. While one can expect MP4 container format to take some space, overhead is generally measured in KB - not MB.
However, both these things were present in both valid and invalid video file. It took going into Advanced mode to reveal more curiosities. At last it let me know where remaining 10 MB were - in the header. And more interestingly it has shown multiple stream size calculations for video stream. File that contained black frame had one of it's six video stream sizes listed as 59.97 MB while fully working file had all video stream sizes set to 60.00 MB.
Either due to crappy encoder or bad coding, Garmin not only bloats header to unreasonable level but it can also miscalculate stream stream sizes. Because MP4 contains stream size data at multiple places, it was dependent on decoder whether error would be noticeable or not.
Knowing I am dealing with the corrupt container and seemingly correct stream (albeit one frame shorter), I decided to simply repackage MP4 without recompression using ffmpeg:
Terminalffmpeg -i input.mp4 -c:v copy -c:a copy fixed.mp4
This copies both video and audio stream (irrelevant if there is no audio stream) into a new file. For normal videos this results in a direct stream copy. Videos where one frame was corrupted end up with 59.967 seconds worth of frames. Essentially the broken frame will be removed. And this repackaging solved the black frame issue for both Vegas Movie Studio and DaVinci Resolve.
Unfortunately, while DaVinci Resolve did recognize files now, exported result had a stutter. For some reason all these files were recognized as 15 fps. And no, this wasn't due to stream copy as original videos were misidentified too. It took me a while to give up and ask the question about it on Blackmagic forum only to find out I stumbled upon a bug.
As a workaround before bug is resolved, I went onto converting the stream to DNxHD LB codec:
Terminalffmpeg -i input.mp4 -c:v dnxhd -profile:v dnxhr_lb -pix_fmt yuv420p -c:a copy fixed.mov
Not only this also removes invalid frames but it also helps editing speed as DNxHD is much more CPU-friendly format.
Being too lazy to deal with these files on case-by-case basis, a bit of Bash magic to repackage multiple files comes in handy:
Terminalmkdir out
find . -type f -name '*.MP4' -exec \
ffmpeg -i {} -c:v dnxhd -profile:v dnxhr_lb -q:v 1 -pix_fmt yuv422p -c:a copy \
out/{}.mov \;