From nobody Mon Jun 15 10:33:32 2015 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE5D1B2F3E for ; Mon, 15 Jun 2015 10:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HO6-K2RInAqK for ; Mon, 15 Jun 2015 10:33:29 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41DC1B2D8A for ; Mon, 15 Jun 2015 10:33:28 -0700 (PDT) Received: by qged89 with SMTP id d89so9372396qge.0 for ; Mon, 15 Jun 2015 10:33:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VlQBBwA8kDuLjY2FNOr3m+QDUcqhvRBPG+hYVzp0f9o=; b=XuOBh3JgEynpEkj11Hj5wetnTO62ORSoKFGTIZ0sUYTDGNTspdj8XoNTPRpaPLWLKN ZlzD/B1zEF7tvms9k9b/IAG3E3Ba8hEOl/LG219mQhFCboScSBR0ECS9M2X/Ayx4m0S6 nxiTQ7/13hUkJMx+/BmdiDf8sVjI/uhep2rHUi9CP+s39t349vzYCvGklcV96/pnczG2 tyTowELc77sUFyGWshIChGQjmVg1J2w2bQ7IXb5NVHJqXkMqom7yig80opYVCDrZL1rK 51OIOgBiQjQQr3+cwPfdCLpe1DaLJ/OOp3nkcg22YCGx0sfBqrzXyQPkuwqQbsirIzU4 Jd9Q== X-Gm-Message-State: ALoCoQkEMLX6KOy5mPb9wiJwT9YvCml9p1pO01UcI8r0iECN6vnq32la2f6M2pbhSamXFawwr6sn X-Received: by 10.140.147.129 with SMTP id 123mr39170599qht.79.1434389607995; Mon, 15 Jun 2015 10:33:27 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id 205sm6563896qht.28.2015.06.15.10.33.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2015 10:33:27 -0700 (PDT) Message-ID: <557F0C65.5010007@jmvalin.ca> Date: Mon, 15 Jun 2015 13:33:25 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: RFC Errata System , koenvos74@gmail.com, tterriberry@mozilla.com, ben@nostrum.com, alissa@cooperw.in, mzanaty@cisco.com References: <20150615150127.C01BE180206@rfc-editor.org> In-Reply-To: <20150615150127.C01BE180206@rfc-editor.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: codec@ietf.org, bigpeteb@gmail.com Subject: Re: [codec] [Technical Errata Reported] RFC6716 (4392) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 17:33:31 -0000 The suggested text is indeed correct. The question is whether that should go in an errata or in this draft that is already meant to update RFC6716: https://tools.ietf.org/html/draft-ietf-codec-opus-update-01 Cheers, Jean-Marc On 15/06/15 11:01 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC6716, > "Definition of the Opus Audio Codec". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6716&eid=4392 > > -------------------------------------- > Type: Technical > Reported by: Peter Budny > > Section: 2 > > Original Text > ------------- > The Opus codec scales from 6 kbit/s narrowband mono speech to > 510 kbit/s fullband stereo music, with algorithmic delays ranging > from 5 ms to 65.2 ms. > > (further in the same section) > > To > compensate for the different look-ahead required by each layer, the > CELT encoder input is delayed by an additional 2.7 ms. > > Corrected Text > -------------- > The Opus codec scales from 6 kbit/s narrowband mono speech to > 510 kbit/s fullband stereo music, with algorithmic delays ranging > from 5 ms to 66.5 ms. > > (further in the same section) > > To > compensate for the different look-ahead required by each layer, the > CELT encoder input is delayed by an additional 4 ms. > > Notes > ----- > For the latter text, the delays for the CELT and SILK layers must match. SILK has a "5 ms look-ahead for noise shaping estimation", and "1.5 ms delay for sampling rate conversion", totaling 6.5 ms. CELT has a "2.5 ms look-ahead due to the overlapping MDCT windows". Thus, the amount of delay needed to align CELT with SILK is 6.5ms - 2.5ms = 4ms. > > The text at the beginning of the section must reflect this as well. The "algorithmic delays" reported apparently include framing (minimum frame size 2.5ms + look-ahead delay in CELT-only mode 2.5ms = 5ms). In that case, the maximum delay is the maximum frame size (60ms) + the maximum delay for look-ahead and resampling (6.5ms) = 66.5ms. > > Confirmed by author ("Jmvalin") at https://en.wikipedia.org/wiki/Talk:Opus_(audio_format)/Archive_1#Codec_delay_values > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6716 (draft-ietf-codec-opus-16) > -------------------------------------- > Title : Definition of the Opus Audio Codec > Publication Date : September 2012 > Author(s) : JM. Valin, K. Vos, T. Terriberry > Category : PROPOSED STANDARD > Source : Internet Wideband Audio Codec RAI > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > From nobody Mon Jun 15 11:46:03 2015 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAF81A1B77 for ; Mon, 15 Jun 2015 11:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQQeEd6GnNnF for ; Mon, 15 Jun 2015 11:46:00 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2451A1B81 for ; Mon, 15 Jun 2015 11:46:00 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5FIjZQ6059224 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 15 Jun 2015 13:45:45 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Jean-Marc Valin" Date: Mon, 15 Jun 2015 13:45:35 -0500 Message-ID: In-Reply-To: <557F0C65.5010007@jmvalin.ca> References: <20150615150127.C01BE180206@rfc-editor.org> <557F0C65.5010007@jmvalin.ca> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: codec@ietf.org, alissa@cooperw.in, tterriberry@mozilla.com, bigpeteb@gmail.com, koenvos74@gmail.com, RFC Errata System Subject: Re: [codec] [Technical Errata Reported] RFC6716 (4392) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 18:46:02 -0000 Am I correct that this is in descriptive overview text that isn't likely = to affect interoperability, especially if it gets corrected in an = update? If so, My thoughts would be to mark this as "hold for update", = and fix in the update. Do people agree? Thanks! Ben. On 15 Jun 2015, at 12:33, Jean-Marc Valin wrote: > The suggested text is indeed correct. The question is whether that > should go in an errata or in this draft that is already meant to = > update > RFC6716: > https://tools.ietf.org/html/draft-ietf-codec-opus-update-01 > > Cheers, > > Jean-Marc > > On 15/06/15 11:01 AM, RFC Errata System wrote: >> The following errata report has been submitted for RFC6716, >> "Definition of the Opus Audio Codec". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6716&eid=3D4392 >> >> -------------------------------------- >> Type: Technical >> Reported by: Peter Budny >> >> Section: 2 >> >> Original Text >> ------------- >> The Opus codec scales from 6 kbit/s narrowband mono speech to >> 510 kbit/s fullband stereo music, with algorithmic delays ranging >> from 5 ms to 65.2 ms. >> >> (further in the same section) >> >> To >> compensate for the different look-ahead required by each layer, the >> CELT encoder input is delayed by an additional 2.7 ms. >> >> Corrected Text >> -------------- >> The Opus codec scales from 6 kbit/s narrowband mono speech to >> 510 kbit/s fullband stereo music, with algorithmic delays ranging >> from 5 ms to 66.5 ms. >> >> (further in the same section) >> >> To >> compensate for the different look-ahead required by each layer, the >> CELT encoder input is delayed by an additional 4 ms. >> >> Notes >> ----- >> For the latter text, the delays for the CELT and SILK layers must = >> match. SILK has a "5 ms look-ahead for noise shaping estimation", = >> and "1.5 ms delay for sampling rate conversion", totaling 6.5 ms. = >> CELT has a "2.5 ms look-ahead due to the overlapping MDCT windows". = >> Thus, the amount of delay needed to align CELT with SILK is 6.5ms - = >> 2.5ms =3D 4ms. >> >> The text at the beginning of the section must reflect this as well. = >> The "algorithmic delays" reported apparently include framing (minimum = >> frame size 2.5ms + look-ahead delay in CELT-only mode 2.5ms =3D 5ms). = = >> In that case, the maximum delay is the maximum frame size (60ms) + = >> the maximum delay for look-ahead and resampling (6.5ms) =3D 66.5ms. >> >> Confirmed by author ("Jmvalin") at = >> https://en.wikipedia.org/wiki/Talk:Opus_(audio_format)/Archive_1#Codec= _delay_values >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6716 (draft-ietf-codec-opus-16) >> -------------------------------------- >> Title : Definition of the Opus Audio Codec >> Publication Date : September 2012 >> Author(s) : JM. Valin, K. Vos, T. Terriberry >> Category : PROPOSED STANDARD >> Source : Internet Wideband Audio Codec RAI >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> From nobody Mon Jun 15 12:38:33 2015 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63381A6FF2 for ; Mon, 15 Jun 2015 12:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqX9kwsdyXP5 for ; Mon, 15 Jun 2015 12:38:30 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D41FE1A6FFF for ; Mon, 15 Jun 2015 12:38:29 -0700 (PDT) Received: by qgf75 with SMTP id 75so30537866qgf.1 for ; Mon, 15 Jun 2015 12:38:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tZfALcI5T4QfTlacQYLR1M8BeegsQKGs/uBDkzqROpU=; b=jPbJuo/Jiq7Ci6WLnr8SGS8b/FLC/g8g6apQ4qyU/1US7/+Uhmx87Fzp0ANjuopgIE rvvJMCOnjQIix/uBnKBTXZEY1944LUyvog3jNtm4VKUlMJ0v4a1OONsDcIk0/++yI9HM azwaO3TFXFvfhNPNFl8wZnDJ6fThZzt4D2o8ByLVR/kDhcdnwbo+BYrCS/b2zFtKW0ur Hf6NIb9sjaezXdzURraOIuo8iNY7+6AZ0nmp5Grbhc5hYRRR+LVV2cOlRvCExjPv5D8i DFqm2253AjylqHPPTYqqSI3qx3QSC7eTNwFIXBiRdGJXSvO2djbhWiRoIQO570bNQgJu CERg== X-Gm-Message-State: ALoCoQn2MIIQpH4rBMHW48OSlyS9SYOEAwGty1R2RSC1ErKo/5s6sMeTTo/E43ublYsL67aBOKpK X-Received: by 10.140.46.75 with SMTP id j69mr37704865qga.17.1434397108996; Mon, 15 Jun 2015 12:38:28 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable074.170-201-24.mc.videotron.ca. [24.201.170.74]) by mx.google.com with ESMTPSA id y11sm1947899qky.42.2015.06.15.12.38.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2015 12:38:28 -0700 (PDT) Message-ID: <557F29B3.2020406@jmvalin.ca> Date: Mon, 15 Jun 2015 15:38:27 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ben Campbell References: <20150615150127.C01BE180206@rfc-editor.org> <557F0C65.5010007@jmvalin.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: codec@ietf.org, alissa@cooperw.in, tterriberry@mozilla.com, bigpeteb@gmail.com, koenvos74@gmail.com, RFC Errata System Subject: Re: [codec] [Technical Errata Reported] RFC6716 (4392) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 19:38:32 -0000 This is indeed in a descriptive overview and there's no interop implication. About the update draft, note that it doesn't replace the original Opus RFC, but just changes some minor errors in the normative description. Cheers, Jean-Marc On 15/06/15 02:45 PM, Ben Campbell wrote: > Am I correct that this is in descriptive overview text that isn't likely > to affect interoperability, especially if it gets corrected in an > update? If so, My thoughts would be to mark this as "hold for update", > and fix in the update. > > Do people agree? > > Thanks! > > Ben. > > On 15 Jun 2015, at 12:33, Jean-Marc Valin wrote: > >> The suggested text is indeed correct. The question is whether that >> should go in an errata or in this draft that is already meant to update >> RFC6716: >> https://tools.ietf.org/html/draft-ietf-codec-opus-update-01 >> >> Cheers, >> >> Jean-Marc >> >> On 15/06/15 11:01 AM, RFC Errata System wrote: >>> The following errata report has been submitted for RFC6716, >>> "Definition of the Opus Audio Codec". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=6716&eid=4392 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Peter Budny >>> >>> Section: 2 >>> >>> Original Text >>> ------------- >>> The Opus codec scales from 6 kbit/s narrowband mono speech to >>> 510 kbit/s fullband stereo music, with algorithmic delays ranging >>> from 5 ms to 65.2 ms. >>> >>> (further in the same section) >>> >>> To >>> compensate for the different look-ahead required by each layer, the >>> CELT encoder input is delayed by an additional 2.7 ms. >>> >>> Corrected Text >>> -------------- >>> The Opus codec scales from 6 kbit/s narrowband mono speech to >>> 510 kbit/s fullband stereo music, with algorithmic delays ranging >>> from 5 ms to 66.5 ms. >>> >>> (further in the same section) >>> >>> To >>> compensate for the different look-ahead required by each layer, the >>> CELT encoder input is delayed by an additional 4 ms. >>> >>> Notes >>> ----- >>> For the latter text, the delays for the CELT and SILK layers must >>> match. SILK has a "5 ms look-ahead for noise shaping estimation", >>> and "1.5 ms delay for sampling rate conversion", totaling 6.5 ms. >>> CELT has a "2.5 ms look-ahead due to the overlapping MDCT windows". >>> Thus, the amount of delay needed to align CELT with SILK is 6.5ms - >>> 2.5ms = 4ms. >>> >>> The text at the beginning of the section must reflect this as well. >>> The "algorithmic delays" reported apparently include framing (minimum >>> frame size 2.5ms + look-ahead delay in CELT-only mode 2.5ms = 5ms). >>> In that case, the maximum delay is the maximum frame size (60ms) + >>> the maximum delay for look-ahead and resampling (6.5ms) = 66.5ms. >>> >>> Confirmed by author ("Jmvalin") at >>> https://en.wikipedia.org/wiki/Talk:Opus_(audio_format)/Archive_1#Codec_delay_values >>> >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC6716 (draft-ietf-codec-opus-16) >>> -------------------------------------- >>> Title : Definition of the Opus Audio Codec >>> Publication Date : September 2012 >>> Author(s) : JM. Valin, K. Vos, T. Terriberry >>> Category : PROPOSED STANDARD >>> Source : Internet Wideband Audio Codec RAI >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG >>> From nobody Mon Jun 15 12:46:55 2015 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68361A8712 for ; Mon, 15 Jun 2015 12:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOtIW1O-DgNC for ; Mon, 15 Jun 2015 12:46:53 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35921A86F7 for ; Mon, 15 Jun 2015 12:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3775; q=dns/txt; s=iport; t=1434397612; x=1435607212; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=q5v1NrBsdvleOJ9rJ7kO8JUNWVx+EbVLaFlZbvrt3UA=; b=EkBltB4D3uUD6tRii4SKMr/yXWGwJddbPwZ2topJW0tbix/tAS4TbtOa Qv47s7y1r8o8jlaIVk/Rgl1txkAMB0ej6cA0/SMqqAliEvlJWooBjCa9s ZDJU9EymrmpGUg63AnX1EKf8fyn25aAXscvZIuDsBPQjswAK7YmbPPoqZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AmBAAXK39V/4QNJK1BGoMQVF8GvWUJgWOFdgKBPTgUAQEBAQEBAYEKhCIBAQEDAXkFCwIBCBguIRElAgQBDQWIGgMKCA06xgsNhUABAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0SBPYEQgUtuB4QtBYZ6A4U0a4NrglQBhE+FEoFggTOEBIpdZocWJoILDQ+BUm8BEoEzgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,620,1427760000"; d="scan'208";a="159499845" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 15 Jun 2015 19:46:52 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5FJkpQ6006006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jun 2015 19:46:52 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Mon, 15 Jun 2015 14:46:51 -0500 From: "Mo Zanaty (mzanaty)" To: Ben Campbell , Jean-Marc Valin Thread-Topic: [Technical Errata Reported] RFC6716 (4392) Thread-Index: AQHQp6QFXhVF7KCf0EuWKSxnH2F4fQ== Date: Mon, 15 Jun 2015 19:46:50 +0000 Message-ID: References: <20150615150127.C01BE180206@rfc-editor.org> <557F0C65.5010007@jmvalin.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [64.100.32.216] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1A045391DE2BCC40B8BEEA6D08704235@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "alissa@cooperw.in" , "codec@ietf.org" , "tterriberry@mozilla.com" , "bigpeteb@gmail.com" , "koenvos74@gmail.com" , RFC Errata System Subject: Re: [codec] [Technical Errata Reported] RFC6716 (4392) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 19:46:54 -0000 "Hold for update=B2 seems most appropriate, given the pending update draft. (Which is now expired, so authors please update the update. ;) Thanks, Mo On 6/15/15, 2:45 PM, Ben Campbell wrote: Am I correct that this is in descriptive overview text that isn't likely to affect interoperability, especially if it gets corrected in an update? If so, My thoughts would be to mark this as "hold for update", and fix in the update. Do people agree? Thanks! Ben. On 15 Jun 2015, at 12:33, Jean-Marc Valin wrote: > The suggested text is indeed correct. The question is whether that > should go in an errata or in this draft that is already meant to > update > RFC6716: > https://tools.ietf.org/html/draft-ietf-codec-opus-update-01 > > Cheers, > > Jean-Marc > > On 15/06/15 11:01 AM, RFC Errata System wrote: >> The following errata report has been submitted for RFC6716, >> "Definition of the Opus Audio Codec". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6716&eid=3D4392 >> >> -------------------------------------- >> Type: Technical >> Reported by: Peter Budny >> >> Section: 2 >> >> Original Text >> ------------- >> The Opus codec scales from 6 kbit/s narrowband mono speech to >> 510 kbit/s fullband stereo music, with algorithmic delays ranging >> from 5 ms to 65.2 ms. >> >> (further in the same section) >> >> To >> compensate for the different look-ahead required by each layer, the >> CELT encoder input is delayed by an additional 2.7 ms. >> >> Corrected Text >> -------------- >> The Opus codec scales from 6 kbit/s narrowband mono speech to >> 510 kbit/s fullband stereo music, with algorithmic delays ranging >> from 5 ms to 66.5 ms. >> >> (further in the same section) >> >> To >> compensate for the different look-ahead required by each layer, the >> CELT encoder input is delayed by an additional 4 ms. >> >> Notes >> ----- >> For the latter text, the delays for the CELT and SILK layers must >> match. SILK has a "5 ms look-ahead for noise shaping estimation", >> and "1.5 ms delay for sampling rate conversion", totaling 6.5 ms. >> CELT has a "2.5 ms look-ahead due to the overlapping MDCT windows". >> Thus, the amount of delay needed to align CELT with SILK is 6.5ms - >> 2.5ms =3D 4ms. >> >> The text at the beginning of the section must reflect this as well. >> The "algorithmic delays" reported apparently include framing (minimum >> frame size 2.5ms + look-ahead delay in CELT-only mode 2.5ms =3D 5ms). >> In that case, the maximum delay is the maximum frame size (60ms) + >> the maximum delay for look-ahead and resampling (6.5ms) =3D 66.5ms. >> >> Confirmed by author ("Jmvalin") at >>=20 >>https://en.wikipedia.org/wiki/Talk:Opus_(audio_format)/Archive_1#Codec_de >>lay_values >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6716 (draft-ietf-codec-opus-16) >> -------------------------------------- >> Title : Definition of the Opus Audio Codec >> Publication Date : September 2012 >> Author(s) : JM. Valin, K. Vos, T. Terriberry >> Category : PROPOSED STANDARD >> Source : Internet Wideband Audio Codec RAI >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> From nobody Mon Jun 15 12:50:21 2015 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015C11A885F for ; Mon, 15 Jun 2015 12:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kGsd7qaNAyN for ; Mon, 15 Jun 2015 12:50:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8E81A88AF for ; Mon, 15 Jun 2015 12:50:16 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5FJnuQk064895 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 15 Jun 2015 14:50:06 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Jean-Marc Valin" Date: Mon, 15 Jun 2015 14:49:55 -0500 Message-ID: In-Reply-To: <557F29B3.2020406@jmvalin.ca> References: <20150615150127.C01BE180206@rfc-editor.org> <557F0C65.5010007@jmvalin.ca> <557F29B3.2020406@jmvalin.ca> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: codec@ietf.org, alissa@cooperw.in, tterriberry@mozilla.com, bigpeteb@gmail.com, koenvos74@gmail.com, RFC Errata System Subject: Re: [codec] [Technical Errata Reported] RFC6716 (4392) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 19:50:20 -0000 If there's no interop impact, then "hold for update" is usually the = right answer. It's up to the working group and authors whether they want = this particular update to fix the issue :-) On 15 Jun 2015, at 14:38, Jean-Marc Valin wrote: > This is indeed in a descriptive overview and there's no interop > implication. About the update draft, note that it doesn't replace the > original Opus RFC, but just changes some minor errors in the normative > description. > > Cheers, > > Jean-Marc > > On 15/06/15 02:45 PM, Ben Campbell wrote: >> Am I correct that this is in descriptive overview text that isn't = >> likely >> to affect interoperability, especially if it gets corrected in an >> update? If so, My thoughts would be to mark this as "hold for = >> update", >> and fix in the update. >> >> Do people agree? >> >> Thanks! >> >> Ben. >> >> On 15 Jun 2015, at 12:33, Jean-Marc Valin wrote: >> >>> The suggested text is indeed correct. The question is whether that >>> should go in an errata or in this draft that is already meant to = >>> update >>> RFC6716: >>> https://tools.ietf.org/html/draft-ietf-codec-opus-update-01 >>> >>> Cheers, >>> >>> Jean-Marc >>> >>> On 15/06/15 11:01 AM, RFC Errata System wrote: >>>> The following errata report has been submitted for RFC6716, >>>> "Definition of the Opus Audio Codec". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6716&eid=3D4392 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Peter Budny >>>> >>>> Section: 2 >>>> >>>> Original Text >>>> ------------- >>>> The Opus codec scales from 6 kbit/s narrowband mono speech to >>>> 510 kbit/s fullband stereo music, with algorithmic delays ranging >>>> from 5 ms to 65.2 ms. >>>> >>>> (further in the same section) >>>> >>>> To >>>> compensate for the different look-ahead required by each layer, the >>>> CELT encoder input is delayed by an additional 2.7 ms. >>>> >>>> Corrected Text >>>> -------------- >>>> The Opus codec scales from 6 kbit/s narrowband mono speech to >>>> 510 kbit/s fullband stereo music, with algorithmic delays ranging >>>> from 5 ms to 66.5 ms. >>>> >>>> (further in the same section) >>>> >>>> To >>>> compensate for the different look-ahead required by each layer, the >>>> CELT encoder input is delayed by an additional 4 ms. >>>> >>>> Notes >>>> ----- >>>> For the latter text, the delays for the CELT and SILK layers must >>>> match. SILK has a "5 ms look-ahead for noise shaping estimation", >>>> and "1.5 ms delay for sampling rate conversion", totaling 6.5 ms. >>>> CELT has a "2.5 ms look-ahead due to the overlapping MDCT windows". >>>> Thus, the amount of delay needed to align CELT with SILK is 6.5ms - >>>> 2.5ms =3D 4ms. >>>> >>>> The text at the beginning of the section must reflect this as well. >>>> The "algorithmic delays" reported apparently include framing = >>>> (minimum >>>> frame size 2.5ms + look-ahead delay in CELT-only mode 2.5ms =3D 5ms)= =2E >>>> In that case, the maximum delay is the maximum frame size (60ms) + >>>> the maximum delay for look-ahead and resampling (6.5ms) =3D 66.5ms. >>>> >>>> Confirmed by author ("Jmvalin") at >>>> https://en.wikipedia.org/wiki/Talk:Opus_(audio_format)/Archive_1#Cod= ec_delay_values >>>> >>>> >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". If necessary, = >>>> please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party (IESG) >>>> can log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC6716 (draft-ietf-codec-opus-16) >>>> -------------------------------------- >>>> Title : Definition of the Opus Audio Codec >>>> Publication Date : September 2012 >>>> Author(s) : JM. Valin, K. Vos, T. Terriberry >>>> Category : PROPOSED STANDARD >>>> Source : Internet Wideband Audio Codec RAI >>>> Area : Real-time Applications and Infrastructure >>>> Stream : IETF >>>> Verifying Party : IESG >>>> From nobody Mon Jun 15 20:21:05 2015 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0291B38EC; Mon, 15 Jun 2015 20:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-_rJ0Cio5XI; Mon, 15 Jun 2015 20:20:59 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 768291B38E3; Mon, 15 Jun 2015 20:20:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1E8C5180204; Mon, 15 Jun 2015 20:18:17 -0700 (PDT) To: bigpeteb@gmail.com, jmvalin@jmvalin.ca, koenvos74@gmail.com, tterriberry@mozilla.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150616031817.1E8C5180204@rfc-editor.org> Date: Mon, 15 Jun 2015 20:18:17 -0700 (PDT) Archived-At: Cc: codec@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [codec] [Errata Held for Document Update] RFC6716 (4392) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 03:21:00 -0000 The following errata report has been held for document update for RFC6716, "Definition of the Opus Audio Codec". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6716&eid=4392 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Peter Budny Date Reported: 2015-06-15 Held by: Ben Campbell (IESG) Section: 2 Original Text ------------- The Opus codec scales from 6 kbit/s narrowband mono speech to 510 kbit/s fullband stereo music, with algorithmic delays ranging from 5 ms to 65.2 ms. (further in the same section) To compensate for the different look-ahead required by each layer, the CELT encoder input is delayed by an additional 2.7 ms. Corrected Text -------------- The Opus codec scales from 6 kbit/s narrowband mono speech to 510 kbit/s fullband stereo music, with algorithmic delays ranging from 5 ms to 66.5 ms. (further in the same section) To compensate for the different look-ahead required by each layer, the CELT encoder input is delayed by an additional 4 ms. Notes ----- For the latter text, the delays for the CELT and SILK layers must match. SILK has a "5 ms look-ahead for noise shaping estimation", and "1.5 ms delay for sampling rate conversion", totaling 6.5 ms. CELT has a "2.5 ms look-ahead due to the overlapping MDCT windows". Thus, the amount of delay needed to align CELT with SILK is 6.5ms - 2.5ms = 4ms. The text at the beginning of the section must reflect this as well. The "algorithmic delays" reported apparently include framing (minimum frame size 2.5ms + look-ahead delay in CELT-only mode 2.5ms = 5ms). In that case, the maximum delay is the maximum frame size (60ms) + the maximum delay for look-ahead and resampling (6.5ms) = 66.5ms. Confirmed by author ("Jmvalin") at https://en.wikipedia.org/wiki/Talk:Opus_(audio_format)/Archive_1#Codec_delay_values -------------------------------------- RFC6716 (draft-ietf-codec-opus-16) -------------------------------------- Title : Definition of the Opus Audio Codec Publication Date : September 2012 Author(s) : JM. Valin, K. Vos, T. Terriberry Category : PROPOSED STANDARD Source : Internet Wideband Audio Codec RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Mon Jun 15 20:21:55 2015 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B52E1B38EE for ; Mon, 15 Jun 2015 20:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0Y95pCLm-rC for ; Mon, 15 Jun 2015 20:21:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0441B38EF for ; Mon, 15 Jun 2015 20:21:51 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5G3LPRv006663 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 15 Jun 2015 22:21:35 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Mo Zanaty (mzanaty)" Date: Mon, 15 Jun 2015 22:21:24 -0500 Message-ID: <74F9CE45-4455-4F60-BA2F-9EF2792E635B@nostrum.com> In-Reply-To: References: <20150615150127.C01BE180206@rfc-editor.org> <557F0C65.5010007@jmvalin.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "codec@ietf.org" , "alissa@cooperw.in" , "tterriberry@mozilla.com" , "bigpeteb@gmail.com" , "koenvos74@gmail.com" , RFC Errata System Subject: Re: [codec] [Technical Errata Reported] RFC6716 (4392) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 03:21:53 -0000 I changed it to "hold for update". Thanks! Ben. On 15 Jun 2015, at 14:46, Mo Zanaty (mzanaty) wrote: > "Hold for update² seems most appropriate, given the pending update draft. > (Which is now expired, so authors please update the update. ;) > > Thanks, > Mo > > On 6/15/15, 2:45 PM, Ben Campbell wrote: > > Am I correct that this is in descriptive overview text that isn't likely > to affect interoperability, especially if it gets corrected in an > update? If so, My thoughts would be to mark this as "hold for update", > and fix in the update. > > Do people agree? > > Thanks! > > Ben. > > On 15 Jun 2015, at 12:33, Jean-Marc Valin wrote: > >> The suggested text is indeed correct. The question is whether that >> should go in an errata or in this draft that is already meant to >> update >> RFC6716: >> https://tools.ietf.org/html/draft-ietf-codec-opus-update-01 >> >> Cheers, >> >> Jean-Marc >> >> On 15/06/15 11:01 AM, RFC Errata System wrote: >>> The following errata report has been submitted for RFC6716, >>> "Definition of the Opus Audio Codec". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=6716&eid=4392 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Peter Budny >>> >>> Section: 2 >>> >>> Original Text >>> ------------- >>> The Opus codec scales from 6 kbit/s narrowband mono speech to >>> 510 kbit/s fullband stereo music, with algorithmic delays ranging >>> from 5 ms to 65.2 ms. >>> >>> (further in the same section) >>> >>> To >>> compensate for the different look-ahead required by each layer, the >>> CELT encoder input is delayed by an additional 2.7 ms. >>> >>> Corrected Text >>> -------------- >>> The Opus codec scales from 6 kbit/s narrowband mono speech to >>> 510 kbit/s fullband stereo music, with algorithmic delays ranging >>> from 5 ms to 66.5 ms. >>> >>> (further in the same section) >>> >>> To >>> compensate for the different look-ahead required by each layer, the >>> CELT encoder input is delayed by an additional 4 ms. >>> >>> Notes >>> ----- >>> For the latter text, the delays for the CELT and SILK layers must >>> match. SILK has a "5 ms look-ahead for noise shaping estimation", >>> and "1.5 ms delay for sampling rate conversion", totaling 6.5 ms. >>> CELT has a "2.5 ms look-ahead due to the overlapping MDCT windows". >>> Thus, the amount of delay needed to align CELT with SILK is 6.5ms - >>> 2.5ms = 4ms. >>> >>> The text at the beginning of the section must reflect this as well. >>> The "algorithmic delays" reported apparently include framing (minimum >>> frame size 2.5ms + look-ahead delay in CELT-only mode 2.5ms = 5ms). >>> In that case, the maximum delay is the maximum frame size (60ms) + >>> the maximum delay for look-ahead and resampling (6.5ms) = 66.5ms. >>> >>> Confirmed by author ("Jmvalin") at >>> >>> https://en.wikipedia.org/wiki/Talk:Opus_(audio_format)/Archive_1#Codec_de >>> lay_values >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC6716 (draft-ietf-codec-opus-16) >>> -------------------------------------- >>> Title : Definition of the Opus Audio Codec >>> Publication Date : September 2012 >>> Author(s) : JM. Valin, K. Vos, T. Terriberry >>> Category : PROPOSED STANDARD >>> Source : Internet Wideband Audio Codec RAI >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG >>> From nobody Wed Jun 17 09:14:50 2015 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E229F1B2DD4 for ; Mon, 15 Jun 2015 08:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.212 X-Spam-Level: X-Spam-Status: No, score=-99.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Gxd3uXPw3li for ; Mon, 15 Jun 2015 08:04:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 6C32F1B2D85 for ; Mon, 15 Jun 2015 08:04:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C01BE180206; Mon, 15 Jun 2015 08:01:27 -0700 (PDT) To: jmvalin@jmvalin.ca, koenvos74@gmail.com, tterriberry@mozilla.com, ben@nostrum.com, alissa@cooperw.in, tterriberry@mozilla.com, mzanaty@cisco.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150615150127.C01BE180206@rfc-editor.org> Date: Mon, 15 Jun 2015 08:01:27 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Wed, 17 Jun 2015 09:14:48 -0700 Cc: codec@ietf.org, bigpeteb@gmail.com, rfc-editor@rfc-editor.org Subject: [codec] [Technical Errata Reported] RFC6716 (4392) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 15:04:11 -0000 The following errata report has been submitted for RFC6716, "Definition of the Opus Audio Codec". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6716&eid=4392 -------------------------------------- Type: Technical Reported by: Peter Budny Section: 2 Original Text ------------- The Opus codec scales from 6 kbit/s narrowband mono speech to 510 kbit/s fullband stereo music, with algorithmic delays ranging from 5 ms to 65.2 ms. (further in the same section) To compensate for the different look-ahead required by each layer, the CELT encoder input is delayed by an additional 2.7 ms. Corrected Text -------------- The Opus codec scales from 6 kbit/s narrowband mono speech to 510 kbit/s fullband stereo music, with algorithmic delays ranging from 5 ms to 66.5 ms. (further in the same section) To compensate for the different look-ahead required by each layer, the CELT encoder input is delayed by an additional 4 ms. Notes ----- For the latter text, the delays for the CELT and SILK layers must match. SILK has a "5 ms look-ahead for noise shaping estimation", and "1.5 ms delay for sampling rate conversion", totaling 6.5 ms. CELT has a "2.5 ms look-ahead due to the overlapping MDCT windows". Thus, the amount of delay needed to align CELT with SILK is 6.5ms - 2.5ms = 4ms. The text at the beginning of the section must reflect this as well. The "algorithmic delays" reported apparently include framing (minimum frame size 2.5ms + look-ahead delay in CELT-only mode 2.5ms = 5ms). In that case, the maximum delay is the maximum frame size (60ms) + the maximum delay for look-ahead and resampling (6.5ms) = 66.5ms. Confirmed by author ("Jmvalin") at https://en.wikipedia.org/wiki/Talk:Opus_(audio_format)/Archive_1#Codec_delay_values Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6716 (draft-ietf-codec-opus-16) -------------------------------------- Title : Definition of the Opus Audio Codec Publication Date : September 2012 Author(s) : JM. Valin, K. Vos, T. Terriberry Category : PROPOSED STANDARD Source : Internet Wideband Audio Codec RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From yong.quan@tekcomms.com Wed Jun 17 23:54:31 2015 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80111B304F for ; Wed, 17 Jun 2015 23:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQNyWyuQw4Ny for ; Wed, 17 Jun 2015 23:54:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0147.outbound.protection.outlook.com [207.46.100.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11FA11A03A1 for ; Wed, 17 Jun 2015 23:54:29 -0700 (PDT) Received: from BY1PR0501CA0033.namprd05.prod.outlook.com (10.162.139.43) by CY1PR0501MB1306.namprd05.prod.outlook.com (10.160.226.11) with Microsoft SMTP Server (TLS) id 15.1.190.14; Thu, 18 Jun 2015 06:54:29 +0000 Received: from BL2FFO11OLC010.protection.gbl (2a01:111:f400:7c09::159) by BY1PR0501CA0033.outlook.office365.com (2a01:111:e400:4821::43) with Microsoft SMTP Server (TLS) id 15.1.195.15 via Frontend Transport; Thu, 18 Jun 2015 06:54:28 +0000 Authentication-Results: spf=pass (sender IP is 192.65.42.19) smtp.mailfrom=tekcomms.com; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of tekcomms.com designates 192.65.42.19 as permitted sender) receiver=protection.outlook.com; client-ip=192.65.42.19; helo=mx.danahertm.com; Received: from mx.danahertm.com (192.65.42.19) by BL2FFO11OLC010.mail.protection.outlook.com (10.173.160.154) with Microsoft SMTP Server (TLS) id 15.1.190.9 via Frontend Transport; Thu, 18 Jun 2015 06:54:27 +0000 Received: from US-BV-EXC02-P.global.tektronix.net (128.181.11.8) by US-BV-EXE02-P.global.tektronix.net (128.181.15.52) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 17 Jun 2015 23:54:24 -0700 Received: from US-BV-EXM01-P.global.tektronix.net ([fe80::9c2d:8d3b:4ab3:6368]) by US-BV-EXC02-P.global.tektronix.net ([fe80::910:1a5f:7ea5:a469%11]) with mapi id 14.03.0224.002; Wed, 17 Jun 2015 23:54:25 -0700 From: "Quan, Yong" To: "codec@ietf.org" Thread-Topic: OPUS MOS calculation Thread-Index: AdCpkzxmIYLPSZ6sRHmYUvgIgYyP9A== Date: Thu, 18 Jun 2015 06:54:24 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.181.15.10] Content-Type: multipart/alternative; boundary="_000_C9B4F75DEFADA3498369CD37F06E481C410D558DUSBVEXM01Pgloba_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC010; 1:cSbX/XGIwb2yr88qSUBCJset66ZtNU+Kh4dA5t3h8xYcLi8tu/Ff0/ZC2JSHPOma/5wjVnq+sNyy31vgaCrk0qEWa3e1HkrKDuV69ySdLu+3RaPoee3JziGUTYxPsZTys/n5HiVV8T9deL1jbX3lLrAI/1sfhKE1MV4wwXvL6PDUgzpfLbrlMtqho+sz6BHz2bxLMG6oFDuYXV9vxFGegYe+giNHSSEK+8vwLQlKqhuR9KY44BUDzL4es35PueVMByqkegmSwmcmhFB7p/h7HsneN5PjGepSpeMJn5VtTQU= X-Forefront-Antispam-Report: CIP:192.65.42.19; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(189002)(164054003)(229853001)(2351001)(512954002)(66066001)(64706001)(106466001)(50986999)(54356999)(84326002)(16236675004)(19625215002)(2656002)(33656002)(87936001)(92566002)(46102003)(19580395003)(5003600100002)(86362001)(5001920100001)(107886002)(2501003)(6806004)(5001970100001)(2900100001)(5250100002)(2930100002)(2920100001)(5000100001)(16796002)(55846006)(450100001)(77156002)(189998001)(19300405004)(110136002)(62966003)(15975445007)(22756005)(102836002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1306; H:mx.danahertm.com; FPR:; SPF:Pass; MLV:ovrnspm; A:1; MX:1; PTR:mx2.danahertm.com; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1306; 2:Cgo7AYShPdYGam1zLiZIEalr6jttMe2uI0cViNqf3Sch5ecdV2XOTXtLoKge66Yt; 2:vTpC5zVcMjfw/pxoT7BV6bupq/iz54Xm4g0AV/7uxwykSBCsfKqHFvEh0wDiNP/08kIz0qaBFByHicCHR+zCxS0/lCZ5t4qCIBWwj2j7j6h1XIp0x8TcyLmcwXyn175IJOjC4kdbq/l6Vg6AWpXfxyw53udxNk/taK6IGlmAODnsNDz5Ecfj00Y75qiU1qqzNc05pB9ZPRogDPMJcxiJSIv6hPuAxriVx46ASS0ETPM=; 6:+T4ofsOcmrr9/sr21eh/30VDSJXcQw71PxwrAIe0Hle2V6t+mp3/8OjRiz1Ln1eRnokfnyGM2aH8OUtWKn9npO/8cCrlhXA5AJNSb804RQh1FXwdqEnwsQKqLsGmDDUk8mNQNBwKM9cR42oqAoN5GzDIHWPClBEmPkKjdj9f8U7wxNlMF1ebbJ42hcwdyIbsKYBO3kPENseN/VOVeESGVQQo3f51+PXRsQ5/vLpYDy8H1aqMoQSnfzBYalE9Mwp9CQsG3FrwzibXKz2qBxIvi4ahrL79TankSriHfxLxMvO27b3bw/2PLA2kiC5VQpvFekDetYl68iymknxGt3Kp8Xucbq/gWYcylpCbIy3VT900bpTHQJxaihbFPnphRPM4wJ7xgqO5Mcyx3jyZOpOfJeqrS/AWGmfkU2M22JZrXHm87jGlHUuthADXSx7oYThXT0mJFYED4s1H8l3ZgMRURcndNDAhUBQOjBRdIwrs3wgvU1FJy90/pm0BQwx89iwW X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1306; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CY1PR0501MB1306; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1306; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1306; 3:YBSRRq4OrlWeqxQFsmXYaR8cOwJvgC9qQ9Wu74LA1tnDU1rZsHvxchs6JO42t5wCFErKyH3hh9Pk3lXzLa5LeSoXYiebpJBWyVWvodt+c01rgp9PMs9vNRLsRObXtNtjwJu9Y/H82FCwjjvc6M3vxdPAFMpHcQpiOe1uaPcZYqV1o0lg9YtyxLrcJoqdUDIG1vu6aFkJOE7S2G0didmArVleFsyq0eHB5TJcfd8DPvLNXoNP/9Vd2k/lhISYOswIivHCbFYL8kqges0SeROIaFB7oXtjGOZF8Ts5m4jyOC/1pkCrovRBPOoaE0z1jU4S X-Forefront-PRVS: 0611A21987 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1306; 9:wufWjrEXmWKpXLXFBduN9BFCwmOvXMkXgdQlrVyr?= =?us-ascii?Q?RYLONklan7BPjWebCFhlY/ZChTupjt5wKDZmiLM/DxJEyTKxOzNZNb35EzSQ?= =?us-ascii?Q?H3dcaqR4NRPJ6JoRKuletr8fF16nPAmn3pxMNvTTRN5ecki2EZsYwLsA6TCG?= =?us-ascii?Q?0b9TzLjZ+p4lcnBNKi12eka6yDe1mc8jebRW2IK3s6BSolyooU/gjbAkLb70?= =?us-ascii?Q?jtJJVe8qMF9bIxj4tIUmo+XmU3JA9+htndJhh8+ad97fnVIZ9EcThz+ck6ji?= =?us-ascii?Q?b5vloIgktkWPCfdjNNXGzAMdzKiIm9iP3EsHEbbutWnXjx4H9xTLyJ+7xsub?= =?us-ascii?Q?bwE9XotdSmJdFS3vgcZ9lHr4AvmUVxAj7s9ssOF2gcrm1g29wkOEOvZoy8ek?= =?us-ascii?Q?p3zEz31PEvC47087rJ8zPlxYt4QBpMX8O83BMIepYanUkPiLw+kYIAzLw3RE?= =?us-ascii?Q?zjKP+OPLr6F+fqFwodjARHsfUZoCfHVqkHgRwSk127iyZKWqniebZJDPg9La?= =?us-ascii?Q?FpVmOjv6KOBL9ar1yM+qOYkjyN2QIlWywnV2D4+RbURbKRzKHbtYkHaTsOYc?= =?us-ascii?Q?PuD9IwsxMSQXxkLLCnXVYumHUCJsd2JtYHr0edwIJHkWc4GZBYN4QyrpDFEX?= =?us-ascii?Q?M5TCIUDDjYhED/DzOt48pzRj4EOeg+0n2bQtpZaz5Psz6YLmnoCG5BU8k8aW?= =?us-ascii?Q?FxXEQ80shYKOGscsy+vSyJ497w06GbqTV+HWNBZLg1o6mylZ3zfZ28IFgZ3S?= =?us-ascii?Q?eeaJDwycPi01sUehk5FU9Bz7FZ7lapeD1wlE1hrfnIpIe1GkxocD5TO59ah8?= =?us-ascii?Q?eNttG4QBAEGshBQ36BwGQGst8pJv8jOseruvIOm/BfbzL3vzepbjNHdfiOSY?= =?us-ascii?Q?44enULygCT6C9JaHypnL/dngjcefm1/xP8xY+ANA6hGHRoGFVW0Vjv88cBip?= =?us-ascii?Q?H5lxFbAoItGC6490lI+jTAD0KymIkf6wVz4gRNpIZ82vcZazmrh+dQXwFGrP?= =?us-ascii?Q?1a3dPhKSzg0LvbOeMsqSPF4eTxZkMHp18f8M9iaLK6diCeSAnoc4wy7gPTUd?= =?us-ascii?Q?9F5qyNd50Kjc9Nyp3dPXfB8UZ5GZp83ItSdDr/JdUqbbUp941IS69CzlT8Xr?= =?us-ascii?Q?8nj6nm1w1JgbNGpRNiZaKanPvGnihYDO5FN4Qt+iST/YJijoHh17GGXAZhYh?= =?us-ascii?Q?wl9udiaPnmtEE9bHCpZzpA6xN8Tzc7mMWqR8Tr3ReA6aBwROtAs/ifeL5w?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1306; 3:wWgpD3Er4lOaAGPqZQ0bpu7CQNW+J76BSajBCkNp27o7Cyk1i207WiDgLtC93T9X8XohUBOg2OPLnTqa/Ecy3OKw/z+EutmBdZqVyabMqKCG2cLYTEd9CyxIlB1ratUeV0nQz0WbPXXfwgwyxtXiuQ==; 10:WfICYaS4N6wOjOpaXcHGRgb5pm7Un2J2lDL8TTuhRH1q0QUptUc9xGDTW3npH674Z4cn62xw2t3H/j9gbfGmZnI1/IHP07kzBEidqezdtJ8=; 6:ZZD+Vv3KIBVYrmkuhhMddN+z2DToA5TLZT0j3n/icNZTGrYP+1Ha8utVrSSZYU6z X-OriginatorOrg: tekcomms.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jun 2015 06:54:27.9477 (UTC) X-MS-Exchange-CrossTenant-Id: 937985d5-3f80-4fc9-be29-0bccc11e8b77 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=937985d5-3f80-4fc9-be29-0bccc11e8b77; Ip=[192.65.42.19]; Helo=[mx.danahertm.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1306 Archived-At: X-Mailman-Approved-At: Tue, 23 Jun 2015 12:35:55 -0700 Subject: [codec] OPUS MOS calculation X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 06:57:47 -0000 --_000_C9B4F75DEFADA3498369CD37F06E481C410D558DUSBVEXM01Pgloba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We are researching on how to assess the quality of OPUS over RTP, = it seems there is no E-Models as other Codec. Is there a recommended algori= thm for calculate MOS for OPUS over RTP? Any information or suggest is highly appreciate! Looking forward t= o hear you back. Thanks, Yong --_000_C9B4F75DEFADA3498369CD37F06E481C410D558DUSBVEXM01Pgloba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

         We = are researching on how to assess the quality of OPUS over RTP, it seems the= re is no E-Models as other Codec. Is there a recommended algorithm for calc= ulate MOS for OPUS over RTP?

 

         Any= information or suggest is highly appreciate! Looking forward to hear you b= ack.

 

Thanks,

 

Yong

--_000_C9B4F75DEFADA3498369CD37F06E481C410D558DUSBVEXM01Pgloba_--