Evaluation of HEVC decoders (SW, Hybrid and HW)

[nevcairiel]

NVDEC and CUVID is exactly the same thing, they just re-branded it to match NVENC. It still offers the deinterlacing capability in the API.

At this point I'm going to assume this confusion started because FFmpeg implemented a new hardware acceleration module using CUVID/NVDEC and named it "nvdec" (in addition to the "cuvid" decoders it already had), and it got quite a bit mis-reported on pages like Phoronix as something magically new, but if this is not your source of confusion then carry on.

The (relatively new) hardware acceleration in FFmpeg called "nvdec" does not offer deinterlacing, because it doesn't fit into the model of how its implemented (decoding and processing should be separated). But thats just implementation, not a change in the API.
As a bonus, the way its done you get the full metadata capability from the FFmpeg decoder, including full SEI parsing for HDR and whatnot - something the stand-alone cuvid decoder could not offer without a lot of extra effort (and even the deinterlacing in the stand-alone cuvid decoder was problematic because decoders are not meant to suddenly double the frame rate in FFmpeg).

In general the "nvdec" implementation in FFmpeg is a much cleaner approach, as it basically behaves like any traditional hardware acceleration API (like VDPAU, VAAPI, DXVA, etc), which allows getting the benefits of the full software decoders in FFmpeg, just with hardware speed. The only downside is that you can't hack in support for some processing features the CUVID/NVDEC API offers, because the decoders are required to output a pristine decoded image, no changes.

All this is not due to a change in the NVIDIA Video SDK however, this could've been done like this years ago, but it is more effort then the simple stand-alone decoders and just simply wasn't done before. It was called "nvdec" to differentiate itself from the old "cuvid" implementation as well as to match the re-branding NVIDIA did, but just to be safe and repeat this: This is not a new API or even new hardware. Internally they didn't even rename any functions, its just an external name.

[Cary Knoop]

The (relatively new) hardware acceleration in FFmpeg called "nvdec" does not offer deinterlacing, because it doesn't fit into the model of how its implemented (decoding and processing should be separated). But thats just implementation, not a change in the API.

If I try deinterlacing using a fully NVDEC and NVENC hardware path it seems to work just fine, am I mistaken?

For instance:

ffmpeg -y -vsync 0 -hwaccel cuvid -c:v mpeg2_cuvid -deint 1 -i ntscfile.m2v -c:v hevc_nvenc -profile:v main -preset slow -r 60000/1001 -g 1 -b:v 20M out.mp4

Gives me an all-intra, frame doubled hevc file.

[aufkrawall]

Thx for shedding some light on this.
Just wanna add that we shouldn't pay any kudos to Nvidia for it, it's a redundant API which only purpose is assery (not supporting VAAPI on Linux).

[huhn]

it is very unlikely that nvdec was created for linux specificity...
and CUVID was used for hardware acceleration before DXVA implementation was a thing.

[aufkrawall]

it is very unlikely that nvdec was created for linux specificity...

It's the only OS where it makes sense to use it and they dropped VDPAU.
So, yes, there is a connection.

[wanezhiling]

https://techreport.com/r.x/2017_11_29_Here_s_a_first_look_at_the_battery_life_of_HP_s_Ryzen_powered_Envy_x3/dxva.png
Ryzen 5 2500U

[NikosD]

Ryzen APU is a 4K H.264/H.265 (8bit & 10bit)/VP9 (8bit & 10bit) DXVA2 accelerator, but can you run some tests using VP9 in order to find out if it's a hybrid or fixed-function VP9 accelerator ?

I mean if you have access to such hardware of course.

@nevcairiel
Very detailed and thorough report for "nvdec" implementation of FFMPEG.
Thanks.

[aufkrawall]

They haven't exposed VP9 hybrid via DXVA2/D3D11VA on Polaris, so it's probably a sign that it's native with RR.

[wanezhiling]

native

https://www.phoronix.com/scan.php?page=news_item&px=Radeon-VCN-Encode-Lands
"Video Core Next" supports MPEG-4 AVC and HEVC/H.265 encoding while on the decoding front is MPEG-2, MPEG-4, VC1, MPEG-4 AVC, H.265 HEVC, and VP9.

[wanezhiling]

https://s10.postimg.org/3jmyi9bzt/QQ_20180205142844.jpg

