Re: [rtcweb] H.264's high-low play (Was: H.264 IPR disclosures (or persistent lack thereof))

[cowwoc <[e-mail]>]

I've seen multiple VP8 proponents rate the following options as Acceptable:

 1. H.261 as MTI
 2. Theora as MTI
 3. Implement two of [H.261, H.264, VP8] as MTI

They might not love the option but they are willing to accept it as a 
compromise. On the flip side, I've seen multiple H.264 backers rate 
"H.264 s MTI" as "Yes" and all other options as "No". They did not 
include a single option as "Acceptable".

It doesn't really matter who responded this way. What *is* important is 
that we can only reach a mutually acceptable compromise if the majority 
rate multiple options as "Acceptable". Anyone who is only willing to 
accept a single option pretty much guarantees that they will find 
themselves disappointed.

I mean... negotiation and compromise, by definition, imply that you are 
not going to get 100% of what you're asking for. The sooner people 
internalize that, the sooner we can move on.

Gili

On 15/12/2013 8:25 PM, Eric Rescorla wrote:
> I'm sure I'm going to regret asking this, but what compromise do you think
> either side has offered?
>
> -Ekr
>
>
> On Sun, Dec 15, 2013 at 5:18 PM, cowwoc <[e-mail]> wrote:
>> +1
>>
>> If the H.264 crowd was as willing to compromise on some other option then we
>> could reach a solution that would be satisfactory to all parties. I still
>> hope that we can reach such a compromise.
>>
>> Gili
>>
>>
>> On 15/12/2013 2:57 AM, Ron wrote:
>>>> By contrast, the primary argument for VP8 is that it's free (despite
>>>> some people saying they couldn't implement it).
>>> I don't remember seeing too many arguments that listed technical reasons
>>> why they _couldn't_.  Only why they said they _wouldn't_ or didn't want
>>> to.  And all of those arguments were basically "oh noes, teh unknown IPR"
>>> (and which realistically I think actually boil down to, in every case,
>>> "we own IPR for H.264, we don't own any for VP8" - which isn't much of a
>>> safety net for the majority of people who don't own H.264 IPR).
>>>
>>> Which if we agree is transferred to someone else if you download a binary
>>> from them, can be mitigated for VP8 at least as well as for H.264.  (and
>>> if we don't agree on that, then Cisco's offer doesn't help either).
>>>
>>> In fact it's still mitigated _better_ for VP8, since Google is giving you
>>> a "free licence" to *all* of the known applicable IPR, along with a strong
>>> defensive reciprocity guarantee - while the Cisco offer is _only_
>>> licencing
>>> you the MPEG-LA pool, which leaves you no licence at all to the other
>>> known
>>> IPR that exists outside of that pool, and no promise from even MPEG-LA
>>> that
>>> you are in any way safe for having a licence from them.
>>>
>>>
>>>> So, if Google were to make a plugin available, that would alleviate the
>>>> concerns of people that it really was encumbered, but it doesn't do
>>>> anything for the existing installed base.
>>> The existing installed base for WebRTC is pretty much exclusively VP8
>>> at present.  So no, it won't do anything for them at all :)  They already
>>> have it.
>>>
>>> For people yet to implement WebRTC, that don't already have VP8 available,
>>> they probably also don't already have Opus available either.  If linking
>>> to libvpx (or a downloaded plugin of it) and linking to libopus, presents
>>> a total showstopper technical difficulty to them, then I don't hold out
>>> much hope for the quality, or delivery, or a WebRTC implementation from
>>> them at all.  This is surely the most trivial part of anything that they
>>> will need to do.
>>>
>>> We already established that almost every platform with "hardware H.264"
>>> would need to reimplement it in software for this anyway.  I don't see
>>> how this poses any significant extra difficulty to do for VP8 instead
>>> (or as well should they choose).
>>>
>>>
>>> The notable thing to my mind, is that the people who considered VP8 as
>>> the only viable option when this was a two horse race, have almost
>>> universally attempted to compromise on some other option that also met
>>> the needs and fears of the people who said the IPR situation surrounding
>>> it was untenable for them.  I can't think of (m)any people from the
>>> H.264 or bust camp that have engaged with that to satisfy the concerns
>>> expressed about it.  Presently they're still arguing that they don't
>>> even need to disclose to the IETF at all ...
>>>
>>> If people are going to talk of Solomonic solutions, then if Solomon was
>>> a chair, I suspect he'd know who cared more about this baby's welfare :>
>>>
>>>     Ron
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb