Re: [rtcweb] Straw Poll on Video Codec Alternatives

<Markus.Isomaki@nokia.com> Thu, 09 January 2014 12:02 UTC

Return-Path: <Markus.Isomaki@nokia.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 C25C21AE2B3 for <rtcweb@ietfa.amsl.com>; Thu, 9 Jan 2014 04:02:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.739
X-Spam-Level:
X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 07PtG4qy_33O for <rtcweb@ietfa.amsl.com>; Thu, 9 Jan 2014 04:02:31 -0800 (PST)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 54F5E1AE04B for <rtcweb@ietf.org>; Thu, 9 Jan 2014 04:02:30 -0800 (PST)
Received: from smtp.mgd.nokia.com ([65.54.30.20]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s09BttQ6014897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for <rtcweb@ietf.org>; Thu, 9 Jan 2014 13:55:56 +0200
Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.242]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.03.0158.002; Thu, 9 Jan 2014 11:55:54 +0000
From: Markus.Isomaki@nokia.com
To: rtcweb@ietf.org
Thread-Topic: [rtcweb] Straw Poll on Video Codec Alternatives
Thread-Index: AQHO9QOUTWziT+aaxkGPTlwTUjWPipp8coIQ
Date: Thu, 09 Jan 2014 11:55:54 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620A17DA28@008-AM1MPN1-043.mgdnok.nokia.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-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only;
x-titus-version: 3.5.9.3
x-headerinfofordlp:
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IuXLQ03m+qIikfGzCPlyW5FEPtqO5h4dAVXDREhvVPO/WLiY0zjJQA6JmOKtXIVwyp78A5K6lcM0WXcNqm0ABKA6CBZ5Hub1rjDuHNneVOI0JL8eiDeadCGMwgk2SSo+RFpVBuEW0q/BiayW0jHK8Y8kpSneQa55joJvjLrxkTla6fcyr7AfYigyIXle4opTznKmJ7p/PkctyiunpqzCuzTDgH6A6fBhH/FnnSLJt7uy
x-originating-ip: [10.236.6.27]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
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: Thu, 09 Jan 2014 12:02:33 -0000

Hi all,

Here's my input to the poll.

> 
> 1. All entities MUST support H.264
> a. Are you in favor of this option [Yes/No/Acceptable]:

YES.

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

> 2. All entities MUST support 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:

VP8 has not been developed and is not maintained through an open and recognized standardization process. It provides no additional technical value over H.264, which is widely used in real-time video conferencing, has wide hardware support, and is included in various other video related standards. This makes it unsuitable as mandatory to implement.

> 3. All entities MUST support both 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:

VP8 has not been developed and is not maintained through an open and recognized standardization process. It provides no additional technical value over H.264, which is widely used in real-time video conferencing, has wide hardware support, and is included in various other video related standards.

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

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

Making browsers a special case creates confusion. 

> 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 is in practice no better than "There is no MTI video codec" from interoperability perspective.

VP8 has not been developed and is not maintained through an open and recognized standardization process. It provides no additional technical value over H.264, which is widely used in real-time video conferencing, has wide hardware support, and is included in various other video related standards.

> 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 does not offer high enough quality and is not widely enough supported. 

> 7. There is no MTI video codec
>  . Are you in favor of this option [Yes/No/Acceptable]:

Acceptable. 

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

Does not accomplish interoperability but still better than some of the either-or or lower quality fallback options. In case none of the other options gets a clear consensus behind it, the WG should accept this option for now rather than spending more time arguing. Otherwise we risk having many more areas of interop problems for the next 2-3 years, after which all of the codecs now considered may be legacy from competitive services perspective anyway. 

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

H.261 does not offer high enough quality and is not widely enough supported.

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

There has been very little analysis on Theora in WebRTC context compared to other codecs being considered. 

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

VP8 has not been developed and is not maintained through an open and recognized standardization process. It provides no additional technical value over H.264, which is widely used in real-time video conferencing, has wide hardware support, and is included in various other video related standards.

H.261 does not offer high enough quality and is not widely enough supported.

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

This would achieve interoperability with reasonable minimum quality, but Option 13 would achieve the same in practice in a cleaner way. These two-out-of-three options should not be a preferred way for standards setting. 

VP8 has not been developed and is not maintained through an open and recognized standardization process. It provides no additional technical value over H.264, which is widely used in real-time video conferencing, has wide hardware support, and is included in various other video related standards.

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

Making a distinction between encoding and decoding creates confusion. Benefits are not clear enough.   

VP8 has not been developed and is not maintained through an open and recognized standardization process. It provides no additional technical value over H.264, which is widely used in real-time video conferencing, has wide hardware support, and is included in various other video related standards.

> 13. All entities MUST support H.263
>  . Are you in favor of this option [Yes/No/Acceptable]:

Acceptable. 

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

This is not the best option, but as a fallback better than H.261 or Theora. Quality would be acceptable for some use cases. H.263 is still somewhat widely available. 

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

There has been very little analysis on Theora in WebRTC context compared to other codecs being considered.

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

Making a distinction between encoding and decoding creates confusion.  

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

MJPEG is too inefficient to be useful in most situations.

Regards,
	Markus