Qualcomm Will Support AV1 Video Codec In 2023, Report Says (arstechnica.com) 36
Protocol reports that Qualcomm will finally jump on the AV1 video codec bandwagon next year. Ars Technica reports: AV1 is the web's next open, royalty-free video codec, and widespread adoption will require hardware support from the world's chip vendors. Qualcomm's 2022 flagship SoC, the Snapdragon 8 Gen 1 chip, doesn't support AV1. Samsung's Exynos 2200 managed to ship the video codec this year in international versions of the Galaxy S22, while the MediaTek Dimensity 1000 SoC has been shipping in phones for over a year now with AV1 support. Apple is a founding member of the AV1 Alliance, but its devices also don't support the codec yet.
The report says Qualcomm's "upcoming flagship Snapdragon mobile processor" -- model number "SM8550" -- will support AV1. That would probably be called the "Snapdragon 8 Gen 2" SoC, due out in 2023. Wide adoption of AV1 seems inevitable, though it is taking a while. The codec is a successor to Google's VP8 and VP9 codecs and is being built by the Alliance for Open Media. The alliance's lineup is a who's who of tech companies, with founding members like Amazon, Apple, ARM, Facebook, Google, Intel, Microsoft, Mozilla, Netflix, Nvidia, and Samsung. Netflix and Google's YouTube are both making AV1 support "a requirement" for future products that want to support either video service. That should motivate just about every hardware and software vendor out there to get the job done. Aside from being open source and royalty-free, the report notes that the newer AV1 codec also has the benefit of being 30% more efficient than H.265.
The report says Qualcomm's "upcoming flagship Snapdragon mobile processor" -- model number "SM8550" -- will support AV1. That would probably be called the "Snapdragon 8 Gen 2" SoC, due out in 2023. Wide adoption of AV1 seems inevitable, though it is taking a while. The codec is a successor to Google's VP8 and VP9 codecs and is being built by the Alliance for Open Media. The alliance's lineup is a who's who of tech companies, with founding members like Amazon, Apple, ARM, Facebook, Google, Intel, Microsoft, Mozilla, Netflix, Nvidia, and Samsung. Netflix and Google's YouTube are both making AV1 support "a requirement" for future products that want to support either video service. That should motivate just about every hardware and software vendor out there to get the job done. Aside from being open source and royalty-free, the report notes that the newer AV1 codec also has the benefit of being 30% more efficient than H.265.
AV1 vs HEVC is the new VHS vs BetaMax (Score:2)
Wrong. (Score:2)
AV1 is both cheaper and higher quality. If Betamax was lower quality then VHS then this analogy would make sense but alas it is not.
Furthermore, it's highly likely that large video sites (youtube, etc) will continue to serve HEVC for quite some time when the AV1 codec is unavailable. I expect it will require a minimum of five years to achieve 70% market penetration because all the "smart" devices (phones, TVs, tablets, android STBs) have to be replaced.
Re: Wrong. (Score:3)
Maybe it can, but nobody wants to do this as a mass or common solution because it drains the battery.
Re: (Score:3)
AV1 will eventually win out over the patent-encumbered and expensively-licenced HEVC
Aye. That's why ogg won the MP3 format.
I kid. But it does indicate that installation base and vendor support are two extremely huge aspects to any format. AV1 coming into hardware Snapdragon is a good move. Just putting the silicon in there will help adoption. That said, there's still a lot of software vendors that have strong buy in with MPEG-LA and MPEG is a very good salesman.
Re: (Score:2)
Sometimes better mouse traps do win. It seems Optus is gradually replacing everything, albeit at a glacially slow pace.
Re: (Score:3)
All the most popular video streaming sites use free audio codecs that are not patent encumbered. For example, YouTube defaults to Opus audio.
Opus is the replacement for OGG Vorbis.
Spotify (Score:2)
That's why ogg won the MP3 format.
I kid.
You never paid attention to the formats used internally by Spotify [spotify.com], did you?
Ogg Vorbis is used on desktop/mobile/tablet, (AAC is for the web). [wikipedia.org]
So yes, Ogg/Vorbis actually won against MP3, and it's successor (to which Xiph also contributed) Opus would be displacing its AAC in the future.
Turns out, when content providers own the whole delivery chain including the client software, trying to get rid of intermediates known for their predatory licensing costs will have an influence on the popularity of license-fre
Re: (Score:2)
Re: (Score:2)
If that were the deciding factor then HD-DVD would have beat Blu-ray. Unfortunately it has more to do with the desires of who provides the content then either the hardware manufacturer's or the public. If there's nothing to watch on the superior platform, then no one will use it.
"will require hardware support" (Score:2)
"will require hardware support from the world's chip vendors
Why "require"? Couldn't it be done in software although less efficiently?
Playing video isn't that resource intensive, it isn't like rendering vector graphics with GL or DirectX. My old 486 could play many video formats fine without an hardware chip to transcode the video. The general purpose CPU was doing the job fine.
Re: (Score:2)
I don't think a 486 could have handled MPEG-1. According to contemporary sources, a 486 would have been able to only manage 8 FPS, while it would have taken a Pentium 90 to get 30FPS.
Re: (Score:2)
It more likely would have been Cinepak, Indeo, or one of the early Sorenson codecs, but the GP is correct that multiple video formats could be played in software on a '486.
Optimization (Score:2)
There is video of an 8088 based PC playing back MPEG1 video. It's low color, very low res, but it can be done. Some lunatic hand-assembled a decoder.
I'd imagine a 486 could to a lot more, but it would probably require, again, hand assembly for a particular video card, and the whole thing running in DOS where there is no multithreading or memory segmenting gobbling up clock cycles.
Re: (Score:3)
it would probably require, again, hand assembly for a particular video card and the whole thing running in DOS where there is no multithreading or memory segmenting gobbling up clock cycles.
Yeah, no. That's not the way things were at all Any generic VGA card would do. Don't you remember Quicktime and Video for Windows?
By the time I got a 486 66 (1994?), there was already tons of video content available on various CD ROM titles. Multimedia was all the range. Hell, even Visual Basic included a video player component so you could easily include video content in your own programs.
Video was old hat by the time Windows 95 rolled around. I'd even be willing to bet that any computer you bought i
Re: (Score:2)
they cheated, it wasn't even 480i, it was something way less than that, like 1/4 for most of that...
Re: (Score:2)
Re: Optimization (Score:2)
DVD support required a hardware decoder for MPEG-2 video on a Pentium system when I wanted that in 1999. My memory is a bit fuzzy on the details now, but it's possible that it came via my SoundBlaster card. Certainly a 486 could have played video in software a few years before this, but not good quality video.
Re: "will require hardware support" (Score:2)
Re: (Score:2)
Why "require"? Couldn't it be done in software although less efficiently
On a desktop PC, sure. But most people consume streaming media on little boxes with no airflow crammed behind their TV, and on mobile devices with similarly poor CPU cooling designs. Software decoding is incredibly inefficient, and if that means your device might overheat (and if running from a battery, rapidly drain) just from playing a video, the codec is a no-go.
Re: "will require hardware support" (Score:2)
I don't think it's fair to say that software decoding is incredibly inefficient. Computational expensive might be a better description. Sure, some decoders are a bit crap and inefficient (not mentioning any of those in a popular OSS productâ¦), but codec manufactures generally heavily optimise them to make them more efficient because they need them in a transcoding pipeline and don't want to be taking CPU cycles away from the encoder(s) of unduly increase decoding latency, especially for live us
Re: (Score:2)
You might be surprised, when WebRTC standard was created they did a bunch of testing. For example a tablet would use more power transferring the bits over WiFi or 4G (same applied to the screen) than it would use CPU power to decode video in software.
Re: (Score:2)
The Dav1d av1 decoder is written in C and has hand coded assembly for many operations for most common CPU architectures (certainly x86 and ARM, I'm not sure which others) so if your smartphone isn't very old it can decode av1 in real time for at least 720p resolutions. Again, not optimal, but doable.
Re: (Score:2)
Why "require"? Couldn't it be done in software although less efficiently?
Generally people don't like their smartphone/laptop to lag while doing video playback and getting so hot that it actually could catch fire. Lesser devices simply won't have the processing power to keep up with real-time decoding.
Playing video isn't that resource intensive
Displaying the video is not the problem, it's decoding the video in real-time that is the issue. The math behind video codecs it has become outstandingly sophisticated which is how we've managed such incredible compression rates.
Re: (Score:2)
Why "require"? Couldn't it be done in software although less efficiently?
On SoC? Hell no. The only reason any SoC does the audio and video it does do is because of hardware. There's maybe a handful of codecs that might be able to run somewhat on SoC chips, especially RISC like ARM type chips. ARM does include Neon for SIMD like ISA, but SoC get away with things because they usually pawn off vector like processing for discrete hardware. That's why software in amd64 is easy stuff and near impossible with SoC. It ain't the clock, it's the ability to use a parallel pipe in the
Storage space, not energy (Score:1)
Aside from being open source and royalty-free, the report notes that the newer AV1 codec also has the benefit of being 30% more efficient than H.265.
It's important to make the distinction that they're referring to storage space, not the amount of energy used to compress/encode the video. According to Wikipedia, AV1 is actually more CPU intensive to encode than h.265, so while it saves space, it requires more electricity (and h.264 is less CPU intensive to encode than h.265, which is why even today, the older h.264 codec is still widely used). This seems to be mostly because the developers are more concerned with avoiding patent landmines rather than o
Re: (Score:2)
While they may not be able to save storage space, they are mostly talking about size with respect to bandwidth.
On the storage front, the situation may be more nuanced. Do they keep pre-encoded, or transcode on-demand? To the extent they keep pre-encoded, how many copies do they need to deliver appropriate performance given how popular/unpopular the restricted devices are? Over time, they may be blocked as 20% of their viewers don't have capable hardware, but if only 20% need the older format, then that m
Re: (Score:2)
Comparing software implementations, AV1 requires about 10 times more power to decode than x265, and about 30 times more power to encode when using a single CPU [winxdvd.com]. AV1 is better at using multiple CPU's that x265 so real time is not quite as slow, but still unusable. That sounds bad, but it's really no different to x265 which is also unusable without hardware assist. Intel GPU drivers for modern chips support both for decoding.
Re: Hardware vs software (Score:3)
Are you mixing up encode and decode?
x265 is not a good benchmark for HEVC quality and performance. x264 sets the bar for AVC quality, at least at lower reductions, x265 is a different product from a different company and set of developers and only really has its name and OSS status in common.
Re: (Score:2)
Re: Hardware vs software (Score:4, Interesting)
Don't get me wrong, any HEVC encoder is probably going to give you significantly better results than an AVC encoder, and perhaps by a long way.
I'm not sure about the free encoders - I think SVT-HEVC for example isn't as good, even though I find SVT-AV1 is more production usable than AOM's AV1 encoder. Unless you really want to go hunting for a better alternative (see below), x265 is probably ok for home videos, even if there are much better options out there.
Further reading/viewing if you're interested:
The commercial codecs tend to improve a lot over x265, for example MainConcept's is 20% better. For personal use, I'm not sure it's available for (maybe ripped somewhere?). An older version used to be embedded in DivX's free consumer software, but they're basically dead after they were divested a few years ago. Table 3 on this page shows that you have to raise the bitrate of x265 by nearly 25% to match the MainConcept HEVC encoder's quality: https://www.streamingmedia.com... [streamingmedia.com]
You can download the free MSU report (Dec 2021) that shows a bunch of others too (as well as comparisons against VVC and AV1), but probably won't help you chose a different encoder. Choose "Mean Overall Quality for 2 usecases" in the downloaded HTML page for an easy to view chart. You can get it from here: http://www.compression.ru/vide... [compression.ru]
Streaming Media also did a webinar last night comparing EVC, LCEVC, and VVC with H 264, HEVC, and AV1. This is here: https://www.youtube.com/watch?... [youtube.com]
Re: Hardware vs software (Score:2)
Re: (Score:2)
That article also says AV1 is 3000x slower.
It's pretty obvious whatever software they're referencing is not optimized; perhaps reference code.
The industry isn't going to get behind a standard that has those claimed massive deficits.
Re: (Score:2)
I saw some benchmarks recently of Mainconcept's HEVC encoder vs. SVT-AV1: the performance level where SVT beat Mainconcept in quality on an i9 for a 1080p stream, SVT was an order of magnitude slower. It was 45dB versus 45.5dB PSNR difference, which isn't visually noticeable to anybody so pretty pointless. At the same speed, AV1's quality was lower. The person creating the benchmarks didn't want to test SVT-AV1 at higher resolutions or with slower presets because it just takes too long (like a week+ for
Will 2023 be... (Score:2)