GNOME Bugzilla – Bug 710623
qtdemux: Video captured by iPad couldn't play in push mode
Last modified: 2013-11-09 09:26:30 UTC
Gst-launch-1.0 play video which captured by iPad failed while play correctly in pull mode; I check the vide, I found where is mvex atom in moov, but there is no moof atom. Could you help check the problem? Thanks.
You can get fragmented mp4 file using above URL. Play fragmented.mp4 in push mode, also failed. Please check, thank you.
The mdats are coming before the moofs for this sample. It says it was created by gpac, IIRC the ipad adds something else to the metadata of the file. Is this the sample you wanted to attach?
Anyway, I'm working on a patch.
Created attachment 258146 [details] [review]
qtdemux: When using a buffered mdat, store all received data for later use
In push mode, when qtdemux can't use a seek to skip the mdat buffer it has
to buffer it for later use.
The issue is that after parsing the next moov/moof, there might be some
trailing bytes from the next atom in the file. This data was being discarded
along with the already parsed moov/moof and playback would fail to continue
after the contents of this moov/moof are played.
This is particularly bad on fragmented files that have the mdat before the
corresponding moof. So you'd get:
When a moof was received, it usually came with some extra bytes that would
belong to the next mdat (because upstream doesn't care about atoms alignment).
So those bytes were being discarded and playback would fail.
This patch makes qtdemux store those extra bytes to reuse them later after the
mdat is emptied.
Created attachment 258147 [details] [review]
qtdemux: handle fragmented files with mdat before moofs
Assume a file with atoms in the following order: moov, mdat, moof,
mdat, moof ...
The first moov usually doesn't contain any sample entries atoms (or
they are all set to 0 length), because the real samples are signaled
at the moofs. In push mode, qtdemux parses the moov and then finds the mdat,
but then it has 0 entries and assumes it is EOS.
This patch makes it continue parsing in case it is a fragmented file so that
it might find the moofs and play the media.
Fixed by those commits, thanks for reporting this bug.