Re: [rtcweb] Proposed Video Selection Process

Ron <> Thu, 21 November 2013 20:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BC3481AE1C8 for <>; Thu, 21 Nov 2013 12:42:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iwGgxgdmMz8Y for <>; Thu, 21 Nov 2013 12:41:58 -0800 (PST)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by (Postfix) with ESMTP id 7C77F1AE1B5 for <>; Thu, 21 Nov 2013 12:41:57 -0800 (PST)
Received: from (HELO audi.shelbyville.oz) ([]) by with ESMTP; 22 Nov 2013 07:11:49 +1030
Received: from localhost (localhost []) by audi.shelbyville.oz (Postfix) with ESMTP id EFBFD4F8F3 for <>; Fri, 22 Nov 2013 07:11:47 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([]) by localhost (audi.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id OOcrx3o+Ftuj for <>; Fri, 22 Nov 2013 07:11:47 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 784424F902; Fri, 22 Nov 2013 07:11:47 +1030 (CST)
Date: Fri, 22 Nov 2013 07:11:47 +1030
From: Ron <>
Message-ID: <20131121204147.GV3245@audi.shelbyville.oz>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] Proposed Video Selection Process
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: Thu, 21 Nov 2013 20:42:00 -0000

On Thu, Nov 21, 2013 at 11:13:11AM -0800, Adam Roach wrote:
> On 11/21/13 10:56, Justin Uberti wrote:
> >Following an IETF meeting on Jabber doesn't count as participating?
> >
> >The "big guy vs little guy" narrative continues...
> I think that's a bit specious. If someone is following the issue at
> such a distance that they haven't expressed an opinion on the
> mailing list, I can't see how taking a vote from them counts as
> anything other than simple, old-fashioned ballot stuffing.
> I'll take it one step further. I find the prospect that we're
> allowing blue sheets to stand in for participation to be highly
> questionable: letting the tourists vote is weighting the opinion of
> demonstrably uninvolved (or less-involved) parties at the same level
> as those who have actually been working on the topic. I do not think
> that a blue-sheet sign in without any on-list participation should
> be sufficient to participate in the kind of process the chairs are
> proposing.
> Or perhaps I'm missing something.

I'd assumed that Justin was referring to the fact that people were
objecting to jabber participants but not the blue sheet tourists
who packed the room for the session with a hum.

So I'm glad you've made that (IMO obvious and important) extra detail
quite specific.

But that said, I think I'm firmly with Peter Saint-Andre here.
Taking this straight to (another) vote seems like a questionable
choice, with a very high chance of an even more questionable and
protested outcome (and precedent). [1]

My understanding of the current situation is:

 - We established consensus long ago that MTI codecs are a very
   important part of this specification.

 - We've had 2 seriously proposed codecs prior to the last meeting.

 - We have people expressing objections to both of them, that the
   chairs consider sufficient to declare there is no workable
   consensus for either at present.

 - The sustainable objections to both all boil down to people claiming
   there are insurmountable IPR difficulties.  Whether that be mythical
   risk, or clear impossibilities of obtaining a licence.

 - We've now had people resign themselves to the fact that this is the
   blocking issue for consensus that needs to be resolved, and propose
   solutions that directly address that issue, through the use of a
   codec that is broadly agreed does not have this problem.

So to me the obvious next step would be to probe for consensus about
the codec options that _do_ remain on the table - and see if anybody
has an actually sustainable objection that would prevent achieving a
rough consensus that the concerns surrounding our original preferred
choices are indeed satisfied by taking this path.

The strong objections that people have had to H.264 and VP8 aren't
going to go away, however a vote might decide - so unless those people
are going to retract their objections now (or the chairs are going to
declare them vexatious and irrelevant), then 'voting' for either of
those as MTI seems utterly pointless.

By my understanding we so far have 2 possible candidates for a MTI
codec that may satisfy the IPR and licencing concerns that have
blocked us from a decision to date:

 - H.261, for which everyone seems to agree the IPR is exhausted.

 - MPEG1, which Stephan raised some oblique concerns about, that
   might still prove unfounded with a little more investigation.

Theora I'm assuming will attract the same FUD that it did with W3C
(since people have already quoted the farce that occurred there)
and that VP8 has attracted.  All the other codecs are still
within the lifetime of live patents.  So if we can rule out H.264
and VP8, then we can immediately rule these out too without going
through the motions of repeating all the same arguments again,
with a just some search and replace for the codec names.

So wouldn't a better first step be to:

 - See if MPEG1 can actually be ruled out with plausible indications
   of real remaining IPR trouble.

 - If it is, we only have one codec left for people to try to raise
   objections about that might be sustained.

 - If it isn't, we really still only have one codec left for people
   to raise objections about, since there's obvious agreement that
   it would be superior to H.261 in every other way.

Given the agreement we've previously seen on what a MTI codec is
supposed to achieve, I'm having a hard time seeing how consensus
couldn't be established for at the worst H.261.  We'll all agree
that it sucks -- but I'm yet to see any reasonable objection about
why it _can't_ satisfy the requirements for being the MTI fallback,
in the absence of working agreement for a better alternative.

So why don't we just skip straight to seeking consensus on this?

Instead of having a vote stacked with multiple options that will remain
just as unacceptable as they are today, for all the same reasons, where
people won't have to actually _justify_ why they consider some option
or another to be unacceptable.


[1] - though I'm not at all questioning the good faith of the chairs
      in trying to find an adequate way to resolve this (or envious
      of their predicament here).