Re: [rtcweb] Video codec selection - way forward

David Singer <singer@apple.com> Thu, 21 November 2013 19:21 UTC

Return-Path: <singer@apple.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E089B1AE275 for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 11:21:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.427
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg3z0nObl_vt for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 11:21:42 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 035711AE247 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 11:21:42 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset="windows-1252"
Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWM00E5WODS30B0@mail-out.apple.com> for rtcweb@ietf.org; Thu, 21 Nov 2013 11:20:27 -0800 (PST)
X-AuditID: 11807143-b7fbb6d00000049d-df-528e5cfaa884
Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 98.4E.01181.AFC5E825; Thu, 21 Nov 2013 11:20:27 -0800 (PST)
Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWM00DJ0OE2KX40@spicerack.apple.com> for rtcweb@ietf.org; Thu, 21 Nov 2013 11:20:26 -0800 (PST)
From: David Singer <singer@apple.com>
In-reply-to: <528E4139.3050808@googlemail.com>
Date: Thu, 21 Nov 2013 11:20:26 -0800
Content-transfer-encoding: quoted-printable
Message-id: <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com>
References: <D9C9C6C10CA24644B3A854DB0C12E7D5014C12B5F1@gbplmail03.genband.com> <52891EDB.2050607@googlemail.com> <D0698C9F-967F-4797-A9F3-E461B9DAE8EB@apple.com> <528B2ABE.4040701@googlemail.com> <BLU169-W24713EECAF0BE76A85E94B93E60@phx.gbl> <528C79AD.10608@googlemail.com> <BLU169-W19675CF49C4FAF3F889E4793E60@phx.gbl> <528D0355.3090603@googlemail.com> <55E140BF-D025-4556-A4F2-2441EE766F6B@apple.com> <528E4139.3050808@googlemail.com>
To: rtcweb@ietf.org
X-Mailer: Apple Mail (2.1822)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUi2FCsofs7pi/I4N5zJou1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8WmOXMEq8YpTszczNTDeFepi5OCQEDCReLTXvouRE8gUk7hw bz0biC0kMJlJYtlrbgh7NZNE5042kHJmAT2J+xe1QMK8QOat5vvMIGFhAUuJC8dNQMJsAqoS D+YcYwSxOYFKlvz6wA5iswDF537eCRZnFtCWePLuAivEGBuJRbteM3UxcgFtOsossfv7GhaQ hIiAsMTWV71MEKfJSux+/p15AiP/LIQrZiG5YhaSsQsYmVcxChSl5iRWGuklFhTkpOol5+du YgSHVaHzDsZjy6wOMQpwMCrx8O6w7AsSYk0sK67MPcQowcGsJML7VR0oxJuSWFmVWpQfX1Sa k1p8iFGag0VJnHeHL1BKID2xJDU7NbUgtQgmy8TBKdXA6G/RZSU5f+d3zoyWXw4SvRs5CnfL f7x5qcJ//emKrms1ad8jZjIYZXNHbfmy4XHsF5P9/A6un68w631x9LLOrRf6MfnO9k18dza9 ZY/cP0t1e8v+xpNxtsG94TxFJ9ZMY77DWFvnc1umYL4fp/bN0p1qb66kte8ukWw8v2qzdHtw RNiss1umK7EUZyQaajEXFScCADmzwn0nAgAA
Subject: Re: [rtcweb] Video codec selection - way forward
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Nov 2013 19:21:46 -0000

Chairs

can we add this as an option to the formal list, so we get formal feedback on its acceptability, please?

“Like option ??, pick at least two of {VP8, H.264 CBP, H.263}”


I think this may be the best (maybe only) way to tease out how much risk people perceive.

Many thanks

On Nov 21, 2013, at 9:22 , Maik Merten <maikmerten@googlemail.com> wrote:

> Cleary H.263 is preferable from an engineering standpoint (as is, e.g., MPEG-1 Part 2): better performance, more deployments. The central question is, however, if those can actually be implemented without some sort of licensing.
> 
> If they can: Aweseome! However, this may not be determinable without a review by people who are knowledgeable in the field of IPR, i.e., "actual lawyers". I understand that H.263 is not yet old enough to automatically be considered "safe" (and neither is MPEG-1 Part 2, although it is closer).
> 
> Best regards,
> 
> Maik
> 
> Am 20.11.2013 20:42, schrieb David Singer:
>> I think we should think hard about H.263 instead of H.261 as the third fallback.  Why?
>> 
>> http://www.itu.int/rec/T-REC-H.263/
>> 
>> 
>> 
>> 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.
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

David Singer
Multimedia and Software Standards, Apple Inc.