While scalability is often the first excuse some use not to use WebRTC, a persistent claim even though that myth has been debunked long ago and many time over since, “quality” is certainly the second one. Webrtc cannot do <put a resolution here>, it’s just good enough for webcams, it cannot use more than 2.5 Mbps, ….. . While all of those previous claims are false, there is one that was correct: the default audio codecs in webrtc implementations, and especially in browsers, are not as good when it comes to spatial info than their streaming or gaming counterparts… untill recently!
This is really a great week with so many of the projects cosmo has been working on or helping for the past years coming out almost at the same time. During last IETF Hackathon, at the webrtc table, and then at cosmo offices in Singapore, INTEL and Apple came together to add HEVC support in webrtc.
INTEL chips have been supporting Encoding and Decoding for some time now. They support it in non-GPU hardware, making it a big deal for devices that can’t afford full discrete GPU. Most Apple devices integrate those INTEL chip, so having support in WebRTC for H265 HW acceleration was de facto enabling H265 in all of Apple devices in one shot (without legal issues). Of course, the more support there is for INTEL features in media stacks above, the more hardware they sell. Win-Win
INTEL (webrtc group in Shanghai) had an implementation for Desktop, android and iOS. CoSMo acted as a catalyst between the two teams, and the two language/culture (chinese and french :-)).
This blog is about the tech details of H265 in particular, and Hardware Accelerated Codecs implementation in libwebrtc in particular.
Updated on april, 7th, to add info about GPU acceleration support, in addition to INTEL CPU HA acceleration support.
(*) CPU Hardware acceleration means the CPU has dedicated silicon circuit to implement the function, as opposed to running a software implementation in the generic x86 CPU. Even though both use the CPU, the former is much faster.
For the past weeks, lots of work was done to make Av1 available in libwebrtc in an easy way. It is very clear from the messages on discuss-webrtc that the compilation process behind chrome, electron and libwebrtc is more often than not too hard to understand, some extra time was spent to make it easier for people to enable it and use it. CoSMo has also prepared a separate GitHub repository with, wait for it, documentation ! Pre-compiled examples, an AV1-ready webrtc SFU, and KITE tests are also provided for people to adopt AV1 faster.
The work to add RTC AV1 in Chrome, which started in November last year is now well underway. Many people still ask the legitimate question: when will it be available and how good will it be. We had planned to deliver the implementation at IETF in Vancouver at the end of the month and make demos, but the IETF like many other events has been cancelled, so we are switching to weekly updates until the release, still planned for April. This post provides some information about both timing and quality questions.
Libwebrtc does not include support for H264 by default. While the code could support it, there are legal obligation when it comes to compile and distribute H.264 in your product: License and royalties! CoSMo just contributed a patch to make libwebrtc use OpenH264 (free as freedom) for encoding, and to dynamically load the Cisco provided library to make it free (free like beer).