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

Victor Pascual Avila <victor.pascual.avila@gmail.com> Tue, 11 November 2014 08:55 UTC

Return-Path: <victor.pascual.avila@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 6C2671AD5F0 for <rtcweb@ietfa.amsl.com>; Tue, 11 Nov 2014 00:55:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 LtSjHjPRo21m for <rtcweb@ietfa.amsl.com>; Tue, 11 Nov 2014 00:55:01 -0800 (PST)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C0D1A8549 for <rtcweb@ietf.org>; Tue, 11 Nov 2014 00:55:01 -0800 (PST)
Received: by mail-lb0-f169.google.com with SMTP id 10so7255690lbg.14 for <rtcweb@ietf.org>; Tue, 11 Nov 2014 00:54:59 -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:content-transfer-encoding; bh=iwNOki9MPyA2OmNuHg6xHWvFoDlFhOJj7bKPa/JDIgI=; b=CwnGAReUPf1E3bglTLYg3tLQBcW6u3BZJ+fWjy0QgG7EyXNf0yCPil/63LUgmkZwUP e/+oe3w81dWghbmtk7cTFIhUGWRsCrx7uV9KqV9YNVS6acFyo2ohLGnng/d72Za13jTA 39CrJLmD9Y5Zzok5AOmqTV7dozl5ekq4BTzp6fkqPX3cSS55L+tcVDmrPGWz7dGFl/BK 0U0PXNzD3LANdJ3s0su1ff+jbljhkGIWefsYX5OS0VqwYQCprNDRXzb0T9e9V6pJSSJA V8mw/epeXEd67m5H7a7yLqZbd3fcnClt9J1ip0X3uWYvKciQO8D3r7HQuGmkmuoDZAsA RGxQ==
MIME-Version: 1.0
X-Received: by 10.152.1.130 with SMTP id 2mr1247343lam.89.1415696099323; Tue, 11 Nov 2014 00:54:59 -0800 (PST)
Received: by 10.25.77.208 with HTTP; Tue, 11 Nov 2014 00:54:59 -0800 (PST)
In-Reply-To: <CAHBDyN6mVsz_98jbKwy_YR_Pkb2ZTqq=QojnXiSHZ4E_OgQj9Q@mail.gmail.com>
References: <54601E19.8080203@nostrum.com> <CAHBDyN6mVsz_98jbKwy_YR_Pkb2ZTqq=QojnXiSHZ4E_OgQj9Q@mail.gmail.com>
Date: Tue, 11 Nov 2014 09:54:59 +0100
Message-ID: <CAGTXFp8KEnE+NeTDtvYow+Sxrd42xLa9U11RnGSyApjCqHy-xA@mail.gmail.com>
From: Victor Pascual Avila <victor.pascual.avila@gmail.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cCakAYSN0kISltGcAmoJu0W8OeY
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: Tue, 11 Nov 2014 08:55:03 -0000

+1

On Mon, Nov 10, 2014 at 9:57 PM, Mary Barnes <mary.ietf.barnes@gmail.com>; wrote:
> I agree with the proposal - I think this is as close as we will ever get on
> an agreed way forward.
>
> Regards,
> Mary.
>
> On Sun, Nov 9, 2014 at 8: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:
>>
>> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



-- 
Victor Pascual Ávila