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

From: Bernard Aboba <[email-masked]>
Date: Fri, 8 Nov 2013 15:31:45 -0800

I cannot resist adding my speculation to everyone else's. I speculate that by this time next year, no one will care about this debate. This could be either because they have moved on to new (but equally unproductive) arguments about VP9 vs. H.265 OR because the RTCWEB WG adopted no MTI but at the same time focused on enabling codec plugability, so that codec technology could evolve more easily.

Rules vs. Tools. Take your choice...

Peter Thatcher <[email-masked]> wrote:

You are responding to a little speculation with a lot of speculation, which
doesn't seem very valuable.  What should *I* do?  Respond with more
speculation, of course.

I will speculate that there is a group of developers that would ignore an
H.264 MTI:  FOSS projects.  They will ignore it because they can't
implement it.  To them, MT(IMPLEMENT) becomes MT(IGNORE_THE_SPEC).  I
speculate this includes FOSS browsers, include the Firefox source code and
(with no extra knowledge from my employer; it's just speculation) Chromium
and FOSS forks of both Firefox and Chromium.  I further speculate this will
include FOSS non-browser RTCWEB endpoints, such as FOSS RTC mobile apps.

So there's my speculation in response to your speculation in response to
Stephan's speculation, probably without value, but perhaps worth reminding
everyone that some people (FOSS projects) will have to ignore the spec if
H.264 is the MTI, because they have no choice (at least in countries where
software patents are enforced).  Of course, you may then speculate in
return that no one cares about FOSS projects and browsers, which I
speculate would be an ironic coming from someone representing a FOSS
project.

On Fri, Nov 8, 2013 at 2:55 PM, Adam Roach <[email-masked]> wrote:

>  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.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 10 Nov 2013 19:56:05 +0000

Agree

I am at the point where I would prefer to spend the meeting cycles getting things we can agree on, rather than where we seem to be at the moment with an issue where there are two clear camps and no real sign of a compromise.

Ultimately the market will decide (and some parts of it probably have already decided - which is probably the reason for no progress).

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: 08 November 2013 23:32
To: Peter Thatcher
Cc: [email-masked]
Subject: Re: [rtcweb] MTI video codec, charter, RFC 3929

You are responding to a little speculation with a lot of speculation, which doesn't seem very valuable.  What should *I* do?  Respond with more speculation, of course.

I will speculate that there is a group of developers that would ignore an H.264 MTI:  FOSS projects.  They will ignore it because they can't implement it.  To them, MT(IMPLEMENT) becomes MT(IGNORE_THE_SPEC).  I speculate this includes FOSS browsers, include the Firefox source code and (with no extra knowledge from my employer; it's just speculation) Chromium and FOSS forks of both Firefox and Chromium.  I further speculate this will include FOSS non-browser RTCWEB endpoints, such as FOSS RTC mobile apps.

So there's my speculation in response to your speculation in response to Stephan's speculation, probably without value, but perhaps worth reminding everyone that some people (FOSS projects) will have to ignore the spec if H.264 is the MTI, because they have no choice (at least in countries where software patents are enforced).  Of course, you may then speculate in return that no one cares about FOSS projects and browsers, which I speculate would be an ironic coming from someone representing a FOSS project.

On Fri, Nov 8, 2013 at 2:55 PM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:
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:

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.

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: David Singer <[email-masked]>
Date: Mon, 11 Nov 2013 09:53:32 +0800

> I am at the point where I would prefer to spend the meeting cycles getting things we can agree on, rather than where we seem to be at the moment with an issue where there are two clear camps and no…

I agree.  I don't think anyone wants to (re-)implement H.261 or something else that old.  I think the best we can do right now is what I suggested: must implement either H.264 CBP or VP8, and should implement both.  It's not perfect, but it may be better than silence.  (And by specifying profile/level of H.264, we are helping convergence.)

I doubt that there is anyone who cannot live with this.

David Singer
Multimedia and Software Standards, Apple Inc.