On Fri, Jun 10, 2016 at 10:39:23PM -0700, Michael Graczyk wrote: > The libopus encoder has a parameter called "channel mapping family" which > is used to specify inter-channel relationships for the purpose of encoding. > I have added a new command line argument which makes it possible to forward > the mapping family parameter along to libopus. > > With this parameter, it is possible to choose between encoding multichannel > audio streams as surround sound (with interchannel masking and channel > coupling) versus independent channels (no interchannel masking nor channel > coupling). > > Example usage: > > $ wget https://samples.ffmpeg.org/A-codecs/wavpcm/8_Channel_ID.wav -O in.wav > > # Use the old behavior. Header contains layout, but no masking > $ ./ffmpeg -y -i in.wav -c:a opus -mapping_family -1 out.ogg > > # Use libopus surround mode. Masking + automatic channel coupling > $ ./ffmpeg -y -i in.wav -c:a opus -mapping_family 1 out.ogg > > # Use libopus with independent channels. No header info, no masking, no > coupling > $ ./ffmpeg -y -i in.wav -c:a opus -mapping_family 255 out.ogg > > This patch also makes it possible to encode up to 254 channels with opus > using channel mapping family 255. > > $ head -c 1728000 /dev/urandom > noise.raw > $ ./ffmpeg -y -f s16le -ar 48000 -ac 18 -i noise.raw -c:a opus > -mapping_family 255 out.opus > > > Questions: > > 1. I had to remove .channel_layouts form ff_libopus_encoder to allow the > encoder to accept streams with more than 8 channels. Is that the right way > to extend the encoder? Based on a discussion on #ffmpeg it seemed like > removing the .channel_layouts field would be the only way to allow more > than 16 channels.
> 2. Am I using AVFrame.data correctly? I recall reading somewhere that > channels after the eighth would be stored in extended_data, but from the > documentation it seems like that is only the case for planar data. extended_data is for more than AV_NUM_DATA_POINTERS planar channels, yes it seems this patch moves some code around, can that be split into a seperate patch so its more clearly vissible what is changed. Also iam not sure people will like the aprouch taken by this patch or prefer the mapping_family to be passed through API like side data and be preserved from input to output [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel