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

+1 on this proposal . Hope IETF91  would be a decision making for this
pending item

Cheers
Suhas

On Mon, Nov 10, 2014 at 11:14 AM, Roman Shpount <roman@telurix.com> wrote:

> Even though I am not 100% happy with this proposal and that it probably
> needs a bit of language clean up, I do support this proposal.
>
> _____________
> Roman Shpount
>
> On Sun, Nov 9, 2014 at 9:08 PM, Adam Roach <adam@nostrum.com> 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
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>