Avoid skipping moov atoms for fragmented MP4 files.

bug #700505

Following a representation change that causes a resolution change,
the video decoder fails to decode correctly. Dashdemux detects the
representation change and pushes a new caps event and an
initialization segment (a new moov atom) to the downstream qtdemux,
but it doesn't handle this new moov yet, it will only parse the
first one it receives.

This commit changes qtdemux to accept a new moov in a dash bitstream
switching scenario.
This commit is contained in:
Alex Ashley 2013-06-11 15:02:21 +01:00 committed by Thiago Santos
parent 384e8f6c34
commit 46a137c810

View file

@ -4582,7 +4582,7 @@ gst_qtdemux_chain (GstPad * sinkpad, GstObject * parent, GstBuffer * inbuf)
if (fourcc == FOURCC_moov) {
/* in usual fragmented setup we could try to scan for more
* and end up at the the moov (after mdat) again */
if (demux->got_moov && demux->n_streams > 0) {
if (demux->got_moov && demux->n_streams > 0 && !demux->fragmented) {
GST_DEBUG_OBJECT (demux,
"Skipping moov atom as we have one already");
} else {
@ -4591,6 +4591,10 @@ gst_qtdemux_chain (GstPad * sinkpad, GstObject * parent, GstBuffer * inbuf)
if (demux->got_moov && demux->fragmented) {
GST_DEBUG_OBJECT (demux,
"Got a second moov, clean up data from old one");
if (demux->moov_node)
g_node_destroy (demux->moov_node);
demux->moov_node = NULL;
demux->moov_node_compressed = NULL;
} else {
/* prepare newsegment to send when streaming actually starts */
if (!demux->pending_newsegment)