Re: [rtcweb] Performance of H.264...

Stephan Wenger <> Wed, 20 November 2013 22:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 07DF31AE084 for <>; Wed, 20 Nov 2013 14:14:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3W9G-q-vGK4g for <>; Wed, 20 Nov 2013 14:14:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B65131AE01C for <>; Wed, 20 Nov 2013 14:14:21 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 20 Nov 2013 22:14:09 +0000
Received: from ([]) by ([]) with mapi id 15.00.0820.005; Wed, 20 Nov 2013 22:14:08 +0000
From: Stephan Wenger <>
To: Basil Mohamed Gohar <>, "" <>
Thread-Topic: [rtcweb] Performance of H.264...
Thread-Index: AQHO5hk+oT4X9Wzm8UyORPNQmBT585oue4QAgAAE7QCAACk3gIAAARyA//9+kYA=
Date: Wed, 20 Nov 2013 22:14:07 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(479174003)(24454002)(189002)(199002)(51704005)(83322001)(36756003)(19580395003)(19580405001)(49866001)(56776001)(54316002)(81686001)(69226001)(56816003)(76176001)(51856001)(47736001)(74876001)(81342001)(83072001)(47976001)(80976001)(46102001)(50986001)(79102001)(77096001)(81816001)(47446002)(76796001)(4396001)(16601075003)(87936001)(76786001)(77982001)(74366001)(80022001)(31966008)(2656002)(74502001)(65816001)(53806001)(87266001)(74662001)(85306002)(63696002)(66066001)(76482001)(74706001)(59766001)(81542001)(54356001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB361;; CLIP:; FPR:; RD:InfoNoRecords; MX:1; A:0; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Performance of H.264...
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: Wed, 20 Nov 2013 22:14:24 -0000

I believe you can indeed include an H.261 *de*coder without running
unmanageable risk, for pretty much every value of unmanageable.  The
*en*coder is much trickier, as you would have to ensure that your
non-standardized mechanisms are also not covered by enforceable patents.
H.261 *En*coders have never been standardized.
You could in theory implement, without deviation, RM8 (the final H.261
test model), published around the same time as H.261.

On 11.20.2013, 16:57 , "Basil Mohamed Gohar" <>

>On 11/20/2013 04:53 PM, Thomas Reisinger wrote:
>> From my opinion we should stick with h.263 even the minimal risk or
>>licences for the implementer. H261 is a no go for me.
>> Thomas Reisinger
>The point of choosing something aside from VP8 and H.264, which are both
>superior to H.263, is to *completely* avoid all raised and known
>licensing concerns in the mandatory part of the spec.
>This is where H.261 has any value at all in this discussion, even more
>so than any alleged quality tweaks and performance.  It is because any
>rtcweb implementation can include a standards-compliant H.261 en/decoder
>without worrying at all about patent risks.
>If we're willing to accept even a small degree of patent risk, then that
>opens up the door to formats far superior to H.261 and even H.263,
>several of which have already been presented.
>Libre Video
>rtcweb mailing list