IETF Logo Mail Archive

Re: [rtcweb] Straw Poll on Video Codec Alternatives

Leon Geyser <lgeyser@gmail.com> Thu, 09 January 2014 14:16 UTC

Return-Path: <lgeyser@gmail.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 68C1D1AE31E for <rtcweb@ietfa.amsl.com>; Thu, 9 Jan 2014 06:16:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 DfeV_C_0WOER for <rtcweb@ietfa.amsl.com>; Thu, 9 Jan 2014 06:16:16 -0800 (PST)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 383E51AE309 for <rtcweb@ietf.org>; Thu, 9 Jan 2014 06:16:15 -0800 (PST)
Received: by mail-lb0-f182.google.com with SMTP id l4so2407562lbv.27 for <rtcweb@ietf.org>; Thu, 09 Jan 2014 06:16:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PShY1Y/DFuU+9t3WgD5JAmcOUyT/zx7whI9rFuPTdHs=; b=YVEOabUfSZcf7SJhl20WDRk+GGaFbE2NK8dY0YUikmK6qdtcqoXvbzmn/SP+vcjccn DfOLvC+wzdNbB5Xsm7gUO01i5SeN4nETdnG+6HTXR6UYUY6DLgDN4EKcxdrpqLV2yDbj 5lJdvXoqGH8+ctYZxovojRa/XoWY/lnWrfz0+8i1orJNAJpqOimVVjjiwgjhTs0wL/zB EiWM8JCNG+fnrkW7WjVIRSrQM6OxuVCcXRpDUfeiF+uOFUJ5BsR1LLJYEp/F4fRRM8Fu mTKuGQeYyu84urw8hM/ysWTxB/0TkFn+P3sFkPEZz5I3Gu/BbCiA86zT7blOxsWtZL0a Muvw==
MIME-Version: 1.0
X-Received: by 10.112.12.106 with SMTP id x10mr1246769lbb.61.1389276964857; Thu, 09 Jan 2014 06:16:04 -0800 (PST)
Received: by 10.114.67.242 with HTTP; Thu, 9 Jan 2014 06:16:04 -0800 (PST)
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A17DA28@008-AM1MPN1-043.mgdnok.nokia.com>
References: <CA+9kkMBSpDLJBBbPxgyMUi+bi3aw3D8zpSXcAvQ4koi115QqBg@mail.gmail.com> <E44893DD4E290745BB608EB23FDDB7620A17DA28@008-AM1MPN1-043.mgdnok.nokia.com>
Date: Thu, 09 Jan 2014 16:16:04 +0200
Message-ID: <CAGgHUiS2XxXH802WdBC++89+tAiCrf7HQCO3YFQ=QjvsFzJ64A@mail.gmail.com>
From: Leon Geyser <lgeyser@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c3f154fc2c8804ef8a3f05"
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 14:16:22 -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:
      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]: NO
      2.

      Do you have any objections to this option, if so please summarize
      them: Too strict requirements
      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: Too strict requirements
      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: Won't help interoperability.
      6.

   All entities MUST support 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:
      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: Won't help 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:
      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:
      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:
      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:
      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:
      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:
      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:
      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: Won't help interoperability.
      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: Very bandwidth intensive.



On 9 January 2014 13:55, <Markus.Isomaki@nokia.com> wrote:

> 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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

v2.23.0 | Report a Bug | By Email