Re: [rtcweb] Straw Poll on Video Codec Alternatives

Lorenzo Miniero <lorenzo@meetecho.com> Wed, 11 December 2013 11:42 UTC

Return-Path: <lorenzo@meetecho.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 01A241AC4AB for <rtcweb@ietfa.amsl.com>; Wed, 11 Dec 2013 03:42:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.02
X-Spam-Level:
X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 DBVZqGSqotO3 for <rtcweb@ietfa.amsl.com>; Wed, 11 Dec 2013 03:42:26 -0800 (PST)
Received: from smtpdg3.aruba.it (smtpdg1.aruba.it [62.149.158.231]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4DE1A1F7C for <rtcweb@ietf.org>; Wed, 11 Dec 2013 03:42:25 -0800 (PST)
Received: from lminiero ([82.49.99.166]) by smtpcmd01.ad.aruba.it with bizsmtp id 0BiE1n00t3bPhp601BiEFh; Wed, 11 Dec 2013 12:42:16 +0100
Date: Wed, 11 Dec 2013 12:42:15 +0100
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Ted Hardie <ted.ietf@gmail.com>
Message-ID: <20131211124215.1b698575@lminiero>
In-Reply-To: <CA+9kkMBSpDLJBBbPxgyMUi+bi3aw3D8zpSXcAvQ4koi115QqBg@mail.gmail.com>
References: <CA+9kkMBSpDLJBBbPxgyMUi+bi3aw3D8zpSXcAvQ4koi115QqBg@mail.gmail.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, Cullen Jennings <fluffy@cisco.com>
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: Wed, 11 Dec 2013 11:42:28 -0000

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

No.

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


I have serious concerns on the licensing burdens that come with H.264.
Anyone that does not already have a license and can't get one would be
unable to support video. The Cisco module would not solve the issue, as
it would still require a separate license for parts of the
specification that are not covered, and cannot be safely depended on in
the long run. Besides, it couldn't be just linked to, but one would
need to download it on the fly for every installation.


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

Yes.

> 
>       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]:
>       2.


No.


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


I have serious concerns on the licensing burdens that come with H.264.
Anyone that does not already have a license and can't get one would be
unable to support video. The Cisco module would not solve the issue, as
it would still require a separate license for parts of the
specification that are not covered, and cannot be safely depended on in
the long run. Besides, it couldn't be just linked to, but one would
need to download it on the fly for every installation.


>       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]:
>       2.


Acceptable.


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


While it may be acceptable for me, as it would allow me NOT to
implement H.264, I must say it's closer to a NO than to an ACCEPTABLE
if I start thinking about browser makers outside of the "Fantastic
Fours". I have serious concerns on the licensing burdens that come with
H.264. Anyone that does not already have a license and can't get one
would be unable to support video, and this would include most of the
open source browsers, especially those in Fedora and Debian. The Cisco
module would not solve the issue, as it would still require a separate
license for parts of the specification that are not covered, and cannot
be safely depended on in the long run. Besides, it couldn't be just
linked to, but one would need to download it on the fly for every
installation.


>       5.
> 
>    All entities MUST support at least one of H.264 and VP8
>    1.
> 
>       Are you in favor of this option [Yes/No/Acceptable]:
>       2.


No.


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


Implementations wouldn't be interoperable.


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


Acceptable.


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


Quality wouldn't be great, but it's not a dealbreaker: some video is
better than no video.


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


No.


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


We do need a MTI video. I'd only be okay with such a consensus if it
meant that we're giving up now, until we manage to find a suitable
candidate later on.


>       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]:
>       2.


Acceptable.


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


Considering how divided the group is on those two codecs, we'd still be
stuck with low quality video for most of the calls.


>       9.
> 
>    All entities MUST support Theora
>    1.
> 
>       Are you in favor of this option [Yes/No/Acceptable]:
>       2.


Yes.


> 
>       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]:
>       2.


Acceptable.


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


Considering how divided the group is on H.264 and VP8, we'd still be
stuck with low quality video for most of the calls.


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


H.263 is much better than H.261, which means decent quality, but
apparently there still are licensing burdens to it, which makes it
better than H.264 but not that much.

Considering how divided the group is on H.264 and VP8, we'd still be
stuck with lower quality video for most of the calls.


>       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]:
>       2.


No.


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


I have serious concerns on the licensing burdens that come with H.264.
Anyone that does not already have a license and can't get one would be
unable to support video. The Cisco module would not solve the issue, as
it would still require a separate license for parts of the
specification that are not covered, and cannot be safely depended on in
the long run. Besides, it couldn't be just linked to, but one would
need to download it on the fly for every installation.


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


Acceptable.


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


H.263 is much better than H.261, which means decent quality, but
apparently there still are licensing burdens to it, which makes it
better than H.264 but not that much.


>       14.
> 
>    All entities MUST implement at least two of {VP8, H.264, Theora}
>    1.
> 
>       Are you in favor of this option [Yes/No/Acceptable]:
>       2.


Yes.


> 
>       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]:
>       2.


No.


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


I said YES to Theora as the MTI, but this option makes no sense, since
it doesn't mandate anything on the encoder side.


>       16.
> 
>    All entities MUST support Motion JPEG
>    1.
> 
>       Are you in favor of this option [Yes/No/Acceptable]:
>       2.


No.


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

It's bandwidth consumption for reasonable resolutions/framerates is so
overkill I really can't see it working anywhere out of a LAN.


Lorenzo