[rtcweb] Opinions are fine, bypassing a vote is not (was: H.261)

cowwoc <cowwoc@bbs.darktech.org> Sat, 23 November 2013 07:00 UTC

Return-Path: <cowwoc@bbs.darktech.org>
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 5660D1AE0DE for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 23:00:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 gk_7Y2QyS11Z for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 23:00:17 -0800 (PST)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4B41AE0E9 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 23:00:16 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id at1so3659281iec.5 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 23:00:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yo+gQxeCW1j7KRfiTAvlSbMOVpgI9vFTPfCwVXFw3TA=; b=bAJTVtCXQlYsFqfRiIPOJ4SZ2+irJtMqRxtnNKu/s/lE7wmYXh4eTkU4WhhiaqHzmk 6MMBgWVS2iudeZX0MOGy+ABDD2UYOddEPhgoOfyOM5T5sBPFyhHGUBaZIIa3DLs8VWG+ vmeBdxcgYsewJzyjZ3BCTxPu+gRwoNsiW3AR4+MyzX8/GZalIQxUD90yUC1egDlr3sRD 73mUMiin/I9b8TFV1NrUqhptbK8aKyggVQn/YHMMDQQ+qHYm1xLNuarO5KOJZEDOfWl9 qDnicj7va2RJ8tnZHVwR35jKkrDs4q05oij9UB9jNLOtRZmSKdwFy8SVV47rPYvFFy3x FbVQ==
X-Gm-Message-State: ALoCoQkAvpIMwfiC7N0TmbDzsPecTOmLNRU5ngVonFK3v8SBBr1BFI0TnxEa2i9mbrC+kBKuXP++
X-Received: by 10.50.92.8 with SMTP id ci8mr5403918igb.23.1385190008965; Fri, 22 Nov 2013 23:00:08 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id a17sm13235172ign.2.2013.11.22.23.00.07 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 23:00:08 -0800 (PST)
Message-ID: <52905257.1060209@bbs.darktech.org>
Date: Sat, 23 Nov 2013 01:59:35 -0500
From: cowwoc <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CEB4350B.1E7B2%mzanaty@cisco.com> <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E671A@ausmsex00.austin.kmvtechnologies.com> <528FC513.4020903@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E6731@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <7949EED078736C4881C92F656DC6F6C130EA9E6731@ausmsex00.austin.kmvtechnologies.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] Opinions are fine, bypassing a vote is not (was: H.261)
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, 23 Nov 2013 07:00:19 -0000

This post is not meant to target Stefan specifically. It is a general 
statement based on what I've noticed over the past 200+ posts on this topic.

I am ... concerned ... by the apparently attempt by certain individuals 
to have options removed ahead of a possible vote. It is one thing to 
explain your opinion in order to encourage/discourage people from voting 
for it. It is another matter to imply that an option is a "waste of 
time" because only a "vocal minority" seems to care about it or that 
"given the choice between what you are proposing and X, most developers 
would prefer X". If no one is in favor of H.261 "except for a vocal 
minority" or "most developers would prefer X" then you have nothing to 
worry about. Let the community vote and see where the chips land. I 
don't think it's safe to rely on "vocal minorities" to gauge what the 
community at large prefers. The only way to find out is to ask them (and 
that's what the vote is all about).

Everyone should be free to express their opinion for/against an option, 
but no option should be removed ahead of a vote.

Just my 2 cents.

Gili

On 22/11/2013 4:14 PM, Stefan Slivinski wrote:
> Why don't we add the "must support both H.264 and VP8 decode and must support at least one of H.264 or VP8 encode" to the list of options and ask for a show of hands as to what people are in favor of.  This would be non-binding, simply a status check.  Maybe no one is in favor of H.261 except for a vocal minority in which case we're wasting time arguing about it.
>
> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Basil Mohamed Gohar
> Sent: Friday, November 22, 2013 12:57 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] H.261
>
> On 11/22/2013 03:44 PM, Stefan Slivinski wrote:
>> Thank you for the link.
>>
>> The point I'm trying to make is H.261 will harm the proliferation of webrtc far more than it will help.  This is purely a technical argument speaking to quality and error resiliency.
>>
>> Has anyone listed the concerns surrounding H.264 and have these been raised with mpeg-la to see if they can make adjustments to the license agreement.  They have certainly done so in the past.
> Believe it or not, the MPEG-LA is currently trying to establish a royalty-free subset of H.264 called "Constrained Baseline Profile", which is very similar to the most commonly-used subset of H.264 features out there.
>
> The problem is, it's not done yet, and there's no indication whether or not it will be successful or not.  This would require all existing stakeholders in H.264 licensing to agree to this royalty-free variant for it to matter.
>
> There's another effort to do the same with one using MPEG-1 as a base.
>
> The problem is, none of these formally exist in royalty-free forms as of yet.  Everything else we've discussed, though, does, including H.261.
>
> And, for what it's worth, I disagree about H.261.  Yes, H.264 and/or VP8 (and a whole list of other codecs) will look *better*, but I think being able to communicate via video over H.261 is better than not being able to all.
>
> And we are at a point where "not at all" is going to happen because the WG is effectively split over using VP8 and H.264.
>
> --
> Libre Video
> http://librevideo.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb