Re: [rtcweb] Platforms that support H264 (was: Congratuiations on the Cisco announcement - but we still prefer VP8)

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

I suspect iOS will be the worst example. Apple likes h.264 and I think is actually most likely to release a Safari native h.264 WebRTC implementation vs any other option.... And I highly doubt they'll be using Cisco's module

To the degree this is about "enabling web browsers with Real-Time Communications (RTC) capabilities via simple Javascript APIs." they actually could check the box easily... And give you a UiWebView... Which may well make WebRTC wind up being the best way to get hardware 264 support in 3rd party apps... And hence push WebRTC even further.

And as always say "Apple iOS is supporting openness"...

Can't wait for those discussions  :-)

Sent from my iPhone

On Nov 2, 2013, at 10:38 AM, "cowwoc" <[e-mail]<mailto:[e-mail]>> wrote:


    How many platforms *really* support H.264 natively today?

    iOS is a great example. On paper, it supports H.264 but in reality the public API only supports H.264 decoding (not encoding). Then, when you try using that API for decoding you discover that it does not support real-time decoding (only decoding from file). So really, iOS doesn't actually support H.264 as required by WebRTC. Android is only marginally better in that respect.

    I can't think of a single platform that supports real-time H.264 encoding/decoding natively today.

Gili

On 02/11/2013 7:31 AM, Bernard Aboba wrote:
Not sure I understand this completely. Isn't support for "the Rube Goldberg Machine" needed only on platforms that do not natively support H.264?

On Nov 1, 2013, at 1:14 PM, "Justin Uberti" <[e-mail]<mailto:[e-mail]>> wrote:

I also want to reiterate that having a MTI codec means Mandatory To Implement.

That means, that should we decide to go down the H.264 path, Firefox and others will be forced to support this Rube Goldberg machine for obtaining H.264 for an indeterminate amount of time, long after WebRTC has moved on to prefer other codecs.


On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach <[e-mail]<mailto:[e-mail]>> wrote:
On 10/31/13 13:47, Harald Alvestrand wrote:

We congratulate Cisco on their intention to make an open source H.264 codec available and usable by the community. We look forward to seeing the result of this effort.


Google still believes that VP8 - a freely available, fully open, high-quality video codec that you can download, compile for your platform, include in your binary, distribute and put into production today - is the best choice of a Mandatory to Implement video codec for the WebRTC effort.

I agree with Harald that VP8 is a better codec than H.264 baseline in a number of important ways.

But I also want to reiterate that having an MTI codec has never been about choosing the best codec or even a good codec. It's about choosing an emergency backup codec-of-last-resort. It's about having one single mandated codec that everyone has in their back pocket in case nothing else works.

The core of RTCWEB is about session *negotiation*. Endpoints will negotiate the best codec they have in common. Once the next generation of codecs come out, this "best codec in common" will only be the MTI if they were about to fail anyway.

So it doesn't have to be good.

It just has to be better than failure.

/a

_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb


_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb



_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb


_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb