Evaluation of HEVC decoders (SW, Hybrid and HW)

[NikosD]

Plain EVR doesn't even support external subtitles.

EVR custom is heavier but more useful in realworld situations.

[Aleksoid1978]

EVR Custom accept input P010 and do output to RGB32(mixer X8R8G9B8):
http://i.imgur.com/Tx2NK35.png

[P.J]

Just ordered my EVGA GTX 960, can't wait :D

[NikosD]

Carrizo from AMD will be the first CPU in mid 2015 with a full fixed-function H.265 decoder, but it seems it's for mobile only. No desktop Carrizo.
According to AMD, it has more than 3.5x transcode performance than Kaveri.
http://www.anandtech.com/show/8995/amd-at-isscc-2015-carrizo-and-excavator-details

[nevcairiel]

Technically, the decoder is part of the iGPU, not the CPU (albeit both part of the same chip of course). And who knows if Skylake beats AMD to it... :)

[NikosD]

Almost all CPUs these days have iGPUs inside and almost all iGPUs have fixed - function transcoders inside too.

So a CPU is actually a triple chip (CPU/GPU/Transcoder)

Carrizo is relevant because it will be used in laptops and notebooks etc and I doubt that Skylake will be available before Q4 if it catches 2015 :)

[STaRGaZeR]

Carrizo is not relevant at all, it's probably built into cheap, nasty notebooks with cheap build quality & 1366x768 TN panel screens. Of course, if thats what you want to buy, go ahead.

You don't know where Carrizo will be, so stop spreading BS.

[NikosD]

Easy guys...

GTPVHD is an Intel fan and he likes to be over optimistic for Intel and aggressive to AMD, but let's not continue this topic in this thread.

[StinDaWg]

Does anyone know if Nvidia's GTX 960 H.265 decoder works with dxva copyback and cuvid? I saw a review where they were using it with dxva2, but haven't seen if it's compatible with the other modes.

[P.J]

Finally got my GTX960, no more glitch like the Hybrid solution!
Anyway to play 10bit HEVC with LAV/MPC-HC?

[nevcairiel]

LAV supports 10-bit HEVC decoding on the GTX 960 just fine, just use DXVA2-CopyBack and it'll work.

[iSunrise]

What's the highest HEVC profile/level GM206/GTX 960 does support? Level 5.1?

[NikosD]

Level 5.1 is the old max of H.264, now it's 5.2.

For HEVC maximum level is 6.2 and should be supported by GTX 960

[iSunrise]

Level 5.1 is the old max of H.264, now it's 5.2.

For HEVC maximum level is 6.2 and should be supported by GTX 960
Yes, but is it actually the case? Especially Level 6.2 seems way too high. I would expect Level 5.2 at the most.

Can someone with a GTX 960 verify?

[sneaker_ger]

Just look at the benchmarks that have been posted: GTX960 does not fully support 6.2.

[NikosD]

I think it supports 4K L6.2, what benchmark do you mean ?

Is there any clip not playable ?

[sneaker_ger]

Level 6.2 allows 4K @ 300 fps, 8K @ 120 fps.

[nevcairiel]

5.2 may barely work depending on the complexity, but its only constrained by speed there, not any other features.
6 and up support higher resolutions (8K), which are not supported, so those levels are not supported.

A level is only supported if its fully supported, including speed and resolution constraints. 5.1 should be fully supported, 5.2 might be close on the speed constraint.

Adding extra conditions like "4K at 24 fps may work on L6.2" is just not something thats a useful statement. :p

[NikosD]

I'm on the opposite direction on this.

Sandybridge has a 1080p H.264 decoder capable of 1080p L5.2@300Mbps@100fps.

And because H.264 L5.2 supports up to 4K, does that mean that Sandy doesn't support H.264 L5.2 ?

NO. Definitely not in my opinion.
I could say it's more than capable of 1080p H.264 L5.2 decoding.

So, if GTX 960 can decode a 4K L6.2. 300Mbps at 80fps in DXVA copy-back, I could say it supports L6.2. with the resolution limit of 4K of course.

[nevcairiel]

The point is that these levels are designed to classify a decoder with one simple statement. Classifications are not exact, they are broad categories, so they don't tell you the entire picture, but they do tell you the *minimum* you can expect.
If I wanted to know exactly which limits it has, I would dig up a spec sheet, or run tests, or something.

