Evaluation of HEVC decoders (SW, Hybrid and HW)

[NikosD]

Welcome to this thread regarding the evaluation of HEVC decoders (HW,Hybrid and SW)

The latest update with new samples for evaluating pure fixed-function HW HEVC decoders is here (https://forum.doom9.org/showthread.php?p=1799099#post1799099) testing Kabylake HD 610, Skylake HD 530, nVidia Turing GTX 1660 Nvidia Pascal GTX 1050 Ti/1060, Nvidia Maxwell 3rd gen GTX 960 and AMD Polaris RX 470 - 01/03/2017

Added some info on VP9 acceleration support of browsers using Youtube on various hardware (including Polaris cards) here (https://forum.doom9.org/showthread.php?p=1813127#post1813127) - 22/07/2017

The first official confirmation of Skylake's (HD 530) 8K (!) HEVC 8bit decoding capability in pure HW decoding mode here (http://forum.doom9.org/showthread.php?p=1737321#post1737321) by Yups - 05/09/2015

Here (http://forum.doom9.org/showthread.php?p=1735714#post1735714) is the comparison between Skylake HD 530 and Nvidia GTX 960 - 24/08/2015

Probably world's first Skylake 4K HEVC 8bit (HD 530) decoding results here (http://forum.doom9.org/showthread.php?p=1735325#post1735325) and here (http://forum.doom9.org/showthread.php?p=1735329#post1735329) and here (http://forum.doom9.org/showthread.php?p=1735586#post1735586) by Yups: (looks like the world's fastest HW decoder for 8bit HEVC) - 22/08/2015

For updated Optimus results, take a look here (http://forum.doom9.org/showthread.php?p=1724055#post1724055) - 27/05/2015


For those interested in hybrid only results on Intel's iGPU (DXVA, OpenCL), look at the results of the new PowerDVD 15 x86 (DXVA, OpenCL) and latest LAV 0.65/MPC 1.4.4.286 DXVA x64/x86 decoders here (http://forum.doom9.org/showthread.php?p=1718243#post1718243)- 22/04/2015

New updated CPU results for latest Lentoid v2.1.0.0, LAV v0.67.3 and MS H.265 decode (build 10586) here (http://forum.doom9.org/showthread.php?p=1748100#post1748100) - 29/11/2015

For those interested in CPU only results, look at the results of the new Lentoid x64/x86 v2.0.3.2, PowerDVD 15 on various CPU architectures and systems including Win 10 Build 10049 using latest LAV 0.65/MPC 1.4.4.286 decoders.
Also added a 10bit HEVC video here (http://forum.doom9.org/showthread.php?p=1717938#post1717938) - 22/04/2015


Added new results for the first public release of UHDcode, the HEVC decoder of MultiCoreWare here (http://forum.doom9.org/showthread.php?p=1715668#post1715668)- 01/04/2015


For HW decoder results of Nvidia 960 GTX, you have to see the post from Nevcairiel here (http://forum.doom9.org/showthread.php?p=1706902#post1706902) - 23/01/2015
(these are the world's first benchmark results of the fixed-function HEVC decoder inside GTX 960)

For a little older tests - 14/01/2015 - including PowerDVD v14 decoder, Microsoft's MFT Windows 10 decoder, a 10bit clip, on various CPU architectures (from Core 2 Duo up to Core i7 Haswell) take a look here (http://forum.doom9.org/showthread.php?p=1705352#post1705352)


The tool I use is always DXVA Checker you can download from here (http://bluesky23.yukishigure.com/en/index.html)


The first post (23/09/2014) starts here:

I used latest DXVA Checker x86/x64 version v3.1.2 using DXVA processing and a scaling resolution of 1280x720 for all clips.


1080p clips

1.ProRes-1080p@30fps-2Mbps
https://www.sendspace.com/file/mo8exg


LAV x64 i7-4790 158/230/251

LAV x86 i7-4790 121/151/188

LAV x64 i7-4790 (DXVA) 83/134/157

LAV x86 i7-4790 (DXVA) 84/133/158

Strongene x86 i7-4790 (OpenCL) 83/112/146

Strongene x86 i7-4790 97/109/111

LAV x64 i5-4200M 76/98/114

LAV x64 i5-4200M (DXVA) 60/84/96

LAV x64 Core 2 Quad 45/52/54




2.Elephants Dream-1080p@24fps-1.7Mbps
http://www.libde265.org/hevc-bitstreams/elephants-dream-1080-cfg02.mkv


LAV x64 i7-4790 93/195/242

LAV x64 i7-4790 (DXVA) 78/138/204

LAV x86 i7-4790 (DXVA) 66/135/200

LAV x86 i7-4790 62/133/259

Strongene x86 i7-4790 66/107/116

LAV x64 i5-4200M 40/97/130

LAV x64 i5-4200M (DXVA) 44/84/112

LAV x64 Core 2 Quad 35/52/55

Strongene x86 i7-4790 (OpenCL) Crashed



3.Big Buck Bunny-1080p@60fps-2Mbps
http://www.libde265.org/hevc-bitstreams/bbb-1920x1080-cfg06.mkv


LAV x64 i7-4790 144/232/267

LAV x64 i7-4790 (DXVA) 123/165/230

LAV x86 i7-4790 (DXVA) 113/161/201

LAV x86 i7-4790 67/146/259

LAV x64 i5-4200M 66/109/131

LAV x64 i5-4200M (DXVA) 68/97/114

LAV x64 Core 2 Quad 45/53/55

Strongene x86 i7-4790 (OpenCL) Crashed

Strongene x86 i7-4790 Crashed just before the end of the file



UHD - 3840x2160p clips


1.Beauty-2160p@30fps-12.3Mbps
http://ultravideo.cs.tut.fi/video/Beauty_3840x2160_120fps_420_8bit_HEVC_MP4.mp4


LAV x64 i7-4790 51/63/65

Strongene x86 i7-4790 (OpenCL) 26/47/47

LAV x86 i7-479025/40/43

Strongene x86 i7-4790 20/34/35

LAV x64 i7-4790 (DXVA) 29/33/35

LAV x86 i7-4790 (DXVA) 30/32/33

LAV x64 i5-4200M 15/25/27

LAV x64 i5-4200M (DXVA) 19/21/22

LAV x64 Core 2 Quad 6/13/13



2.Fitness-2160p@30fps-8Mbps
http://cloud.ultrahdtv.net/fitness-trailer-8000.mkv


LAV x64 i7-4790 57/71/82

LAV x64 i7-4790 (DXVA) 41/55/77

LAV x86 i7-4790 (DXVA) 40/52/76

LAV x86 i7-4790 35/48/71

Strongene x86 i7-4790 28/40/50

LAV x64 i5-4200M (DXVA) 25/30/39

LAV x64 i5-4200M 22/29/38

LAV x64 Core 2 Quad 9/13/13

Strongene x86 i7-4790 (OpenCL) Crashed



3.Ducks-2160p@50fps-4Mbps
https://www.sendspace.com/file/cyiv49


LAV x64 i7-4790 62/72/73

Strongene x86 i7-4790 (OpenCL) 29/46/50

LAV x86 i7-4790 (DXVA) 43/45/47

LAV x64 i7-4790 (DXVA) 42/45/47

Strongene x86 i7-4790 27/41/42

LAV x86 i7-4790 29/40/44

LAV x64 i5-4200M 25/31/33

LAV x64 i5-4200M (DXVA) 27/29/30

LAV x64 Core 2 Quad 10/13/13



Comments:

I used latest nightly of LAV filters 0.62.46 (24-09-2014) with LAV Video threads set to Auto and latest Strongene's OpenCL and CPU HEVC decoders.

The Core i7 system tested was:
Win 8.1 Pro x64 - Core i7-4790 - HD 4600 - Drivers v.3907

The Core i5 system tested was:
Win 8.1 x64 - Core i5-4200M@2.5GHz (battery mode) - HD 4600 - Drivers v.3907 - Nvidia 740M - Drivers 344.11 - Optimus technology

The Core 2 Quad system tested was:
Win 8.1 Pro x64 - Core 2 Quad Q9550@2.26GHz (266MHz x 8.5) - Nvidia GT610 - Drivers 344.11

For laptop and Nvidia hybrid decoder, see my post here (http://forum.doom9.org/showthread.php?p=1694992#post1694992)

For tests using more threads than Auto, null renderer, overclocked CPUs and different OS (Win 7) check this (http://forum.doom9.org/showthread.php?p=1695007#post1695007) post:

CPU decoders for Core i7


The CPU decoders were using GPU as low as possible ~25%-35% with 600MHz clock, but Strongene's CPU was a little higher ~80%@600MHz

1080p
For LAV x86/x64 CPU decoders, CPU utilization was 55% - 60% using all 8 threads with a clock of 3.8GHz, for Strongene CPU decoder it was only 16% !!! with a clock of ~4.0GHz with only a few threads enabled.

2160p
For LAV x64 CPU decoder, CPU utilization was 77% - 91% using all 8 threads with a clock of 3.8GHz, for LAV x86 CPU CPU utilization was 92% - 94% using all 8 threads with a clock of 3.8GHz, for Strongene CPU decoder it was only 25% -29% !!! with a clock of ~4.0GHz with only a few threads enabled.



CPU decoders for Core i5/ Core 2 Quad


I used only LAV x64 decoder and the results are completely weird.

Core i5-4200M@2.5GHz is a dual core processor with four threads (2C/4T) and achieved a CPU utilization of 76% - 86% for 1080p and 76% - 89% for 2160p

Core 2 Quad Q9550@2.26GHz is a quad core processor with four threads (4C/4T) and achieved a CPU utilization of 50% - 58% for 1080p and 55% - 60% for 2160p

For all clips the performance of the dual core Core i5@2.5GHz is almost double than the quad Core 2 Quad@2.26GHz with more than 50% CPU utilization (!) for the dual core (2C/4T) chip (!!)



GPU decoders for Core i7


1080p
The DXVA decoders were using GPU at ~100% and max 1200MHz clock and CPU at ~14% with a clock of 2.6GHz - 4.0GHz

Strongene's OpenCL decoder used GPU like Strongene's CPU decoder - only a few MHz higher (600MHz - 750MHz) and a CPU usage of ~11% at 4.0GHz


2160p
The DXVA decoders were using GPU at ~90% and max 1200MHz clock and CPU at ~14% with a clock of 2.6GHz - 4.0GHz.

The memory usage went to the limit of ~960MB-990MB, the maximum that iGPU can use.

Strongene's OpenCL decoder used GPU a lot more than 1080p at 85%@850MHz - 900MHz and the CPU usage of 36% - 50% at 3.8GHz-4.0GHz which is double than Strongene's CPU decoder!


GPU decoders for Core-i5

See here (http://forum.doom9.org/showthread.php?p=1694992#post1694992)



----------------------------------------------------------------------------------------------------------------------------------
LAV DXVA x86 and x64 have almost the same performance and in 2160p they are slower than OpenCL decoder, mainly because of the CPU usage of OpenCL decoder and not GPU.

It's interesting that LAV DXVA x86/x64 is faster than LAV CPU x86 in 1080p clips and low bitrate 2160p clips.
But in just 12Mbps 2160p clip, the LAV x86 CPU is faster than DXVA.

During benchmarking LAV CPU decoders were using more power (watt) than DXVA or OpenCL decoder, but I think during playback the opposite occurs (I haven't tested yet)

I used latest Intel's GPA tool to monitor any QuickSync (fixed-function HW) activity, but it was a dead zero during DXVA decoding.

So everything is decoded in EUs and a little CPU for HEVC DXVA2 decoder.

----------------------------------------------------------------------------------------------------------------------------------

Conclusion

LAV DXVA uses maximum iGPU memory of 1GB for 4K decoding and with a low bandwidth of even 12Mbps is slower even than LAV x86 CPU.
It's more useful for lower resolutions.

Strongene's OpenCL decoder is definitely a lot more useful for 4K than 1080p, but it has incompatibilities and in order to be fast at 4K it uses a lot the CPU, not so much the GPU.

Strongene's CPU decoder is almost always slower of all.

LAV x64 CPU is always faster than anything else in all bitrates and resolutions.

CPU utilization of all CPU decoders, rises with the increased resolution and low bitrate.
Best example is Duck 2160p@4Mbps clip with LAV x64 CPU utilization of 91% and LAV x86 at 94%

When bandwidth increases a little, the CPU utilization and decoding performance drops more.

For all decoders I used a good case scenario of a 1280x720 display resolution.

When native resolution is used for display at 1080p and 2160p, the results are lower by a good percentage.

For 4K BluRay with a bitrate of 100Mbps and 10 bit resolution, expect CPU decoders and hybrid decoders to be useless (?)* even with Haswell-E or Xeon processors.

We are going to need definitely pure fixed-function HW decoders for 4K BluRay.

On the other hand, 4K BluRay will appear on winter holidays of 2015, so until then, CPU and hybrid decoders are just fine for low bandwidth and low fps clips that HEVC is the best codec to use.

I have already encoded 4K H.264 and 4K H.265 up to 600Mbps (!) and I can say for sure that 4K H.264 performance of Haswell QuickSync decoder is about 190fps for 4K H.264 100Mbps clip at 1280x720 display resolution.

Intel and Nvidia decided to offer a hybrid solution now, which is a useful choice for low fps, low bandwidth clips even at 4K resolution and by the time of 4K BluRay arrival, fixed-function decoders will be ready.

Hopefully AMD will follow.

* according to these (http://forum.doom9.org/showthread.php?p=1694854#post1694854) results by cyberbeing an overclocked CPU - even without HT - and a real fast Nvidia card can handle even more difficult to decode 4K HEVC clips at greater speed than my results.

But still 4K BluRay will be out of their reach I think.

[NikosD]

Next thing to test is a special driver from Nvidia or Intel or a LAV filters special version with significant gain in performance (CPU or Hybrid) for Nvidia or Intel.

I'll definitely try to repeat the tests with Optimus laptop to check if anything has changed regarding Nvidia's hybrid decoder performance.

If any of you has interesting samples (difficult to decode), I would give them a try, especially in 1080p resolution for which I didn't find a lot of samples.

[wanezhiling]

Off topic: Today's PotPlayer 1.6.49903 has supported HEVC CUDA/DXVA decoding as well. :)

http://i.imgur.com/hcLDgBG.png

[nevcairiel]

They are fast with stealing my code, apparently.

[sneaker_ger]

If any of you has interesting samples (difficult to decode), I would give them a try

Astra 4K demo channel:
https://www.dropbox.com/s/6rbqlrrhhvbz79l/Astra%20UHD.ts?dl=0 (probably not cut correctly at GOP border)

But it uses 10 bit coding - I don't know if Nvidia and Strongene support that?

[JohnLai]

They are fast with stealing my code, apparently.

So, what is the action you will take against them?

This code stealing activity is frowned upon.

[NikosD]

They are fast with stealing my code, apparently.

So, what is the action you will take against them?

This code stealing activity is frowned upon.

Guys, please don't start this discussion here.

I think there are threads here in Doom9 with that subject - I think it has been discussed thoroughly - or you can start a new thread about that.

Astra 4K demo channel:
https://www.dropbox.com/s/6rbqlrrhhvbz79l/Astra%20UHD.ts?dl=0 (probably not cut correctly at GOP border)

But it uses 10 bit coding - I don't know if Nvidia and Strongene support that?


Well, you are going to make me buy a new CPU for that file!

I used latest nightly MPC-HC x64 and I got a lot of stuttering using EVR-CP.
I had to use plain EVR in order to be smoother, but I can't say it was absolutely smooth.

LAV DXVA, Strongene's OpenCL and CPU decoders are all incompatible with 10-bit HEVC, so I can't use them for decoding comparisons.

I don't know yet about Nvidia's HEVC decoder, but I think only LAV CPU can decode 10-bit HEVC clips.

BTW, I have a lot of 10 bit 4K HEVC clips from here http://demo-uhd3d.com/ which all of them stutter during playback.

It's not exactly stutter or judder, it's like repeatedly spasmodic movement, after a few seconds of normal playback each time - you can call it stutter.

The problem with those 6 demo files I have, is that the CPU utilization is below 50% when the movement looks like stuttered.

I thought the problem was in the encoding or muxing and stopped downloading other clips from that site for that reason.

Is it possible the decoding speed to be the reason of stuttering ?

Those clips are huge.

6 of them are 5.15GBytes on my disk.

I don't know if you grabbed your sample from there and you cut a smaller sample, but if you have a link of the original source I would like to download the whole file.

Also I would be interested in HEVC 1080p files too.

[sneaker_ger]

Well, you are going to make me buy a new CPU for that file!
Yes, it's very demanding. My core i7-860 does less than the at least required 50 fps on that sample even with Null Renderer. But compared to the 4K Blu-Ray this is low bitrate. We're looking at 4Kp60, 10 bit and more bitrate than current Blu-Rays.

I don't know if you grabbed your sample from there and you cut a smaller sample, but if you have a link of the original source I would like to download the whole file.
It's a direct capture from the Astra 19.2° satellite.

[NikosD]

Yes, it's very demanding. My core i7-860 does less than the at least required 50 fps on that sample even with Null Renderer.



I get 56/67/77 with Null Renderer (DXVA Decoding using DXVA Checker) using 8 threads @ 3.8GHz with 76% utilization.


But compared to the 4K Blu-Ray this is low bitrate. We're looking at 4Kp60, 10 bit and more bitrate than current Blu-Rays.


By that time, I think around winter holidays of 2015, we will have HW decoders which will eat 4K Bluray for breakfast :)


It's a direct capture from the Astra 19.2° satellite.


OK, thanks.

[huhn]

the potplayer hevc hardware decoder is used with 10 bit hevc it totally fails and uses only 1 thread for decoding but there is something like a picture.

the output is reported as nv12 by madVR

[NikosD]

Added 2160p clips and changed a lot the comments for the new results.

I added a conclusion, too.

[cyberbeing]

i5-3570K @4.4Ghz, 16GB DDR3 1866Mhz 8-9-9-24
NVIDIA GTX 770 2GB, PCI-E 3.0 x8
Win7 SP1 x64
LAV Filters git-33f0b3 (2014-09-21)
DXVA Checker 3.1.2



1.Beauty-2160p@30fps-12.3Mbps

LAV x64 CPU (Null) 91/106/110
LAV x64 CPU (1280x720 scale) 78/100/110

LAV x64 DXVA (Null) 78/86/87
LAV x64 DXVA (1280x720 scale) 78/84/86

LAV x86 DXVA (Null) 76/83/86

LAV x86 CPU (Null) 36/47/53


2.Fitness-2160p@30fps-8Mbps

LAV x64 CPU (Null) 109/132/142
LAV x64 CPU (1280x720 scale) 88/125/142

LAV x64 DXVA (Null) 100/113/146
LAV x64 DXVA (1280x720 scale) 97/111/125

LAV x86 DXVA (Null) 86/101/123

LAV x86 CPU (Null) 41/62/118


3.Ducks-2160p@50fps-4Mbps

LAV x64 DXVA (Null) 193/197/198
LAV x64 DXVA (1280x720 scale) 183/187/189

LAV x86 DXVA (Null) 185/189/190

LAV x64 CPU (Null) 128/140/144
LAV x64 CPU (1280x720 scale) 107/131/140

LAV x86 CPU (Null) 36/48/54


Astra-UHD@50fps-18Mbps (10bit)
https://www.dropbox.com/s/6rbqlrrhhvbz79l/Astra%20UHD.ts?dl=0

LAV x64 CPU (Null-P010) 70/86/107
LAV x64 CPU (1280x720 scale-NV12) 65/86/107

LAV x86 CPU (Null-P010) 28/44/86


UHD_ENT_Transformer_Quad@24fps-51Mbps (10bit)
http://demo-uhd3d.com/files/4k/Transformers_extinction_Trailer_4K.zip

LAV x64 CPU (Null-P010) 45/59/102
LAV x64 CPU (1280x720 scale-NV12) 45/59/102

LAV x86 CPU (Null-P010) 25/39/86

[nevcairiel]

Are you sure DXVA was actually used? The performance seems extremely high for 2160p content. I never saw it go above 50 fps at that resolution, no matter how "simple" i made the encodes.

[cyberbeing]

Yes, I'm sure 'DXVA (Native)' was used. CPU usage was low, GPU usage was high. LAV reported 'dxva2n' during playback/benchmark.

Ducks UHD, GPU load ~90%, GTX 770 Core 1200Mhz (Boost)
Fitness UHD, GPU load ~55%, GTX 770 Core 1110Mhz (non-Boost)
Beauty UHD, GPU load ~65%, GTX 770 Core 1110Mhz (non-Boost)

[NikosD]

Yes, I'm sure 'DXVA (Native)' was used. CPU usage was low, GPU usage was high. LAV reported 'dxva2n' during playback/benchmark.

Ducks UHD, GPU load ~90%, GTX 770 Core 1200Mhz (Boost)
Fitness UHD, GPU load ~55%, GTX 770 Core 1110Mhz (non-Boost)
Beauty UHD, GPU load ~65%, GTX 770 Core 1110Mhz (non-Boost)

You have a system with an HD 4600 card and a discrete Nvidia card.

I think HEVC DXVA2 decoder is only for Intel cards, tomorrow I'll try Nvidia cards to see if it works for them too.

I'm sure that Nvidia cards have NVCUVID ability to decode HEVC.

The results of LAV DXVA for what card are referred to ?

Is it Nvidia using NVCUVID ?

[huhn]

no nvidia HEVC DXVA2 works with better kampler cards.

[cyberbeing]

I don't even have the driver from my CPU's HD4000 installed and it's disabled in the BIOS, so it's impossible that it would be used.

LAV added support for both DXVA2 & CUVID on supported NVIDIA cards (Kepler and newer?).

Use of the CUVID or DXVA2 Copyback modes is of course much slower than DXVA2 Native, especially since I'm only using a PCI-E 3.0 x8 link. Though GPU & CPU usage is also much lower when benching in these modes, since the hybrid decoder seems to become heavily bottlenecked by 3840x2160 copyback performance.

For example:

Ducks-2160p@50fps-4Mbps
LAV x64 DXVA Native (Null) 193/197/198
LAV x64 CUVID (Null) 73/78/78
LAV x64 DXVA Copyback (Null) 69/73/73

Fitness-2160p@30fps-8Mbps
LAV x64 DXVA Native (Null) 100/113/146
LAV x64 CUVID (Null) 50/57/70
LAV x64 DXVA Copyback (Null) 49/55/66

Beauty-2160p@30fps-12.3Mbps
LAV x64 DXVA Native (Null) 78/86/87
LAV x64 CUVID (Null) 43/51/55
LAV x64 DXVA Copyback (Null) 41/48/50

[NikosD]

Nice!

I didn't know.

So I have much work to do tomorrow if I want to test every possible decoder for 740M.

Hopefully I will see HEVC DXVA2 for 740M.

Yes your CPU is Ivy so your card is HD 4000, not 4600.

I thought that CUVID due to 3D clocks and zero memory performance penalty would be about equal to DXVA2 native.

Thanks for the info!

[huhn]

CUVID and DXVA2 use the same decoder so CUVID is like DXVA2 copyback at least with new cards.
currently i don't see any benefit with using CUVID over DXVA2 copyback or native

[nevcairiel]

I think I mostly tested performance with Copy-Back, so that may explain it, but I'm surprised its such a massive difference, wonder if I can tune something there..
On H.264 for example, the difference was always minimal, but i guess that was 1080p and not 2160p.

[NikosD]

CUVID and DXVA2 use the same decoder so CUVID is like DXVA2 copyback at least with new cards.
currently i don't see any benefit with using CUVID over DXVA2 copyback or native

From the words of nevcairiel, I was under the impression that Nvidia's hybrid HEVC decoder was a CUVID only feature, like MPEG4-ASP

[nevcairiel]

Who ever said MPEG4-ASP is a CUVID only feature? Its just that noone ever bothered to implement it in DXVA2, because its quite a bit of work for practically no return value. :)
With CUVID, it just comes for free, since its all handled in the driver, not much code needed at all.

HEVC is obviously implemented in DXVA2, and as such it also works on NVIDIA of course, and not only through CUVID.

[NikosD]

OK I'll test it and I'll post the results.

[sheppaul]

There is a MPEG4-ASP DxVA decoder in potplayer though.

I believed the code was from lav.

[huhn]

There is a MPEG4-ASP DxVA decoder in potplayer though.

I believed the code was from lav.

why do you think so there is no DXVA decoder for ASP in lavfilter only CUVID.

[edison]

The x64 LAV video does good job here, but there is another problem, we still have not a mature replay suit. for example: there is not a x64 DTS-HD software audio decoder so far.
So, we still need to wait for a real HW decoder which support 4K 60p(at least) HEVC( GM1XX does not have a full HW HEVC decoder, but GM2XX does).

[huhn]

The x64 LAV video does good job here, but there is another problem, we still have not a mature replay suit. for example: there is not a x64 DTS-HD software audio decoder so far.
So, we still need to wait for a real HW decoder which support 4K 60p(at least) HEVC( GM1XX does not have a full HW HEVC decoder, but GM2XX does).

the new nvidia 980/970 didn't have a full HW decoder for HEVC they only have a HW HEVC encoder nvenc used for shadow play of cause they don't use HEVC encoding at the current version but the card can do it.

you can read about this here.

http://www.anandtech.com/show/8526/nvidia-geforce-gtx-980-review/5

[sheppaul]

why do you think so there is no DXVA decoder for ASP in lavfilter only CUVID.

There is a checkbox for that though it is disabled by default.

I didn't know that it is not implemented.

BTW, the hybrid hevc decoder is pretty disappointing. Is there any room to improve?

[videoh]

BTW, the hybrid hevc decoder is pretty disappointing. In what way do you find it to be disappointing?

[NikosD]

BTW, the hybrid hevc decoder is pretty disappointing. Is there any room to improve?

From the results of cyberbeing using Nvidia 770, the hybrid decoder using DXVAn can be a lot faster than CPU decoder on my CPU Core i7-4790 and 2160p clips.

Look at the Ducks sample.
It's more than two times faster.

[NikosD]

Using a laptop with Nvidia's Optimus technology proved a difficult task for video decoding benchmarking.

First of all, I didn't find a way to disable it in BIOS, so I had to live with it.

Using initially Intel's HD 4600 iGPU inside the Core i5-4200M, I saw that even when DXVA native was used during video decoding, the HD 4600 never reached max clocks with maximum utilization.

The clocks were most of the time at 850MHz@100% usage for 1080p and 2160p clips with a max clock of 1150MHz.

Also, the CPU utilization was too high for DXVA native mode, ~40% for 1080p clips and 33% - 57% for 2160p and the CPU clock went to max 2.5GHz a lot of times during benchmarking.

It looks like a system with an iGPU and a discrete Nvidia card on the same system using Optimus technology, can't utilize perfectly DXVA native mode for both GPUs.

Of course DXVA copy-back was even slower.

From the Control Panel I chose max performance for iGPU.
Also I tried using the laptop in battery and plugged-in.

Nothing changed.



But with Nvidia's 740M GPU the problems were a lot bigger.

Starting with 340.52 driver, the clocks went high at 980MHz (max 1060MHz) but with low GPU utilization.
Then the video dropped to 0fps and stopped working.

Unfortunately that happened with almost all clips I tried and all modes (DXVA copy-back, NVCUVID)

I tried both LAV x86 and x64 with no success.

I did an update to the latest driver 344.11, but still had issues.

The GPU clocks went further down to 140MHz - 230MHz (!) with very little GPU usage, but at least most of the clips were fully decoded without sudden stops, but not all the clips I tried.
Some, still have incompatibilities.

So, there are still compatibility problems with 740M even with latest drivers and LAV nightly 0.62.46

The results were extremely low for the clips that decoded fine and some didn't reach the end, so I decided to not include any results.

I don't know if it's Optimus technology problem or driver or LAV Video.

I will try again after a while, to see if anything has changed.

[huhn]

the max gpu clock is heat controlled for both nvidia and intel.

and this is a laptop they are not know for efficient heat management.

[NikosD]

the max gpu clock is heat controlled for both nvidia and intel.

and this is a laptop they are not know for efficient heat management.

I was way below the heat throttling of both GPUs.

Especially for Nvidia, the issue is certainly not there.


i5-3570K @4.4Ghz, 16GB DDR3 1866Mhz 8-9-9-24
NVIDIA GTX 770 2GB, PCI-E 3.0 x8
Win7 SP1 x64
LAV Filters git-33f0b3 (2014-09-21)
DXVA Checker 3.1.2



OK you have a:
Core i5-3570K @4.4Ghz (Ivy) 4cores/4threads (No HT) - Win7 SP1 x64 - 16GB - DDR3 1866MHz CL9 - LAV Filters git-33f0b3 (2014-09-21) - DXVA Checker 3.1.2

I have a:
Core i7-4790@3.8GHz (Haswell) 4cores/8threads (HT On) - Win 8.1 Pro x64 - 8GB - DDR3 1600MHz CL9 - LAV filters git 52 (25-09-2014) - DXVA Checker 3.1.2 (DXVA Decoding)

Your processor has 16% higher frequency, but it's only 4 threads vs 8 threads and it's older architecture (Ivy vs Haswell)


Results:


1.Beauty-2160p@30fps-12.3Mbps


LAV x64 i5-3570K 97/107/111 CPU Utilization: 95% (Threads=12) (Windows 7) (4.4GHz)

LAV x64 i5-3570K 89/103/109 CPU Utilization: 91% (Threads=12) (Windows 8.1) (4.4GHz)

LAV x64 i7-3770K 85/101/105 CPU Utilization: 79% (Threads=16) (HT on) (Windows 7) (4.0GHz)

LAV x64 i7-4790 82/95/99 CPU Utilisation: 78% (Threads=16) (HT on) (Windows 8.1) (3.8GHz)

LAV x64 i7-3770K 88/93/100 CPU Utilization: 95% (Threads=16) (HT off) (Windows 7) (4.0GHz)

LAV x64 i7-3770K 80/93/99 CPU Utilization: 70% (Thread=Auto) (HT on) (Windows 7) (4.0GHz)

LAV x64 i7-3770K 77/92/97 CPU Utilization: 94% (Threads=12) (HT off) (Windows 7) (4.0GHz)

LAV x64 i7-4790 78/90/95 CPU Utilisation: 73% (Threads=Auto) (HT on) (Windows 8.1) (3.8GHz)

LAV x64 i5-3570K 76/82/86 CPU Utilization: 72% (Threads=Auto) (Windows 7) (4.4GHz)

LAV x64 i7-4790 69/81/87 CPU Utilisation: 90% (Threads=16) (HT off) (Windows 8.1) (3.8GHz)

LAV x64 i7-4790 69/81/85 CPU Utilisation: 90% (Threads=12) (HT off) (Windows 8.1) (3.8GHz)

LAV x64 i7-3770K 61/71/76 CPU Utilization: 71% (Threads=Auto) (HT off) (Windows 7) (4.0GHz)

LAV x64 i7-4790 61/68/72 CPU Utilisation: 90% (Threads=Auto) (HT off) (Windows 8.1) (3.8GHz)





2.Fitness-2160p@30fps-8Mbps

LAV x64 i5-3570K (Null) 109/132/142 Threads=12
LAV x64 i7-4790 (Null) 99/120/148 CPU Utilisation: 92% Threads=16
LAV x64 i7-4790 (Null) 97/113/136 CPU Utilisation: 85% Threads=Auto



3.Ducks-2160p@50fps-4Mbps

LAV x64 i5-3570K (Null) 128/140/144 Threads=12
LAV x64 i7-4790 (Null) 109/122/127 CPU Utilisation: 92% Threads=16
LAV x64 i7-4790 (Null) 110/120/122 CPU Utilisation: 91% Threads=Auto



Astra-UHD@50fps-18Mbps (10bit)


LAV x64 i5-3570K 71/86/108 CPU Utilization: 94% (Threads=12) (Windows 7) (4.4GHz)

LAV x64 i5-3570K 76/82/86 CPU Utilization: 72% (Threads=Auto) (Windows 7) (4.4GHz)

LAV x64 i5-3570K 73/81/86 CPU Utilization: 69% (Threads=Auto) (Windows 8.1) (4.4GHz)

LAV x64 i7-4790 61/72/85 CPU Utilisation: 80% (Threads=16) (HT on) (Windows 8.1) (3.8GHz)

LAV x64 i7-4790 59/69/81 CPU Utilisation: 76% (Threads=Auto) (HT on) (Windows 8.1) (3.8GHz)

LAV x64 i5-3570K 55/69/95 CPU Utilization: 75% (Threads=Auto) (Windows 7) (4.4GHz)

LAV x64 i7-4790 51/64/77 CPU Utilisation: 93% (Threads=12) (HT off) (Windows 8.1) (3.8GHz)

LAV x64 i7-4790 47/63/77 CPU Utilisation: 92% (Threads=16) (HT off) (Windows 8.1) (3.8GHz)

LAV x64 i7-4790 47/55/76 CPU Utilisation: 79% (Threads=Auto) (HT off) (Windows 8.1) (3.8GHz)



UHD_ENT_Transformer_Quad@24fps-51Mbps (10bit)

LAV x64 i5-3570K(Null-P010) 45/59/102
LAV x64 i7-4790 (Null) 45/58/85 CPU Utilisation: 96% Threads=16
LAV x64 i7-4790 (Null-P010) 45/57/80 CPU Utilisation: 94% Threads=Auto


Can you explain me at least the last result, a Core i7-4790 with a CPU utilization of 96% (full 8 threads decoding) to have less decoding performance than a Core i5-3570K with 15% higher frequency.

I find it unbelievable.

I used DXVA Checker's v3.1.2 DXVA decoding choice for Null renderer and latest (today's) LAV filters 0.62.52

Can you try that tool with that filters version to check the performance reporting CPU utilization too?

Thanks!

[cyberbeing]

All my previous results were with LAV Video set to Threads=12, since as you also noticed, CPU utilization and resulting performance is lower than expected on some HEVC samples with LAV set to Threads=Auto. I'd assume this is the discrepancy you are seeing.

[NikosD]

All my previous results were with LAV Video set to Threads=12, since as you also noticed, CPU utilization and resulting performance is lower than expected on some HEVC samples with LAV set to Threads=Auto. I'd assume this is the discrepancy you are seeing.

OK.

I tried first putting Threads=12, but it was equal or a little slower than Auto for my CPU.

So I went all the way up to Threads=16.

I edited my previous post to show the results of Threads=16

There is an increase, but still I can't reach you.

I still find it extremely weird.

Do you have a secret ? ;)

Did you use GraphStudioNext for benchmarking Null renderer ? :p

I can't figure it out, unless it's the different LAV filters version.

I can't think of anything else.

[cyberbeing]

I'm not doing anything special:
DXVAChecker 3.1.2 -> Decoder tab -> Drag/Drop Video -> Click Arrow -> Benchmark -> DXVA decoding

Threading differences between Win7 & Win8, HT vs no-HT, architecture jumps not always being superior in all metrics, and that Intel CPUs sometimes unbottleneck themselves when overclocked could all be possible explanations. Also since you have a laptop, it's possible your CPU is power/thermal throttling and not using maximum TurboBoost when benchmarking. If you download RealTemp TI (http://forum.techinferno.com/downloads.php?do=file&id=43), it should show you the actual clock speed at any given time.


It looks like LAV HEVC threading problem I was referring to only occurs on the following two samples:

3570K@4.4Ghz
LAV Filters git-1d591 (Betaking build)

1.Beauty-2160p@30fps-12.3Mbps

LAV x64 i5-3570K 97/107/111 CPU Utilization: 95% (Threads=12)
LAV x64 i5-3570K 76/82/86 CPU Utilization: 72% (Threads=Auto)


Astra-UHD@50fps-18Mbps (10bit)

LAV x64 i5-3570K 71/86/108 CPU Utilization: 94% (Threads=12)
LAV x64 i5-3570K 55/69/95 CPU Utilization: 75% (Threads=Auto)

The other samples had good utilization (>92%) with Threads=Auto, and only ~1% lower performance vs Threads=12. Not so for the two samples above.

[huhn]

@cyberbeing
he uses processing with 1280x720.

my i7 3770k 4.0 ghz

get's this with 62.52 and processing 1280x720

Beauty-2160p@30fps

12 threads CPU 64 83 90 / 60 % cpu usage

[cyberbeing]

@cyberbeing
he uses processing with 1280x720.

Above (http://forum.doom9.org/showpost.php?p=1695007&postcount=34) NikosD was testing Null, which implies no scaling.

My results (http://forum.doom9.org/showpost.php?p=1694854&postcount=13) using 'DXVA Processing' and 1280x720 scaling with actual renderer output, explicitly state so. There is not much difference in performance either way.

Since you both have CPUs with Hyperthreading, try disabling HT and see if your results improve. And you huhn, since you have a 3770k, could try matching my 4.4Ghz overclock. If you are only seeing 60% CPU Utilization on your 3770K that is extremely strange...were you also using Win8 and not Win7 like I am? I'll try booting into Win8.1 later and see if there is any difference.

Also, the LAV Filters nightly builds I've been using for testing are those from Betaking: here (http://pan.baidu.com/s/1gd1its3#dir/path=%2F%E8%87%AA%E7%BC%96%E8%AF%91%E8%BD%AF%E4%BB%B6). Which builds have you guys been using?

Edit (Win7 vs Win8.1 Threading):
Windows 8.1 does seem to have marginally lower CPU Utilization and benchmark performance compared to Windows 7, but not significant enough to explain what NikosD or huhn are seeing.

1.Beauty-2160p@30fps-12.3Mbps
LAV x64 i5-3570K 97/107/111 CPU Utilization: 95% (Threads=12) (Windows 7)
LAV x64 i5-3570K 89/103/109 CPU Utilization: 91% (Threads=12) (Windows 8.1)

LAV x64 i5-3570K 76/82/86 CPU Utilization: 72% (Threads=Auto) (Windows 7)
LAV x64 i5-3570K 73/81/86 CPU Utilization: 69% (Threads=Auto) (Windows 8.1)

Edit2 (Betaking 2014-09-25 vs K-Lite 10.76 LAV nightly build):
No difference in performance.

[huhn]

i used windows 7.

lavfilter is 0.62.0.52 i took it from KLCP

4.4 GHz results in a blue screen after reboot. my 3770k has pretty bad quality silicon so i stay at 4.0.
my RAM was at 1333 for some reasons it now at normal 1600.
the system wasn't rebooted for some time looks a lot better with 1600 and rebooted system:

Beauty_3840x2160_120fps_420_8bit_HEVC_MP4

80 93 99 / 70% threads auto (should be 12 with 8 thread system)
85 101 105 / 79% threads 16

i'm pretty sure an i7 will look pretty good with 24-32 threads.

all used Null rendering

edit:
non HT

61 71 76 / 71% threads auto (should be 6)
77 92 97 / 94% threads 12
88 93 100 / 95% threads 16


looks like using 3 times the number of threads the CPU got helps for HEVC decoding.

12 thread with core 4 cpu and 12 threads with 4 core cpu with HT threads have about the same speed the min FPS is a lot higher with HT.
at 16 threads it looks like HT give a decent speed boost where non HT has no real difference except min fps.
i guess HT does a good job with a lot of threads too but this will take "a lot" of RAM. i guess even with 32 threads this shouldn't be a real problem for people with 8 thread CPUs.

[nevcairiel]

Some clips are just not encoded in a way that would be beneficial to multi-threading, and while you can try throwing more and more threads at it to try to improve the CPU utilization, its usually a bad solution.
For such clips it may be useful to combine both frame and slice multi-threading, so that big I frames can use slice threading (or wpp) to speed up their decoding, since everything hinges on them being ready as a reference for the others. I've seen preliminary patches for this, but its never been finished.

[huhn]

so on a file with only 1 I frame and a length of over 2000 frame this should be meaningless because only the first frame would benefit from throwing threads against it?

number with a i3 4130 at 3.4 ghz
37 48 54 / 75% threads auto (6)
38 55 62 / 95% threads 12

[nevcairiel]

other frames with a lot of complexity can also benefit, generally such bottlenecks start because its waiting for a reference frame, although a 2000 frame GOP is already a terribly encoded video.
Usually I frames are the most complex, since they are an order of magnitude bigger than any other frames.

[NikosD]

Astra-UHD@50fps-18Mbps (10bit)

LAV x64 i5-3570K 71/86/108 CPU Utilization: 94% (Threads=12)
LAV x64 i5-3570K 55/69/95 CPU Utilization: 75% (Threads=Auto)



LAV x64 i5-3570K 76/82/86 CPU Utilization: 72% (Threads=Auto) (Windows 7)
LAV x64 i5-3570K 73/81/86 CPU Utilization: 69% (Threads=Auto) (Windows 8.1)



The results for ASTRA clip in those two posts (one after the other), do not interpret.

[NikosD]

Also since you have a laptop, it's possible your CPU is power/thermal throttling and not using maximum TurboBoost when benchmarking. If you download RealTemp TI (http://forum.techinferno.com/downloads.php?do=file&id=43), it should show you the actual clock speed at any given time.


My Core i7-4790 results are from a desktop system.
I think there is no laptop with such a hot (!) CPU.
They all use the M or U branches.

The results of Core i5-4200M are from laptop.

I use CoreTemp for real turbo boosted frequencies and it's 3.8GHz all the time during benchmarking.


It looks like LAV HEVC threading problem I was referring to only occurs on the following two samples:

3570K@4.4Ghz
LAV Filters git-1d591 (Betaking build)

1.Beauty-2160p@30fps-12.3Mbps

LAV x64 i5-3570K 97/107/111 CPU Utilization: 95% (Threads=12)
LAV x64 i5-3570K 76/82/86 CPU Utilization: 72% (Threads=Auto)


Astra-UHD@50fps-18Mbps (10bit)

LAV x64 i5-3570K 71/86/108 CPU Utilization: 94% (Threads=12)
LAV x64 i5-3570K 55/69/95 CPU Utilization: 75% (Threads=Auto)

The other samples had good utilization (>92%) with Threads=Auto, and only ~1% lower performance vs Threads=12. Not so for the two samples above.

Exactly.
My tests show exactly this behavior, so the explanation of performance difference, still remains for the other clips which don't have benefits by raising the number of threads.

Update:

Looking more carefully the "refreshed" results of huhn using a tad faster 4.0GHz CPU, I think that Win 7 could probably matters most for the performance difference.


Since you both have CPUs with Hyperthreading, try disabling HT and see if your results improve.


I did that too and posted the results in the above post, along with yours results (yours and huhn).

The results with HT off are worse than HT on for me and huhn.


looks like using 3 times the number of threads the CPU got helps for HEVC decoding.

12 thread with core 4 cpu and 12 threads with 4 core cpu with HT threads have about the same speed the min FPS is a lot higher with HT.
at 16 threads it looks like HT give a decent speed boost where non HT has no real difference except min fps.
i guess HT does a good job with a lot of threads too but this will take "a lot" of RAM. i guess even with 32 threads this shouldn't be a real problem for people with 8 thread CPUs.

For me, using HT off and Threads=16 had the same or a little worse results than using Threads=12.

But with HT on, the results of Threads=16 are the best.

Look at the post above with all the results (cyber, me, you)

[NikosD]

Playing around with the number of threads of LAV video I had the chance to answer another question I had regarding hyperthreading and explains the results of cyber, me and huhn.

I finally got the answer I was looking for!

If you have a non hyperthreaded CPU, but you have the ability to change the number of threads of a real parallel process like video decoding, what would be the difference/ benefit of the exact same CPU, with all other parameters equal but Hyperthreading ON ?

The answer came by testing my Core i7-4790 and the other 2160p videos than the ones tested above (beauty and astra)

So, for the 2160p clips 2. and 3. the advantage is 11% - 18%.
It's a clear advantage, but not huge.

It was the transformers clip with the huge bandwidth and a CPU utilization of nearly 100% for (HT on) and (HT off) that gave an advantage to the HT CPU of 27% using 12 threads for both of them.

And this explains how a HT 3.8GHz CPU has the same performance with a non HT 4.4GHz CPU on the transformers clip, using - the HT CPU - a slower OS (Win 8.1) for that task.

On the other hand, for more "serialized" video decoding processes or other similar processes, using a higher clock and a large number of threads, is faster than using a HT CPU with a lower clock.

[NikosD]

i5-3570K @4.4Ghz, 16GB DDR3 1866Mhz 8-9-9-24

UHD_ENT_Transformer_Quad@24fps-51Mbps (10bit)
http://demo-uhd3d.com/files/uhd/Transformers_extinction_Trailer_4K.zip

LAV x64 CPU (Null-P010) 45/59/102
LAV x64 CPU (1280x720 scale-NV12) 45/59/102

LAV x86 CPU (Null-P010) 25/39/86


I used latest nightly MPC-HC x64 v1.7.6.253 using SW decoding with EVR and EVR-CP renderes and while it gives me 0frames dropped and a CPU utilization of 20% - 35%, I see clearly occasional stuttering in movement.

Using your overclocked CPU, are you able to decode this clip in normal/realtime playback using MPC-HC in SW mode, without any "stuttering" or any "glitch" in the movement during the decoding of the video ?

I think it should be the encoding/ muxing of the video and probably the frame-rate which looks like variable although it shouldn't.
It's supposed to be a 23.976fps clips.

I can't see how could this be a decoding performance issue.

Update:

I used DXVA Checker as a player (in play mode) using LAV x64 CPU 0.62.57 and I got:

Frame rate: 18/22/24
CPU utilization %: 18/28/38

[cyberbeing]

You're correct, that sample does seem to have a massive stutter every 2 seconds during playback.

[NikosD]

I think all of them, from that site I posted in a previous post.

I downloaded 6 of them and all of them had the same problem, so I stopped downloading more.

[cyberbeing]

It seems like it could be a problem with FFMPEG, since interestingly enough the NVIDIA Hybrid CUVID decoder (older LAV 2014-09-21 build where 10bit fallback was broken) does not stutter at all even though sections making heavy use of the 10bit color range are very corrupt. Since it would seem those samples are supposedly Samsung showroom demos used to show off the capabilities for the HEVC hardware decoders on Samsung UHD TVs, it would seem rather doubtful that they wouldn't catch playback issues such as this.

[nevcairiel]

It seems like there is a timestamp gap in there whenever that happens. I don't know if its maybe eating a frame or two for some reason, but whenever it stutters the timestamp jumps for 3 frames (125ms) instead of the usual 41.7ms per frame.
Can't tell for sure yet if those frames are missing, or they are not being output for $reasons.

Edit:
Seems like its eating the frames inside the decoder somehow.