Evaluation of HEVC decoders (SW, Hybrid and HW)

[nevcairiel]

I've seen that before, some HW decoders crash when they are lacking a reference frame (or too many reference frames), not really easy to do something about that, though.

[JohnLai]

Originally Posted by P.J

Copy-back/CUVID like slow motion for me on 60fps video.
Copy-back causes more problems too, stops for some seconds.
10-bit doesn't work with CUVID.
Do Ivybridge/Geforce 600 offer hybrid HEVC too?

As for Ivybridge HD2500/4000 with latest driver, I verify that there is no HEVC DXVA support. (Tested it yesterday). There is no HEVC DXVA exposed as shown in DXVAChecker.

Sigh......and here I am hoping for Intel HD4000 HEVC support so that I can use lavfilter Quicksync in future for the acceleration.

Nev, do you have plan to enable HEVC DXVA with Quicksync in future?

[NikosD]

Originally Posted by JohnLai

Sigh......and here I am hoping for Intel HD4000 HEVC support so that I can use lavfilter Quicksync in future for the acceleration.

I was the one who was pressing Intel in their own Intel forums to enable HEVC DXVA in their Pentium Haswell line.

I'm not sure if they finally did it, because I switched to Core i7, but last time I checked it out they hadn't done it.

Judging from the results of HD 4600 inside a Core i7, maybe HEVC DXVA is not a good idea to be enabled in such low performance GPUs.

The same reason goes for HD2500 too.

HD4000 could be better, but only up to 720p and a few easy 1080p clips.

Originally Posted by JohnLai

Nev, do you have plan to enable HEVC DXVA with Quicksync in future?

The developer of QuickSync decoder is Eric Gur from Intel.

You should ask him if he wants to add QS support of HEVC hybrid decoder, but I think he has already said no.

He will do it when pure HW solution will be available - more than a year from now.

[P.J]

Right, even HD4400/4600 aren't that powerful for hybrid solution specially at 4K@60

EVR-CP causes stutter even while playing 4K H.264

[NikosD]

Originally Posted by P.J

EVR-CP causes stutter even while playing 4K H.264

I don't think this is right.

Even with Pentium G3420, I never had any problem with 4K H.264 and EVR-CP, with an exception of 4K120fps which need plain EVR.

ALL the other 4K clips have zero stuttering.

If you have a 4K H.264 clip which stutters with EVR-CP, please share it.

[P.J]

You're right, the Jitter value is about 7 for HEVC but 1 for H.264

[hwti]

I have a GTX970 so here are the results of the hybrid decoder with LAV filters 0.63.0 x64.
I used DXVA processing with 1280x720 like the first post, results were a little better with DXVA benchmark.

Beauty GTX970 : sometimes 46/59/65, sometimes 55/80/86 (CPU usage 9-10%) with higher GPU clock
Beauty i7 3930K : 86/104/109 (CPU usage 56%)

Fitness GTX970 : 67/79/106 (CPU usage 13%)
Fitness i7 3930K : 103/150/158 (CPU usage 76%)

Ducks GTX970 : 106/158/182 (CPU usage 11%)
Ducks i7 3930K : 147/167/175 (CPU usage 88%)

So the hybrid decoder doesn't seem to be very fast, but it allows to reduce CPU usage.
DXVA checker doesn't show the GPU usage, but on Beauty sample GPU-Z shows 60-80% usage with GPU@800Mhz Mem@405Mhz when it decodes at 59fps.
I don't know why the clocks are low, perhaps it's optimized for playback, or there is a bottleneck somewhere.

[NikosD]

Originally Posted by hwti

So the hybrid decoder doesn't seem to be very fast, but it allows to reduce CPU usage.
DXVA checker doesn't show the GPU usage, but on Beauty sample GPU-Z shows 60-80% usage with GPU@800Mhz Mem@405Mhz when it decodes at 59fps.
I don't know why the clocks are low, perhaps it's optimized for playback, or there is a bottleneck somewhere.

