Re: [rtcweb] MTI video codec, charter, RFC 3929
Adam Roach <adam@nostrum.com> Fri, 08 November 2013 22:56 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0812521E805F for <rtcweb@ietfa.amsl.com>; Fri, 8 Nov 2013 14:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.522
X-Spam-Level:
X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZNQRm4gUCwb for <rtcweb@ietfa.amsl.com>; Fri, 8 Nov 2013 14:56:00 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2E53311E80FB for <rtcweb@ietf.org>; Fri, 8 Nov 2013 14:55:59 -0800 (PST)
Received: from dhcp-b7d7.meeting.ietf.org (dhcp-b7d7.meeting.ietf.org [31.133.183.215]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rA8Mtr6W074366 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 8 Nov 2013 16:55:56 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <527D6BFA.9090509@nostrum.com>
Date: Fri, 08 Nov 2013 14:55:54 -0800
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Stephan Wenger <stewe@stewe.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <CEA19328.A9A84%stewe@stewe.org>
In-Reply-To: <CEA19328.A9A84%stewe@stewe.org>
Content-Type: multipart/alternative; boundary="------------030901000807040700080604"
Received-SPF: pass (shaman.nostrum.com: 31.133.183.215 is authenticated by a trusted mechanism)
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 08 Nov 2013 22:56:03 -0000
On 11/7/13 18:57, Stephan Wenger wrote: > ...a decision for either of the two candidate codecs will be ignored > by a significant part of the implementer community. I'm not sure that's true any longer. Indulge me in a bit of armchair game theory application. Let's start by looking at ground zero: the browsers. Considering the public statements that have been made, I think it's fairly safe to assume that the following can be taken as given: 1. Chrome will support at least VP8. 2. Firefox will support both VP8 and H.264. 3. Internet Explorer is almost certain to support H.264. 4. Safari (including Mobile Safari) is almost certain to support H.264. If the codecs are *only* those called out above, then you'll end up with an interesting situation in which IE, Safari, and Firefox can all mutually interoperate; Chrome and Firefox can interoperate with each other; and Chrome cannot interoperate with anything else. I'm not going to put plans in Google's mouth, but envision yourself in the same set of circumstances: you own a fully-paid H.264 license, already ship an H.264 codec as part of your browser, and are getting a huge black eye for not interoperating with significant major browsers. What do you do? Okay. Now, shift your imagined role: you're a non-browser implementor, and discover the facts on the ground to be those described above. You can deploy VP8 and work with two of the four major browsers, or you can deploy H.264 and work with all four. Yeah, you might not be in love with the structural issues involved in integrating the Cisco library [1] -- and I'm certainly not -- but you're not actually precluded from using H.264. What do *you* do? Which is a kind of long way to get to the fact that I think we're in a situation where H.264 is a de facto MTI codec anyway [2]. Now, imagine you're working in an SDO with this particular set of writing on the wall. You have a solid decision to choose one MTI video codec. You can choose one that's going to be functionally MTI regardless of what you say, or you can choose one that is quite probably going to be ignored by some non-trivial set of implementors. So. What do *we* do? /a ____ [1] There's been quite a bit of handwringing around the impact this has on iOS developers, as they cannot download modules at runtime. Bear in mind that these are curated applications, with a single, well-accounted-for distribution point. These are not libre software by a long shot, and they don't need to worry about the implications of third parties compiling their own versions. So, these implementors statically link in the OpenH264 library, and are exempted for the first 100,000 instances they ship each year. Beyond that point, they're not "small fish" any more. Back when I was one of the owners of the company I worked at, "complications arising from selling more than 100,000 copies a year" is the kind of thing that I would place on a list titled "problems I wish I had." [2] And to be clear, this is *not* the result I would have preferred. But I recognize that this isn't about my personal preferences. I find myself in the odd position of actually arguing for the position contrary to what I think is ideal, simply because I think it is the only practical path to success.
- Re: [rtcweb] MTI video codec, charter, RFC 3929 cowwoc
- [rtcweb] MTI video codec, charter, RFC 3929 Stephan Wenger
- Re: [rtcweb] MTI video codec, charter, RFC 3929 cowwoc
- Re: [rtcweb] MTI video codec, charter, RFC 3929 Leon Geyser
- Re: [rtcweb] MTI video codec, charter, RFC 3929 Adam Roach
- Re: [rtcweb] MTI video codec, charter, RFC 3929 Peter Thatcher
- Re: [rtcweb] MTI video codec, charter, RFC 3929 Bernard Aboba
- Re: [rtcweb] MTI video codec, charter, RFC 3929 Adam Roach
- Re: [rtcweb] MTI video codec, charter, RFC 3929 Peter Thatcher
- Re: [rtcweb] MTI video codec, charter, RFC 3929 cowwoc
- Re: [rtcweb] MTI video codec, charter, RFC 3929 Justin Uberti
- Re: [rtcweb] MTI video codec, charter, RFC 3929 Ron
- Re: [rtcweb] MTI video codec, charter, RFC 3929 Mohammed Raad
- Re: [rtcweb] MTI video codec, charter, RFC 3929 cowwoc
- [rtcweb] Who is committed to supporting MTI? (was… Adam Roach
- Re: [rtcweb] MTI video codec, charter, RFC 3929 Lorenzo Miniero
- Re: [rtcweb] MTI video codec, charter, RFC 3929 Lorenzo Miniero
- Re: [rtcweb] Who is committed to supporting MTI? … Peter Thatcher
- Re: [rtcweb] Who is committed to supporting MTI? … cowwoc
- Re: [rtcweb] Who is committed to supporting MTI? … Ron
- Re: [rtcweb] MTI video codec, charter, RFC 3929 DRAGE, Keith (Keith)
- Re: [rtcweb] MTI video codec, charter, RFC 3929 David Singer