AMD is so f**king weak....
I swear i will never purchase red anythings...:angry:

[huhn]

well maybe wait for 1 or 2 driver before you finally judge this.
maybe try to give the GPU more memory maybe the sharing process is very slow and you clearly need more than 256 mb to do anything related to UHD.
but this looks sad...

[aufkrawall]

Perhaps also try D3D11VA, it's probably fastest in browsers. mpv dumb-mode would also be really fast, but stupid upstream ffmpeg doesn't support VP9 10 bit in hardware.

Edit: You could also try instaling the latest discrete graphics card driver via Windows device manager, it boosts performance in some games compared to the driver delivered with the notebooks.

[NikosD]

AMD is so f**king weak....
I swear i will never purchase red anythings...:angry:

The GPU usage is extremely high for native HW VP9 10bit decoding, almost like video decoding usage.

It looks like a hybrid decoding a lot more than native decoding.

Unless the UHD resolution is too much for scaling using Vega 8 and 256MB is too low for VRAM.

But still, that GPU usage is huge.

Can you try DXVA decoder in benchmark (renderless) mode on the same clip and see the GPU usage again ?

Thanks!

[wanezhiling]

It should be a fixed-function VP9 accelerator according to my experience.
I tested on some 4K_HEVC_10bit_60p and 4K_VP9_8&10bit_60p clips and found the GPU is extremely slow........ With EVR-CP, its dead, R.I.P:devil: With vanilla EVR, well can work but GPU usage is also very high ~90+.

4K_VP9_8bit_60
decode: https://s14.postimg.org/6ovqhf0m9/VP9_D.png
playback(native resolution): https://s14.postimg.org/b9hwwxcs1/VP9_P.png

4K_VP9_10bit_60
decode: https://s14.postimg.org/szjlhyy2p/VP9_10_D.png
playback(native resolution): https://s14.postimg.org/fwnyy3zyp/VP9_10_P.png


ps: the model of the laptop is Lenovo ideapad 720s at DDR4-2133 memory and only single channel.:o

[huhn]

try to give it more Vram like 2gb in the bios is may help a lot.
the next problem could be the intel GPU that is maybe used to display everything so so it needs to be copied there before it can be send to the display which can be really slow and yes nvidia can have this problem too with this terrible optimus implementation.

it depends heavily where the display is connected to is it iGPU or the dGPU and this may change depending on the used connector or the build in display.

[aufkrawall]

I don't think that it's hybrid with RR because when I'm using hybrid VP9 in Chrome with the RX 560, the GPU usage reported by Task Manager is allegedly lower than with software decoding.
It's impossible to be true, that reported D3D GPU usage by the Task Manager (it's been available for ages in hwinfo) probably can't detect the load by the hybrid decoder correctly and gets confused (it can't detect OpenCL and Vulkan Async Compute correctly either).
However, then reported GPU load likely wouldn't be so high with RR, so there probably really is something else going on like weird copyback or driver issues.

It's weird that the video engine runs at 100%, but that doesn't explain the generally high 3D load.

[NikosD]

It should be a fixed-function VP9 accelerator according to my experience.
I tested on some 4K_HEVC_10bit_60p and 4K_VP9_8&10bit_60p clips and found the GPU is extremely slow........ With EVR-CP, its dead, R.I.P[emoji317] With vanilla EVR, well can work but GPU usage is also very high ~90+.


From your results, the CPU usage (almost zero) and the Video Decoding usage (~100%) according to Task Manager, it is 100% sure that the Video Decoding hardware is a pure fixed function implementation.

But the GPU usage shows me a crippled system regarding rendering and displaying the image on the screen.

It looks like Optimus.

Those 95fps of pure decoding are good enough for any clip I think, but they drop to 50fps using EVR.
Not good.

But it's only single channel memory, the results could be a lot better with dual channel memory.

That's a problem that discrete VEGA cards with VCN 1.0 (Video Core Next) shouldn't have and they should keep those 95fps using EVR or even EVR-CP.

[wanezhiling]

Don't worry, AMD is not sentenced to death yet, I will buy a Ryzen 5 2400G soon.

[aufkrawall]

