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

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

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)

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."

On Oct 25, 2013, at 5:05 AM, Leon Geyser <[e-mail]> wrote:

> It would be nice if video just works for the end user instead of them having to install a different browser or buying a different device with a different browser.
> 
> I personally think there needs to be a MTI video codec even if it is an old codec such as H.261. Although the codec should not require a lot of bandwidth to look decent which excludes something such as MJPEG.
> 
> 
> On 25 October 2013 10:50, DRAGE, Keith (Keith) <[e-mail]> wrote:
> Agree
> 
> We can either explicitly make a "no MTI" decision, or just let it become the default by the absence of agreement.
> 
> Keith
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of [e-mail]
> > Sent: 25 October 2013 09:04
> > To: [e-mail]; [e-mail]
> > Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
> >
> > Hi,
> >
> > Harald Alvestrand wrote:
> > >
> > > Formalistically, the people who argue for abandoning an
> > MTI, like the
> > > people who argue for adapting an antiquated codec, have not
> > put in a
> > > draft by the chairs' deadline of October 6, so have not
> > made a proposal.
> > >
> > > But I'm not the one who argued for this to be put on the
> > agenda for 2 hours.
> > > The people who pushed for this to be on the agenda for 2
> > hours need to
> > > come forward and say why they believe this is a good use of
> > our time.
> > > I haven't yet heard a VP8 proponent saying so.
> > >
> >
> > I thought it has been mainly the VP8 proponents who have
> > insisted to continue this discussion and have it on the agenda.
> >
> > I am a H.264 proponent but it's clear to me there is no
> > consensus, no substantially new information since March, and
> > for that reason the IETF should not pick either H.264 or VP8
> > as *mandatory*. And consequently 2 hours is too much time for this.
> >
> > It is useful to discuss pros and cons of H.264 and VP8 and
> > compare them, since most likely every WebRTC endpoint will
> > implement at least one of them, but I think we need to stop
> > pushing for the decision of mandating one of them.
> >
> > Of course, if we come back to this issue every November, we
> > can eventually choose H.264 as mandatory, after all of its
> > IPR has expired :-)
> >
> > Markus
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb