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

Eric Rescorla <> Sat, 23 November 2013 15:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EB4901ADF59 for <>; Sat, 23 Nov 2013 07:00:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W5vtkEzqhwEu for <>; Sat, 23 Nov 2013 07:00:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0E4D41ADF10 for <>; Sat, 23 Nov 2013 07:00:02 -0800 (PST)
Received: by with SMTP id q58so2224709wes.19 for <>; Sat, 23 Nov 2013 06:59:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rbXVI5SWTg3FZ+QOZtnFQPk7OLjTmBGYbDSZbeCgyCA=; b=AFjgPrUP27r1SDMM+7TxbrhAonSvpAXIjBrYUHWiIC5HQtg23rKkaAuXOPpTo5o9Po SJblEEp27dbQCcfXG17KNAs776D9iu1jFyQdq0IUKbs+WI7KxpEurQLLVRNPjpmk/Top +LxJ6yD6Clp+6UoKTxSj0+ezMhx/UAW3Ojw6ojFKa+tNimWdGWryxawPUExUUeo3omm6 WWaJ117raDgwEbwNW04ICKOL4I1thCCyunnUp41scU+94CdbdnpAxAe/9gIV79wbEQT6 8f7Tclc9xsSVmX95SUMYKEJiHzv2NQOuLzHMatK3vwB9jeTzP3Sww6bl9PmEJ8sRsHtl GiUw==
X-Gm-Message-State: ALoCoQlOi4aZX9EnmdA82n3jAKiOG+sBIklWfJzGAjinAW93F8vVJXpS/nUu+hOS//gLmsr50xK+
X-Received: by with SMTP id u9mr7037739wif.5.1385218795104; Sat, 23 Nov 2013 06:59:55 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 23 Nov 2013 06:59:14 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <20131122171020.GY3245@audi.shelbyville.oz> <> <> <> <> <> <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Sat, 23 Nov 2013 06:59:14 -0800
Message-ID: <>
To: cowwoc <>
Content-Type: multipart/alternative; boundary="f46d04447f673801b004ebd9620d"
Cc: "" <>
Subject: Re: [rtcweb] Opinions are fine, bypassing a vote is not (was: H.261)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 23 Nov 2013 15:00:06 -0000


I would like to push back on this a bit. Say that we had general consensus
that Theora was strictly better than H.261. I think it would be OK to remove
H.261. Obviously, if there's any significant dissent, we shouldn't, but I'm
already pretty sad about all the options, and I don't think it's bad to
the field if there is near-unanimity on something....


On Fri, Nov 22, 2013 at 10:59 PM, cowwoc <> wrote:

> 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 [] On Behalf Of Basil Mohamed
>> Gohar
>> Sent: Friday, November 22, 2013 12:57 PM
>> To:
>> 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
>> _______________________________________________
>> rtcweb mailing list
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list