Re: [rtcweb] Straw Poll on Video Codec Alternatives

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Wed, 11 December 2013 19:45 UTC

Return-Path: <keith.drage@alcatel-lucent.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 6EF051AE1A3 for <rtcweb@ietfa.amsl.com>; Wed, 11 Dec 2013 11:45:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 IRe4tccWSQ5T for <rtcweb@ietfa.amsl.com>; Wed, 11 Dec 2013 11:45:00 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC321AE1DE for <rtcweb@ietf.org>; Wed, 11 Dec 2013 11:45:00 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rBBJimtQ008704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Dec 2013 13:44:49 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rBBJileb030998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 20:44:48 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 11 Dec 2013 20:44:47 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Roman Shpount <roman@telurix.com>, Ted Hardie <ted.ietf@gmail.com>
Thread-Topic: [rtcweb] Straw Poll on Video Codec Alternatives
Thread-Index: AQHO9QO2ubcd8jULd0mZjw0Bzj7W3JpPPwsAgAAlCtA=
Date: Wed, 11 Dec 2013 19:44:46 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0F6AF2@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <CA+9kkMBSpDLJBBbPxgyMUi+bi3aw3D8zpSXcAvQ4koi115QqBg@mail.gmail.com> <CAD5OKxuq6C8Gz7oUnvh0-GRRo=k3qwq4dd0zDO3Fg4G-hzfQYw@mail.gmail.com>
In-Reply-To: <CAD5OKxuq6C8Gz7oUnvh0-GRRo=k3qwq4dd0zDO3Fg4G-hzfQYw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0F6AF2FR712WXCHMBA11zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: Cullen Jennings <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Straw Poll on Video Codec Alternatives
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: Wed, 11 Dec 2013 19:45:04 -0000

I was of the understanding that the statement:

"Encoder is not specified by the standard and there are no obligations for MPEG members to declare anything, so you are more then likely exposed to addition IPR risks when implementing a good encoder. "

applied to pretty much every videocodec under the sum, and was not specific to H.264.

The general method of specifying videocodecs is to specify the decoder only. I'd certainly thought seen a statement of that sort previously on the list; have I understood it wrong?

Essentially if you do anything innovative that is not covered by the standard, you stand a chance of contravening IPR of someone who thought of it before you did and then patented it.

Keith Drage



________________________________
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 11 December 2013 18:15
To: Ted Hardie
Cc: rtcweb@ietf.org; Cullen Jennings
Subject: Re: [rtcweb] Straw Poll on Video Codec Alternatives


  1.  All entities MUST support H.264

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Not acceptable to anybody who is not already using H.264 due to its licensing schema. To license H.264 you need to make a deal with MPEG-LA. After this you need to make a deal with Nokia and other people not part of MPEG-LA. As a result you are going to get rights to decoder. Encoder is not specified by the standard and there are no obligations for MPEG members to declare anything, so you are more then likely exposed to addition IPR risks when implementing a good encoder. You cannot afford not to license since if you are real business (ie one generating money or taking investor money) you cannot afford such business risk. Even if you are planning to distribute less then 100K codec instances you will still need a license since MPEG-LA terms are ambiguous enough that you would want to have a contact that clarifies what exactly you can do. After you jumped through all these licensing hoops you are still exposed to all the potential undisclosed IPR with your only hope that patent trolls will go after the bigger guys first (from my experience they will not).


Using Cisco binary codec is also unacceptable unless you are doing something basic since it limits what you can do by requiring to use their pre-built binary. I am building conferencing servers, so I expect that I will need to optimize the codec for my needs. I will need to build custom optimized VP8 to H.264 transcoder. I will need to build custom H.264 bitrate adaptation (ie H.264 to H.264 transcoder to adjust bitrate). All of this is not an option with Cisco binary.


  1.  All entities MUST support VP8

     *   Are you in favor of this option [Yes/No/Acceptable]:

Acceptable

     *   Do you have any objections to this option, if so please summarize them:

It is acceptable since implementation is provided by Google under reasonable license terms. It is not a strong yes since VP8 is not formally defined by any standard's body.


  1.  All entities MUST support both H.264 and VP8

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:


Not acceptable due to H.264 licensing. Creates additional burden on development and support


  1.  Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:


Not acceptable due to H.264 licensing. Creates additional burden on development and support


  1.  All entities MUST support at least one of H.264 and VP8

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Does not result in MTI.


  1.  All entities MUST support H.261

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Quality is not acceptable for modern video communications


  1.  There is no MTI video codec

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Video is essential to WebRTC


  1.  All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Essentially makes H.261 an MTI, but its quality is not acceptable for modern video communications


  1.  All entities MUST support Theora

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

No better then VP8 since it never went through a standard body, but much worse quality wise.


  1.  All entities MUST implement at least two of {VP8, H.264, H.261}

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:


Additional burden on implementation and support with a strong option of using H.261 for call which is not acceptable due to quality.


  1.  All entities MUST implement at least two of {VP8, H.264, H.263}

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:


Additional burden on implementation and support with a strong option of using H.263 for call which is not acceptable due to quality and additional IPR licensing requirements


  1.  All entities MUST support decoding using both H.264 and VP8, and MUST support encoding using at least one of H.264 or VP8

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Decoding H.264 has exactly the same licensing issues as encoding it, so it is as unacceptable for me as simple H.264 support


  1.  All entities MUST support H.263

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Quality is much worse then H.264 and VP8. Still requires IPR licensing


  1.  All entities MUST implement at least two of {VP8, H.264, Theora}

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:


Additional support burden. Theora can be used for communications but its quality is much worse then VP8 or H.264


  1.  All entities MUST support decoding using Theora.

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Does not create an MTI


  1.  All entities MUST support Motion JPEG

     *   Are you in favor of this option [Yes/No/Acceptable]:

No

     *   Do you have any objections to this option, if so please summarize them:

Resulting quality would be so bad it would be almost unusable.

______________

Roman Shpount