Testing AMD VCE on Handbrake using a 2400g APU

Nightfire

2[H]4U
Joined
Sep 7, 2017
Messages
3,279
I decided to see how the VCE encoder would work on Handbrake. For the test, I used an episode of Midsomer Murders from a Blu-Ray mkv rip. Settings for all encodes were 22 quality using 1080p, DTS-HD AC3 256 bit stereo (limited options). Included are fps, approx time to complete (never around to see it finish), file size and power usage, though this is only for comparative purposes as the tv and other devices were on the meter.

First up was cpu using H.264: 12.3 fps, ~3:05, 3.02 GB, 200w.
Overall, great picture but slow at over 3 hours and rather large.
cpu264.png


Next was cpu using H.265: 19 fps, ~2:00, 1.93 GB, 200w.
Similar quality, surprisingly faster, and about 2/3s the size.
cpu265.png


Now for gpu using H.264: 67 fps, 0:35?, 1.24 GB, 150w using about 80% gpu and 30% of the cpu
Super fast, very small file, but a terrible picture. I am currently trying with better settings with deblock. Perhaps the VCE H.264 does not line up the same.
gpu264.png

Finally I tried gpu H.265: 72 fps, 0:32, 5.12 GB, 170w using about 80% gpu and 50% of the cpu
Fast, nice picture. Though the file was huge and I am really not ready for H.265 for my network videos.
Again, pehaps the presets do not line up. Maybe I will try 23 quality and see how it matches up.
gpu265.png

When zooming in to the old farts in the back ground, this looks to be the case. Compare the smaller file cpu H.265 to the much larger gpu H.265. I am thinking I can set gpu H.265 to at least 23 while still getting similar quality.
cpu265 zoom.png
gpu265 zoom.png


The image on the left looks slightly more hazy, at least to me.
 
Last edited:
264 is old school man... hah

I do all my vidz in 65

My 5700xt turns about 200fps avg with handbrake about the same as my 2080ti

But I dont use handbrake because its like super entry level.

Use Staxrip for way way more power.

As far as 2400g performance, I think you are limited to the reduced number of GPU cores compared to the big cards so expect a lower performance, but definitely faster than a CPU.

I hope your not using that quad core CPU for encodes, that has to be painfully slow.

My 3900x can do 4x handbrakes at the same time @ 12-15fps h265 each 1080p q25'ish with options turned on. A true CPU encoding monster.

I just dont like GPU encoding due to the quality loss. I find CPU turns out a much better quality because therea re more advanced algorithms that can be run on the far more complex CPU extensions available. Now if we can get some AVX 256 encoding for these Zen 2s that would be awesome.
 
264 is old school man... hah

I do all my vidz in 65

My 5700xt turns about 200fps avg with handbrake about the same as my 2080ti

But I dont use handbrake because its like super entry level.

Use Staxrip for way way more power.

As far as 2400g performance, I think you are limited to the reduced number of GPU cores compared to the big cards so expect a lower performance, but definitely faster than a CPU.

I hope your not using that quad core CPU for encodes, that has to be painfully slow.

My 3900x can do 4x handbrakes at the same time @ 12-15fps h265 each 1080p q25'ish with options turned on. A true CPU encoding monster.

I just dont like GPU encoding due to the quality loss. I find CPU turns out a much better quality because therea re more advanced algorithms that can be run on the far more complex CPU extensions available. Now if we can get some AVX 256 encoding for these Zen 2s that would be awesome.

What is the advantage of 65 over 64 other than file size? Space is not a huge concern and I am more concerned about compatibility. Not everything plays H.265.

What percent of your 5700xt is used when encoding and what quality setting do you use for 200 fps? 1/3 of the 5700xt performance still seems really good.

I did not see any quality loss when using gpu with H.265, though gpu with H.264 was a mess.
 
Did you compare CPU 265 vs GPU 265? Hard to know if there is a quality loss if you didn't. Nevermind, I see the text says CPU 265, the image is incorrectly labeled (or wrong image?).

265 should be larger than 264 with similar quality (not preset quality, actual). Odd that you 264 looks that bad, I knew there was a difference, but not that bad.
 
