Re: [rtcweb] Finishing up the Video Codec document

Adam Roach <> Wed, 26 November 2014 17:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3F7CD1A0149 for <>; Wed, 26 Nov 2014 09:09:16 -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 9Ctp6j64oIkB for <>; Wed, 26 Nov 2014 09:09:11 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EAE51A0173 for <>; Wed, 26 Nov 2014 09:09:11 -0800 (PST)
Received: from Orochi.local ([]) (authenticated bits=0) by (8.14.9/8.14.7) with ESMTP id sAQH95Xv002558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Nov 2014 11:09:06 -0600 (CST) (envelope-from
X-Authentication-Warning: Host [] claimed to be Orochi.local
Message-ID: <>
Date: Wed, 26 Nov 2014 11:09:01 -0600
From: Adam Roach <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To:, "" <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Harald Alvestrand <>
Subject: Re: [rtcweb] Finishing up the Video Codec document
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: Wed, 26 Nov 2014 17:09:16 -0000

On 11/26/14 03:15, Daniel-Constantin Mierla wrote:
> IMO, mandatory codec revisiting has to be done for all webrtc entities.
> Why not doing it for web browsers when one codec is proved to be royalty
> free?

The rationale here is browser accommodation for very constrained "WebRTC 
compatible" devices, which will most typically be concerned with browser 
interoperation. The example that's been tossed around in this space is 
the "WebRTC doorbell" -- when someone rings the bell, you navigate to 
its interface using WebRTC, and stream an image from a small, embedded 
camera. In these kinds of very-low-cost devices, you're going to likely 
see hardware video encoding (e.g. do a web search for NVS2200), which 
will likely be one codec or another, but not both.

The goal is continued browser support for such devices in perpetuity.

> Btw, from the minutes sent on the mailing list, I understood that the
> decision is to be confirmed on the list (which is the norm for IETF
> anyhow). Unless I missed some messages, I haven't seen any discussion
> here following the last IETF meeting, exposing the conclusion of the
> meeting and asking to have a decision on that.

Sure. I'll leave it to the chairs to cross their t's and dot their i's 
how they see fit, but it's pretty clear which direction the wind is 
blowing. Frankly, if I were chair [1], I would consider the on-list 
conversation from November 9th through November 15th (67 messages in 
total) to be sufficient ratification for the proposal, and the in-person 
discussion simply a final punctuation mark on this long-languishing 

If the on-list and in-person conversations had been pointed different 
directions from each other, I'd definitely be holding off trying to get 
the draft language nailed down. But they weren't, so I'm not.


[1] I'm not second-guessing what the chairs are doing here, mind you -- 
I'm just pointing out that they appear to be choosing their actions out 
of an abundance of caution rather than absolute necessity.