[rtcweb] MTI Video Codec: a novel proposal

Adam Roach <adam@nostrum.com> Mon, 10 November 2014 02:08 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id A793D1A8872 for <rtcweb@ietfa.amsl.com>; Sun, 9 Nov 2014 18:08:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.207
X-Spam-Status: No, score=0.207 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IuMm2jQYEjiF for <rtcweb@ietfa.amsl.com>; Sun, 9 Nov 2014 18:08:27 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3D1B41A886E for <rtcweb@ietf.org>; Sun, 9 Nov 2014 18:08:27 -0800 (PST)
Received: from dhcp-b419.meeting.ietf.org (dhcp-b419.meeting.ietf.org []) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAA28Ph0038936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <rtcweb@ietf.org>; Sun, 9 Nov 2014 20:08:26 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <54601E19.8080203@nostrum.com>
Date: Sun, 09 Nov 2014 16:08:25 -1000
From: Adam Roach <adam@nostrum.com>
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: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="------------040503070102040402080201"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/juVsZKp-AmRpYLCgy-uwartuNrY
Subject: [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 02:08:32 -0000

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.