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