WebRTC is used on a massive scale thanks to Facebook messenger and Google, but when it comes to video streaming services, some find its open source codec VP8 too restrictive. WebRTC is actively evolving to adapt and become codec agnostic though this work is ongoing. In the meantime, Comcast is here to show us there is a way to inject the codec of your choice into WebRTC.
Finding that many of their video capture devices, CCTV cameras and the like, had hardware AVC encoders, Bryan Meissner explains Comcast didn’t feel it had much of a choice in codec, therefore they looked for a way to make WebRTC to carry AVC.
While forcing an unsupported codec into a protocol wasn’t ideal, they were able to leave much of WebRTC unchanged. The RTP and Data channels were established as normal and peering continued to work as ever. With control of both the send and receive side, the team found they could pick out the data from the WebRTC stack ahead of the normal decoder and feed that into Exoplayer using its API. This allowed playback on Android devices. Bryan goes on to explain the approach for iOS and web browsers. As WebRTC is ‘baked in’ to browsers, there really are very few ways to change the signal flow.
At the end of the day, Comcast made this work and used it in production or many years, Jeff Cardillo explains as he wraps up this video. But he also takes time to talk through some of the problems. Having to bypass parts of a program with parts of another library does increase complexity. Not only does the code become more complex but the code becomes platform specific, you need control over the source and keeping the individual parts synchronously up to date can be a balancing act.
Jeff finishes this talk from Demuxed SF 2019 by elaborating on the mobile and browser tradeoffs at play.
The ever popular, always analytical Jan Ozers spends time here evaluating the quality of these codecs against the ever-present h.264. As the team here at The Broadcast Knowledge takes a short break, we’re recapping the most popular posts of the year. Interestingly, this post is from over a year ago but is still seeing top-10 traffic. This is no surprise since, as I said in my interview with SMPTE on the subject of codecs, everyone touches codecs in some way even if only at home. So it’s no surprise there is such an interest.
Jan takes a careful approach to explaining the penetration adn abilities of h.264 in order to see at what point we can break even and start to ebenefit from using alternative codecs. He then takes each codec in turn looking at it its pros and cons to paint a picture of the options available for those willing and able to go beyond h.264.
AVC, now 16 years old, is long in the tooth but supported by billions of devices. The impetus to replace it comes from the drive to serve customers with a lower cost/base and a more capable platform. Cue the new contenders VVC and AV1 – not to mention HEVC. It’s no surprise they comptes better then AVC (also known as MPEG 4 and h.264) but do they deliver a cost efficient, legally safe codec on which to build a business?
Thierry Fautier has done the measurements and presents them in this talk. Thierry explains that the tests were done using reference code which, though unoptimised for speed, should represent the best quality possible from each codec and compared 1080p video all of which is reproduced in the IBC conference paper.
Licensing is one important topic as, by some, HEVC is seen as a failed codec not in terms of its compression but rather in the réticente by many companies to deploy it which has been due to the business risk of uncertain licensing costs and/or the expense of the known licensing costs. VVC faces the challenge of entering the market and avoiding these concerns which MPEG is determined to do.
Thierry concludes by comparing AVC against HEVC, AV1 and VVC in terms of deployment dates, deployed devices and the deployment environment. He looks at the challenge of moving large video libraries over to high-complexity codecs due to cost and time required to re-compress. The session ends with questions from the audience. Watch now! Speaker
President-Chair at Ultra HD Forum,
VP Video Strategy, Harmonic
Twitch is constantly searching for better and lower cost ways of streaming and its move to include VP9 was one of the most high profile ways of doing this. In this talk, a team of Twitch engineers examine the reasons for this and other moves.
Tarek Amara first takes to the stage to introduce Twitch and its scale before looking at the codecs available, the fragmentation of support but also the drivers to improve the video delivered to viewers both in terms of frame rate and resolution in addition to quality. The discussion turns to the reasons to implement of VP9 and we see that if HEVC were chosen instead, less than 3% of people would be able to receive it.
Nagendra Babu explains the basic architecture employed at Twitch before going on to explain the challenges they met in testing and developing the backend and app. He also talks about the difficulty of running multiple transcodes in the cloud. FPGAs are in important tool for Twitch, and Nagendra discusses how they deal with their programming.
The last speaker is Nikhil who talks about the format of VP9 being FMP4 delivered by transport stream and then outlines the pros and cons of Fragmented FMP4 before handing the floor to the audience.