That's a problem that discrete VEGA cards with VCN 1.0 (Video Core Next) shouldn't have and they should keep those 95fps using EVR or even EVR-CP.
Current discrete Vega cards don't have the new VCN of Raven Ridge, and for the one paired with Intel CPU it doesn't matter.

[el Filou]

8 Vega CUs should have no problem downscaling 4K (at least with EVR), the issue is definitely the single channel DDR4-2133.
My discrete card can use up to 13,5-14,5 GB/s memory bandwidth in that situation.
AMD needs some quad channel DDR4 memory for their APUs, that would help a lot. :D

[aufkrawall]

Quick idea: Give Windows 10 video app a try. I wouldn't recommend it for actually watching videos, but it's low on resources and probably can use D3D11VA for VP9 10 bit.

[sneaker_ger]

From VLC 3.0 release notes:
Hardware Decoder:
* Support 4:4:4 and 4:2:2 chroma samplings with VDPAU hw acceleration

What is the meaning behind this? Nvida says: "Decode HW: 4:2:0, ** 4:2:2 is not natively supported on HW (https://developer.nvidia.com/nvidia-video-codec-sdk)".

[Yups]

From your results, the CPU usage (almost zero) and the Video Decoding usage (~100%) according to Task Manager, it is 100% sure that the Video Decoding hardware is a pure fixed function implementation.



It's a slow fixed function implementation (if it is). 72 FPS for VP9 10 bit, my old HD 630 with DDR4-3200 gets 255 fps for this VP9 sample.

[huhn]

From VLC 3.0 release notes:


What is the meaning behind this? Nvida says: "Decode HW: 4:2:0, ** 4:2:2 is not natively supported on HW (https://developer.nvidia.com/nvidia-video-codec-sdk)".

nvidia support hardware decoding of 4:4:4 >lossless progressive< h246 and maybe h265

[NikosD]

It's a slow fixed function implementation (if it is). 72 FPS for VP9 10 bit, my old HD 630 with DDR4-3200 gets 255 fps for this VP9 sample.

Mobile Kabylake CPUs with HD 600 iGPU series released on Q3 2016 but still HD 600 series is the latest iGPU architecture from Intel, even Coffee lake uses the same architecture.

Obviously for Intel there is no reason to change fixed-function hardware in terms of features or performance since Kabylake.

And I think Intel is right.

Is there something better/faster/more efficient in Nvidia's fixed-function hardware ?

We have to wait for Cannonlake to see if Intel changed something inside fixed-function hardware.

[wanezhiling]

Quick idea: Give Windows 10 video app a try.
I knew that, tested already, very fast, video engine 85%, no frames drop


http://bluesky23.yukishigure.com/en/DXVAChecker.html

Version 4.0.0 (02/10/2018)
Added support for video playback and decode using D3D11 Video Acceleration
Added support for video playback using DXVA-HD Video Acceleration
Added GPU engine usage monitor (Winodws10 Fall Creators Update only)
Added support for HEVC Video Extension decoder and MPEG2 Video Extension decoder
Added support to check VP9 hybrid decode acceleration on AMD Radeon GPU
Fixed issue when selecting "VP9" for format in DirectShow/MediaFoundation Decoder Check
Added "Process Priority" setting on playback and decode performance setting form
Updated DSF/MFT Viewer
Changed "DXVA2" to "D3D9" in "Attribute" on DSF/MFT Viewer
Changed system requirements
Minor changes and fixes

[Yups]

Mobile Kabylake CPUs with HD 600 iGPU series released on Q3 2016 but still HD 600 series is the latest iGPU architecture from Intel, even Coffee lake uses the same architecture.

In the meantime AMD released two new GPU architectures. Intel didn't because of their 10nm delays. It's still their old 2015 Gen9 architecture with the addition of a Gen9.5 media block. And Geminilake gets a Gen10 display controller.



We have to wait for Cannonlake to see if Intel changed something inside fixed-function hardware.

Cannonlake is dead more or less, especially 2+2. Intels next meaningful GPU progress will come with Icelake.

[NikosD]

http://bluesky23.yukishigure.com/en/DXVAChecker.html

OMG!

What an amazing version is this.

It has everything we have ever dreamed of and all the features are working perfect.

I tried v4.0.0 using my AMD RX 470 Polaris card on Win 10 Fall Creators Update and it is simply amazing.

