Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

Gaelle Martin-Cocher <> Fri, 05 December 2014 18:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8291A1A1B63 for <>; Fri, 5 Dec 2014 10:57:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xEX1_6viMYT5 for <>; Fri, 5 Dec 2014 10:57:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A3CAA1A1AE3 for <>; Fri, 5 Dec 2014 10:57:00 -0800 (PST)
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 05 Dec 2014 13:56:55 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 5 Dec 2014 13:56:54 -0500
Received: from ([fe80::fcd6:cc6c:9e0b:25bc]) by ([::1]) with mapi id 14.03.0210.002; Fri, 5 Dec 2014 13:56:54 -0500
From: Gaelle Martin-Cocher <>
To: Harald Alvestrand <>, "" <>
Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
Thread-Index: AQHQDyewEeqVo81nB0ShjNtLfXarlJx+j7gAgAAgMwD//7RIMIAAge4A///FiXCAAQTWgIABqNgw
Date: Fri, 5 Dec 2014 18:56:53 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-CA, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
X-Mailman-Version: 2.1.15
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: Fri, 05 Dec 2014 18:57:02 -0000

Hi Harald, 

Is that a google position or just an assumption?
I don't think anyone has an issue with WebRTC-Compatible endpoint. 
Assuming browsers have to implement both and that this question is out of the way.
The remaining point is the 'non-browser', which is already differentiated by the note, and it is acknowledged that (over time?) they may only have one codec to implement. 
I don't see why revisiting the  non-browser category is a problem.


-----Original Message-----
From: rtcweb [] On Behalf Of Harald Alvestrand
Sent: Thursday, December 04, 2014 7:26 AM
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

On 12/04/2014 03:10 AM, Gaelle Martin-Cocher wrote:
> There was a single hum for the three categories (browser, non-browser, compatible endpoints), right?
> That makes a lot of sense for non-browser entities that are in fact WebRTC-compatible enpoints (apps, or gateways or else) to push the burden on the browser vendors as those entities will need to interact with browsers.  Hence "hum"...
> I think it would make a lot of sense to have different "hums" or questions for the two different categories.
> That will bring clarity on what the "non-browser" yet WebRTC endpoint is, versus what the WebRTC-compatible endpoint is (let aside gateways).
> It is not clear to me that we would have had the same results for each category if there was two (or three) different questions.

It is not clear that the questions are independent.

In fact, it is pretty clear to me that some participants who were willing to go with this package deal were quite unwilling to commit to all the pieces of the package if they were presented one at a time, and they had to answer the question not knowing how all the other pieces came out.

I think this is a textbook case of a "package deal".

rtcweb mailing list