[gst-devel] multi-channel, try#2

Stefan Kost kost at imn.htwk-leipzig.de
Thu May 6 04:07:03 CEST 2004


Hi Ronald,

here is how M$ is doing it
http://www.ambisonic.net/mulchaud.html

anyway multi-channels really make things so compilcated, stereo is so easy.
When one audio-convert needs to reduce four channels to two, it will probably
just add center and rear channels with -3db to left an right channels (flatten
the sound field). Alternativly it could do dolby surround encoding, but elements
like audio-convert work best when they need no parameters (parameter mean user
intervention required) ...

Stefan

Ronald S. Bultje wrote:
> Hey gang,
> 
> so, I just thought we had this perfect layout thing... I made a
> string-like approach, '3f2rlfe' being 5:1 sound, '2f2r' or '3f1r' being
> 4:0, you get the rest. Order of samples in buffers would be interleaved,
> left-to-right, front-to-rear, then lfe. So, I thought I'd implement that
> in faad and alsa.
> 
> I can't!
> 
> Faad is slightly more complicated. Faad actually has a position per
> channel, not an enum, so the order of samples in the buffer can be
> random. That means that I need to rearrange samples before pushing out
> the buffer. Also, I can (in theory) not be very sure that the channel
> locations are equally divided from left-to-right, which is assumed by
> the above scheme, so 3-left-0-right channel setups won't work. That's
> only a theoretical issue though, it'll never happen in practice.
> 
> Alsa has the same issue: I need to re-arrange buffers before using the
> audio, because alsa expects LF,RF,LR,RR,C,LFE sample order. a52/dts spit
> out C,LF,RF,LR,RR,LFE. Faad does it random. So this will not work, it'll
> require all sort of conversions in plugins/elements, we don't want that.
> Audioconvert should do it.
> 
> So, I do a new proposal: GstCaps carries a "channel_positions" property,
> which is an array of strings of size gst_structure_get_int ("channels").
> The strings indicate channel positions. Those could also be enums
> (defined in gst/audio/audio.h), I don't really care. We'd have enums
> like in faad.h, so left-front, right-front, center, left-side,
> right-side, left-rear, right-rear, back, LFE. Think of it as your keypad
> keys, you're the 5 and all numbers around you are possible channel
> positions.
> 
> So, is everyone fine with this? I want to prevent using the "gradient"
> approach from matroska, because it'll make conversions horribly
> difficult, it's simply too complicated for now. I guess this is the most
> workable solution. The magic will happen in audioconvert...
> 
> Ronald
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> 

-- 
      \|/            Stefan Kost
     <@ @>           private            business
+-oOO-(_)-OOo------------------------------------------------------ - - -  -   -
|       __  Address  Simildenstr. 5     HTWK Leipzig, Fb IMN, Postfach 301166
|      ///           04277 Leipzig      04251 Leipzig
| __  ///            Germany            Germany
| \\\///    Phone    +49341 2253538     +49341 30766101
|  \__/     EMail    st_kost_at_gmx.net kost_at_imn.htwk-leipzig.de
|           WWW      www.sonicpulse.de  www.imn.htwk-leipzig.de/~kost/about.html
===-=-=--=---=---------------------------------- - - -  -    -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kost.vcf
Type: text/x-vcard
Size: 345 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20040506/692883cb/attachment.vcf>


More information about the gstreamer-devel mailing list