You can use and benchmark D3D11 decoding in both native and playback modes.

It can display GPU and Video Decoding usage even using AMD cards (Fall Creators Update only)

It can use and benchmark hybrid VP9 acceleration of VP9 using Polaris cards (!)

The hybrid VP9 accelerator of RX 470 is ~60% faster than my CPU Sandy Core i5-2400 with half CPU usage (!)

I didn't take a look on DXVA-HD acceleration, next time.

All in all, amazing work once again.

[nevcairiel]

I didn't take a look on DXVA-HD acceleration, next time.

Back when I tried to play with it, AMD didn't implement DXVA-HD at all. Not sure that changed. DXVA-HD also goes mostly unused, so its probably not a big deal.

[aufkrawall]

It still reports that DXVA HD is not supported, but I'm really not missing it.

The VP9 hybrid decoder of Polaris seems to be much more useful than what Nvidia used on Maxwell for HEVC 8 bit, at least it doesn't fry the GPU.

Btw: mpv offers zero copy D3D11VA, it saves quite an amount of CPU and GPU performance here with AMD. Weird thing is that it had the opposite effect with Nvidia.

[littleD]

DXVA-HD is not used by any decoder on main dxva checker page. Nonetheless intel supports it for kabylake at least in one of the earlier gpu drivers releases.

Also i believe that on second tab (dsh/MF decoder) all benchmarks and playback is done only at supported "mode" by decoder. So, even if you choose dxva-HD, you play at either dxva2 or dxva11, and lavfilters are one-level decoder, so you have to manually change option dxva vs d311, and lavs supports on decoder tab, only one "mode" at a time.

After some short testing in d3d11 mode, microsoft mf decoder plays Arri65_from_raw.mp4 file fluent, while lavfilters shutters, and thats the concern on intel all the time.

[NikosD]

Well, my HD 4400 of Core i3 4170 with v4835 drivers (latest) has DXVA-HD "Playback" mode available in benchmark and normal playback.

I can't see any difference in terms of quality or performance compared to DXVA2 and D3D11.

I think that DXVA-HD is rather old used in Windows 7 OS and it doesn't make any difference.

Just another feature added to an impressive tool - DXVAChecker - in order to be complete, I think.

[v0lt]

DXVA-HD is not a decoder, it's a video processor. It's similar to DXVA2-VP, but it has a slightly different API.
https://msdn.microsoft.com/en-us/library/windows/desktop/ee663586(v=vs.85).aspx
Microsoft DirectX Video Acceleration High Definition (DXVA-HD) is an API for hardware-accelerated video processing. DXVA-HD uses the GPU to perform functions such as deinterlacing, compositing, and color-space conversion.

DXVA-HD is similar to DXVA Video Processing (DXVA-VP), but offers enhanced features and a simpler processing model. By providing a more flexible composition model, DXVA-HD is designed to support the next generation of HD optical formats and broadcast standards.

[NikosD]

Test system:

Core i5-2400 (Sandybridge)

Win 10 x64 (16299.194)

AMD RX 470 - 18.2.1 drivers

DXVA Checker v4.0.0 in Decode Benchmark Mode

LAV filters x64 0.71



Legacy (Bluray) codecs (MPEG2, VC-1, H.264)



MPEG2 (1080p clip 38Mbps / 30fps)


LAV CPU 479fps CPU 70%

LAV DXVA2 cb 179fps CPU 4% GPU 15% VPU 99%

MS MF DXVA2 161fps CPU 29%

LAV D3D11 cb 155fps CPU 6% GPU 8% VPU 93%

MS MF D3D11 131fps CPU 26% VPU 99%

LAV DXVA2 na 128fps CPU 1% GPU 0% VPU 98%


Comments:

1) LAV SW decoding is a lot faster than HW decoding, as MPEG2 is an easy to decode format and HW acceleration doesn't care for top speeds (for AMD at least)

2) LAV DXVA2 native performance is the lowest and copy-back is the highest, probably because clocks are pushed higher for 3D (copy-back) mode.
I didn't monitor GPU clocks, but i have no other explanation.
AMD is using UVD in a strange way.

3) MS MF DXVA2 falls back to SW mode for MPEG2.



VC-1 (Devil May Cry 1080p clip 40Mbps / 60fps)



