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

Jean-Marc Valin <jmvalin@jmvalin.ca> Fri, 02 March 2018 00:55 UTC

Return-Path: <jmvalin@jmvalin.ca>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18692127419 for <codec@ietfa.amsl.com>; Thu, 1 Mar 2018 16:55:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jmvalin-ca.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S66sr7i1ZLg for <codec@ietfa.amsl.com>; Thu, 1 Mar 2018 16:55:28 -0800 (PST)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0639126C2F for <codec@ietf.org>; Thu, 1 Mar 2018 16:55:28 -0800 (PST)
Received: by mail-qt0-x232.google.com with SMTP id d26so10053579qtk.10 for <codec@ietf.org>; Thu, 01 Mar 2018 16:55:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jmvalin-ca.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=6WahbVRHYB997a5SNmjaPQOa7UcA/fLJ3KC7ks7D6Lw=; b=PS5BuU2ZUfGzXaYHC9la0/JPKFyCTLVky2/cpijBq0STLRvPug7N05UDjvR/XICcC+ RZphb3NtT7diBTOX0NqfSsEtGVy8C5Alw4ofovAy69wi8a8d5T+MX+foDBP5J9BJpnwR hHUrCTU5ONhFAyZV0AKv1bKN+5n0/Cwqnc6FarhBHBX1EaLrroSH1zQQ0MMML9p2iZA4 pbOll1jYY11YSy+SGnOPsI1lWyEg0I5Xboj4dKSmcBeYO/OGsNUJLxxbIlDmaqryKVHP cRwlp7Jii0Agi6j9CHJ5eknVZTS0OS3iIWPOH1KA15/m++dyt9q9hEG5aYoNh36f4PDW YU0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6WahbVRHYB997a5SNmjaPQOa7UcA/fLJ3KC7ks7D6Lw=; b=qhPsbZUMTWPSHz6U/iV762g41ujIqN44DNo/8zat4ifOwTwp8ccU/zgczdX1f1liDu zj31J3PIECouV8R+6pKtXtXV3+RCBufeC8Prr+SPrU9+AFaO5SGB7mPGVWEx3ckxKyQ8 Wba4NU1X/NreZhd8YbZMW3XFz+D65U4mYisZ8+FCJTzAA7vVanxonBXMUH2BnIWd8kkj VDcJ2wNQfVAlGDGwRd4Z62s+tUu9e9L6wnVttKalPdAUX1C6ltqY2wVGJhOsNMDqeaBj pD6QLUi5MatdR4jSIwmGZae+C6NqFTJDNuPPVFIrOyLB0444DmUFAM57BX3y6m7+uh9D XHRA==
X-Gm-Message-State: AElRT7GfW1WH78MALBRT9/BlL8WRxHuYAK6ajeTvCn3rEnIWEvr2OWqq Rq1aX5at9TZIU/r3eKz93rdvuRNF18I=
X-Google-Smtp-Source: AG47ELtmdIcU7xm1dNaH4GHBk8Lohg1XsmVsC8z8ZrZY/kHH3xKrAi0mZXVPdP5CnM54vsfNx7zPNg==
X-Received: by 10.200.54.39 with SMTP id m36mr6201864qtb.304.1519952127305; Thu, 01 Mar 2018 16:55:27 -0800 (PST)
Received: from obelix.jmvalin.ca (modemcable231.101-131-66.mc.videotron.ca. [66.131.101.231]) by smtp.gmail.com with ESMTPSA id i63sm3445224qke.86.2018.03.01.16.55.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 16:55:26 -0800 (PST)
To: Jan Skoglund <jks@google.com>, codec@ietf.org
References: <150939093944.7875.18287414379904492939@ietfa.amsl.com>
From: Jean-Marc Valin <jmvalin@jmvalin.ca>
Message-ID: <1df76ba7-8398-fef0-8390-2dc2b49fd7d2@jmvalin.ca>
Date: Thu, 1 Mar 2018 19:55:25 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <150939093944.7875.18287414379904492939@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/codec/d8k-2qhMFkHhFh97i8hhS8BQjpQ>
Subject: Re: [codec] I-D Action: draft-ietf-codec-ambisonics-04.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Mar 2018 00:55:31 -0000

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, internet-drafts@ietf.org 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
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>