Re: [rtcweb] Platforms that support H264

[Gili <[e-mail]>]

     With respect, no. As I keep on repeating, there is a strong need 
for WebRTC outside of the browser. I don't see how I am supposed to 
integrate WebRTC into a closed-source iOS application if H.264 is MTI. I 
would be more than happy to revisit my position once someone provides a 
credible solution.

Gili

On 11/2/2013 11:16 AM, Jeremy Laurenson (jlaurens) wrote:
> 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]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rtcweb