After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 710623 - qtdemux: Video captured by iPad couldn't play in push mode
qtdemux: Video captured by iPad couldn't play in push mode
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.0.5
Other All
: Normal normal
: 1.2.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-10-22 10:24 UTC by Haijiao Qiao
Modified: 2013-11-09 09:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
qtdemux: When using a buffered mdat, store all received data for later use (5.12 KB, patch)
2013-10-25 21:57 UTC, Thiago Sousa Santos
committed Details | Review
qtdemux: handle fragmented files with mdat before moofs (2.16 KB, patch)
2013-10-25 21:57 UTC, Thiago Sousa Santos
committed Details | Review

Description Haijiao Qiao 2013-10-22 10:24:48 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.
Comment 1 Haijiao Qiao 2013-10-23 03:11:03 UTC
http://developer.longtailvideo.com/trac/browser/testing/files/fragmented.mp4?rev=1411

You can get fragmented mp4 file using above URL. Play fragmented.mp4 in push mode, also failed.  Please check, thank you.
Comment 2 Thiago Sousa Santos 2013-10-25 15:17:47 UTC
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.
Comment 3 Thiago Sousa Santos 2013-10-25 21:57:02 UTC
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:

mdat|moof|mdat|moof ...

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.
Comment 4 Thiago Sousa Santos 2013-10-25 21:57:07 UTC
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.
Comment 5 Thiago Sousa Santos 2013-11-07 14:39:12 UTC
0e78ffc9d61ffa0adca14be6e4214c8b08450b57
33ebda8ecfd976ab28879ea7fd232572d0cb1ace

Fixed by those commits, thanks for reporting this bug.