isomp4/mux: don't overwrite with a bigger moov when fragmenting
authorMatthew Waters <matthew@centricular.com>
Thu, 19 Aug 2021 06:02:47 +0000 (16:02 +1000)
committerGStreamer Marge Bot <gitlab-merge-bot@gstreamer-foundation.org>
Mon, 23 Aug 2021 04:17:36 +0000 (04:17 +0000)
When outputting fragmented mp4, with a seekable downstream, we rewrite
the moov to maybe add a duration to the mvex.  If we start by not
writing the initial moov->mvex->mhed duration and then overwrite with a
moov containing mhed atom, the moov's will have different sizes and
could overwrite subsequent data and result in an unplayable file.

e.g. The initial moov would be of size 842 and the final moov would have
a size of 862.

Fix by always pushing out the mhed duration in the moov when
fragmenting.

Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/898

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1060>

gst/isomp4/atoms.c

index cc191ed..290d1fd 100644 (file)
@@ -2970,11 +2970,9 @@ atom_mvex_copy_data (AtomMVEX * mvex, guint8 ** buffer, guint64 * size,
     return 0;
   }
 
-  if (mvex->mehd.fragment_duration > 0) {
-    /* only write mehd if we have anything extra to add */
-    if (!atom_mehd_copy_data (&mvex->mehd, buffer, size, offset)) {
-      return 0;
-    }
+  /* only write mehd if we have anything extra to add */
+  if (!atom_mehd_copy_data (&mvex->mehd, buffer, size, offset)) {
+    return 0;
   }
 
   walker = g_list_first (mvex->trexs);