Re: [rtcweb] MTI Video Codec: a novel proposal
Ron <ron@debian.org> Tue, 11 November 2014 01:11 UTC
Return-Path: <ron@debian.org>
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 72CED1A700C for <rtcweb@ietfa.amsl.com>; Mon, 10 Nov 2014 17:11:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 K1wS2MnwGUU1 for <rtcweb@ietfa.amsl.com>; Mon, 10 Nov 2014 17:11:22 -0800 (PST)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id 069D01A87E0 for <rtcweb@ietf.org>; Mon, 10 Nov 2014 17:11:09 -0800 (PST)
Received: from ppp14-2-63-74.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.63.74]) by ipmail07.adl2.internode.on.net with ESMTP; 11 Nov 2014 11:41:08 +1030
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 5EE15FFEDC for <rtcweb@ietf.org>; Tue, 11 Nov 2014 11:40:56 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0YTAYeO6KZt7 for <rtcweb@ietf.org>; Tue, 11 Nov 2014 11:40:55 +1030 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 20821FFC3E for <rtcweb@ietf.org>; Tue, 11 Nov 2014 11:40:55 +1030 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 0CFB680470; Tue, 11 Nov 2014 11:40:55 +1030 (ACDT)
Date: Tue, 11 Nov 2014 11:40:55 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20141111011054.GR8092@hex.shelbyville.oz>
References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/A7I_KhY0u2PG29vZ_KrXEYPoV14
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 01:11:28 -0000
On Mon, Nov 10, 2014 at 03:04:04PM -0800, David Singer wrote: > > On Nov 10, 2014, at 13:55 , 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? > > That is my question too; what has changed since this was > (effectively) one of the options in the notorious long-ago poll? I think Adam explained this in his original rationale. There appears to be a growing consensus that, "The only thing worse than this current stalemate is people wanting us to remain stalled indefinitely in a state of stalemate over this decision". His option guarantees that anyone implementing only their preferred codec will be able to interop with any compliant implementation, though it may not be able to do so with another non-compliant implementation that similarly opted out of supporting that codec. It also gives the people who are ultimately in the position of prolonging this stalemate indefinitely a mechanism whereby they could, at their option, end it in favour of their preferred codec becoming the sole MTI. Whatever the odds of that actually happening may be, we'll all know exactly who to blame if this compromise ends in its worst case outcome for everyone rather than its best one. > On the face of it, this requires proponents of ‘must be free’ to take > on a non-free license (in principle, though rarely in practice), which > is unacceptable to them, and for the ‘must be reasonably clear of IPR > risk and independently implementable’ people to have to take on IPR > risk and try (?) to implement from the specs, which seems unacceptable > to them. It doesn't "require" any such thing. It requires a compliant implementation to be fully compatible with any non-compliant implementation that for one reason or another finds it impossible to achieve full compliance with the MTI video codec(s). If the escape clause is exercised, we all win and everyone can interop. If it isn't there may be some implementations which give a poorer experience to their users than others do. That's still better than the state of total chaos which would exist if no MTI at all was specified. > So, am puzzled. Yes, this proposal would make everyone unhappy (if > they actually do it), or non-compliant (if, as I suspect, people > implement only what they were going to implement anyway, no matter > what the spec. says). (A mandate is only effective if followed.) > > Can anyone explain what’s changed, or what I am missing? All of the major players in the browser market have said they are on board and will follow this mandate. If some of the remainder don't, or won't, or can't, they get to weigh up their reasons for that against the possibility of having their users simply switch to a browser that does. If some of those players are in a position to be able to exert the pressure they feel upon the other people who are blocking us from being able to exercise the tie-breaker clause, then maybe our odds of triggering it are slightly improved too. Nobody can be forced into providing a fully compliant implementation, but even in the worst case under this, given the assurances we already have, the people who have protested that they absolutely can't ship one of these codecs will still be able to interop with all the major players if they can find no other way around that problem. It's certainly not my preferred solution, but it's definitely not the worst one I can imagine, and is both measurably better than the status quo, and seems to provide reasonable incentives for the people who turn the screws to still try to improve the situation further in their favour, should they actually choose to do so. I eagerly await the next surprising announcement of something we all thought was simply unimaginable a year or two ago! Ron
- [rtcweb] MTI Video Codec: a novel proposal Adam Roach
- Re: [rtcweb] MTI Video Codec: a novel proposal Lorenzo Miniero
- Re: [rtcweb] MTI Video Codec: a novel proposal Jonathan Rosenberg
- Re: [rtcweb] MTI Video Codec: a novel proposal Ron
- Re: [rtcweb] MTI Video Codec: a novel proposal Harald Alvestrand
- Re: [rtcweb] MTI Video Codec: a novel proposal DRAGE, Keith (Keith)
- Re: [rtcweb] MTI Video Codec: a novel proposal Bernard Aboba
- Re: [rtcweb] MTI Video Codec: a novel proposal Ron
- Re: [rtcweb] MTI Video Codec: a novel proposal tim panton
- Re: [rtcweb] MTI Video Codec: a novel proposal Daniel-Constantin Mierla
- Re: [rtcweb] MTI Video Codec: a novel proposal Timothy B. Terriberry
- Re: [rtcweb] MTI Video Codec: a novel proposal Cavigioli, Chris
- Re: [rtcweb] MTI Video Codec: a novel proposal Tim Panton
- Re: [rtcweb] MTI Video Codec: a novel proposal cowwoc
- Re: [rtcweb] MTI Video Codec: a novel proposal Daniel-Constantin Mierla
- Re: [rtcweb] MTI Video Codec: a novel proposal Cullen Jennings
- Re: [rtcweb] MTI Video Codec: a novel proposal Cavigioli, Chris
- Re: [rtcweb] MTI Video Codec: a novel proposal Stephan Wenger
- Re: [rtcweb] MTI Video Codec: a novel proposal Adam Roach
- Re: [rtcweb] MTI Video Codec: a novel proposal Justin Uberti
- Re: [rtcweb] MTI Video Codec: a novel proposal Eric Rescorla
- Re: [rtcweb] MTI Video Codec: a novel proposal Mary Barnes
- Re: [rtcweb] MTI Video Codec: a novel proposal Emil Ivov
- Re: [rtcweb] MTI Video Codec: a novel proposal Roman Shpount
- Re: [rtcweb] MTI Video Codec: a novel proposal Matthew Kaufman
- Re: [rtcweb] MTI Video Codec: a novel proposal Iñaki Baz Castillo
- Re: [rtcweb] MTI Video Codec: a novel proposal Matthew Kaufman
- Re: [rtcweb] MTI Video Codec: a novel proposal Iñaki Baz Castillo
- Re: [rtcweb] MTI Video Codec: a novel proposal Eric Rescorla
- Re: [rtcweb] MTI Video Codec: a novel proposal Harald Alvestrand
- Re: [rtcweb] MTI Video Codec: a novel proposal David Singer
- Re: [rtcweb] MTI Video Codec: a novel proposal Suhas Nandakumar
- Re: [rtcweb] MTI Video Codec: a novel proposal Bernard Aboba
- Re: [rtcweb] MTI Video Codec: a novel proposal Adam Roach
- Re: [rtcweb] MTI Video Codec: a novel proposal Tim Lindsey
- Re: [rtcweb] MTI Video Codec: a novel proposal Roman Shpount
- Re: [rtcweb] MTI Video Codec: a novel proposal Ron
- Re: [rtcweb] MTI Video Codec: a novel proposal David Singer
- Re: [rtcweb] MTI Video Codec: a novel proposal Harald Alvestrand
- Re: [rtcweb] MTI Video Codec: a novel proposal Justin Uberti
- Re: [rtcweb] MTI Video Codec: a novel proposal Bernard Aboba
- Re: [rtcweb] MTI Video Codec: a novel proposal Alexandre GOUAILLARD
- Re: [rtcweb] MTI Video Codec: a novel proposal Matthew Kaufman
- Re: [rtcweb] MTI Video Codec: a novel proposal Matthew Kaufman
- Re: [rtcweb] MTI Video Codec: a novel proposal Harald Alvestrand
- Re: [rtcweb] MTI Video Codec: a novel proposal Roman Shpount
- Re: [rtcweb] MTI Video Codec: a novel proposal Matthew Kaufman
- Re: [rtcweb] MTI Video Codec: a novel proposal Ron
- Re: [rtcweb] MTI Video Codec: a novel proposal Bernard Aboba
- Re: [rtcweb] MTI Video Codec: a novel proposal Victor Pascual Avila
- Re: [rtcweb] MTI Video Codec: a novel proposal Andrew Allen
- Re: [rtcweb] MTI Video Codec: a novel proposal Harald Alvestrand
- Re: [rtcweb] MTI Video Codec: a novel proposal Ron
- Re: [rtcweb] MTI Video Codec: a novel proposal Peter Saint-Andre - &yet
- Re: [rtcweb] MTI Video Codec: a novel proposal Martin Thomson
- Re: [rtcweb] MTI Video Codec: a novel proposal tim panton
- Re: [rtcweb] MTI Video Codec: a novel proposal Harald Alvestrand
- Re: [rtcweb] MTI Video Codec: a novel proposal Adam Roach
- Re: [rtcweb] MTI Video Codec: a novel proposal cowwoc
- Re: [rtcweb] MTI Video Codec: a novel proposal Iñaki Baz Castillo
- Re: [rtcweb] MTI Video Codec: a novel proposal Gaelle Martin-Cocher
- Re: [rtcweb] MTI Video Codec: a novel proposal Harald Alvestrand
- Re: [rtcweb] MTI Video Codec: a novel proposal cowwoc
- Re: [rtcweb] MTI Video Codec: a novel proposal stephane.proust
- Re: [rtcweb] MTI Video Codec: a novel proposal Randell Jesup
- Re: [rtcweb] MTI Video Codec: a novel proposal Gaelle Martin-Cocher
- Re: [rtcweb] MTI Video Codec: a novel proposal Shijun Sun
- Re: [rtcweb] MTI Video Codec: a novel proposal Florian Weimer