[gstreamer-bugs] [Bug 551660] gstreamer fails to handle variable number of channels in AC3 stream

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Fri Sep 12 10:05:55 PDT 2008


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=551660

  GStreamer | don't know | Ver: 0.10.x

Thijs Vermeir changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thijsvermeir at gmail.com




------- Comment #8 from Thijs Vermeir  2008-09-12 17:05 UTC -------
(In reply to comment #7)
> Patch almost works, but I had to replace
> gst_structure_fixate_field_nearest_int() call with gst_structure_set() as first
> invocation fixates number of channel to 2 and never changes it later, as as a
> result renegotiation never occurs. No idea if it can break something else,
> could use some guidance here.

That does not sound correct,... the gst_structure_fixate_field_nearest_int
tries to get the amount of channels allowed in the caps. Using the *_set
function does not look at the caps and forces this amount of channels (which
can be a not allowed channel number in some cases). However we pick the first
caps from a list of allowed caps, the caps are sorted in preferred order of the
sink. However I see that alsasink is not prefering more channels over stereo...

alsa gstalsasink.c:321:gst_alsasink_getcaps:<alsasink0> returning caps
...channels=(int)[ 1, 2 ]; ... channels=(int)4 ...

So, on my system a52dec will always try to downmix to 2 channels because
alsasink prefers this over multiple channels...but I assume that this is a bug
in alsasink and it should prefer as much channels as possible.

> Following the chain... pulsesink only handles change in like 30% of cases,
> failing in other 70% in gst_pulsesink_prepare(), some kind of timing/threading
> issue.. But thats another story, for now got around it by disabling check for
> stream state after connect.

Can you check what pulsesink is returning as preferred caps?


-- 
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=551660.




More information about the Gstreamer-bugs mailing list