[Bug 784258] qtmoovrecover can't recover video

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=784258

--- Comment #23 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
(In reply to Gregoire from comment #22)
> 
> - can you please commit your latest patch to the tree, that would simplify
> the testing. This patch definitely helps.

Yeah, will merge it soon.

> 
> - I have done again a clean git master cerbero + the patch in this bug
> report, I still get a mild error:
> 
> git clone git://anongit.freedesktop.org/gstreamer/cerbero
> ./cerbero-uninstalled bootstrap
> ./cerbero-uninstalled package gstreamer-1.0
> ./cerbero-uninstalled buildone gst-plugins-good-1.0 (with patch)
> ./cerbero-uninstalled shell
> gst-launch-1.0 videotestsrc ! x264enc ! qtmux moov-recovery-file=test.mrf !
> filesink location=test.mov
> CONTROL-C
> gst-launch-1.0 qtmoovrecover recovery-input=test.mrf broken-input=test.mov
> fixed-output=testo.mov
> mp4info testo.mov 
> 
> As you can see, it still reports something incorrect.
> 
> mp4info version -r
> testo.mov:
> ReadChildAtoms: "testo.mov": In avc1 atom, extra 4 bytes at end of atom
> Track	Type	Info
> 1	video	H264 Unknown Profile f4 at 1.3, 68.533 secs, 1500 kbps, 320x240 @
> 30.000146 fps
> ReadChildAtoms: "testo.mov": In avc1 atom, extra 4 bytes at end of atom

Those extra 4 bytes are actually intentional AFAIK. Some players out there
expect that extra stuff. It is harmless.

> 
> - My question in my previous post was more to hack/fix the problem in the
> recovery stage rather than in the encoding stage. In the atomsrecovery.c
> file, where is the logic that (could/would/should) compare the size of the
> mdat in the broken file and the size of the headers in the mrf file?

At the end of moov_recov_write_file, in atomsrecovery.c there is a piece of
code for reading the mdat atom and writing it to the output. It just reads
chunks from 1 file and writes it to the other file. Look for FOURCC_mdat and
that should be the place. It writes the size of the mdat, then the mdat
identifier and then reads the data from the file into the output. It doesn't
check for the size of the mdat it intends to write and adds the rest of the
file at the end. This will appear as bogus data to the players.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.