[gstreamer-bugs] [Bug 480222] mpegdemux does not emit no-more-pads signal

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=480222

  GStreamer | gst-plugins-ugly | Ver: 0.10.6




------- Comment #2 from Wouter Cloetens  2007-09-27 08:25 UTC -------
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?


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=480222.