Re: [rtcweb] MTI Video Codec: a novel proposal

David Singer <> Mon, 10 November 2014 23:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A95FF1ACEF0 for <>; Mon, 10 Nov 2014 15:04:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.895
X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IfkVx1QxFh_r for <>; Mon, 10 Nov 2014 15:04:05 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 88E7B1A893A for <>; Mon, 10 Nov 2014 15:04:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1415660644; x=2279574244; h=From:Sender:Reply-To:Subject:Date:Message-Id:To:Cc:Mime-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=iQvKn0ExWBAAM/hDT4kup9yMd8iJ40dAux9C/ynLI7w=; b=yy+zGrZCTybJOu8KkFe2eD7EztpsLOLr4vgBB/tdmlefiN4NFQteeDizjlhYsO0N iaasoBfuA4up8sQ+UtyY9oW+zH/ELQ7fHTfBqptHeLbUMRgcHBL7+iGFhFEF/aYr aLijpAFVfdEcxFbkYjxyfr2igMutOcm7M06ma5VQpPwigYROB8fcuQTSJUHihU6P ABTqA8TAdgNHjS/Uo/YWWnKT1bfTvEo76EEvXyO9vdk6o5elf9VG7P6A5PDTKRZt q7+W8h7Tbz1DvSBDLgnwRlB9BvR/zMF+hM4o+4bQ18yCri38krP0XMn3zme1dwQP 8WL36OfMA3xILCtjqKHEhQ==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id F2.63.02334.46441645; Mon, 10 Nov 2014 15:04:04 -0800 (PST)
X-AuditID: 11973e13-f79ee6d00000091e-de-546144649308
Received: from ( []) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by (Apple SCV relay) with SMTP id 9F.09.30150.F5441645; Mon, 10 Nov 2014 15:03:59 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: David Singer <>
In-Reply-To: <>
Date: Mon, 10 Nov 2014 15:04:04 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "" <>
X-Mailer: Apple Mail (2.1878.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FDorJvikhhisP+qoMXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmDr5L2vBN+2K0z/DGxj3K3cxcnJICJhIvF15lx3CFpO4cG89 WxcjF4eQwF5GiY873rHDFPU+72SCSExgknh0sosNJMEsoCex4/ovVhCbV8BAYsmuTcwgtrCA ucSdD//BmtkEVCUezDnG2MXIwcEpYCfxYY88SJgFKHxp72ImiDHaEssWvmaGGGMj8fHkP7Dx QgIxEg+/3GABsUUE1CUuP7wAdY+8xIcPx9lB7pEQuMkqMfPjQqYJjIKzkJw0C8lJs5DsWMDI vIpRKDcxM0c3M89UL7GgICdVLzk/dxMjKCin2wnvYDy9yuoQowAHoxIPr8Pb+BAh1sSy4src Q4zSHCxK4ryTtBNDhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBOKNfl1xP+EuAwaQnH0m87 gle5bNpqZJi9562EbrGYl9jNpKXPq/elVZ3wm+hV5jKHS0PMbGJN+YrsaVcidk/9ff9+bJK9 XnyI7TnhI6y8Nk/8/89fNCXp5py/Dv/5Lkk9yX3bKfBi7gy3TzwrFm+55hnZ9f98bHZXVmdD 8o1CC/fZC7tn3b2qxFKckWioxVxUnAgA5CzfcysCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42IRPCnxUTfeJTHEYOlTRYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMXXyX9aCb9oVp3+GNzDuV+5i5OSQEDCR6H3eyQRhi0lcuLee rYuRi0NIYAKTxKOTXWwgCWYBPYkd13+xgti8AgYSS3ZtYgaxhQXMJe58+M8OYrMJqEo8mHOM sYuRg4NTwE7iwx55kDALUPjS3sVMEGO0JZYtfM0MMcZG4uPJf2DjhQRiJB5+ucECYosIqEtc fniBHeIeeYkPH46zT2Dkm4XkillIrpiFZOwCRuZVjAJFqTmJlUZ6iQUFOal6yfm5mxhBQdRQ 6LyD8dgyq0OMAhyMSjy8Dm/jQ4RYE8uKK3MPMUpwMCuJ8PpoJIYI8aYkVlalFuXHF5XmpBYf YpTmYFES5w2Ljg0REkhPLEnNTk0tSC2CyTJxcEo1MJ7eE8rW92lWN8M8rnDv1k8bP+pw+M/1 usu5UHe9nqjZ7ys/r4XmCvpuVUyWEzI4VL7g3LnCBZtaZeazWFqk9l4VcvgnFDuD85/U/GMi R+/tFP+/9rmlh9FH6Z9p9xzu8rrKcM1gCrxy01z62z/x46Lbe+yOTYx3r+jbwKEdqXK4YOKd 5JC0diWW4oxEQy3mouJEAMlKvXEeAgAA
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal
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: Mon, 10 Nov 2014 23:04:07 -0000

On Nov 10, 2014, at 13:55 , Matthew Kaufman <> wrote:

> I cited those three players just as examples of known positions. There are several others, of course.
> This proposal puts the large initial burden of IPR risk and/or cost on the browser vendors... 
> I think we would need to know how happy Apple, Google, Microsoft, and Mozilla (plus the other major browser vendors ) are with a requirement that both H.264 and VP8 be included with their browser and/or operating system.
> We may be tired of this, but it isn't like we have a royalty-free option for H.264 MPEG-LA or IP risk indemnification from Google.. So what's changed for the browser makers?

That is my question too;  what has changed since this was (effectively) one of the options in the notorious long-ago poll?

On the face of it, this requires proponents of ‘must be free’ to take on a non-free license (in principle, though rarely in practice), which is unacceptable to them, and for the ‘must be reasonably clear of IPR risk and independently implementable’ people to have to take on IPR risk and try (?) to implement from the specs, which seems unacceptable to them.

So, am puzzled. Yes, this proposal would make everyone unhappy (if they actually do it), or non-compliant (if, as I suspect, people implement only what they were going to implement anyway, no matter what the spec. says).  (A mandate is only effective if followed.)

Can anyone explain what’s changed, or what I am missing?

> Matthew Kaufman
> (Sent from my iPhone)
> On Nov 9, 2014, at 6:08 PM, Adam Roach <> wrote:
>> It appears that we're running headlong into another in-person discussion about the relative merits of H.264 and VP8 as MTI candidates again. Matthew Kaufman has argued that this conversation is doomed to failure because no major player has been willing to change their position. The players he cited were Cisco, Google, and Mozilla, who have represented the three main positions on this topic pretty effectively. Although we participate as individuals in the IETF, I think it's fair to say that the last time we had this conversation, the median positions of participants from those companies were "H.264 or die", "VP8 or die", and "either one as long as it's *only* one", respectively.
>> However, even if nothing else has changed, I think one salient point may have become quite important: we're all tired of this. Over two years ago, in March of 2012 -- before I even had an particular interest in WebRTC except as a user -- this had already become such a long-running acrimonious debate that I was brought in as a neutral third party to try to mediate. I'm weary of this argument; and, with the exception of a few aggressive voices who seem to enjoy the battle more than the outcome, I'm hearing a similar exhausted timbre in the messages of other participants (and the key stakeholders in particular).
>> So, I want to float a proposal that represents a compromise, to see if we can finally close this issue. First, I want to start out by reiterating a well-worn observation that the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm about to float just barely clears the bar of what I think I can live with. This proposal is based on an observation that the dominating issues in this conversation remain those of licensing, not technology or even incumbency. I’ve discussed this extensively with representatives of all three of the players I mention above, and they are willing to sign on.
>> This proposal is based on the definitions of "WebRTC User Agent", "WebRTC device", and "WebRTC-compatible endpoint" in section 2.2 of draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:
>> 	• WebRTC User Agents MUST implement both VP8 and H.264.
>> 	• WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents. 
>> 	• WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn't really need to be stated, but I want this proposal to be as explicit as possible).
>> This has the property of ensuring that all devices and user agents can work with all devices and user agents. This has the property of giving no one exactly what they want. And, unlike any other previous plans, this has the property of coming to a decision while maintaining pressure on the only parties who can make a change in the IPR landscape to do so.
>> /a
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list

David Singer
Manager, Software Standards, Apple Inc.