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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Mon, 10 November 2014 07:34 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7221A19FB for <rtcweb@ietfa.amsl.com>; Sun, 9 Nov 2014 23:34:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.493
X-Spam-Level:
X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaG0ibnELWt1 for <rtcweb@ietfa.amsl.com>; Sun, 9 Nov 2014 23:34:39 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D209B1A8957 for <rtcweb@ietf.org>; Sun, 9 Nov 2014 23:34:38 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 01A6D89520E62; Mon, 10 Nov 2014 07:34:36 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sAA7Yahq004504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Nov 2014 08:34:36 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 08:34:36 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Adam Roach <adam@nostrum.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] MTI Video Codec: a novel proposal
Thread-Index: AQHP/ItDFWMeXG1KFEOVaXuFJ8cIl5xZdbZw
Date: Mon, 10 Nov 2014 07:34:36 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B2760AD@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <54601E19.8080203@nostrum.com>
In-Reply-To: <54601E19.8080203@nostrum.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B2760ADFR712WXCHMBA11zeu_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nFeyysQo0x52K5iTQe_Y9qSxJl8
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 07:34:43 -0000

First of all can I point out that the correct point of reference within the overview document is I believe section 2.4, not 2.2. Section 2.2 is merely the introduction saying these terms will be defined. 2.4 is the definitive material.

I think your proposal thinks this is all about IPR, and it is not.

The argument from the H.264 side is about interoperability, both in making use of existing embedded H.264 codecs in devices that will support webrtc, and in the ability to interwork through gateways with other devices where the inherent population is H.264.

So the parallel conditional on your item 2) which currently states

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

would be something like...

"If evidence arises that a significant population of webrtc devices and other video capable IP devices beyond gateways support (or are otherwise mandated to support, e.g. by a GSMA specification) a specific video codec (either one of these two or a third) the IETF will change this normative statement to indicate that only that codec is required."

And this condition would need to be ANDed with the first condition.

I can work with 1) 3) and otherwise the first half of 2)

regards

Keith



________________________________
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach
Sent: 10 November 2014 02:08
To: rtcweb@ietf.org
Subject: [rtcweb] MTI Video Codec: a novel proposal

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:


  1.  WebRTC User Agents MUST implement both VP8 and H.264.

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

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