> I would suggest removing the "Output Channel Numbering" field because it
> is fully equivalent to simply permuting lines of the matrix. Also, I
> believe that the size of the matrix was meant to be "32*(N+M)*C bits"
> rather than "32*N*C bits".
So based further discussions off-list with Mark and Tim, it seems like
there's a few issues with RFC7845 that would need to be addressed:
5.1.1. Channel Mapping
> The order and meaning of these
> channels are defined by a channel mapping, which consists of the
> 'channel mapping family' octet and, for channel mapping families
> other than family 0, a 'channel mapping table', as illustrated
> in Figure 3.
This seems to impose that all other families have a channel mapping
table, which as I pointed out for family 3, isn't always appropriate. So
I think this draft should update RFC7845 to state that only the "Stream
Count" and "Coupled Count" fields are required for all families greater
than 0. The channel mapping table isn't required unless a particular
family defines it.
5.1.1.4. Undefined Channel Mappings
> The remaining channel mapping families (2...254) are reserved. A
> demuxer implementation encountering a reserved 'channel mapping
> family' value SHOULD act as though the value is 255.
If we change the channel mapping table to not be defined for all
families, then we would need to update this paragraph to state that
undefined families should be treated as 255, but assuming an "identity
ordering" rather than attempting to read a mapping table that may not
actually exist.
I also think we should officially mark families 250-254 (or maybe a
larger range?) as reserved for experimental features that have yet to be
assigned a permanent family number by IANA. For example, the Opus code
currently uses 254 and 253 to handle what would be families 2 and 3 ones
this draft becomes RFC.
Mark, Tim, did I forget anything?
Cheers,
Jean-Marc
_______________________________________________
codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/codec
