Re: [rtcweb] MTI Video Codec: a novel proposal

[Eric Rescorla <[e-mail]>]

+1

As should be obvious from Mozilla's decision to implement both VP8
and H.264 in Firefox, we believe that supporting both codecs is the
best path forward for now.

In the future, hopefully we can have one MTI best-in-class codec that
is also RF -- as Opus is for audio -- but in the meantime this
seems like the solution that is best for helping the ecosystem
move forward.

-Ekr




On Mon, Nov 10, 2014 at 9:54 AM, Justin Uberti <[e-mail]> wrote:

> Adam, thanks for your work on this.
>
> I think this plan represents a legitimate compromise in what had
> previously seemed like a stalemate. While not our (Google's) ideal outcome,
> we think this is good for the WebRTC ecosystem - it ensures
> interoperability, and provides a reasonably clear path for reaching a
> completely RF solution.
>
> In the meantime, WebRTC devices can use APIs such as Android's MediaCodec
> or iOS' VideoToolkit to provide H.264 support without having to distribute
> it themselves. (MediaCodec, of course, can also be used for VP8, and soon,
> VP9).
>
> Lastly, on the point of whether any codec can meet the bar of being
> considered RF, note that the text provides some discretion:
>
>
> *If compelling evidence arises that one of the codecs is available for use
> on a royalty-free basis, *such as* all IPR declarations known for the codec
> being of (IETF) Royalty-Free or (ISO) type 1, ...*
>
> This allows the IETF to make a decision based on the preponderance of the
> evidence.
>
> On Sun, Nov 9, 2014 at 6:08 PM, Adam Roach <[e-mail]> wrote:
>
>>  It appears that we're running headlong into another in-person discussion
>> about the relative merits of H.264 and VP8 as MTI candidates again. Matthew
>> Kaufman has argued that this conversation is doomed to failure because no
>> major player has been willing to change their position. The players he
>> cited were Cisco, Google, and Mozilla, who have represented the three main
>> positions on this topic pretty effectively. Although we participate as
>> individuals in the IETF, I think it's fair to say that the last time we had
>> this conversation, the median positions of participants from those
>> companies were "H.264 or die", "VP8 or die", and "either one as long as
>> it's *only* one", respectively.
>>
>> However, even if nothing else has changed, I think one salient point may
>> have become quite important: we're all tired of this. Over two years ago,
>> in March of 2012 -- before I even had an particular interest in WebRTC
>> except as a user -- this had already become such a long-running acrimonious
>> debate that I was brought in as a neutral third party to try to mediate.
>> I'm weary of this argument; and, with the exception of a few aggressive
>> voices who seem to enjoy the battle more than the outcome, I'm hearing a
>> similar exhausted timbre in the messages of other participants (and the key
>> stakeholders in particular).
>>
>> So, I want to float a proposal that represents a compromise, to see if we
>> can finally close this issue. First, I want to start out by reiterating a
>> well-worn observation that the hallmark of a good compromise is that nobody
>> leaves happy, but everyone can force themselves to accept it. And I want to
>> be crystal clear: the solution I'm about to float just barely clears the
>> bar of what I think I can live with. This proposal is based on an
>> observation that the dominating issues in this conversation remain those of
>> licensing, not technology or even incumbency. I’ve discussed this
>> extensively with representatives of all three of the players I mention
>> above, and they are willing to sign on.
>>
>> This proposal is based on the definitions of "WebRTC User Agent", "WebRTC
>> device", and "WebRTC-compatible endpoint" in section 2.2 of
>> draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:
>>
>>
>>    1. WebRTC User Agents MUST implement both VP8 and H.264.
>>
>>     2. WebRTC devices MUST implement both VP8 and H.264. If compelling
>>    evidence arises that one of the codecs is available for use on a
>>    royalty-free basis, such as all IPR declarations known for the codec being
>>    of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative
>>    statement to indicate that only that codec is required. For absolute,
>>    crystal clarity, this provision is only applicable to WebRTC devices, and
>>    not to WebRTC User Agents.
>>
>>     3. WebRTC-compatible endpoints are free to implement any video
>>    codecs they see fit, if any (this follows logically from the definition of
>>    "WebRTC-compatible endpoint," and doesn't really need to be stated, but I
>>    want this proposal to be as explicit as possible).
>>
>>
>> This has the property of ensuring that all devices and user agents can
>> work with all devices and user agents. This has the property of giving no
>> one exactly what they want. And, unlike any other previous plans, this has
>> the property of coming to a decision while maintaining pressure on the only
>> parties who can make a change in the IPR landscape to do so.
>>
>> /a
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>