
From iesg-secretary@ietf.org  Mon Jul  2 08:55:30 2012
Return-Path: <iesg-secretary@ietf.org>
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 55F7921F8630; Mon,  2 Jul 2012 08:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeXcbAWxCc+2; Mon,  2 Jul 2012 08:55:29 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045A321F8699; Mon,  2 Jul 2012 08:55:29 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.21p1
Message-ID: <20120702155529.29915.35651.idtracker@ietfa.amsl.com>
Date: Mon, 02 Jul 2012 08:55:29 -0700
Cc: codec mailing list <codec@ietf.org>, codec chair <codec-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [codec] Protocol Action: 'Definition of the Opus Audio Codec' to Proposed	Standard (draft-ietf-codec-opus-16.txt)
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 02 Jul 2012 15:55:30 -0000

The IESG has approved the following document:
- 'Definition of the Opus Audio Codec'
  (draft-ietf-codec-opus-16.txt) as Proposed Standard

This document is the product of the Internet Wideband Audio Codec Working
Group.

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-codec-opus/




Working Group Summary

The chairs believe there is good consensus behind the document,
particularly around the technology. There has not been any significant
disagreement on any of the technical aspects of the codec. However, the
working group has left the detailed specification work to the small
author team. There are several vocal participants who continue to
express dissatisfaction over the testing and codec validation associated
with the work. The WG chairs do not believe that there was consensus to
make these changes.

This document has been the subject of a number of IPR declarations.
See:

Microsoft: https://datatracker.ietf.org/ipr/1670/
Skype: https://datatracker.ietf.org/ipr/1602/
Broadcom: https://datatracker.ietf.org/ipr/1526/
Xiph: https://datatracker.ietf.org/ipr/1524/
Qualcomm: https://datatracker.ietf.org/ipr/1520/
Huawei: https://datatracker.ietf.org/ipr/1712/
Huawei: https://datatracker.ietf.org/ipr/1741/

The WG has had an opportunity to review these disclosures in Last Call
and has opted to proceed with document publication.


Document Quality

There is an existing implementation - the reference implementation which
is included in the appendix of the document and has been maintained by
the authors of the specification. One of the authors developed several
independent decoder implementations in order to help validate the
specification. There are no known alternative encoder
implementations. There are no significant reviewers worth noting beyond
the author team.

The codec has gone through a great degree of testing that demonstrates
its quality. Test results can be found at:
http://datatracker.ietf.org/doc/draft-ietf-codec-results/.


Personnel

Shepherd: Jonathan D. Rosenberg, Ph.D. <jdrosen@jdrosen.net>
Responsible AD: Robert Sparks <rjsparks@nostrum.com> 


RFC Editor Note:

Please replace the instances of rfcXXXX in this document with rfc number assigned for this draft.

Please work with the draft editors to replace rfcXXXX as it appears in the files in the appendix with the rfc number assigned for this draft.

Please work with the draft editors to ensure that the following is added (with XXXX replaced appropriately) to  the README file in the appendix: "These files were extracted from RFCXXXX. Please see that RFC for additional information."

From stpeter@stpeter.im  Mon Jul  2 09:22:30 2012
Return-Path: <stpeter@stpeter.im>
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 495AC21F86C9 for <codec@ietfa.amsl.com>; Mon,  2 Jul 2012 09:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.46
X-Spam-Level: 
X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32USnIM1ahK9 for <codec@ietfa.amsl.com>; Mon,  2 Jul 2012 09:22:29 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 23DB221F8747 for <codec@ietf.org>; Mon,  2 Jul 2012 09:22:29 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AE1194005A for <codec@ietf.org>; Mon,  2 Jul 2012 10:40:47 -0600 (MDT)
Message-ID: <4FF1CAC9.2050305@stpeter.im>
Date: Mon, 02 Jul 2012 10:22:33 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: codec mailing list <codec@ietf.org>
References: <20120702155529.29915.35651.idtracker@ietfa.amsl.com>
In-Reply-To: <20120702155529.29915.35651.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [codec] Protocol Action: 'Definition of the Opus Audio Codec' to Proposed	Standard (draft-ietf-codec-opus-16.txt)
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 02 Jul 2012 16:22:30 -0000

On 7/2/12 9:55 AM, The IESG wrote:
> The IESG has approved the following document:
> - 'Definition of the Opus Audio Codec'
>   (draft-ietf-codec-opus-16.txt) as Proposed Standard

Congratulations to the team on finishing this work! As a co-chair of
your second BoF, I'm happy to see this success. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





From fluffy@cisco.com  Tue Jul  3 10:01:25 2012
Return-Path: <fluffy@cisco.com>
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 82D8D11E8096 for <codec@ietfa.amsl.com>; Tue,  3 Jul 2012 10:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.454
X-Spam-Level: 
X-Spam-Status: No, score=-110.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZS8OC2C5A3C for <codec@ietfa.amsl.com>; Tue,  3 Jul 2012 10:01:24 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A48DC11E8098 for <codec@ietf.org>; Tue,  3 Jul 2012 10:01:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3123; q=dns/txt; s=iport; t=1341334893; x=1342544493; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TrZCM/ygk+nu6/HViUHyrMwicg7X8IUoy08eqCC/J2I=; b=U367boWxLuMy9YL28LXxj+mX3nOzs2SACULiObqAfIVPSrxE74y+s23X Lkx6WLEjyF6u00ktv6g/6Nsx/8djW1agz6lk/KSfvjmNtczi5X+MP+eF0 D3rmEJrUl8HXByKTtyDQsmjqAC0067gr3T4C0uZnMXG/rej1XpPQNHr32 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAJAj80+tJV2a/2dsb2JhbABEtwaBB4IYAQEBAwESASc/BQsCAQg2BQsyJQIEAQ0FIodkBQuaDKBHizeFOmADlTWBEo0LgWaCX4FYIw
X-IronPort-AV: E=Sophos;i="4.77,516,1336348800"; d="scan'208";a="98420905"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 03 Jul 2012 17:01:32 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q63H1WoR019569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 17:01:32 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.100]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Tue, 3 Jul 2012 12:01:32 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: codec mailing list <codec@ietf.org>, codec chair <codec-chairs@tools.ietf.org>
Thread-Topic: Protocol Action: 'Definition of the Opus Audio Codec' to Proposed	Standard (draft-ietf-codec-opus-16.txt)
Thread-Index: AQHNWGswzBflw6r/SkK3aCDDnR7txJcYHfYA
Date: Tue, 3 Jul 2012 17:01:31 +0000
Message-ID: <FB434EC3-9967-4BCD-B5C3-FA4D40851DD3@cisco.com>
References: <20120702155529.29915.35651.idtracker@ietfa.amsl.com>
In-Reply-To: <20120702155529.29915.35651.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.66.36]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.003
x-tm-as-result: No--43.800300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A9BE12B3F2AFF44FB3063B144553B070@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [codec] Protocol Action: 'Definition of the Opus Audio Codec' to Proposed	Standard (draft-ietf-codec-opus-16.txt)
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 03 Jul 2012 17:01:25 -0000

Many thanks to AD and the authors who put in a huge amount of effort to get=
 this through the IESG so quickly.=20


On Jul 2, 2012, at 8:55 , The IESG wrote:

> The IESG has approved the following document:
> - 'Definition of the Opus Audio Codec'
>  (draft-ietf-codec-opus-16.txt) as Proposed Standard
>=20
> This document is the product of the Internet Wideband Audio Codec Working
> Group.
>=20
> The IESG contact persons are Robert Sparks and Gonzalo Camarillo.
>=20
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-codec-opus/
>=20
>=20
>=20
>=20
> Working Group Summary
>=20
> The chairs believe there is good consensus behind the document,
> particularly around the technology. There has not been any significant
> disagreement on any of the technical aspects of the codec. However, the
> working group has left the detailed specification work to the small
> author team. There are several vocal participants who continue to
> express dissatisfaction over the testing and codec validation associated
> with the work. The WG chairs do not believe that there was consensus to
> make these changes.
>=20
> This document has been the subject of a number of IPR declarations.
> See:
>=20
> Microsoft: https://datatracker.ietf.org/ipr/1670/
> Skype: https://datatracker.ietf.org/ipr/1602/
> Broadcom: https://datatracker.ietf.org/ipr/1526/
> Xiph: https://datatracker.ietf.org/ipr/1524/
> Qualcomm: https://datatracker.ietf.org/ipr/1520/
> Huawei: https://datatracker.ietf.org/ipr/1712/
> Huawei: https://datatracker.ietf.org/ipr/1741/
>=20
> The WG has had an opportunity to review these disclosures in Last Call
> and has opted to proceed with document publication.
>=20
>=20
> Document Quality
>=20
> There is an existing implementation - the reference implementation which
> is included in the appendix of the document and has been maintained by
> the authors of the specification. One of the authors developed several
> independent decoder implementations in order to help validate the
> specification. There are no known alternative encoder
> implementations. There are no significant reviewers worth noting beyond
> the author team.
>=20
> The codec has gone through a great degree of testing that demonstrates
> its quality. Test results can be found at:
> http://datatracker.ietf.org/doc/draft-ietf-codec-results/.
>=20
>=20
> Personnel
>=20
> Shepherd: Jonathan D. Rosenberg, Ph.D. <jdrosen@jdrosen.net>
> Responsible AD: Robert Sparks <rjsparks@nostrum.com>=20
>=20
>=20
> RFC Editor Note:
>=20
> Please replace the instances of rfcXXXX in this document with rfc number =
assigned for this draft.
>=20
> Please work with the draft editors to replace rfcXXXX as it appears in th=
e files in the appendix with the rfc number assigned for this draft.
>=20
> Please work with the draft editors to ensure that the following is added =
(with XXXX replaced appropriately) to  the README file in the appendix: "Th=
ese files were extracted from RFCXXXX. Please see that RFC for additional i=
nformation."


From tterribe@xiph.org  Tue Jul  3 10:24:52 2012
Return-Path: <tterribe@xiph.org>
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 6664D11E80A4 for <codec@ietfa.amsl.com>; Tue,  3 Jul 2012 10:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCtjUTn7sEjz for <codec@ietfa.amsl.com>; Tue,  3 Jul 2012 10:24:51 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id C771511E8175 for <codec@ietf.org>; Tue,  3 Jul 2012 10:24:49 -0700 (PDT)
Received: from [10.250.6.54] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id D6030F2701;  Tue,  3 Jul 2012 10:24:57 -0700 (PDT)
Message-ID: <4FF32AC6.100@xiph.org>
Date: Tue, 03 Jul 2012 10:24:22 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1
MIME-Version: 1.0
To: codec mailing list <codec@ietf.org>
References: <20120702155529.29915.35651.idtracker@ietfa.amsl.com> <FB434EC3-9967-4BCD-B5C3-FA4D40851DD3@cisco.com>
In-Reply-To: <FB434EC3-9967-4BCD-B5C3-FA4D40851DD3@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: codec chair <codec-chairs@tools.ietf.org>
Subject: Re: [codec] Protocol Action: 'Definition of the Opus Audio Codec' to Proposed	Standard (draft-ietf-codec-opus-16.txt)
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 03 Jul 2012 17:24:52 -0000

Cullen Jennings (fluffy) wrote:
>
> Many thanks to AD and the authors who put in a huge amount of effort to get this through the IESG so quickly.

Yes, the thanks to our ADs are warmly echoed, and to our chairs, who 
provided invaluable assistance as well.