265 is significantly more efficient in compression


But yes if space is a luxury 264 is way easier on decoding and compatibility.

I think handbrake uses like 50% of any gpu I toss at it whilst staxrip uses 100%. I get over 450fps on 5700xt and 2080ti encoding 1080p on h265 using Staxrip. But handbrake just SUCKS at using full gpu power. At least last time I used it

Dont be fooled VCE is very relevant and the 5700xt is very powerful for a so called midrange gpu. Im thinking my old 2400g hit 200fps or so in stax and much less on HBrake.
 
How is the staxrip quality with VCE? File size and quality similar to CPU encoding?

No, it's still off. CPU is superior. I say, if your die hard about video work, spend on your CPU more than your gpu.

3900x is faster at video work than my 2950x threadripper was by far.

1080ti was faster than 2080ti, but 2080ti can render B frames, 1080ti cant.

5700xt I'm still learning. I think vce and cuda look the same but CPU is far superior albeit far slower. Depends on your work load. Cuda has more support from nVidia and VCE has more support from community and overall less support than cuda across the board.

4k to 1080p is faster to use gpu with minimal losses but 1080p 264 to 1080p 265 cpu is absolutely superior.

But someone out there may have a nice CLI script using 264/5 that can make a gpu as good as a cpu but I dont have anyone on mind that I know.

Staxrip doesnt do anything its self. It's just an interface. But it allows access to much deeper rendering and conversion functions within the 264/65 feature stacks that handbrake refuses to implement. Handbrake is simple and works great out of box. But staxrip is a small bitch to learn but works great once you learn it.
 
Last edited:
265 is significantly more efficient in compression


But yes if space is a luxury 264 is way easier on decoding and compatibility.

I think handbrake uses like 50% of any gpu I toss at it whilst staxrip uses 100%. I get over 450fps on 5700xt and 2080ti encoding 1080p on h265 using Staxrip. But handbrake just SUCKS at using full gpu power. At least last time I used it

Dont be fooled VCE is very relevant and the 5700xt is very powerful for a so called midrange gpu. Im thinking my old 2400g hit 200fps or so in stax and much less on HBrake.
first i hear of staxrip.....you use it over handbrake?
 
I've been using handbrake as well, I'm going to check out staxrip, sounds pretty neat.
 
Did you compare CPU 265 vs GPU 265? Hard to know if there is a quality loss if you didn't. Nevermind, I see the text says CPU 265, the image is incorrectly labeled (or wrong image?).

265 should be larger than 264 with similar quality (not preset quality, actual). Odd that you 264 looks that bad, I knew there was a difference, but not that bad.

Yep, wrong image. VCE 265 was twice as big as CPU 265. I will try again later with VCE 265 at 24 quality and see if it still holds up visually while being faster.

There is something wrong with VCE 264. No matter what the settings, it is always the same small file size. When I mess with the image settings, Handbrake then only uses 20% of the gpu and around 10% of the cpu. Encoding time is actually a little slower than cpu alone, but efficiency is through the roof. My meter was using around 130 watts (updated)! As a baseline, that meter reads about 200w when the cpu is running H.264.
 
Last edited:
265 is significantly more efficient in compression


But yes if space is a luxury 264 is way easier on decoding and compatibility.

I think handbrake uses like 50% of any gpu I toss at it whilst staxrip uses 100%. I get over 450fps on 5700xt and 2080ti encoding 1080p on h265 using Staxrip. But handbrake just SUCKS at using full gpu power. At least last time I used it

Dont be fooled VCE is very relevant and the 5700xt is very powerful for a so called midrange gpu. Im thinking my old 2400g hit 200fps or so in stax and much less on HBrake.


Stax seems cool, but I am pretty stubborn about adding new software. I wouldn't say space is a luxury, it's just the cheapest part for me. For myself, I would put quality and compatibility at the top of importance for video encoding and both file size and speed at the bottom. I would even put power consumption above speed.
I really have no desire of encoding more than one movie a day, so if I start it before work or bed, it happens instantaneous in my mind. I just liked the idea of using the APU more efficiently and effectively in case you did need the cpu resources.
 
