Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Ron <> Wed, 13 March 2013 14:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7209A21F8B20 for <>; Wed, 13 Mar 2013 07:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PD2HH4498IR6 for <>; Wed, 13 Mar 2013 07:27:45 -0700 (PDT)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by (Postfix) with ESMTP id EA4ED21F8D8F for <>; Wed, 13 Mar 2013 07:27:34 -0700 (PDT)
Received: from (HELO audi.shelbyville.oz) ([]) by with ESMTP; 14 Mar 2013 00:57:33 +1030
Received: from localhost (localhost []) by audi.shelbyville.oz (Postfix) with ESMTP id D68724F8F3; Thu, 14 Mar 2013 00:57:32 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([]) by localhost (audi.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id z7iB8iz2Fy88; Thu, 14 Mar 2013 00:57:32 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 265864F902; Thu, 14 Mar 2013 00:57:32 +1030 (CST)
Date: Thu, 14 Mar 2013 00:57:32 +1030
From: Ron <>
To: Xavier Marjou <>,
Message-ID: <20130313142732.GE12022@audi.shelbyville.oz>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Mar 2013 14:27:46 -0000

Hi Xavier,

On Wed, Mar 13, 2013 at 09:14:30AM -0400, Xavier Marjou wrote:
> Here is a summary of the draft-marjou-rtcweb-audio-codecs-for-interop-00
> presentation that I had prepared for yesterday's session:
> - The co-authors want to underline that non-WebRTC voice endpoints usually
> use one of the following codecs: AMR, AMR-WB or G.722, which will result in
> massive transcoding when there will be communications between WebRTC
> endpoints and non-WebRTC endpoints.

"Massive" seems a little overstated here.  Any system providing a gateway
service to or between 'low bandwidth' devices is almost surely going to
support more than just WebRTC, and is going to have to transcode for most
or all of them anyway.  Adding an extra burden to WebRTC, especially one
that would only ever apply to some small subset of users, wouldn't appear
to make a significant difference in the requirements for such a system.

> - On one side, transcoding is bad for many reasons discussed in the draft
> (cost issues, intrinsic quality degradation, degraded interactivity,
> fallback from HD to G.711...);

Are you aware of the listening tests presented to the CODEC WG?

In particular the ones that show Opus->AMR and AMR->Opus is not significantly
worse than the intrinsic quality degradation suffered by using AMR alone?

Or that Opus->G.711->AMR is actually better than AMR->G.711->AMR ?

> - On the other side, it is recognized that implementing additional codecs
> in the browsers can generate additional costs.
> - In order to reach a compromise, we would like to add some text in the WG
> draft draft-ietf-rtcweb-audio providing incentives for the browser to use
> these three codecs: make them mandatory to implement when there is no cost
> impact on the browser (e.g. if codec already installed, paid by the device
> vendor...).

Since there is never no cost impact to supporting additional features, that
would imply this is never mandatory ...

In which case why bother half-saying otherwise?

I thought it was already quite clear all along, that people who want to or
have their own good reasons to are free to implement any other codecs they
please - and that they already have, and certainly will continue to do so?

> Any opinion on that?

I don't really see much point to handwaving about particular niche codecs
for particular niche uses unless this is going to be some sort of separate
informational document, that is kept up to date with changes in all the
niches that people have an interest in.

That might be useful.  But 'mandating' something that the people who will
do it were going to do it anyway, and the people who were not are still
not going to do, doesn't seem to add any real value here to either users
or implementers.  It won't explain anything to anybody that they don't
already know if it is of any interest to them.