From jmvalin@mozilla.com  Tue Jul  3 10:39:07 2012
Return-Path: <jmvalin@mozilla.com>
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 7E57C11E808E for <codec@ietfa.amsl.com>; Tue,  3 Jul 2012 10:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yb6fzyrWDN4W for <codec@ietfa.amsl.com>; Tue,  3 Jul 2012 10:39:06 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAA811E8073 for <codec@ietf.org>; Tue,  3 Jul 2012 10:39:06 -0700 (PDT)
Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 2FEB8F2827;  Tue,  3 Jul 2012 10:39:13 -0700 (PDT)
Message-ID: <4FF32E40.4050404@mozilla.com>
Date: Tue, 03 Jul 2012 13:39:12 -0400
From: Jean-Marc Valin <jmvalin@mozilla.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: "Timothy B. Terriberry" <tterribe@xiph.org>
References: <20120702155529.29915.35651.idtracker@ietfa.amsl.com> <FB434EC3-9967-4BCD-B5C3-FA4D40851DD3@cisco.com> <4FF32AC6.100@xiph.org>
In-Reply-To: <4FF32AC6.100@xiph.org>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: codec mailing list <codec@ietf.org>, codec chair <codec-chairs@tools.ietf.org>
Subject: Re: [codec] Protocol Action: 'Definition of the Opus Audio Codec' to Proposed	Standard (draft-ietf-codec-opus-16.txt)
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 03 Jul 2012 17:39:07 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/03/2012 01:24 PM, Timothy B. Terriberry wrote:
> Yes, the thanks to our ADs are warmly echoed, and to our chairs,
> who provided invaluable assistance as well.


I'd like to second that. Many thanks to our ADs and chairs for their
support.

	Jean-Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP8y48AAoJEJ6/8sItn9q9K6kIAIey56TSzsXh5mjabj+fWO8H
/hrGfV+MnK1ytRDcEwlW445+0nOQ4yhyCpnyabseaXy+YaDKwzWggQqm4O1JzzLY
aOIQ7fh+cM7V3JgQdxy/525kAwd0+IuaznwV+49gWxjHKhQp8Md7Uap+bSi5rRAs
iV7lGkj+wwJi7JeJwJIM1B90syNqPpEzaQqmQQFRSRwmBOq7f2bj/+ULPwMCEFn6
ri+tvaS1d6moubnwkXIvHB9gcjDKjDJmgK/nEAIw8OX/YJB8Lys/HKZQbkXM3VXj
/JrsWrWw52BW8Q5APsXn6lGotFsGsqtsadBUpSdSSzXwKwCjuQUApl690uisg4o=
=pjgS
-----END PGP SIGNATURE-----

From tterribe@xiph.org  Thu Jul  5 08:12:39 2012
Return-Path: <tterribe@xiph.org>
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 53AC511E80B7 for <codec@ietfa.amsl.com>; Thu,  5 Jul 2012 08:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arkQFHHqhQQT for <codec@ietfa.amsl.com>; Thu,  5 Jul 2012 08:12:38 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5A711E80A5 for <codec@ietf.org>; Thu,  5 Jul 2012 08:12:38 -0700 (PDT)
Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 4C30BF22BA for <codec@ietf.org>; Thu,  5 Jul 2012 08:12:46 -0700 (PDT)
Message-ID: <4FF5AEED.8080300@xiph.org>
Date: Thu, 05 Jul 2012 08:12:45 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120620 SeaMonkey/2.10.1
MIME-Version: 1.0
To: codec@ietf.org
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com>
In-Reply-To: <20120705150704.14085.7364.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20120705150704.14085.7364.idtracker@ietfa.amsl.com>
Content-Type: multipart/mixed; boundary="------------050601020401040409020608"
Subject: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 05 Jul 2012 15:12:39 -0000

This is a multi-part message in MIME format.
--------------050601020401040409020608
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Now that the main codec draft has been approved by the IESG, I thought 
we should move on to standardizing a long-term storage file format. 
After some discussion with the ADs, we decided that the codec WG itself 
was the best place to do this, so we've written a draft for it (see 
forwarded message).

The text here isn't perfect (there are some outstanding issues even the 
authors want to resolve), but I thought I'd post it now to get some 
discussion rolling. For the actual format itself, we currently have 
deployed implementations in our own opus-tools package, Firefox, and 
gstreamer. I expect libav/FFmpeg and additional application support will 
be coming soon.

--------------050601020401040409020608
Content-Type: message/rfc822;
 name="New Version Notification for draft-terriberry-oggopus-00_txt.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="New Version Notification for draft-terriberry-oggopus-00_txt";
 filename*1=".eml"

Return-Path: <internet-drafts@ietf.org>
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on kizuka.merseine.nu
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=4.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.2
X-Original-To: derf@kizuka.merseine.nu
Delivered-To: derf@kizuka.merseine.nu
Received: from mail.xiph.org (westfish.xiph.osuosl.org [140.211.166.32])
	by kizuka.merseine.nu (Postfix) with ESMTP id 6F4E175C02F
	for <derf@kizuka.merseine.nu>; Thu,  5 Jul 2012 11:07:20 -0400 (EDT)
Received: by mail.xiph.org (Postfix)
	id 32EC51CDBB; Thu,  5 Jul 2012 08:07:20 -0700 (PDT)
Delivered-To: tterribe@xiph.org
Received: from fraxinus.osuosl.org (fraxinus.osuosl.org [140.211.166.137])
	by mail.xiph.org (Postfix) with ESMTP id 304B81CDB9
	for <tterribe@xiph.org>; Thu,  5 Jul 2012 08:07:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by fraxinus.osuosl.org (Postfix) with ESMTP id 24DEA1002E4
	for <tterribe@xiph.org>; Thu,  5 Jul 2012 15:07:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
	by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 5kUjPn1vK9Tb for <tterribe@xiph.org>;
	Thu,  5 Jul 2012 15:07:19 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail.ietf.org (mail.ietf.org [12.22.58.30])
	by fraxinus.osuosl.org (Postfix) with ESMTP id 3FFD31000BF
	for <tterribe@xiph.org>; Thu,  5 Jul 2012 15:07:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
	by ietfa.amsl.com (Postfix) with ESMTP id 1FF4F21F86CF;
	Thu,  5 Jul 2012 08:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([12.22.58.30])
	by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id JSxq3t8JjBu2; Thu,  5 Jul 2012 08:07:04 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1])
	by ietfa.amsl.com (Postfix) with ESMTP id 5EC8421F8792;
	Thu,  5 Jul 2012 08:07:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: tterribe@xiph.org
Cc: ron@debian.org
Subject: New Version Notification for draft-terriberry-oggopus-00.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 4.30
Message-ID: <20120705150704.14085.7364.idtracker@ietfa.amsl.com>
Date: Thu, 05 Jul 2012 08:07:04 -0700


A new version of I-D, draft-terriberry-oggopus-00.txt
has been successfully submitted by Timothy B. Terriberry and posted to the
IETF repository.

Filename:	 draft-terriberry-oggopus
Revision:	 00
Title:		 Ogg Encapsulation for the Opus Audio Codec
Creation date:	 2012-07-03
WG ID:		 Individual Submission
Number of pages: 27
URL:             http://www.ietf.org/internet-drafts/draft-terriberry-oggop=
us-00.txt
Status:          http://datatracker.ietf.org/doc/draft-terriberry-oggopus
Htmlized:        http://tools.ietf.org/html/draft-terriberry-oggopus-00


Abstract:
   This document defines the Ogg encapsulation for the Opus interactive
   speech and audio codec.  This allows data encoded in the Opus format
   to be stored in an Ogg logical bitstream.  This provides Opus with a
   long-term storage format supporting all of the essential features,
   including metadata, fast and accurate seeking, corruption detection,
   recapture after errors, low overhead, and the ability to multiplex
   Opus with other codecs (including video) with minimal buffering.  It
   also provides a live streamable format, capable of delivery over a
   reliable stream-oriented transport, without requiring all the data,
   or even the total length of the data, up-front, in a form that is
   identical to the on-disk storage format.

                                                                           =
       =



The IETF Secretariat


--------------050601020401040409020608--

From kpfleming@digium.com  Thu Jul  5 08:37:07 2012
Return-Path: <kpfleming@digium.com>
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 BFCEA21F8751 for <codec@ietfa.amsl.com>; Thu,  5 Jul 2012 08:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPXPiy4gsbZs for <codec@ietfa.amsl.com>; Thu,  5 Jul 2012 08:37:07 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 31E6C21F8735 for <codec@ietf.org>; Thu,  5 Jul 2012 08:37:07 -0700 (PDT)
Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from <kpfleming@digium.com>) id 1Smo7M-0006n7-G1 for codec@ietf.org; Thu, 05 Jul 2012 10:37:20 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 7E4A2D887D for <codec@ietf.org>; Thu,  5 Jul 2012 10:37:20 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyfO864KSeiF for <codec@ietf.org>; Thu,  5 Jul 2012 10:37:20 -0500 (CDT)
Received: from [10.24.19.142] (sligo.digium.internal [10.24.19.142]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 295DCD887C for <codec@ietf.org>; Thu,  5 Jul 2012 10:37:20 -0500 (CDT)
Message-ID: <4FF5B4AE.6020403@digium.com>
Date: Thu, 05 Jul 2012 10:37:18 -0500
From: "Kevin P. Fleming" <kpfleming@digium.com>
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: codec@ietf.org
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org>
In-Reply-To: <4FF5AEED.8080300@xiph.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 05 Jul 2012 15:37:07 -0000

On 07/05/2012 10:12 AM, Timothy B. Terriberry wrote:
> Now that the main codec draft has been approved by the IESG, I thought
> we should move on to standardizing a long-term storage file format.
> After some discussion with the ADs, we decided that the codec WG itself
> was the best place to do this, so we've written a draft for it (see
> forwarded message).

Will this require a charter update, to add this as a WG deliverable?

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org



From tterribe@xiph.org  Thu Jul  5 08:53:53 2012
Return-Path: <tterribe@xiph.org>
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 218E821F87BC for <codec@ietfa.amsl.com>; Thu,  5 Jul 2012 08:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RG3gkLenBaJ for <codec@ietfa.amsl.com>; Thu,  5 Jul 2012 08:53:52 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id B28C921F86A1 for <codec@ietf.org>; Thu,  5 Jul 2012 08:53:52 -0700 (PDT)
Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 38CDCF22C1 for <codec@ietf.org>; Thu,  5 Jul 2012 08:54:05 -0700 (PDT)
Message-ID: <4FF5B89C.2090802@xiph.org>
Date: Thu, 05 Jul 2012 08:54:04 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120620 SeaMonkey/2.10.1
MIME-Version: 1.0
To: codec@ietf.org
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FF5B4AE.6020403@digium.com>
In-Reply-To: <4FF5B4AE.6020403@digium.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 05 Jul 2012 15:53:53 -0000

Kevin P. Fleming wrote:
> Will this require a charter update, to add this as a WG deliverable?

I believe Robert said he would coordinate with the chairs to get a 
milestone in place. I don't know if we need to do anything more than that.



From giles@thaumas.net  Thu Jul  5 15:38:08 2012
Return-Path: <giles@thaumas.net>
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 58A4E11E80BD for <codec@ietfa.amsl.com>; Thu,  5 Jul 2012 15:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHd9MEpo0p6Q for <codec@ietfa.amsl.com>; Thu,  5 Jul 2012 15:38:03 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CAAF121F850F for <codec@ietf.org>; Thu,  5 Jul 2012 15:38:03 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so13796579pbc.31 for <codec@ietf.org>; Thu, 05 Jul 2012 15:38:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=YckOrvqpVlQp9/OEmJIN3yAmaYS8CoK7wnMQco9wwc8=; b=UnX/6Yp47BpdPhoCy/tek0H5bswR2VjX1tgg7ViaU/vj1Rt1DYi+mcvXFqgheKxMwO MmxPG/I0nPzgW/2naPLkboBbh9FsIGNWdJdTO+S3V6djZRp0QeQ2PiiRREjw+qvjkGG5 dIHaR4aVJZ0v44zccghU5658AFfdJq0ixrlWPDYVA6b1LkyH5R8jTVXy8lgK3hcTmcd0 KjC6TZMucwsTYrybVHSVcUIXjuEKAZFAuV7aS8UnaoRO923mMjMqaxmkW2oTtZasjuJt EA1y/11RopPrgMlFJxBrX56eYfs6SMEm5L+u1aNus4eHZITRPP7hTFZ8U9DSQo4Os3KD j3gA==
Received: by 10.68.138.169 with SMTP id qr9mr31460294pbb.27.1341527898468; Thu, 05 Jul 2012 15:38:18 -0700 (PDT)
Received: from Glaucomys.local ([64.213.70.194]) by mx.google.com with ESMTPS id oo6sm20537456pbc.22.2012.07.05.15.38.13 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 15:38:14 -0700 (PDT)
Message-ID: <4FF61755.5060205@thaumas.net>
Date: Thu, 05 Jul 2012 15:38:13 -0700
From: Ralph Giles <giles@thaumas.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: "Timothy B. Terriberry" <tterribe@xiph.org>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org>
In-Reply-To: <4FF5AEED.8080300@xiph.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQk3GzhhSSc1l0iwUmlXnFTM6PaEkOUzWUZe4jl/Q6dLUZsQScw8fwnujn6eZx3Hgp/MEz0r
Cc: codec@ietf.org
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 05 Jul 2012 22:38:08 -0000

On 12-07-05 8:12 AM, Timothy B. Terriberry wrote:

> Now that the main codec draft has been approved by the IESG, I thought
> we should move on to standardizing a long-term storage file format.

Thanks for writing this up! As Tim says, this draft is already
implemented in Firefox, with support in the HTML <audio> element, hidden
behind a preference switch. You can try it with Aurora (alpha) and
Nightly builds. See http://people.xiph.org/~giles/2012/opus/ for details.

You can create test files with an experimental suite of command-line
utilities in the opus-tools package. See
http://opus-codec.org/downloads/ for how to obtain a copy.

Some comments on the draft:

I think it would be better to swap sections 4 and 5. In particular, the
header layout figures are of general interest to writing file
identification and metadata extraction tools, as well as full
implementations, so having them near the beginnning of the draft makes
for easier reference. The granulepos section is quite long, and fits
better with the seeking and other considerations in section 6.

Section 4 says the granulepos values MUST increment by the number of
decodeable samples in the intervening packets, so that decoders can
calculate identical timestamps moving either forward or backward. I
think the draft should offer some guidance as to what a decoder MAY or
SHOULD do if there *is* a hole in the data, for example if part of the
file is corrupt.

Of course such a file is technically invalid, and the paragraph about
granuleposition offsets being smaller than decoded data still stand, but
in the case of corrupt Ogg pages, a decoder MAY wish to scan for the
next valid page and trust its timestamp or the average bitrate to
reconstruct what durations of packets were invalid.


In the description of the 'pre-skip' field in the granulepos discussion,
the draft says this may be used to exactly trim the start-time of stream
to perform lossless cropping. Then in the description of the field in
the ID header section, "When constructing cropped Ogg Opus streams, a
pre-skip of at least 3,840 samples (80 ms) is RECOMMENDED." Do I
understand correctly that, since pre-skip is subtracted from granulepos
to obtain timestamps, cropping this way requires rewriting the
granulepos field for every page in the logical stream, if
synchronization with other logical streams is to be maintained? I
suppose this is true of vorbis cropping too, but the need to preroll the
encoder makes the issue much more noticeable.


I don't understand the motivation for the R128_TRACK_GAIN header.
Applying this gain is optional, while there is already a manditory
output_gain in the ID header. It seems like there are two ways to
specify the same thing here.

>From informal discussions, I'm aware of the following arguments for
specifying this field. Perhaps someone more familiar with audio
normalization can respond if I've left someting out.

(a) It is important to describe the interaction between normalization
metadata, user-controlled volume settings, and the output_gain header
field to ensure that the later is correctly implemented as a manditory
element.

(b) While the manditory output_gain field can be used to fix recording
level problems in situations where re-encoding is not feasible, for
example files produced by a separate workflow, or a recording of a live
event, some producers and distributors want an *optional* way to mark
files to support the subset of applications which apply playback
normalization. This is effectively metadata for machine consumption, not
a change in the intended mix level, so a separate field is justified.

(c) It is useful to define a new tag based on the EBU R128 reference
level, rather than reusing the older 'replaygain' specification. The EBU
standard is technically superiour and gaining broader support in audio
production tools and safety regulations.

All of which seems noble enough, but only (a) is specific to Opus, and
addressing that issue doesn't require defining a new tag. Would it be
better to document this in another draft, or a revision of the
referenced vorbis-comment document?

Contrariwise, why does the draft tackle this one metadata issue without
addressing other infelicities with vorbis-comment tag schemes, such as
non-dublincore keys, machine-parsible date formats, proper attribution
of Creative Commons licensed work, and so on?


I was surprised that the R128_TRACK_GAIN field specifies its value is
the ascii representation of an integer, which is then interpreted as
a fixed point number. Surely including the radix would be more natural
for a human-readable field. The draft could still specify the same valid
range.

I also think it would be better to clamp the allowed range rather than
specifying that it MUST be valid. As a decoder author I wouldn't reject
a file because an optional metadata value is incorrect.


It might be useful to define a metadata scheme for naming the output
channels from Channel mapping 255. One use case for this mode is
multitrack recording for later offline mixing. Being able to propagate
channel labels between the input and output applications would be a nice
feature. For example:

CHANNEL_000=lead mic
CHANNEL_001=backing mic
CHANNEL_002=guitar
CHANNEL_003=bass
CHANNEL_010=piano left
CHANNEL_011=piano right

Cheers,
 -r

From tterribe@xiph.org  Thu Jul  5 16:55:23 2012
Return-Path: <tterribe@xiph.org>
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 6A62811E80F6 for <codec@ietfa.amsl.com>; Thu,  5 Jul 2012 16:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkPzZj8cbDQG for <codec@ietfa.amsl.com>; Thu,  5 Jul 2012 16:55:19 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 42DD411E807F for <codec@ietf.org>; Thu,  5 Jul 2012 16:55:19 -0700 (PDT)
Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 3F180F230E for <codec@ietf.org>; Thu,  5 Jul 2012 16:55:30 -0700 (PDT)
Message-ID: <4FF62970.5070704@xiph.org>
Date: Thu, 05 Jul 2012 16:55:28 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120620 SeaMonkey/2.10.1
MIME-Version: 1.0
To: codec@ietf.org
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FF61755.5060205@thaumas.net>
In-Reply-To: <4FF61755.5060205@thaumas.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 05 Jul 2012 23:55:23 -0000

Ralph Giles wrote:
> Thanks for writing this up! As Tim says, this draft is already

Well, I had a bunch of help. This has been percolating for a while at 
http://wiki.xiph.org/OggOpus

> I think it would be better to swap sections 4 and 5. In particular, the

Of course, this means the reader has none of the concepts needed to 
understand the pre-skip field when it is introduced (in particular, the 
48 kHz decoding rate assumption, the difference between granule position 
and PCM sample position, etc.). We could forward-reference it, but it 
will remain completely mysterious until they get to the granule position 
section.

Anyone else have opinions on this?

> calculate identical timestamps moving either forward or backward. I
> think the draft should offer some guidance as to what a decoder MAY or
> SHOULD do if there *is* a hole in the data, for example if part of the
> file is corrupt.

