Re: [rtcweb] VP8 vs H.264 - the core issue

["Jeremy Laurenson (jlaurens)" <[e-mail]>]

On Oct 25, 2013, at 3:50 PM, Justin Uberti <[e-mail]> wrote:

> 
> 
> 
> On Fri, Oct 25, 2013 at 4:25 AM, Jeremy Laurenson (jlaurens) <[e-mail]> wrote:
> First, my area of focus is system deployment for existing organizations, and my employer is clearly leaning H.264, however as an individual:
> 
> I am of the opinion that from a "browser user perspective" this is pretty easy because two of the issues I see seem not to have a significant winner based on all this list activity:
> 	The average browser user does not care, except that bandwidth is materially affected - and there seems both are close in performance.
> 		(Profiles and efficiency could be argued forever at this rate)
> 	IPR does seem to be in the air - and without being a lawyer, I see Nokia folks on this list declaring there is an issue here.
> 		(But lawyers can argue forever)
> 
> No, this is a fundamental issue. If H.264 is the MTI, to quote Harald, "we give up and live with royalties forever". This will have a significant impact on WebRTC innovation and adoption.

> 
> The fact that there are some who disagree with the IPR status of VP8 does not invalidate this point.

The fact that Nokia has informed the group they believe there are IPR issues and they will not license means that regardless of whether we are all proponents of "royalty free", VP8 is likely not "the answer". This would mean that VP8 has no bearing whatsoever on the point Harald made. Until someone here digs into the Nokia filings, I remain firmly unconvinced.

> 
> There seems to be a split.... however I believe the third factor here, while less technical in nature, will affect deployment and adoption.
> 
> I believe the ability to leverage existing applications/infrastructure with a relatively small amount of work is a third leg in this stool and tips the balance materially for those looking to light up applications.
> 
> Simply put, a user would ask why a new, less-interoperable standard is being introduced in absence of  functionality or bandwidth savings.
> 
> This has material cost savings and media flow implications for a large set of the people who are going to use this technology. Clearly this was an important factor based on the SDP slant of the content of the spec.
> 	
> In my opinion we are not paying enough attention to an important line in the burman h.264 proposal: "In addition, using H.264 enables interoperability with many other services without video transcoding."