Evaluation of HEVC decoders (SW, Hybrid and HW)

[NikosD]

OK.

I've just seen Nevcairiel's answer.

Is it a problem of both x86 and x64 versions ?

[cyberbeing]

Yes, the issue happens on x86 as well.

[NikosD]

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.


Using latest PotPlayer x64 and HEVC DXVA2 decoder for Intel iGPU, I can clearly see the exact same issue like SW decoding.

PotPlayer uses DXVA HEVC for all cases, even 10 bit clips, if you select it.

So, once again even in HW mode, all of my downloaded samples are stuttering.

[nevcairiel]

There is a huge difference between CUVID HW decoding and DXVA decoding, DXVA also uses a lot of ffmpeg code (at least in LAV and since PotPlayer just "borrowed" that code, also in PotPlayer), and CUVID uses none.

[cyberbeing]

The NVIDIA CUVID decoder definitely does not show the same stuttering as the FFMPEG software decoder. The CUVID decoder unlike DXVA is a black box though, so far all we know NVIDIA has some extra error handling logic to avoid "eating the frames inside the decoder" like Nev said is occurring with FFMPEG.

All of those Samsung Demo samples were Main10@L5.2 encoded by ATEME Titan KFE (http://ateme.com/en/products/Transcoders/KFE), and ATEME has a reputation for creating high quality encoding solutions. At this point, I'd give them the benefit of the doubt that these streams are somehow valid, but really who knows. I wouldn't worry too much about it as these are still very early days for HEVC. I'm sure quirks like these will get sorted out by all vendors before 4K Blu-ray is released in Q4 2015.

[nevcairiel]

Its certainly possible the decoder has a bug. I should probably cut a smaller sample out of the Transformers trailer that demonstrates it and poke one of the developers of the decoder with it.
On the other hand, from debug logs it almost seemed like the POC of one frame was repeated, which would indicate the streams have been stitched badly, but i'm not sure i was reading this right.

[cyberbeing]

it almost seemed like the POC of one frame was repeated

Depending on what you are seeing:
All pictures in the same CVS must have a unique POC value. Pictures from different CVSs may share the same POC value, but pictures can still be uniquely identified since there is no possibilities to mix pictures from one CVS with any picture of another CVS. Gaps in POC values are allowed in a CVS...
http://books.google.com/books?id=3WhYBAAAQBAJ&pg=PA35&dq=hevc+POC&hl=en&sa=X

Though it does appear that ATEME Titan KFE is a distributed encoding solution, so bad stitching could very well be within the realm of possibility.

[NikosD]

Its certainly possible the decoder has a bug. I should probably cut a smaller sample out of the Transformers trailer that demonstrates it and poke one of the developers of the decoder with it.



That would be the best.

[P.J]

MPC-HC 1.7.7 LAV 0.63.0, Win 8.1 x64, 750Ti:
"Beauty" video stutters a lot with DXVA2 (EVR/EVR Custom) but no problem with CPU decoder (i3 4150)
"Fitness" works quite great with EVR Custom :confused:

Edit: Almost no problem with the DXVAChecker's player

[NikosD]

I don't have a working Nvidia card to check it out, but I think 750 Ti is a rather powerful card.
Are you sure that DXVA native is selected and not copy-back ?

Also EVR is lighter than EVR-CP.

[P.J]

Yes, it's mostly between 40-70% without max boost.
Even by using CUVID, there's no problem but it's about twice slower than DXVA2, not suitable for 60fps.
10-bit videos doesn't work on Nvidia cards too.

[P.J]

Ok, switched to the iGPU HD4400 and no more stuttering issue with DXVA2.
But it's quite weak for decoding HEVC, played "Fitness" well ~%90 but failed to play "Beauty" smoothly and crashed on 60fps :(

[cyberbeing]

MPC-HC 1.7.7 LAV 0.63.0, Win 8.1 x64, 750Ti:
"Beauty" video stutters a lot with DXVA2 (EVR/EVR Custom)

I can reproduce this with DXVA2-Native. Using EVR-Custom it's quite noticeable, but not as much with plain EVR. The decoder output appears to stall briefly every second or so. madVR seems to avoid this problem by absorbing these brief delays in its queues. DXVA2 Copy-back & CUVID appear unaffected with all renderers.

[NikosD]

I have tried a lot with an Nvidia optimus laptop to make the DXVA decoder work, without success, so I don't have a clear picture what is really going on with Nvidia.

From the posts of cyberbeing above, I think it was clear that DXVA native decoder is very fast for 770 card and he didn't mention any stuttering problems.

But it seems that Nvidia DXVA native decoder has stuttering problems with EVR/EVR CP, so the benchmark speed is useless.

For DXVA copy-back and CUVID, there are no stuttering issues, but the performance is low especially on non super fast cards.

The problem with DXVA native and Nvidia decoder could be a driver's problem or LAV Video problem.

Based on Nevcairiel's posts, the code of DXVA decoder is the same for Intel and Nvidia.

So if Intel's DXVA decoder works in DXVA, which I can assure, then obviously is Nvidia's driver problem.

So, the only good thing left for Nvidia is the ability of CUVID (and only CUVID) decoder to play those pesky 10 bit clips in SW without stuttering.

It seems that is the only decoder capable of doing that.

[JohnLai]

Speak of Intel and Nvidia DXVA, how about AMD solution other than the pretty much pointless Strongene CPU optimised decoder?

Last I read, when AMD Kaveri was released in January 2014, there was a news about AMD collaboration with Telestream to develop HEVC codec that utilised HSA.
It has been 9 months and nothing is heard about the special HSA codec.

On other news, Intel just release new gpu driver for HD2500/4000 version 15.33.29.3945 dated 9/26/2014. Anyone with these IGPU can check if Intel exposes the HEVC DXVA?

[cyberbeing]

I can reproduce this with DXVA2-Native. Using EVR-Custom it's quite noticeable, but not as much with plain EVR. The decoder output appears to stall briefly every second or so. madVR seems to avoid this problem by absorbing these brief delays in its queues. DXVA2 Copy-back & CUVID appear unaffected with all renderers.

Actually it appears that only CUVID has completely stable playback on the Beauty sample, looking at the EVR-Custom CTRL+J stats.

Software = 0ms jitter (-0.8ms <-> 1.2ms)
CUVID = 0ms jitter (-0.8ms <-> 1.2ms)
DXVA2-Copyback = 4ms jitter (-10ms <-> +20ms spikes)
DXVA2-Native = 8ms jitter (-25ms <-> +35ms spikes)

A similar anomaly affecting DXVA2 can also be seen on the Elecard sample:
http://www.elecard.com/assets/files/other/clips/140803_4k_hm130_4s_sao_dbf_qp27.265

Notably, that Elecard sample has the same mulit-threading scaling issue with software decoding as the Beauty sample, so I wouldn't be surprised the issue with DXVA2 has a similar underlying cause. Though seeing CUVID once again being completely immune is curious. It's hard to make an overall conclusion about this without a larger test set of high bitrate 8bit UHD HEVC samples though, since the issue only seems to affect a subset of HEVC encoders.

[NikosD]

Notably, that Elecard sample has the same mulit-threading scaling issue with software decoding as the Beauty sample, so I wouldn't be surprised the issue with DXVA2 has a similar underlying cause. Though seeing CUVID once again being completely immune is curious. It's hard to make an overall conclusion about this without a larger test set of high bitrate 8bit UHD HEVC samples though, since the issue only seems to affect a subset of HEVC encoders.

Have you tried with Nvidia (DXVA/ CUVID) this clip ?

http://demo-uhd3d.com/files/uhd/Hispasat_UHD_NAB-2014_HEVC.zip

Intel's DXVA crashes in both copy-back and native (or gives black screen with audio only)

[NikosD]

Speak of Intel and Nvidia DXVA, how about AMD solution other than the pretty much pointless Strongene CPU optimised decoder?

Last I read, when AMD Kaveri was released in January 2014, there was a news about AMD collaboration with Telestream to develop HEVC codec that utilised HSA.
It has been 9 months and nothing is heard about the special HSA codec.

Don't have high expectations from AMD.

Everything is slow there.

It took them 4 years to implement 4K H. 264 HW decoding.

They announced it on Q2 2010 and they implemented it on Q3 2014.

[dukey]

It took them 4 years to implement 4K H. 264 HW decoding.
Because there is so much 4k hd material ?

[NikosD]

Basically because they said so.

They said that AMD cards support HW acceleration of 4K H.264 and they lied for 4 years and a half.

[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?

[NikosD]

Copy-back/CUVID like slow motion for me on 60fps video.
Copy-back causes more problems too, stops for some seconds.


That reminds me the issues I had with Nvidia 740M and Optimus.


10-bit doesn't work with CUVID.


What do you mean by that ?
It should fall back to SW, I think.


Do Ivybridge/Geforce 600 offer hybrid HEVC too?

I don't have such systems.

[P.J]

It should fall back to SW, I think.

Yes, I meant that :)

Are all of the HEVC videos 10-bit here? http://demo-uhd3d.com/

[NikosD]

No, I have downloaded 8 bit HEVC clips from there, like the one I posted above which crashes Intel's DXVA.

It's here:
http://demo-uhd3d.com/files/uhd/Hispasat_UHD_NAB-2014_HEVC.zip

If you manage to download it, try Nvidia's DXVA/CUVID too.

It should crash I think

[cyberbeing]

Seems http://demo-uhd3d.com finally came back up after being down this past week. All the previous links in the /uhd/ directory have now been moved to a /4k/ directory:
http://demo-uhd3d.com/files/4k/Hispasat_UHD_NAB-2014_HEVC.zip

[NikosD]

Thanks I didn't check it, I've just posted the original source that I had downloaded it.

If someone manages to download it and try to decode it, I would like to know the results of Nvidia.

[cyberbeing]

That Hispasat_UHD_NAB-2014_HEVC sample plays fine with DXVA2-Native, DXVA2-Copyback, and CUVID on my GTX 770.

DXVA2-Native & CUVID have no jitter, stutter, or other issues.
DXVA2-Copyback shows a 5-6ms jitter in EVR-CP, but no noticeable stutter.

[NikosD]

It crashes my Intel DXVA decoder.

That's another difference between the two dxva decoders.

Thanks.

P.S

Assuming of course they didn't change the file!

[cyberbeing]

Assuming of course they didn't change the file!

Well the current hash of Hispasat_UHD_NAB-2014_HEVC.mkv is:
CRC32: 644311D3
MD5: D4985EEC2C985E91DE7D559C560AB51F
SHA-1: 665574705C2588B2E7977F6EAE3524AA576577AC

MediaInfo:
General
Unique ID : 229628849404647287506461971024399774989 (0xACC0E860196F166C85202086ADE7350D)
Complete name : Hispasat_UHD_NAB-2014_HEVC.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 2.13 GiB
Duration : 17mn 11s
Overall bit rate : 17.7 Mbps
Encoded date : UTC 2014-05-09 20:05:46
Writing application : mkvmerge v6.9.1 ('Blue Panther') 32bit built on Apr 18 2014 18:15:44
Writing library : libebml v1.3.0 + libmatroska v1.4.1

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L5.0
Codec ID : V_MPEGH/ISO/HEVC
Duration : 17mn 11s
Bit rate : 17.0 Mbps
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.085
Stream size : 2.04 GiB (96%)
Default : Yes
Forced : No

Audio
ID : 2
Format : E-AC-3
Format/Info : Audio Coding 3
Format settings, Endianness : Big
Codec ID : A_EAC3
Duration : 17mn 11s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 47.2 MiB (2%)
Default : Yes
Forced : No


It's possible the Intel decoder crashes just because of the bad trim, since even with software decoding the first 20 frames are corrupt likely since it's missing a keyframe at the start.

[NikosD]

Well the current hash of Hispasat_UHD_NAB-2014_HEVC.mkv is:
SHA-1: 665574705C2588B2E7977F6EAE3524AA576577AC


Exactly the same file.


It's possible the Intel decoder crashes just because of the bad trim, since even with software decoding the first 20 frames are corrupt likely since it's missing a keyframe at the start.

That could be an explanation.

It crashes both MPC-HC (LAV video) and PotPlayer (obviously they have similar code)

[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]

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]

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.


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]

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]

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]

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]

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]

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]

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]

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

[NikosD]

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


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)

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 ?