Re: [rtcweb] Video codecs: Clear positions....

Ron <> Thu, 11 December 2014 22:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D39331A8A52 for <>; Thu, 11 Dec 2014 14:48:28 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BtXxtuQQGPkI for <>; Thu, 11 Dec 2014 14:48:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3424E1A1AA9 for <>; Thu, 11 Dec 2014 14:48:26 -0800 (PST)
Received: from (HELO mailservice.shelbyville.oz) ([]) by with ESMTP; 12 Dec 2014 09:18:25 +1030
Received: from localhost (localhost []) by mailservice.shelbyville.oz (Postfix) with ESMTP id 10D01FFD93; Fri, 12 Dec 2014 09:18:24 +1030 (ACDT)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([]) by localhost (mailservice.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id 3tgyZPBQVKwU; Fri, 12 Dec 2014 09:18:23 +1030 (ACDT)
Received: from hex.shelbyville.oz (hex.shelbyville.oz []) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 047D6FFB5A; Fri, 12 Dec 2014 09:18:23 +1030 (ACDT)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id EB38F80470; Fri, 12 Dec 2014 09:18:22 +1030 (ACDT)
Date: Fri, 12 Dec 2014 09:18:22 +1030
From: Ron <>
To: Peter Saint-Andre - &yet <>,
Message-ID: <20141211224822.GB20986@hex.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.23 (2014-03-12)
Subject: Re: [rtcweb] Video codecs: Clear positions....
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, 11 Dec 2014 22:48:29 -0000

On Thu, Dec 11, 2014 at 02:35:13PM -0700, Peter Saint-Andre - &yet wrote:
> On 12/9/14, 2:44 AM, Harald Alvestrand wrote:
> >I note that the "confirming sense of the room" thread has gotten a lot
> >of messages that are not declaring a position on the question.
> >
> >I also note that from the messages on the thread, I can't figure out if
> >Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a
> >position (I could guess, but I don't want to - besides, they might not
> >want to take a position, which is perfectly OK).
> +0. I neither support nor object to The Honolulu Compromise (THC).
> As Mo Zanaty pointed out, its primary benefit is that it necessitates codec
> negotiation, capabilities discovery, and other features that can will prove
> helpful once we have a truly open and technically superior video codec
> (think "Opus for video").
> Until then, THC is merely a temporary palliative.

I still would be very interested in seeing some sort of rationale text
that lays this side of things out a bit more openly, if only to give
some sort of guidance (even if not normative) to future folk (and the
broader internet community when this gets to them for review) about
how we arrived at this state and why we've accepted it as an interim
workaround even if a lot of us do think it's a kind of dopey situation
to have ended up wedged in.  I certainly don't think you're alone in
criticising it in this way, whatever the concern may be for upsetting
a delicate consensus.

I'd like to think there is some way we can elaborate on this without
risking pulling the ground out from under what people have been resigned
to agreeing to here.  Even Cisco folk are on the record for saying they
would greatly prefer the kind of Final Solution that an "Opus for video"
could bring us.

I'd hinted at that again here:

  You are right that there are more than just these two camps though.
  There's also a (clearly large) subset of both that cares enough about
  the success of this project to compromise with each other in its best
  interests.  With enough options and workarounds to get by until we have
  an IETF video codec to solve it properly (and I still do think that
  clarifying that is important here.  If we're going to do something as
  audacious as mandate a patent minefield like H.264 when there is an
  equivalent that actually meets the IETF's aspirational requirements for
  RF technology, we need a better reason for that than "some people with
  H.264 patents insisted" if it's going to survive being challenged, or
  ridiculed, in later review).

and in one or two other comments here.  But I could easily forgive
anyone for missing that in the current frenzied scrum.

As I understand things we not only need to get consensus on this here,
but it also needs to stand up to scrutiny from the IESG and internet
community in general, who still could reject it as a load of hazy tosh
if we haven't made our reasoning clear and acceptable to them.

I don't know what the odds of that actually are, but I can only assume
they are worse if we don't clearly explain not only "what" but "why"
in a case like this.