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=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
