Re: [rtcweb] Alternative decision process in RTCWeb

John Leslie <> Tue, 03 December 2013 14:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D98021AD694 for <>; Tue, 3 Dec 2013 06:16:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kyja9EVJlRfO for <>; Tue, 3 Dec 2013 06:16:27 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BC4F01ADFFA for <>; Tue, 3 Dec 2013 06:16:19 -0800 (PST)
Received: by (Postfix, from userid 104) id A03ADC94A9; Tue, 3 Dec 2013 09:16:14 -0500 (EST)
Date: Tue, 3 Dec 2013 09:16:14 -0500
From: John Leslie <>
To: Bjoern Hoehrmann <>
Message-ID: <20131203141614.GJ87911@verdi>
References: <> <> <> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
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: Tue, 03 Dec 2013 14:16:29 -0000

Bjoern Hoehrmann <> wrote:
> * cowwoc wrote:
>> H.261 is meant as a fallback only in the case that the market cannot 
>> agree to upgrade to VP8 or H.264 at runtime. If a sizable portion of the 
>> market cannot agree at runtime, what makes you believe that that same 
>> sizable portion can agree on a MTI codec? And a final question, in case 
>> you disagree with everything I've written so far: How do you advocate we 
>> proceed in light of the fact that we already tried to (and failed) to 
>> reach consensus around VP8 and H.264?
> If I were to believe VP8 and H.264 are not royality-free options that
> can be used in Free implementations of the protocol then the mandatory-
> to-implement codec is likely their only option to communicate with
> commercial implementations.

   We have strong evidence that implementors believe there is significant
IPR risk in either of these. That is what matters -- not whether someone
else thinks they're "royalty-free".

> If the only option is "not good enough", I might prefer the Working Group
> say so instead of offering a fig leaf.

1: There's always more than one option. If folks think H.261 is as bad
   as you think it, transcoding services will arise, and I expect most
   folks that care about video quality to find browsers which support
   VP8 _and_ H.264;

2: Any codec will be "good enough" for some uses, and not for others;

3: Nothing prevents the Working Group from adding language about the
   limitations of H.261;

4: This is not about "offering a fig leaf" -- it's about preventing
   negotiation failure until the market can settle on some better way:
   I remind you that codecs better than VP8 and H.264 are already
   starting to see use;

5: Whatever _you_ might prefer, there are others who would prefer to
   get this specification out the door and widely implemented.

John Leslie <>