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

Justin Uberti <juberti@google.com> Mon, 10 November 2014 19:55 UTC

Return-Path: <juberti@google.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 A752E1ACD4E for <rtcweb@ietfa.amsl.com>; Mon, 10 Nov 2014 11:55:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.972
X-Spam-Level:
X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] 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 KtIOJ6UIZLQ8 for <rtcweb@ietfa.amsl.com>; Mon, 10 Nov 2014 11:55:22 -0800 (PST)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6941ACD4A for <rtcweb@ietf.org>; Mon, 10 Nov 2014 11:55:19 -0800 (PST)
Received: by mail-yk0-f182.google.com with SMTP id q9so1554551ykb.41 for <rtcweb@ietf.org>; Mon, 10 Nov 2014 11:55:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nJeu530+YUlKAiRPrZXgTs7S8L8bdYVl6GtfLmZoJLw=; b=pnKuyHHqSCARKB49qLzVQ/0+NwSFH5U6vrd+3oaTHf4xIF51KIZ53ENKoJcoVNwLiU x0HLXs1FETyipFTDGqH8pa1T8zhI03C2xH/f1UH18QybdLkp8JqUSvPILX2n1Sqd9Lmv ZIOOlnM8HZcS+G9PwOipzvmWKsEoyysE7GiX/ck2loKXE/g66o3wJvEYoEeOUKzxU4cL t5/x5Sl8N3b8q11RLG/03G/ZlYtW5lPPYHD6KALbtaGaOxUASjcs59woErMEgUxiS+j5 tM1hlKq5SUUGFh5Xo6/Y8bqm5c9newDI8rFb/0REjKc4ejbd3JYywkwq3qkwfcGpzZsc IeRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nJeu530+YUlKAiRPrZXgTs7S8L8bdYVl6GtfLmZoJLw=; b=FT6TnbiXp7f9LLKh7N7brLhXjTBKsEw8wZla4/UmEqFKuIR2K7eQaA9v1nJoN9VFc8 9gAuLzXyQEbvgNeKxQtIAZLg1xwZOULWIkorVrVwx+93Xhq7xbFup7UCBEZxxyIuMCIG 0Lk6A/KgENfNuAf9R5aTrJupkVI9NanxXOfy76wNDFEWtli2nKaNG/a1MUPRLCdgX2TX xHnRcNlNx0iAnZquKhTU3al0UfRBjiSWcIxdBHSrtRzkQTBc4DqjgoLlhQjpw32Og0dk zEvcepSJLWmAj7MXcEq3FZUj82QiVSzE9IFjxMd1BqGQ8HMQLlNXsEZLOfF/RKdujhCn uECg==
X-Gm-Message-State: ALoCoQkxSfA6H61JmYjDoNd6K7w/xHGb113j6S03O1c4y2nqhG9yxjwuZhYTl2VZS0HQp9BvnmWS
X-Received: by 10.221.22.136 with SMTP id qw8mr13430vcb.77.1415649317191; Mon, 10 Nov 2014 11:55:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.237.130 with HTTP; Mon, 10 Nov 2014 11:54:55 -0800 (PST)
In-Reply-To: <54601E19.8080203@nostrum.com>
References: <54601E19.8080203@nostrum.com>
From: Justin Uberti <juberti@google.com>
Date: Mon, 10 Nov 2014 11:54:55 -0800
Message-ID: <CAOJ7v-28XZcnbc1d6i8C_Gt9HV46SeTaagGuYFipUd0xCpsF7g@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Content-Type: multipart/alternative; boundary=001a11337688ada0120507868a89
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IiH-FY0pwe_Vtvy57OZn-IeV4qs
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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 19:55:27 -0000

Adam, thanks for your work on this.

I think this plan represents a legitimate compromise in what had previously
seemed like a stalemate. While not our (Google's) ideal outcome, we think
this is good for the WebRTC ecosystem - it ensures interoperability, and
provides a reasonably clear path for reaching a completely RF solution.

In the meantime, WebRTC devices can use APIs such as Android's MediaCodec
or iOS' VideoToolkit to provide H.264 support without having to distribute
it themselves. (MediaCodec, of course, can also be used for VP8, and soon,
VP9).

Lastly, on the point of whether any codec can meet the bar of being
considered RF, note that the text provides some discretion:


*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, ...*

This allows the IETF to make a decision based on the preponderance of the
evidence.

On Sun, Nov 9, 2014 at 6:08 PM, Adam Roach <adam@nostrum.com>; 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:
>
>
>    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
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>