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

[Eric Rescorla <[e-mail]>]

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