Evaluation of HEVC decoders (SW, Hybrid and HW)

[NikosD]

1 - link to wrong file(30fps) :)
2 - i found there with 50fps and on my RX460 it's play stable 50fps.

Sorry, this is the clip:
ftp://helpedia.com/pub/multimedia/x264/testvideos/2160p%20samples/DucksTakeOff_2160p50.x264.CRF24.mkv

It sticks to ~42fps and using DXVA Checker I have the same result ~42fps

[CruNcher]

Overriding LAV VIDEO avcodecs auto threading decisions can improve bitrate spike drooped frame situations significantly :)

in both H.264/H.265 x264/x265 especially sudden encoder overflow situations

http://i1.sendpic.org/t/23/23qZ0HYj5AxO8QmrQpBR36j9zmV.jpg (http://sendpic.org/view/1/i/tTQF1z3b6GjfUVQtVRrmxn0kSCL.png)

Need to retest vs Lentoid :D

[nevcairiel]

Did you increase or reduce the number of threads? Auto uses Core Count * 1.5, which has shown in benchmarks to be the best, but for realtime exceeding the core count is probably not good, so I should maybe reduce that.
(Note that this doesn't affect HW decoding at all)

[Aleksoid1978]

NikosD
Tested on Polaris RX460.
DucksTakeOff_2160p50.x264.CRF24.mkv - MPC-HC/MPC-BE/Pot/Microsoft Video Decoders(DS/MFT) ~30fps
47.Crowd_run@120fps-60Mbps.mkv - as i said have wrong timestamp. I don't know how Pot's splitter handle this file(maybe it's ignore timestamp from file and generate it). Here fixed version(corrected timestamp) - 47.Crowd_run@120fps-60Mbps_fix.mkv (https://yadi.sk/i/74_5v5Kn33X3UL), play perfect ~120fps on MPC-BE/MPC-HC.

[NikosD]

NikosD
Tested on Polaris RX460.
DucksTakeOff_2160p50.x264.CRF24.mkv - MPC-HC/MPC-BE/Pot/Microsoft Video Decoders(DS/MFT) ~30fps


Not here.

30 fps ?

No way.

I get 43fps with MPCs and stable 50fps with PotPlayer.

Can you record your playback with ReLive ?

[Aleksoid1978]

Not here.

30 fps ?

No way.

I get 43fps with MPCs and stable 50fps with PotPlayer.

Can you record your playback with ReLive ?

Why record ?? I see what i see :).
Maybe you have RX470/480 and it's faster then my RX460.

P.S. ~30fps in MPC-BE/MPC-HC with statistics :)
Here records:
MPC-BE (https://yadi.sk/i/YhoyGx9033YuvM)
Pot (https://yadi.sk/i/OuFT-0Cw33Yuwp)

[CruNcher]

Did you increase or reduce the number of threads? Auto uses Core Count * 1.5, which has shown in benchmarks to be the best, but for realtime exceeding the core count is probably not good, so I should maybe reduce that.
(Note that this doesn't affect HW decoding at all)


Im currently swinging between 8 and 12 threads with 4 Physical cores for Edge cases on this System with MPC-BEs OSD Enabled.

The situations we talk about though are very specific when the CPU suddenly jumps from say 25% to above 90% and then in an instant back doiwn

Though DIAVC is still the most impressive it survives these overflows without really any visible issue in the AVC case.

But it's also easy visible why this is the case it never really reaches the 90% at all but stays at 75%, it never really reaches the critical area.

And yeah with 12 threads i can reduce it with Lav Video to 83%

[NikosD]

Why record ?? I see what i see :).
Maybe you have RX470/480 and it's faster then my RX460.

P.S. ~30fps in MPC-BE/MPC-HC with statistics :)
Here records:
MPC-BE (https://yadi.sk/i/YhoyGx9033YuvM)
Pot (https://yadi.sk/i/OuFT-0Cw33Yuwp)

Well, you have to re-examine your sight :D

Your first recording with MPC-BE starts at 50fps then drops to ~40fps and then rises again to ~48fps (!) looking at OSD statistics.

On the other hand, the below playback statistics reveal something more funny, a steady playback at ~60 fps (!)

What is going on ?

Very strange behavior but certainly not 30fps.

Are you sure you recorded the playback of the proper clip ?

Could you open the full statistics of the OSD in your next recording ?

[Aleksoid1978]

With full statistics fps ~25-30fps, the same as Pot.

[CruNcher]

GM204 reaches the 50 FPS as well with MPC-BE here

http://i1.sendpic.org/t/wH/wHrnezK4GTUy76uu74TiLAjbDZb.jpg (http://sendpic.org/view/1/i/bUwBqtk4bMp974Ret4LVwNTMVm9.png)

But statistics mode 2 full statistics is to much timer pressure i rarely use it ;)

And yes Aleksoid still using an older build (dont like what has happened to the Graph scaling)


And on Mobile i really like to avoid the seekbar ;)


Wow that is a pretty bad decoding result ?

was it cached or first play ?

That sample has some very insane I/O peaks up to 288 mb, better caching 1st to avoid possible false results from I/O congestion.

@nevcairiel

Highering the thread count smoothes out this issue as well

http://i1.sendpic.org/t/A6/A6TzCmzn6U6NFjXab6Sliak0rLo.jpg (http://sendpic.org/view/1/i/wf0jW8KnRy8EKNDRZszBb7jGL9h.png)

but still Lentoid is more efficient in that case not 1 peakdown with it.

Absolute undisturbed playback with Lentoid in thiose Ateme Encoder situations

http://i1.sendpic.org/t/mV/mVYvnRdT8OxdjbAhyMYImGahy1R.jpg (http://sendpic.org/view/1/i/2OejQmSS2pNWqRVTu1yzF554XqB.png)

With LAV Video (avcodec) it allways suddenly falls down to 21 fps

The Pattern looks intra frame relatied (scenecuts)

Wow Mainconcepts "Low Latency" Mode in their H.264 Decoder is pretty efficient 0 issues with the x264 encoder overflow best result together with DiAVC so far.

And it is also damn stable each run, but therefore they don't survive the extreme 4K 60 FPS sample so well even with deblocking off they don't seem to be able to maintain the performance needed for that extreme sample, 2 jitter fails then they stabilize and 1 jitter fail again without their deblocking overhead that's pretty strange ;)


Though i get render slowdowns i dont really recognize statistics wise at all but i hear them from the CPU Fan Reaction ;)

