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=http://rdmedia.bbc.co.uk/dash/ondemand/testcard/1/client_manifest-nosurround-ctv.mpd

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.