For many transcoding workflows, efficiency or quality are the primary factors defining how they are created. But when ingesting user-generated videos like those uploaded to the online video platform, Vimeo, life gets difficult. Dealing with the wide variety of formats uploaded and the many edge cases in the way that otherwise normal AVC videos are delivered means throwing out any assumptions you ever had and analysing every aspect of the file.
Senior video encoding engineer, Derek Buitenhuis takes us through the many lessons he and his colleagues have learnt over the years. Don’t, he says, assume that properties don’t change between frames – sometimes they change in every single frame. Assuming that you have a single frame rate throughout the video is another ‘no no’ as there are many variable-frame rate videos.
Derek also looks at dealing with samples stamped with negative timestamps, the need for sample durations, the myriad of issues seeking through a file, the fun of having some frames that aren’t displayed and multiple-track videos.
Colour spaces, no surprise to anyone, cause handling difficulties for example if the bitstream colour properties are different to those in the container. As the talk finishes, we’re left considering old MPEG2 files that can have unavoidable banding, replicating looping MOV files, and dealing with QuickTime special effects channels that animate a fire on the screen.
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
Subscribe to get daily updates
Views and opinions expressed on this website are those of the author(s) and do not necessarily reflect those of SMPTE or SMPTE Members.
This website is presented for informational purposes only. Any reference to specific companies, products or services does not represent promotion, recommendation, or endorsement by SMPTE