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 743407 - qtdemux: doesn't ignore data after last sample in mdat.
qtdemux: doesn't ignore data after last sample in mdat.
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-01-23 15:54 UTC by Chris Bass
Modified: 2015-02-03 14:00 UTC
See Also:
GNOME target: ---
GNOME version: ---

Throw away non-sample data at end of mdat. (1.23 KB, patch)
2015-01-23 15:57 UTC, Chris Bass
none Details | Review
qtdemux: Fix data dropping for fragmented streams (2.29 KB, patch)
2015-01-26 20:12 UTC, Thiago Sousa Santos
committed Details | Review

Description Chris Bass 2015-01-23 15:54:45 UTC
If qtdemux is demuxing a fragmented stream (e.g., a DASH stream), and it receives a fragment that contains data in its mdat after the end of the last sample, playback fails.

The reason is that qtdemux will start trying to parse the next fragment starting from the byte following the end of the last sample (i.e., while still inside the current fragment's mdat) rather than discarding the remaining bytes in the mdat and starting parsing from the beginning of the next fragment. At that point playback fails, since the bytes after the last sample won't be valid ISOBMFF boxes.

This can be demonstrated by playing this DASH stream:

gst-launch-1.0 playbin uri=

Some of the audio fragments in this stream have "watermarks" in them; the watermark consists of some data inserted in their mdat after the end of the last sample. When the client reaches one of these segments (which on my system happens when playback reaches roughly 1m 29s), it throws an error and exits:

ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux1: This file is invalid and cannot be played.
Additional debug info:
qtdemux.c(5045): gst_qtdemux_process_adapter (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux1:
atom RD
Execution ended after 0:01:29.561894521

The ISOBMFF spec allows data other than sample data to be carried in an mdat; the demuxer should extract only the sample data that is referenced by metadata in the fragment's moof box.
Comment 1 Chris Bass 2015-01-23 15:57:51 UTC
Created attachment 295282 [details] [review]
Throw away non-sample data at end of mdat.

This patch fixes the problem for the DASH case, in which the ISOBMFF fragments contain only one track, but it may need to be "generalized" to handle fragments that contain more than one track.
Comment 2 Thiago Sousa Santos 2015-01-26 20:12:26 UTC
Created attachment 295480 [details] [review]
qtdemux: Fix data dropping for fragmented streams

Thanks for the detailed report and sample. The bug was actually
caused by a missing data skipping operation when qtdemux detects
it is out of samples.

Please check if this patch solves your issue.
Comment 3 Mathieu Duponchelle 2015-01-26 20:52:44 UTC
Review of attachment 295480 [details] [review]:

Seems correct to me and fixes the reported issue, OK
Comment 4 Chris Bass 2015-01-27 08:38:31 UTC
That fixes it for me - thanks.
Comment 5 Thiago Sousa Santos 2015-01-27 12:05:09 UTC
Thanks for confirming.

commit 2586a219f65e0cb56178e1b50fedeb180b816ecf
Author: Thiago Santos <>
Date:   Mon Jan 26 17:08:12 2015 -0300

    qtdemux: Fix data dropping for fragmented streams
    For fragmented streams with extra data at the end of the mdat
    qtdemux was not dropping those bytes and would try to use
    that extra data as the beginning of a new atom, causing the
    stream to fail.