Re: [rtcweb] Proposal for H.263 baseline codec

Stephan Wenger <> Thu, 29 March 2012 14:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5332521E8168 for <>; Thu, 29 Mar 2012 07:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.813
X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Emx5PK0SOWXz for <>; Thu, 29 Mar 2012 07:20:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 612E321E8167 for <>; Thu, 29 Mar 2012 07:20:16 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Thu, 29 Mar 2012 14:20:15 +0000
Received: from mail24-ch1 (localhost []) by (Postfix) with ESMTP id 95C722406C3; Thu, 29 Mar 2012 14:20:15 +0000 (UTC)
X-SpamScore: -24
X-BigFish: PS-24(z11d7lzbb2dI9371I1432N98dKzz1202h1082kzz1033IL8275dhz2fh2a8h668h839h946h)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
Received-SPF: pass (mail24-ch1: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail24-ch1 (localhost.localdomain []) by mail24-ch1 (MessageSwitch) id 1333030813425384_20914; Thu, 29 Mar 2012 14:20:13 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTP id 60E483A0045; Thu, 29 Mar 2012 14:20:13 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 29 Mar 2012 14:20:11 +0000
Received: from ([]) by ([]) with mapi id 14.16.0135.002; Thu, 29 Mar 2012 14:20:11 +0000
From: Stephan Wenger <>
To: Basil Mohamed Gohar <>, "" <>
Thread-Topic: [rtcweb] Proposal for H.263 baseline codec
Thread-Index: AQHNDaWq9kefa/omnUePrLHPwXaly5aBQduAgAAyeIA=
Date: Thu, 29 Mar 2012 14:20:10 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Proposal for H.263 baseline codec
X-Mailman-Version: 2.1.12
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: Thu, 29 Mar 2012 14:20:18 -0000

Please see inline.

On 3.29.2012 15:19 , "Basil Mohamed Gohar"
<> wrote:

>On 03/29/2012 08:15 AM, Dean Willis wrote:
>> So I propose we set H.263 as the baseline ( I expect a bit of
>> profiling may be necessary to further qualify the baseline) and run
>> with that for now. If the situation changes, we can always replace it
>> before final publication.
>> --
>> Dean
>Claiming that VP8 is riskier than a known IPR-enforced format is a
>specious claim considering its already widely implemented usage across
>the web on numerous sites and in hardware.  Additionally, a patent pool
>was called for over a year ago, and nothing has been made public about

These things take time.  The formation of the MPEG-2 patent pool took 4+
years, the formation of the H.264 pool almost as long.  VP8 may be a
particularly hard-to-deal-with technology, because it is not a formal
standard, which may provide rightholders options to enforce their patents
in ways not available if they would have been involved in a standards
setting process (see below), which can make the negotiation of the pool
more complex (can't re-use previous pool agreements as templates, may have
to check for antitrust compliance, and so on).

The most commonly cited timeline for a widely in use technology to be
"save" from a patent viewpoint, based on equitable defenses such as laches
(in the US) is six years.  In some countries of significant size, this
time is longer, and in others, equitable defenses do not exist.  (Very
briefly, and perhaps incorrectly put, those equitable defenses allow a
defendant to argue successfully that a patent cannot be enforced as the
right holder knew that the patent claim was likely being infringed, and
did not enforce the patent.).

>No technology can be completely free from the specter of patent trolls
>and spurious software patents, so these arguments that VP8 is not
>suitable based on this could be applied to anyone.  The fact of the
>matter is that the only known patents on VP8 are owned now by Google and
>they have been licensed in a way compatible with all appropriate uses of
>the technology, including WebRTC.

The second part of your sentence may or may not be true, depending on your
relationship with google, your willingness to use the webm implementation
in unchanged form, and other factors.  Please see the webm license
conditions, which AFAIK can be found here:

In addition, as I pointed out in the meeting, the use of a video codec
created by a body such as MPEG or ITU-T SG16 has the advantage of that the
patents of all participating players are available at least under
Reasonable and Non Discriminatory (RAND) terms.  This may sound like a Bad
Thing if you operate under a business model that prevents you to pay
anything for patent licenses, but it is surely a Good Thing if you are
willing to dish out a moderate amount of money for a license.  RAND
recently has gotten teeth, not so much in terms of the monetary
compensation aspect, but in terms of difficulty (if not unavailability) to
obtain injunctive relive, among others.  H.26x and the MPEG standards
benefit from RAND commitments, VP8, AFAIK, does not.


>While I appreciate the sentiment of this suggestion, I am of the opinion
>that choosing a known-restricted format over VP8 will be
>counter-productive to the adoption of the WebRTC standard and will, in
>fact, restrict possible implementations.
>rtcweb mailing list