actually that's wrong you can see them in the jitter number the graph is not detecting them it's already the difference from 0ms to 1ms i pick up in that sample on its motion as heavy discontinuities (slowdowns).


The Graph seems not to have the resolution to show this 1 ms render difference efficiently.

Also the jitter counter reacts a little later on the slowdown after it passed by.

The Sync Video Renderer has overall also some nice properties the 3 jitter fails become immediately dropped frames and recognized as glitches

and it shows that 1 ms difference as a clear peakdown, perfect :)

This is indeed really cool where Mainconcept in EVR-CP showed the 3 jitter issues of peaks around 16 ms its now dropping frames entirely in those 3 areas with EVR-SYNC and Lav Video survives it with only 1ms peakdowns where on EVR-CP it showed no visible peaks at all in the Sync Graph.

Which in the end means EVR-Sync is even more sensitive and the room for errors like in EVR-CP becomes mega small and you gonna recognize even 1 ms discontinuities from the Decoder with it's Graph and big blow ups will result in dropped frames immediately displayed ;)

[NikosD]

UHD what else but you really have to higher the RePlay bitrate somehow :)

and don't forget changing to MPC-BE and using the 2nd statistics display mode to reduce overhead you get to much sync offset with all that timers running and overall jitter.




Could you run some Vulkan/D12/OpenGL application while recording the playback with VSR at 4K :D ?

But please use MPC-BE on it's 2nd statistics display



Could you try the same with VSR and MPC-BE


OK, I had two problems with VSR:

1) From my native and top resolution of 1680 x 1050, I couldn't go higher than 2560 x 1600.
That's the top resolution supported, no 2160p for my monitor.

2) When I switched to 2560 x 1600 VSR, I couldn't record in that resolution using HEVC.
The decoding frame rate dropped to ~4fps.

It works using AVC at that resolution and HEVC at 1080p.

So, I have two versions of VSR playback.
All of my desktop recordings are at 15Mbps this time.


Normal 1680 x 1050 resolution MPC-BE

1) Full OSD
https://www.sendspace.com/file/493mdg

2) Minimal OSD
https://www.sendspace.com/file/0wp41a


VSR 2560 x 1600 resolution MPC-BE

3) HEVC 1080p minimal OSD
https://www.sendspace.com/file/533rh1

4) AVC 1600p minimal OSD
https://www.sendspace.com/file/4ojrng

[CruNcher]

I will try to prepare the most efficient hevc encoding i can from my desktop this will give a very pretty interesting compare with our pretty close system specs it will be very interesting especially also from the OS Driver point of view between GM204 28nm VPX (NVDEC/NVENC) implementation and Polaris 10 RX 470 14nm UVD/VCE (optimized WDDM 1.1 vs still in optimization phase WDDM 2.0) :)

Obviously though we can't or better shouldn't do this with the H.265 Decoder base GM204 would be very badly limited their on the CUDA Decoder side and that is far far away from Playing that 4K Channel sample and would create to much overhead on the CPU anyways even with simpler complexity levels, also that it is officially not able to play that 4K Channel sample at all ;)

1) From my native and top resolution of 1680 x 1050, I couldn't go higher than 2560 x 1600.
That's the top resolution supported, no 2160p for my monitor.

That VSR is still limited Hardware wise is a pretty heavy let down though it seems 4K is only invested into the Fiji based High cost Platform i guess where it makes more sense.

Though now i wonder if VSR works at least on the RX 480 in 4K like it did previously on the 390x didn't it ?


2) When I switched to 2560 x 1600 VSR, I couldn't record in that resolution using HEVC.
The decoding frame rate dropped to ~4fps.

Very interesting information that you also hardly see in reviews :)

But reviews clearly show that the RX 470 is entirely optimized for the 1080p Edge not even really 2560x1600 overall, so it's not that surprising at all that it seems to brake down especially on 2560x1600 60 FPS HEVC Encoding a 4K output result scaled to that resolution @ 60 FPS at the same time which is heavy on everything, especially that whole thing Discrete in our case over the PCI-E 2 Bus you need some very efficient low latency compression ideas here and very efficient capturing from the OS Driver Level of course.

