AMD FINALLY updated their H.264 encoder… all the way back in March. So why… haven’t
I covered it? Tons of tweets from you all, multiple articles recently posting about
the update - thanks for the shoutouts by the way - so why did I stay quiet? Well,
because you can’t use it still. And, the improvement is marginal.
But the journey to find this out was an interesting one and I discovered someone
else has updated their encoder beyond what I possibly expected, so we have a lot to talk about.
This video is sponsored by NordVPN. Get two years
plus a bonus month at a heavy discount at the link below.
Real quick, let’s go over how encoders work. There’s the hardware side - there’s physical
silicon, usually in the form of ASICs or fixed function chips, that physically handle the
encoding and decoding of video. Performance, and thus the quality that can be achieved, of these
chips can change with new GPU generations and this makes the MOST impact on improving video encoding
quality. That’s why Nvidia’s H.264 encoder quality mostly stayed the same until the Turing 20 series
GPUs where they improved the physical NVENC chips onboard and quality leaped quite a bit.
AMD has seemingly just not touched theirs on the consumer side, at all.
But then there’s the software side. Hardware manufacturers - AMD,
Intel or Nvidia in this case - provide SDKs, development software, that allow
software developers to use to implement the encoder into their apps - like OBS or FFMPEG,
for instance. Those manufacturers can continue to iterate on and improve how the SDK works,
add new features or presets, and so on to improve performance and sometimes improve quality a bit.
The SDKs are implemented on the user side for program access via GPU driver updates. We saw
this when Nvidia partnered with the OBS developers to implement the updated SDK they launched with
RTX cards which not only added the new features required to achieve higher quality on those cards,
but also added some pretty significant performance benefits to older cards, as well.
That’s what we’re looking at today. Back in March of this year, AMD updated the
AMF (Advanced Media Framework) SDK for their video encoders and decoders. In this update,
the big noteworthy thing was that they finally added support for b-frames, a feature of the
H.264 codec that some consider very important, and seemed to be how many explained why AMD’s video
quality was so poor compared to everyone else’s. I showed in 2020 during my last round of encoder
quality comparisons that AMD’s H.264 encoder had barely improved at all, if any, through
the generations and paled in comparison to both NVENC from Nvidia and QuickSync from Intel, and
was often worse than lightweight X264 presets that most streamers would be able to run on their CPU.
So did this update help? Well no, not really. I think I know why, though.
But first, what is a b-frame? This is an annoying question to answer,
as there’s so much compounding encoder documentation to dive
through just to understand it but I’m going to make it pretty simple here.
H.264 compression makes video files so small because it doesn’t actually encode every frame
of video. Instead, it looks for movement in the scene, makes guesses about what should
be where and what pixels need updated, and only encodes part of the image at a time. That’s why
when you have too low of a bitrate (such as on a Twitch stream) or too much movement (such as from
a fast action video game with a first-person camera), you get a ton of blocking artifacts.
There aren’t enough bits to assign to each frame and too much movement to encode all at once.
To do this guessing and limiting process, the encoder uses different reference frames.
Reference frames are either the full image or the guesses on what’s changed. There’s two main
types of reference frames: Keyframes, also called i-frames, and then the delta frames,
or the frames that only have the parts that change between frames.
Keyframes, or i-frames, are the entire image. Think of it like a screenshot of that video
in that moment. They’re still limited by the bitrate being encoded, but they contain all
of the information at that moment in time. The delta frames then are used in-between
keyframes and just have the parts that change or move between each instance of a keyframe.
With enough bitrate, you COULD have every frame be a keyframe and have effectively
no messy compression - plenty of cameras record this way. But trying to do this in
a low bitrate live stream would mean far more turned into a pixelated blocky mess
rather than having some of the image preserved.
There’s a few different types of delta frames, including b-frames. The B in B-Frames stands
for bi-directional. Most delta frames, such as p-frames, only look to the previous frame before
it to figure out where blocks of the image are moving. B-Frames can refer to and interpolate from
frames before AND after it, as well as looking at two or more frames in the first place. This looks
for redundancy both in space on the frame and through time and can have a big impact on reducing
data use. But since it’s referring to frames at different points in time, it requires a buffer to
reference future frames, rather than going 100% linearly, and special implementations to work.
This is a really in-depth topic,
I’ll have more reading about it linked below if you’re interested.
All of this leads back to the question that was repeatedly asked when the Nvidia
encoder updates released: How many should you use? In OBS you can use
up to 4 b-frames in the options for NVENC, but more isn’t always better.
I captured fresh lossless 4:4:4 samples at 1080p60 of some video games and ran them through NVENC,
Quick Sync, and AMD AMF H.264 encoding with 3 different bitrates and different
b-frame amounts to see which is the best for each encoder, and how the encoders compare.
It’s worth noting that I won’t cover all of my samples here, as I have a more massive encoder
analysis of the year coming after Nvidia and AMD release their new graphics cards,
but this is a good starter as we lead into Intel’s AV1 encoder in the next video. All
of my samples and data are available to download for Nebula subscribers.
Let’s look at some nerdy data.
I tested 3 different bitrates for 1080p60 footage - 3.5mbps, 6mbps,
and 8mbps to test commonly-streamed formats. I didn’t go lower because
1080p shouldn’t be used if you have to go that low, and I didn’t go higher,
as you hit diminishing returns for encoder differences past 8mbps. But these represent
normal Twitch streams. I used Netflix’s Video Multi-Method Assessment Fusion,
or VMAF, to analyze video quality of compressed copies versus lossless footage. This is now the
industry standard for truly determining quality differences based on how a viewer would actually
perceive them. I tested other measurements such as PSNR and SSIM, but they’re not super useful
for this kind of thing, so we’re just focusing on VMAF data here as it’s far more reliable.
When compared against utilizing 0 b-frames, the use of b-frames in AMD’s AMF encoder
provides 2 to 4% quality improvements at lower bitrates such at 3.5mbps,
but only 1-2% at most once you start hitting 6 and 8mbps. This IS an improvement,
and a free quality bump for AMD GPU users, but it’s not revolutionary.
It gets more interesting when we open up to the secondary question of “how many b-frames should
you use”, as I tested all of the different combinations. The current AMD driver only
allows for a maximum of 3 b-frames to be used, which is interesting given that both Nvidia and
Intel can use up to 4. But regardless, in every single encode at every bitrate level,
the best quality result was using only 1 b-frame. In most, but not all, tests,
2 and 3 b-frames were still a quality improvement over not using them at all,
but limiting the encoder to only 1 resulted in the best quality.
I also observed that another option made a big difference in quality. The AMD encoder gives
you an option between 3 motion estimation modes to determine where pixels are moving:
Full-pixel, tracking things at the size of a full pixel, half-pixel, and quarter-pixel.
Most H.264 encoders primarily tend to use half-pixel motion, but quarter-pixel wins
out sometimes here. My results are literally split 50-50 with regards to whether half or
quarter-pixel is best performing, depending on the game. And it’s consistent across bitrates where
a specific game’s footage will perform best with half at all bitrates, or quarter at all bitrates.
So then, knowing we see a small but present quality bump on AMD’s encoder,
how does it stand in 2022 versus H.264 encoded on Nvidia GPUs or Intel iGPUs?
Well, the numbers are all honestly reasonably close these days, especially at higher bitrates,
but Nvidia’s H.264 encoder is still outperforming AMD’s by upwards of 5%
in most cases. At 6 and 8mbps, even NVENC’s worst-performing settings combination scores
better than AMD’s best. It’s not until we drop to 3.5mbps, a very low bitrate for 1080p as it is,
where NVENC and AMF really start trading blows, depending on the game. But we’re talking less
than 2 total VMAF score points’ worth of difference across the board here, anyway.
This also reveals a pretty significant diversity in which settings actually produce
the best results from Nvidia’s side. While 1 b-frame was the best no matter what for AMF,
for NVENC, it completely varies. 0 b-frames performs best for all
of the samples at 3.5mbps for NVENC, but at 6mbps, 2 games looked better with 2 b-frames,
1 with 0 and 1 with 1 b-frame. Then at 8mbps, most had best results with 1 b-frame,
but one game looked best with 2. It seems the tradeoff of the extra bandwidth that b-frames
can eat up for their specific frame versus what they save down the line is hit or miss here.
Similarly, it was a constant back and forth trade of whether utilizing lookahead with
NVENC - a feature added in that RTX-adjacent update I mentioned - performed best here,
with the differences between it being on or off often being quite marginal.
Most interestingly from all of this testing, I thought, was the revelation that Intel has been
quietly updating their QuickSync H.264 encoder continuously over the years. I teased during my
original 12th-gen coverage that it was really good now, but consistently on almost every test
combination, QuickSync out-performed NVENC by 2 to 6% depending on bitrate, with a similar scenario
of even the worst settings combinations in QuickSync still scoring higher than Nvidia’s best.
Also just to note, 3 b-frames seems to be the sweet spot for QuickSync,
with 1 sometimes performing better, but 3 was generally the best.
Quantitative measurement doesn’t tell the full picture, however, and in motion,
the differences in these encoders becomes MUCH less noticeable. We’re talking much
smaller gaps in the VMAF scores than we had before, anyway. This is awesome,
the fun takeaway here is that all 3 are in a great spot compared to before, and performing
quite well. But bitrate limitations matter way more here, and you should be streaming in the
highest bitrate you can as allowed by your internet connection and streaming platform.
The differences sometimes just come down to different priorities in the encoder’s
philosophies. Sometimes a scene looks smoother and less blocky in one encoder, but also less
sharp. While the other encoder might have more blocking but you get a feel for more detail.
And then sometimes the AMD encoder is just both blurrier and blockier than the other two, and
that’s just how it is.
Thankfully, we don’t have to wait very long for things to change, as Intel already has
GPUs with AV1 encoding - a new open source video encoder that is promising to be even more bitrate
efficient. I have one in-hand and we’ll be covering in the next video, so get subscribed.
I’m mostly left with one question: Why did AMD release this update? Clearly it’s not a big push
for them, as literally NOTHING an end-user can use even has implemented the update. OBS doesn’t have
it, FFMPEG doesn’t have it, Handbrake (which is basically just a GUI for FFMPEG) doesn’t have it.
I had to use some obscure Japanese Github build of the encoder to even
try it out at all, which is part of why I haven’t covered it yet.
*Actually I just wanted to cut in and say you CAN build OBS with a more recent and
patched-in version of FFMPEG that you’d have to compile fully yourself, and THEN use the
StreamFX plugin with THAT custom build to utilize b-frames, but that’s… a mess. Don’t do that.*
So, why, then? Well, while it’s a nice show of effort to see that AMD still has engineers who
care about video encoding, I get the feeling that this was more just prep work for whatever next
generation of graphics cards AMD is supposed to be releasing this year. Much how Nvidia
revamped their SDK when they released a major encoder update with 20 series Turing cards,
expectations are set that AMD will at least support AV1 encoding with their next generation,
which does mean a silicon change. But given Nvidia is at least happy to sit
on their pile of 30-series Ampere cards and wait to roll out their new GPUs,
AMD probably isn’t dropping theirs right away either, so for now AMD users are just kinda
stuck in last place, hoping AMD starts to care about streaming at some point.
With Nvidia and Intel both releasing high quality encoders, background removal tech,
and so on… AMD has some ground to make up when it comes to streaming and content creation.
Doing all this video and encoding testing is fun, but it uses a LOT of bandwidth and data.
Especially getting all these samples uploaded for you all. And every time I do these kinds
of projects, I end up getting my bandwidth throttled by my ISP. Meanwhile, I'm getting
thermal throttled by this heat wave... phew. There are clearly high points when everyone's
at home watching YouTube and movies online at the same time that my ISP starts limiting
what I can upload with - but with NordVPN, that's no longer an issue.
NordVPN is upgrading to colocated and 10-gig servers meaning we'll all have
even faster browsing experiences, plus all of their server nodes are diskless,
meaning they don't store any of your configuration or data on-site. You can even route your traffic
through a second VPN server for double the encryption if that's your thing.
I've been using NordVPN to stay secure online and keep from getting throttled
since moving to our new house - well, to keep from getting bandwidth throttled at
least. You can try it out with a 30-day risk-free money-back guarantee and get
a 2 year plan plus an additional month at a massive discount at nordvpn.com/eposvox.
They can't protect you from the heat, unfortunately. Stay safe out there.
I still have tons more encoder data to share both in the AV1 video and in the big encoder
drop later this year, don’t worry. In the meantime, check out this playlist if you
want to see how these encoders stacked up in the past, or check out this video on how
you can start improving audio for your videos. I’m the Stream Professor, remember Be Kind, Rewind.