Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

Ron <ron@debian.org> Fri, 05 December 2014 03:57 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 3EFB01ABC75 for <rtcweb@ietfa.amsl.com>; Thu, 4 Dec 2014 19:57:16 -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 kXGoZWTlYyMq for <rtcweb@ietfa.amsl.com>; Thu, 4 Dec 2014 19:57:14 -0800 (PST)
Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id ACB8D1ABD39 for <rtcweb@ietf.org>; Thu, 4 Dec 2014 19:57:13 -0800 (PST)
Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail06.adl6.internode.on.net with ESMTP; 05 Dec 2014 14:27:12 +1030
Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 3A09DFFEE9 for <rtcweb@ietf.org>; Fri, 5 Dec 2014 14:27:10 +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 KHFGM647H1IE for <rtcweb@ietf.org>; Fri, 5 Dec 2014 14:27:07 +1030 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 1C631FF82B for <rtcweb@ietf.org>; Fri, 5 Dec 2014 14:27:07 +1030 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 09A0980470; Fri, 5 Dec 2014 14:27:07 +1030 (ACDT)
Date: Fri, 5 Dec 2014 14:27:06 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20141205035706.GB21150@hex.shelbyville.oz>
References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <CALiegfkbiN1BAaJyrqOzUeYiViCGHcs6QaM7VVHwUzCUVAuKBw@mail.gmail.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3qVqrcHLQuE3T4-1HyLCuH9GDy8
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
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: Fri, 05 Dec 2014 03:57:16 -0000

On Thu, Dec 04, 2014 at 02:03:44PM -0800, David Singer wrote:
> 
> > On Dec 4, 2014, at 13:59 , Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > 
> > 2014-12-03 19:33 GMT+01:00 David Singer <singer@apple.com>om>:
> >> As I understand it, the recent face to face meeting decided to draft the requirement that WebRTC browsers be required to implement both VP8 and H.264, and get feedback on this, on the list.
> >> 
> >> This is some feedback.
> > 
> > I've been searching in both the rtcweb and public-webrtc mailing
> > lists, and must say that it is VERY SAD that the only "contribution"
> > and "feedback" received from Apple are these regarding "MTI codecs",
> > nothing else.
> > 
> > I hope Apple has better things to do than sending FUD to working
> > groups in which they have no interest.
> 
> I apologize for both the fact that you think this is FUD, and for the lack of other engagement.
> 
> Quite where you see the uncertainty and doubt in the “you MUST
> implement something which, it is stated, is subject to IPR which
> CANNOT be licensed”, I am less sure.  Fear, yes, I get that.

Are you seriously suggesting that the due diligence which Google's
team did prior to the acquisition of On2 and the VP8 IP was so
completely incompetent that they "somehow missed" the barnload of
random claims that Nokia have belatedly asserted here as a last
scorched earth defence after all other lines of sophistry were
apparently failing dismally?

And/or that Google was also subsequently too incompetent to look
at those and make a few small changes to avoid any they really did?

I think you're right that there isn't actually much uncertainty
or doubt there, but a small group of H.264 patent holders sure is
still trying hard to project the idea that there ought to be some.
Their fear is showing yes.  But it doesn't really appear to be
rubbing off onto anyone else.


> “We may as well all drown together” — it’s not very cheery, is it?

I think the metaphor you were looking for here was "burn on the
platform together".

I don't think there's much uncertainty or doubt as to who the
arsonists are here.  If they want to self-immolate, that's fine,
but wanting to burn everyone else to the water line with them
isn't encouraging anyone to want to join them in that.

The current "compromise" is a direct response to attempts to game
the system to avoid the clear no-brainer outcome of adopting VP8,
which for all empirical measures is still as RF as Opus is, and
would be a near perfect fit as the sort of open to everyone
technology that the IETF prefers to endorse in its standards.

If you don't like the compromise, that's fine.  Lots of us don't
very much like it either.  But if you want to actually fix that,
you're flexing your muscles at the wrong group.  You ought to be
leaning on Nokia instead.  They are the ones who keep shoving a
sabot into the machinery here - though it's hard to think they'd
persist in that like they have without firm encouragement from
their peers.  It's not a good look for them.

The H.264 patent holder cartel holds all the cards to resolve this
one way or the other now.  This compromise explicitly hands them
the deck to shuffle and deal.  The sooner they understand that
they can't just bully or frighten the people who really need an
RF codec into giving up on having one, the sooner we can all get
on with the real game.

This compromise is a way of saying that you can't bully us into
total inaction and failure of this standard either.


I commend the people from both camps who have agreed to meet in
the middle, for all the work they have done trying to find real
ways to move this forward.

  Ron