Yep, wrong image. VCE 265 was twice as big as CPU 265. I will try again later with VCE 265 at 24 quality and see if it still holds up visually while being faster.

There is something wrong with VCE 264. No matter what the settings, it is always the same small file size. When I mess with the image settings, Handbrake then only uses 20% of the gpu and around 10% of the cpu. Encoding time is actually a little slower than cpu alone, but efficiency is through the roof. My meter was using around 130 watts (updated)! As a baseline, that meter reads about 200w when the cpu is running H.264.
Could it be defaulting to constant bitrate? that would result in a consistent file size. quality would depend on the encoding time, although it will be limited by the bandwidth restriction.
 
Stax seems cool, but I am pretty stubborn about adding new software. I wouldn't say space is a luxury, it's just the cheapest part for me. For myself, I would put quality and compatibility at the top of importance for video encoding and both file size and speed at the bottom. I would even put power consumption above speed.
I really have no desire of encoding more than one movie a day, so if I start it before work or bed, it happens instantaneous in my mind. I just liked the idea of using the APU more efficiently and effectively in case you did need the cpu resources.
Stax is pretty much portables so it's not even like you install it, just download and run. If you don't like it, delete it. I plan to test it (probably this weekend).
 
Could it be defaulting to constant bitrate? that would result in a consistent file size. quality would depend on the encoding time, although it will be limited by the bandwidth restriction.

No, it was constant quality. I even tried higher quality as well as denoise filters. Same file size, just much slower. I will try with a full blu ray this weekend.
 
H.264 doesn't have distribution royalties whereas H.265 does. For hobbyist encodes this isn't an issue but for commercial use it does.

Also, as Nightfire mentioned, H.264 is compatible with more devices than H.265 at present.
 
If you do 265.make sure to do 10 bit as it has significant dark scene and color banding performance compared to 8 bit.

Roku by the way can decode 265 as well as plex servers all day long

As far as apu for encoding, it doesn't get more power efficient than that. I see zero harm in your goals.
 
H.264 doesn't have distribution royalties whereas H.265 does. For hobbyist encodes this isn't an issue but for commercial use it does.

Also, as Nightfire mentioned, H.264 is compatible with more devices than H.265 at present.

When you day commercial use, does that mean transcoding on to a DVD? I like the idea of putting near-blu ray level quality on to a cheap dvd. From what I remember, that is harder to do with H.265, or maybe requires the 'ultimate' version of the dvd burning software.

As stated, I like the idea that my daughter can take an external hdd and play movies on her friends old pc/tv without issues. Same for a usb onto a camper or vehicle infotainment system.

Honestly, I probably won't use H.265 until I start ripping 4k blu ray which may be a long while away.
 
By commercial use I mean distributing for sale. When H.264 first came out the licensors of the format decided to not collect royalties for distribution in the hope that it would become a ubiquitous format (which it did). The licensors of the H.265 format have not decided (as far as I know) to allow royalty-free distribution for commercial use so the company I work for doesn't distribute videos using that format (in addition to not being as compatible with as many devices).
 
AMD's "new" h.264 encoder is known to be broken. Some youtubers have made AMD aware of it and a VP said he put some people on it. But who knows when we will see any improvement.
 
AMD's "new" h.264 encoder is known to be broken. Some youtubers have made AMD aware of it and a VP said he put some people on it. But who knows when we will see any improvement.
Whats broken? Could swear the AMD vce265 worked ok every time i tried it with handbrake? wouldnt 265 (rather than 264) be a better choice anyway?
 
Whats broken? Could swear the AMD vce265 worked ok every time i tried it with handbrake? wouldnt 265 (rather than 264) be a better choice anyway?

Just look at the 3rd pic I posted. It looks terrible. H.265 using the gpu looks CPU quality at the same settings and was very fast, but the file size is 2.5x as big as the cpu running h.265. Right now I am running the gpu at h.265 and 28 quality to see if I can get similar quality with similar file size, but for some reason it has slowed to a crawl and using only 20% of the gpu. The same thing happened when I tried to 'fix' gpu h.264 using deblock and denoise filters.

There are many redit posts on it. VCE definitely has issues. I will try once more with a full blu ray mkv movie this weekend with dolby passthru to see if the audio is possibly goofing things up.
 
