Re: [rtcweb] confirming sense of the room: mti codec

Ron <> Tue, 09 December 2014 04:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DF9C01A1B98 for <>; Mon, 8 Dec 2014 20:06:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jjooYFdmMEnS for <>; Mon, 8 Dec 2014 20:06:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D8F2D1A7013 for <>; Mon, 8 Dec 2014 20:06:49 -0800 (PST)
Received: from (HELO mailservice.shelbyville.oz) ([]) by with ESMTP; 09 Dec 2014 14:36:45 +1030
Received: from localhost (localhost []) by mailservice.shelbyville.oz (Postfix) with ESMTP id 0616FFF8FA for <>; Tue, 9 Dec 2014 14:36:44 +1030 (ACDT)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([]) by localhost (mailservice.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id UtlfPcAU1sg4 for <>; Tue, 9 Dec 2014 14:36:42 +1030 (ACDT)
Received: from hex.shelbyville.oz (hex.shelbyville.oz []) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 0AFA9FF819 for <>; Tue, 9 Dec 2014 14:36:42 +1030 (ACDT)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id EA8EA80470; Tue, 9 Dec 2014 14:36:41 +1030 (ACDT)
Date: Tue, 09 Dec 2014 14:36:41 +1030
From: Ron <>
Message-ID: <20141209040641.GH19538@hex.shelbyville.oz>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [rtcweb] confirming sense of the room: mti codec
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Dec 2014 04:06:56 -0000

On Tue, Dec 09, 2014 at 12:45:03AM +0000, Andrew Allen wrote:
> Our preference is for H.264 to be the single MTI. We believe that
> Cisco's open source royalty free code offer goes a long long way to
> address the concerns of many related to IPR on H.264 and the
> prevalence now of APIs to access embedded codecs (such as H.264) on
> mobile devices goes even further to address those concerns.

"Our preference is for VP8 to be the single MTI. We believe that
 Google's open source royalty free code offer goes a long long way to
 address the concerns of many related to IPR on H.264 and the
 prevalence now of APIs to access embedded codecs (such as VP8) on
 mobile devices goes even further to address those concerns."

Do you see how this works?  If you don't care about my concerns,
why should I give the smallest rat's about yours?  When your only
argument to dismiss mine is a straw man, and a pretty shabbily
stuffed one at that, then it's going to get torn to shreds by the
cold steel facts of the matter -- because despite the mirrored
expression, those two statements aren't direct equivalents in
their veracity at all once you really look into them.

I'd invite you to (re)read:

Repeatedly.  Until you begin to gather some glimmering of understanding
about why it's not the IPR on H.264 that is a problem, it's the crippling
*licence* conditions on it.  And the farce of pretending there's a pool
you can maybe try to licence it from, if they'll even talk to you, when
there are numerous companies outside of it, which also demand you have
separate agreements with them.  It's not just Nokia.  AT&T also has their
own out of pool IPR on H.264.  All of which the people pushing H.264-only
have pretended do not exist and handwaved away every time someone asks.

None of which goes away just because somebody else was kind enough to pay
the first installment of the protection racket bill for you.

You are right that there are more than just these two camps though.
There's also a (clearly large) subset of both that cares enough about
the success of this project to compromise with each other in its best
interests.  With enough options and workarounds to get by until we have
an IETF video codec to solve it properly (and I still do think that
clarifying that is important here.  If we're going to do something as
audacious as mandate a patent minefield like H.264 when there is an
equivalent that actually meets the IETF's aspirational requirements for
RF technology, we need a better reason for that than "some people with
H.264 patents insisted" if it's going to survive being challenged, or
ridiculed, in later review).

It's kind of laughable to describe people who don't share that interest
who've not participated in the implementation and interop testing, who
only seem concerned about their own narrow business interest (which may
well be in direct conflict to the charter of this group) as being some
form of "primary participants" we ought to kowtow to.

If they can't come up with a proposal that is more acceptable than the
current compromise, that doesn't give them a right to veto it.  It just
means they are in the rough.  If they weren't going to implement it
anyway, then nothing changes for them.  If they are, the onus is on them
now to offer something workably constructive.  Stamping your feet and
repeating the same old, tired, thoroughly debunked, chestnuts isn't
actually challenging the emerging consensus at all.

This group formed precisely to avoid the sort of "VHS vs Beta" debacle
that you are proposing as a solution.  I'm not sure why you'd be at all
surprised that the answer to that suggestion is a resounding ...

  Uh. No.

We can't stop you from doing that yourself anyway.  But we can stand
together united behind this group's charter.  And I suspect you know
who'll win that competition if we do ...

  The users.