Re: [rtcweb] Straw Poll on Video Codec Alternatives

"Cavigioli, Chris" <chris.cavigioli@intel.com> Mon, 13 January 2014 11:03 UTC

Return-Path: <chris.cavigioli@intel.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 2CDEE1AE109 for <rtcweb@ietfa.amsl.com>; Mon, 13 Jan 2014 03:03:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.438
X-Spam-Level:
X-Spam-Status: No, score=-7.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 voIKnTjYxHDU for <rtcweb@ietfa.amsl.com>; Mon, 13 Jan 2014 03:03:08 -0800 (PST)
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id AEE091AE05C for <rtcweb@ietf.org>; Mon, 13 Jan 2014 03:03:08 -0800 (PST)
Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 13 Jan 2014 02:58:56 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="4.95,652,1384329600"; d="scan'208,217"; a="465772412"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by orsmga002.jf.intel.com with ESMTP; 13 Jan 2014 03:02:55 -0800
Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 13 Jan 2014 03:02:53 -0800
Received: from FMSMSX110.amr.corp.intel.com ([169.254.1.185]) by FMSMSX155.amr.corp.intel.com ([169.254.5.40]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 03:02:53 -0800
From: "Cavigioli, Chris" <chris.cavigioli@intel.com>
To: Ted Hardie <ted.ietf@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, Richard Barnes <rlb@ipv.sx>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Cullen Jennings <fluffy@cisco.com>
Thread-Topic: [rtcweb] Straw Poll on Video Codec Alternatives
Thread-Index: AQHO9QOYx3vvGbPBK0KeFG6EHe2AAJqCp26g
Date: Mon, 13 Jan 2014 11:02:52 +0000
Message-ID: <E36D1A4AE0B6AA4091F1728D584A6AD238213AD5@FMSMSX110.amr.corp.intel.com>
References: <CA+9kkMBSpDLJBBbPxgyMUi+bi3aw3D8zpSXcAvQ4koi115QqBg@mail.gmail.com>
In-Reply-To: <CA+9kkMBSpDLJBBbPxgyMUi+bi3aw3D8zpSXcAvQ4koi115QqBg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.200.108]
Content-Type: multipart/alternative; boundary="_000_E36D1A4AE0B6AA4091F1728D584A6AD238213AD5FMSMSX110amrcor_"
MIME-Version: 1.0
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: Mon, 13 Jan 2014 11:03:13 -0000

Here is my straw below...

Chris Cavigioli
Intel Corp, Marketing & Product Planning, Graphics/Multimedia, Mobile and Communications Group (MCG)
+1 (415) 254-4545 mobile
+1 (408) 653-8348 desk
+1 (408) 884-2400 fax
This e-mail may contain confidential and privileged material for the sole use of the intended recipient(s).  Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.


From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Monday, December 09, 2013 9:25 AM
To: rtcweb@ietf.org; Gonzalo Camarillo; Richard Barnes; Magnus Westerlund; Cullen Jennings
Subject: [rtcweb] Straw Poll on Video Codec Alternatives

*SNIP*

1.    All entities MUST support H.264

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

NO, incomplete.  This is necessary, but not sufficient.

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

One codec isn't enough



2.    All entities MUST support VP8

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

NO, incomplete.  This is necessary, but not sufficient.

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

One codec isn't enough



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

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

YES, there is no commercially-viable alternative.  Transcoding must be avoided at all costs if we intend to provide a good end-user experience.

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

Given the passion behind each camp, we must deploy both.

Android, iOS and Windows commercial logo requirements mandate the presence of H.264 encode and decode anyhow.   No device will be missing H.264 ... all Android devices have H.264 and VP8 (both).



4.    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, this implies that browsers will be able to talk to each other, but some other entities will not .. unless they have a browser on board.  For commercial success, browsers must tap into native hardware codecs.

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

#3 is a better option



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

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

NO.

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

This forces a hodge-podge of transcoding and that won't work.



6.    All entities MUST support H.261

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

NO

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

H.261 is obsolete, cannot handle higher resolutions and contributes to the data tsunami in our networks.   That is exactly the reason we're moving to H.265 and VP9 ... to reduce bandwidth, increase quality ... let's not go backwards.



7.    There is no MTI video codec

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

NO

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

The market will fragment into camps and nobody wins.  WebRTC becomes a passing "flash in the pan" because systems don't work with each other.



8.    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

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

Wasteful.  H.261 must be categorically avoided because it wastes transmission bandwidth to communicate mediocre quality.



9.    All entities MUST support Theora

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

NO

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

Wasteful.  Rare codec - not widely available in hardware - and obsolete technology (same argument against H.261 above)



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

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

NO

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

Wasteful.  H.261 must be categorically avoided because it wastes transmission bandwidth to communicate mediocre quality.  Transcoding issues.



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

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

NO

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

Wasteful.  H.263 must be categorically avoided because it wastes transmission bandwidth to communicate mediocre quality.  Transcoding issues.



12.  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

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

So complex that this will be hard to explain ... and doesn't solve the transcoding issue

13.  All entities MUST support H.263

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

NO

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

Wasteful.  H.263 must be categorically avoided because it wastes transmission bandwidth to communicate mediocre quality.



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

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

NO

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

Wasteful.  Theora must be categorically avoided because it wastes transmission bandwidth to communicate mediocre quality.  Transcoding issues.



15.  All entities MUST support decoding using Theora.

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

NO

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

Wasteful.  Theora must be categorically avoided because it wastes transmission bandwidth to communicate mediocre quality.  Transcoding issues.



16.  All entities MUST support Motion JPEG

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

NO

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

Wasteful.  Motion JPEG must be categorically avoided because it wastes transmission bandwidth to communicate mediocre quality.  Transcoding issues.


H.264 is a reference to the proposal in https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/<https://datatracker.ietf.org/doc/draft-burman-rtcweb-h264-proposal/>


VP8 is a reference to the proposal in https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/<https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-vp8/>


Theora is a reference to Xiph.org Theora Specification from March 16, 2011 (http://www.xiph.org/theora/doc/Theora_I_spec.pdf)


H.263 is a reference to profile 0 level 70 defined in annex X of ITU-T rec H.263 (http://www.itu.int/rec/T-REC-H.263/)


H.261 is a reference to http://tools.ietf.org/html/rfc4587


Motion JPEG is a reference to http://tools.ietf.org/html/rfc2435


Thanks,


The Chairs