I think your DXVA results are fast, it's that your 6 core SandyBridge-E is too fast and makes DXVA results to seem slower.

Of course Nvidia driver looks like it's not optimised for HEVC decoding and it's not stable yet (that's why the clocks go up and down)

But your CPU results are extraordinary.

Which is your CPU clock ?

Update:

After doing some tests with CPU x64 HEVC decoder and DXVA decoding (Null renderer) the performance gap is huge between DXVA Processing (EVR renderer) and DXVA decoding using iGPU (HD 4600)

Beauty:
LAV x64 0.63 (DXVA processing) 53/65/68
LAV x64 0.63 (DXVA decoding) 80/93/96

But using a fast GPU like Nvidia 770 or 970 the performance gap between Null renderer and EVR renderer would be a lot smaller.

So, your results are not extraordinary using DXVA processing and Nvidia 970 (they would be if you were using internal iGPU)

[P.J]

Beauty video isn't interlaced, so why is Null renderer faster?

[NikosD]

Because EVR/ EVR-CP renderers are a lot heavier than Null when using slow GPUs, even in relatively low resolutions like 1280 X 720, which is not low for iGPUs.

I've been writing about this issue of CPU decoders and the degradation of performance due to slow GPUs using even low complexity renderers like EVR/EVR CP the last two years, at least.

GPU is important even in CPU decoding, when you want to display the decoded images.

[huhn]

Originally Posted by NikosD

Because EVR/ EVR-CP renderers are a lot heavier than Null when using slow GPUs, even in relatively low resolutions like 1280 X 720, which is not low for iGPUs.

I've been writing about this issue of CPU decoders and the degradation of performance due to slow GPUs using even low complexity renderers like EVR/EVR CP the last two years, at least.

GPU is important even in CPU decoding, when you want to display the decoded images.

EVR uses the post processing form the GPU driver this can have a huge effect on dxva results but doesn't matter in real world.

even my hd4000 doesn't have problems with madVR and a 60 fps progressive source when setup right.

[NikosD]

That's one of the first things I always disable.

Post processing filters of the driver.

In order to check what we are talking about, you have to benchmark the same video file using "DXVA decoding" and "DXVA processing" options of DXVA checker with your HD 4000.

One issue e.g is scaling, which has a large performance cost for low GPUs.

Using a real renderer even if you disable everything from post processing filtering of the driver's control panel, you can never avoid the performance penalty of scaling a 4K clip to 1280x720p.

[huhn]

Originally Posted by NikosD

That's one of the first things I always disable.

Post processing filters of the driver.

In order to check what we are talking about, you have to benchmark the same video file using "DXVA decoding" and "DXVA processing" options of DXVA checker with your HD 4000.

why should I when real world playback works fine? what to gain from these informations?

[NikosD]

Because that's what we are talking about.

The performance impact of using real world renderer vs null renderer.

You can only play clips that you can actually play, but which is your limit ?

How could you know where is the upper limit of your system ?

If your system can play a clip using DXVA processing with 100fps and using DXVA decoding with 150fps when the real time frame rate of the clip is 24fps, then of course you will not have a real world decoding problem.

But if the clip is 60fps and you can decode it with null renderer (DXVA decoding) in 75fps but with EVR (DXVA processing) in 50fps, then it's more than obvious you will have a problem playing back in real time that 60fps clip using EVR or a more complicated renderer.

For me the main question about this issue is what exactly slows down a low GPU using EVR instead of Null renderer, but doesn't affect so much a high performance GPU which has same results using either null or EVR renderer.

One example I thought of performance penalty is scaling.

[hwti]

Originally Posted by NikosD

I think your DXVA results are fast, it's that your 6 core SandyBridge-E is too fast and makes DXVA results to seem slower.

Of course Nvidia driver looks like it's not optimised for HEVC decoding and it's not stable yet (that's why the clocks go up and down)

But your CPU results are extraordinary.

Which is your CPU clock ?

On Ducks, the CPU is mostly at its turbo frequency, 3.8Ghz.
With other samples, the CPU usage is lower so the clocks change a lot.

The 3 samples don't use an high bitrate, for example the 4K demo on Hotbird is 3840x2160 50fps 30Mbps.
It's 10 bit, so the hybrid decoder doesn't work.
LAV x64 is now very fast on it, but the gap with LAV x32 is huge :
- It plays fine with MPC-HC x64 (50% CPU)
- stuttering with MPC-HC x32 or DVBViewer with LAV x32 (100% CPU)
DXVAChecker seems to have a few problems with it :
- DXVA processing shows 0 fps
- DXVA decoding doesn't show the video, but averages at 85fps for the difficult parts (at least on my 3 minute capture, perhaps there are slower parts during the whole loop)

[NikosD]

Originally Posted by hwti

The 3 samples don't use an high bitrate, for example the 4K demo on Hotbird is 3840x2160 50fps 30Mbps.
It's 10 bit, so the hybrid decoder doesn't work.
LAV x64 is now very fast on it, but the gap with LAV x32 is huge :
- It plays fine with MPC-HC x64 (50% CPU)
- stuttering with MPC-HC x32 or DVBViewer with LAV x32 (100% CPU)
DXVAChecker seems to have a few problems with it :
- DXVA processing shows 0 fps
- DXVA decoding doesn't show the video, but averages at 85fps for the difficult parts (at least on my 3 minute capture, perhaps there are slower parts during the whole loop)

Can you upload somewhere a sample ?

[hwti]

Originally Posted by NikosD

Can you upload somewhere a sample ?

Here is a short (25s) sample
http://jheberg.net/captcha/hotbird-4k-demo/

[NikosD]

Originally Posted by hwti

Here is a short (25s) sample
http://jheberg.net/captcha/hotbird-4k-demo/

Originally Posted by hwti

LAV x64 is now very fast on it, but the gap with LAV x32 is huge :
- It plays fine with MPC-HC x64 (50% CPU)
- stuttering with MPC-HC x32 or DVBViewer with LAV x32 (100% CPU)
DXVAChecker seems to have a few problems with it :
- DXVA processing shows 0 fps
- DXVA decoding doesn't show the video, but averages at 85fps for the difficult parts (at least on my 3 minute capture, perhaps there are slower parts during the whole loop)

Originally Posted by huhn

why should I when real world playback works fine? what to gain from these informations?

Excellent sample.

@hwti

Because it's a 10bit clip you have to disable from LAV properties the 10bit output format "P010" because Nvidia driver has problems with 10bit clips.

After that, everything works fine with DXVA Checker in both modes "DXVA Decoding" and "DXVA Processing"

@huhn

Look at the results to see what exactly I was saying about Null/ EVR/ EVR-CP renderers.

With signature system and LAV x64 0.63 using CPU (SW decoding) and threads = 16

Benchmarks:
LAV x64 CPU DXVA Decoding (Null) 47/62/66 CPU Usage 98%

LAV x64 CPU DXVA Processing (EVR) 33/49/52 CPU Usage 95%

The best CPU usage I've seen during SW video decoding.

Playback:
In realworld playback using MPC-HC x64 v1.7.7 and EVR-CP the clip has a jitter of ~9-10ms and it can't go more than 44fps-45fps and a few dropped frames.

Using EVR, the jitter=0ms and video decoding is at 50fps - realtime decoding.

[huhn]

but is your file a real world file? I guess not. if a i7 can decode it easily it is simple an extrem case nothing you can buy or normally create.

I don't see HEVC as a real world problem right now.

[NikosD]

When I put the issue of EVR/ EVR-CP renderer being heavier than Null renderer with low GPUs, I put it in general and not HEVC specifically.

Now, about HEVC specifically I have to say that all those samples from ASTRA and HOTBIRD are real world samples of Satellite broadcast video.

What is more real file than that ?