MS MF CPU 232fps CPU 93%

LAV CPU 220fps CPU 92%

MS DS CPU 194fps CPU 93%

LAV DXVA2 cb 95fps CPU 3% GPU 8% VPU 99%

LAV D3D11 cb 81fps CPU 3% GPU 4% VPU 96%

LAV DXVA2 na 47fps CPU 0% GPU 0% VPU 99%

MS MF DXVA2 47fps CPU 1% GPU 0% VPU 99%

MS MF D3D11 47fps CPU 25% VPU 99%




Comments:

1) VC-1 is more complex to decode using the same bandwidth than MPEG2 (For AMD's implementation)

2) MS MFT CPU decoding is faster than both DS filters (LAV, MS DS) and all CPU decoders are a lot faster than HW VC-1 decoding (for AMD at least)

3) LAV DXVA2 native performance, like MS MFT DXVA2/D3D11 native, is the lowest and copy-back is the highest, probably because clocks are pushed higher for 3D (copy-back) mode and it's lower than real-time (47fps vs 60fps)
I didn't monitor GPU clocks, but i have no other explanation.
AMD is using UVD in a strange way.

4) During normal playback using DXVA2 native mode, you can reach 60fps easily like DXVA2 copy-back mode and unlike DXVA2 native in Decode Benchmark mode.
AMD is using UVD in a strange way.




H.264 (Ducks Take Off 2160p clip 370Mbps / 50fps)



LAV DXVA2 cb 59fps CPU 6% GPU 18% VPU 98%

LAV D3D11 cb 59fps CPU 7% GPU 11% VPU 99%

MS MF DXVA2 na 58fps CPU 2% GPU 0% VPU 98%

MS MF D3D11 58fps CPU 3% GPU 0% VPU 99%

LAV DXVA2 na 57fps CPU 3% GPU 0% VPU 98%

LAV CPU 23fps CPU 93%

MS DS CPU 19fps CPU 95%

MS MF CPU 19fps CPU 96%

MS DS DXVA2 na Incompatible





Comments:

1) 370Mbps bandwidth is no match for Sandy Core i5 CPU. You need HW acceleration (obviously)

2) There is no real difference between copy-back and native modes regarding performance

3) LAV (ffmpeg) CPU decoding is more optimized than MS

4) MS DS DXVA2 native could only decode once that particular clip (the other runs couldn't complete)


Last comment for all clips (MPEG2, VC-1, H.264)

D3D11 cb is more optimized than DXVA2 cb in terms of lower GPU usage for LAV.

All MS MFT HW accelerated codecs work in native mode.

[Zetti]

http://bluesky23.yukishigure.com/en/DXVAChecker.html
Version 4.0.1 (02/18/2018)
Fixed the same GPU was displayed in GPU selector when enabling extend on multi display
Fixed HEVC_VLD_Main was not displayed as supported mode in LAV Filters Version 0.71.0 when selecting "H.265/HEVC" for format

[NikosD]

Has anyone noticed that H.264 spec has expanded to 8K officially ?

It seems that there are new Levels 6, 6.1, 6.2 which all support 8K and especially L6.2 goes up to 8K120fps and 800 Mbps (!) bandwidth.

I wonder if there are any actual commercial uses for those H.264 levels and if x264 supports those levels in its latest versions.

I'm sure no HW accelerator exists supporting H.264 L6.x, though.

[sneaker_ger]

x264 supports the new levels.

[mytbyte]

@NikosD: it's probably to standardize 8K h264 for picture aquisition (in cameras). It's easier to decode in CPU than h265 in editing or if CPU is still too weak, it gets converted to intermediate low-CPU, gigantic-files-codec for editing more often than not

[NikosD]

DXVA-HD is not a decoder, it's a video processor. It's similar to DXVA2-VP, but it has a slightly different API.

x264 supports the new levels.

@NikosD

Thanks all for the info!

[NikosD]

Test system:

Core i3-4170 (Haswell)

Win 10 x64 (16299.194)

Dual DDR3-1600MHz

Intel iGPU HD 4400@1.3GHz - v4835 drivers

DXVA Checker v4.0.1 in Decode Benchmark Mode

LAV filters x64 0.71



Legacy (Bluray) codecs (MPEG2, VC-1, H.264)



MPEG2 (1080p clip 38Mbps / 30fps)



LAV DXVA2 na 1470fps CPU 13% GPU 0% VPU 99%

MS MF D3D11 750fps CPU 15% VPU 52%

LAV DXVA2 cb 421fps CPU 15% GPU 0% VPU 60%

LAV CPU 407fps CPU 77%

LAV DXVA2 QS 358fps CPU 33% GPU 0% VPU 52%

MS MF DXVA2 198fps CPU 28%

LAV D3D11 cb 170fps CPU 3% GPU 60% VPU 19%





Comments:

1) Make no mistake, that 1470 fps performance is real. QuickSync ASIC is extremely fast even in that ancient and less demanding format - MPEG2

