Re: [rtcweb] Platforms that support H264

["Mo Zanaty (mzanaty)" <[e-mail]>]

Note that fixing the OS API issues helps all codecs. We should all be supportive of that, not using the issues as an excuse to ignore hardware benefits or abandon good engineering design. The Google Nexus 5 can encode and decode 1080p60 H.264 or VP8 fully in hardware. Why should Chrome, Hangouts or other Google apps not take advantage of a Google hardware codec on a Google phone/OS?

Forget H.264 vs. VP8 for a moment. If you have codec X available at 1080p60 in hardware, why fallback to software?

Randell, I feel your pain on getting hardware access to work reliably and universally. We have gone through this for several apps and platforms, and it is indeed a pain, and sometimes you still need software fallback. But it is better than giving up and always relying on software fallback. I applaud Firefox for wrestling with Android APIs, and encourage you and others to continue doing so for all hardware codecs. (We will get more than H.264 or VP8 in next year’s silicon, so this will pay off even more.)

Mo


On 11/5/13, 7:24 PM, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>> wrote:

Hi,

I agree there is definitely a need to improve the access to the H.264  “HW” codecs so they would be realistically usable for WebRTC or other interactive video apps. But that still seems to me as the best way forward compared to the other options. I know improvements are coming at least to Windows Phone and Windows RT.

Markus


From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of ext Justin Uberti
Sent: 06 November, 2013 00:58
To: Randell Jesup
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [rtcweb] Platforms that support H264



On Tue, Nov 5, 2013 at 6:58 AM, Randell Jesup <[e-mail]<mailto:[e-mail]>> wrote:
On 11/5/2013 12:55 AM, Mo Zanaty (mzanaty) wrote:
I’m serious. Name a device in mass production that is relevant to rtcweb but does not have H.264 hardware.

Plenty have hardware is out there that might not be optimized (or usable) for the types of arbitrary-sized, realtime simultaneous h.264 encode/decode.  Even just handling streaming decode on Android via OMX has been a year of pain for one of our engineers, because (especially before JB) the interfaces were unsupported, randomly modified/incompatible, and with lots of restrictions on what actually is supported.  Even with "perfect" API layers exposing them, the hardware layers (especially encoders) may not have the low-latency and other realtime characteristics needed, or knobs to tell them about things like packet loss reports that require IDR generation.  How many does this affect? who knows - and the API layers on top are inconsistent enough (or non-existent at the present) that it's especially hard to tell.

And many of them can handle only a single stream at a time; which makes "hangout"/simulcast cases more fun (need to run HW and SW in parallel, or drop to SW only - makes capability signaling fun too; the LCD of the SW and HW codecs needs to be what you offer probably, unless you want real pain).

Exactly. Name a 3rd-party software application in wide use on any of today's popular platforms that uses a H.264 HW encoder for rtcweb scenarios.




Your second point is valid; hardware is useless without supporting software. OS APIs to access codecs (both hardware and software, real-time and buffered) is an important issue. Android is the dominant OS on the planet. If you are not happy with its OS APIs, just change them; it’s open source like VP8 right?

Not really.  You can't modify the underlying OS provided by the manufacturer (no rooting of phones to run webrtc should be required...)  and even custom roms are going to get much harder or virtually impossible  with kitkat.  And witness my comments about the pain of platform decoders on Android today.

   Randell




Mo


On 11/5/13, 1:10 AM, cowwoc <[e-mail]<mailto:[e-mail]>> wrote:


    I'm not sure if you're being sarcastic or not...

    In any case, I had a question regarding BlackBerry 10. Are you implying that every BlackBerry 10 phone includes an API for real-time encoding/decoding of H.264 video streams? If so, which API is it? I took a quick look but couldn't find it.

Thanksm
Gili

On 04/11/2013 9:52 PM, Mo Zanaty (mzanaty) wrote:
I think you meant *every* phone, tablet, laptop, desktop, set-top, camera…


On 11/2/13, 7:41 PM, Kaiduan Xie <[e-mail]<mailto:[e-mail]>> wrote:

Every BlackBerry 10 phone has H.264 hardware encoder/decoder.

/Kaiduan

On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:


On Sat, Nov 2, 2013 at 1:01 PM, Gili <[e-mail]<mailto:[e-mail]>> wrote:
Martin,

    I fully understand why Firefox would be happy but as someone who plan to integrate WebRTC into a non-browser application, especially on iOS, Cisco's solution simply does not work. I appreciate their contribution, but again, it simply doesn't help my use-case.

I haven't seen  you explain how your use case is different from that of
a browser. Could you please do so?

-Ekr

Gili


On 11/2/2013 11:02 AM, Martin Thomson wrote:
On 2 November 2013 07:37, cowwoc <[e-mail]<mailto:[e-mail]>> wrote:
     I can't think of a single platform that supports real-time H.264
encoding/decoding natively today.
That's a very strange way to put the question.

Let me put another spin on it, and please excuse the example...

Skype runs on more platforms than you might think.  Those platforms
can all support H.264 to the extent that Skype requires.
Cisco's generous offer opens almost the same capability to anyone,
with the caveat that some platforms currently remain closed.  Of
course, you could let your ideals get in the way of progress.  Me, I'm
a pragmatist.  This gift represents a great opportunity for people who
actually care about the practical outcomes.

There's been a lot of mouth-gazing of gift horses on this list of
late.  I sure hope that this isn't representative of the real
sentiment of the community.  I'd like to think that people are better
than that.

(BTW, I understand and respect Harald's position.  From where he sits,
I'm sure that his conclusion makes perfect sense.)



--

Randell Jesup

[e-mail]<mailto:[e-mail]>

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