What are the advantages of H.264 over VP8 in WebRTC?

This content was created by Tsahi Levent-Levi. This content was uploaded by Tsahi Levent-Levi. This is a YouTube video titled "What are the advantages of H.264 over VP8 in WebRTC?" created on October 4, 2024. It features a technical discussion about the advantages and disadvantages of using H.264 versus VP8 video codecs in WebRTC applications, focusing on aspects like hardware acceleration, battery life, and browser compatibility.
Chapters
What are the advantages of H.264 over VP8 in WebRTC? And we're talking about the video codec that we're going to use for our meeting or application. Okay. I would say there are two different angles to that. One is in the browser, the other is in a native application on mobile. In particular, the main advantage of H.264 is hardware acceleration, both in the encoder and the decoder. And on mobile that means battery life, which is you have no other choice in the browser on the desktop. The problem we have seen in the past is that the H.264 hardware encoders totally suck. They don't get you the target that you want. So Everybody does use OpenH264 for encoding in the end, or at least everybody who has spent enough time debugging that kind of issue. There are also other types of applications that end up in the browser, but not are kind of hybrid. I either need to encode in the cloud or I get the source of the data from somewhere else, for example a surveillance camera. Or I need to go and connect my application into a third party to be able to. I don't play back the file somewhere or stream it into something that isn't WebRTC. In many of these cases, VP8 is not even supported. So I need to use H.264 on the edges of my application. And that might get me to the point where I would say, well, I'd rather do H.264 end to end and not transcode somewhere to use VP8, which is better inside browsers or whatever it is that I need. Yes, yes. I mean, we've seen that recently in cloud gaming. We had an issue where on a certain Android Hardware decoder, the H264 encoder stream generated a lot of delay. And that turned out to be a case where we needed to do more tuning of H.264. And H.264 is a lot more flexible than VP8, but that flexibility also comes with a lot of things you can do wrong. Had it? Yes, yes. Okay. And why is H.264 not that good in the browser? Because Google doesn't really care because their calls are VP8 or VP9 and AV1. And if you look at the H.264 implementation in LibrePRC, it's basically a very unmaintained version of the old VP8 pipeline for decoding H.261. VP8 are very different codecs. They have very different features requirements. So I wouldn't use the H.264 pipeline as is. Yeah. So putting the effort in to actually fix that issue. So the main maintainer of Willy WebRTC, which goes into all browsers, doesn't use H.264 on their own. Hence they don't care about or don't maintain it as well as they do to the other video codecs that they have. Yes. Okay, thank you. Thank you.
More from Tsahi

Meta rebuilt AV1 for mobile scale. Should smaller teams follow? | Chats with Arin