All in all enough RAW Power with clever ideas and perfect low level optimization not only limited to the Decoder/Encoder IP ;)

PS: The HEVC 2560 Encoding indeed looks very jittery especially in the ballerina scenes but the problem can be many causes all that timers running make me headaches

[baii]

Any info on vp9 acceleration enabled on latest radeon driver? Seems like the only thing tipping htpc user to the red side now other than price.

[huhn]

on they didn't add it and it is very unlikely that it will be a hardware decoder.

[CruNcher]

@NikosD

Could you try the Philips and the Channel 4k sample with EVR-SYNC once with the additional 3rd party hardware counter polling and once without (plain desktop) ?

http://demo-uhd3d.com/fiche.php?cat=uhd&id=135

http://i1.sendpic.org/t/nx/nx3QJ4doQK7WmeZlMvewMJf8ys9.jpg (http://sendpic.org/view/1/i/cKzTXemtZ95aEFo32jnooWGitoX.png)

[Yups]

I already received my i7-7700k which I replaced with my i7-6700k. I did some decoding tests from my 6700k before I switched to the 7700k, comparison between Skylake and Kabylake will follow.


http://fs5.directupload.net/images/161217/h6tn4jdp.png

[CruNcher]

Nice should be stomping AMD and Nvidia into the ground once again :)

Though RayZen might get the same Encoder/Decoder update like Vega.

and with DX12/Vulkan Renderer on the rise it could also get better for Realtime Video stability

[Yups]

i7-6700k 4.0 Ghz, HD 530 1.15 Ghz/i7-7700k 4.2 Ghz, HD 630 1.15 Ghz
Windows 10 x64, lav 0.69, 21.20.16.4551, DDR4-3200, CPU Turbo disabled


DucksTakeOff_2160p50.x264.CRF24.mkv (h264) 134 fps/134 fps
LG_4K_View-the-Feeling.mp4 (HEVC 8 bit) 190 fps/213 fps +12%
bbb-3840x2160-cfg02.mkv (HEVC 8 bit) 173 fps/191 fps +10%
5_crowd_run_2160p50_300Mbps.mkv (HEVC 8 bit) 125 fps/135 fps +8%
4_yvid_SAM_0235-UHD_Sample1.MP4 (HEVC 8 bit) 211 fps/235 fps +11%


H264 decoding speed didn't change, HEVC 8 bit is roughly 10% faster than before. A HEVC 10 bit comparison didn't make sense since Skylake doesn't support 10 bit in hardware. I will check this later with a GTX 1080 comparison.

[CruNcher]

Where is the RyZen Bitstream Su talked about we can get publicly that they used for the Handbrake Transcoding AVC Demo
http://www.amd.com/en-us/innovations/new-horizon

can't find it ?

@yups

even if it's hybrid 10 bit decoding it makes a lot of sense to compare it with that 20x time power reduction 10w to 0.5w advertised ;)

[Yups]

i7-7700k HD 630 1150 Mhz / GTX 1080 1960-2000 Mhz
Rest of the system same as #1609


DucksTakeOff_2160p50.x264.CRF24.mkv (h264) 134 fps/100 fps
jellyfish-250-mbps-4k-uhd-h264.mkv (h264) 141/103 fps

LG_4K_View-the-Feeling.mp4 (HEVC 8 bit) 213/227 fps fps
bbb-3840x2160-cfg02.mkv (HEVC 8 bit) 191/240 fps fps
5_crowd_run_2160p50_300Mbps.mkv (HEVC 8 bit) 135/148 fps fps
4_yvid_SAM_0235-UHD_Sample1.MP4 (HEVC 8 bit) 235/189 fps


10bit_Astra.SES.Demo.HEVC.ts (HEVC 10 bit) 183/238 fps
Eutelsat.Demo.HEVC.ts (HEVC 10 bit) 230/239 fps
10bit_Samsung_UHD_Ride_on_Board.ts (HEVC 10 bit) 208/221 fps
UHD_PQ_Lovely_Swiss.ts (HEVC 10 bit) 205/226 fps
jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv (HEVC 10 bit) 81/83 fps


Out of 9 HEVC videos GTX 1080 wins 8 of them, averaged roughly 10% overall. Both are very fast. Intels HEVC decoding unit is really smart considering that Nvidia requires a 70% higher clock rate to achieve this result with Pascal.

As for H264 Intel is clearly faster, at least in these very high bitrate samples.

Are there any useful VP9 samples available?

[sneaker_ger]

