Assertion `current_chunk_.n_samples_' failed for Garmin Dash Cam 56 mp4 videos (valid or not)

[klaeufer]

GRMT0054.MP4: ISO Media, Apple QuickTime movie, Apple QuickTime (.MOV/QT)

The following happens whether the input file is valid or not. No output is produced.

docker run -v ~/Downloads/Dashcam/104TLPSE/:/mnt:rw untrunc -s /mnt/GRMT0054.MP4 /mnt/GRMT0059.MP4
Info: version 'a0bf2e8-dirty' using ffmpeg '3.3.9'
Info: reading /mnt/GRMT0054.MP4
Info: parsing healthy moov atom ... 
Composition time offset atom found. Out of order samples possible.

Info: reading mdat from truncated file ...
untrunc: src/track.cpp:667: void Track::pushBackLastChunk(): Assertion `current_chunk_.n_samples_' failed.

When the input file is valid, there are many additional messages of the form

bad detection (at 1034410577 / 1034476113, pkt 3452, chunk 0, pkt_in_chunk 3452):
detected: 'avc1', 242091, 1, 0
correct : 'avc1', 242091, 0, 1001

[anthwlock]

interesting, can you send me the files? What happens if you disable the assert statement?

[klaeufer]

Great idea! After I disabled the assertion, untrunc -s started producing playable, partially valid videos. vlc seems to handle them better than mplayer. Some of the sections are in the wrong order, but I think that's how it was stored on the SD card and I can fix it manually.

Also, I got different results depending on the reference file used, and some of the options caused assertions to fail also depending on the reference file used.

I'll be happy to share some sample files if you'd like.

Thanks a lot! You helped me salvage some important footage.

[anthwlock]

I'll be happy to share some sample files if you'd like.

Yes, that would help. Thanks!

[klaeufer]

Yes, that would help. Thanks!

Shared via email!

The video I repaired plays locally in VLC, albeit with some segments in the wrong order and tons of "error splitting the input into NAL units" messages. mplayer seems to bum out after the first segment. YouTube says it can't be processed. So I still need to figure out how to locally fix the segment order and get it ready for YouTube.

Thanks for your work on this tool!

[anthwlock]

Interestingly, the GRMT0052.MP4 file contains 8 moov atoms. I added the -lsm option so one can better see what's going on.

It seems like that file contains 4 "normal" files. I believe the camera always creates two moovs, and wraps the unused one in a free atom.

b08a880a1b2feea4d5e521068bc79f0ddd219fe8 solves the reported issue. 6091fae0638e95416cd7dd2bbf46c7eded08f3cc improves the resulting file, please try it out.

So I still need to figure out how to locally fix the segment order and get it ready for YouTube.

It looks like these "segments" are often separated by a 4 zero-bytes. I made a script to extract the different parts. Then repair the resulting files like this: For the first one: untrunc -s ../good1.mp4 0_0_113819632.mp4 All other: untrunc -range 0: ../good1.mp4 1_113819632_1029609788.mp4

Note that there might be a better way to do this, which splits all 4 segments not just 3.

Hope this helps!

[klaeufer]

Thanks for your efforts! I'll give it a try as soon as have a chance.