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 430677 - [audioconvert] does not preserve channel positions when fixating
[audioconvert] does not preserve channel positions when fixating
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 0.10.15
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 490184 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-04-17 14:25 UTC by Jindrich Makovicka
Modified: 2007-10-31 18:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
audioconvert patch (789 bytes, patch)
2007-04-17 14:25 UTC, Jindrich Makovicka
none Details | Review
don't loose channel positions (3.02 KB, patch)
2007-10-26 11:46 UTC, Thijs Vermeir
none Details | Review

Description Jindrich Makovicka 2007-04-17 14:25:02 UTC
Currently, audioconvert does not pass the channel positions, which disallows i.e. recoding from DTS do AC3, because dtsdec produces float samples while ffmpeg AC3 encoder accents only integers.

The attached patch ensures that the position information is passed when the channel count does not change.
Comment 1 Jindrich Makovicka 2007-04-17 14:25:50 UTC
Created attachment 86499 [details] [review]
audioconvert patch
Comment 2 Sebastian Dröge (slomo) 2007-04-17 15:03:34 UTC
I wonder if the channel positions shouldn't always be set in the outcaps... Currently when converting I see no place where the channel positions are set so the channel positions in the output are more or less undefined unless I'm mistaken.

Other than that, if the channel positions were set before, this patch looks fine IMHO... having someone who knows a bit more about the channel position business take a look at it would be better before committing though :)
Comment 3 Tim-Philipp Müller 2007-04-17 15:27:02 UTC
I noticed this issue as well when working on bug #398033.

I think we really need some unit tests for this stuff (there might already be one or two related tests in the patch for the other bug to build on, but we need to check down/upmixing too both for channels >2 and <=2).
Comment 4 Tim-Philipp Müller 2007-10-25 17:26:12 UTC
*** Bug 490184 has been marked as a duplicate of this bug. ***
Comment 5 Thijs Vermeir 2007-10-26 11:46:14 UTC
Created attachment 97911 [details] [review]
don't loose channel positions

Behavior of this patch:
- if no channel up/down-mixing keep the same channel-positions.
- if up/down-mixing use the channel-positions from the otherpeer.

If channel positions are not present, add the default channel positions and give a warning that there is a multichannel element without proper channel positions.
Comment 6 Tim-Philipp Müller 2007-10-31 18:33:05 UTC
I think we need something a bit more elaborate here, since there's no guarantee the possible output caps have a fixed channel layout (it may be a list of possible layouts), or -- in case that input and output have the same number of channels -- that downstream can do the input channel layout:

 2007-10-31  Tim-Philipp Müller  <tim at centricular dot net>

        * gst/audioconvert/gstaudioconvert.c: (find_suitable_channel_layout),
          (gst_audio_convert_fixate_channels), (gst_audio_convert_fixate_caps):
          Preserve channel layout when fixating the number of channels in the
          output caps, or make sure there's a suitable channel position layout
          set on the caps if required. Fixes #430677.

(Thijs: also, you probably meant to fixate first and only read the number of output channels fixated to after that :)).

Please test and re-open if it doesn't work right.