Re: [rtcweb] Confirmation of consensus on audio codecs

[Stefan Hakansson LK <[e-mail]>]

On 08/28/2012 06:30 PM, Jean-Marc Valin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/28/2012 08:36 AM, Stefan Hakansson LK wrote:
>> "Opus" not well enough defined ============================== Just
>> saying "Opus" is a bit vague for me (who has not been in the codec
>> WG). Is a certain version meant? Which one? Or is it a moving
>> target (i.e. always implement the latest version)?
>
> The exact implementation (or version of that implementation) does not
> matter as long as the implementation is compliant with (upcoming) RFC
> 6716.
>
>> What is included (is jitter management, loss concealment part of
>> Opus or something that is up to the implementation)?
>
> The jitter buffer is not part of Opus, nor is it part of any other
> codec I know of. As for loss concealment, the Opus reference
> implementation proposes one, but implementers can choose what they
> want because there is no interoperability issue with
> changing/improving loss concealment.
>
>> And how is it judged what is a compliant implementation? Is there a
>> ref implementation that you test against? How do you test? Are
>> there test-vectors that must be conformed to? Or is "Opus"
>> standardized as a wire format (meaning that any implementation that
>> can produce/decode that wire format is compliant)? If the latter is
>> true, implementers have more wiggle room to e.g. reduce complexity
>> or design around IPRs (submarine IPRs may surface).
>
> The text in the upcoming RFC 6716 is very clear that only the decoder
> is standardized. This is similar to how codecs like MP3 and AAC are
> defined. We also provide a set of test vectors, along with a program
> that evaluates the decoded output to determine whether the decoder
> under test is compliant.
Jean-Marc,

the info above goes a long way in answering my questions, thanks. I 
don't know the exact rules for IPR statements so I would like to double 
check: the fact that the RFC only defines the decoder, does that mean 
that there can be IPRs known by people in the codec WG that are not 
declared since they would apply to the encoder only (then there is the 
risk of IPRs held by those who have not participated in codec WG)?

Another question I had was if Opus is atomic, or if you can implement 
different profiles, and if so what parts should be MTI for rtcweb (and 
should the profile that is MTI be the same regardless of the device type 
- there has been issues raised regarding complexity?).

>
>> Opus not mature and proven enough
>> ================================= As far as I understand, Opus is a
>> brand new standard. There are implementations on-going, but yet no
>> deployment, no experience from real world use (and definitely not
>> from use in larger scale over a wide range of conditions, involving
>> a broad range of end user devices).
>
> So far, Opus has been deployed in Firefox, GStreamer, FFMpeg,
> Foobar2000, and a few other applications. This is far more deployment
> than any ITU-T/MPEG codec has had by the time of standardization.

That is great, but sort of underlines that there would be no harm in 
delaying the decision until there are experiences made from real world 
use - 'cause it would not be that long till that experience has been 
made (Markus also brought up the IPR status as a reason for waiting - I 
have no idea how long it would take to know more about that).

> Not
> only that, but some of the underlying technology has been in use for
> years now. The original SILK codec (not compatible with Opus but
> having a lot in common) has been in Skype for about 3 years, while
> CELT (again, not compatible but sharing a lot of technology) has been
> deployed in many applications in the past 3 years, including Mumble,
> which has about half a million users worldwide.
>
>> In addition, I've been told that so far Opus has gone through less
>> characterization tests than codecs usually are put through.
>
> When it comes to testing, I recommend reading
> http://tools.ietf.org/html/draft-valin-codec-results-00 which
> summarizes the listening tests that were done on Opus. Also, I
> recommend reading
> https://www.ietf.org/proceedings/82/slides/codec-4.pdf
> This describes a whole series of tests we did that other SDOs
> generally don't do on their codecs.

As Paul suggested, I was referring to the lack of formal, controlled,
characterization tests. That is how other SDOs do it. I don't think that 
is the only way to do it, but I think we should at least have either 
such tests conducted or experience from deployment and use (in a wide 
range of conditions and device types) before making it MTI.

>
>> I don't think it is fair to mandate the implementation of a codec
>> (which is a large and complex piece) under these circumstances.
>
> Well, compared to the rest of webrtc, I find that Opus is so small,
> simple and well-defined :-)

Especially if you draw a diagram with all the signaling paths, all 
components involved, and then make a small box for "codec" (or Opus) :-)

>
> Cheers,
>
> 	Jean-Marc
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJQPPIhAAoJEJ6/8sItn9q93vYH/1Q6/dW3ZTkIsMu8y9GOLLNK
> Agyp8cyfmAREgjP5w5LZw0rmAMGfiPiWKuv7lvTgpivR3HOQbuhnMw9vdQEUJEPw
> xLHpj5SmZMggA8LFNPcWcmztkUcTnEfKCxPcdFPhA2i3b2cBR/L1b4oLRkUY706c
> p/EaBVIvOe7Uk54o13V0S671LaaJlX7qGY5Asf3BWLZlGB5xspwtOJvpQ+C6NiTD
> 94vPId9xKv1BlGIXPbWnUOb3sIAuegGbjkuM36m7DxqVH+zEiXBs8BIDDFdDVSV3
> iatsJSeRb1E11/RSEoPjQQE2oiP3R+K2jZhEZeLSfdY75mpAjE11qqfDQMUUCo0=
> =Otiw
> -----END PGP SIGNATURE-----
>