search for: channel_map

...,NULL, 0}, {"downmix-stereo",no_argument,NULL, 0}, {"no-downmix",no_argument,NULL, 0}, @@ -337,6 +340,7 @@ int main(int argc, char **argv) opus_int32 coding_rate=48000; opus_int32 frame_size=960; int chan=2; + int channel_mapping=-1; int with_hard_cbr=0; int with_cvbr=0; int expect_loss=0; @@ -465,6 +469,12 @@ int main(int argc, char **argv) fprintf(stderr,"Expected loss is a percent and must be 0-100.\n"); exit(1); } +...

...r. >> I that this is handled pretty nicely by the "simple map" that Sampo suggested. This is basically the same thing as the "channel map" described on the wiki, but with the (physical,logical) channel pair swapped. So, using the syntax from the wiki: channel_type = OGG_CHANNEL_MAP_STEREO channel_map [OGG_CHANNEL_FRONT_LEFT] = 1 channel_map [OGG_CHANNEL_FRONT_RIGHT] = 2 This is nice because it makes it impossible for somebody to do something stupid like define two channels as carrying FRONT_LEFT. A player can't handle that situation sanely, but handling both FRONT_LEFT...

> Yes. Channel map type tells us what the primary interpretation of the > stored signals is. Channel definitions are there to tell which stored > channel corresponds to which abstract channel in the type. Channel > conversions define downmixes to secondary formats, as they do in MLP, > and might end up being ignored unlike the channel map. I think the channel conversion will

> True, but remember that the channel map type implied the number of > entries in the table, and also that in this organization you'll always > number the logical channels consequtively since each logical channel > indeed corresponds to an index into the array. If the channel map type > says it's a map for 5.1, there will only be 6 slots in the table no > matter how

.... What we're proposing is to define the channel map for each supported channel group type. The array syntax I used in my last post probably added to the confusion - look at it again but without using the assigned values to the OGG_CHANNEL_* text. A couple examples: Packet 1: channel_type = OGG_CHANNEL_MAP_5_1 channel_map [0 = OGG_CHANNEL_FRONT_LEFT] = 1 channel_map [1 = OGG_CHANNEL_FRONT_CENTER] = 2 channel_map [2 = OGG_CHANNEL_FRONT_RIGHT] = 3 Packet 2: channel_type = OGG_CHANNEL_MAP_STEREO channel_map [0 = OGG_CHANNEL_FRONT_LEFT] = 1 channel_map [1 = OGG_CHANNEL_FRONT_RIGHT] = 2 Packet 3: channe...

...-stereo",no_argument,NULL, 0}, > {"no-downmix",no_argument,NULL, 0}, > @@ -337,6 +340,7 @@ int main(int argc, char **argv) > opus_int32 coding_rate=48000; > opus_int32 frame_size=960; > int chan=2; > + int channel_mapping=-1; > int with_hard_cbr=0; > int with_cvbr=0; > int expect_loss=0; > @@ -465,6 +469,12 @@ int main(int argc, char **argv) > fprintf(stderr,"Expected loss is a percent and must be > 0-100.\n"); >...

Hi Drew, Some comments on the libopusenc patch: + int _oge_use_projection(int channel_mapping); These functions are part of libopusenc, so I'd expect them to have an ope prefix like the other functions in the libopusenc library. + if (_oge_use_projection(h->channel_mapping)) + { + len=27+(h->channels*(h->nb_streams+h->nb_coupled)*2); + } + else + { + len=27...

...LS 6 #define OPUS_SURROUND_MAPPING_FAMILY 1 #define SAMPLE_RATE 48000 typedef union t_SurroundInfo { unsigned char surroundInfo[1]; struct { unsigned char channels; unsigned char streams; unsigned char coupled_streams; unsigned char channel_mapping[MAX_SURROUND_CHANNELS]; }s; }SurroundInfo; </defines and vars> <encoder> int streams = 0; int coupled_streams = 0; m_SurroundInfo.s.channels = CHANNELS; // set to 6 m_MSEnc = opus_multistream_surround_encoder_create(SAMPLE_RATE, // SAMPLE_RATE = 48000...

Hi Drew, I think the libopusenc patch is better, but there's still a few issues left: 1) The static MAX_PACKET_BUFFER_SIZE value is still problematic because if you link libopusenc with a new version of libopus that supports higher order projection or just more projection channels for order 3, then you will overflow the buffer. I think what you'd want is a _ope_opus_header_get_size() call

...LS 6 #define OPUS_SURROUND_MAPPING_FAMILY 1 #define SAMPLE_RATE 48000 typedef union t_SurroundInfo { unsigned char surroundInfo[1]; struct { unsigned char channels; unsigned char streams; unsigned char coupled_streams; unsigned char channel_mapping[MAX_SURROUND_CHANNELS]; }s; }SurroundInfo; </defines and vars> <encoder> int streams = 0; int coupled_streams = 0; m_SurroundInfo.s.channels = CHANNELS; // set to 6 m_MSEnc = opus_multistream_surround_encoder_create(SAMPLE_RATE, // SAMPLE_RATE = 48000...

