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.

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

1 files changed, 9 insertions, 0 deletions

diff --git a/gst/isomp4/qtdemux.h b/gst/isomp4/qtdemux.h
index d27134c9b..3fb43daea 100644
--- a/gst/isomp4/qtdemux.h
+++ b/gst/isomp4/qtdemux.h
@@ -91,6 +91,15 @@ struct _GstQTDemux {
   GstAdapter *adapter;
   GstBuffer *mdatbuffer;
   guint64 mdatleft;
+  /* When restoring the mdat to the adatpter, this buffer
+   * stores any trailing data that was after the last atom parsed as it
+   * has to be restored later along with the correct offset. Used in
+   * fragmented scenario where mdat/moof are one after the other
+   * in any order.
+   *
+   * Check https://bugzilla.gnome.org/show_bug.cgi?id=710623 */
+  GstBuffer *restoredata_buffer;
+  guint64 restoredata_offset;
 
   guint64 offset;
   /* offset of the mdat atom */