Re: [rtcweb] Video codec selection - way forward

Leon Geyser <lgeyser@gmail.com> Thu, 21 November 2013 19:33 UTC

Return-Path: <lgeyser@gmail.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 3B3CC1AE074 for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 11:33:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 NFthkveTsoMt for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 11:33:04 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9691AE19E for <rtcweb@ietf.org>; Thu, 21 Nov 2013 11:32:54 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id eh20so174660lab.4 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 11:32:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JMtnvKR5kxjV/7ELQjKXo4r48JBZ0zfz4lnv5g6uFxI=; b=UTNqQfKy1641xM3lUsip/TAlxX/rOHgBSMrsKSH6eNt9tumvSg8v2Heid6eh54sUQZ wY0wdmGfdRJNN68vw1hB8yOyva+FmoS5cZG+wnDEK0WPJHLb4ofh1E9c0GErrvopPSQx yBsA0Ek9Z7CfrbrtCvptVH/HDn8XDKZ9abFXB6mgErv3U7yFSLq0iQicPQlgef5wo+fa 4+rDEdxjojC6u1I9JKDC4nn6pwHbZTPGlR1/ir9xblr4dukMKeRP4m3rk4CnynZxc8cH cISyyG+KRLJPcgrvOGmL54lE4SLNExHOE9VLPrdQRMd5yW+T3mHd7l6IDh3U+AvjMOI3 MsxQ==
MIME-Version: 1.0
X-Received: by 10.152.4.230 with SMTP id n6mr6085092lan.1.1385062367628; Thu, 21 Nov 2013 11:32:47 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Thu, 21 Nov 2013 11:32:47 -0800 (PST)
In-Reply-To: <528E5E89.8040706@googlemail.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>
Date: Thu, 21 Nov 2013 21:32:47 +0200
Message-ID: <CAGgHUiTDm=+Tztvp-hGMLOfCr1bXNwRLnb8wu2Kq=pxvhK9Pzg@mail.gmail.com>
From: Leon Geyser <lgeyser@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary=089e013d1e8e6a124304ebb4f66e
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:33:07 -0000

+1


On 21 November 2013 21:27, Maik Merten <maikmerten@googlemail.com>; 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
>