I stuck my TXP back in due to this. NVENC is pretty good in comparison. I can compress most things 40%-50% whilst maintaining same/similar PQ with mediacoder. AMD really need to throw some resources at developing support for their gpu outside of games.
 
Just look at the 3rd pic I posted. It looks terrible. H.265 using the gpu looks CPU quality at the same settings and was very fast, but the file size is 2.5x as big as the cpu running h.265. Right now I am running the gpu at h.265 and 28 quality to see if I can get similar quality with similar file size, but for some reason it has slowed to a crawl and using only 20% of the gpu. The same thing happened when I tried to 'fix' gpu h.264 using deblock and denoise filters.

There are many redit posts on it. VCE definitely has issues. I will try once more with a full blu ray mkv movie this weekend with dolby passthru to see if the audio is possibly goofing things up.
i have to do another test cause with all mine it the past it would use 80% or more of the gpu. (testing 4k ultra Bd's) it hast been a few driver revisions since my last conversion
 
Whats broken? Could swear the AMD vce265 worked ok every time i tried it with handbrake? wouldnt 265 (rather than 264) be a better choice anyway?
absolutely abysmal image quality. Suggesting something is being utilized correctly. Also, compatibility issues with various multimedia/editing/capturing software.

There are lots or reasons to not use H.265. However, AMD's encoder for that is quite good.
 
absolutely abysmal image quality. Suggesting something is being utilized correctly. Also, compatibility issues with various multimedia/editing/capturing software.

There are lots or reasons to not use H.265. However, AMD's encoder for that is quite good.

I saved a few TB by recoding all my movies from h264 to 65. I used all CPU encodes to do it. My 2950x would spend days on end coding away. Then my 3900x does it too.

My average was a 2GB 1080p file to 900mb with no quality loss on avg.
 
I saved a few TB by recoding all my movies from h264 to 65. I used all CPU encodes to do it. My 2950x would spend days on end coding away. Then my 3900x does it too.

My average was a 2GB 1080p file to 900mb with no quality loss on avg.
Was it even worth the CPU running that long? It's about $0.02 per GB for HDD space, and somewhere around .13 per kwh, interested if it was worth the re encoding to save a tiny bit of space. Did you encode from the original or from the already encoding 264?
 
I saved a few TB by recoding all my movies from h264 to 65. I used all CPU encodes to do it. My 2950x would spend days on end coding away. Then my 3900x does it too.

My average was a 2GB 1080p file to 900mb with no quality loss on avg.
this is exactly why i want to store mine that way. I also look forward to the day we can get equal quality with H265 (AMD VCE) so i can do it in half the time or better:) The few tests i ran on some uncompressed 4k ultra files went way faster but produced files larger than the cpu only type of encode. (i kinda wonder if the quality can be tweaked to equal it out?) Regardless to me i just assume use H265 and keep the best quality per MB of storage. I dont go change any of mine already encoded in h264 but just when i get new uncompressed files from redbox or the internet.
 
I saved a few TB by recoding all my movies from h264 to 65. I used all CPU encodes to do it. My 2950x would spend days on end coding away. Then my 3900x does it too.

My average was a 2GB 1080p file to 900mb with no quality loss on avg.
One other thing. If you were to re encode an already ripped movie file that was encoded in H264, wouldnt it end up being a different file quality wise of a movie that was encoded in 265 to begin with?
 
The few tests i ran on some uncompressed 4k ultra files went way faster but produced files larger than the cpu only type of encode. (i kinda wonder if the quality can be tweaked to equal it out?)

Unless you're talking about raw camera files your 4K video is already highly compressed (likely using H.265).

One other thing. If you were to re encode an already ripped movie file that was encoded in H264, wouldnt it end up being a different file quality wise of a movie that was encoded in 265 to begin with?

Re-encoding a transcoded file will almost always be associated with a further reduction in quality regardless of the container used, but that's why terms like visually lossless is a thing (this isn't true if you're using a lossless encoder but those are used for archival footage and not playback and they have their own drawbacks). Most people won't discern a degradation in quality for two or three re-encodes but if you have a choice you really should re-encode from as close to the original as you can. Since we're talking about commercial DVDs and Blu-Rays here ideally you're re-encoding direct from the DVD or Blu-Ray.
 
