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