[gst-devel] Some WavPack related questions

[Sebastian Dröge]

Hi,
I'm planning to implement proper multi-channel support and float support
in the WavPack parser/decoder/encoder and there are now two questions
that came to my mind:

a) Should a decoder that supports multichannel audio already export the
preferred channel order in the pad template? i.e. have channels=[1;8]
and then for each of this possible 8 channels the location set? Or
should one leave this undefined in the pad template, look at one gets
and then pre-process the audio data to have exactly the channel order
that the encoder wants? I'd assume the latter though it would be
slightly more work of course ;)

b) For float support there's a caps problem. Currently the parser
outputs caps like "audio/x-wavpack,width=32,channels=2,..." and the
decoder simply forwards this as "audio/x-raw-int,...". Now with float
support one could either already distinguish in the parser and add...
say... "audio/x-wavpack-float,..." or "audio/x-wavpack,float=true,..."
or leave the wavpack caps as is and only set the src pad caps of the
decoder to float or int as appropiate.
I would prefer to have it all in the caps of the parser (and the encoder
of course) but how could this be done in a backward compatible way? The
wavpack caps are at least used in the matroska stuff too...

"audio/x-wavpack-float" would work backwards compatible but is a
complete new media type although it's essentialy the same as
"audio/x-wavpack". Adding a new field to "audio/x-wavpack" would require
very special care for having it backward compatible and negotiation
work, right?

Can someone give any pointers on what could be the best way? :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20071024/16b1fbfb/attachment.pgp>