GNOME Bugzilla – Bug 480222
mpegdemux does not emit no-more-pads signal
Last modified: 2009-05-06 15:53:42 UTC
Please describe the problem: The mpegdemux plug-in does not invoke a registered callback for "no-more-pads" once the video and audio source pads have been created. My test case is playing an MPEG-1 video file. Steps to reproduce: I set up the following chain from a program: gst-launch gnomevfssrc location=file:///home/zombie/download/mpeg/tripping.mpg ! mpegdemux name=demux demux.audio_00 ! fakesink demux.video_00 ! queue ! mpeg2dec ! ffmpegcolorspace ! videoscale ! xvimagesink Actual results: Expected results: Does this happen every time? Other information: qtdemux does do this fine. I tried to look in the sources (current svn) and I can see this being emitted for dvddemux in the same directory. It's not clear to me when the signal should be emitted though, as there are also private stream sources. How does one know when there will really be no more pads created...?
The thing is that the element cannot know when there are no more streams in the file unless it has scanned the complete file. Why do you need the signal? you can add streams while running and with queues you can peek into N MB of data while searching for the streams.
Ok, perhaps I am just misunderstanding the purpose of no-more-pads. I am using it to determine that both video and audio pads have been created, so I can build the rest of the pipeline. What I'm doing as a work-around is to listen on pad-added, determine for every pad if it's a video our audio pad, and continue when I have both. That is a lot more code than just these two lines in the no-more-pads handler: gst_element_link_pads(qtdemux, "audio_00", fakesink, "sink"); gst_element_link_pads(qtdemux, "video_00", queue2, "sink"); > The thing is that the element cannot know when there are no more streams in the > file unless it has scanned the complete file. Out of curiosity... if that is the case, then how can qtdemux and dvddemux signal no-more-pads? Does a VOB file have an index that tells you exactly how many audio and subpicture streams are available in the PS? Is QuickTime/MPEG-4's system different from the MPEG-TS/PS stream concept?
We could make mpegdemux/dvddemux emit no-more-pads. It already contains logic to guess when that can be done (currently only in order to know when to aggregate multiple downstream FLOW_NOT_LINKED into an upstream FLOW_NOT_LINKED and when to just ignore the downstream FLOW_NOT_LINKED). However, I don't think it will simplify your code a lot, because if you link pads only in the no-more-pads handler it is likely that things like newsegment events, tag events or buffers get dropped before you connect those pads.
I don't know why this bug was set to NEEDINFO, because I was the one who asked a question, not the one who should provide info. Shall we close this?
> I don't know why this bug was set to NEEDINFO, because I was the one who asked > a question, not the one who should provide info. It doesn't necessarily mean that YOU should provide info, but I guess the question was "do you still want this given that it's not particularly useful?" :) I haven't decided yet whether I want to implement this though, so keeping it open for now.
Setting the bug to an open, especially UNKNOWN, state as per comment #5 :)
no-more-pads should be used like this: - an element that knows exactly how many streams there will be for the complete duration of the stream can signal this when it has added all pads (qtdemux, avidemux). It is expected that no more pads appear while streaming. - If after the no-more-pads signal more streams appear, the application should assume that all previous pads will be removed from the element. The pads added after the no-more-pads signal belong to a new group or related media and is in no way related to the previous pads. (oggdemux with chained oggs) - An element that does not know how many streams there will be at runtime and where pads can appear/disappear while streaming, should not signal no-more-pads. The application must peek into the file for a configurable amount of time/bytes before starting playback of the discovered streams. When streams are added at a later time, they will logically belong to the previously streams. (mpeg2 but maybe not mpeg1, which has fixed headers) The no-more-pads signal thus marks the boundaries of related streams. Decodebin uses this signal to quickly start playback instead of waiting for queues to fill up. It's also used to manage the pad groups in decodebin2. so you need to look at how the container works and what the features are to determine if it should emit no-more-pads or not. Hope that clears it up.