[Bug 784258] qtmoovrecover can't recover video

[GStreamer (GNOME Bugzilla)]

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

--- Comment #21 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
(In reply to Gregoire from comment #20)
> First, I appreciate your efforts.
> 
> Please correct me if I'm wrong: from what I have understood, the problem is
> more during the encoding stage where the mdat is longer than the mrf headers
> or said differently, the mrf headers are shorter than the mdat. Perhaps
> there is an issue to write the mrf headers to file.

Yes, it looks to be on the encoding side.

> 
> What I'm confused about is that the mdat file is written at the beginning of
> the file, so how can the system know how long is going to be the mdat or the
> mrf headers?

It doesn't know, but for every sample that it puts in the mdat it writes about
this sample on the mrf (size, offset, timing information, stream to which it
belongs). The same information is kept in memory to write the final headers in
case the file is successfully finished. The mrf is an extra step that is done,
if enabled.

> 
> Anyway, the investigation is more on the encoding stage rather than during
> the pure recovery.
> 
> Could you point in the code where I should hack/patch the recovery phase so
> that the mdat is trunk-ed to the size of the mrf headers?

The mdat is written by the pipeline (filesink), so mp4mux writes to it by
pushing buffers downstream. The mrf is written by the
"atoms_recov_write_trak_samples" function. Look in qtmux code for
"moov_recov_file". Try to track the data added to the mrf and correlate with
the buffers pushed downstream. You might find that some extra data is being
pushed or some data is not being sent to the mrf.

Good luck!

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