The only classification valid for the GTX 960 decoder is Level 5.1, since none of the other levels are 100% supported.
This is also how the HEVC standard specifies these levels (and H.264 too). To quote: "A decoder that conforms to a given tier/level is required to be capable of decoding all bitstreams that are encoded for that tier/level and for all lower tiers/levels."

There is a definition so that everyone talking about it will talk about the same thing. Talking about anything else makes no sense, as its confusing at best and at worst mis-represents the facts.

Of course this doesn't mean it cannot decode a select assortment of streams using a higher level, and it can, but there is no classification to express that.
Strictly speaking the old H264 decoders are only L4.1, but that does not mean that they cannot decode 5.1/5.2 1080p streams. But they are not conforming to a full 5.2 decoder!

What you want is something that expresses their full potential, but something like that doesn't exist. The levels only express the minimum features it supports 100%, not the maximum.

PS:
"L6.2 with resolution limit to 4K" also is not correct, as L6.2 allows 300 fps at 4K, and it certainly isn't capable of that.
Do you see how you would need to limit this further and further? Might as well drop the level then and say "it can do 4K, 300 mbps at 80 fps", the level wouldn't add any information anymore.

[NikosD]

I can't disagree with you, especially when you refer to strict definitions, but I remember a time around my first posts here, when the H.264 decoders couldn't decode 1080p H.264 L5.1 streams.

What was the main reason ?

They couldn't handle the 16 Ref.

That feature was critical, because they couldn't play at all those clips.

So, a 1080p H.264 decoder which can't decode at all a certain clip due to the lack of an advanced feature of the level (like ref) does certainly not belong to that level.

So, when ATI fixed the driver for UVD2.2 in order to decode 16 Ref clips, they claimed 1080p L5.1 decoding capability, meaning they fixed the 16 Ref limitation which was critical and not the 300Mbps requirement of L5.1 or the 4K resolution.

Using the rules as strict as you do is one point of view, but in many cases a lot of people reading a GTX 960 is a L5.1 H.265 decoder would understand that they couldn't decode a 4K L6.2@60 fps at all, when we both agree that it can.

Update:


Strictly speaking the old H264 decoders are only L4.1, but that does not mean that they cannot decode 5.1/5.2 1080p streams. But they are not conforming to a full 5.2 decoder!


Looking at the definition of H.264 levels, I'm afraid that your claim about old H264 decoders is not true.

The L4.1 asks for H.264 2048x1024@30fps support, that none of the 1080p old H.264 decoders provide.
The same restriction is true for L4.0

So, according to the strict rules you brought to our conversation, the old decoders like VP4 or QuickSync of SandyBridge are only L3.2 decoders (!)

This is both hilarious and ridiculous...It's completely meaningless and waste of time to talk again about strict level definitions.

[iSunrise]

5.2 may barely work depending on the complexity, but its only constrained by speed there, not any other features.
6 and up support higher resolutions (8K), which are not supported, so those levels are not supported.

A level is only supported if its fully supported, including speed and resolution constraints. 5.1 should be fully supported, 5.2 might be close on the speed constraint.
I basically read all the benchmarks of GM206 and after reading the relevant Wikipedia HEVC article, I could only guess that L5.1 was fully supported by GM206, while I was not sure about L5.2. Also, according to one NV slide the X1 SoC can only do HEVC 4K@30fps (which would conform to L5.0). These guesses were based upon the fact that the maximum resolution and fps for a specific Level was fully met.

So, when taking pre-encoded content into account and purely from a real-time playback perspective, L5.1/L5.2 looks like it's sufficient, which is probably also the reason why they (meaning NV, we will have to see about Intel with Skylake) went with that (Ultra HD Blu-Ray). Even for mobile devices, on current or a future SoC, video encoding/decoding 1080p@300fps and 2160p@120fps is more than enough. For encoding or any other usage scenarios, the more speed, the better, obviously.

We really need a table with confirmed specs and user tests (to see the limits) of devices.

