[gstreamer-bugs] [Bug 417420] [autoaudiosink] add "caps" property to filter sinks by caps

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=417420

  GStreamer | gst-plugins-good | Ver: HEAD CVS





------- Comment #11 from Jan Schmidt  2007-03-14 16:08 UTC -------
At the moment, playbin2 is modelled on a large pipe that delivers dreams. ie,
it doesn't look like anything yet.

I think it is extremely unlikely that caps negotiation and autopluggin will
ever interact in a way that would allow this behaviour - the semantics of this
scenario as I see them are: 

a) wait until decodebin2 indicates that encoded audio is a possibility, in a
format that you *might* have a hardware decoding sink for.
b) go try your sinks and see if one manages to attain READY state
then
c1) if you found a sink, tell decodebin2 you're happy to accept the encoded
audio directly so it will output it, then connect that to your hardware sink
or
c2) none of the sinks worked/are available and you need software decoding so
you should get decodebin2 to continue plugging decoders on this stream and get
autoaudiosink to find you a decoder for a raw audio stream instead.

Similar logic applies to the (also imaginary at the moment) case of using an
XvMC sink to collaborate in decoding MPEG-2.

Further complications arise if we want to consider how you'd handle switching
between software decoding and hardware decoding on the fly - for example
switching between an mp3 track and an AC-3 track within one media file. I don't
know how that would work, either technically or functionally from a user's
perspective.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email