Re: [codec] WGLC of draft-ietf-codec-opus-07

[Jehan Pagès <[e-mail]>]

Hi,

On Sun, Jul 24, 2011 at 10:44 AM, Christian Hoene
<[e-mail]> wrote:
>> Hi,
>>
>> I went through the draft and parts of the source code and it seems that
>> WGLC
>> is quite too early.
>>

I skimmed through the draft, mainly because it is a complicated one
and am not really knowledgeable on codecs, especially when it came to
the encoding/decoding part with formulas and complicated algorithms
(thus I read the codec modes part more carefully, but the rest, I
would need dedicated days, that I don't have just now). So pardon me
for giving only very superficial bugs that I noticed. I figure that's
better than nothing.

* Section "3. Codec Modes" (page 11):
« For code 2 packets, the TOC byte is followed by a one or two byte
   sequence indicating the the length of the first frame (marked N1 in
   the figure below), followed by N1 bytes of compressed data for the
   first frame. »
=> there is a "the the" repetition.

* Just below, in the same paragraph:
«
The
   length of the first frame, N1, MUST be no larger than the size of the
   payload remaining after decoding that length for all code 2 packets.
»
=> I am not sure what it means? Aren't we simply telling that the
advertised length must not be larger than the actual length (which
appears logical to be by "definition" of "length")?

* At the beginning of section "4. Opus decoder", the little graph has
a block which says "SILK encoder". I think it was supposed to say
"SILK decoder", no?

>> Some text in the draft is hardly understandable if at all, the source code
>> has some (minor) bugs, and the codec supports things that should be done
> in
>> the payload such as frame and a feature called "padding".
>>

Also probably a stupid question for someone new here, but I wondered:
what is exactly the role of padding? Is there an interest to have a
fixed size of packets on some platform for instance?

>> Does anybody beside me review the drafts or the code at all (I mean beside
>> the authors)?
>>
>> More emails are to come or shall I use the track again. Hopefully, it
> would
> [Christian Hoene] not - really not -
>> take a year again to get the issues fixed.
>>
>> Christian
>>

That's all from me. Sorry for not being more helpful.

Jehan