PS:
I already did tests in the past with my iPhone 5s, which has limited 4K H.264 decoding capabilities. Up until today, I am not sure what decoding capabilities the iPhone 6 has, because no one really has tested that. And the iPhone is one of the most sold devices today. Apple only lists what they think is necessary for their needs, not the real capabilities of their PowerVR encoder/decoder that is integrated into their SoC (because it's not relevent for the majority).

[NikosD]

From AnandTech GTX960 launch preview:


A full review is expected in the following days.

It's almost two months since the launch preview article about Nvidia GTX 960 in the Anandtech site.

Did they forget to review the card ? :rolleyes:

[iSunrise]

It's almost two months since the launch preview article about Nvidia GTX 960 in the Anandtech site.

Did they forget to review the card ? :rolleyes:
Still no review, unfortunately.

BTW, NV seems to have added H.264 lossless support to their drivers (at least for Linux according to https://devtalk.nvidia.com/default/topic/821171/unix-graphics-announcements-and-news/linux-solaris-and-freebsd-driver-349-12-beta-/). Does this mean that the performance is the same as with the H.264 lossy settings? They really surprise me, seems NV makes huge improvements when it comes to their hardware VDPAU feature-set or drivers respectively.

[P.J]

I have never seen H.264 lossless but H.264/MPEG2 4:2:2

[P.J]

Cyberlink Video Decoder from PowerDVD v14 does support OpenCL H.265 hw-assisted video decoding and it is available to other DS players, it just has a 'do not use' merit.
You also have to set the decoder to use HAM-mode, don't remember if DXVA-mode would also use OpenCL hybrid decoding. When playing a HEVC video go to the Filters-tab, press and hold 'Ctrl'+'Left Mouse' on the 'Cyberlink Video Decoder (PDVD Generic)', it will open advanced/detailed settings view, the Profile column will tell you if the decoder is using OpenCL or not.
It wont use OpenCL on my GTX 550Ti, but does work on my brothers AMD Radeon HD 5700, too bad, because mine does a lot better on all my samples and tests.
But even in SW-mode I think it does even better than Lentoid and it also supports 10-bit, which Lentoid does not, and both are a LOT faster than LAVVideo x86, on my brothers x64-machine also LAVVideo x64 was slower than Cyberlink and Lentoid, of course it has an old AMD Phenom X4 2.6 Ghz with up to SSE4A instructions.

P.S. last LAV build I tested was 0.63.0.12, don't know how much faster 0.63.0.41 is, I did read it should have better error handling now.

No luck with GTX 960 too :rolleyes:

[vivan]

Multicoreware claim that their decoder is "the fastest, most reliable HEVC software decoder in the world". It's now (temporary, lol) available for free https://x265.com/store/index.php/download-free/ (it requires some stupid registration). Also it will screw file associations (since they know better than you that WMP is the best player ever) and maybe mess with merits or other things.
UPD: actually no need to install, just unpack and build graph using UHDcodeSrcFilter.dll and UHDcodeDecFilter.dll filters. But it still will require activation.

Of course this claim is wrong.
Beauty-2160p@30fps-12.3Mbps on i5-4670K:
LAV x64 (16 threads): 85 fps
LAV x64 (auto threads): 68 fps
MS MFT (DXVA): 46 fps
MCW x64: 42 fps

[nevcairiel]

They have been claiming that theirs is the fastest and only complete decoder for quite some time now, even after being informed of the state of the ffmpeg decoder. What can you do. ;)

[NikosD]

I've downloaded and used for a while the first public release of HEVC decoder by MultiCoreWare - UHDcode.

I have to thank Tom (aka x265_Project) from MCW for providing the app and the coupon, which is free right now as vivan wrote above at https://x265.com/store/index.php/checkout/cart/

Before benchmarks, I have some general comments to make:

1) There is no support of 10bit (main10 profile)

2) I couldn't manage to use the UHDcode HEVC plugin with .mkv, .ts or any other container besides .mp4.
So, it seems that right now it can be used only with elementary streams (.265, .h265, .hevc) and .mp4

3) There is no property sheet for the decoder nor for the splitter. So, for example I couldn't change the number of threads, although the decoder used all 8 threads.

4) The only way to actually use the decoder even with .mp4 files is only if you let the UHDcode splitter handle the .mp4 container.

In that way I couldn't enumerate both LAV video and UHDcode at the same time in DXVA Checker.
I had to change the preferred splitter for .mp4 between LAV and UHDcode splitters in order to test both decoders.

5) I tried to install it to my second Win 10 system with a Core 2 Quad processor, but it was already activated in my main system so I couldn't install it there.
It doesn't allow me to register the UHDcodeDecFilter.dll in a second system.

6) After the installation, the .mp4 files are associated with WMP

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

All benchmarks were done on a Core i7 4790 with Win x64 8.1 Pro system, using latest DXVA Checker x64 v3.3.2 in Benchmark decode mode.

I used LAV Video x64 v0.64.38 , MPC Video Decoder x64 v1.4.4.265 , both using 16 threads and UHDcode v1.0.5.3/1.0.5.4


1. Girls -1080p60 fps -11Mbps


LAV x64 214/300/396 CPU 70%

MPC x64 216/298/379 CPU 70%

UHDcode 140/163/220 CPU 70%



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

LAV x64 81/94/96 CPU 78%

MPC x64 80/93/96 CPU 78%

UHDcode 36/53/57 CPU 80%


Well, the numbers speak for themselves, I don't have to add anything.
For the same CPU utilization, the performance difference is huge on an AVX2 CPU at least.

P.S

In the package of the installer, it seems that there is an OpenCL component of UHDcode HEVC plugin which wasn't installed on my Intel iGPU system.
I don't know if it can be used with other dGPU cards by AMD and Nvidia.

[vivan]

The UHDcode DirectShow filter supports all video resolutions and frame rates, but as most consumer video displays only support 8 bits/pixel, it is limited to HEVC Main profile. A professional version of UHDcode is available for professional products.What a lame reason.
So they do have 10 bit decoder, but to get it you need to pay even more money.

[x265_Project]

All benchmarks were done on a Core i7 4790 with Win x64 8.1 Pro system, using latest DXVA Checker x64 v3.3.2 in Benchmark decode mode.

I used LAV Video x64 v0.64.38 using 16 threads and UHDcode v1.0.5.3/1.0.5.4

1. Girls -1080p60 fps -11Mbps

LAV x64 203/287/370 CPU 70%
UHDcode 140/163/220 CPU 70%

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

LAV x64 81/94/96 CPU 78%
UHDcode 36/53/57 CPU 80%

Our UHDcode DirectShow filter wasn't designed for benchmarking this way. We've done performance testing against other open-source HEVC decoders, and UHDcode always compared favorably. The DirectShow filter is designed to decode frames and feed them to the player application as requested. It doesn't have a benchmarking mode where it would decode as fast as possible. I'll ask our team to try this out however.

BTW, UHDcode is OpenCL accelerated on the latest AMD discrete and APU integrated graphics, and we will to support Intel and NVIDIA platforms as soon as possible.

[x265_Project]

What a lame reason.
So they do have 10 bit decoder, but to get it you need to pay even more money.
Even more than zero?

[NikosD]

Our UHDcode DirectShow filter wasn't designed for benchmarking this way. We've done performance testing against other open-source HEVC decoders, and UHDcode always compared favorably. The DirectShow filter is designed to decode frames and feed them to the player application as requested. It doesn't have a benchmarking mode where it would decode as fast as possible. I'll ask our team to try this out however.


There is no other way to test the performance of a decoder, but pushing it to the limit without the renderer limitation of realtime playback.

Moreover, I tested the decoder in renderless mode (pure decoding), so there are no limitations at all.

I'm open to suggestions for both method and tools.


BTW, UHDcode is OpenCL accelerated on the latest AMD discrete and APU integrated graphics, and we will to support Intel and NVIDIA platforms as soon as possible.


Nvidia doesn't have a decent OpenCL driver. You have to use CUDA.

For Intel, I managed to run Kernelbinary.exe, IIRC correctly the name and it used OpenCL driver of Intel in order to create some files.

Every other OpenCL decoder even built for AMD (like Lentoid or Cyberlink) can be used by Intel because Intel has a real OpenCL 1.2 driver.

So, you only have to allow it in order to be used by Intel.

[huhn]

what are you talking about? nvidia openCL work totally fine.
and openCL 1.2 is not that important...

[huhn]

i tried to use UHDcode on windows 10 to compare it with the build in HEVC decoder from Microsoft which can do 10 bit BTW.
but DXVA checker got stuck when i tried to play a file with that decoder.

after that started windows media player and watched under plugin if i could see this decoder plugin but nothing to see there. and yes i made sure it was the 64 bit version.

after that i played a file in 32 and 64 bit and didn't notice a huge difference in CPU load.

[NikosD]

what are you talking about? nvidia openCL work totally fine.


What are you talking about ?

What do you mean "Nvidia OpenCL works totally fine" ?

CUDA works fine, not OpenCL.

You are confusing things....

[huhn]

do you have an example?

madVR nnedi3 uses openCL and works totally fine with nvidia.

