Re: [rtcweb] H.261

Ron <> Fri, 22 November 2013 19:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E4A8E1AE26D for <>; Fri, 22 Nov 2013 11:26:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CpKP_8tGbQFn for <>; Fri, 22 Nov 2013 11:26:55 -0800 (PST)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by (Postfix) with ESMTP id D38271AE1C2 for <>; Fri, 22 Nov 2013 11:26:54 -0800 (PST)
Received: from (HELO audi.shelbyville.oz) ([]) by with ESMTP; 23 Nov 2013 05:56:45 +1030
Received: from localhost (localhost []) by audi.shelbyville.oz (Postfix) with ESMTP id 9409D4F8F3 for <>; Sat, 23 Nov 2013 05:56:42 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([]) by localhost (audi.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id YGSQl0838B40 for <>; Sat, 23 Nov 2013 05:56:41 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 85E1F4F902; Sat, 23 Nov 2013 05:56:41 +1030 (CST)
Date: Sat, 23 Nov 2013 05:56:41 +1030
From: Ron <>
Message-ID: <20131122192641.GZ3245@audi.shelbyville.oz>
References: <> <20131122171020.GY3245@audi.shelbyville.oz> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] H.261
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: Fri, 22 Nov 2013 19:26:57 -0000

On Fri, Nov 22, 2013 at 11:23:02AM -0600, Stefan Slivinski wrote:
> You are not going to avoid patent issues with H.261.  Even if all patents
> associated with the H.261 specification have expired you are going to run
> into generic video patents around motion estimation or rate distortion and
> many, many other areas that have not.  At the end of the day, if a patent
> troll sees you have money, they are going to find a way to sue you.

You keep repeating this, but it's not clear to me what you are actually
arguing here?

Are you saying that the concerns of the VP8 objectors are irrelevant
since the only confirmed relevant IP is freely licenced (just like H.261
now is), and that we should use it instead?

For the people who can't use H.264, the problem is intractable, unless
the holders of its patents revise their licence terms, or until they
also expire.

For the people who say they can't use VP8, the problem is much as you
describe, "maybe some mugger will spring out of the hedges", despite
the protections provided by its licencing.

There seems to be general agreement that the patent risk of H.261 is
no greater than for *any* other technology that will go into this
standard (will you be allowed to establish a connection with one click?)
and that its age provides a certain amount of shelter an implementor
could cower under should that be their best choice.

When was the last time you heard Stephan agree that some technology was
fairly sure to be unencumbered ;?   I rest my case ...

The interesting question that remains is do we have consensus that the
patent risk of MPEG1 is equally minimal (or will be by the time there
are implementations of WebRTC using it out in the wild and/or this
standard is ratified).

If we do, then it remains an option for the MTI video codec.

If there is consensus that the fear of it is too great to expose people
to, then we only have one "safe" choice left for us to consider that
addresses the concerns of those objecting to VP8, and has none of the
problems of H.264.

As I said right after the last meeting, I think we're still a long way
from having exhausted the normal IETF consensus procedures on this
question - though we do seem to be at the point where most people now
realise their most preferred codec option is going to be steadfastly
prevented from achieving consensus by the objections of others.

And so we again basically only have 2 options:

 - Those objections are rejected as vexatious by the chairs and we
   find that we do have consensus on one of the original preferences. [1]

 - Those objections are upheld as valid consensus blockers by the
   chairs, and we need to look at other solutions which address them.

The latter is what the people proposing H.261 are directly addressing.
I'm not sure which part of that you find confusing.


[1] - which would seem to be difficult, assuming they both like their
      role in the IETF and like it to remain uncontroversial, and like
      the job they have with their present employers :)