Re: [rtcweb] Video codec selection - way forward

David Singer <> Wed, 20 November 2013 19:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 54CC41AE482 for <>; Wed, 20 Nov 2013 11:42:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.427
X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RdxKVMwxI3Uk for <>; Wed, 20 Nov 2013 11:42:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7308D1AE47D for <>; Wed, 20 Nov 2013 11:42:57 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from ([]) by (Oracle Communications Messaging Server 7u4-23.01 ( 64bit (built Aug 10 2011)) with ESMTP id <> for; Wed, 20 Nov 2013 11:42:51 -0800 (PST)
X-AuditID: 1180715a-b7f3c6d00000020e-c8-528d10ba8f42
Received: from ( []) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by (Apple SCV relay) with SMTP id D6.15.00526.AB01D825; Wed, 20 Nov 2013 11:42:50 -0800 (PST)
Received: from [] (unknown []) by (Oracle Communications Messaging Server 7u4-24.01 ( 64bit (built Nov 17 2011)) with ESMTPSA id <> for; Wed, 20 Nov 2013 11:42:50 -0800 (PST)
From: David Singer <>
In-reply-to: <>
Date: Wed, 20 Nov 2013 11:42:50 -0800
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <> <> <> <> <BLU169-W24713EECAF0BE76A85E94B93E60@phx.gbl> <> <BLU169-W19675CF49C4FAF3F889E4793E60@phx.gbl> <>
X-Mailer: Apple Mail (2.1816)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FAcp7tLoDfIYMN0G4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8XzGG5aCU9wVk/bOZ2xg7OfsYuTkkBAwkei6MZEdwhaTuHBv PVsXIxeHkMBEJolVu08zQjjzmSS2vpgMlOHgYBbQk7h/UQukgRfIPHrmNRNIWFjAUuLCcROQ MJuAqsSDOccYQWxOoJLb65+ygdgsQPGj62Yyg9jMAtoST95dYIUYYyOxqWs2O8SqN0wSTx50 gxWJCAhLbH3VywRxnKzExL8nGCcw8s9CuGIWkitmIRm7gJF5FaNAUWpOYqWZXmJBQU6qXnJ+ 7iZGcHgVRu1gbFhudYhRgINRiYe343FPkBBrYllxZe4hRgkOZiUR3vMcvUFCvCmJlVWpRfnx RaU5qcWHGKU5WJTEeVVndAcJCaQnlqRmp6YWpBbBZJk4OKUaGP2nPTSV3vP8ZHjRNYOTpw9e evpl7c1H1XznHBxfnJU97pRUKNXUt+txHd++NoaZreKiNU++H+L3k5r9c1/SA5YLjDo67k9i dkspXA1L0XbY4Nycv+hyVlTk+R1TnAXaXD7xnpi7t7k3svUhd+m61Y9m3NZSzxHh1sixbO+a cWnC14+bv7Gw8imxFGckGmoxFxUnAgC8j6rdKwIAAA==
Subject: Re: [rtcweb] Video codec selection - way forward
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 19:42:59 -0000

I think we should think hard about H.263 instead of H.261 as the third fallback.  Why?

H.263 was first published in March 1996, so it's 17 years old.  The restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more recent amendments deal with this (and a plethora of other issues), so we’d need to settle on which of those are mandatory (the usual profiling discussion).

There are 34 records in the patent database against H.261, mostly from 1989 but one as recent as 2005 (though that is a re-file).  That's 2.2 (reciprocity), as was one other I checked.

Rather surprisingly, there are only 31 against H.263!  The most recent is 2011, and is also option 2.  Most are 1997-2001.

On this quick glance, H.263 appears no worse than H.261. IANAL (as I am sure you have all noticed).

H.263 is much more widely supported and mandated.  It has been mandated in the 3GPP specs for years (for lots of services, including videoconf), and is effectively the fallback codec today in the industry, as I understand.  It was ubiquitous in video telephony for years, and I suspect many of those systems still ship it.

So, would “MUST implement at least two of (H.264, VP8, H.263)” work?

(I am asking the question, not even answering on behalf of my company, yet.  Let’s get the issues on the table.)

David Singer
Multimedia and Software Standards, Apple Inc.