Trying to specify what to do in the case of a corrupt file always looked 
like a pretty deep rathole to me (years ago I started writing a tool to 
make a best-effort attempt at repairing all kinds of corruption and 
invalid constructs in Ogg files, and with all the restrictions on 
beginning and end of stream, headers, ordering, etc., it becomes 
exceedingly complicated extremely quickly. And then you add chaining.

> Of course such a file is technically invalid, and the paragraph about
> granuleposition offsets being smaller than decoded data still stand, but
> in the case of corrupt Ogg pages, a decoder MAY wish to scan for the
> next valid page and trust its timestamp or the average bitrate to
> reconstruct what durations of packets were invalid.

Most of these restrictions are in place to make things easier to 
implement, but "what's easy" depends a good deal on your application. 
Just to illustrate: scanning forward for the next valid page is fine and 
good, but what do you do with the data once you get there? If you're not 
synchronizing with other streams and playing out to a soundcard, maybe 
you just keep playing (after skipping a suitable amount of samples for 
preroll and maybe cross-fading to avoid clicks... though sounding 
obviously broken in this case might be an advantage). If you are 
synchronizing with other streams or writing to a file, maybe you run a 
PLC algorithm or inject silence (in the file writing case, because you 
don't know what use it will be put to afterwards, so maintaining sync 
might be important there, too). Try not to think too hard about what 
happens if you're using a frame-based PLC like the one in libopus, and 
the gap is not a multiple of a valid frame size in the most recent mode. 
The more important question is, what happens when the next timestamp is 
2**63 samples in the future?

And of course, most importantly, I don't want to give people the 
impression that, however weakly we suggest it in the spec, what's 
written there is what all implementations will do, and that therefore 
encoders will _rely_ on that behavior. Then it becomes impossible to use 
the decoder flexibility gained by declaring such constructs invalid.

> pre-skip of at least 3,840 samples (80 ms) is RECOMMENDED." Do I
> understand correctly that, since pre-skip is subtracted from granulepos
> to obtain timestamps, cropping this way requires rewriting the
> granulepos field for every page in the logical stream, if
> synchronization with other logical streams is to be maintained? I
> suppose this is true of vorbis cropping too, but the need to preroll the
> encoder makes the issue much more noticeable.

Yes, I believe this is correct. This is still an improvement, in that 
you can get sample-accurate cutting without rewriting the granulepos 
field in every page so long as you _aren't_ trying to synchronize with 
another stream. That's impossible in Vorbis.

> I don't understand the motivation for the R128_TRACK_GAIN header.
> Applying this gain is optional, while there is already a manditory
> output_gain in the ID header. It seems like there are two ways to
> specify the same thing here.

I don't think these are the same thing. As the draft says, the field in 
the header should normally correspond to what REPLAYGAIN_ALBUM_GAIN used 
to represent. R128_TRACK_GAIN corresponds to REPLAYGAIN_TRACK_GAIN. The 
former is a single normalization calculated across an entire collection 
of files (for some definition of collection), while the latter is 
calculated from the apparent loudness of just that individual file.

> (a) It is important to describe the interaction between normalization
> metadata, user-controlled volume settings, and the output_gain header
> field to ensure that the later is correctly implemented as a manditory
> element.
>
> [Snip]
>
> All of which seems noble enough, but only (a) is specific to Opus, and
> addressing that issue doesn't require defining a new tag. Would it be
> better to document this in another draft, or a revision of the
> referenced vorbis-comment document?

I think it might be reasonable to document R128 versions of the 
ReplayGain tags elsewhere, but I think point (a) is the reason that this 
tag was discussed explicitly in this draft, and not any of the other issues.

There is also the whole proscriptive (output gain) vs. descriptive 
(R128_TRACK_GAIN) argument, but I'll let Greg Maxwell argue that one.

> I was surprised that the R128_TRACK_GAIN field specifies its value is
> the ascii representation of an integer, which is then interpreted as
> a fixed point number. Surely including the radix would be more natural
> for a human-readable field. The draft could still specify the same valid
> range.

Care to offer some text to make this more clear?

> I also think it would be better to clamp the allowed range rather than
> specifying that it MUST be valid. As a decoder author I wouldn't reject
> a file because an optional metadata value is incorrect.

As a decoder author, you of course could do whatever you wanted if an 
encoder fails to follow a MUST restriction. For example, you might want 
to just not apply the tag at all, because it's likely the result of a 
bogus calculation in the encoder (and the extremes of the representable 
range are _very_ extreme).

> It might be useful to define a metadata scheme for naming the output
> channels from Channel mapping 255. One use case for this mode is

I don't have a strong opinion on this one, so I'll defer to others here.

Thanks for the feedback!

From hoene@uni-tuebingen.de  Thu Jul  5 23:57:19 2012
Return-Path: <hoene@uni-tuebingen.de>
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 7A4A021F86D1 for <codec@ietfa.amsl.com>; Thu,  5 Jul 2012 23:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4nBdy5QU+R3 for <codec@ietfa.amsl.com>; Thu,  5 Jul 2012 23:57:18 -0700 (PDT)
Received: from mx08.uni-tuebingen.de (mx08.uni-tuebingen.de [134.2.3.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBA621F86C7 for <codec@ietf.org>; Thu,  5 Jul 2012 23:57:18 -0700 (PDT)
Received: from ChristianHoene (u-173-c040.cs.uni-tuebingen.de [134.2.173.40]) (authenticated bits=0) by mx08.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id q666vRx8020178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jul 2012 08:57:28 +0200
From: "Hoene" <hoene@uni-tuebingen.de>
To: "'Jean-Marc Valin'" <jmvalin@mozilla.com>, "'Timothy B. Terriberry'" <tterribe@xiph.org>, "Koen Vos" <koen.vos@skype.net>
References: <20120702155529.29915.35651.idtracker@ietfa.amsl.com>	<FB434EC3-9967-4BCD-B5C3-FA4D40851DD3@cisco.com>	<4FF32AC6.100@xiph.org> <4FF32E40.4050404@mozilla.com>
In-Reply-To: <4FF32E40.4050404@mozilla.com>
Date: Fri, 6 Jul 2012 08:57:30 +0200
Message-ID: <000c01cd5b44$9efd5a40$dcf80ec0$@uni-tuebingen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJdIcxYhNZve7JqcIt1VZnc/lQmiwFtK/ZuAkVqY8YCUXpB3ZXKxrYQ
Content-Language: de
X-AntiVirus: NOT checked by Avira MailGate (version: 3.2.1.23; host: mx08)
Cc: 'codec mailing list' <codec@ietf.org>, 'codec chair' <codec-chairs@tools.ietf.org>
Subject: Re: [codec] Protocol Action: 'Definition of the Opus Audio Codec' to Proposed	Standard (draft-ietf-codec-opus-16.txt)
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 06 Jul 2012 06:57:19 -0000

Yes,

also my congratulations to codec developers, which did a ground-breaking =
and
industry changing work.

Bowing,

 Christian


--
Dr.-Ing. Christian Hoene, University of T=FCbingen,
Faculty of Science, Department of Computer Science,=20
Communication Networks, Sand 13, 72076 T=FCbingen, Germany,
Phone +49 7071 2970532, http://kn.inf.uni-tuebingen.de


-----Urspr=FCngliche Nachricht-----
Von: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] Im Auftrag =
von
Jean-Marc Valin
Gesendet: Dienstag, 3. Juli 2012 19:39
An: Timothy B. Terriberry
Cc: codec mailing list; codec chair
Betreff: Re: [codec] Protocol Action: 'Definition of the Opus Audio =
Codec'
to Proposed Standard (draft-ietf-codec-opus-16.txt)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/03/2012 01:24 PM, Timothy B. Terriberry wrote:
> Yes, the thanks to our ADs are warmly echoed, and to our chairs, who=20
> provided invaluable assistance as well.


I'd like to second that. Many thanks to our ADs and chairs for their
support.

	Jean-Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP8y48AAoJEJ6/8sItn9q9K6kIAIey56TSzsXh5mjabj+fWO8H
/hrGfV+MnK1ytRDcEwlW445+0nOQ4yhyCpnyabseaXy+YaDKwzWggQqm4O1JzzLY
aOIQ7fh+cM7V3JgQdxy/525kAwd0+IuaznwV+49gWxjHKhQp8Md7Uap+bSi5rRAs
iV7lGkj+wwJi7JeJwJIM1B90syNqPpEzaQqmQQFRSRwmBOq7f2bj/+ULPwMCEFn6
ri+tvaS1d6moubnwkXIvHB9gcjDKjDJmgK/nEAIw8OX/YJB8Lys/HKZQbkXM3VXj
/JrsWrWw52BW8Q5APsXn6lGotFsGsqtsadBUpSdSSzXwKwCjuQUApl690uisg4o=3D
=3DpjgS
-----END PGP SIGNATURE-----
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec


From jmvalin@mozilla.com  Mon Jul  9 18:27:49 2012
Return-Path: <jmvalin@mozilla.com>
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 4089021F8622 for <codec@ietfa.amsl.com>; Mon,  9 Jul 2012 18:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROxpT5fG50-X for <codec@ietfa.amsl.com>; Mon,  9 Jul 2012 18:27:48 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9871C21F861C for <codec@ietf.org>; Mon,  9 Jul 2012 18:27:48 -0700 (PDT)
Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 6543EF2632;  Mon,  9 Jul 2012 18:28:14 -0700 (PDT)
Message-ID: <4FFB851E.7040906@mozilla.com>
Date: Mon, 09 Jul 2012 21:27:58 -0400
From: Jean-Marc Valin <jmvalin@mozilla.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: "Timothy B. Terriberry" <tterribe@xiph.org>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org>
In-Reply-To: <4FF5AEED.8080300@xiph.org>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: codec@ietf.org
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 10 Jul 2012 01:27:49 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One thing we should explicitly mention in the draft is that a decoder
MUST NOT reject a file because the header is longer than expected.
This makes it possible to have a minor revision to the format that
adds a field to the header. As an exception, if the decoder knows the
exact length of header for the minor revision that the file uses, then
it MAY reject it. Any thoughts?

	Jean-Marc

On 07/05/2012 11:12 AM, Timothy B. Terriberry wrote:
> Now that the main codec draft has been approved by the IESG, I
> thought we should move on to standardizing a long-term storage file
> format. After some discussion with the ADs, we decided that the
> codec WG itself was the best place to do this, so we've written a
> draft for it (see forwarded message).
> 
> The text here isn't perfect (there are some outstanding issues even
> the authors want to resolve), but I thought I'd post it now to get
> some discussion rolling. For the actual format itself, we currently
> have deployed implementations in our own opus-tools package,
> Firefox, and gstreamer. I expect libav/FFmpeg and additional
> application support will be coming soon.
> 
> 
> _______________________________________________ codec mailing list 
> codec@ietf.org https://www.ietf.org/mailman/listinfo/codec
> 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP+4UeAAoJEJ6/8sItn9q9U20H/2tSynXwbg+qpPigsfV9BrYz
A59ML3GPAblMAZh56cwYvTjCP9DQF6A189d+zalT+MX2MQT+O5hhk4VZ8L8+KCVE
9x940W5f9KL5XYqf70hAqCwVf5OR5NJc1Zi0f14F2MpZGVOUmWModJnVt3xSQ9PC
0AO5dan/nW5PAFpFb0gKCYi2H9PNXDB1KCpxiQN7n37gRpzMKY1kDhgRDqHLBuH+
ZIU9ATJWj4ascDP7cTq6OWCy5TuNOgr7YdS/SAUjT/IgeWoBYUz11b3LjB+FnlFV
+wt20/thGNZwim4hr4ctptmBrFTIyiH94pdhr17rFDlcbZW+C08LBl8uwe+oILM=
=JZaT
-----END PGP SIGNATURE-----

From tterribe@xiph.org  Tue Jul 10 18:32:16 2012
Return-Path: <tterribe@xiph.org>
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 D9B5E11E80AA for <codec@ietfa.amsl.com>; Tue, 10 Jul 2012 18:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level: 
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NR4v4iUy-HoT for <codec@ietfa.amsl.com>; Tue, 10 Jul 2012 18:32:16 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7E41911E8079 for <codec@ietf.org>; Tue, 10 Jul 2012 18:32:16 -0700 (PDT)
Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 1D74CF293C for <codec@ietf.org>; Tue, 10 Jul 2012 18:32:45 -0700 (PDT)
Message-ID: <4FFCD7BC.6000906@xiph.org>
Date: Tue, 10 Jul 2012 18:32:44 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1
MIME-Version: 1.0
To: codec@ietf.org
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FFB851E.7040906@mozilla.com>
In-Reply-To: <4FFB851E.7040906@mozilla.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Jul 2012 01:32:17 -0000

Jean-Marc Valin wrote:
> One thing we should explicitly mention in the draft is that a decoder
> MUST NOT reject a file because the header is longer than expected.

Yeah, I hadn't touched on this because I wasn't sure what I thought yet.

> This makes it possible to have a minor revision to the format that
> adds a field to the header. As an exception, if the decoder knows the
> exact length of header for the minor revision that the file uses, then
> it MAY reject it. Any thoughts?

The test would actually have to be: exact version is known (0 or 1) AND 
(mapping family is 0 AND length is not 19, OR mapping family is > 0 and 
length is not 21+c). I don't see a reason to disallow rejection this 
case beyond the complexity required to explain how to allow rejection. 
What's the upside to allowing rejection?

From jmvalin@jmvalin.ca  Tue Jul 10 19:00:22 2012
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 8FCBA11E80DC for <codec@ietfa.amsl.com>; Tue, 10 Jul 2012 19:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.178
X-Spam-Level: 
X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.421,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZM4ENSHPiXy for <codec@ietfa.amsl.com>; Tue, 10 Jul 2012 19:00:22 -0700 (PDT)
Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by ietfa.amsl.com (Postfix) with ESMTP id 125ED11E8072 for <codec@ietf.org>; Tue, 10 Jul 2012 19:00:22 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from [192.168.1.14] ([96.21.20.94]) by VL-VM-MR002.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0M6Z001OY498N870@VL-VM-MR002.ip.videotron.ca> for codec@ietf.org; Tue, 10 Jul 2012 22:00:45 -0400 (EDT)
Message-id: <4FFCDE25.8030201@jmvalin.ca>
Date: Tue, 10 Jul 2012 22:00:05 -0400
From: Jean-Marc Valin <jmvalin@jmvalin.ca>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: "Timothy B. Terriberry" <tterribe@xiph.org>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FFB851E.7040906@mozilla.com> <4FFCD7BC.6000906@xiph.org>
In-reply-to: <4FFCD7BC.6000906@xiph.org>
X-Enigmail-Version: 1.4.2
Cc: codec@ietf.org
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Jul 2012 02:00:22 -0000

On 12-07-10 09:32 PM, Timothy B. Terriberry wrote:
> The test would actually have to be: exact version is known (0 or 1) AND
> (mapping family is 0 AND length is not 19, OR mapping family is > 0 and
> length is not 21+c). I don't see a reason to disallow rejection this
> case beyond the complexity required to explain how to allow rejection.
> What's the upside to allowing rejection?

Well, the alternative would be to say that implementations MUST NOT
reject (some) files that are known to be invalid. That seems a bit wrong
to me.

	Jean-Marc

From ron@debian.org  Tue Jul 10 21:48:52 2012
Return-Path: <ron@debian.org>
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 626D021F8552 for <codec@ietfa.amsl.com>; Tue, 10 Jul 2012 21:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ht+ZH8O3nx3M for <codec@ietfa.amsl.com>; Tue, 10 Jul 2012 21:48:51 -0700 (PDT)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0BF21F8541 for <codec@ietf.org>; Tue, 10 Jul 2012 21:48:50 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAH4F/U95LQwo/2dsb2JhbABFt36BCIIgAQEFOhwhAhALGC4UGA0kiB+9SYtAhW4DiEeFHodQAZAFgm+BSCM
Received: from ppp121-45-12-40.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.12.40]) by ipmail06.adl2.internode.on.net with ESMTP; 11 Jul 2012 14:19:05 +0930
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 3B7784F8F3; Wed, 11 Jul 2012 14:19:04 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oKdbnMWqYBRg; Wed, 11 Jul 2012 14:19:03 +0930 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 48FF94F8FE; Wed, 11 Jul 2012 14:19:03 +0930 (CST)
Date: Wed, 11 Jul 2012 14:19:03 +0930
From: Ron <ron@debian.org>
To: Jean-Marc Valin <jmvalin@mozilla.com>
Message-ID: <20120711044903.GK18009@audi.shelbyville.oz>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FFB851E.7040906@mozilla.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4FFB851E.7040906@mozilla.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: codec@ietf.org
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Jul 2012 04:48:52 -0000

On Mon, Jul 09, 2012 at 09:27:58PM -0400, Jean-Marc Valin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> One thing we should explicitly mention in the draft is that a decoder
> MUST NOT reject a file because the header is longer than expected.
> This makes it possible to have a minor revision to the format that
> adds a field to the header. As an exception, if the decoder knows the
> exact length of header for the minor revision that the file uses, then
> it MAY reject it. Any thoughts?