...his is handled pretty nicely by the "simple map" that Sampo > suggested. This is basically the same thing as the "channel map" > described on the wiki, but with the (physical,logical) channel pair > swapped. So, using the syntax from the wiki: > channel_type = OGG_CHANNEL_MAP_STEREO > channel_map [OGG_CHANNEL_FRONT_LEFT] = 1 > channel_map [OGG_CHANNEL_FRONT_RIGHT] = 2 Not sure this is a good idea. Remember that channel_map is just an array (unless you want to make it a map?). So if you had a OGG_CHANNEL_SPECIAL with an id of 1000, it would force 1000 entries in t...

Just to confirm, I would use opeint_* for all the OpusGenericEncoder-related functions? On Tue, Mar 20, 2018 at 8:38 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Mark, Drew, > > On 03/20/2018 02:40 AM, Mark Harris wrote: > > + int _oge_use_projection(int channel_mapping); > > > > These functions are part of libopusenc, so I'd expect them to have an > > ope prefix like the other functions in the libopusenc library. > > I'd like to avoid using the ope_ prefix for functions that's aren't in > the public API. Right now th...

...g format by encoding with the Opus codec and setting the Channel Mapping Family value to 254 in the Ogg Identification Header. A demuxer implmentation encountering Channel Mapping Family 254 SHOULD interpret the Opus stream as containing ambisonics with the format described in <xref target="channel_mapping"/>. </t> <section anchor="channel_mapping" title="Channel Mapping Family 254"> <t> Allowed numbers of channels: (1 + l)^2 for l = 0...14. Explicitly 4, 9, 16, 25, 36, 49, 64, 81, 100, 121, 144, 169, 196, 225. Ambisonics from zeroth to fourteenth...

...the Ogg format by encoding with the Opus codec and setting the Channel Mapping Family value to 2 in the Ogg Identification Header. A demuxer implmentation encountering Channel Mapping Family 2 MUST interpret the Opus stream as containing ambisonics with the format described in <xref target="channel_mapping"/>. </t> <section anchor="channel_mapping" title="Channel Mapping Family 2"> <t> Allowed numbers of channels: (1 + n)^2 for n = 0...14. Explicitly 4, 9, 16, 25, 36, 49, 64, 81, 100, 121, 144, 169, 196, 225. Ambisonics from zeroth to fourteenth or...

...t; > > On Tue, Mar 20, 2018 at 8:38 AM Jean-Marc Valin <jmvalin at jmvalin.ca > > <mailto:jmvalin at jmvalin.ca>> wrote: > > > > Hi Mark, Drew, > > > > On 03/20/2018 02:40 AM, Mark Harris wrote: > > > + int _oge_use_projection(int channel_mapping); > > > > > > These functions are part of libopusenc, so I'd expect them to have > an > > > ope prefix like the other functions in the libopusenc library. > > > > I'd like to avoid using the ope_ prefix for functions that's a...

...> > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>> wrote: > > > > > > Hi Mark, Drew, > > > > > > On 03/20/2018 02:40 AM, Mark Harris wrote: > > > > + int _oge_use_projection(int channel_mapping); > > > > > > > > These functions are part of libopusenc, so I'd expect them > > to have an > > > > ope prefix like the other functions in the libopusenc > library. > > > > > > I'd lik...

...alin.ca <mailto:jmvalin at jmvalin.ca>>> wrote: >>> > > >>> > > Hi Mark, Drew, >>> > > >>> > > On 03/20/2018 02:40 AM, Mark Harris wrote: >>> > > > + int _oge_use_projection(int channel_mapping); >>> > > > >>> > > > These functions are part of libopusenc, so I'd expect them >>> > to have an >>> > > > ope prefix like the other functions in the libopusenc >>> library. >>>...

Tim, Would you mind giving me a more specific example of the sort of document that you think this should look like? I'd like to write up something that is somewhat final. On Mon, May 2, 2016 at 9:30 PM, Michael Graczyk <mgraczyk at google.com> wrote: > On Fri, Apr 29, 2016 at 4:32 PM, Timothy B. Terriberry > <tterribe at xiph.org> wrote: > > As a general point,

I've tried to solicit discussion on this point in the past, but now I'd like the press the issue for a bit. I'd like to remove the less well developed mapping header (option 1) from the OggPCM draft, and make my/our (with Martin Leese) suggestion (option 2) the definitive one. If anybody objects, let's discuss it on-list. If not, I think it wouldn't be too bad of an idea

Hi Mark, Drew, On 03/20/2018 02:40 AM, Mark Harris wrote: > + int _oge_use_projection(int channel_mapping); > > These functions are part of libopusenc, so I'd expect them to have an > ope prefix like the other functions in the libopusenc library. I'd like to avoid using the ope_ prefix for functions that's aren't in the public API. Right now there are other functions with...