Re: [codec] I-D Action: draft-ietf-codec-ambisonics-04.txt

[Jean-Marc Valin <[e-mail]>]

Hi,

Mark and I had some discussion about the required updates to RFC 7845
and we'd like to propose adding the following section to the ambisonics
draft:



5.  Updates to RFC 7845

5.1.  Format of the Channel Mapping Table

   The language in Section 5.1.1 of RFC 7845 implies that the channel
   mapping table, when present, has a fixed format for all channel
   mapping families:

      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 document updates RFC 7845 to clarify that the format of the
   channel mapping table may depend on the channel mapping family:

      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'.

      The format of the channel mapping table depends on the channel
      mapping family.  Unless the channel mapping family requires a
      custom format for its channel mapping table, the RECOMMENDED
      channel mapping table format for new mapping families is
      illustrated in Figure 3.

   The change above is not meant to change how families 1 and 255
   currently work.  To ensure that, the first paragraph of
   Section 5.1.1.2 is changed from:

      Allowed numbers of channels: 1...8.  Vorbis channel order (see
      below).

   to

      Allowed numbers of channels: 1...8, with the mapping specified
      according to Figure 3.  Vorbis channel order (see below).

   Similary, the first paragraph of Section 5.1.1.4 is changed from:

      Allowed numbers of channels: 1...255.  No defined channel meaning.

   to

      Allowed numbers of channels: 1...255, with the mapping specified
      according to Figure 3.  No defined channel meaning.

5.2.  Unknown Mapping Families

   Treatment of unknown mapping families is changed slightly.
   Section 5.1.1.4 of RFC 7845 states:

      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.

   This is changed to:

      The remaining channel mapping families (2...254) are reserved.  A
      demuxer implementation encountering a 'channel mapping family'
      value that it does not recognize SHOULD NOT attempt to decode the
      packets and SHOULD NOT use any information except for the first 19
      octets of the ID header packet (Fig. 2) and the comment header
      (Fig. 10).



There would need to be text added to the abstract and the metadata to
indicate that the document updates 7845.

In addition, I would like to propose making the ambisonics draft
register mapping families 240 to 254 for experimental (not yet adopted)
mappings. This is meant to avoid experiments causing collisions or
spreading around files encoded with non-final versions of a mapping.
This is the proposed section.


6.  Experimental Mapping Families

   To make development of new mapping families easier while reducing the
   risk of creating compatibility issues with non-final version of
   mapping families, mapping families 240 through 254 (inclusively) are
   now reserved for experiments and implementations of in-development
   families.  Implementers SHOULD attempt to use experimental family
   numbers that have not recently been used and SHOULD advertise what
   experimental numbers they use (e.g. for Internet-Drafts).

   The ambisonics mapping experiments that led to this document used
   experimental family 254 for family 2 and experimental family 253 for
   family 3.


It would also require adding the following line to the table in the IANA
Considerations section:

                  | 240-254 | This Document Section 6   |


With those changes applied, I see no remaining issues with the
ambisonics draft.

Cheers,

	Jean-Marc


On 10/30/2017 03:15 PM, [e-mail] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Internet Wideband Audio Codec WG of the IETF.
> 
>         Title           : Ambisonics in an Ogg Opus Container
>         Authors         : Jan Skoglund
>                           Michael Graczyk
> 	Filename        : draft-ietf-codec-ambisonics-04.txt
> 	Pages           : 8
> 	Date            : 2017-10-30
> 
> Abstract:
>    This document defines an extension to the Opus audio codec to
>    encapsulate coded ambisonics using the Ogg format.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-codec-ambisonics/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-codec-ambisonics-04
> https://datatracker.ietf.org/doc/html/draft-ietf-codec-ambisonics-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-codec-ambisonics-04
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>