3

I know well that H.264 support is not the goal of WebRTC's current maintainers. However, while poking around the native code, I noticed some commented out bits referring to an H.264 RTP packetizer. The environment I'm working on is the OMAP4430, which has hardware-accelerated support for H.264 SVC encode/decode, so it'd be great if I could re-add H.264 support to native WebRTC for my application. (VP8 is extremely slow on my device.) Is starting with the packetizer currently in the project a good start? Has anyone done this / have recommendations for how to go about adding H.264 support? (I plan on sending the H.264 WebRTC data to Doubango's Media Breaker to provide support for regular WebRTC clients.)

If the above is absolutely not possible or very hard, can anyone at least recommend how I might get better VP8 performance on my device? It's a NEON-based ARM SoC, so I would imagine libvpx should automatically take advantage of that. Is there any way to know for sure?

Dany Joumaa
  • 2,030
  • 6
  • 30
  • 45

1 Answers1

3

"H.264 support is not the goal of WebRTC's current maintainers" is not correct at all.

The IETF has not made a decision as to whether VP8 or H.264 or both will be mandatory to implement yet.

Google, who hosts webrtc.org obviously wants their own VP8 codec in there, so there is nary a mention of 264 on their site or their example code... doesn't mean that how this will all end up.

I would visit ietf.org and sign up for the WebRTC email list - and ask for some help there. :-)

JeremyLaurenson
  • 979
  • 2
  • 11
  • 23
  • Thanks for an explanation of the politics here. I figured something was up, especially considering the fact that some H.264 code exists in the codebase even today! – Dany Joumaa Oct 03 '13 at 17:13
  • By the way, news as of December is that VP8 AND h.264AVC are mandatory for Browsers. – JeremyLaurenson Jan 09 '15 at 21:49