GNOME Bugzilla – Bug 670921
[tsdemux] File can not preroll when tsdemux is autoplugged into playbin2
Last modified: 2012-05-24 08:24:04 UTC
Created attachment 208537 [details] Full log of playbin2 failling to start playing + dump file of the created pipeline This sample file: http://people.collabora.com/~tsaunier/media-samples/DVB_subtitles__MPEG-1_Layer__MPEG-2_Video Plays correctly when building the pipeline by hand such as: gst-launch souphttpsrc location=http://people.collabora.com/~tsaunier/media-\ samples/DVB_subtitles__MPEG-1_Layer__MPEG-2_Video ! tsdemux name=d ! \ mpegaudioparse ! mad ! input-selector ! queue ! \ audioconvert ! audioresample ! autoaudiosink d. ! mpegvideoparse ! \ ffdec_mpegvideo ! input-selector ! queue ! ffmpegcolorspace ! \ subtitleoverlay name=sub ! ffmpegcolorspace ! autovideosink d. ! \ queue ! sub. but bumping the rank of tsdemux so it gets autoplugged, the pipeline never start playing, I attache here a full log. Note that playing the same file locally produces the the exact same result. The fact that playbin2 adds a multiqueue right after the demuxers seems the be the "cause" of the issue.
Is this for all files or only this one? Does this file work with the other demuxer? This usually happens because the multiqueue is filled up and stuff blocks (check from the logs if this happens) or because the different streams are incorrectly timestamped (e.g. one stream being much ahead of another stream).
It happens only with this file, and tsdemux (works with mpegtsdemux).
The problem is that in the PMT, a stream (pid=0x25a and stream_type=mpegaudio) is declared, but this stream actually contains no data. The tsdemux element creates the src pads directly according to the Program Map Table from the media stream, without knowing if the stream that are declared there actually contain data or not. So we get stuck waiting for data from the pad which will never happen. As opposed, the mpegtsdemux element creates the pads when data arrives for a particular stream, so this problem doesn't exists. I am not sure what would be a smart fix for that, I think it is a choice to do it the way it is done, so we shouldn't use the same strategy as the mpegtsdemux element (moreover, according to a comment in mpegtsdemux "Adding streams (pads) early fixes a wedge in some low bitrate streams, but causes deadlocks - disabled for now").
Could you check with Edward why pads are not only added after the streams have data? We're doing the same in asfdemux too btw, I think it's the safer approach for 0.10 and in 0.11/1.0 we should be able to do it differently by using the GAP events.
Created attachment 208690 [details] [review] Fix the bug activating pads only when receiving data for the streams
commit ece4dfc3c6316e77a21d794d6df42244bdf382dd Author: Thibault Saunier <thibault.saunier@collabora.com> Date: Wed Feb 29 11:14:15 2012 -0300 tsdemux: Activate pads only when receiving data for the stream https://bugzilla.gnome.org/show_bug.cgi?id=670921
The fix was correct ... except that you forgot to emit no-more-pads when all streams that were valid (have a pad) were activated. Resulting in live streams sitting there until multiqueue becomes full. I have a pending patch for this.
I think not emiting nmp is done on purpose in the mpeg TS demuxer. In mpeg-ts new streams can be added at any time, so we took the desicion not to emit it (and discussed that on IRC) There is a bug report (#665814) about that for mpegtsdemux.
Streams might be added at any time, but that probably does not happen all the time (as in often). Even then this could be handled by considering it as a program switch which itself is a sort-of chain switch and handle it accordingly (adding new pads, eos old pads, remove old and then no-more-pads again). No emitting no-more-pads at all has the disadvantage mentioned earlier as well as not playing along nicely (at all) with decodebin2.
commit 77f87ab7587204816aea04e74d75e15a145ffd52 Author: Edward Hervey <edward@collabora.com> Date: Fri May 18 10:07:56 2012 +0200 tsdemux: Emit no-more-pads when all pads are activated Fixes #670921 again
*** Bug 649494 has been marked as a duplicate of this bug. ***