Re: [rtcweb] H.264 CBP (was: Video codec selection - way forward)
Stefan Slivinski <sslivinski@lifesize.com> Sun, 24 November 2013 04:43 UTC
Return-Path: <sslivinski@lifesize.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 B04241AD948 for <rtcweb@ietfa.amsl.com>; Sat, 23 Nov 2013 20:43:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 2RjqTYZnWM5G for <rtcweb@ietfa.amsl.com>; Sat, 23 Nov 2013 20:43:33 -0800 (PST)
Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with SMTP id 0209C1AE3B6 for <rtcweb@ietf.org>; Sat, 23 Nov 2013 20:43:32 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUpGD7NezZEfehp54VEntkpark7K1jAS8@postini.com; Sat, 23 Nov 2013 20:43:25 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Sat, 23 Nov 2013 22:39:34 -0600
From: Stefan Slivinski <sslivinski@lifesize.com>
To: cowwoc <cowwoc@bbs.darktech.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Sat, 23 Nov 2013 22:39:32 -0600
Thread-Topic: [rtcweb] H.264 CBP (was: Video codec selection - way forward)
Thread-Index: Ac7oHffBBXway9eJR8qi0y95/5KZpgAsAx+A
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E677B@ausmsex00.austin.kmvtechnologies.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> <2B458AB3-A219-4F3C-B393-8F0969C2CC08@apple.com> <528E5E89.8040706@googlemail.com> <52905990.8070207@bbs.darktech.org>
In-Reply-To: <52905990.8070207@bbs.darktech.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] H.264 CBP (was: 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: Sun, 24 Nov 2013 04:43:35 -0000
I don't know which profile was under discussion but constrained baseline profile (CBP) removes tools like FMO and ASO from baseline profile which have been unpopular because of their complexity and quality tradeoffs. In realtime video communications High profile typically just adds cabac and 8x8 transform which in general reduce the bitrate for video communications type content (talking heads, no high action movies) by about 20-25% as compared to CBP. Cabac in particular adds a fair amount of complexity but most modern hardware acceleration supports it meaning there is no performance hit to the CPU. -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of cowwoc Sent: Friday, November 22, 2013 11:30 PM To: rtcweb@ietf.org Subject: [rtcweb] H.264 CBP (was: Video codec selection - way forward) +1 In the original VP8 vs H.264 discussion, what H.264 profile was under discussion? If it was not H.264 CBP, do we need to revisit the comparison? Do the two profiles use the same bandwidth, CPU and produce the same quality? Thanks, Gili On 21/11/2013 2:27 PM, Maik Merten wrote: > Btw, should any occurrence of "H.264" in the current list of options > be substituted with "H.264 CBP"? Perhaps it is best to be very clear > on the profile which should be implemented. > > Thanks, > > Maik > > Am 21.11.2013 20:20, schrieb David Singer: >> 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. >> >> _______________________________________________ >> 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 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] Video codec selection - way forward Gonzalo Camarillo
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Stephan Wenger
- Re: [rtcweb] Video codec selection - way forward Jonathan Rosenberg
- Re: [rtcweb] Video codec selection - way forward Bernard Aboba
- Re: [rtcweb] Video codec selection - way forward cb.list6
- Re: [rtcweb] Video codec selection - way forward Robin Raymond
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Gustavo Garcia
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Gonzalo Camarillo
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Gonzalo Camarillo
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Jeremy Fuller
- Re: [rtcweb] Video codec selection - way forward Jonathan Rosenberg
- Re: [rtcweb] Video codec selection - way forward Gili
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Bjoern Hoehrmann
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Harald Alvestrand
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Basil Mohamed Gohar
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Thomas Reisinger
- Re: [rtcweb] Video codec selection - way forward Basil Mohamed Gohar
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Thomas Reisinger
- Re: [rtcweb] Video codec selection - way forward Ross Finlayson
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Thomas Reisinger
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- [rtcweb] H.263 licensing situation Stephan Wenger
- Re: [rtcweb] Video codec selection - way forward cowwoc
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- [rtcweb] Reference implementation of software cod… cowwoc
- Re: [rtcweb] Reference implementation of software… cowwoc
- Re: [rtcweb] Reference implementation of software… Maik Merten
- Re: [rtcweb] Video codec selection - way forward DRAGE, Keith (Keith)
- Re: [rtcweb] Video codec selection - way forward DRAGE, Keith (Keith)
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Bernard Aboba
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Gili
- Re: [rtcweb] Video codec selection - way forward Bernard Aboba
- Re: [rtcweb] Video codec selection - way forward Gili
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Bernard Aboba
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Magnus Westerlund
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Adam Roach
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Cullen Jennings
- Re: [rtcweb] Video codec selection - way forward David Singer
- Re: [rtcweb] Video codec selection - way forward Cullen Jennings
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Maik Merten
- Re: [rtcweb] Video codec selection - way forward Leon Geyser
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Martin Thomson
- Re: [rtcweb] Video codec selection - way forward Steve Kann
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Monty Montgomery
- Re: [rtcweb] Video codec selection - way forward Matt Fredrickson
- Re: [rtcweb] Video codec selection - way forward Eric Rescorla
- Re: [rtcweb] Video codec selection - way forward Martin Thomson
- Re: [rtcweb] Video codec selection - way forward Enrico Marocco
- Re: [rtcweb] Video codec selection - way forward Cullen Jennings
- Re: [rtcweb] Video codec selection - way forward Matthew Kaufman
- [rtcweb] cisco binary on ec2 Cullen Jennings
- Re: [rtcweb] cisco binary on ec2 Matt Fredrickson
- Re: [rtcweb] cisco binary on ec2 Lorenzo Miniero
- Re: [rtcweb] Video codec selection - way forward cb.list6
- [rtcweb] H.264 CBP (was: Video codec selection - … cowwoc
- Re: [rtcweb] H.264 CBP (was: Video codec selectio… Eric Rescorla
- Re: [rtcweb] H.264 CBP (was: Video codec selectio… Stefan Slivinski
- Re: [rtcweb] cisco binary on ec2 Cullen Jennings
- Re: [rtcweb] cisco binary on ec2 cowwoc
- Re: [rtcweb] cisco binary on ec2 Roman Shpount