Re: [rtcweb] Straw Poll on Video Codec Alternatives

Engel Nyst <engel.nyst@gmail.com> Wed, 11 December 2013 21:32 UTC

Return-Path: <engel.nyst@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 82BA21AE00C for <rtcweb@ietfa.amsl.com>; Wed, 11 Dec 2013 13:32:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 Wt6jwFRqlzp2 for <rtcweb@ietfa.amsl.com>; Wed, 11 Dec 2013 13:32:40 -0800 (PST)
Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 475A71AE060 for <rtcweb@ietf.org>; Wed, 11 Dec 2013 13:32:40 -0800 (PST)
Received: by mail-ee0-f54.google.com with SMTP id e51so2939595eek.41 for <rtcweb@ietf.org>; Wed, 11 Dec 2013 13:31:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=LVLXcpF0TXTRLq78bGRa41yDBfWgEcRD/yOT3RaYIIE=; b=lCkg6MrR68huBqlZSuj26NMP4NUGN6xPUD7a3m9OfsFT7onpy+zACAfxoTi1hMOjI3 vzNWGkgOlkXMHsmpCEhvLu3cVoruZKG4E/CwjG9/A7/vaWH7f6CIbnQ2C5D7f3rlTPvv YU1UqSiBrDVYNK3Iv0OuarqokeWYQEDW1+fUBV39sfMKrYQxSDsDqznt0HF9HelaatX/ S9mHezz+oxEq0WDEXjXJkw5snQhwtQD5KeUx/g7CHyZOq77tXA/PznTVwEkwIBn5ZB8c 3Tn2PJLnWrAky5NZaM871dJ8KyMxgnMIPwqG7Ro392T9uD9Hvl80wkc8jih8HsCYGP3Q PW1A==
X-Received: by 10.14.204.135 with SMTP id h7mr4075226eeo.104.1386797519170; Wed, 11 Dec 2013 13:31:59 -0800 (PST)
Received: from [192.168.1.33] ([109.100.150.49]) by mx.google.com with ESMTPSA id 1sm58001678eeg.4.2013.12.11.13.31.57 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 13:31:58 -0800 (PST)
Message-ID: <52A8D97A.1000103@gmail.com>
Date: Wed, 11 Dec 2013 23:30:34 +0200
From: Engel Nyst <engel.nyst@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131104 Icedove/17.0.10
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CA+9kkMBSpDLJBBbPxgyMUi+bi3aw3D8zpSXcAvQ4koi115QqBg@mail.gmail.com>
In-Reply-To: <CA+9kkMBSpDLJBBbPxgyMUi+bi3aw3D8zpSXcAvQ4koi115QqBg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 21:32:42 -0000

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

No.

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

MPEG-LA owns patents /and/ uses them aggressively to stifle development 
of open standards. I do not see this as remotely appropriate for 
*Mandatory*-to-Implement.
I am concerned about the fake appearances Cisco is giving. The code 
"appears" to be BSD-licensed, and github repository gives no indication 
to well intended people that in reality it's not. Forking the repository 
and building a derivative release *already runs afoul* of MPEG-LA 
restrictions and exposes people to uncertainty and being chased for 
fees, when it's a natural thing to do.
Misleading people that an implementation is open source when it's not is 
an unacceptable action in my book, under any shape or form; and I will 
keep short here as to other practical scenarios and issues that it brings.

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

Yes.

Practical results achieve interoperability. Quality. On the right path 
towards open standards.

>     3. All entities MUST support both H.264 and VP8
>        Are you in favor of this option [Yes/No/Acceptable]:

No.

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

MPEG-LA owns patents /and/ uses them aggressively to stifle development 
of open standards. I do not see this as remotely appropriate for 
*Mandatory*-to-Implement.
Misleading innocent actors that it's open sourced when it's not, is an 
unacceptable action in my book.

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

Acceptable.

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

MPEG-LA owns patents /and/ uses them aggressively to stifle development 
of open standards. I do not see this as remotely appropriate for 
*Mandatory*-to-Implement.
Misleading innocent actors that it's open sourced when it's not, exposes 
them even more to uncertainty and doubt.
Interoperability issues.
However, at least I see in this option a narrow and difficult path to 
many, not all, compliant setups, at the price of ignoring the codec one 
doesn't implement or use in practice.

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

Acceptable.

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

Interoperability issues. However, at least the islands that will result 
are feasible setups taken in isolation. Not optimal, but I could live 
with it considering all the context of this decision.

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

Yes.
Path to an open standard of better quality next time.

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

Yes.
The result in practice is "islands" in other options, so might as well 
not choose a mandatory-but-not-used-in-practice solution.

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

Interoperability not achieved for the next years before an open standard 
is ready at the quality of the day. However the objection should be read 
as softened by the above.

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

Yes.
Interoperability achieved. Choice between preferred and fallback.

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

Acceptable.

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

Acceptable.

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

MPEG-LA owns patents /and/ uses them aggressively to stifle development 
of open standards.
Misleading innocent actors that it's open sourced like any other when 
it's not, exposes them even more to uncertainty and doubt.
But another practical result of this option is interoperability.

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

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

Too risky still. Patent aggressivity and bad faith.

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

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

MPEG-LA owns patents /and/ uses them aggressively to stifle development 
of open standards. I do not see this as remotely appropriate for 
*Mandatory*-to-Implement.
Misleading innocent actors that it's open sourced like any other when 
it's not, exposes them even more to uncertainty and doubt.

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

No.

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

Too risky still. Patent aggressivity and bad faith.

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

Acceptable.

>     15. All entities MUST support decoding using Theora.
>        Are you in favor of this option [Yes/No/Acceptable]:

Acceptable.

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

Acceptable.

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

Quality issues.


-- 
~enyst

"Excuse me, Professor Lessig, but may I ask you to sign this CLA, so 
that we have legally your permission to distribute your CC-licensed words?"