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, [email protected] 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/codec
>
_______________________________________________
codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/codec
