LAV Filters - DirectShow Media Splitter and Decoders

[CruNcher]

I can fully understand that decision though these frequency shift "glitches" can be not only small but they can become freaking huge with DXVA Native

13 ms



0.4 ms

[nevcairiel]

You are testing a hybrid decoder though, due to their high CPU usage they behave a bit more unusual than actual hardware decoders.

[huhn]

the issue could be the renderer too. hard to judge from a simple screen without knowing the exact renderer. it's an EVR renderer that's all i know.

[clsid]

Is using the CUDA API enough to force P0? Or must you actually also do something with it besides initialization? If not, it could optionally be used by madVR and EVR-CP as a means to provide more stable playback.

[CruNcher]

Originally Posted by nevcairiel

You are testing a hybrid decoder though, due to their high CPU usage they behave a bit more unusual than actual hardware decoders.

Ah come on that CPU usage is pretty much a joke compared to the complexity and Firefox is running in the background also, sure OpenHEVC isnt far from it and you shouldn't forget you aren't using 0 copy



Though HEVC is not AVC and it is much better Shader optimizeable Nvdia took that chance to try it and doesn't keep the Performance Line user completely in the Dust with CPU Decoding and the results aren't that bad @ all for a Hybrid using parts of the VP6 AVC SIP Block sure the GM206 smokes it with it's complete 10 bit SIP Block of VP7

This is a typical Nvidia Design Strategy only the Cards get the full SIP Block where it's economical for them @ the Time so all the Maxwell Mobiles will have the VP7 SIP Block like X1 (Nvidia Shield Android TV Console) has it and the GM206 as a Low Power HTPC Product.

And this time Intel Adapted to this Strategy as well only AMD didn't they pushed once again everything into their Chip economical or not

4K HEVC Results Beauty 30 FPS (Realtime Playback)

Bit rate : 12.3 Mbps
Maximum bit rate : 17.4 Mbps

Lav Decoder (OpenHEVC 8bit) = AVG 40% CPU (Sandy Bridge 4C)
Nvidia VP6 HEVC Hybdrid Decoder 8 bit = max 17% CPU (generic copy)

And yes im fully aware of the Power/GPU/CPU Balance (P0 State Voltage increase) but that's not part of the testing for now (most user of these Gamer Cards don' t care about power @ all)

[NikosD]

Originally Posted by CruNcher

Though HEVC is not AVC and it is much better Shader optimizeable Nvdia took that chance to try it and doesn't keep the Performance Line user completely in the Dust with CPU Decoding and the results aren't that bad @ all for a Hybrid using parts of the VP6 AVC SIP Block sure the GM206 smokes it with it's complete 10 bit SIP Block of VP7

This is a typical Nvidia Design Strategy only the Cards get the full SIP Block where it's economical for them @ the Time so all the Maxwell Mobiles will have the VP7 SIP Block like X1 (Nvidia Shield Android TV Console) has it and the GM206 as a Low Power HTPC Product.

And this time Intel Adapted to this Strategy as well only AMD didn't they pushed once again everything into their Chip economical or not

Not sure about Nvidia, but pretty sure about Intel that for hybrid decoding of HEVC 8bit, doesn't use any of the QuickSync fixed-function blocks.

Because during hybrid HEVC decoding on Haswell, the usage of QuickSync HW decoding block is dead zero 0%.

[CruNcher]

Not the case for Nvidia 1 Part of the VPU Engine is active Node 6,Engine 6 not much though Node 3,Engine 3 is completely silent, this doesn't get exposed via NVAPI indeed hmm maybe though Node 6,Engine 6 is the cuda copy part



Ok indeed it seems to be even completely shader based no SIP Block sharing as i assumed first.



As nevcariel said now it makes perfect sense why DXVA fails with those frequency fluctuations keeping it stable

But what is Node 6 it's not the MCU

[huhn]

Originally Posted by clsid

Is using the CUDA API enough to force P0? Or must you actually also do something with it besides initialization? If not, it could optionally be used by madVR and EVR-CP as a means to provide more stable playback.

CUVID forces P0 i don't know why.

there are other ways to get P0.

@CruNcher

have you made sure the issue isn't with the EVR renderer from MPC-BE?

and why is the resizer NN?

[CruNcher]

DSR does the overall scaling currently

[huhn]

no it doesn't.

[CruNcher]

Originally Posted by huhn

no it doesn't.

Im pretty sure i see no impact no matter which scaler i chose on anything.











So either they are all broken or Nvidias DSR overides them all

And when you think in Nvidias Logic (if we have a superior scaling algorithm why should we keep everyone else running and causing troubleshoot problems)

it isn't really surprising

One of the 8 bit Samples where everything brakes apart currently 46.4 Mbps



Though some of the parts play fine but most 30 ms or more (watching out for Driver improvements)

OpenHEVC handles this stream much much better on the 4 Cores




I guess 40% OpenHEVC equals roughly what Nvidias Shader Decoder can playback currently 80% is 2x more complex guess the Decoder will die practically everywhere OpenHEVC drives 80% CPU results or dies itself.

[Mangix]

Originally Posted by nevcairiel

Talk to any Linux developer where they have to implement one API for every GPU vendor, its absolute pain.

Everyone uses VDPAU nowadays. Everything else seems to have died.

[nevcairiel]

Originally Posted by Mangix

Everyone uses VDPAU nowadays. Everything else seems to have died.

Thats not true. VAAPI is still very much alive, and Intel doesn't support anything else.

[huhn]

@CruNcher
that's your screen.
http://sendpic.org/view/2/i/1d7snQ8C...V9VjNt6DuO.png

can you stop trolling please?

[foxyshadis]

Originally Posted by nevcairiel

Thats not true. VAAPI is still very much alive, and Intel doesn't support anything else.

The nice thing about VDPAU, though, is that it can translate transparently to VAAPI, whereas the reverse definitely isn't true.

[nevcairiel]

Originally Posted by foxyshadis

The nice thing about VDPAU, though, is that it can translate transparently to VAAPI, whereas the reverse definitely isn't true.

From what I'm told that doesn't work that well..

[CruNcher]

Originally Posted by huhn

@CruNcher
that's your screen.
http://sendpic.org/view/2/i/1d7snQ8C...V9VjNt6DuO.png

can you stop trolling please?

And what do you want to say with that the source is highly compressed the output result is fast and it looks the same nothing artificialized you could still run a sharpener over it if you need it but the overhead is still lower in any case.

Or do you think this looks bad also as its native downscaled,upscaled

[huhn]

you post a UHD video at UHD can you plz stop kidding...

[P.J]

Originally Posted by CruNcher

And what do you want to say with that the source is highly compressed the output result is fast and it looks the same nothing artificialized you could still run a sharpener over it if you need it but the overhead is still lower in any case.

Or do you think this looks bad also as its native downscaled,upscaled

+10MB for a screenshot?

[CruNcher]

Its the entire Framebuffer