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

[Bultje, R.S.]

Hi,

> From: Benjamin Otte [mailto:in7y118 at public.uni-hamburg.de]
> 1) use a different mime type to make sure plugins that carelessly exported
> more than 2 channels don't mess up our pipelines. Use something like
> "audio/x-raw-int-positioned" or something.

That might be a good idea, but has some disadvantages. It will make conversion in audioconvert somewhat more of a pain, for example. I was hoping to prevent that by specifying that channels==2 is always stereo (LF,RF) and channels==1 is always mono, that pretty much covers everything.

> 2) use the same caps as audio/x-raw-int apart from the channels property.

I'd prefer this... If it really causes problems, I can always remove it again. consider the current state of all this "developmental" and "experimental".

> 3a) make a property for each channel, like "channel1=LF,channel2=RF".
> Maybe make sure the list is terminated, like
> "channel1=LF,channel2=RF,channel3=''". Or use numbers instead of strings.

Numbers is easier since it allows for switch/cases. Not sure if we want that, but I can add some defines to gst/audio/audio.h, or even a real enumeration type.

> 3c) invent a new caps type (that'd require quite some work for
> serialization, intersection and such) for an array. Put the strings in an
> array.
[..]
> The problem with 3 is that we must be able to specify fixed caps and
> ranges. There might be elements that allow any subset of a channel setup
> in their caps and this must be available in a serializable and
> intersectable form so the caps system doesn't screw up.

This will be hard, I know that. Arrays will screw up loads of things if we make them lists. Basically, my first-thought proposal was to handle channel_positions similar to codec_data: it is *always* fixed. But that wouldn't work for sink elements like alsasink, so audioconvert would screw up negotiation with alsasink.

What we could do is to call fixation on elementary types recursively if a type if an array. So for a GValueArray type, you would re-fixate/-intersect each member of the array. Not sure if this has negative side-effects, but it makes fixed-vs-range-or-list work.

This has the negative aspect that you need to exactly specify channel positions on caps, so templates become somewhat harder and should probably be generated rather than written out as a string (as we currently do). Mpeg2enc uses this as well. So an alsasink template would then look like this (quasi-coding, only showing the x-raw-int part, not sure if the 4:0 channel thing is correct):

audio/x-raw-int,
  channels=(int)[1,2],
  ..;
audio/x-raw-int,
  channels=(int)4,
  channel_positions=(int)<LF,RF,LR,RR>,
  ..;
audio/x-raw-int,
  channels=(int)6,
  channel_positions=(int)<LF,RF,LR,RR,C,LFE>,
  ..

LF/RF etc. are similarly parsed as BYTE_ORDER & co. Maybe that requires a separate type (channel_position instead of int), I'm not that much into GValue hooking yet, but it should be doable. LF/RF etc. will then be a GType'ed enumeration. alsasink/a52dec/dtsdec would have fairly simple caps templates (since they have fairly limited abilities for multi-channel).

Faad would be harder, because the caps template would have to specify a range or list for each channel option (which is why you want to autogenerate the template rather than write it down fully). Basically, any channel number can have any channel position, and a stream can contain any number of channels (if I understand the lib correctly). Audioconvert would be similarly tricky. that's the downside of the whole thing. Not to mention that conversion in audioconvert would be tricky as well, but that's your problem, not mine </bad argument>. ;).

If someone can finetune this or has better ideas/comments, please give your input!

Ronald
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20040430/8cb9c1d9/attachment.htm>