[gst-devel] channel configuration

[Benjamin Otte]

On Tue, 27 Apr 2004, Ronald S. Bultje wrote:

> So, my proposal, I actually have two.
>
> The first is to take the faad/a52/dts approach: use a number of front,
> rear and low-frequency (LFE, ususally subwoofer) channels. You can then
> get an audio configuration like 3F1R+LFE, which means 3 front (left,
> center, right), 1 read (center) and one LFE. That means that in the case
> of audio/x-raw-int,width=16,depth=16, the first two bytes in the buffer
> are a sample for left-front, then the next two bytes are a center-front
> sample, right-front, center-rear, lfe and then back to left-front again.
> This is simple, managable, easily implementable but not very extendible.
> The property would be called something like channel_positions and would
> contain something like a GstStructure, which contains properties
> 'front', 'rear' and 'lfe', all ints, with their respective numbers. I
> can shortcut this in gst-plugins/gst-libs/gst/audio/audio.[ch] if
> wanted.
>
Are there any places where this does not work? Not hypothetical, but
prectical, do you know of any apps that use more sophisticated stuff?

> The second is to take the Matroska approach, where every channel has a
> degree-number associated with it, which is the number of degrees (0-360)
> from the center front speaker (point-of-origin). This is harder to
> implement, especially because of the theoretical option that the
> left-front-speaker in the audiosink is located slightly differently from
> the intended left-front speaker position in the audio source. The buffer
> has a similar layout as in the previous proposal, except that the order
> of samples is as given in the array of channel positions instead of
> simply left-to-right, front-to-rear-to-lfe.
>
I'm afraid of something that ends up as bad as our RGB caps.
And I'm not writing the converter here.

So I'd go with the first solution and make sure we have a converter that
is capable of converting any to any with the caps we defined.

Benjamin