"The World in HDR", VP9 8 bit, 2160p60, 24.9 Mbps:
youtube-dl (https://rg3.github.io/youtube-dl/download.html).exe -f 315 tO01J-M3g0U

"The World in HDR", VP9 10 bit, 2160p60, 18.2 Mbps:
youtube-dl.exe -f 337 tO01J-M3g0U

[CruNcher]

i7-7700k HD 630 1150 Mhz / GTX 1080 1960-2000 Mhz
Rest of the system same as #1609


DucksTakeOff_2160p50.x264.CRF24.mkv (h264) 134 fps/100 fps
jellyfish-250-mbps-4k-uhd-h264.mkv (h264) 141/103 fps

LG_4K_View-the-Feeling.mp4 (HEVC 8 bit) 213/227 fps fps
bbb-3840x2160-cfg02.mkv (HEVC 8 bit) 191/240 fps fps
5_crowd_run_2160p50_300Mbps.mkv (HEVC 8 bit) 135/148 fps fps
4_yvid_SAM_0235-UHD_Sample1.MP4 (HEVC 8 bit) 235/189 fps


10bit_Astra.SES.Demo.HEVC.ts (HEVC 10 bit) 183/238 fps
Eutelsat.Demo.HEVC.ts (HEVC 10 bit) 230/239 fps
10bit_Samsung_UHD_Ride_on_Board.ts (HEVC 10 bit) 208/221 fps
UHD_PQ_Lovely_Swiss.ts (HEVC 10 bit) 205/226 fps
jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv (HEVC 10 bit) 81/83 fps


Out of 9 HEVC videos GTX 1080 wins 8 of them, averaged roughly 10% overall. Both are very fast. Intels HEVC decoding unit is really smart considering that Nvidia requires a 70% higher clock rate to achieve this result with Pascal.

As for H264 Intel is clearly faster, at least in these very high bitrate samples.

Are there any useful VP9 samples available?

Please test the 4K Channel and Sony Camp Demos ;)

And show also the CPU Cores utilization data and active nodes on the HD 630

could you please force Quicksync into Software Decoding mode and check how Kaby-Lake at all performs their with Intels Decoder, and also with Lav Video :)

And does it hold that 1150 MHz entirely also while rendering ?

Some data so far their seems really interesting was this a review test system or did you have other tasks running that could have influenced your measurements ?

You used DXVAChecker ?

Anyway that will get really interesting in the new low power atoms especially vs Tegra P on 4K 60 Decode/Encode :D

[Yups]

Please test the 4K Channel and Sony Camp Demos ;)


Do you have a link?


And show also the CPU Cores utilization data and active nodes on the HD 630

I can do but the CPU utilization is basically zero. I could check however the power draw from the HD 630 with HWInfo.


And does it hold that 1150 MHz entirely also while rendering ?

Yes

Some data so far their seems really interesting was this a review test system or did you have other tasks running that could have influenced your measurements ?

No review system, just my personal computer at home.


You used DXVAChecker ?

DXVAChecker 3.14 was used.

[wanezhiling]

10-bit VP9 clips: https://yadi.sk/d/mADzsqUnzEYfk

[NikosD]

Can you test the "World in HDR" with your 1050 Ti ?

[wanezhiling]

My system is 'broken' again, no decoders are shown in dxva checker....

[NikosD]

Nvidia drivers ? :D

[eddman]

Intels HEVC decoding unit is really smart considering that Nvidia requires a 70% higher clock rate to achieve this result with Pascal.

What's the GPU utilization?

I don't see how clock comparison is relevant when it comes to HW video decoding. IINM, video blocks do not directly rely on GPU's clock speed.

Even if they do, a higher clock speed doesn't necessarily mean it's less efficient. It's just one factor among many.

For example, a stock Radeon 480 runs at 1266 MHz typical boost and a stock GTX 1070 at 1683 MHz, yet the 1070 uses less power in games and is faster too.

[NikosD]

So many mistakes in just one post that I have to reply and because I liked your last post.

What's the GPU utilization?

I don't see how clock comparison is relevant when it comes to HW video decoding. IINM, video blocks do not directly rely on GPU's clock speed.


As I have clearly shown, Intel's IGPU ASIC we call QuickSync and it's responsible for video decoding is directly connected with iGPU clock and its speed is proportional to iGPU's clock.

The overclocking of IGPU is so ridiculously easy - you just increase the multiplier - and free for everyone even the non-K CPUs like Core i7-4790 and Core i3-4170 that I had and have.

I always posted my HD 4600 results at 1.5GHz and now my HD 4400 of Core i3-4170 is at 1.3GHz.

The speed of those Haswells in H.264 HW decoding is proportionally faster than Kaby at 1.15GHz



For example, a stock Radeon 480 runs at 1266 MHz typical boost and a stock GTX 1070 at 1683 MHz, yet the 1070 uses less power in games and is faster too.

All Polaris cards are artificially over-volted probably because AMD wanted them to be overclocking friendly.

My RX 470 had 1.093V and asked for 130W in a particular game.

By under-volting to 0.985 using Wattman - a free and extremely easy tool inside the drivers - the power consumption went down to 85W on the same game and I overlocked the card at the same time from 1260MHz to 1300MHz (!)

Polaris can become extremely power efficient if you want to and AMD just buried them in that matter.

[eddman]

So many mistakes in just one post that I have to reply and because I liked your last post.

As I have clearly shown, Intel's IGPU ASIC we call QuickSync and it's responsible for video decoding is directly connected with iGPU clock and its speed is proportional to iGPU's clock.


I was relying on some old information from my memory that mentioned video blocks ran independently. That's why I wrote "IINM". I was mistaking.

Thanks for the clarification, but what about power efficiency? Pascal runs at a higher clock speed, but how much power does the video block consume?

Perhaps a video playback runtime test is in order? EDIT: on laptops. :D Do you know people in this thread with kaby lake and Pascal laptops?

All Polaris cards are artificially over-volted probably because AMD wanted them to be overclocking friendly.

My RX 470 had 1.093V and asked for 130W in a particular game.

