Re: [rtcweb] Finishing up the Video Codec document

Daniel-Constantin Mierla <> Thu, 27 November 2014 10:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 35D0F1A88C7 for <>; Thu, 27 Nov 2014 02:37:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8NJDh740uVxm for <>; Thu, 27 Nov 2014 02:37:47 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CEF231A888E for <>; Thu, 27 Nov 2014 02:37:46 -0800 (PST)
Received: by with SMTP id l15so7847501wiw.10 for <>; Thu, 27 Nov 2014 02:37:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Sukoy4Lc5KmO6VHTeB8NwW5OK7D1+RDUmBKv7oxmJ6U=; b=eb24gyZdmv85RYQQRv09TCN6cXmurDvuCXjhNueibZ2xd6bm5b/xUmbC0Z4xJXcvoi qee7JiSNQMUOwN77KWpr642ryR9H+a9vrtRcaTyP+hF/xjmtbpO+vw1AXmG7lpVLbaT7 eXnDoOyth7YhWVem9OZtua4xPD1VQH+a+9XqufsmJ6QRdxPastUgcH+SMYLjAG5gflnq BSBHg4z0UvJT7JgWFxRiX7uT4fk8095gUimayMdUedjogf3uOSdQYjGDmNtW3DavLqMN wM4AnRy6cgTteAKf7H51a2HJ06eOaJhC7Y4tn+j8lda4Howonqh4x8zsD6MjI/oeQAoa dOfQ==
X-Received: by with SMTP id bw16mr51020410wib.50.1417084665660; Thu, 27 Nov 2014 02:37:45 -0800 (PST)
Received: from ([2a01:4f8:a0:638e::2]) by with ESMTPSA id ud1sm10122979wjc.7.2014. for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Nov 2014 02:37:44 -0800 (PST)
Message-ID: <>
Date: Thu, 27 Nov 2014 11:37:42 +0100
From: Daniel-Constantin Mierla <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Adam Roach <>, "" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
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: Thu, 27 Nov 2014 10:37:49 -0000

On 26/11/14 18:09, Adam Roach wrote:
> 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.

That is the decision of a business entity to go for a technology that
can add extra costs to the user of the product. I couldn't find that as
a guiding rule for IETF versus the rule of preferring technologies with
no IPR.

Similar decisions were taken by ITU/GSMA and cell phone manufacturers
with AMR or other things, which haven't impacted any decision on WebRTC
specs (as it should be).

>> 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 chapter.
> 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.

I didn't get the impression that was any clear conclusion on anything,
including if this is the right proposal (e.g., there were voices arguing
about inability to tailor open source browsers for particular needs,
including form those that as some point welcomed the proposal) as well
as what and how should be mandatory for what so ever form (terminology)
of webrtc endpoints.

Besides the well known group of interests jumping on stage with the
'yes', there were real concerns put on table that seems to be ignored.

Moreover, your proposal with considering a past discussions for
something that was not made clear as a decision making process to a
sensitive subject, looks like changing the rules of the game after the
match. Then, using the in-person meeting of a bunch of people in a
far-end corner of the world (for most of the population) to end this
subject, again, without a prior notification, definitely is not a
transparent process, but more an obscure decision system, which I though
it is not how IETF aims to work.


> /a
> _____
> [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.

Daniel-Constantin Mierla!/miconda -