2) The MS MFT DXVA2 performance is unexpectedly slow, the SW fall back mode doesn't seem to utilize properly the CPU.

3) The fastest performance comes when VPU is fully utilized and iGPU clocks go up to maximum 3D clocks, which is the case for LAV DXVA2 native and MS MFT D3D11 only.



VC-1 (Devil May Cry 1080p clip 40Mbps / 60fps)



LAV DXVA2 na 1067fps CPU 12% GPU 0% VPU 93%

MS MF D3D11 678fps CPU 8% GPU 27% VPU 59%

MS MF DXVA2 668fps CPU 10% GPU 28% VPU 60%

LAV DXVA2 cb 565fps CPU 26% GPU 0% VPU 80%

LAV DXVA2 QS 220fps CPU 19% GPU 0% VPU 41%

MS MF CPU 154fps CPU 50%

LAV CPU 143fps CPU 51%

LAV D3D11 cb 127fps CPU 5% GPU 55% VPU 23%

MS DS CPU 119fps CPU 72%



Comments:

1) VC-1 is more complex to decode using the same bandwidth than MPEG2 (For Intel's implementation)

2) Again the highest performance is achieved by using DXVA2 native mode of LAV video, leveraging fully the VPU and 3D highest clocks.




H.264 (Ducks Take Off 2160p clip 370Mbps / 50fps)



LAV DXVA2 na 144fps CPU 7% GPU 0% VPU 94%

MS DS DXVA2 137fps CPU 12% GPU 0% VPU 90%

MS MF D3D11 123fps CPU 7% GPU 0% VPU 76%

MS MF DXVA2 110fps CPU 4% GPU 0% VPU 69%

LAV DXVA2 cb 97fps CPU 17% GPU 0% VPU 79%

LAV DXVA2 QS 58fps CPU 28% GPU 0% VPU 72%

LAV D3D11 cb 46fps CPU 5% GPU 42% VPU 34%

LAV CPU 20fps CPU 93%

MS DS CPU 11fps CPU 48%

MS MF CPU 10fps CPU 46%



Comments:

1) This time we don't see huge numbers for HW acceleration, but still it's almost 3x real-time decoding (50fps vs 144fps)

2) LAV (ffmpeg) CPU decoding is twice as fast as MS, due to the CPU utilization (MS is like using no hyperthreading)



Last comment for all clips (MPEG2, VC-1, H.264)

1) D3D11 cb is more optimized than DXVA2 cb in terms of lower CPU usage but no GPU usage like AMD.

This time for Intel, GPU usage using D3D11 is huge (especially for LAV).

2) All MS MFT HW accelerated codecs work in native mode.

[NikosD]

Test system:

Core 2 Duo E7300 (Wolfdale@2.83GHz)

Win 10 x64 (16299.192)

Nvidia GT610 - v390.77 drivers

PCI-E v1.x compatible (x4)

DXVA Checker v4.0.1 in Decode Benchmark Mode

LAV filters x64 0.71


The Nvidia card has two more parameters monitored by DXVA Checker, than Intel and AMD.

For MPEG2 and VC-1 it uses three video decoding engines, so DXVA Checker reports three different values for Video decoding.

For H.264, Nvidia uses two video decoding engines and one GPU copy engine, so DXVA Checker reports two different values for video decoding and one for GPU copy.

I measured the copy-back modes for MPEG2 but for the other two formats i didn't, because of the slow PCI-E bus.



Legacy (Bluray) codecs (MPEG2, VC-1, H.264)



MPEG2 (1080p clip 38Mbps / 30fps)



