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

Basil Mohamed Gohar <> Wed, 20 November 2013 21:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0E9C71AE580 for <>; Wed, 20 Nov 2013 13:57:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.553
X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DtfFSdyWbSDV for <>; Wed, 20 Nov 2013 13:57:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5BFBB1AE576 for <>; Wed, 20 Nov 2013 13:57:28 -0800 (PST)
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id AF2E76531C0 for <>; Wed, 20 Nov 2013 16:57:21 -0500 (EST)
Message-ID: <>
Date: Wed, 20 Nov 2013 16:57:19 -0500
From: Basil Mohamed Gohar <>
Organization: Libre Video
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
References: <> <BLU169-W140BE51D70DC1F7C4E297AF93E60@phx.gbl> <> <20131120192550.GA34900@verdi> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 21:57:30 -0000

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