Re: [rtcweb] MTI video codec, charter, RFC 3929

Lorenzo Miniero <lorenzo@meetecho.com> Sat, 09 November 2013 16:28 UTC

Return-Path: <lorenzo@meetecho.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 3526B21F9D1C for <rtcweb@ietfa.amsl.com>; Sat, 9 Nov 2013 08:28:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level:
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 HGZsaXmc5fth for <rtcweb@ietfa.amsl.com>; Sat, 9 Nov 2013 08:28:01 -0800 (PST)
Received: from smtpdb12.aruba.it (smtpdb12.aruba.it [62.149.158.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF8621F9D12 for <rtcweb@ietf.org>; Sat, 9 Nov 2013 08:28:00 -0800 (PST)
Received: from lminiero ([88.128.80.2]) by smtpcmd04.ad.aruba.it with bizsmtp id nUTw1m00Z02zm9U01UTxk6; Sat, 09 Nov 2013 17:27:58 +0100
Date: Sat, 09 Nov 2013 17:27:56 +0100
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Adam Roach <adam@nostrum.com>
Message-ID: <20131109172756.713c433c@lminiero>
In-Reply-To: <527D6BFA.9090509@nostrum.com>
References: <CEA19328.A9A84%stewe@stewe.org> <527D6BFA.9090509@nostrum.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Sat, 09 Nov 2013 16:28:06 -0000

Il giorno Fri, 08 Nov 2013 14:55:54 -0800
Adam Roach <adam@nostrum.com> ha scritto:

> 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?
> 


I *would* use a different library, if I could. Which I can't, because
we're talking of a patented library and I'm all at disadvantage here. I
stated several times why the current Cisco plugin, while a nice and
generious offer (funny thing they changed the original "Christmas
release" slide, BTW ;-) ), is not an acceptable option for me. What some
see as an opportunity, I see as a leash, that could (or could not) be
use at any time to either slow me down or stop me entirely. I'd rather
have a free web, please.


> 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].
> 


A weird statement, considering I've yet to see an H.264 WebRTC
implementation at all.


> 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
> 


The above mentioned non-trivial set of implementors is currently
ignoring the whole spec anyway. Why should I care?


> ____
> [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."
> 


I really can't accept the 100k thing. First of all, it's not at all
clear how they're computed in the first place. Are you consuming one
when you install an app? when you open an encoder/decoder instance? a
mix of the two? what about servers? am I breaking the law every time I
play a video I took with my phone using mplayer, or transcoding it
with streamer/ffmpeg, if I don't tell MPEG LA? as I told EKR on the
chat, I've tried looking several times for information about licensing
in that sense, and have always miserably failed. I may be incredibly
dumb, but apparently I'm in good company, as I've often read posts,
blogs and more by people who tried to do the same to no avail. This
excellent post on librevideo, for instance, is three years old now and
yet so up-to-date:

http://www.librevideo.org/blog/2010/06/14/mpeg-la-answers-some-questions-about-avch-264-licensing/

I do remember something I read on a post here thats truck me at the
time. I can't remember who wrote that, and so I may be corrected, but
it said something like "just tracking down all the licenses being
consumed, even when you're under the 100k, is almost a full-time job".
For a small (actually tiny) company like mine, devoting a full
resource just for that, especially when you could use it to much
more benefit (like working on actual WebRTC stuff), is inevitably out of
the question. And the fact that other companies can instead just ignore
that and pay the cap as if it were a rounding error to their coffee
budget doesn't make me more symphatethic to the cause.


> [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.


I understand your points, and appreciate the fact you'd rather take a
different way, even if you're doing a really good job at fostering the
other. :-)

Lorenzo