MS MF D3D11 166fps CPU 10% GPU 0% VPU 98%

LAV DXVA2 na 165fps CPU 8% GPU 0% VPU 98%

LAV CPU 124fps CPU 74%

MS MF DXVA2 104fps CPU 18%

LAV D3D11 cb 59fps CPU 36% GPU 84% VPU 38%

LAV DXVA2 cb 52fps CPU 7% GPU 84% VPU 43%

LAV CUVID 47fps CPU 5% GPU 87% VPU 36%




Comments:


1) The MS MFT DXVA2 performance is unreasonable again, as it seems that SW fall back is strange at least.




VC-1 (Devil May Cry 1080p clip 40Mbps / 60fps)



LAV DXVA2 na 146fps CPU 10% GPU 0% VPU 99%

MS MF D3D11 145fps CPU 2% GPU 0% VPU 99%

MS MF DXVA2 145fps CPU 5% GPU 0% VPU 99%

LAV D3D11 cb 59fps CPU 38% GPU 82% VPU 45%

MS MF CPU 53fps CPU 90%

LAV CPU 49fps CPU 90%

MS DS CPU 44fps CPU 93%



Comments:


1) VC-1 seems to have the same complexity to decode using the same bandwidth like MPEG2 (For Nvidia's implementation)




H.264 (Ducks Take Off 2160p clip 370Mbps / 50fps)



MS MF D3D11 29fps CPU 3% GPU 0% VPU 99%

MS MF DXVA2 28fps CPU 4% GPU 0% VPU 96%

LAV DXVA2 na 28fps CPU 5% GPU 0% VPU 97%

MS DS DXVA2 27fps CPU 9% GPU 0% VPU 95%

LAV D3D11 cb 16fps CPU 15% GPU 85% VPU 57%

LAV CPU 9fps CPU 94%

MS MF CPU 7fps CPU 94%

MS DS CPU Incompatible




Comments:

1) The specific clip with 370Mbps bandwidth is clearly out of real-time decoding for the old VP5 video decoder of Nvidia.

2) Again these are the most reasonable results with no surprises, besides the wrong number of decoded frames for MS DS CPU.

[el Filou]

Why test H.264 at such a high bitrate when you'll never encounter that in any commercial content?

[wanezhiling]

https://s14.postimg.org/rtykjnvvl/234242rzcdwwrv4pdo9p4g.jpg

Desktop R3 2200G, no miracle

[NikosD]

Desktop R3 2200G, no miracle

Only 1GB for VRAM ?

The GPU usage goes to maximum 100% probably due to low VRAM and scaling.

The VPU could reach 60fps, it's not 100% used.

[huhn]

gaming tests show it doesn't really matter if you give the iGPU 64 mb or 2 gb of Vram the performance is about the same.

and it is a really bad implementation if you have to tweak it anyway. so i point at driver or they don't really care.

[el Filou]

Yes, modern iGPUs dynamically allocate VRAM.

Isn't there some way with and AMD app to "tune" the available power of the APU in favour of its GPU? The task manager graph shows it's compute limited.

[NikosD]

Vega 8/11 is a very very powerful iGPU (actually the strongest iGPU ever), so it's completely unreasonable why GPU usage goes to 100%

Driver problem ?
hidden VPP filters enabled by default ?
HW implementation fault (like Optimus) ?

Who knows...

[v0lt]

Desktop R3 2200G, no miracle
Please make a screenshot in MPC-BE.

MPC-BE 1.5.2.3435 without installer is here (https://yadi.sk/d/hNmZm-Yq3NkFuM).

[mytbyte]

I'm not sure AMD APU-s will allocate more than 1GB even if they do allocate VRAM dynamically i.e it will use dynamic allocation up to the 1GB limit...it must be forced in BIOS to 2GB...I feel lack of VRAM is the primary reason, gaming is a different beast

[littleD]

I cannot believe it but it is truth, 250MB vs 2GB gives almost no difference in games https://www.youtube.com/watch?v=YDmYHpykcDo
Thats how modern system works.

On a wanezhiling picture VRAm is set to 1GB and is fully occupied. Does decode engine behave differently than games?

Remeber, recommended RAM clocks are 3200 MGH which gives nice boost over 2400. Should help a bit decoding too?