GNOME Bugzilla – Bug 311423
[playbin2] ac3/dts passthrough
Last modified: 2018-05-04 08:45:44 UTC
$ totem ~/Desktop/King_Kong_Trailer_1080i_DD5.1.ts No accelerated IMDCT transform found ERROR (0xbe2ba0 - 311727:33:54.078035000) GST_PADS(29550) gstpad.c(2562):gst_pad_set_explicit_caps:<a52dec0> failed to negotiate (try_set_caps with "audio/x-raw-float, endianness=(int)1234, width=(int)32, channels=(int)6, rate=(int)48000, buffer-frames=(int)0, channel-positions=(GstAudioChannelPosition)< GST_AUDIO_CHANNEL_POSITION_LFE, GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT, GST_AUDIO_CHANNEL_POSITION_FRONT_CENTER, GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT, GST_AUDIO_CHANNEL_POSITION_REAR_LEFT, GST_AUDIO_CHANNEL_POSITION_REAR_RIGHT >" returned REFUSED) ERROR (0xbe2ba0 - 311727:33:54.078253000) scheduler(29550) gstoptimalscheduler.c(2800):gst_opt_scheduler_iterate:<optscheduler1> in error state (totem:29550): GStreamer-WARNING **: element internal_thread claimed state-change success,but state didn't change to PLAYING. State is PAUSED (NONE_PENDING pending), fix the element ** Message: Couldn't initialize lirc. (totem:29550): GStreamer-CRITICAL **: gst_element_get_factory: assertion `GST_IS_ELEMENT (element)' failed
Try 'alsasink device=hw:0' in gstreamer-properties?
Oh, n/m, so this is SPDIF, which we indeed do not support yet.
I'm not sure gstreamer even knows/tries to use SPDIF here. Xine plays the file ok, but xine is told explicitly (~/.xine/config) to use SPDIF output. I haven't configured gstreamer in any way to use a specific ALSA output type/port. This only seems to happen with the a52dec element. Playing an mp3 or other non-ac3 video works fine with totem+gstreamer. Perhaps the a52dec element detects AC3 output and encounters the SPDIF output and can't deal with that?
Copying Mike for comment on the SPDIF/ac3 issues and Totem. He has an element to do that that will land in CVS at some point. I'm ignoring the crasher part now, because it seems to be 0.8 scheduling-related, and 0.8 is unmaintained.
To support SPDIF/raw ac3 output from playbin, we'll need to enhance playbin and decodebin's autoplugging logic. Adding the audiosink that supports ac3 output to CVS is easy enough, but at the moment playbin won't use it because decodebin always keeps plugging until it has decoded raw audio samples - there's no way (at the moment) to tell it to stop when it finds audio/x-ac3
Could someone remind me what the actual issue here is again, besides the 'would be nice if we had an alsaspdifsink and playbin could support that' (which should probably be two separate feature request bugs in -base, no?)? So the sink _only_ supports SPDIF and that's why things fail?
It shouldn't crash?
Besides the crash I meant (which was - probably correctly - attributed to 0.8 scheduler/thread borkage in comment 4) :)
We now have an alsaspdifsink. Playbin still does not support it. Changing bug title and severity to reflect this.
I think alsasink also handles SPDIF now, rendering alsaspdifsink obsolete (not that it matters much in terms of implementation).
I’m really interested in finally seeing SPDIF output work with Totem+GStreamer, probably enough to code some bits, so could anyone sum up what is missing and what should be done if we want to see it working?
(In reply to comment #10) > I think alsasink also handles SPDIF now, rendering alsaspdifsink obsolete (not > that it matters much in terms of implementation). Actually it doesn’t seem to work. The following does not work: gst-launch-0.10 -v filesrc location=/tmp/toto.ac3 ! ac3iec958 ! alsasink while the following does: gst-launch-0.10 -v filesrc location=/tmp/toto.ac3 ! ac3iec958 ! alsaspdifsink but actually playbin does not use it. AIUI, we need to extend playbin with a new property so that it actually understands that we want IEC958 output. Otherwise you may end up with no sound on other systems. If this parameter is set and if the audio stream type is audio/ac3, we should replace the audio decoder by ac3iec958 and the output sink by alsaspdif sink. Does it feel like a correct approach? I’m ready to code it, however I’m relatively new to GStreamer and don’t know where these are set in playbin, so if someone could point me to where to start, it would be very nice.
Doesn't this work now with playbin2 ? gst-launch-0.10 -v playbin2 uri=file:///tmp/toto.ac3
Closing as no additional information was provided (playbin2 should theoretically support this)
> Closing as no additional information was provided The NEEDINFO was bogus in the first place. Comment #12 has a summary of the situation. I don't think much has changed since then. > (playbin2 should theoretically support this) playbin2 still won't plug ac3iec958 or do AC3 passthrough for alsasink/spdif, so reopening.
*** Bug 435123 has been marked as a duplicate of this bug. ***
Some design study on http://gstreamer.freedesktop.org/wiki/PlayBinPassthrough now.
This should work now with the latest pulseaudio and gstreamer git, if passthrough is configured for these formats in the pulseaudio GUI. Still needs implementing in alsasink, but that shouldn't keep this bug open really.
Dear Tim-Philipp, your last post (Comment 18) sounds interesting. But which pulseaudio GUI? pavucontrol? paprefs?
http://www.pulseaudio.org/wiki/Passthrough
Isn't this fixed with pulseaudio nowadays ?
Yes, also alsasink can do compressed passthrough. This should just work in theory nowadays in playbin, there's only an open issue about renegotiation in pulsesink which has another bug (devices might be replugged, losing AC3 support so that you suddenly need to start decoding).