Re: [rtcweb] Summary of Video Codec contributions

Ron <ron@debian.org> Wed, 17 October 2012 19:20 UTC

Return-Path: <ron@debian.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6282E21F861A for <rtcweb@ietfa.amsl.com>; Wed, 17 Oct 2012 12:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.034
X-Spam-Level:
X-Spam-Status: No, score=0.034 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MBMh2AfE2Zc for <rtcweb@ietfa.amsl.com>; Wed, 17 Oct 2012 12:20:50 -0700 (PDT)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFF121F8634 for <rtcweb@ietf.org>; Wed, 17 Oct 2012 12:20:49 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANEDf1B20idQ/2dsb2JhbABFwCeBCYIgAQEEATocKAsLGC4UGA1Sh2MFvAiLWIZCA44Bh2kBkDSDAg
Received: from ppp118-210-39-80.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.39.80]) by ipmail06.adl2.internode.on.net with ESMTP; 18 Oct 2012 05:50:48 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id C98DA4F8F3 for <rtcweb@ietf.org>; Thu, 18 Oct 2012 05:50:46 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bttJe36CLlus for <rtcweb@ietf.org>; Thu, 18 Oct 2012 05:50:46 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 42D474F902; Thu, 18 Oct 2012 05:50:46 +1030 (CST)
Date: Thu, 18 Oct 2012 05:50:46 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20121017192046.GO6812@audi.shelbyville.oz>
References: <507D4302.9050108@ericsson.com> <CAPF_GTaxcBezxbjd36Xkev5ugof9BAt3vdpZaO_qA7A0ujhp3Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPF_GTaxcBezxbjd36Xkev5ugof9BAt3vdpZaO_qA7A0ujhp3Q@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] Summary of Video Codec contributions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 17 Oct 2012 19:20:51 -0000

Hi Erik,

On Wed, Oct 17, 2012 at 01:56:55AM -0700, Erik Lagerway wrote:
> Thought it important to point out the fact that FREE-P8 (VP8) would likely
> be the preferred codec implemented by independent developers. Royalties and
> admin headaches create a barrier to entry. Independent dev shops equate to
> a great deal of innovation and some of these have been responsible for
> dictating the standard in market with hundreds of millions of users. Yes,
> there is plenty of interoperability with 264 today but that doesn't mean it
> will be that way tomorrow.

Very true.  Though for developers who don't click-track and count users
of their software it is more than just preferred.  An RF solution is
actually the only viable way for this standard to be accessible to them.

Any standard that immediately excludes a large portion of potential
developers and adopters can only ever be of niche value and is certain
to be replaced before long by an alternative that doesn't have that
constraint as a fundamental flaw preventing its broadest use.

If the whole point of this group was to avoid further fracturing of
the developer efforts in this space, then solving this problem now
would be much preferable to forcing another group to develop another
competing standard that does address that issue.  It would be a sad
waste of the invested time of the people here if we didn't recognise
this necessity.

I think the points you make above are very relevant here.


> Can't we do both, as we have done for Audio MTI?

Well, the M in MTI stands for Mandatory.  So mandating both would be
mandating the barriers to entry that you so clearly identified above?

Mandating an RF video codec, and permitting any other to be negotiated
as an extension would be more like what we decided was best for audio.


> If unknown IPR is the only real reason not to include VP8 then I maybe we
> are not trying hard enough.

If that's the only reason people have for opposing VP8 then maybe they're
trying too hard.  Resorting to imaginary reasons to make the issue seem
more complex than it really is doesn't seem very enlightening.

Every day that goes by leaves this argument dangling from a thinner, more
strained thread of tenuousness.  It's been well over a year since the very
public call to form an offensive pool was made or even since the last very
vague mumbling of "yeah, some people responded.  honest." - meanwhile VP8
continues to serve millions of users every day through things like youtube
et al. with no concrete claim being made against them of infringement.

It's not like this is a secret, so any submarine patent holder must know
that laches is now daily eroding their 'investment'.  The extensive patent
search made in the attempt to form a pool surely only weakens their case
further in the absence of any real disclosure or claim being made - if not
outright coming close in itself to 'proving' that no such IPR exists.

If VP8 was mandated here, I presume that would additionally place an
obligation of disclosure on any of the participants of this group, which
would strengthen that protection even more.

If we get to the end of this process and there are still no actual claims
being presented for substantiation, then it seems reasonable to conclude
that we may be as safe as it is ever possible to be from "unknown IPR"
(until the laws are changed to end that kind of madness once and for all).


By contrast the present day known burdens of H.264 are very real, and if
we're going to project our future concerns, then I think we've got more
to worry about from the royalties for H.264 being dialled up greatly as
the patents on it begin to expire and their holders want to 'encourage'
people to switch to H.265 while its patents are still nice and fresh.

Locking people into that seems like a far greater danger.  Especially
since unlike VP8, H.264 really has had submarine patents surface on it
and really is an exposed pawn in the present theatre of patent warfare
that everyone else seems to be ducking stray bullets from these days.

So spruiking there's somehow a spookier risk to VP8 in the face of all
available evidence to the contrary seems like some sport where you have
to squint pretty hard and tip your head 90 degrees to the left in a
dark room, before that line of plot extrapolation might perhaps appear
to be spinning in an even vaguely-real kind of direction, sort of ...

And even then, only if the people wanting you to buy that proposition
don't properly label their axes ...


> RTCweb / WebRTC is supposed to be the next big thing, why hamper
> innovation like this?

Indeed we should not, and I for one certainly hope consensus is
that we will not.


 Stay sharp!
 Ron