[NikosD]

Cyberlink's OpenCL HEVC decoder and Lentoid OpenCL HEVC decoder.

There is no OpenCL driver from Nvidia.

All there is, is just a wrapper over CUDA translating OpenCL calls to CUDA calls.

Nvidia doesn't provide any help, maintenance or update to its OpenCL driver.

Intel and AMD have already moved to OpenCL 2.0 and Nvidia is stuck to 1.1 because OpenCL is directly competitive to their proprietary CUDA technology.

Don't expect anything from Nvidia other than just a wrapper over CUDA.

[huhn]

and why is the driver broken now? if i want i can write nirmal programs that doesn't work with intel CPU does that mean intel driver are broken?

if nvidia is doing a hybrid decoder there self they will very likely use cuda no secret.
and they provide this decoder already using CUVID or DXVA on older GPUs.

[huhn]

how about claiming down a bit?

BTW. i can't disagree that a CUDA hybrid decoder has more potential than a openCL hybrid decoder. but this would mean a lot of code needs to be rewritten a little over kill if openCL has to work too and it should be generally the same code for all 3 brands.

and this is no reason to call the nvidia openCL driver broken.

BTW. i was trying to use the UHDcode decoder with my r9 270.

and the 349.90 and 349.65 are windows 10 driver i tried both of them already.

[foxyshadis]

Geez, I come back from a month away and the place explodes the day I get back. Try to keep the discussion to numbers, capabilities, artifacts, and official announcements, not your opinions of each other.

[NikosD]

Looks like Nvidia changes its mind about OpenCL and starting to fix the OpenCL driver.
http://anandtech.com/show/9139/nvidia-posts-35005-hotfix-driver-fixes-games-adds-opencl-12-support

What a coincidence ! Maybe they are reading our posts :D


First announced in late 2011, OpenCL is a point update for OpenCL 1.x that added a handful of new (but potentially important) features. More importantly however is the fact that until now NVIDIA has declined to support OpenCL 1.2, opting instead to direct their energies into the growing CUDA ecosystem and its wider usage than OpenCL 1.x. Consequently the addition of OpenCL 1.2 support at this stage comes as a bit of a surprise, but we’ll take it. And hopefully this is a sign that NVIDIA is going to be catching up on OpenCL so that they can support SPIR/SPIR-V and OpenCL 2.x.


But it remains as a CUDA wrapper.

[nevcairiel]

OpenCL 1.2 has been available in the 349 branch of drivers for a while now. Until today drivers from that branch were only available for Windows 10 or Linux though.

It being a CUDA-wrapper is not necessarily a bad thing. It makes implementing it much easier for NVIDIA, and the real question would be how much overhead it really has. If OpenCL kernels just get compiled into CUDA kernels once, there doesn't necessarily have to be a high overhead. Unfortunately, the overhead is really hard to measure.

[NikosD]

Nvidia says the wrapper is thin, but it's not that the biggest problem of OpenCL driver.
It's not the performance.

As users of Nvidia cards write down under the anandtech's article in the comments section, there are incompatibilities, bugs and as anandtech says Nvidia didn't bother fix all those issues.
They have CUDA.

That's why they stuck years in OpenCL 1.1 version.

There was no intension of updating OpenCL driver and fixing incompatibilities and bugs.

They were completely into CUDA and they just made a wrapper to have an excuse of people complaining about complete luck of OpenCL support.

They are not lazy or incompetent.
They do it intentionally, obviously.

[huhn]

because some people in comment on this?
yes there are bugs and there even new ones in this new driver no question.

there are bugs in CUDA too and AMD has problems with openCL too.

[P.J]

So why isn't it possible to use OpenCL in some programs with Nvidia cards?

[Sulik]

OpenCL pretends to be vendor-agnostic, but it really isn't in practice... You still have to write 3 different OpenCL code paths for each vendor if you want to get any kind of decent perf. At least cuda is just like C/C++, so it's not as NVidia-centric as one might think (hence why all serious gpgpu work is done with cuda and not OpenCL).

[wanezhiling]

DXVA Checker v3.4.0 (http://bluesky23.yukishigure.com/en/DXVAChecker.html)

[huhn]

still can't use UHDcode with dxva checker...

[P.J]

DXVA Checker v3.4.0 (http://bluesky23.yukishigure.com/en/DXVAChecker.html)

Great, finally both x86-x64 together :)