anthwlock
commented
3 years ago It seems like untrunc is not picking up on which hvc1 frames are real and which are not
More like it didn't find the start of these hvc1 frames at all. And that was mainly because of the bad tmcd and lpmc prediction.The recent commits should improve on this, please give them a try.
Maybe there is a way to search the mdat to figure out which are real?
If you can figure this out with a hexeditor, you can tell untrunc where to start the recovery via -range <start_of_good_mdat_data>:.
Besides this: untrunc tries to combine all mdat atoms it finds. It does this by simply skipping the mdat header, see here
I have a broken HVEC .MOV from a Fuji X-T3 camera that I think it should be possible to repair because virtualdub2 is able to parse the bad file and decode the frames before the truncation to zeros.
I have tried untrunc "-s", "-s -sm", "-sm" and "-sm -dyn" with the same result. The repair output from untrunc 644978f is not playable in virtualdub2 or vlc. The repair seems to have one key frame worth of hvc1 when I expect a few hundred frames. If I run untrunc -d on the repair file:
Not an expert at this but I think the camera writes a moov with 20 minutes worth of hvc1 files at the beginning of file recording. Consequently, if the recording stops, the moov in bad.MOV refers to a bunch of hvc1 frames that do not exist and where the binary data in mdata is all zero.
It seems like untrunc is not picking up on which hvc1 frames are real and which are not real when it comes to output the repair. It seems like it should because if I do "untrunc -f
Maybe there is a way to search the mdat to figure out which are real? I'm not a C++ person but maybe I can help eventually.
Bad file truncated to first 240 MB (zeros are not visible since they occur at about 1.5 GB in) : https://drive.google.com/file/d/1uBpsJjvDZqXkHdLPGXOn3hV2RmQpTsXo/view?usp=sharing
Good file (131 MB): https://drive.google.com/file/d/1iQlIMcV18-5QdsanXZVm1v8DQxJ3Gryc/view?usp=sharing
Thanks,