Evaluation of HEVC decoders (SW, Hybrid and HW)

[el Filou]

Originally Posted by NikosD

All these are good questions, but I'm afraid GT 1030 is not so popular so the one and only owner appeared here has declared that he doesn't own a 4K display.

We must find a combination of 1030 using a 4K display, which could be rare considering low GPU power of the card and only 2GB VRAM.

Spec-wise, a 1030 is pretty much half a 1050 Ti in every way: half the quantity of VRAM, half the number of transistors and half the number of compute cores, and nearly half (43%) the memory bandwidth.
So in theory you just need someone with a 1050 Ti and a 4K TV (sorry, 1080p for me), and ask them to watch with GPU-Z if GPU usage, VRAM usage, and memory controller usage never go above 50% (or let's say 40-45% to keep a safe margin) and if it doesn't then it should be fine for a 1030, right?

[huhn]

you don't need a 4k display to test 4k "output" at least not with nvidia.

the problem is the Vram and nothing else. if you do a proper render chain with proper buffer you will run out of Vram or close to it.

[peca89]

Thanks for your replies. I must admit I do not really understand why do you think (or why it is) 4k so demanding. If you accept the logic that performance and ability to play video in realtime can be linearly scaled like some people here mentioned, can you explain why my ages old Radeon 5670 with only 512MB of VRAM and only 400 MHz of clock during playback is perfectly capable of chewing 1080p at 60 Hz. It stays below 250 MB of memory usage and below 50% of GPU usage using Win 10, MPC-HC, EVR and LAV video with DXVA native. 4k is "only" 4 times more pixels than 1080p and 1030 has 4x more VRAM, 3x GPU clock and much faster shaders.

Main question: Why does 4k need >2GB of VRAM when 1080p needs 10 times less?

[el Filou]

Originally Posted by peca89

Thanks for your replies. I must admit I do not really understand why do you think (or why it is) 4k so demanding. If you accept the logic that performance and ability to play video in realtime can be linearly scaled like some people here mentioned, can you explain why my ages old Radeon 5670 with only 512MB of VRAM and only 400 MHz of clock during playback is perfectly capable of chewing 1080p at 60 Hz. It stays below 250 MB of memory usage and below 50% of GPU usage using Win 10, MPC-HC, EVR and LAV video with DXVA native. 4k is "only" 4 times more pixels than 1080p and 1030 has 4x more VRAM, 3x GPU clock and much faster shaders.

Main question: Why does 4k need >2GB of VRAM when 1080p needs 10 times less?

You are right, and 2 GB is well enough for "basic" 4K video playback (Edit: except for Netflix, if you believe NVIDIA, but they've never explained the exact reason), it's just that quality is a highly subjective question.
A lot of people on this forum are videophiles, and if you want to take full advantage of the processing power of a PC GPU to enhance the rendering quality and smoothness of your video playback, then you'll have to use things like a long buffer queue, internal processing using high precision floating point formats etc. All of this combined can increase VRAM usage quite a lot.

Here are some numbers on my 1050 Ti, playing HEVC Main10 2160p60 140 Mbps (i.e. Blu-ray UHD level) with DXVA Native, and outputting to 1080p:

MPC-HC EVR: 705 MB
MediaPortal EVR-CP: 1110 MB
MPC-HC madVR: 1483 MB
MPC-HC EVR-CP 8 buffers: 1765 MB (I can't understand why it uses more than madVR)
MediaPortal madVR: 1802 MB

Using DXVA CopyBack instead of Native adds 370 MB to those numbers.
Outputting to 2160p 10 bit instead of 1080p would add a few 100 MBs again.

[v0lt]

Originally Posted by el Filou

MPC-HC EVR-CP 8 buffers: 1765 MB (I can't understand why it uses more than madVR)

Why 8 buffers? What is the format of these buffers?

[el Filou]

Originally Posted by v0lt

Why 8 buffers? What is the format of these buffers?

The renderer setting is just called "EVR Buffers", the default is 5 but I found that increasing that value a bit prevents skipped frames in rare conditions.
I guess it's a setting equivalent to madVR's "GPU queue size".

[huhn]

@el Filou

you are aware that at UHD output the render queue and the output frame are at least 4X as big which is more than 100 mb...

like i said before you can test it using nvidia DSR. and again UHD output with 2 GB is possible but you are really pushing it.

[el Filou]

Originally Posted by huhn

@el Filou you are aware that at UHD output the render queue and the output frame are at least 4X as big

Yes I am.

Originally Posted by huhn

which is more than 100 mb...

I know, that's why I wrote "a few 100 MBs", but I should have written "a few hundreds".

Originally Posted by huhn

like i said before you can test it using nvidia DSR. and again UHD output with 2 GB is possible but you are really pushing it.

Thanks for the clarification, I didn't understand how it could be done when you said we could test 4K output.
I've tried DSR and here is the VRAM usage I find in 2160p, with DXVA Native:

EVR: 1105 MB
EVR-CP, render queue 5: 1775 MB
madVR (my custom settings): 2480 MB
madVR shortest render queue: 1988 MB.

So EVR is fine, MPC-HC's EVR-CP is still alright but approaching the limit.

[huhn]

windows high DPI settings can take up some Vram just opening a web browser can make it harder too.

adding needed 10 bit processing and output is going to make it even harder.
subtitles and other things too.

i made madVR work with 2 GB too but i will never ever recommend someone to do the same so do yourself a favor and get 4 Gb Vram or more.

[v0lt]

Never use 32-bit Floating Point textures (in MPC-HC, this is called Full Floating Point Processing). This leads to a meaningless consumption of video memory.

If you really need a floating point for intermediate results, then use 16-bit Floating Point textures (in MPC-HC, this is called Half Floating Point Processing). This is quite enough.

I'll advise you to see the video settings and playback statistics in MPC-BE. There it is more clear.

[edwdevel]

Originally Posted by peca89

Hello,

I'm following this forum for a month now and I didn't find definitive answer if a new GT 1030 would be adequate upgrade for my years old HTPC. It will be connected directly to 4K HDR TV using HDMI.

• Can it upscale 1080p60 and output 2160p60 using EVR? Can it do it using madVR?
• Can it decode AVC/HEVC/VP9 2160p60 SDR and output 2160p60 SDR? EVR or madVR?
• Can it decode AVC/HEVC/VP9 2160p60 HDR and just pass it through to a HDR compatible TV, therefore skipping resource-hungry 4K scaling and HDR<->SDR conversion?

The short answer to your questions is: if you want to use madvr with a 4k TV,
you will probably not be happy with a GT 1030.

The long answers to your questions are:

First, I am the poster here who benchmarked several clips using a GT 1030 and a
wolfdale 2core 3Ghz and a 1600x900 monitor. Since I posted the benchmarks,
my old FHD LCD TV died, and has since been replaced with a brand new Sony XBR900E UHD TV.
Unfortunately, I don't have a HTPC (nor will I), so I still won't be able to
definitively tell you that a 1030 can drive a 4k TV. However, I have been doing
some research with madvr vs. EVR using the 1030, and I believe that some reasonably
confident conclusions can be made about the performance of the GPU with 4k output.

Several posters here have shown that the 1030 with its' 2GB memory *should* be able
to drive a 4k TV. Also, is it obvious that there is nothing special about the 1030 in
Nvidia 10 series line of 1050, 1060, etc. when it comes to 4k output? Nvidia has not
come out with a bulletin stating that, sorry, our 1030 just cannot drive 4k output .
I have done playback benchmarks using DXVA Checker with native 4k resolution and EVR
with various 4k clips. In "Colors of Journey" I got over 100fps, with low cpu and 100%
GPU (this may be normal for playback benchmarks). It is illogical to think that
the GPU scanning electronics cannot drive an HDMI output at 4K from a video memory
resident frame. Thus, I think we can confidently state that the 1030 can display 4k60fps
clips using HEVC and VP9 and EVR.

Madvr, though, is a completly different story. I benchmarked a 4k24fps clip "Exodus"
downsizing to monitor size (about 1080p) with MPC-BE and madvr, and basically
got perfect beautiful HDR output, with the cpu at 10% and the gpu at 90%- without DXVA
downsizing. As soon as DXVA downsizing is set on, the GPU goes to 20% (though the
colors are all wrong- I reported this as a bug on the madvr forum here). This
demonstrates the real issue with madvr: it basically is an image processor using D3D
GPU function for even simple downsizing and is completely dependant on the performance
of the GPU board. My 1030 cannot play 4k60fps clips with madvr bilinear downsizing
to 1080p- not because of the 2G memory, but simply because the 1030, which is the
weakest GPU in the 10 series, cannot keep up with madvr's demands. I can say, though,
both "Exodus" and "Life of Pi" 4k24fps can play perfectly- downsized to 1080p.

So, if you want to use madvr to do image processing such as downscaling, upscaling,
sharping or basically anything, you can forget about using the 1030. You should hang
out in the madvr forum here, where people complain about $600 GTX 1080 boards having
performance problems.

But why do you even need an HTPC if you are going to a modern 4k TV? I've been enjoying
my new android wi-fi state of the art full array dimming UHD TV for the past few days,
which can play all of my 4k clips using wi-fi DLNA perfectly, not to mention all 4k
youtube clips and, yes, Netflix UHD, directly over wi-fi connected to the router (though
I did have problems with the old wi-fi speed, and have since upgraded both my router and
internet connection- but that is another story)

Regards,
edwdevel

[NikosD]

Major performance drop using latest 17.7.2 drivers.

The GPU clocks have been stabilized and using pure decoding mode, the memory clock is always at min state (300 MHz) and the GPU clock is at min state (300 MHz) around 90% of the whole decoding process time, going up to 466 MHz occasionally.

Of course pure video decoding mode has nothing to do with GPU clocks, but memory clock always at min state (300 MHz) could be a problem.

AMD has probably put the internal video decoder clocks lower (they are invisible to the user)

The result is a pure decoding speed less than the <17.4 drivers, a lot less to be more exact. Huge drop in performance.

Now, during playback benchmark mode we are on the opposite situation, regarding GPU/ memory clocks.

GPU clock and Memory clock are at max speed, but still the decoding speed is less than previous drivers, but better than <17.4 drivers.

I also got a micro-stuttering issue while moving cursor on the desktop, it seems that the cursor pauses just for a sec with no reason, like some older situations when incompatible drivers have been installed on the system or some other kind of interrupt caused that little pause.

17.7.2 is a major update, but a probably a little unpolished.

I don't know if the decision of slowing down internal video clocks of the video decoder (invisible to the user) in pure decode mode is permanent for AMD.

[el Filou]

Originally Posted by NikosD

Major performance drop using latest 17.7.2 drivers.

The GPU clocks have been stabilized and using pure decoding mode, the memory clock is always at min state (300 MHz) and the GPU clock is at min state (300 MHz) around 90% of the whole decoding process time, going up to 466 MHz occasionally.

AMD has probably put the internal video decoder clocks lower (they are invisible to the user)

Did they slow it down so much that you can't play 2160p60 smoothly?

[NikosD]

In playback mode the decoding speed is:

Drivers earlier than 17.4 < 17.7.2 < Drivers after 17.4.x up to 17.7.1

So, you can play 2160p60 smoothly, but previous drivers from 17.4.x up to 17.7.1, were definitely faster.

[el Filou]

Maybe they introduced a bug while trying to optimise power profile?
I understand that in this new computing landscape where laptops and other mobile devices represent the mass market, you'd want the lowest possible power consumption while still providing real-time playback, but they should provide an advanced option to put the video decoder to highest performance state for desktop parts.

[aufkrawall]

I've followed Phoronix news quite thoroughly during the last months, and I think there's still not a single sign of AMD supporting VP9 with Vega on Linux.
Nvidia's cuda decoding isn't great either since it has more often problems with certain formats (e.g. HEVC 10 bit HDR), but at least it works well for VP9 YT videos (and without quality degradation, unlike shit APIs by Microsoft).

[nevcairiel]

Originally Posted by aufkrawall

it works well for VP9 YT videos (and without quality degradation, unlike shit APIs by Microsoft).

Microsofts decoding APIs are perfectly bit-exact decoding. Try not to spread false rumors.

[NikosD]

Least expensive RX VEGA 56 will cost around 400$, so I don't think a lot of people would buy it for HTPC or watching YouTube videos.

Only video quality freaks using madVR could find that card interesting for video playback, along with 3D gaming of course.

But I think the plans of AMD involve a desktop APU release on early 2018, along with some medium level cards based on VEGA replacing Polaris cards, so yes, in a longer term it's important for VEGA core to support VP9 hardware decoding.

[aufkrawall]

Originally Posted by nevcairiel

Microsofts decoding APIs are perfectly bit-exact decoding.

You likely know the issues very well, no need to be extra-smart.

[nevcairiel]

Originally Posted by aufkrawall

You likely know the issues very well, no need to be extra-smart.

In which case you likely do not, otherwise you would know better.

There are absolutely no issues to get a perfect bit-exact image out of the hardware decoder using DXVA. FFmpeg has regression tests that test the bit-exactness of decoding, you are free to run those with DXVA decoding to confirm this fact.

I can only guess you are referring to the DXVA-native "issue" that madVR has (and some other players following a similar implementation).
This is not related to decoding, the decoder gives you a perfect bit-exact image back, it only gets degraded through the process of how these renderers convert it into a texture - which is a D3D9 limitation (lack of 4:2:0 textures). You could use DXVA with D3D11 to avoid this (ffmpeg calls this "d3d11va"), or even map the decoded surface to OpenGL - or the easy alternative, albeit with a performance hit (although in my experience on NVIDIA the impact is barely measurable), use Copy-Back.

If you build against Direct3D, using D3D11 is clearly the best option, because you should be using that anyway to get NV12/4:2:0 support for your textures, so you don't have to cheat the chroma upsampling shaders.

NVDEC decoding (formerly CUVID) isn't any different. Either you use copy-back or you map the CUDA memory as a OpenGL surface, or even a D3D surface - although if you use D3D9, the same problems would manifest themself.

With any decoding API one of the main problems is how to get the image from the decoder format (typically a simple GPU memory buffer) into a format for display (typically a texture), but this is generally more limited by the display API you are using, not the decoder. In this case above, D3D9 (not DXVA) is just limited, but we have a modern replacement already.