After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 400134 - [playbin] support non-raw-formats sinks
[playbin] support non-raw-formats sinks
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.11
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-01-24 10:09 UTC by Tommi Myöhänen
Modified: 2007-12-05 17:55 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Tommi Myöhänen 2007-01-24 10:09:59 UTC
We have a case where there's a hw audio decoder and also audio rendering is done outside gstreamer. Our idea is that decodebin2 could be used for demuxing and a special sink element could be used to feed the encoded data to decoder. However currently decodebin2 is expected to produce raw decoded a/v data. Also playbin is expected to deal with a/v sinks consuming raw decoded data. 

More flexibility could be added e.g. with the following modifications:

* Adapt decodebin2 to sink elements existing in system

 - Decodebin2 could scan the registry for supported sink element caps, these caps could be then used to determine when to finish decodebin2 construction. Currently there are hard-coded caps for raw audio and video used for this purpose.

* Playbin to support sinks consuming encoded data
 - If decodebin2 didn't produce raw decoded data, then convert, scale, etc. elements would be omitted before the sink

* More intelligent sink selection in autoaudiosink
 - Autoaudiosink could use offered caps information when choosing sink. Currently autoaudiosink chooses one of sink candidates when it can switch one to ready state successfully. 

What do you think, all comments welcome!
Comment 1 Edward Hervey 2007-01-24 11:44:40 UTC
Tommi, decodebin2 can do exactly what you're asking for... In fact it was designed partly to support EXACTLY what you want to do (hint:n770).

What you need to do is to tell decodebin2 what formats you can handle outside of it.

Let's say, for example, you can handle "audio/mpeg,mpegversion=1,layer=[1,3]" with a dedicated sink. The easiest way is to add that caps to the 'caps' property of decodebin2.
By default 'caps' contains all know raw audio/video/text formats, so you need to create a new caps containing those PLUS your format:

mycaps = gst_caps_from_string("video/x-raw-yuv;video/x-.....plain;text/x-pango-markup;audio/mpeg,mpegversion=1,layer=[1,3]");
g_object_set (mydecodebin2, "caps", mycaps, NULL);

decodebin2 will then consider mp3 as a final format and will provide you that pad like any other raw stream (using 'new-decoded-pad' callback). Then you can connect it to your dedicated sink.


On the other hand, playbin HAS to be modified to support what you request. In the same way decodebin2 was created from scratch, there is a new playbin (playbin2) currently being designed which will use all the advantages decodebin2 brings and be able to handle the features you mention.

Changing the bug title accordingly.
Comment 2 Tommi Myöhänen 2007-01-24 16:03:05 UTC
Allright, nice to find out you've already been thinking about this :) It looks like we pretty much agree about the general idea. The main difference seems to be that you've been planning to make playbin2 aware of supported sink caps instead of decodebin2. That might be a good idea, that way sink handling can be isolated as playbin2's task and demuxing/decoding will be decodebin2's task. Any news when first version of playbin2 will be available, I couldn't see one yet in cvs?
Comment 3 Wim Taymans 2007-12-05 17:55:19 UTC
it's in CVS nowadays and supports non-raw sinks. closing.