8 ms·
Qualcomm is adding AV1 support, which could be huge for online video
- shmerl 5y agoWill RDNA3 cards have AV1 encoder? RDNA2 ones got the decoder at least. With encoders in place, video calls can start using AV1 too.
- kbumsik 5y agoAFAIK, none of commercially-available hardware supports AV1 encode yet. I guess it is quite expensive to implement AV1 encoder. Edit: I meant no consumer hardware support it.
- shmerl 5y agoWell, RDNA3 GPUs aren't available yet either. But at some point encoders should become viable I suppose.
- wmf 5y agoIntel's upcoming DG2 has AV1 encode. https://videocardz.com/newz/intel-confirms-arctic-sound-m-data-center-gpu-features-dg2-processor https://videocardz.com/newz/intel-confirms-arctic-sound-m-da...
- kbumsik 5y agoThat is for data centers though. Oh I did a typo. There still is no consumer-grade product supports AV1 encode.
- aesh2Xa1 5y agoDG2 has a codename "Alchemist" and it's a mid-range card line that targets gamers, too. You're still right that there's no standard, consumer-focused card, but that's "yet" – the product is just launching later this year.
- klodolph 5y agoI wonder what the timeline is from “encoder appears in consumer chip” to “people use it for video calls”.
- clouddrover 5y agoCisco's WebEx uses AV1: https://blog.webex.com/engineering/the-av1-video-codec-comes-to-webex/ https://blog.webex.com/engineering/the-av1-video-codec-comes... https://blog.webex.com/video-conferencing/cisco-leap-frogs-h-264-video-collaboration-with-real-time-av1-codec/ https://blog.webex.com/video-conferencing/cisco-leap-frogs-h... https://www.youtube.com/watch?v=Op-rzboJ_1Q https://www.youtube.com/watch?v=Op-rzboJ_1Q
- brigade 5y agoI think it's negative for every major codec thus far, except maybe VP9 (did any videoconferencing apps use VP9?) H.263, H.264, VP8, HEVC, and AV1 certainly were all used by various videoconferencing apps before hardware blocks reached consumer devices.
- _joel 5y agoLinphone if you mess with it.
- SoapSeller 5y agoNvidia Orin(the SOC, successor to Xavier) that coming out this Q will have AV1 encoding(up to two streams of 4K60). One can assume next gen nvidia gpus(rumored for the end of this year) will have it as well.
- Dylan16807 5y agoOn the desktop you can probably spare a core or two for encoding just fine.
- shmerl 5y agoTrue, but it can still be pretty CPU intensive. Plus on laptops it's a bigger deal.
- LinAGKar 5y agoA core or two is not enough for high quality real-time encoding.
- Dylan16807 5y agoSays who? Software encoding works just fine for current video call applications, and also most twitch streams, without using more CPU than that. If you mean AV1 specifically, do you think software encoders won't get anywhere near x264, which can do it in less than one core?
- realityking 5y ago> If you mean AV1 specifically, do you think software encoders won't get anywhere near x264, which can do it in less than one core? From what I understand, AV1’s encoding complexity is more like H.265 than H.264. It’d be more appropriate to look at the performance of x265 to see what might be possible.
- LinAGKar 5y ago>Software encoding works just fine for current video call applications Current video call applications look like crap >also most twitch streams Don't they use hardware encoding when possible? And higher bitrate than video calls. >do you think software encoders won't get anywhere near x264, which can do it in less than one core? Not at full quality
- 8K832d7tNmiQ 5y agoThere is no additional benefit to use AV1 for video calls since VP9 can do that just enough for the next 5 years.
- shmerl 5y agoIsn't it supposed to have lower bitrate for the same quality? If there wouldn't have been any benefits they wouldn't have developed a whole new codec.
- IshKebab 5y agoI don't think bandwidth is the main challenge with video calls. Packet loss and latency cause far more quality issues.
- wtallis 5y agoPacket loss and increased latency are the main symptoms of using more bandwidth than the network can reasonably provide.
- bawolff 5y agoIn live video, latency from encoding is a limiting factor for what types of compression you can use. Its not like bandwidth is the sole limiting factor here.
- shmerl 5y agoI don't think you can just dismiss bandwidth concerns, especially when you consider video conferencing.
- LinAGKar 5y agoI can still see compression artifacts, so it's clearly not using enough bandwidth. It could probably compress it better if it had hardware available, rather than needing to do real-time encoding in software (since it doesn't have a VP9 encoder either).
- kmfrk 5y agoWe only just got AV1 decoding on the latest gen of GPUs, it might be too optimistic to hope for encoding in the next one. In 2019, Twitch predicted roll-out of AV1 support by 2024, but then the pandemic happened: https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=131163 https://www.streamingmedia.com/Articles/ReadArticle.aspx?Art...: > For head content, it's okay to streaming multiple formats because the viewership is huge, so streaming multiple formats, although increase our cost, it still actually save our traffic cost, so it's still worth while. But for the tail content, it's very different. We can only afford streaming one single format, so our strategy is currently still doing H.264 using hardware, high-density hardware solution, but we're hoping towards 2024, 2025, the AV1 ecosystem is ready, we want to switch to AV1 100%. > > Jan Ozer: Did you say 2024 and 2025? > > Yueshi Shen: 2024, this is our projection right now. But on the other hand, so as I said, our AV1 release will be, for the head content will be a lot sooner, we are hoping 2022-2023 we are going to release AV1 for the head content. But for the head content, we will continue to stream dual-format, AV1, H.264. But for the tail content, we are hoping towards five years from now to AV1, whole eco, every five-year-old device supports AV1. Then, we will be switching to AV1 100%. The initial roll-out will probably just involve transcoding at sub-source quality settings to save bandwidth with no encoding to be done by the streamer. Right now, platforms have only talked about AV1 for transcoding purposes, so there's not the same urgency to add encoding support on consumer-level GPUs. Even thought it'd be amazing to see AV1 streams and YouTube videos, it's mostly on the server-end to cut costs and make things easier on people with data plans and cellular.
- The_rationalist 5y agoEnergy consumption of HW accelerated AV1 decoding vs h265?
- ZeroGravitas 5y agoSofware decode is broadly comparable so should be about the same. Later generations often have more tools, which can lead to bigger die size, but this can also lead to energy gains from those tools depending on content/usage. See cisco's presentation about adding AV1 to Webex and how it could outperform H264 in this niche due to having specific tools for it. In Netflix type content the grain emulation for example could make a big difference.
- viktorcode 5y agoNote, no support for hardware encoding was announced by Qualcomm. Decoding only. This seems to repeat the trajectory of VP9, where it exists and is supported solely thanks to YouTube, while the whole world is utilising H.265 for everything else, including recording video on smartphones. It very well may be AV1 and H.266 will play the same roles in the future.
- ksec 5y agoIt will be interesting to see if Google will include AV1 encoder in their Pixel Phone and eventually give away hardware AV1 encoder IP. But Google has never been a coherent company.
- aesh2Xa1 5y agoWhat does it take to integrate an encoder into hardware? Could you explain? AV1 is an open, royalty-free codec, so I don't understand how Google could help competitors. Maybe Google is in a place to give away knowledge, although I doubt they know more about a competitor's chip design.
- oefrha 5y agoThe reference software implementation (libaom) is royalty-free. Any company can come up with their own proprietary implementation, including in hardware. There are no royalty-free hardware designs at the moment.
- lapinot 5y agoWell, the actual standard is royalty-free and that's what we usually mean by royalty-free in this context. A royalty-based standard requires you to purchase a license for developing your own implementation of it.
- oefrha 5y agoYes. The codec itself and the reference implementation are both royalty-free, so we’re both right. The implementation part is more relevant here since gp was asking about it.
- BluSyn 5y agoI'm hoping future Apple chips have AV1 decode support as well. If Intel, Google, Qualcomm, and Apple all add AV1 support in hardware, it would become the gold standard as far as codecs go. Right now it's all a mixed bag.
- ChuckNorris89 5y agoConsidering Apple's love for proprietary everything and their large market share, I wouldn't be surprised to see them roll out their own codec in SW and HW, same how they developed Metal instead of using the open Vulkan.
- threeseed 5y agoa) Apple has always been an active part of the MPEG standards group for decades so not sure why they would roll their own. b) CoreGraphics and CoreAnimation are underpinned by Metal. If you were building an OS that was going to be used by every device you make (computer, phone, tablet, monitor, watch, TV streamer, headset) would you rely on an open source project that you don't control and may have different values, wishes, roadmap etc than you.
- jhasse 5y agoyes
- throw0101a 5y ago> If you were building an OS that was going to be used by every device you make […] would you rely on an open source project that you don't control and may have different values, wishes, roadmap etc than you. Apple's XNU kernel is a derivation of open source OSFMK and FreeBSD kernels, and Apple's Darwin has large components of FreeBSD userland. They use (se)L4 for running their Secure Enclave. I remember in the early days of MacOS where entries from the FreeBSD release notes would appears as word-for-word copies in the Apple ones.
- mhh__ 5y agoYou could still open source the work afterwards.
- ZeroGravitas 5y ago> Uptake of the open-video codec AV1 has been slow, with major video providers waiting for broader device support. The people involved in AV1 had a software decode plan B that has worked better than most of them hoped. If you combine that with encoding choice based on software decode impact, most big players have started with software rollouts, but still seen gains. "You need hardware support for a codec" is often the same kind of delaying tactic as "renewables need storage". You do both in parallel, not enter an infinite loop where you don't do either because the other isn't complete yet.
- deleted 5y ago[deleted]
- tarsinge 5y agoHardware support for a codec is a business decision decision, it doesn’t require a tech/physics breakthrough as renewables storage at city and country scale does, it’s not remotely comparable.
- asdfasgasdgasdg 5y agoRenewable storage is also a business decision? Like we know how to build enough storage, it's just very expensive using current technology. In the limit, you can just make a lot of these: https://e360.yale.edu/features/in-boost-for-renewables-grid-scale-battery-storage-is-on-the-rise https://e360.yale.edu/features/in-boost-for-renewables-grid-...
- CodesInChaos 5y agoThat article is pretty confusing, since it only talks about the power of those batteries, not how much energy they can store. Or is it confusing MWh with MW?
- asdfasgasdgasdg 5y agoI don't necessarily vouch for this particular article. My point is merely that grid scale battery is no longer a question of technology, but money.
- rdsubhas 5y agoThis looks quite big for battery life. Any idea how much this would improve battery life (assuming a mobile device is continuously playing video?)
- gjsman-1000 5y agoAV1 has had several issues plaguing its uptake (as a close observer of the technology): - The reference silicon design for an AV1 decoder was very space-inefficient, and so many chip vendors refused to use it. This, however, necessitated the development of internal or 3rd-party decoding IP which slowed uptake considerably. - AV1, partially due to it's patent-free design, has an extremely complicated compression process. So complicated, that even in software it is still a few dozen times slower than H.264 encoding. This, plus the first issue mentioned above, means on-chip AV1 encoding is a ways away. - AV1, despite being "patent-free," has had a patent troll (Sisvel) come along and claim that they have a bunch of patents applying to it. They want 20 cents per device. AV1's founding group claims to have a legal defense fund for members but the terms and coverage are unclear. Sisvel wants 20 cents per device using AV1, so now you need to get the lawyers involved to figure out whether to bet on paying Sisvel or bet on taking the AV1 founder's view of the matter. - Finally... there's AV2 coming. Though a ways away, it will use recently-expired patents to further help its compression capabilities, new techniques that couldn't be completed on time for AV1, and will feature a more optimized reference silicon implementation that might be actually easily usable by chip designers this time.
- chasil 5y agoThe wiki mentions that the original reference encoder was not optimized, and did not perform well: https://en.wikipedia.org/wiki/AV1#History https://en.wikipedia.org/wiki/AV1#History "While still working on the format, the encoder was not targeted for production use and speed optimizations were not prioritized. Consequently, the early version of AV1 was orders of magnitude slower than existing HEVC encoders. Much of the development effort was consequently shifted towards maturing the reference encoder. In March 2019, it was reported that the speed of the reference encoder had improved greatly and within the same order of magnitude as encoders for other common formats." Other encoders also exist that are much faster, listed in a different section of the wiki. https://en.wikipedia.org/wiki/AV1#Software_implementations https://en.wikipedia.org/wiki/AV1#Software_implementations I didn't know about Sisvel and the hardware design problems, although Sisvel is in the wiki. The specific license fees that you listed are interesting. https://en.wikipedia.org/wiki/AV1#Patent_claims https://en.wikipedia.org/wiki/AV1#Patent_claims