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 583510 - playbin2 plugs my sink even though it only does a subset of what a decoder does
playbin2 plugs my sink even though it only does a subset of what a decoder does
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-05-22 00:27 UTC by Andreas Frisch
Modified: 2011-05-20 06:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
debug log of Internal data flow error caused by incorrect plugging (97.23 KB, application/octet-stream)
2009-05-22 00:28 UTC, Andreas Frisch
Details

Description Andreas Frisch 2009-05-22 00:27:08 UTC
Please describe the problem:
i have a sink which has audio/mpeg mpegversions {1, 2, 4} as static caps. now depending on the actual hardware, in the get_caps function i may either decide to support mpeg 1 layer 3 stream decoding (parsed=true) or not allow them.
on the box with mp3 hardware decoder, playbin2 mp3 playback works fine
on the legacy box without mp3 support, i expect mad to do the decoding, but instead playbin2 plugs mp3parse and then ends up with an internal data flow error because my sink turns out to not accept the stream after all.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Andreas Frisch 2009-05-22 00:28:57 UTC
Created attachment 135148 [details]
debug log of Internal data flow error caused by incorrect plugging

GST_DEBUG=*:3,*dvb*:5,*playbin2*:5 gst-launch playbin2 uri=....
Comment 2 Andreas Frisch 2009-05-25 06:04:28 UTC
the problem also applies to a case where my sink limits the allowed spectrum of rates for mp3 streams:

0:00:01.437935000  1055 0x10061e20 DEBUG         dvbaudiosink gstdvbaudiosink.c:511:gst_dvbaudiosink_get_caps:<dvbaudiosink0> old caps: audio/mpeg; audio/x-ac3; audio/x-private1-ac3; audio/x-dts; audio/x-private1-dts                                                                                                
new caps: audio/mpeg, mpegversion=(int)1, layer=(int)[ 1, 2 ], rate=(int)[ 0, 48000 ]; audio/mpeg, mpegversion=(int)1, layer=(int)3, rate=(int){ 44100, 48000 }; audio/mpeg, mpegversion=(int)2, rate=(int){ 96000, 88200, 64000, 48000, 44100, 32000, 24000, 22050, 16000, 12000, 11025, 8000, 7350 }; audio/mpeg, mpegversion=(int)4, rate=(int){ 96000, 88200, 64000, 48000, 44100, 32000, 24000, 22050, 16000, 12000, 11025, 8000, 7350 }; audio/x-ac3; audio/x-private1-ac3; audio/x-dts; audio/x-private1-dts

in this case, prerolling also fails instead of playbin2 choosing a fallback decoder instead which can handle e.g. a rate of 22050.
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2009-10-28 11:32:34 UTC
I could only think of making playbin2 retry with different elements (no idea how easy that is). Now at first we would need to figure out from which elemnt the error comes. Do your decoders do a GST_ELEMENT_ERROR( elem, GST_STREAM_ERROR_xxx, ...)?
Comment 4 Andreas Frisch 2009-10-28 11:42:01 UTC
hi stefan,

in case an unhandled stream type arrives in the sink, we throw 
GST_ELEMENT_ERROR (self, STREAM, TYPE_NOT_FOUND, (NULL), ("unimplemented stream type %s", type));

but that doesn't even happen since static caps previously excluded e.g. layer 3 from mpeg audio streams. therefore it's not redirected at all into our sink by playbin2 and the stream error is being invoked outside our domain
Comment 5 Sebastian Dröge (slomo) 2011-05-20 06:28:26 UTC
This should be fixed now in the latest release of gst-plugins-base. The logic to select sinks was improved.