Sunday, October 11th 2020
AMD RDNA2 Graphics Architecture Features AV1 Decode Hardware-Acceleration
AMD's RDNA2 graphics architecture features hardware-accelerated decoding of the AV1 video format, according to a Microsoft blog announcing the format's integration with Windows 10. The blog mentions the three latest graphics architectures among those that support accelerated decoding of the format—Intel Gen12 Iris Xe, NVIDIA RTX 30-series "Ampere," and AMD RX 6000-series "RDNA2." The AV1 format is being actively promoted by major hardware vendors to online streaming content providers, as it offers 50% better compression than the prevalent H.264 (translating into that much bandwidth savings), and 20% better compression than VP9. You don't need these GPUs to use AV1, anyone can use it with Windows 10 (version 1909 or later), by installing the AV1 Video Extension from the Microsoft Store. The codec will use software (CPU) decode in the absence of hardware acceleration.
Source:
Microsoft Tech Community
42 Comments on AMD RDNA2 Graphics Architecture Features AV1 Decode Hardware-Acceleration
You need advancement in compression tech to make this better content feasible. Wanna try ripping a 4k bluray and converting it to MPEG-2, with no perceptible loss in quality, and see what the resulting filesize is?
I for one would love to download over 2 GB for less than two minutes of video /s
MPEG-2 is actually a lot smaller than the H264 at max quality, but apparently it's not supposed to support 4K, so I'm not sure if it played fine because Media Player Classic is just that great or if it the table below is wrong (or maybe I'm misunderstanding something).
I ran this test using Handbrake "Production Max" preset, with two config subsets. The "normal" one, while changing only the CQ, and the "special" one where I also removed a few encoder settings that were set manually into Handbrake by the developer. I had to do a little research for this, but it was kinda fun :laugh:
The encoder additional options that I removed were:
[ICODE]keyint [/ICODE]and [ICODE]min-keyint[/ICODE], which control the interval between IDR frames. Just to explain it quickly here for those that do not know it (and if someone is well versed in this stuff and spots an error, do tell), H264 uses "reference" frames (IDR frames) that contain a full picture (this type of frames which are "full pictures" are called I-frames, but not all I-frames are IDR frames, depending on encoding settings), while the following frames only tell the decoder what has changed. They also act as a separator of sorts, since a frame can't reference any other frame that is on the other side of the IDR frame. They're quite useful for the fast-seeking feature of nearly every media player out there, but they're rather large, so letting the encoder use a larger interval saves a few bytes here and there. The original setting was 12 frames per IDR frame, removing this option let the encoder use one IDR frame per 300 "normal" frames.
[ICODE]ref[/ICODE]. This controls the size of the Decoded Picture Buffer. This affects the so-called P-frames (frames that only contain differences compared to previous frames). The normal Prod. Max preset only lets a P-frame reference the previous frame. Removing this setting lets a P-frame use more (in this case, since I used only the "fast" encoder preset, the encoder used 2 ref frames. The slower/higher encoding quality presets allow for up to 16 ref frames, but the 3820x2160 resolution enforces the 5.1 encoder level, which is limited to a maximum of 5 ref frames)
[ICODE]bframes[/ICODE]. This one controls B-frames (which are similar to P-frames, but can also use the future frames as reference, not just the previous ones). Again, the fast preset uses only 3 frames, but H264 supports up to 16 frames for this.
[ICODE]dct-decimate[/ICODE]. DCT Decimation allows the x264 encoder to skip encoding any of the blocks which it views as redundant information. These blocks are the not written to the output file, effectively reducing the bitrate. Blocks are basically arrays of pixels, as I understand it. The option was set to 0 (no decimation), but I removed it. Again, I think this might be affected by both the encoder preset and the quality control, so maybe using a lower quality or a slower encoder preset would have yielded a bigger size saving?
[ICODE]fast-pskip[/ICODE]. By default, x264 will skip macroblocks in P-frames that don't appear to have changed enough between two frames to justify encoding the difference. This considerably speeds up encoding. When this parameter is not set explicitly, it's controlled by the encoder preset and quality control, from what I have observed.
I left the other options (qcomp, aq-strength and deblock) alone, since they are still a little beyond my understanding and do not really change the size of the video stream. They deal mostly with quality concerns according to the content you're encoding, or at least that's what I understand after looking through a bunch of pages.
Though, do you actually plan to use AV1 for something?
To be fair, Handbrake itself suggests using CQ20 to 23 for high def sources (btw, CQ15 and lower qualities yield a smaller size than CQ1 MPEG2)... I suspect that using a higher quality level isn't really worth it unless the source has some peculiarity. Even then, a skilled encoder might be more interested in using some other parameter, like the encoder tune or even using a command line and being very specific about things like adaptive quantization (which sounds so sci-fi, frankly :laugh: ), rather than simply raise the quality factor.
Netflix, youtube, etc etc etc, they all gotta use compression in order to save space. I mean as a big video provider most of the costs are going to uplink saturation. You pay per Gbit uplink basicly. Well the more video you can push through that connection the better. And even if it's 10% savings; it's still 10% on a dozen of video's on which it counts.
Point is, everyone should have control over what is available to them to stream. Let the users decide if they want to consume more bandwidth. My ISP has no care how much I use my internet connection (so long as what I do isn't illegal), why won't all the streaming services allow me to stream at uncapped bitrates in 1080P or 4K?
That said, your ISP does care, they all want us to pay as much as possible and use it as little as possible, as they pay for the bandwidth they use as an ISP, especially if the traffic goes outside of their network.
This is why Netflix for example has some of their servers co-located with large ISPs. This lowers the ISPs costs, as the videos you're streaming are all local on the ISPs network.
Besides the cost for Netflix, what will happen if everyone would suddenly request full-quality 4k HDR to watch at the same time? Especially those that watch on their smartphones.
The silver lining (if you can call it that) is even at its worst, Netflix still looks miles better than TV broadcast.
TV broadcasts are mainly in either old fashioned 480/525p, 720p or 1080i. I don't think there's a single country that broadcasts in 1080p, unless it's via satellite and then only a few select channels are in 1080p. It's simply too bandwidth heavy for the old infrastructures that are being used for broadcast TV, as DVB/DVB-x2 is simply not using efficient enough encoding and ATSC so far is no beter. ATSC 3.0 would be the first standard that can offer really high quality broadcast TV as it's using HEVC encoding and it's designed for 4K transmissions. However, it seems like it's not reaching all that wide adaptation due to the costs involved at the moment and it's not a requirement in new equipment by the FCC, which generally means adoption rates in the new hardware will be low.
Then again, streaming seems to be the future, as it allows you to watch what you want, when you want.
Somewhat unrelated, but I remembered this line from "Young Sheldon": "I'm not paying for TV. TV is free. Always was, always will be."
That said, a lot of the European countries provides various free services for this kind of content.
Here's a service you can watch globally for free that has a lot of documentaries.
www.arte.tv/en/