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

Tim Lindsey <timwlindsey@gmail.com> Mon, 10 November 2014 22:30 UTC

Return-Path: <timwlindsey@gmail.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 059101ACEF9 for <rtcweb@ietfa.amsl.com>; Mon, 10 Nov 2014 14:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, 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 5eXAbmElfLZD for <rtcweb@ietfa.amsl.com>; Mon, 10 Nov 2014 14:30:24 -0800 (PST)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B749A1ACEF1 for <rtcweb@ietf.org>; Mon, 10 Nov 2014 14:30:23 -0800 (PST)
Received: by mail-oi0-f46.google.com with SMTP id g201so6137189oib.19 for <rtcweb@ietf.org>; Mon, 10 Nov 2014 14:30:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d8Tru51s04RWtQOMps5FeTzOo813D93wzs5HfMoIhkU=; b=Oa/ZoqQliG6hU9y4h8AZxCt9II8VIQlaO0Me01iIm2bGIsKvucZ7K6MlyRyCYMwlKF S+rdvC6lWmKWFK9GnbpLr1l+I5LscUToNjWm6/Pj2gMjyrzk11SRaear/lzlmcTN4xnN SNDGR+dPSA5v164mga4XXuuVQTyM6z8RwZopH+6Kw7SxxwXwyWJHDuG/IjeHSInw+JW/ KsFHBqXd+ZHfjXNRibN2X79kPyb63vfeCYwSDwrEM+nL9RmltmGA25889J8WF0HrQmjD q+7UHu0gcbGd139dqACovmFNbR+vi9qc9BJ0Z4ALi1TT/Dne/M8g7R+tKcw1AdThY4lw 17bQ==
MIME-Version: 1.0
X-Received: by 10.182.89.161 with SMTP id bp1mr29394577obb.19.1415658622901; Mon, 10 Nov 2014 14:30:22 -0800 (PST)
Received: by 10.202.227.6 with HTTP; Mon, 10 Nov 2014 14:30:22 -0800 (PST)
In-Reply-To: <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at>
References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at>
Date: Mon, 10 Nov 2014 16:30:22 -0600
Message-ID: <CAJ_e8bNdRyJbSo+yz6iomQLoUNJ4-C+nzcO6chbHJekuNUMb2g@mail.gmail.com>
From: Tim Lindsey <timwlindsey@gmail.com>
To: Matthew Kaufman <matthew@matthew.at>
Content-Type: multipart/alternative; boundary=089e013d0e0257639b050788b503
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/K2MJI8tUpSWKTj0M5E3KF_RXWZo
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 23:42:17 -0000

Agreed. Last I read Apple did not support and had no definitive plan to
begin support for VP8/9. If this stance hasn't wavered I think it presents
an immediate and significant road block to ever making this proposal a
reality, however reasonable it may seem.

On Mon, Nov 10, 2014 at 3:55 PM, Matthew Kaufman <matthew@matthew.at>; 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?
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
> On 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
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>