GNOME Bugzilla – Bug 644395
mpegtsdemux / mpegtsmux: data flow error
Last modified: 2014-02-26 13:39:22 UTC
easy to reproduce: $ gst-launch-0.10 videotestsrc ! x264enc ! mux. audiotestsrc ! ffenc_ac3 ! mux. mpegtsmux name=mux ! mpegtsdemux ! fakesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data flow error. Additional debug info: gstbasesrc.c(2550): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: streaming task paused, reason error (-5) ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... according to __tim this is caused by a bug in mpegtsdemux'ssend_event return value aggregation and/or mpegtsmux being to bitchy about that case
Fixed the main problem: commit 70e71562b7aee9eaf8002b72beb950a026863847 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Mon Mar 14 12:33:29 2011 +0000 mpegtsmux: don't error out if downstream fails to handle the newsegment event If downstream doesn't handle the newsegment event, don't error out (esp. not without posting a proper error message on the bus), but just continue. If there's a problem, we'll find out when we start pushing buffers. https://bugzilla.gnome.org/show_bug.cgi?id=644395 demuxer send_event return aggregation still needs fixing, keeping bug open for that.
There is a tsdemux_combine_flows nowadays which seems to do what it should be doing afaics, so that should take care of this, unless some more/other "fixing" was meant here ?
This is all a bit stupid/weird. The reason why it fails, is because pushing a tag event onto tsdemux returns FALSE. As a result, when mux:src pushes out the sticky events, gst_pad_send_event_unchecked will consider that as an error and return GST_FLOW_ERROR, and everything will fail because of that :( Shouldn't tags be considered as non-fatal if downstream didn't handle it ?
It doesn't seem right that it errors out because tags weren't accepted. But then tsdemux should probably also not return FALSE here (it should just forward the tags on all pads IMHO, at least if they have global scope).
It receives those tags before any data, so it doesn't know of any programs, so no source pads exists, so it returns FALSE. Maybe mpegtsmux shouldn't forward the tags it receives on its sink pad ?
It should drop all the stream-specific tags but keep the global ones IMHO.
Created attachment 270218 [details] [review] tsdemux: store global tags to push later Keep a list of current global tags around and push them whenever a new stream is started. Also drop all stream specific tags in favor of the tags that are found while demuxing the ts data.
Created attachment 270219 [details] [review] mpegtsmux: forward tags that have global scope Instead of dropping all tag events
Comment on attachment 270218 [details] [review] tsdemux: store global tags to push later I think stream-scope tags should be converted to global-scope tags in demuxers. They were stream-scope for the container stream, so are now global scope for all inside-the-container streams
Created attachment 270262 [details] [review] tsdemux: store global tags to push later updated patch based on comment. Now the stream tags are converted to global when stored. Thanks for the review.
Thanks for reviewing. commit 2b3c3d485bc5ef16f2b21c883a687c23eeb2fe51 Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Mon Feb 24 22:53:14 2014 -0300 mpegtsmux: forward tags that have global scope Instead of dropping all tag events https://bugzilla.gnome.org/show_bug.cgi?id=644395 commit 6b4ce0d04fed78dd30625928b867cd24468a561f Author: Thiago Santos <ts.santos@sisa.samsung.com> Date: Mon Feb 24 22:43:56 2014 -0300 tsdemux: store global tags to push later Keep a list of current global tags around and push them whenever a new stream is started. Also convert all stream specific tags to global as they are stream specific for the container, so they are global for the streams from within that container. https://bugzilla.gnome.org/show_bug.cgi?id=644395