Re: [rtcweb] Confirmation of consensus on audio codecs

On 08/16/2012 07:15 PM, Cullen Jennings (fluffy) wrote:
>
> At the last meeting we took a hum on selecting Opus and G.711 as the
> mediatory to implement audio codecs. If there is any new opinions
> please send them to the list by August 30th, after which the chairs
> will make a determination of consensus.

As much as I would like to say "I agree", I come to the conclusion it is 
not that simple.

I have two things that concern me:

* "Opus" not well enough defined
* Opus not mature and proven enough (this is the more important concern)

Lets talk about both of these.

"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)?

What is included (is jitter management, loss concealment part of Opus or 
something that is up to the implementation)?

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). Are implementors required to support all
aspects of Opus, or are there sub-sets/profiles that would be sufficient 
(perhaps for certain classes of devices)? [1] suggests that not all 
ptime options need to be supported, but are there others things?

Many of the answers are probably available, but I think they should be
put in front of the WG before making this decision.

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). In
addition, I've been told that so far Opus has gone through less
characterization tests than codecs usually are put through.

I don't think it is fair to mandate the implementation of a codec (which 
is a large and complex piece) under these circumstances. Some real 
deployment (involving many device types) and experience (including
operation in different conditions) should be gained before doing so. It
could also be argued that there is a bigger risk from a licensing
perspective to mandate a codec that has not been in use.

Do I mean we should mandate just G.711?
=======================================
No, not necessarily. Looking ahead, I am convinced that new and improved 
codecs for audio and video will be introduced as they become available. 
There is a logic in adopting technology that reduces the transmitted 
number of bits and enhances the end user experience, and the WG is 
designing a solution that enables new codecs to be introduced and used 
(and I really hope they can be made use of even if the applications is 
untouched) IIUC. However, if G.711 would be the only MTI audio codec, 
services that expect audio BW that goes beyond narrowband could suffer 
since there is no guarantee that there is any other codec than G.711 
supported by both endpoints.

In addition G.711 is not that well suited for for challenging network 
conditions (the most important parts like packet loss concealment and 
jitter management depends on the implementation - or are we going to 
standardize those parts?; what I am after is that it is unable to lower 
the send rate as reaction to congestion - the only method available is 
to use longer frames to make the IP header overhead lower).

I see three possible ways forward:

a) Mandate G.711 only, and let the market decide if there will be a
universally available codec giving higher quality.

b) Postpone the decision for some time. Let Opus (and other new codecs
if such are introduced) get deployed, tested, perhaps improved. The
drawback with this approach is that the selection is delayed. If this
approach is chosen, I would also recommend that the WG spends some time
on selection criteria. In the presentation given in Vancouver ([2]) six
criteria were used (three of them considered more important). I think
they make sense, but can't remember we actually discussed them (or what
other criteria that may make sense).

c) Mandate some other codec (that is already deployed and in use).

Of these approaches, perhaps b) is the most reasonable one.

Stefan

[1] http://datatracker.ietf.org/doc/draft-cbran-rtcweb-codec/?include_text=1
[2] http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-6.pdf

>
> Thanks, Cullen
>
> Please note that the following IPR disclosure have been made on these
> codecs. They can be found at
>
> http://datatracker.ietf.org/ipr/
>
>
> 2010-11-07 • ID # 1445 "Broadcom Corporation's Statement about IPR
> related to draft-ietf-codec-opus-00 and
> draft-ietf-codec-description-00 (1)" 2010-11-07 • ID # 1446 "Xiph.Org
> Foundation's Statement about IPR related to
> draft-ietf-codec-opus-00" 2010-11-12 • ID # 1447 "Broadcom
> Corporation's Statement about IPR related to draft-ietf-codec-opus-00
> and draft-ietf-codec-description-00 (2)" 2011-03-23 • ID # 1520
> "Qualcomm Incorporated's Statement about IPR related to
> draft-ietf-codec-opus-05" 2011-03-27 • ID # 1524 "Xiph.Org
> Foundation's Statement about IPR related to
> draft-ietf-codec-opus-05" 2011-03-29 • ID # 1526 "Broadcom
> Corporation's Statement about IPR related to
> draft-ietf-codec-opus-05" 2011-03-29 • ID # 1525 "Skype Limited's
> Statement about IPR related to draft-ietf-codec-opus-05" 2011-07-23 •
> ID # 1602 "Skype Limited's Statement about IPR related to
> draft-ietf-codec-opus-07" 2012-01-25 • ID # 1670 "Microsoft
> Corporation's Statement about IPR related to
> draft-ietf-codec-opus-10" 2012-03-12 • ID # 1712 "Huawei Technologies
> Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11
> (1)" 2012-04-02 • ID # 1741 "Huawei Technologies Co.,Ltd's Statement
> about IPR related to draft-ietf-codec-opus-11 (2)"
>
>
>
> _______________________________________________ rtcweb mailing list
> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>