Re: [rtcweb] RTCWEB needs an Internet Codec

Harald Alvestrand <harald@alvestrand.no> Thu, 30 August 2012 19:41 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6E221F85A4 for <rtcweb@ietfa.amsl.com>; Thu, 30 Aug 2012 12:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.069
X-Spam-Level:
X-Spam-Status: No, score=-110.069 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXwE3VrVPNEZ for <rtcweb@ietfa.amsl.com>; Thu, 30 Aug 2012 12:41:25 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA2221F859C for <rtcweb@ietf.org>; Thu, 30 Aug 2012 12:41:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3F42739E2BE; Thu, 30 Aug 2012 21:40:50 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VG76N1gErLi; Thu, 30 Aug 2012 21:40:48 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 72AB439E170; Thu, 30 Aug 2012 21:40:48 +0200 (CEST)
Message-ID: <503FC1BF.5020004@alvestrand.no>
Date: Thu, 30 Aug 2012 21:40:47 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: "Mandyam, Giridhar" <mandyam@quicinc.com>
References: <p06240603cc63f3f41ca9@[99.111.97.136]> <503F46C5.2090607@alvestrand.no> <EDC0A1AE77C57744B664A310A0B23AE240CBCCD8@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <503F61CC.1010709@alvestrand.no> <CAC8DBE4E9704C41BCB290C2F3CC921A162D278D@nasanexd01h.na.qualcomm.com>
In-Reply-To: <CAC8DBE4E9704C41BCB290C2F3CC921A162D278D@nasanexd01h.na.qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] RTCWEB needs an Internet Codec
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2012 19:41:26 -0000

On 08/30/2012 09:13 PM, Mandyam, Giridhar wrote:
> Hello Harald,
> Can you clarify this viewpoint?  If we use the criterion that any MTI codec has to be suitable for all use cases as currently documented, then it seems neither Opus nor G.711 can suffice.
That's not what I said. I said that the *set* of MTI codecs should cover 
the use cases.
We have a requirement (F21) that explicitly mentions commonly supported 
codecs in telephony services; there's no way Opus can cover that case.
>    
>
> For instance, use case 4.2.7 - "... the user's provider of cellular access has QoS support enabled.  The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular."
You're not reading the latest draft. That section is now 4.2.6.
>    If the guaranteed bit rate (GBR, part of the QoS Class Indicator in 3GPP defined networks) falls outside of the operating range where Opus is the best performing codec (e.g. the sub-8kbps part of the 'Quality vs Bitrate' curve in http://www.opus-codec.org/comparison/), another codec would be required.
Section 4.1 of the draft defines "narrowband" to be "10s to 100s of 
Kbits/sec".
>
> The study available at http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_Quality_Characterization_of_IETF_Opus_Codec.pdf clearly shows a significant advantage in MOS scores at 5.9 kbps for  AMR-NB as compared to Opus (Silk).
Respectfully ..... the slight advantage in quality that AMR-NB seems to 
offer over Opus at 8 kbps is very different from the advantage that Opus 
enjoys over G.711 at 64 Kbits and above.
>    The initial conclusion from my end is that using Opus when cellular QoS support results in a guaranteed bit rate less than 8 kbps would not result in the user being "able to take advantage of the QoS support" as per the use case.
Neither does it cover the case where there's not enough bits to carry an 
IP+RTP header every 20 milliseconds. There are cases where WebRTC won't 
work.
>
> I think we shouldn't try to mandate codecs to try to cover every single use case.  Rather we should mandate as few as necessary to avoid codec negotiation failure.
Yes. And failure to negotiate an usable codec is a negotiation failure.
>
> -Giri
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
> Sent: Thursday, August 30, 2012 5:51 AM
> To: DRAGE, Keith (Keith)
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec
>
> On 08/30/2012 02:38 PM, DRAGE, Keith (Keith) wrote:
>> Surely that argument extends to every possible codec.
> The set of MTI codecs should cover the set of use cases that have been identified.
> Additional MTI codecs that don't cover new use cases shouldn't be added.
>
> I believe the use case "distributed music band" in draft-ietf-rtcweb-use-cases-and-requirements can't be satisified with G.711.
>
>> If the codecs supported by both endpoints do not supply the characteristics needed for the communication, then you will get interoperability failure.
>>
>> If I want more bandwidth or quality than OPUS supplies, then I will also get interoperability failure.
>>
>> Keith
>>
>>> -----Original Message-----
>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>>> Behalf Of Harald Alvestrand
>>> Sent: 30 August 2012 11:56
>>> To: rtcweb@ietf.org
>>> Subject: Re: [rtcweb] RTCWEB needs an Internet Codec
>>>
>>> The counterpoint is that having G.711 as the only MTI means that you
>>> get interoperability failure for any application in which G.711 sound
>>> quality is not acceptable.
>>>
>>> This includes all applications involving music.
>>>
>>> On 08/29/2012 06:30 PM, Randall Gellens wrote:
>>>> At 12:13 AM -0400 8/29/12, Roman Shpount wrote:
>>>>
>>>>>    I would argue G.711 should be the MTI codec. The rest can be left
>>>>> up to browser implementers.
>>>> I agree.
>>>>
>>>>>    We can argue all we want, but the best royalty free low bitrate
>>>>> codec available will be the one everybody supports.
>>>> Very good point, and why we should mandate only one audio codec.
>>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb