Re: [rtcweb] H.264 CBP (was: Video codec selection - way forward)

Eric Rescorla <ekr@rtfm.com> Sat, 23 November 2013 15:01 UTC

Return-Path: <ekr@rtfm.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 D20B71AE13C for <rtcweb@ietfa.amsl.com>; Sat, 23 Nov 2013 07:01:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 yM0lBywtmNOd for <rtcweb@ietfa.amsl.com>; Sat, 23 Nov 2013 07:01:08 -0800 (PST)
Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 155F21AE139 for <rtcweb@ietf.org>; Sat, 23 Nov 2013 07:01:07 -0800 (PST)
Received: by mail-we0-f179.google.com with SMTP id q59so2209532wes.24 for <rtcweb@ietf.org>; Sat, 23 Nov 2013 07:01:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UC5+zgc4tACZMy6Un0QBIRSAFyHEDFDgrnHIoiMORTA=; b=ZFndGqVKbPDuOyR8YqUZTYbzqdXhjtO1rm9yVWDe/3/0nuP+oQP5vpaxpIOfP17Dfg RA6+VRuG1O54B4VROa45SjH4Ylji6bhtS5u1RkvTVAyOnLdkp1cg9wWCsbg5jT3lyhqv C6osc8IHVPTjRp0cKunvXEtMDTzU8OR+Mc3QvMr2jJYN9u8M3oVZCE+8F66cGIUlfw49 HWK5dC9dhqewVU0QT0sI2wmBb3sv/t4iN/+izVWUqCBCl6QjkrMCxFiCqmiqliqFbfFD O79Gwsu4MBAQ1djPdLPOvuFMHUB8NRf28TsUbFfZBvdi67/aGsxXiA+AsjtU6kPa0L/y M06A==
X-Gm-Message-State: ALoCoQlnjpX8jWWY97QNQ6ugGndO0M7BsamKNxxNiSPgAK8cB/ZkVa16oYdSss7rRZHHnhViXjMd
X-Received: by 10.194.93.3 with SMTP id cq3mr15196635wjb.26.1385218860229; Sat, 23 Nov 2013 07:01:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Sat, 23 Nov 2013 07:00:20 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <52905990.8070207@bbs.darktech.org>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 23 Nov 2013 07:00:20 -0800
Message-ID: <CABcZeBMxnPsZnYOferm-es6PGghH3RcwfU7-m5J=ZW4MUa-a2g@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Content-Type: multipart/alternative; boundary=047d7bb0482219bb0504ebd96625
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Sat, 23 Nov 2013 15:01:11 -0000

It was CBP.

I think there's some debate about the relative performance characteristics,
with
general agreement that H.264 CBP and VP8 are in the same neighborhood
and also general agreement that performance is not the important factor.

-Ekr



On Fri, Nov 22, 2013 at 11:30 PM, cowwoc <cowwoc@bbs.darktech.org>; wrote:

>
> +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
>