By under-volting to 0.985 using Wattman - a free and extremely easy tool inside the drivers - the power consumption went down to 85W on the same game and I overlocked the card at the same time from 1260MHz to 1300MHz (!)

Polaris can become extremely power efficient if you want to and AMD just buried them in that matter.

How about Pascal cards? Can they be under-volted too, or they become unstable?

EDIT: It seems they can be stably under-volted too.

https://www.youtube.com/watch?v=CVOhBwJZQTI

This is just one example though. I suppose it could behave differently in different games.

[Yups]

What's the GPU utilization?


From both GPUs? Will check later.


I don't see how clock comparison is relevant when it comes to HW video decoding. IINM, video blocks do not directly rely on GPU's clock speed.


There is no separate clock domain for the VPU on Intel GPUs, that's why people always refer to the GPU clock.

LG_4K_View-the-Feeling

HD 630 500 Mhz= 94,5 fps
HD 630 1150 Mhz= 213 fps

230% higher GPU clock results in a 225% faster decoding speed, scales almost lineary. Bandwidth is a small factor, that's why it doesn't scale lineary.



Even if they do, a higher clock speed doesn't necessarily mean it's less efficient. It's just one factor among many.


I'm not talking about power consumption figures, haven't checked this out yet. Clock per clock Intels decoder is much more powerful and faster. Of course the end result matters but If I could decide I always would prefer the bigger unit with lower clocks, it's usually more efficient and could have long term benefits if for some reasons Nvidias next gen clocks are down to Maxwell levels, or even current gen benefits. For example mobile Pascal variants may not clock that high. Intels fastest desktop KBL clocks at 1150 Mhz, mobile variants roughly at 1000 Mhz. Clock dependency is much lower for Intel.

[eddman]

There is no separate clock domain for the VPU on Intel GPUs, that's why people always refer to the GPU clock.

Could you under-clock your 1080 and see how it affects the video performance? If it's been done before in this thread, do you remember a post?

I'm not talking about power consumption figures, haven't checked this out yet. Clock per clock Intels decoder is much more powerful and faster. Of course the end result matters but If I could decide I always would prefer the bigger unit with lower clocks, it's usually more efficient and could have long term benefits if for some reasons Nvidias next gen clocks are down to Maxwell levels, or even current gen benefits. For example mobile Pascal variants may not clock that high. Intels fastest desktop KBL clocks at 1150 Mhz, mobile variants roughly at 1000 Mhz. Clock dependency is much lower for Intel.

That's a good point, although it seems that Pascal's laptop variants aren't much slower than their desktop models.

Obviously video playback power consumption doesn't matter for desktops but it is something to consider for laptops, although I think intel have the edge there anyway, being integrated and whatnot. It'd be nice to have some battery tests while playing videos at their normal frame rates.

[huhn]

it is very unlikely that a dGPU can beat a iGPU in term of power consumption. PCIe transfer the size of the GPU other stuff...

but if you do power consumption comparison stop wasting your time with software TDP/watt measuring tools.

[Yups]

Could you under-clock your 1080 and see how it affects the video performance? If it's been done before in this thread, do you remember a post?



I don't know how to do this. I noticed there is also a GPU Video clock in HWInfo for the GTX 1080. Let's use this video with a similar decoding performance for Kabylake and Pascal:

jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv


Idle GTX 1080
GPU= 253 Mhz
GPU Video= 544 Mhz
GPU Power consumption= ~6W
Total system measured by Energy check 3000= ~50W

Decoding load GTX 1080
GPU= 1999.5 Mhz
GPU Video= 1708.5 Mhz
GPU Power consumption= ~51W
Total system measured by Energy check 3000= ~107W


Idle HD 630 (GTX 1080 is still attached as secondary GPU, means Idle power use from GTX 1080 is included here)
GPU= 150 Mhz
GPU Power consumption= less than 1W
Total system measured by Energy check 3000= ~50W


Decoding load HD 630
GPU= 1150 Mhz
GPU Power consumption= ~3W
Total system measured by Energy check 3000= ~61W


Idle-load delta is 11W for the entire system on my HD630 while on the GTX 1080 the delta is 56W.

[NikosD]

A lot of misunderstandings that I have to clarify


That VSR is still limited Hardware wise is a pretty heavy let down though it seems 4K is only invested into the Fiji based High cost Platform i guess where it makes more sense.

Though now i wonder if VSR works at least on the RX 480 in 4K like it did previously on the 390x didn't it ?



The hardware limitation of VSR it seems that it's not in the card but in the monitor, as I wrote in my previous post.

The first monitor with max 1680 x 1050 resolution went up to 2560 x 1600.
But my 2nd monitor with max 1920 x 1080 resolution went up to 3840 x 2160 using my RX 470

So, no problem using VSR


Very interesting information that you also hardly see in reviews :)

But reviews clearly show that the RX 470 is entirely optimized for the 1080p Edge not even really 2560x1600 overall, so it's not that surprising at all that it seems to brake down especially on 2560x1600 60 FPS HEVC Encoding a 4K output result scaled to that resolution @ 60 FPS at the same time which is heavy on everything, especially that whole thing Discrete in our case over the PCI-E 2 Bus you need some very efficient low latency compression ideas here and very efficient capturing from the OS Driver Level of course.