I'm a bit uncomfortable with the idea of this header being "arbitrarily"
extensible without any clearly defined mechanism for encapsulating further
'backward compatible' extensions that allows at least some measure of
basic validation to be performed.

If my code recognises version 1 headers, and I get a version 2 header
that is several MB in size, should I really just blindly accept that
Nothing Is Wrong?

It also doesn't really seem ideal to be appending extra fields after
the variable length mapping table data anyway.


Since any extra fields added with a minor version change must necessarily
be optional, with correct decoder behaviour still occurring if they are
ignored, I see two possible angles we could look at this from.  One is
that such things be added to the comment header - which already defines
a mechanism for arbitrary additional fields.  The other would be to
define some more formal extension mechanism, and perhaps put the channel
mapping table into it as well.

I'm not really sure what things you envisage may be added in a minor
version bump though, which are important enough to add a field to the
header, but incidental enough that decoders might ignore them with no
ill effects.  So it's not quite clear to me yet what the best way to
go for this would be either.

We already have one mechanism for extra data that is optional, do we
actually need to have a second one?

 Cheers,
 Ron



From ron@debian.org  Tue Jul 10 22:39:34 2012
Return-Path: <ron@debian.org>
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 AC04511E80BA for <codec@ietfa.amsl.com>; Tue, 10 Jul 2012 22:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSYqxnQtU3hR for <codec@ietfa.amsl.com>; Tue, 10 Jul 2012 22:39:30 -0700 (PDT)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 1566611E80BF for <codec@ietf.org>; Tue, 10 Jul 2012 22:39:29 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EACYR/U95LQwo/2dsb2JhbABFt36BCIIgAQEFOhwhEgsYLhQYDYhDvUOLQIJSgxwDiEeFHodQAYESiXWEfoJv
Received: from ppp121-45-12-40.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.12.40]) by ipmail06.adl2.internode.on.net with ESMTP; 11 Jul 2012 15:09:58 +0930
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id A0EDA4F8F3 for <codec@ietf.org>; Wed, 11 Jul 2012 15:09:56 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7VG4uHDNoybt for <codec@ietf.org>; Wed, 11 Jul 2012 15:09:51 +0930 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id E1F024F8FE; Wed, 11 Jul 2012 15:09:51 +0930 (CST)
Date: Wed, 11 Jul 2012 15:09:51 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20120711053951.GL18009@audi.shelbyville.oz>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FF61755.5060205@thaumas.net> <4FF62970.5070704@xiph.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4FF62970.5070704@xiph.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Jul 2012 05:39:34 -0000

On Thu, Jul 05, 2012 at 04:55:28PM -0700, Timothy B. Terriberry wrote:
> Ralph Giles wrote:
> >Thanks for writing this up! As Tim says, this draft is already
> 
> Well, I had a bunch of help. This has been percolating for a while
> at http://wiki.xiph.org/OggOpus
> 
> >I think it would be better to swap sections 4 and 5. In particular, the
> 
> Of course, this means the reader has none of the concepts needed to
> understand the pre-skip field when it is introduced (in particular,
> the 48 kHz decoding rate assumption, the difference between granule
> position and PCM sample position, etc.). We could forward-reference
> it, but it will remain completely mysterious until they get to the
> granule position section.

The order this is currently presented in seems fairly correct and
logical to me, in the sense that we have:

 1. - Introduction (refers the reader to the Ogg RFC as the basic
      first thing they need to know something about).

 3. & 4. - Expands on Ogg concepts that Ogg leaves to the codec
           mapping to define.

 5. - Defines the detail of things that are 'completely new' for
      this mapping.


I agree that section 4 is kind of long, and talks about more than
just granule position, but the order the information is presented
there seems roughly correct too for understanding as much as you
might from a first linear reading of the document.  It probably
could usefully be split into some subsections - with the pre-skip
definition in section 5 then providing a back reference to 4.1
about how it fits together with granule position etc.


Section 6 I suspect should be folded back into appropriate places
in the rest of the document and that section dropped entirely.
That was kind of a placeholder for various issues that came up in
discussion, but didn't otherwise already have a place in the wiki
where it obviously fit at the time.


The defined values for Channel Mapping Family might benefit from
being moved to that field's description in 5.1 rather than being
left until the latter part of 5.1.1 - or at least moved to the
top of 5.1.1 where it flows directly on from that, since we refer
to the special cases for family 0 in the descriptions of the
mapping table fields, without having introduced family 0 except
by way of saying "it's special".


I'm likewise interested in how this reads to other people too
though, since being clear to people who haven't read it before
is obviously the goal :)

 Cheers,
 Ron



From gmaxwell@juniper.net  Wed Jul 11 09:45:57 2012
Return-Path: <gmaxwell@juniper.net>
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 70DAF21F8622 for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 09:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHCm7T2ZsyhK for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 09:45:56 -0700 (PDT)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8FC21F861E for <codec@ietf.org>; Wed, 11 Jul 2012 09:45:56 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT/2t4hxKSb4ZQmnD0HHPgVuBjlx22w/C@postini.com; Wed, 11 Jul 2012 09:46:27 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 11 Jul 2012 09:45:17 -0700
From: Gregory Maxwell <gmaxwell@juniper.net>
To: "Timothy B. Terriberry" <tterribe@xiph.org>, "codec@ietf.org" <codec@ietf.org>
Date: Wed, 11 Jul 2012 09:45:17 -0700
Thread-Topic: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
Thread-Index: Ac1fBRT3wFz5vyjmRnqyiW4U1BVGaQAdkDwO
Message-ID: <BCB3F026FAC4C145A4A3330806FEFDA940BEEE25FE@EMBX01-HQ.jnpr.net>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FFB851E.7040906@mozilla.com>,<4FFCD7BC.6000906@xiph.org>
In-Reply-To: <4FFCD7BC.6000906@xiph.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [codec] Fwd: New Version Notification for	draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Jul 2012 16:45:57 -0000

