View Full Version : Evaluation of HEVC decoders (SW, Hybrid and HW)
huhn
30th January 2015, 02:08
to display 10 bit videos in 10 bit you need a directx 10+ fullscreen surface too a lot needs to be changed.
mhourousha
30th January 2015, 03:25
So, it seems that DXVA2 Native and 10bit HEVC decoding are incompatible.
What about EVR-CP ?
Any difference ?
Could Intel or AMD do any tricks with the driver, in order for DXVA2 Native and 10bit to be compatible ?
GPU can't handle any YUV420 format(NV12 P010 P016 etc) directly before D3D11.1.
therefore if you want avoid cpu copy-back,you need convert YUV 420 to RGB(StretchRect or VideoProcessBlt)in DXVA pass, in render pass,convert it back to YUV420,apply some upsample and color-space mapping algorithm,or use the RGB surface directly.
the problem is most GPU can't do P010/P016->RGB conversion under D3D9EX,so if decoder output P010/P016 surface,then can't convert it to D3D compatible format with GPU.
D3D11.1 can read YUV420 format directly(mapping to 2 SRV one for Y and the other for UV)。so it no need to do the YUV->RGB conversion in DXVA pass。but it need a DX11 Decoder(Decoder use DX11 device instead of D3D9Ex)。D3D9Ex Device can't share YUV420 DXVA Surface to DXGI_FORMAT_NV12 or DXGI_FORMAT_P010/DXGI_FORMAT_P016
NikosD
30th January 2015, 06:57
Microsoft's MFT decoders are all D3D11, but I think LAV Video is D3D9.
nevcairiel
30th January 2015, 10:29
DirectShow EVR is D3D9 only, it doesn't offer a D3D11 interface to DXVA2. No experience with MediaFoundation to say if thats any different.
Its possible that MF EVR is a lot better and supports all we need already, but other than Windows Media Player, nothing uses MF.
Microsoft is unfortunately not going to care about DirectShow in Windows 10 anymore, they haven't really cared about it for a long time now.
huhn
30th January 2015, 18:53
i guess they want to "force" developer to switch to MF.
at least they start to add some small reasons to do this.
cyberbeing
1st February 2015, 09:25
On my GTX 770 (PCI-E 3.0 x8) & i5-3570K @4.4Ghz, the new LAV dxva2cb-Direct mode only has a minor performance benefit with the 4K HEVC hybrid decoder, but it does reduce CPU usage somewhat. dxva2native continues to be much faster with the HEVC 4K hybrid decoder on this GPU.
3.Ducks-2160p@50fps-4Mbps
DXVAChecker x64 - Playback Benchmark (scaled to 1280x720)
DXVA2 Native: 187.350 fps | CPU Usage 28% | GPU Load ~93%
DXVA2 Copyback: 66.561 fps | CPU Usage 21% | GPU Load ~52%
DXVA2 Copyback Direct: 73.253 fps | CPU Usage 15% | GPU Load ~52%
nevcairiel
1st February 2015, 11:06
The hybrid decoder is CPU bound, which is why it behaves quite differently. Additionally, it probably has to upload a lot more data to the GPU itself, which I then download again, and upload again, which would explain how its generally not ideal for a CB workflow.
On H.264, or using my 960 with HEVC/HEVC 10, the speed difference is practically non-existent with minimal CPU usage (< 2%, down from 5-6%) now.
This mode does allow however using CB for HEVC 4K Main10 files on the 960 without any significant performance impact, while DXVA2-Native for 10-bit just doesn't work with the software we have.
cyberbeing
1st February 2015, 12:23
I figured as much, which is why I've always seen the hybrid decoder as nothing more than a crutch. If copyback-direct greatly improves performance using the modern ASIC decoder on your GTX 960, that's all that really matters to me. What sort of decoding performance discrepancy were you seeing between 'normal dxva2 copyback' and 'dxva native' on your GTX 960 prior to these changes?
The ASIC decoder on this GTX 770 seems too slow to bottleneck copyback on high-bitrate 4K H264. Testing a 100Mbps clip, the biggest difference was lower CPU usage:
DXVAChecker x64 - Playback Benchmark (scaled to 1280x720)
37.342fps | 0% CPU (Native)
37.206fps | 3% CPU (Copyback-Direct)
37.198fps | 5% CPU (Copyback)
On something like 10Mbps 1080p H264 baseline clip used by WinSAT, again it mainly saved CPU time:
DXVAChecker x64 - Playback Benchmark (scaled to 1280x720)
175.522 fps | 0% CPU (Native)
166.549 fps | 5% CPU (Copyback-Direct)
163.770 fps | 8% CPU (Copyback)
That said, I can't complain about lower CPU usage with slightly higher performance even if DXVA2 Native retains an edge. :)
NikosD
2nd February 2015, 06:26
The hybrid decoder is CPU bound, which is why it behaves quite differently.
Using a Core i7-4790 with an iGPU HD 4600, it's definitely GPU bound.
This mode does allow however using CB for HEVC 4K Main10 files on the 960 without any significant performance impact, while DXVA2-Native for 10-bit just doesn't work with the software we have.
Can you post some figures in Playback Performance mode for 10bit 4K HEVC in DXVA Copy-Back ?
For example the ASTRA clip or any other demanding clip which mimics UHD Bluray.
nevcairiel
2nd February 2015, 16:02
On the Astra clip, using DXVA2 Copy-Back in direct mode. In the meantime I implemented Direct Mode for P010 out, and a direct mode for P010 decode -> NV12 out (for renderers that don't do 10-bit)
Decode, Direct P010 Out: 127 fps, 3% CPU
Playback (1280x720), Direct P010 Out: --- EVR doesn't do P010 out.
Decode, Direct NV12 Out: 126 fps, 3% CPU
Playback (1280x720), Direct NV12 Out: 116 fps, 6% CPU
And for giggles without the new Direct Mode:
Decode, No Direct P010 Out: 73 fps, 6% CPU
A significant performance loss due to the extra copying being done right there.
NikosD
2nd February 2015, 16:30
So, it's a 4K 120fps decoder even for 10bit in DXVA-CBD.
Impressive.
Does the HW decoder stutter in those Samsung 4K 10bit HEVC files like ffmpeg SW decoder ?
nevcairiel
2nd February 2015, 17:09
That stuttering thing should have been fixed a long time ago already.
At least the "UHD_ENT_Transformer_Quad.ts" that I have, which is a Samsung 10-bit clip, plays perfectly in direct mode (or in SW mode for that matter).
NikosD
2nd February 2015, 20:01
Well, I had tried your fix which worked fine, but you told me that it wasn't an official fix, but rather a "fix", like a workaround.
Back then, FFMpeg developers hadn't included it in their updates.
I don't know if recent FFMpeg updates include your "fix" or an official fix :)
But, yes it works.
prxy99999
3rd February 2015, 01:30
I've been evaluating hevc decoders for 1080p playback on older hardware like core2duos and core2quads. I've found the lav filters (both 32 and 64bit) indistinguishable visually on playback on the core2quads from a decoder like strongene. In the case of the core2duos however when it comes to a scene where the camera pans across from side to side or up and down, especially if there is a lot of action in the scene than I do get lots of stutter and delay with lav but the strongene decoder plays them smoothly.
According to the strongene webpage and manual the decoder is free for personal use. But I'm finding on all systems that as soon as any clip hits the 22-23 min mark the picture will freeze and remain static while audio continues. If I stop the clip and seek to just before it freezes and continue playback it continues on for another 22-23mins. I've tried searching the web and emailing them but haven't had a reply. So was wondering if anyone else knows whether the strongene decoder is free to use but "time limited" for playback.
The version of the strongene CPU decoder i'm using is the one currently available for download on the website:
Strongene H.265/HEVC Decoder for Windows
Version:2.0.2.6 Release: 2014/06/10
Neet009
3rd February 2015, 05:10
CPU:core2quad Q9550
GPU:GTX 960 (driver 347.25)
OS:win7 x64
I tried LAVFilters-0.63.0.74-git, it seems DXVA2 Copy-Back direct mode doesn't work with 10bit HEVC clips, and return to use SW decode. I tested ASTRA clips and Samsung 4K 10bit HEVC clips with EVR and madVR, all of them doing the same result.
http://i.imgur.com/OXL7RYq.png
However, when playing 8bit HEVC clips, DXVA2 Copy-Back direct mode works normally as expected.
http://i.imgur.com/w1QccVo.png
Use DXVAchecker to check 10bit HEVC clips, it show this:
http://i.imgur.com/5GL6wsV.png
http://i.imgur.com/Yo747cM.png
http://i.imgur.com/athd4N5.png
8bit HEVC clips:
http://i.imgur.com/0mii44h.png
http://i.imgur.com/meTRPIv.png
Did l do something wrong?:confused:
nevcairiel
3rd February 2015, 10:02
10-bit is not supported yet in the nightly builds.
Neet009
3rd February 2015, 10:17
10-bit is not supported yet in the nightly builds.
I got it. Thank you for reply.
NikosD
3rd February 2015, 12:42
According to the strongene webpage and manual the decoder is free for personal use. But I'm finding on all systems that as soon as any clip hits the 22-23 min mark the picture will freeze and remain static while audio continues. If I stop the clip and seek to just before it freezes and continue playback it continues on for another 22-23mins. I've tried searching the web and emailing them but haven't had a reply. So was wondering if anyone else knows whether the strongene decoder is free to use but "time limited" for playback.
The version of the strongene CPU decoder i'm using is the one currently available for download on the website:
Strongene H.265/HEVC Decoder for Windows
Version:2.0.2.6 Release: 2014/06/10
Using the same latest version of Strongene HEVC decoder and DXVA Checker as media player, I had no problem of decoding a HEVC movie up to 40min and then I stopped.
So, it looks like a problem in your system/media player rather than the Strongene decoder.
NikosD
3rd February 2015, 13:18
On the Astra clip, using DXVA2 Copy-Back in direct mode.
Could you test this small (92MB) and short (25s) clip with your 960 DXVA-CBD decoder ?
http://www.filedropper.com/hotbird4kdemo
It's a 10bit 2160p50fps HEVC clip with 30Mbps bitrate that I can't play in realtime even with plain EVR and latest LAV x64 nightly version.
v0lt
4th February 2015, 04:36
On the Astra clip, using DXVA2 Copy-Back in direct mode. In the meantime I implemented Direct Mode for P010 out, and a direct mode for P010 decode -> NV12 out (for renderers that don't do 10-bit)
It is possible to convert to YUY2 or directly into RGB32?
nevcairiel
4th February 2015, 10:44
It is possible to convert to YUY2 or directly into RGB32?
No, that would defeat the primary purpose of direct mode (speed), since those conversions are very slow.
It also wouldn't be very direct anymore. :)
Especially with 4K content, and even more so 10-bit, its crucial that we don't need or want to perform software processing on the video, because its going to be super slow.
Any processing should be done on the GPU, so direct mode will not offer any conversions that are not absolutely required to get the image to the GPU. In short, this is NV12 -> NV12 out, P010 -> P010 out, and as one special case, P010 -> NV12 out, since not every renderer accepts 10-bit (and this kind of conversion is very fast)
I may add NV12/P010 -> YV12 as well because its a rather simple conversion, but I have not decided yet if its really all that useful. Anything that would benefit from it already adds a high overhead, so its kind of meh.
nevcairiel
4th February 2015, 12:13
Could you test this small (92MB) and short (25s) clip with your 960 DXVA-CBD decoder ?
http://www.filedropper.com/hotbird4kdemo
It's a 10bit 2160p50fps HEVC clip with 30Mbps bitrate that I can't play in realtime even with plain EVR and latest LAV x64 nightly version.
Decode to P010, 120 fps (116-125)
Decode to NV12, 117 fps (105-121)
Playback in NV12, 1280x720, 107 fps (66-113)
All tests in direct mode of course.
NikosD
4th February 2015, 14:06
Decode to P010, 120 fps (116-125)
Decode to NV12, 117 fps (105-121)
Playback in NV12, 1280x720, 107 fps (66-113)
All tests in direct mode of course.
Thanks for testing.
I have a few more general questions.
For most of us with 8bit displays (TV screens, PC monitors), what's the difference of a 10bit vs 8bit clip in terms of picture quality.
Can we actually see any difference on our displays due to 10bit encoding ?
What's the pipeline of 10bit decoding and displaying a 10bit clip on a 8bit monitor and which component does the conversion from 10bit to 8bit and how ?
The decoder, renderer, GPU driver ?
Are there many ways for 10bit to 8bit conversion ?
clsid
4th February 2015, 16:24
The primary benefit of 10bit is that the encoder can work with a higher precision. This results in better compression and/or better quality. So 10bit encodes can actually be smaller than 8bit ones, and it also benefits quality, particularly giving less banding. These benefits are there regardless of whether you end up decoding to 8bit or not! The potential larger range of colors that is available if outputting 10bit is much much much less important.
So yes, 10bit has benefits, even for 8bit displays. In fact, some displays even use less than 8bits internally.
Most video renderers only support 8bit input. In that case the conversion is done by LAV Video decoder. It uses high quality conversion, with dithering.
MadVR is the only DirectShow renderer that supports 10bit input. In that case, conversion is done by MadVR. Again, high quality with dithering.
NikosD
4th February 2015, 17:26
Thanks for the prompt and detailed reply.
Neet009
10th February 2015, 16:41
CPU:core2quad Q9550
GPU:GTX 960 (driver 347.25)
OS:win7 x64
I did some test with LAV 0.63.0.75-git:
Astra clips(4K 10bit HEVC), Copy-Back direct mode
DXVAChecker x64, decode, P010 out
76~78 fps , 15% CPU
DXVAChecker x64, decode, NV12 out
92~93 fps, 14% CPU
DXVAChecker x86, decode, P010 out
67~69 fps, 15% CPU
DXVAChecker x86, decode, NV12 out
86~88 fps, 14% CPU
Ducks-2160p@50fps-4Mbps, Copy-Back direct mode
DXVAChecker x64, decode
152~154 fps, 15% CPU
DXVAChecker x86, decode
153~154 fps, 16% CPU
It seems the 10bit results are slower than Nevcairiel's test. What reason is likely to make a difference? Is my cpu too old or lack of some instruction sets?
cyberbeing
10th February 2015, 17:49
It seems the 10bit results are slower than Nevcairiel's test. What reason is likely to make a difference? Is my cpu too old or lack of some instruction sets?
Assuming nevcairiel's i7-4770K results still hold true, it's probably both your CPU & Memory subsystem being too slow, especially if you see a similar performance difference with P010 vs NV12 output when using software decoding of 10bit H264 video. P010 output requires transferring 16bit (padded) data, while NV12 is only 8bit data. Use of P010 output doubles the bandwidth requirements, the amount of data being transferred across system memory, and to/from your GPU over PCI-E. It's not abnormal for the overhead of outputting P010 directly to be larger than the CPU overhead of converting to NV12, especially on an older system.
nevcairiel
10th February 2015, 22:44
Note that I'm on a i7-5930K now with DDR4 memory, so my memory performance is quite good, and core 2 is quite old, the memory may be much more of a bottleneck there than on newer CPUs.
Interesting is the difference between NV12 and P010. LAV has to read the full P010 from the GPU in any case, in the NV12 case its just converted before writing to sysmem (in processor registers), so that would clearly point to the system memory being a bottleneck here, since the only major difference is the amount of memory being written into system memory.
Neet009
11th February 2015, 16:40
OK, it seems that system memory would be bottleneck on some old systems when using 4K 10bit HW decoding. Thank you for explaining.
NikosD
11th February 2015, 17:53
CPU:core2quad Q9550
GPU:GTX 960 (driver 347.25)
OS:win7 x64
Could you test using your GTX 960 with latest DXVA Checker 3.3.2 x64 in DXVA native and "decode" mode using latest LAV x64 0.63.0.75 the clip below ?
http://xhmikosr.1f0.de/samples/2160p/DucksTakeOff/DucksTakeOff_2160p50.x264.CRF25.mkv
It's a 2160p H.264 video with huge bitrate.
Neet009
11th February 2015, 19:50
Could you test using your GTX 960 with latest DXVA Checker 3.3.2 x64 in DXVA native and "decode" mode using latest LAV x64 0.63.0.75 the clip below ?
OK!
DucksTakeOff_2160p50.x264.CRF25
DXVAChecker 3.3.2 x64, DXVA native, decode
78.5 fps, cpu 2% (Test 5 times, Avg)
DXVAChecker 3.3.2 x64, DXVA copy-back direct, decode
77.9 fps, cpu 9%
NikosD
12th February 2015, 00:12
OK!
DucksTakeOff_2160p50.x264.CRF25
DXVAChecker 3.3.2 x64, DXVA native, decode
78.5 fps, cpu 2% (Test 5 times, Avg)
DXVAChecker 3.3.2 x64, DXVA copy-back direct, decode
77.9 fps, cpu 9%
Thanks! I thought so!
It seems that Nvidia uses the same H.264 decoder for 960, like the previous models VP6.
They didn't improve H.264 performance, so it's still a 4K80 fps H.264 decoder.
Just for comparison, my Core i7-4790- iGPU HD 4600 (GT2) at 1.5GHz has these results:
DucksTakeOff_2160p50.x264.CRF25
DXVAChecker 3.3.2 x64, DXVA native, decode
200 fps, cpu 1% (Test 5 times, Avg)
NikosD
14th February 2015, 12:21
CPU:core2quad Q9550
GPU:GTX 960 (driver 347.25)
OS:win7 x64
NVIDIA GTX 960 Benchmarks
I encoded a 2160p50fps-HEVC_Main10 file with an average bitrate of 128Mbps close to BluRay UHD.
The clip is here:
http://www.filedropper.com/crowdrun2160p50main10-127mbps
I also added, just for testing reasons, a 300Mbps clip here:
http://www.filedropper.com/crowdrun2160p50-hevcmain10300mbps
I would like to see some results using LAV x64 v0.64 DXVA-CBD of Nvidia 960 of both decode and playback modes.
I'm interested in MIN/AVG/MAX fps.
Using my Core i7-4790 the results are:
1st clip (130Mbps)
Decode: 20/38/42
Playback (1280x720):12/33/35
2nd clip (300Mbps)
Decode: 3/27/30
Playback (1280x720):0/24/28
nevcairiel
14th February 2015, 13:05
Decode (P010): 94/100/104
Decode (NV12): 94/100/105
Playback (NV12, 720p): 36/89/101
I'm not sure when the Playback min value occured, it did seem to run through the video very fast at all times. Maybe right at the start when it was still loading or something. Not sure I would put too much value on it.
NikosD
14th February 2015, 13:48
Decode (P010): 94/100/104
Decode (NV12): 94/100/105
Playback (NV12, 720p): 36/89/101
I'm not sure when the Playback min value occured, it did seem to run through the video very fast at all times. Maybe right at the start when it was still loading or something. Not sure I would put too much value on it.
Just added a 300Mbps test clip.
It's either that you write or the clip has some spikes with huge bitrate.
A simple bitrate viewer I have it's not compatible with HEVC in order to check it out.
Neet009
14th February 2015, 17:28
My results:
(GTX 960, Q9550 3.4GHz, DDR3-1333 16G)
LAV x64 v0.64 DXVA-CBD
1st clip (130Mbps)
Decode(P010): 73/80/83
Decode(NV12): 84/92/95
Playback (1280x720):54/85/91
2nd clip (300Mbps)
Decode(P010): 60/78/82
Decode(NV12): 64/79/84
Playback (1280x720):39/75/84
P.J
17th February 2015, 21:10
LAV 0.64.0 got much better but the only problem is the glitches :(
The video doesn't play smoothly while the CPU/GPU are ~50%
NikosD
18th February 2015, 11:03
For anyone interested in testing, I encoded a 8K (7680x4320) HEVC clip at 60fps in both 10bit and 8bit versions.
Of course, you can't HW accelerate the decoding of those clips even if you have a 960 card, due to high resolution.
You need a very fast CPU.
The clips are just 1 sec and very small.
Clip 1- HEVC 4320p60fps -10bit
http://www.filedropper.com/crysis3-7680x432060fps-137mbps1sec-hevc10bit
Clip 2 - HEVC 4320p60fps -8bit
http://www.filedropper.com/crysis3-7680x432060fps-141mbps1sec-hevc
Tests
DXVA Checker x64 3.3.2 - LAV x64 v0.64 - Core i7 4790
Clip 1
Decode 2/16/17
Clip 2
Decode 10/21/22
Note that I'm on a i7-5930K now with DDR4 memory, so my memory performance is quite good, and core 2 is quite old, the memory may be much more of a bottleneck there than on newer CPUs.
I'm sure you are going to need a faster processor, like Core i7-5960X for realtime decoding of those 8K HEVC clips :)
foxyshadis
18th February 2015, 11:41
What was the cpu utilization like? Pegging all 8 threads? I wonder how much of that is just CABAC processing at 140mbps.
NikosD
18th February 2015, 13:45
It sure uses all 8 threads and the CPU utilization is on average ~80% by putting 16 threads in LAV Video properties, as in the above benchmark tests.
Looking at the decoding performance of the 4K HEVC 10bit ~130Mbps, it has more than double fps (38 fps vs 16 fps) than 8K HEVC 10bit ~140Mbps.
So, the resolution plays the most important role for decoding.
Aleksoid1978
21st February 2015, 06:29
Hi all.
I buy GTX 960, test LAV Video Decoder on HEVC 10bit, then modify MPC-BE's video decoder. And ... perfect work DXVA HEVC 10bit, EVR Custom accept P010 DXVA input.
Here test build - http://aleksoid.voserver.net/MPC-BE/mpc-be.exe_DXVA_HEVC_4K_10Bit.7z - it's test build and work only 10bit HEVC DXVA decoder.
P.S. Only MPC-BE' EVR Custom can accpet P010 DXVA.
NikosD
21st February 2015, 08:17
P.S. Only MPC-BE' EVR Custom can accpet P010 DXVA.
So, does that mean that you can use DXVA native with 10bit HEVC ?
I asked nevcairiel about EVR-CP but he didn't answer.
What's the difference between MPC-HC EVR custom and MPC-BE EVR custom ?
Aleksoid1978
21st February 2015, 08:24
So, does that mean that you can use DXVA native with 10bit HEVC ?
What's the difference between MPC-HC EVR custom and MPC-BE EVR custom ?
Yes - native DXVA HEVC 10bit but only in EVR Custom, vanilla EVR show only white screen.
About MPC-HC - it's use hook and drop P010 input for EVR :)
wanezhiling
21st February 2015, 08:42
http://i2.tietuku.com/91a1f3f716deb554.gif
Any proof?
Like dxva checker trace log.
Aleksoid1978
21st February 2015, 09:25
Proof - 1.5-3% cpu load when decoding hevc 10bit 4k :)
NikosD
21st February 2015, 09:41
This is my post asking nevcairiel about EVR-CP.
He didn't answer, but probably he didn't thought about MPC-BE.
So, it seems that DXVA2 Native and 10bit HEVC decoding are incompatible.
What about EVR-CP ?
Any difference ?
Could Intel or AMD do any tricks with the driver, in order for DXVA2 Native and 10bit to be compatible ?
Aleksoid1978
21st February 2015, 11:26
What interesting - HEVC DXVA 10bit decoder support output to "standart" NV12 type.
http://i.imgur.com/XQhZjgd.png
http://i.imgur.com/0sAiMMD.png
nevcairiel
21st February 2015, 11:38
As long as vanilla EVR does blindly fail on it, i'm not enabling it, its as simple as that. I don't add buggy features that only work in one player with one specific renderer, and crap out everywhere else.
And I'm definitely not enabling NV12 output from the decoder without proper dithering... :)
Let us know when you get EVR to actually accept a P010 connection, and not NV12, then you got something new. :p Your screenshot has 8-bit surfaces everywhere, thats no good for quality.
Using a NV12 connection and sending P010 DXVA2 surfaces is something I tried before as well, but it crashes on some systems, shows white screens on others...
Aleksoid1978
21st February 2015, 12:33
Let us know when you get EVR to actually accept a P010 connection, and not NV12, then you got something new. :p
Using a NV12 connection and sending P010 DXVA2 surfaces is something I tried before as well, but it crashes on some systems, shows white screens on others...
Only EVR Custom/EVR Sync accept NV12 for HEVC 10bit. Vanilla EVR - show white screen, madVR - green :)
wanezhiling
21st February 2015, 13:17
EVR-CP works, that's enough, most people use it cuz it's a default renderer in most third-party win players. :)
Well, how to do a proper dither, it's a problem..
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.