All in all enough RAW Power with clever ideas and perfect low level optimization not only limited to the Decoder/Encoder IP ;)


I have to clarify that when I started desktop recording of 2560 x 1600, I stopped it immediately when I saw the decoding of the clip at 4fps.

So, it's not the recorded video at 4fps but the decoding of the file when HEVC transcoding is used at VSR 2560 x 1600.

I'll check with my 2nd monitor at 3840 x 2160 the framerate of the recorded clip and post again.


PS: The HEVC 2560 Encoding indeed looks very jittery especially in the ballerina scenes but the problem can be many causes all that timers running make me headaches

There is no HEVC 2560 encoding, only AVC 2560 encoding.

The HEVC encoding of VSR 2560 is at 1080.

@NikosD

Could you try the Philips and the Channel 4k sample with EVR-SYNC once with the additional 3rd party hardware counter polling and once without (plain desktop) ?

http://demo-uhd3d.com/fiche.php?cat=uhd&id=135


I will do it on my 2nd monitor at 1920 x 1080, but since the card has gone to its owner, I don't know when I'll do the test.

What do you mean EVR-SYNC by the way ?

[eddman]

I don't know how to do this. I noticed there is also a GPU Video clock in HWInfo for the GTX 1080. Let's use this video with a similar decoding performance for Kabylake and Pascal:


Thanks for the test. You mean that when you under-clock the 1080, its video clock speed doesn't change?

Yea, comparing desktop power consumption isn't really useful, since there is an entire card that needs to be powered vs. an integrated solution.

I did know that there is a difference but didn't expect it to be this big.

What was the GPUs and also video engines loads? Could you also play the video at its native frame rate and compare that?

[CruNcher]

I don't know how to do this. I noticed there is also a GPU Video clock in HWInfo for the GTX 1080. Let's use this video with a similar decoding performance for Kabylake and Pascal:

jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv


Idle GTX 1080
GPU= 253 Mhz
GPU Video= 544 Mhz
GPU Power consumption= ~6W
Total system measured by Energy check 3000= ~50W

Decoding load GTX 1080
GPU= 1999.5 Mhz
GPU Video= 1708.5 Mhz
GPU Power consumption= ~51W
Total system measured by Energy check 3000= ~107W


Idle HD 630 (GTX 1080 is still attached as secondary GPU, means Idle power use from GTX 1080 is included here)
GPU= 150 Mhz
GPU Power consumption= less than 1W
Total system measured by Energy check 3000= ~50W


Decoding load HD 630
GPU= 1150 Mhz
GPU Power consumption= ~3W
Total system measured by Energy check 3000= ~61W


Idle-load delta is 11W for the entire system on my HD630 while on the GTX 1080 the delta is 56W.

So we have a Decoding load on the Card Subsystem of 56W for 4K 400 mbps ?
Not sure if those measurements though are that reliable with a power wall plug measurement but obviously vs the dgpu efficiency no chance but as huhn said this was pretty clear from the beginning,

Though on P1 we only have 256 shaders that will lower power out under full load also a lot same for the atom version of the HD 630 it will have fewer EUs and the P1 will have the same Core Decoding state as the 1050 ti VPX.

They overall gonna calculate reaching those 60 FPS.


So it would be nicer if measurements are not done in Benchmark Mode but Realistic Playback Scenario (with 4K Render overhead) also then 400 mbps is insane out of avg consumer reality

Not 1 TV Manufacture releases a Demo at such a overall Bitrate complexity level , it's a nice test file surely but has 0 todo with reality, avg consumer reality starts with UHD Blu-Ray, Broadcast and Web not with jellyfish 400 mbps ;)

Many avg consumer will be already absolute happy being able to transcode in Realtime 3x realtime is surely nice but not really the mass market target, lowering power consumption to the maximum at those 60 FPS and one 4K Output is the next big goal :)


Avg Consumer (Sony, Microsoft, AMD, corporate Console target)
Gamers (Avg Consumer with Premium targets, also partly establishes even in the Console world) <- heavily exploded in prices and insane products over the last years a bubble to blow (mostly putting a led on something and selling it for a big uptake)
Pro Summer
Professionals

Gamers can also be devided in the sub target group of overcliockers and a new established target group "Streamers".

A lot of misunderstandings that I have to clarify



The hardware limitation of VSR it seems that it's not in the card but in the monitor, as I wrote in my previous post.

The first monitor with max 1680 x 1050 resolution went up to 2560 x 1600.
But my 2nd monitor with max 1920 x 1080 resolution went up to 3840 x 2160 using my RX 470

So, no problem using VSR



I have to clarify that when I started desktop recording of 2560 x 1600, I stopped it immediately when I saw the decoding of the clip at 4fps.

So, it's not the recorded video at 4fps but the decoding of the file when HEVC transcoding is used at VSR 2560 x 1600.

I'll check with my 2nd monitor at 3840 x 2160 the framerate of the recorded clip and post again.



There is no HEVC 2560 encoding, only AVC 2560 encoding.

The HEVC encoding of VSR 2560 is at 1080.



I will do it on my 2nd monitor at 1920 x 1080, but since the card has gone to its owner, I don't know when I'll do the test.

What do you mean EVR-SYNC by the way ?

