Re: [rtcweb] Alternative decision process in RTCWeb

John Leslie <john@jlc.net> Tue, 03 December 2013 14:16 UTC

Return-Path: <john@jlc.net>
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 D98021AD694 for <rtcweb@ietfa.amsl.com>; Tue, 3 Dec 2013 06:16:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyja9EVJlRfO for <rtcweb@ietfa.amsl.com>; Tue, 3 Dec 2013 06:16:27 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id BC4F01ADFFA for <rtcweb@ietf.org>; Tue, 3 Dec 2013 06:16:19 -0800 (PST)
Received: by mailhost.jlc.net (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 <john@jlc.net>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Message-ID: <20131203141614.GJ87911@verdi>
References: <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <D4D5920A-E041-42E8-BB1C-1CB24FBEE3F4@nominum.com> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <529CEAA6.9000501@librevideo.org> <e5bq99dg3h6e82mnsn6k21aunc9eqlvc7q@hive.bjoern.hoehrmann.de> <529D4617.6060909@bbs.darktech.org> <cbkr99d1ei74s2ugbn4pfkpb6ia7iuo731@hive.bjoern.hoehrmann.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cbkr99d1ei74s2ugbn4pfkpb6ia7iuo731@hive.bjoern.hoehrmann.de>
User-Agent: Mutt/1.4.1i
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
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: Tue, 03 Dec 2013 14:16:29 -0000

Bjoern Hoehrmann <derhoermi@gmx.net> 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 <john@jlc.net>