Unless you're talking about raw camera files your 4K video is already highly compressed (likely using H.265).

For me im talking about taking videos straight of the BD disks (including 4k ultras) with Anydvd or whatever else works. So im talking about taking that 40-80 GB video and storing it in a virtually lossless file. Im thinking in most cases we should be able to drop it to a size that would fit on a bd disk (just for picking a file size if possible)
 
Yeah, converting compressed digital to digital seems like a bad idea, even if it saves some space.

I may convert some of my monsterous 1080p60 gopro videos to h.265 though. I take it those are uncompressed videos and is why they are so large. They do look gorgeous, though and sort of pop out of the screen.
 
One other thing. If you were to re encode an already ripped movie file that was encoded in H264, wouldnt it end up being a different file quality wise of a movie that was encoded in 265 to begin with?

You can maintain almost 99% of the 264 quality with the right settings. But it requires you to be aggressive with CPU and patient with time.

Dont assume

Do it and be impressed.
 
You can maintain almost 99% of the 264 quality with the right settings. But it requires you to be aggressive with CPU and patient with time.

Dont assume

Do it and be impressed.
Yeah, I was able to do that, converting 1hr 1080p15 video clips at about 10fps on my 1600x, then stitched 8 together in a few hours at 1080p60, about 90% quality, for a time lapse (a few thousand fps).

Did it all via software on cpu, using ffmpeg in a terminal. Some of the options are confusing for me, since I don't do much of this, but they are explained in the wiki.
 
You can maintain almost 99% of the 264 quality with the right settings. But it requires you to be aggressive with CPU and patient with time.

Dont assume

Do it and be impressed.
just something i was wondering about and in some cases a nice 4k hdr display wouldn't hurt.....well i keep telling myself i need one of those anyway:)
 
If you factor in audio, space savings of 265 are not as big over 264. I took a 27.6 GB Mad Max Fury Road rip and encoded with 22 quality and 768 kbps 7 channel aac audio with both h.264 and h.265.

H.264 had a data rate of 6150 kbps while h.265 ended up with 3450 kbps. That is nearly half, however; both had a bit rate of 768 kbps.
H.265 was smaller at 3.54GB vs 5.81 GB, but not really worth the compatibility issues on my network and twice the CPU up time (17 fps vs 30 fps). VCE didn't work properly at all for the movie running slower than even the cpu.
 
Last test using for now using AMD VCE. This time it was a 3:40 gopro 1080p60 video that came in at a whopping 793 MB. Cpu conversions done using 20 quality and 160 AAC audio, which was slightly higher than source.

First I used H.264 with the CPU. It converted a 13.3 fps, hit 200w at the wall, and created a 345 MB file.

Next was H.265 with the CPU. This time it was 17 fps, 186w and 275 MB file. Damn good all around.

H.264 on the GPU was a disaster as usual. Just a muddy mess.

Finally, I did H.265 on the gpu and things got weird. And the same '20' quality, the file size was actually bigger. When I lowered the quality, performance tanked. I then used the constant bit rate from H.265 cpu to get the same file size. It ran 150w at 70 fps while using 50% cpu and 80% gpu.

Quality was not nearly as good as the H.265 cpu, which was the same file size, so I did one last run at the same bit rate as H.264 plus running the 'slow' setting. Performance started the the, but the gpu sort of died to 20% at the end and final speed was around 50 fps.

Here is a comparison of GoPro original, H.264 cpu, H.265 cpu, H.264 gpu@275MB, H.265 gpu@345MB slow, and finally GoPro again. The picture is of a zoomed in moving car at the exact same frame.

go zoom.png

264 zoom.png

265 zoom.png

g265 match.png

g265 match slow.png

go zoom.png
 
I think one of the reasons i get so much different results with handbrake and AMD 265 is im actually running the gpu part on my Vega 64 gpu and not an IGP part of the cpu. So it makes sense we would have very different results is all.
Capture.PNG
 
Last edited:
Back
Top