yes that rescaled 1080p output it shows playback jitter that isn't recognized by the graph really EVR-SYNC is less forgiving in that it will either droop the frames and depending in how high and long the duration of the jitter that can become very critical upto displaying nothing at all or cause a peakdown if the jitter can be compensated fast enough as you see in the FPS difference for that 24 fps philips sample alternating up and down up and down on the 60 Hz refresh :)

you might see those jitter as a 1 ms difference but it's latency before display is bad the Graph is overall more reliable EVR-CP/EVR-SYNC recognizing these issues and here EVR-SYNC espeicialy as it will be less forgiving and show immediately a peakdown for every 1 ms discontinuity :)

Though in your case i guess the frames where dropped on the recording side not on the playback side at all like you also seem to recognize the 4fps render result being entirely recording efficiency related when scaling up to 2560 and recording it in native res with the HEVC Encoder at the 59 hz DWM output but as i said even the 1080p recording at that 15 mbps now shows issues but with that hwinfo and the graph display gadget all firing so many timers it could be very normal. also depending on the power management state, its Windows after all.

Though we shouldn't forget that it's Sandy Bridge and i think since Skylake intel took over it from Microsoft and could also improve counter reading overhead when frequency scaling or even core parking which was a big issue for Realtime 3D causing timer issues, i guess though you had core parking disabled ?.


I will show you where exactly i see issues @ playback so others might be able to confirm or i find a problem on my side ;)

We talking about

MPC-BE_Channel4K_VSR_to_1080_HEVC.mp4

just to be sure :)

i can see 3 very problematic areas that i cant pinpoint yet as playback issues on my side @ 59 Hz (actually not as timer issues, therfore its to stable repeating each run).

1) Choppy Head Motion

http://i1.sendpic.org/t/3L/3LYQki8MgeTQWkQBF9KxkWEuqve.jpg (http://sendpic.org/view/1/i/7Lh9O6BogLdZWy1q58Ume1I87sQ.png)

2) Choppy Air Throw

http://i1.sendpic.org/t/ry/ryJWALTaMpH6x6abxSohmVwYXOs.jpg (http://sendpic.org/view/1/i/dwR37dkPs4C6PMe7XC0Iv0kckU4.png)

3) Choppy Rotation Movement (not 100% sure about this though)

http://i1.sendpic.org/t/yy/yyMLnncysFcBNmqnpIHxgaqPYuq.jpg (http://sendpic.org/view/1/i/wo7bOWBH14NbL1gg6IVpTVhHNNp.png)

Dont be surprised it's nearest neighbour i want to be absolutely sure that everything is as low overhead as possible (internally).

The glitch count was a test between CUVID and avcodec first to run with Lav Video (avcodec) 2nd with Lav Video (CUVID) on the CUDA Decoder.

[Yups]

So it would be nicer if measurements are not done in Benchmark Mode but Realistic Playback Scenario (with 4K Render overhead) also then 400 mbps is insane out of avg consumer reality



Power consumption is much higher even in playback with MPC. Difference depends on the video, power consumption with HD 630 sits between 55-60W during playback with my sample videos. GTX 1080 has bigger fluctuations, 85W or even 100W in some 4K videos, smaller videos can be below these figures.

[huhn]

+50 watt is pretty bad...

[eddman]

Power consumption is much higher even in playback with MPC. Difference depends on the video, power consumption with HD 630 sits between 55-60W during playback with my sample videos. GTX 1080 has bigger fluctuations, 85W or even 100W in some 4K videos, smaller videos can be below these figures.

Really want to see its GPU utilization numbers. Theoretically, it should be very low.

If it consumes that much even for consumer level HEVC videos, then it sure is odd.

According to TPU's review, a stock 1080 consumes about 7W while playing a blu-ray, in a scene that goes up to 40 Mbps.

https://www.techpowerup.com/reviews/NVIDIA/GeForce_GTX_1080/24.html

If it's efficient while playing h.264, then why can't it do the same for HEVC? Did nvidia get HEVC decoding wrong?

Could you test one or two h.264 videos and measure the power draw?

[CruNcher]

Power consumption is much higher even in playback with MPC. Difference depends on the video, power consumption with HD 630 sits between 55-60W during playback with my sample videos. GTX 1080 has bigger fluctuations, 85W or even 100W in some 4K videos, smaller videos can be below these figures.

This was for DXVA Native zero copy on plain EVR ?

Anyway such Wall Plug measurements wont bring us far it's to fast switching we need higher resolution like only the most advanced reviewer have measuring at those.

Please show the Node usage of the GTX 1080 for LG View the Feeling and Crowd run

[nevcairiel]

I don't think comparing power usage of a huge high-performance GTX 1080 with a tiny iGPU is really a fair comparison in any sense (or even very meaningful). Just powering the GPU to run on medium or high clocks without load will use way more power then even the iGPU at full load.
It generally also depends what kind of player and video renderer you use, as that can have a huge impact on which power level the GPU runs in.

[CruNcher]

Sure more efficient would be a compare especialy with the 1050 which VPX will also land in the P1

At the End there will stay x86 ATOM Celeron vs ARM P1 ;)

Nintendo Switch could become a nice Media Player ;)

Or we might see a new revision of the Android Shield and Nvidias Streaming service update to VP9 or H.265, which still could be deployed backward compatible for both and theoretically a deal with Nintendo could also be arranged vs Sonys Streaming service :)

