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

[Mohammed Raad <[e-mail]>]

Hi,

One point that does concern me, is that there seems to be a general
acceptance that VP8 does meet the requirements to be selected as MTI, yet
it is still not acceptable to many in your WG. Added to this the various
attempts to dress up H.264 into something that looks as workable as VP8.

I note here that there is now an attempt to present "market realities" in
such a way as to imply H.264 is a defacto MTI. Of course, the game theory
example given does not include any actual deployment numbers and so doesn't
lead to a sound conclusion.

Nonetheless, I do not think that an SDO should be simply guided by market
deployments, decisions should be based on how to best meet the requirements
of a particular project. I'm not saying market information should be
ignored, I am saying that whether or not a particular solution meets a
project's requirements should be the driver behind adoption.

In this case, two camps have developed around two technologies and both
camps have taken steps to make their preferred solution better aligned with
the project's requirements. In such a case it would be ideal if the
technical merit could be used as the deciding factor, but chasing a
decision on that basis is by definition impractical given that two groups
of technologists have already formed - meaning there is enough ambiguity in
the technical information to allow each group to justify its position.

In such situations, one looks for compromise.

In answering the question "what do we do":

I have suggested one possible way to compromise, a couple of people seemed
supportive, others were not.

BR,
Mohammed
On Nov 9, 2013 9:56 AM, "Adam Roach" <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>