Re: [rtcweb] Straw Poll on Video Codec Alternatives

Harald Alvestrand <harald@alvestrand.no> Tue, 17 December 2013 11:17 UTC

Return-Path: <harald@alvestrand.no>
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 8C05B1AE15D for <rtcweb@ietfa.amsl.com>; Tue, 17 Dec 2013 03:17:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level:
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538] 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 R0FpJv7Fg1Fg for <rtcweb@ietfa.amsl.com>; Tue, 17 Dec 2013 03:17:35 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [IPv6:2001:700:1:2:213:72ff:fe0b:80d8]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0381AE148 for <rtcweb@ietf.org>; Tue, 17 Dec 2013 03:17:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E81A039E182 for <rtcweb@ietf.org>; Tue, 17 Dec 2013 12:17:35 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gfknSeTNo3i for <rtcweb@ietf.org>; Tue, 17 Dec 2013 12:17:32 +0100 (CET)
Received: from [192.168.1.156] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2C41839E01E for <rtcweb@ietf.org>; Tue, 17 Dec 2013 12:17:32 +0100 (CET)
Message-ID: <52B032C8.7060000@alvestrand.no>
Date: Tue, 17 Dec 2013 12:17:28 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CA+9kkMBSpDLJBBbPxgyMUi+bi3aw3D8zpSXcAvQ4koi115QqBg@mail.gmail.com>
In-Reply-To: <CA+9kkMBSpDLJBBbPxgyMUi+bi3aw3D8zpSXcAvQ4koi115QqBg@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/mixed; boundary="------------050209040509060604020106"
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: Tue, 17 Dec 2013 11:17:41 -0000

*

Some introduction:


*

I think this is a difficult poll to answer, and even harder to analyze
responses for. There are multiple considerations here, and different
evaluations of those considerations.

My primary consideration is that we want a vibrant WebRTC ecosystem.

To reach that state, I think it is important that entities without the
ability to do licensing deals can become first class citizens of the
ecosystem - that's why a royalty free video codec is important.

I also think that having a good quality video experience in all cases is
important. A bad quality video will in many (most?) cases be better than
no video. Having a consistently good video quality is even better - but
I don't think that's as vital.

In many cases, there's doubt. Especially about IPR risk. That's hard to
quantify.

I've chosen to adopt Steve McFarlin's "weight" number on my "acceptable"
alternatives - ranging from 0.1 to 0.9 - 1.0 would be "Yes", 0.0 would
be "No".


This message is sent in HTML mail - apologies to those who see it as
broken formatting. A PDF version is attached "just in case".

*

**

 1.

    All entities MUST support H.264

     1.

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

     2.

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

         1.

            This option locks the entire ecosystem into the MPEG-LA
            licensing scheme. This is harmful for the development of the
            ecosystem.

 2.

    All entities MUST support VP8

     1.

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

     2.

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

 3.

    All entities MUST support both H.264 and VP8

     1.

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

     2.

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

         1.

            0.7. This option locks the ecosystem into the MPEG-LA
            licensing scheme, but the inclusion of a royalty-free
            alternative means that entities that do not claim
            conformance can leave out H.264, and still be members of the
            ecosystem; therefore, the harm to the ecosystem is less than
            a pure H.264 MTI.

 4.

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

     1.

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

     2.

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

         1.

            0.5 This locks the browser part of the ecosystem into the
            MPEG-LA licensing scheme. The current large browser vendors
            (Apple, Microsoft, Google, Mozilla) all have current or
            planned strategies for H.264 licensing agreements - H.264
            licensing fees are not an issue for them (including the
            Cisco/Mozilla alliance). This option allows other entities
            to claim conformance while still communicating with the
            browser ecosystem; it is therefore less objectionable than
            3, but still gets a lower score because the inconsistent
            requirements allow some cases of interoperability failure.
             It does require new browsers to find a way to live with
            H.264 licensing in order to claim conformance.

 5.

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

     1.

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

     2.

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

         1.

            This option does not give interoperability.

 6.

    All entities MUST support H.261

     1.

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

     2.

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

         1.

            While H.261 is presumably royalty free, the quality impact
            is high enough to isolate baseline codec users from the
            ecosystem.

 7.

    There is no MTI video codec

     1.

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

     2.

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

         1.

            This fails to achieve interoperability.

 8.

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

     1.

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

     2.

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

         1.

            0.3 This achieves very limited interoperability between high
            quality islands, but will allow a high quality ecosystem to
            evolve, even if islanded, and is therefore less
            objectionable than the pure "H.261 as MTI" alternative.

 9.

    All entities MUST support Theora

     1.

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

     2.

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

         1.

            The IPR and quality properties of this codec are not
            different enough from those of VP8 to make it an
            "alternative that makes a difference"; the IPR status is
            approximately equal, and the quality is definitely worse.

10.

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

     1.

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

     2.

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

         1.

            0.4 This achieves very limited interoperability between high
            quality islands, but will allow a high quality ecosystem to
            evolve. In contrast to 8, this allows entities without H.261
            to claim conformance.

11.

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

     1.

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

     2.

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

         1.

            0.2 This achieves limited interoperability at a slightly
            higher quality level than with H.261, but at the cost of
            some IPR risk. It allows a high quality ecosystem to evolve.

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

     1.

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

     2.

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

         1.

            0.4 It is not clear what the implication of this alternative is.

13.

    All entities MUST support H.263

     1.

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

     2.

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

         1.

            0.2 H.263 raises some IPR risk, but gives better quality
            interoperation than H.261.

14.

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

     1.

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

     2.

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

         1.

            0.3 This achieves limited interoperability at a reasonable
            quality, but the advantage of including Theora in the mix
            seems limited in terms of reassuring people with IPR worries.

15.

    All entities MUST support decoding using Theora.

     1.

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

     2.

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

         1.

            This alternative does not give interoperability, since it
            doesn't have an MTI encoder.

16.

    All entities MUST support Motion JPEG

     1.

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

     2.

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

         1.

            The same logic as for 6 applies. In addition, the bitrate
            shown for MJPEG is appallingly high for any reasonable quality.




*