Though im not sure if Nvidia would get the Deal to get Nintendo Games on their Cloud Platform for PC Gamers (Inside the Geforce Experience Ecosystem) or even their Shield users technically obviously absolutely possible but i guess Nintendo wont do it for their "Exclusive titles" ;)

But Nintendow Switch surely will get a GameStream App to the PC that's as clear as kloßbrühe, interesting question will Nvidia supply it and slowly try to also reach AMD users with it ;)

[eddman]

It generally also depends what kind of player and video renderer you use, as that can have a huge impact on which power level the GPU runs in.

I was thinking the same and searching the web for some info. If Pascal's video engine sits in its own clock domain, then the GPU itself (shaders, etc.) should not have to run at full 3D clocks, if you're only playing a video with full HW decoding.

The card alone consuming 30-50W power just for HW decoding doesn't seem right.

Sure more efficient would be a compare especialy with the 1050 which VPX will also land in the P1


So far all Pascal chips (except for GP100) have the same feature set H video engines, unless nvidia made a mistake in its documents. I really doubt 1050 has a different video block. The VP9 profile 3 support that we are seeing is probably due to drivers, just like the missing VP8 support for GP102 based Quadro and Tesla. Don't know about Titan X P, since there is no info on nvidia's website.

[CruNcher]

I was thinking the same and searching the web for some info. If Pascal's video engine sits in its own clock domain, then the GPU itself (shaders, etc.) should not have to run at full 3D clocks, if you're only playing a video with full HW decoding.

The card alone consuming 30-50W power just for HW decoding doesn't seem right.



So far all Pascal chips (except for GP100) have the same feature set H video engines, unless nvidia made a mistake in its documents. I really doubt 1050 has a different video block. The VP9 profile 3 support that we are seeing is probably due to drivers, just like the missing VP8 support for GP102 (Titan X).


Feature Set aren't worth much footnotes are, though i agree with you the power measurements look insane so far.

Because it wont work at all efficient in the Mobile Pascal Platforms and they would be empty in no time ;)

As im not able to measure such high resolutions i myself prefer measuring heat and fan speed and actual noise levels instead and their correlation ;)

As the PWM Systems are very fast reacting lower then the OS level and reading those performance counters doesn't influence so heavily at least via NVAPI if you don't over pressure the pooling ;)

VPX was in the beginning a 400 MHz clocked domain by now it should have roughly reached 500 MHz

Btw i really like to compare Nvidias SOA with Cheap under 100$ Chinese ARM SOC IP solutions ;)

[eddman]

Feature Set aren't worth much footnotes are

Please use punctuation marks. Reading your comments are rather hard.

Yes, the footnotes say "limited to select Pascal chips", but we don't know which chips, and even then, it might just be a driver limitation.

I think it'll all become clear once Video Codec SDK 8.0 is released. If it turns out that GP107 actually has a better video block, then I'd be somewhat pissed at nvidia for misleading us.

[Yups]

Really want to see its GPU utilization numbers. Theoretically, it should be very low.

If it consumes that much even for consumer level HEVC videos, then it sure is odd.

According to TPU's review, a stock 1080 consumes about 7W while playing a blu-ray, in a scene that goes up to 40 Mbps.

https://www.techpowerup.com/reviews/NVIDIA/GeForce_GTX_1080/24.html

If it's efficient while playing h.264, then why can't it do the same for HEVC? Did nvidia get HEVC decoding wrong?

Could you test one or two h.264 videos and measure the power draw?


I can see this low power draw in several videos in my collection, also several with an exorbitant high power draw. As far as I can see it really comes from the Video Engine because GPU load stays very low. HWinfo log is messy unfortunately and GPUz doesn't display/log some things like GPU Video clock or GPU Power (TDP only).

[CruNcher]

you could lower your overhead using Process Hacker and it's Node View for looking up the domain states utilization

What for a GTX 1080 you have exactly ?

Are you running in a GPU Mixed config or is the Nvidia Card the Primary (intel igpu bios disabled) ?

Your Power Management setup CPU/GPU ?

OS i guess Windows 10 ?

Which samples give you the highest power draw highest VPU utilization ?

LGE View the Feeling should be pretty darn low same for NikosD AMD VCE recordings, the DIVX Profile samples also very low.

Dont forget the 400 mbps and have you not seen samples also gonna suck power from other subsystems ;)

If you want to be sure only 1 part is fixed consuming and avoid extra latency move the entire sample into the Ram (Ramdrive) or on a SSD always prefer the ramdrive though.

[NikosD]

"The World in HDR", VP9 8 bit, 2160p60, 24.9 Mbps:
youtube-dl (https://rg3.github.io/youtube-dl/download.html).exe -f 315 tO01J-M3g0U

"The World in HDR", VP9 10 bit, 2160p60, 18.2 Mbps:
youtube-dl.exe -f 337 tO01J-M3g0U
Very nice way to download VP9 10bit from YouTube and probably the only way if you have a non HDR monitor like me and the majority of people.

Because when Youtube sees a non HDR monitor automatically offers VP9 8bit only streams, so it's impossible to download the 10bit streams from Youtube directly.

[Yups]

LG_4K_View-the-Feeling power draw is low after 5-10 seconds of playback. In contrast UHD_PQ_Lovely_Swiss is way higher.