Timothy B. Terriberry [tterribe@xiph.org]:
>> One thing we should explicitly mention in the draft is that a decoder
>> MUST NOT reject a file because the header is longer than expected.
>Yeah, I hadn't touched on this because I wasn't sure what I thought yet.
>> This makes it possible to have a minor revision to the format that
>> adds a field to the header. As an exception, if the decoder knows the
>> exact length of header for the minor revision that the file uses, then
>> it MAY reject it. Any thoughts?
>The test would actually have to be: exact version is known (0 or 1) AND
>(mapping family is 0 AND length is not 19, OR mapping family is > 0 and

I'd prefer to just say=97 generally=97 that they SHOULD rejected headers
which are completely defined by this specification which can not be
completely parsed.

And that they also MUST accept new minor numbers which have=20
additional data.  It's not like there is any complexity in this. You just
stop when you're done reading what you understand.

If an addition is made which can't be safely handled this way
then it should simply use a new major number.

Ron [ron@debian.org]:
> and I get a version 2 header that is several MB in size, should I
> really just blindly accept that Nothing Is Wrong

Well=97You'll blindly accept that nothing is wrong with
several MB of junk in the comments or in Opus padding.

But, see RFC 3533. The initial header packet must be on a single
page, so its limited by the container spec to 64K.

And because there is no explicit length field implementers won't
run into contradictions with the decoder or memory exhaustion
attacks where you malloc the signaled size which can be much
greater than the bits on the wire.

> It also doesn't really seem ideal to be appending extra fields after
> the variable length mapping table data anyway.

I'm not sure what you're thinking here. You just append them.

With this extensions must be monotonic=97 e.g. you couldn't
know about Y but not an extension added before it, but the
version numbers are also monotonic.  If there arose a need
for TLV style extensions in this header, that could be added
in some version.  But /currently/ I can only come up with
reasons why this would be a horrible idea.

A key point here is that there are not currently any anticipated
extensions.  But a byte there aligns the header, and having
it be explicit is superior to the header size sniffing I observed
implementers doing for version=3D0, before the pre-draft spec
defined how the version field should be used (when it was
just treated as a null terminator for "OpusHead")

I'm stridently opposed to implementing some deathstar
complexity binary-xml-extension-mechanism-whatever
when we don't have much of idea what it would be used for.

Experience in early implementations shows what we have in=20
the document now is simple enough that people will implement
and validate the whole thing, even parts they don't really
care about.

No one who's contributed to the draft so far is new at this,
and, apparently, based on the collective experience with
vorbis, speex, flac, theora, (and the many non Ogg formats
we've all worked with), it doesn't appear that there will
ever need to be anything added to the header.

But, Opus is new and hits some new applications and it
would seem to be foolish to leave no graceful way out
in the case of currently unanticipated needs.

If it would be helpful, let me suggest a kind of thing
that would be done with this:

Say we find that through some astonishing
boneheaded flaw, the Opus bitstream spec results
in terrible quality for some important signal. Experts
mash their heads together and come up with a
bitstream modification which can be decoded by the
original decoder with no worse quality and fixes the=20
decode when played with a new type decoder, but
only if it knows its playing a new-type bitstream. The
Opus RFC is updated.

But then an updated player needs to know that it
has a new-type file.  The header could just be
changed entirely but then the result wouldn't
play in old players.

So instead a v=3D2 header would just define some
field to signal this.  Because its a codec setup
header it would be available in the right layers
of applications to pass it on to the codec
implementation.

This is all terribly unlikely, not just because of all
the work that went into the opus spec but also
because no one would be eager to revise the bitstream,
but the availability of a simple compatible version
field prevents being cornered with ~zero complexity
in the likely case that it never happens.

> One is that such things be added to the comment header - which
> already defines a mechanism for arbitrary additional fields

Ugh.  The comment header is for stream metadata.
In theory it should all just be preserved if you transcode
the file between other formats.  It really shouldn't
contain anything codec specific. =20

My experience in Vorbis indicates to me that using
the comment packets for less-metadata-ish use has=20
had bad consequences:  It results in an application
layering violation (metadata doesn't get anywhere=20
near the codec itself), it gets moved between
files where it doesn't belong, and editing tools invalidate
it without removing it (because they can 'parse' but
not understand it).  You'd have applications that
care nothing about metadata being forced to parse
it just to get whatever extension you need.  And then
you also get lovely results like your terminal getting
broken because something shoved a bunch of binary
data into the comments and a simplistic application
just splat it out to your terminal.



From giles@thaumas.net  Wed Jul 11 10:29:53 2012
Return-Path: <giles@thaumas.net>
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 6BE5111E8120 for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 10:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nL1Y1JGQuKoF for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 10:29:52 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9E1611E8107 for <codec@ietf.org>; Wed, 11 Jul 2012 10:29:52 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so2465547pbc.31 for <codec@ietf.org>; Wed, 11 Jul 2012 10:30:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=thHwFxYSSTcuh/ajSoUxPCC6uRWrV6uSguxe+4m5ZjQ=; b=K7qBudNWvOWci7zWmBvilU/sAWc4AFhd5YML48/inNGgH5ryJwipJgXHzH08rqksrM HRt6lxugTKPqR/w++w029aoIOIHQj+NfBR4w3m6Azygrz0eo9LN7kCQ3MlH3173jzrjL mZduM76Lqogv6cPfce5FTiP7CjbHS8jwC+j0UVf2U9+Mr7C+NOwVP7tRtAp14Zn+K4Yf GOdDN1LmeGl/WudDUZAuvSzn4tqUDn4syAjR4Ym8kN4sdepEiDdDivtt76B3mPNwxFHw wELKgANxpbZuM52RxWVZazKtAr9GUEbIxfHK0Q34LXwkh35L0P5apbCb/1BwBcDyqkcG Oy8A==
Received: by 10.68.223.138 with SMTP id qu10mr80997311pbc.50.1342027823855; Wed, 11 Jul 2012 10:30:23 -0700 (PDT)
Received: from Glaucomys.local ([64.213.70.194]) by mx.google.com with ESMTPS id ql3sm2066205pbc.72.2012.07.11.10.30.21 (version=SSLv3 cipher=OTHER); Wed, 11 Jul 2012 10:30:22 -0700 (PDT)
Message-ID: <4FFDB82D.9000306@thaumas.net>
Date: Wed, 11 Jul 2012 10:30:21 -0700
From: Ralph Giles <giles@thaumas.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Gregory Maxwell <gmaxwell@juniper.net>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FFB851E.7040906@mozilla.com>, <4FFCD7BC.6000906@xiph.org> <BCB3F026FAC4C145A4A3330806FEFDA940BEEE25FE@EMBX01-HQ.jnpr.net>
In-Reply-To: <BCB3F026FAC4C145A4A3330806FEFDA940BEEE25FE@EMBX01-HQ.jnpr.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQn63YIRsz8uxYLTjpsL03oj6oF/m2JAQ9L4egOvmmtFurbSqS7STvJwoiP8CNDeFQ60RsuX
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Jul 2012 17:29:53 -0000

On 12-07-11 9:45 AM, Gregory Maxwell wrote:

> But, Opus is new and hits some new applications and it
> would seem to be foolish to leave no graceful way out
> in the case of currently unanticipated needs.

Another versioning example, although it doesn't address the length
issue: The draft defines three channel mapping familes which give
semantic meaning to the various output channels, and specifies that any
unrecognized channel mapping should be treated like mapping 255, which
is discrete multichannel with no specific channel meanings.

If an a new surround audio encoding became popular, like an ambisonic
expansion or a 24 speaker configuration for immersive environments, a
revision of this specification could define a new channel mapping family
for that encoding. But, and this is something I think the draft could
describe more clearly, encoders producing files with that family number
could reasonably increment the minor version nibble to indicate a
compatible change. This would signal to updated decoders how to
interpret the new channel mapping family value, while older decoders
would produce discrete output without confusion.

> No one who's contributed to the draft so far is new at this,
> and, apparently, based on the collective experience with
> vorbis, speex, flac, theora, (and the many non Ogg formats
> we've all worked with), it doesn't appear that there will
> ever need to be anything added to the header.

This is my expectation as well. I think it's still valuable to specify
decoders MUST ignore extra data at the end of the header packets so
later drafts can take advange of the extension flag if it is needed.

 -r

From tterribe@xiph.org  Wed Jul 11 10:37:45 2012
Return-Path: <tterribe@xiph.org>
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 47FC411E8110 for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 10:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82o-VDSUQ3yM for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 10:37:44 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED9211E8107 for <codec@ietf.org>; Wed, 11 Jul 2012 10:37:44 -0700 (PDT)
Received: from [10.250.6.54] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 71C0BF21F6 for <codec@ietf.org>; Wed, 11 Jul 2012 10:38:13 -0700 (PDT)
Message-ID: <4FFDBA05.4040004@xiph.org>
Date: Wed, 11 Jul 2012 10:38:13 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1
MIME-Version: 1.0
To: "codec@ietf.org" <codec@ietf.org>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FFB851E.7040906@mozilla.com>, <4FFCD7BC.6000906@xiph.org> <BCB3F026FAC4C145A4A3330806FEFDA940BEEE25FE@EMBX01-HQ.jnpr.net>
In-Reply-To: <BCB3F026FAC4C145A4A3330806FEFDA940BEEE25FE@EMBX01-HQ.jnpr.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Jul 2012 17:37:45 -0000

Gregory Maxwell wrote:
> I'd prefer to just say— generally— that they SHOULD rejected headers
> which are completely defined by this specification which can not be
> completely parsed.
>
> And that they also MUST accept new minor numbers which have
> additional data.  It's not like there is any complexity in this. You just
> stop when you're done reading what you understand.

This sounds pretty good to me.

From tterribe@xiph.org  Wed Jul 11 11:18:54 2012
Return-Path: <tterribe@xiph.org>
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 7A4E621F85EA for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 11:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.477
X-Spam-Level: 
X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8xoLKs88o10 for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 11:18:54 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 057B021F85B4 for <codec@ietf.org>; Wed, 11 Jul 2012 11:18:53 -0700 (PDT)
Received: from [10.250.6.54] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 7C046F21F6 for <codec@ietf.org>; Wed, 11 Jul 2012 11:19:23 -0700 (PDT)
Message-ID: <4FFDC3AB.8020900@xiph.org>
Date: Wed, 11 Jul 2012 11:19:23 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1
MIME-Version: 1.0
To: codec@ietf.org
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FF61755.5060205@thaumas.net> <4FF62970.5070704@xiph.org> <20120711053951.GL18009@audi.shelbyville.oz>
In-Reply-To: <20120711053951.GL18009@audi.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Jul 2012 18:18:54 -0000

Ron wrote:
> might from a first linear reading of the document.  It probably
> could usefully be split into some subsections - with the pre-skip
> definition in section 5 then providing a back reference to 4.1
> about how it fits together with granule position etc.

Yes, this is a pretty good idea. Feel free to offer some suggestions for 
section titles, etc.

> Section 6 I suspect should be folded back into appropriate places
> in the rest of the document and that section dropped entirely.
> That was kind of a placeholder for various issues that came up in
> discussion, but didn't otherwise already have a place in the wiki
> where it obviously fit at the time.

The first paragraph probably belongs in Section 4 somewhere, but I 
worried that introducing it too early would confuse the issue with 
pre-skip, when the concepts are totally independent. I should probably 
also add a sentence about what to do if the seek point is before the 
first 80 ms.

The rest (discussing packet size limitations) arguably belongs in 
Section 3, but it really is a complete aside. Having it off the critical 
path for "things you need to understand to implement this specification" 
is an advantage, I think.

I may move the first paragraph out and re-title Section 6 to reflect the 
fact that it just discusses packet size limitations.

> The defined values for Channel Mapping Family might benefit from
> being moved to that field's description in 5.1 rather than being
> left until the latter part of 5.1.1 - or at least moved to the
> top of 5.1.1 where it flows directly on from that, since we refer
> to the special cases for family 0 in the descriptions of the
> mapping table fields, without having introduced family 0 except
> by way of saying "it's special".

I think I originally pushed it back because I wanted a clear definition 
of "decoded channels" vs. "output channels" in place before I tried to 
describe the restrictions associated with each mapping family. Upon 
re-reading, I agree this order creates some other problems, though. 
However, I do think it's beneficial to keep it in its own subsection.

From ron@debian.org  Wed Jul 11 17:39:57 2012
Return-Path: <ron@debian.org>
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 0DD2B11E8176 for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 17:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qosv2efsMz1 for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 17:39:56 -0700 (PDT)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id C2E6C11E816D for <codec@ietf.org>; Wed, 11 Jul 2012 17:39:55 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAIoc/k95LQwo/2dsb2JhbABFt3mBCIIgAQEEATocIRILGC4UGA2IPgW+C4tAhW4DiEmFHodSAZAGgm8
Received: from ppp121-45-12-40.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.12.40]) by ipmail06.adl2.internode.on.net with ESMTP; 12 Jul 2012 10:10:25 +0930
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 8CECE4F8F3 for <codec@ietf.org>; Thu, 12 Jul 2012 10:04:39 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fuK2VavjGANr for <codec@ietf.org>; Thu, 12 Jul 2012 10:04:38 +0930 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id A22064F8FE; Thu, 12 Jul 2012 10:04:38 +0930 (CST)
Date: Thu, 12 Jul 2012 10:04:38 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20120712003438.GR18009@audi.shelbyville.oz>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FFB851E.7040906@mozilla.com> <4FFCD7BC.6000906@xiph.org> <BCB3F026FAC4C145A4A3330806FEFDA940BEEE25FE@EMBX01-HQ.jnpr.net> <4FFDB82D.9000306@thaumas.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4FFDB82D.9000306@thaumas.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 12 Jul 2012 00:39:57 -0000

On Wed, Jul 11, 2012 at 10:30:21AM -0700, Ralph Giles wrote:
> On 12-07-11 9:45 AM, Gregory Maxwell wrote:
> 
> > But, Opus is new and hits some new applications and it
> > would seem to be foolish to leave no graceful way out
> > in the case of currently unanticipated needs.
> 
> Another versioning example, although it doesn't address the length
> issue: The draft defines three channel mapping familes which give
> semantic meaning to the various output channels, and specifies that any
> unrecognized channel mapping should be treated like mapping 255, which
> is discrete multichannel with no specific channel meanings.
> 
> If an a new surround audio encoding became popular, like an ambisonic
> expansion or a 24 speaker configuration for immersive environments, a
> revision of this specification could define a new channel mapping family
> for that encoding. But, and this is something I think the draft could
> describe more clearly, encoders producing files with that family number
> could reasonably increment the minor version nibble to indicate a
> compatible change. This would signal to updated decoders how to
> interpret the new channel mapping family value, while older decoders
> would produce discrete output without confusion.

This was the only concrete thing that really occurred to me which we
_might_ plausibly get value out of the "minor version" with -- however
the draft explicitly says "General-purpose players SHOULD NOT attempt
to play these (family 255) streams" -- which kind of conflicts with
the notion that minor version increments are backward compatible and
existing decoders SHOULD accept them and be able to play them.

If we add a new mapping family, then we sort of have created a stream
that is not really backward compatible with previously existing code.

The minor version in this case at best might act as a sort of crude
checksum, that says family 7 really is supposed to be defined, rather
than being an encoding error - but if we use it like that, we're going
to run out of minor versions long before we run out of new mapping
families that we might add ...  and what will we do then?

One alternative is we could just revise the spec to define new families
without bumping the minor version.  Since they'd basically act as you
suggest for things that don't recognise them anyway in that case.

> > No one who's contributed to the draft so far is new at this,
> > and, apparently, based on the collective experience with
> > vorbis, speex, flac, theora, (and the many non Ogg formats
> > we've all worked with), it doesn't appear that there will
> > ever need to be anything added to the header.
> 
> This is my expectation as well. I think it's still valuable to specify
> decoders MUST ignore extra data at the end of the header packets so
> later drafts can take advange of the extension flag if it is needed.

I likewise don't actually expect we will ever find a reason to bump
the minor version (though defining new mapping families seems like a
real possibility), which is mostly why I wonder if this is really the
best mechanism for enabling extensions that we cannot yet imagine,
and mostly doubt we'll need ...

 Ron



From tterribe@xiph.org  Wed Jul 11 17:52:08 2012
Return-Path: <tterribe@xiph.org>
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 E5FD621F84EE for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 17:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.527
X-Spam-Level: 
X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGHcyTIj542t for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 17:52:08 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5BF21F84EC for <codec@ietf.org>; Wed, 11 Jul 2012 17:52:07 -0700 (PDT)
Received: from [10.250.6.54] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 7EEC1F21F6 for <codec@ietf.org>; Wed, 11 Jul 2012 17:52:39 -0700 (PDT)
Message-ID: <4FFE1FD7.7050908@xiph.org>
Date: Wed, 11 Jul 2012 17:52:39 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1
MIME-Version: 1.0
To: codec@ietf.org
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FFB851E.7040906@mozilla.com> <4FFCD7BC.6000906@xiph.org> <BCB3F026FAC4C145A4A3330806FEFDA940BEEE25FE@EMBX01-HQ.jnpr.net> <4FFDB82D.9000306@thaumas.net> <20120712003438.GR18009@audi.shelbyville.oz>
In-Reply-To: <20120712003438.GR18009@audi.shelbyville.oz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 12 Jul 2012 00:52:09 -0000

Ron wrote:
> One alternative is we could just revise the spec to define new families
> without bumping the minor version.  Since they'd basically act as you
> suggest for things that don't recognise them anyway in that case.

I think this is basically what we'd want to, _provided_ that the new 
families did not need more information added to the header. I can easily 
see a family that required specifying speaker/capture positions (e.g., 
something CLUE-like).

But I'm not in a rush to go down that path. I just want to leave the 
door open should we need it. Let's keep things simple for now.

From gmaxwell@juniper.net  Wed Jul 11 18:18:03 2012
Return-Path: <gmaxwell@juniper.net>
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 9AED811E816D for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 18:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Zrj-tOabhF1 for <codec@ietfa.amsl.com>; Wed, 11 Jul 2012 18:18:03 -0700 (PDT)
Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id E0C3311E8159 for <codec@ietf.org>; Wed, 11 Jul 2012 18:18:02 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT/4l5okdDOiBrA7p47fovchcyvTNGnrh@postini.com; Wed, 11 Jul 2012 18:18:35 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 11 Jul 2012 18:16:41 -0700
From: Gregory Maxwell <gmaxwell@juniper.net>
To: Ron <ron@debian.org>, "codec@ietf.org" <codec@ietf.org>
Date: Wed, 11 Jul 2012 18:16:41 -0700
Thread-Topic: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
Thread-Index: Ac1fxvE9z41B5haNQBuU5By+cw9gAgABFRA5
Message-ID: <BCB3F026FAC4C145A4A3330806FEFDA940BEEE2603@EMBX01-HQ.jnpr.net>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FFB851E.7040906@mozilla.com> <4FFCD7BC.6000906@xiph.org> <BCB3F026FAC4C145A4A3330806FEFDA940BEEE25FE@EMBX01-HQ.jnpr.net> <4FFDB82D.9000306@thaumas.net>, <20120712003438.GR18009@audi.shelbyville.oz>
In-Reply-To: <20120712003438.GR18009@audi.shelbyville.oz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 12 Jul 2012 01:18:03 -0000

Ron [ron@debian.org] wrote:
> If we add a new mapping family, then we sort of have created a stream
> that is not really backward compatible with previously existing code.

Thats unavoidable.  Say I tell you now that mapping 3 is B-format.
None of your existing code would know that. It wouldn't be able to
play it.  Not playing it is the right thing to do. rather than sending
W out the left speaker and Z out the right and what have you.

Other than perhaps adding more channels in the mapping 1
sequence (e.g. for counts > 8) I would not generally expect
other new mappings to actually be usefully compatible without
actually knowing what they were.

> One alternative is we could just revise the spec to define new families
> without bumping the minor version.  Since they'd basically act as you
>suggest for things that don't recognise them anyway in that case.
[snip]
> I likewise don't actually expect we will ever find a reason to bump
> the minor version=20

Nah, thats the reason they're reserved.  You can think of it is though
they are all _already_ defined, but the devilish fog of causality
prevents you from seeing the definitions as of yet, and thus
you can't implement support for them.


From ron@debian.org  Sun Jul 15 05:46:42 2012
Return-Path: <ron@debian.org>
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 A5CDD21F85B4 for <codec@ietfa.amsl.com>; Sun, 15 Jul 2012 05:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzv-xfEbiBIY for <codec@ietfa.amsl.com>; Sun, 15 Jul 2012 05:46:42 -0700 (PDT)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id D371721F85AC for <codec@ietf.org>; Sun, 15 Jul 2012 05:46:41 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAHK7AlB20o5H/2dsb2JhbABFuCmBCIIgAQEEATocIQcLCxguFBgNiD4FugCLQIJmgxwDiEmFHodTAZAGgm8
Received: from ppp118-210-142-71.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([118.210.142.71]) by ipmail05.adl6.internode.on.net with ESMTP; 15 Jul 2012 22:17:20 +0930
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 28EFF4F8F3 for <codec@ietf.org>; Sun, 15 Jul 2012 22:17:19 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KjsOISksdOVu for <codec@ietf.org>; Sun, 15 Jul 2012 22:17:18 +0930 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 6B3594F8FE; Sun, 15 Jul 2012 22:17:18 +0930 (CST)
Date: Sun, 15 Jul 2012 22:17:18 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20120715124718.GY18009@audi.shelbyville.oz>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FF61755.5060205@thaumas.net> <4FF62970.5070704@xiph.org> <20120711053951.GL18009@audi.shelbyville.oz> <4FFDC3AB.8020900@xiph.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4FFDC3AB.8020900@xiph.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sun, 15 Jul 2012 12:46:42 -0000

On Wed, Jul 11, 2012 at 11:19:23AM -0700, Timothy B. Terriberry wrote:
> Ron wrote:
> >might from a first linear reading of the document.  It probably
> >could usefully be split into some subsections - with the pre-skip
> >definition in section 5 then providing a back reference to 4.1
> >about how it fits together with granule position etc.
> 
> Yes, this is a pretty good idea. Feel free to offer some suggestions
> for section titles, etc.

As currently written, the logical sub-section breaks to me look
something like:


 4.1 - Pre-skip
   There is some amount of latency introduced ...


 4.2 - PCM sample position
   The PCM sample position is ...


The paragraph beginning "Vorbis streams use a granule position", should
perhaps become a footnote, or possibly move up into section 4.1.  That
seems like useful information for people who already understand the
Vorbis Ogg mapping, but may just add confusion to people who first look
at this in the context of Opus.  As part of the rationale for why we
have preskip there is useful information in it that should be included
somewhere here though.


 4.3 - EOS trimming
   The page with the 'end of stream' flag ...


 4.4 - Streams beginning after time 0
   The granule position of the first audio data page with a completed
   packet MAY be larger ...

   [Someone might have a better section title for this ...]


> >Section 6 I suspect should be folded back into appropriate places
> >in the rest of the document and that section dropped entirely.
> >That was kind of a placeholder for various issues that came up in
> >discussion, but didn't otherwise already have a place in the wiki
> >where it obviously fit at the time.
> 
> The first paragraph probably belongs in Section 4 somewhere, but I
> worried that introducing it too early would confuse the issue with
> pre-skip, when the concepts are totally independent. I should
> probably also add a sentence about what to do if the seek point is
> before the first 80 ms.

We could maybe add a: 4.5 - Seeking within a stream
and elaborate a little on general best practices for that there too.
Since this seems to be something people commonly do badly on their
first attempt, despite good methods having been detailed elsewhere.
Some references to those might be enough.

> The rest (discussing packet size limitations) arguably belongs in
> Section 3, but it really is a complete aside. Having it off the
> critical path for "things you need to understand to implement this
> specification" is an advantage, I think.
> 
> I may move the first paragraph out and re-title Section 6 to reflect
> the fact that it just discusses packet size limitations.

Yes, that makes good sense to me.  I agree that once the first paragraph
is taken out of section 6, the rest does fairly coherently talk about
just packet size issues, and is distinct enough from everything else to
put in its own specific section as a final discussion point.

 Cheers,
 Ron



From ron@debian.org  Sun Jul 15 07:09:51 2012
Return-Path: <ron@debian.org>
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 3701621F84E7 for <codec@ietfa.amsl.com>; Sun, 15 Jul 2012 07:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL21zGISXOkk for <codec@ietfa.amsl.com>; Sun, 15 Jul 2012 07:09:46 -0700 (PDT)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id CDEA721F84E1 for <codec@ietf.org>; Sun, 15 Jul 2012 07:09:45 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EADjOAlB20o5H/2dsb2JhbABFhWmyQIEIgiABAQQBIw8BIyEHCwsYAgImAgIUGA03iAcFqDaRVoEgiiAUglKCCoESA4hJhR6HUwGQBoJvgUY
Received: from ppp118-210-142-71.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([118.210.142.71]) by ipmail05.adl6.internode.on.net with ESMTP; 15 Jul 2012 23:40:26 +0930
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id DF8154F8F3 for <codec@ietf.org>; Sun, 15 Jul 2012 23:32:40 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FJjhzlaBDKpV for <codec@ietf.org>; Sun, 15 Jul 2012 23:32:40 +0930 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 18F6E4F8FE; Sun, 15 Jul 2012 23:32:40 +0930 (CST)
Date: Sun, 15 Jul 2012 23:32:40 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20120715140124.GZ18009@audi.shelbyville.oz>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FFB851E.7040906@mozilla.com> <4FFCD7BC.6000906@xiph.org> <BCB3F026FAC4C145A4A3330806FEFDA940BEEE25FE@EMBX01-HQ.jnpr.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BCB3F026FAC4C145A4A3330806FEFDA940BEEE25FE@EMBX01-HQ.jnpr.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [codec] Fwd: New Version Notification for	draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sun, 15 Jul 2012 14:09:51 -0000

On Wed, Jul 11, 2012 at 09:45:17AM -0700, Gregory Maxwell wrote:
> Ron [ron@debian.org]:
> > and I get a version 2 header that is several MB in size, should I
> > really just blindly accept that Nothing Is Wrong
> 
> Wellâ€”You'll blindly accept that nothing is wrong with
> several MB of junk in the comments or in Opus padding.

There is a chance that _might_ not actually be wrong though, for instance
there could be base64 encoded cover art in comments etc.  while a MB of
junk in the OpusHead packet would 'clearly' always be wrong.

What wasn't clear is how much more accurately I could bound that given
the "MUST accept extra header data" condition that was proposed.

> But, see RFC 3533. The initial header packet must be on a single
> page, so its limited by the container spec to 64K.

That RFC is actually a little handwavy on this detail, and mostly delegates
to the codec mapping to define what is a valid BOS packet.  It does say:

 So, a physical bitstream begins with the bos pages of all logical
 bitstreams containing one initial header packet per page, followed by
 the subsidiary header packets of all streams, followed by pages
 containing data packets.

But that's not a MUST, and hinges on 'containing' meaning the packet
completes on that page and is not continued to a subsequent page.

I agree that is the only sane interpretation for the current set of
mappings, where the BOS packet is quite small, and that it probably
was the original intention, but the stronger requirement is:

 The format of the bos page is dependent on the codec and therefore
 MUST be given in the encapsulation specification of that logical
 bitstream type.


So if we are going to add the condition:
"MUST accept new minor numbers which have additional data."

Then amending section 3 which says the BOS packet "MUST be placed alone"
to also explicitly explain that it "MUST complete on that page", at least
places a clear constraint on the amount of additional data that may ever
appear in some later version - and gives us a chance that application
authors won't just make up their own arbitrary 'sanity check' bounds
(or accept dozens of pages of carefully crafted rubbish) - which is the
main problem I worried we could be newly introducing here.

 Cheers,
 Ron



From giles@thaumas.net  Mon Jul 16 11:38:50 2012
Return-Path: <giles@thaumas.net>
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 5AD5121F880F for <codec@ietfa.amsl.com>; Mon, 16 Jul 2012 11:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.956
X-Spam-Level: 
X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jn8KqsxlZh23 for <codec@ietfa.amsl.com>; Mon, 16 Jul 2012 11:38:47 -0700 (PDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAED21F8814 for <codec@ietf.org>; Mon, 16 Jul 2012 11:38:42 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so5863755ggn.31 for <codec@ietf.org>; Mon, 16 Jul 2012 11:39:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=QFfA7X/WT/5I5/yOoqecMKMGrsXZfSEAjzeDEFXhCRg=; b=cLTHVOME7NCizuRPxxztUh7uxhwfrY96TK27ujxB+zTg0zoJZ/hRaR138D/06RDmQt HgHu9Zlf4Zjre1jhjtmiHFTE+FqqR5my4zc7xUimjjR9UFF1hGrmwj8QANbtDIHSZfsF Abe55W9KkwyrkHzOA0UTHKbjeaVxXZHND1NTmd1ByRr1tz2nQT9ilrMFCp6NjaEkNvPG f4BZMjkM1BHu34CSHAK+i571NLEdvwV8of/39qGkti/ND4MFT1cNsS2RSosO7v5xtMgg Dv/Ie7NuA05LBHhio1jFvN0AtAfExxTbHtPxqhA6Yc0ezA4TbvQN+Zs5QQ5mjtZdoo4p 6ClA==
Received: by 10.50.42.165 with SMTP id p5mr6013109igl.68.1342463967525; Mon, 16 Jul 2012 11:39:27 -0700 (PDT)
Received: from Glaucomys.local ([66.207.208.98]) by mx.google.com with ESMTPS id q1sm19984490igj.15.2012.07.16.11.39.26 (version=SSLv3 cipher=OTHER); Mon, 16 Jul 2012 11:39:26 -0700 (PDT)
Message-ID: <50045FDD.70508@thaumas.net>
Date: Mon, 16 Jul 2012 14:39:25 -0400
From: Ralph Giles <giles@thaumas.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: "Timothy B. Terriberry" <tterribe@xiph.org>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FF61755.5060205@thaumas.net> <4FF62970.5070704@xiph.org>
In-Reply-To: <4FF62970.5070704@xiph.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQk5l3XHG3Vb/LntuhL820EynjHSz8dbFugRMeqSk5Vl+O6U6CjhZGreZfef5bQjMoOrYfuk
Cc: codec@ietf.org
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 16 Jul 2012 18:38:50 -0000

On 12-07-05 4:55 PM, Timothy B. Terriberry wrote:

> Trying to specify what to do in the case of a corrupt file always looked
> like a pretty deep rathole to me 

Fair enough.

> Most of these restrictions are in place to make things easier to
> implement, but "what's easy" depends a good deal on your application.

True, but you go on to list exactly the sort of options I was thinking
it would be helpful to document. What options and tradeoffs are
available isn't necessarily obvious to implementors without previous
experience with the Ogg container, or the details of the Opus codec.

> And of course, most importantly, I don't want to give people the
> impression that, however weakly we suggest it in the spec, what's
> written there is what all implementations will do, and that therefore
> encoders will _rely_ on that behavior. Then it becomes impossible to use
> the decoder flexibility gained by declaring such constructs invalid.

Ok.

>> Do I
>> understand correctly that, since pre-skip is subtracted from granulepos
>> to obtain timestamps, cropping this way requires rewriting the
>> granulepos field for every page in the logical stream, if
>> synchronization with other logical streams is to be maintained?
> 
> Yes, I believe this is correct. This is still an improvement, in that
> you can get sample-accurate cutting without rewriting the granulepos
> field in every page so long as you _aren't_ trying to synchronize with
> another stream. That's impossible in Vorbis.

I agree. Thanks for clarifying.

>> I was surprised that the R128_TRACK_GAIN field specifies its value is
>> the ascii representation of an integer, which is then interpreted as
>> a fixed point number. Surely including the radix would be more natural
>> for a human-readable field. The draft could still specify the same valid
>> range.
> 
> Care to offer some text to make this more clear?

One new comment tag is introduced for Ogg Opus:

  R128_TRACK_GAIN=-2.238

representing the volume shift needed to normalize the track's volume.
The value of this tag is an ASCII signed decimal number representing
the gain in dB with the same scale as the ID header's 'output gain'
field.

An Ogg Opus logical stream MUST NOT have more than one such tag. Players
MAY clamp the the value to the same range and precision of the Q7.8
fixed-point value of the 'output-gain' field.

Decoders MUST ignore any additional characters after the last digit. So
'R128_TRACK_GAIN=-2.238dB' would be equivalent to the above example.

 -r

From tterribe@xiph.org  Mon Jul 16 15:55:41 2012
Return-Path: <tterribe@xiph.org>
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 57DBB11E809B for <codec@ietfa.amsl.com>; Mon, 16 Jul 2012 15:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.034
X-Spam-Level: 
X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_NJABL_PROXY=1.643]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73iDhw9FI50v for <codec@ietfa.amsl.com>; Mon, 16 Jul 2012 15:55:40 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id ED0FD11E8079 for <codec@ietf.org>; Mon, 16 Jul 2012 15:55:39 -0700 (PDT)
Received: from [10.242.27.190] (unknown [66.207.208.98]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id B0BEBF2691 for <codec@ietf.org>; Mon, 16 Jul 2012 15:56:22 -0700 (PDT)
Message-ID: <50049C10.3090100@xiph.org>
Date: Mon, 16 Jul 2012 15:56:16 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1
MIME-Version: 1.0
To: codec@ietf.org
References: <20120716224054.4047.16310.idtracker@ietfa.amsl.com>
In-Reply-To: <20120716224054.4047.16310.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20120716224054.4047.16310.idtracker@ietfa.amsl.com>
Content-Type: multipart/mixed; boundary="------------090703090908050205020806"
Subject: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-01.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 16 Jul 2012 22:55:41 -0000

This is a multi-part message in MIME format.
--------------090703090908050205020806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

We consolidated the suggestions on the list that appeared to have some 
amount of consensus (and made some additional minor changes), and put 
together a new version of the draft. Brief changelog:

- Mandate that the ID header must complete on the first page (to 
remove any ambiguities about this requirement in RFC 3533).
- Split the "Granule Position" section into subsections.
- Move the first paragraph of the "Other Implementation Notes" 
section into the "Granule Position" section, add general seeking 
implementation guidance, and be specific about the interaction 
between pre-roll and pre-skip.
- Retitle the remaining contents of the "Other Implementation Notes" 
section to "Packet Size Limits"
- Specify that all the header fields are REQUIRED and that 
implementations SHOULD reject headers that don't have enough data.
- Specify that implementations MUST NOT reject headers with extra 
data if they have an unknown minor version number.
- Add a reference to RFC 3629 (UTF-8).
- Clarify what "skipped" means with pre-skip.
- Add an informative reference to Vorbis end-trimming.
- Clarify contents of the vendor string.
- Clarify how Opus packets are packed into multistream Ogg packets.
- Other minor grammatical and wording improvements.
- Add Ralph Giles as an author.

I specifically did not swap the order of Sections 3 and 4, and I did not 
move the definitions of the channel mapping families before the 
definition of the channel mapping table fields (because in addition to 
the definition of "output channels", it requires the concept of "stream 
index", which requires the definition of "coupled streams"). Right now 
two out of three authors are arguing against those two changes, but if 
more people have opinions, or if there's anything else I forgot, feel 
free to speak up.

--------------090703090908050205020806
Content-Type: message/rfc822;
 name="New Version Notification for draft-terriberry-oggopus-01_txt.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="New Version Notification for draft-terriberry-oggopus-01_txt";
 filename*1=".eml"

Return-Path: <internet-drafts@ietf.org>
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on kizuka.merseine.nu
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=4.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.3.2
X-Original-To: derf@kizuka.merseine.nu
Delivered-To: derf@kizuka.merseine.nu
Received: from mail.xiph.org (westfish.xiph.osuosl.org [140.211.166.32])
	by kizuka.merseine.nu (Postfix) with ESMTP id 321D275C02F
	for <derf@kizuka.merseine.nu>; Mon, 16 Jul 2012 18:41:43 -0400 (EDT)
Received: by mail.xiph.org (Postfix)
	id EDD7C1CD9C; Mon, 16 Jul 2012 15:41:42 -0700 (PDT)
Delivered-To: tterribe@xiph.org
Received: from fraxinus.osuosl.org (fraxinus.osuosl.org [140.211.166.137])
	by mail.xiph.org (Postfix) with ESMTP id EA85A1C348;
	Mon, 16 Jul 2012 15:41:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by fraxinus.osuosl.org (Postfix) with ESMTP id E07F1FFDB2;
	Mon, 16 Jul 2012 22:41:42 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
	by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id R6lvOtBwNWQg; Mon, 16 Jul 2012 22:41:41 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail.ietf.org (mail.ietf.org [12.22.58.30])
	by fraxinus.osuosl.org (Postfix) with ESMTP id 22625FFB9C;
	Mon, 16 Jul 2012 22:41:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
	by ietfa.amsl.com (Postfix) with ESMTP id 8778A11E8340;
	Mon, 16 Jul 2012 15:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([12.22.58.30])
	by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id mEQCmZo648IM; Mon, 16 Jul 2012 15:40:54 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1])
	by ietfa.amsl.com (Postfix) with ESMTP id 0E1F211E833B;
	Mon, 16 Jul 2012 15:40:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: tterribe@xiph.org
Cc: giles@xiph.org, ron@debian.org
Subject: New Version Notification for draft-terriberry-oggopus-01.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 4.30p3
Message-ID: <20120716224054.4047.16310.idtracker@ietfa.amsl.com>
Date: Mon, 16 Jul 2012 15:40:54 -0700


A new version of I-D, draft-terriberry-oggopus-01.txt
has been successfully submitted by Timothy B. Terriberry and posted to the
IETF repository.

Filename:	 draft-terriberry-oggopus
Revision:	 01
Title:		 Ogg Encapsulation for the Opus Audio Codec
Creation date:	 2012-07-16
WG ID:		 Individual Submission
Number of pages: 30
URL:             http://www.ietf.org/internet-drafts/draft-terriberry-oggop=
us-01.txt
Status:          http://datatracker.ietf.org/doc/draft-terriberry-oggopus
Htmlized:        http://tools.ietf.org/html/draft-terriberry-oggopus-01
Diff:            http://tools.ietf.org/rfcdiff?url2=3Ddraft-terriberry-oggo=
pus-01

Abstract:
   This document defines the Ogg encapsulation for the Opus interactive
   speech and audio codec.  This allows data encoded in the Opus format
   to be stored in an Ogg logical bitstream.  Ogg encapsulation provides
   Opus with a long-term storage format supporting all of the essential
   features, including metadata, fast and accurate seeking, corruption
   detection, recapture after errors, low overhead, and the ability to
   multiplex Opus with other codecs (including video) with minimal
   buffering.  It also provides a live streamable format, capable of
   delivery over a reliable stream-oriented transport, without requiring
   all the data, or even the total length of the data, up-front, in a
   form that is identical to the on-disk storage format.

                                                                           =
       =



The IETF Secretariat


--------------090703090908050205020806--

From harald@alvestrand.no  Mon Jul 30 09:54:15 2012
Return-Path: <harald@alvestrand.no>
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 C096B11E8132 for <codec@ietfa.amsl.com>; Mon, 30 Jul 2012 09:54:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.305
X-Spam-Level: 
X-Spam-Status: No, score=-110.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6julSYIKwzi for <codec@ietfa.amsl.com>; Mon, 30 Jul 2012 09:54:15 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CE11A11E8130 for <codec@ietf.org>; Mon, 30 Jul 2012 09:54:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 65D3639E13F for <codec@ietf.org>; Mon, 30 Jul 2012 18:54:13 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fbm81QxXrfm2 for <codec@ietf.org>; Mon, 30 Jul 2012 18:54:12 +0200 (CEST)
Received: from [IPv6:2001:df8:0:16:221:6aff:fe8f:cf14] (unknown [IPv6:2001:df8:0:16:221:6aff:fe8f:cf14]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 682BB39E058 for <codec@ietf.org>; Mon, 30 Jul 2012 18:54:12 +0200 (CEST)
Message-ID: <5016BC45.9010304@alvestrand.no>
Date: Mon, 30 Jul 2012 09:54:29 -0700
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: codec@ietf.org
References: <619CA092-0565-41EE-AD7B-D2F836B22337@ibp.de> <4FD7BCCA.5000708@jmvalin.ca> <D3DD025A-B14C-4494-8973-B24B44375DE4@ibp.de> <4FD7E0F1.4080801@mozilla.com> <47991A48-3BEF-44CE-B416-693373693F96@ibp.de> <4FD9FE2D.8070408@mozilla.com>
In-Reply-To: <4FD9FE2D.8070408@mozilla.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [codec] draft-spittka-payload-rtp-opus-00: a=fmtp:101 application=audio
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 30 Jul 2012 16:54:16 -0000

On 06/14/2012 08:07 AM, Jean-Marc Valin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 06/13/2012 06:52 PM, Lars Immisch wrote:
>> Well, the draft talks about "audio mode" and "voice mode" [1]. I
>> should have suggested the parameter name "mode" and not
>> "application" to stay within the draft's language.
> Actually, the audio mode/voice mode will go away in the next revision
> - -- it's just not needed considering that the sender knows better.
>
>> But how can the receiver say: "encode at high bit-rate"? I don't
>> see how that can be done.
> You can do that with the b=AS: parameter
>
Ooops...... do you mean RFC 3550 section 6.2 bandwidth, as referred to 
by RFC 4566 section 5.8?

in the case where we send multiple tracks in a session, the SDP b= 
parameter applies to the total bandwidth of the media streams covered by 
the SDP m= line or SDP session.

If there are mulitple tracks with potentially different bitrates, the 
allocation of bandwidth between the tracks has to be done by the sender.

