Re: [rtcweb] Straw Poll on Video Codec Alternatives

Jan-Ivar Bruaroey <jib@mozilla.com> Sat, 11 January 2014 20:16 UTC

Return-Path: <jib@mozilla.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 6CAE71AE020 for <rtcweb@ietfa.amsl.com>; Sat, 11 Jan 2014 12:16:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.815
X-Spam-Level:
X-Spam-Status: No, score=-3.815 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 cqrN_0BlbKla for <rtcweb@ietfa.amsl.com>; Sat, 11 Jan 2014 12:16:39 -0800 (PST)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 64EA81ADFF3 for <rtcweb@ietf.org>; Sat, 11 Jan 2014 12:16:39 -0800 (PST)
Received: from [192.168.1.112] (c-68-80-94-125.hsd1.pa.comcast.net [68.80.94.125]) (Authenticated sender: jbruaroey@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 0115FF249F; Sat, 11 Jan 2014 12:16:27 -0800 (PST)
Message-ID: <52D1A69B.7020303@mozilla.com>
Date: Sat, 11 Jan 2014 15:16:27 -0500
From: Jan-Ivar Bruaroey <jib@mozilla.com>
Organization: Mozilla
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
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>
References: <CA+9kkMBSpDLJBBbPxgyMUi+bi3aw3D8zpSXcAvQ4koi115QqBg@mail.gmail.com>
In-Reply-To: <CA+9kkMBSpDLJBBbPxgyMUi+bi3aw3D8zpSXcAvQ4koi115QqBg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------040806000309090305020004"
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: Sat, 11 Jan 2014 20:16:42 -0000

 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:
        - Does not achieve interoperability, because it is not FOSS.
        - Still license encumbered. Even with decoder binary gift, this
        is still the blue pill.
        - Encoding is key to interoperability.

 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:
        - Risk. It might be prudent to wait a bit for Nokia claim to
        unfold (or fold).
        - Still best option until Daala.

 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:
        - A compromise that marginalizes FOSS (license-free gets
        noncomply-labeled).

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

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - What's a non-browser? Weakness of tying limits to names.
        - Not interoperable.

 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:
        - Not interoperable.

 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:
        - I'm unfamiliar with H.261, but claims of low quality makes me
        uninterested.

 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:
        - Not interoperable.

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

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - Interoperably indistinguishable from #6 to me.

 9.

    All entities MUST support 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:
        - Seems like a less famous yet-to-be-sued VP8.

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

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - I'm unfamiliar with H.261, but claims of low quality make me
        uninterested.

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

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - I'm unfamiliar with H.263, but claims of IPR make me
        uninterested + seems old.

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

     2.

        Do you have any objections to this option, if so please
        summarize them:
        - Trojan!
        - At first seems like pragmatic result of #3 (why encode both
        when unnecessary)
        - But if few devices encode VP8 then even non-compliers cannot
        ignore licensing.
        - Hence not interoperable by my definition.

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:
        - I'm unfamiliar with H.263, but claims of IPR make me
        uninterested + seems old.

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:
        - Theora seems like a less famous yet-to-be-sued VP8.

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:
        - Trojan! Incoming call, hello?
        - If few devices encode Theora then even non-compliers cannot
        ignore licensing.
        - Theora seems like a less famous yet-to-be-sued VP8.

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:
        - Too bandwidth demanding.


Clarification: Why I call out "Trojan" in two answers above: Consistent 
with my other answers, a key to interoperability in my view is accepting 
(even non-compliant) license-unencumbered nodes in a network. I.e. Both 
sides of a call negotiation must agree to either of multiple formats, or 
"both" isn't truly both. - Thus, any question that separates encoding 
from decoding I call a Trojan, because incoming calls rule. I.e. If the 
other side requires a license, I need a license. True, I avoid an 
encoding license, so the distinction has merit, but beware of the 
licensing consequence when answering.

.: Jan-Ivar :.