LAV Filters - DirectShow Media Splitter and Decoders [Archive] - Page 388

ksio89

13th July 2015, 15:18

Why is HW acceleration not working with nVidia CUVID decoder? Only intel QS and DXVA2 native/cb are working. CUVID decoder is selected for all compression standards and yet is not being activated.

I selected CUVID in both internal MPC-HC and external LAV video filters, activaed first internal and then external but it didn't work with either one. I'm using DXVA2 native as a workaround decoder for HW acceleration.

When CUVID decoder is selected, the active decoder is avcodec. I'm using K-lite Full Codec Pack 11.2.7. Would be glad if someone instructed me on how enable CUVID decoder. Thanks in advance.

Info:

CPU: Intel core i5-4210U
OS: Winodws 8.1 Core x64
GPU: nVidia GeForce 840M (PureVideo HD VP6/VDPAU feature set E)
MPC-HC: 1.7.9.30
LAV Filters: 0.65.0.20

nevcairiel

13th July 2015, 15:19

Optimus is weird, don't hope for any improvements.
Just use DXVA2-CopyBack, its better than CUVID anyway.

ksio89

13th July 2015, 15:44

Thanks for the reply. I use DXVA2 native because the CPU usage is way lower than with DXVA2 copy-back (direct) or Intel QS HW decoder, especially when playing UHD videos in H.264.

I have another laptop with a Radeon HD 8870M, with AMD Enduro technology which is similar to nVidia Optimus, and DXVA2 native decoder gives me lower CPU usage as well. Thanks for the help :)

nevcairiel

13th July 2015, 15:44

CUVID is similar to CopyBack, so it would result in higher CPU usage as well.
If you can use Native in your setup, then do that, its going to be the most efficient - although not always compatible with everything.

mbordas

14th July 2015, 21:01

I'm getting a weird crash from certain files with cuvid (this is with mpc-hc). Switching to dxva avoids it and it sounds like I should be doing that anyway?

WARNING: Following frames may be wrong.
nvcuvid+0x91d67
lavvideo!CDecCuvid::CreateCUVIDDecoder+0xa3
lavvideo!CDecCuvid::InitDecoder+0x586
lavvideo!CDecodeThread::CreateDecoderInternal+0x4ef
lavvideo!CDecodeThread::ThreadProc+0xc3
lavvideo!CAMThread::InitialThreadProc+0x36
lavvideo!_beginthreadex+0xb4
lavvideo!_endthreadex+0x102
kernel32!BaseThreadInitThunk+0xe
ntdll!__RtlUserThreadStart+0x2b
ntdll!_RtlUserThreadStart+0x1b

nevcairiel

14th July 2015, 21:03

The crash is in the NVIDIA driver (nvcuvid), not much I can do about those.
But yeah I generally recommend DXVA2 over any of the other modes.

Dogway

15th July 2015, 04:11

Is there a place where I can read what condition must a video meet to be hardware accelerated with DXVA2, and Quicksync? I recall DXVA requiring L4.1 or below I don't remember. I'm trying to figure out if a Intel HD 6100 (from Intel NUC) can render 1080p video or scale up to 1080 with madVR using nnedi3 doubling + lanczos.

huhn

15th July 2015, 10:23

it depends on the GPU it self.

if will be able to decode a blu ray spec video for sure.

nevcairiel

15th July 2015, 10:35

Most recent GPUs can decode the majority of valid Main/High profile videos, that means 8-bit and 4:2:0 only.
If its 1080p only and not higher resolutions, then even better and even more hardware will be capable.

Dogway

15th July 2015, 10:41

I see, so QuickSync doesn't accept 10-bit.
I was reading here (http://www.missingremote.com/review/intel-nuc-kit-nuc5i5ryk-mini-pc). It seems we are still far for NNEDI3 in Intel iGPU, what a let down. I thought NNEDI was CPU, offloading work for QuickSync which is busy decoding the video.

huhn

15th July 2015, 11:22

why should you use quicksync when the only GPU is intel?

DXVA is a more stable choice and has at least the same speed.

romulous

15th July 2015, 13:12

I have been testing the re-written asf/wmv demuxer from Libav, and it seems to seek OK in this sample.

I'll probably enable it in the next nightly build, so testing would be appreciated, ideally beyond seeking, as it is very new and may still have other short-comings that need fixing.

Can confirm that the sample file is fixed in the nightly. I think I have seen a few other videos posted hereabouts for this particular problem - will see if I have them in my collection to run some more videos through it.

romulous

CruNcher

15th July 2015, 14:45

hmm it's strange i experience currently something which is hard to explain

the Beauty Retranscode from the HEVC Decoder Benchmark tests is giving me strange results with Maxwells Decoder on the GTX 970 with LAV DXVA Native it has playback issues that aren't visible (stuttering) with DXVA Copy Back Direct nor CUDA i find that pretty strange ?

Beauty_3840x2160_120fps_420_8bit_HEVC_MP4.mp4

The jittering is much higher and uneven with DXVA Native and full Lav Filter Chain

http://abload.de/thumb/copybokfbbd2.jpg (http://abload.de/image.php?img=copybokfbbd2.jpg) http://abload.de/thumb/dxvanativenbxl6.jpg (http://abload.de/image.php?img=dxvanativenbxl6.jpg)

The frame lose is also strange, though MPC-HC seems to have a big problem with the OSD and several interactions which causes spikes in the OSD Rendering of EVR Custom.

For example a Volume Change the Graph also detects a jitter explosion the second of the EVR OSD call.

MPC-BE seems not to have that problem with it's EVR Custom OSD Rendering though.

But that seems to be mostly a different issue then from the the DXVA Copyback/Native jittering visible here though it could depend on each other in some way.
But generally these "Beauty Test Scene" is strange in all ins incarnations (wouldn't surprise me if it's rather strange muxed) it's floating around no idea who did this but the naming convention the actual data doesn't even correlate really (urgh)

http://abload.de/thumb/beautygeyj2.jpg (http://abload.de/image.php?img=beautygeyj2.jpg)

mbordas

15th July 2015, 16:24

If I enable DXVA native or CB, it then uses DXVA for chroma upscaling, overriding whatever alogrithm is selected in madVR? Is this correct? If so, is this really the best option?

nevcairiel

15th July 2015, 16:25

If I enable DXVA native or CB, it then uses DXVA for chroma upscaling, overriding whatever alogrithm is selected in madVR? Is this correct? If so, is this really the best option?

That only applies to Native decoding, and that is a question for madVR. - And it has an option to disable this.

P.J

15th July 2015, 16:58

Hybrid HEVC solution had never worked fine for me, lots of jitters...

Anyway to use the standard EVR resizer (DXVA scaler) when using EVR-CP?

mbordas

15th July 2015, 18:08

That only applies to Native decoding, and that is a question for madVR. - And it has an option to disable this.

ah yes, thanks. Apparently it happens with CB as well, but only for low res content like 720x480. But I see the options are under "trade quality for performance", that's why I missed them.

huhn

15th July 2015, 18:25

Hybrid HEVC solution had never worked fine for me, lots of jitters...

Anyway to use the standard EVR resizer (DXVA scaler) when using EVR-CP?

no only madVR and EVR can use DXVA scaling in mpc-hc right now.

XinHong

15th July 2015, 20:05

Maybe MPDN can do it now with the DXVA HD Scaler (https://github.com/zachsaw/MPDN_Extensions/wiki/DXVA%20HD%20Scaler) extension

RenderGuy2

16th July 2015, 02:49

The only thing that still seems really weird to me is that in one clip the upper 25% of the bit range is empty, in the other 30% is empty (ie on a 0-255 scale the white point for one clip is 191ish, the other is 180ish).

The SMPTE 2084 3DLUT I made still expects the brightest tone to be 255 (or 1023 for 10bit).

Not sure if anyone is interested in HDR, but I have done a little more research and I'm fairly certain that LAV decoder is working well with these samples. The reason that the upper portion of the bit range is empty is because the SMPTE 2084 (PQ) EOTF is designed for displays outputting up to 10,000 cd/m^2, mastering/consumer displays are not nearly that bright yet, so the upper portion of the bit range is reserved for the brighter displays of the future. On a 0-255 scale a value of 191 would correspond to about a 974 cd/m^2 display. 180 would correspond to about 656 cd/m^2.

I guess the way to display these samples (if you have a bright enough display) is to multiply by a constant (after converting to RGB) to clip the source at its mastering luminance and then build a rec2020 3dlut that uses the correct portion of the PQ EOTF (this can be done with dispcalGUI). Hopefully in the future LAV will be able to read metadata with information about luminance and color-space and pass it on to the renderer.

huhn

16th July 2015, 03:59

i guess waiting for the first couple of UHD BDs is the way to go for now.

but nice to see a way to use HDR on a none HDR TV.
even some older and cheap TV can reach 400 cm². using dispcalGUI and some tricks it could be used for HDR up to 400 cm².

P.J

16th July 2015, 15:26

Maybe MPDN can do it now with the DXVA HD Scaler (https://github.com/zachsaw/MPDN_Extensions/wiki/DXVA%20HD%20Scaler) extension

How to use it?

XinHong

16th July 2015, 19:34

It's a bit off-topic but you have to download from the front page (http://forum.doom9.org/showthread.php?t=171120):
- the x86 or x64
- MPDN Extensions Binaries

Unzip/install the application and unzip the extensions in the app folder.

Then you have to select DXVA HQ Render in the Render Script submenu:

http://img15.hostingpics.net/pics/342993Capture.png

e-t172

16th July 2015, 19:40

Not sure if anyone is interested in HDR, but I have done a little more research and I'm fairly certain that LAV decoder is working well with these samples. The reason that the upper portion of the bit range is empty is because the SMPTE 2084 (PQ) EOTF is designed for displays outputting up to 10,000 cd/m^2, mastering/consumer displays are not nearly that bright yet, so the upper portion of the bit range is reserved for the brighter displays of the future. On a 0-255 scale a value of 191 would correspond to about a 974 cd/m^2 display. 180 would correspond to about 656 cd/m^2.

I guess the way to display these samples (if you have a bright enough display) is to multiply by a constant (after converting to RGB) to clip the source at its mastering luminance and then build a rec2020 3dlut that uses the correct portion of the PQ EOTF (this can be done with dispcalGUI). Hopefully in the future LAV will be able to read metadata with information about luminance and color-space and pass it on to the renderer.

That's quite interesting. I guess with displays that have sufficient contrast ratio the correct thing to do would be to use the GPU gamma ramps (3x1D-LUTs) to make sure the Windows desktop stays at a comfortable luminance, and then disable the gamma ramps while using madVR so that a HDR-specific 3DLUT can take over and do its magic in the HDR range for videos that announce the correct colorspace.

Am I right in assuming 10-bit becomes a basic requirement for this stuff? Otherwise the banding would become much more pronounced.

nevcairiel

16th July 2015, 20:11

Actually that analysis seems incomplete at best. The way HDR works is that extra metadata is provided to indicate the luminance range, so leaving part of the coded range empty instead of using the metadata seems like a weird thing to do.
In any case, we'll see what we can do about HDR in the future, so that it at least looks decent with madVR on a non-HDR screen. Proper support for HDR screens would be the icing on the cake, but sending such metadata to the display may prove challenging. I know there is API in the NVIDIA SDK to send arbitrary data over HDMI, but I have no idea if it actually works - and it would still be GPU specific. We'll see!

e-t172

16th July 2015, 22:07

I just did some research and I think I see what RenderGuy2 is talking about. A Google search finds two different approaches to HDR: the "double layer camp" (Dolby Vision (http://www.dolby.com/us/en/technologies/dolby-vision/dolby-vision-white-paper.pdf)) and the "single layer camp" (BBC WHP 283 (http://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP283.pdf)).

The former seems to advocate for a vast and complex processing pipeline including weird layered bistream formats and proprietary technologies, while the latter describes a way of "shoehorning" higher dynamic range into existing BT.709 infrastructure by using clever tricks to exploit the additional codes provided by 10-bit formats. The former aims to achieve the highest possible quality at a high complexity cost, while the latter aims to achieve the best quality/compatibility tradeoff to leverage existing systems. Another difference is that the Dolby paper seems to advocate using absolute luminance (as opposed to relative luminance which is what everyone has been working with since the dawn of time), while the latter sounds very skeptical on this topic, again for compatibility reasons.

The BBC paper is a very interesting read; I can definitely relate to the authors when they lament about the sad state of the current EOTF (gamma) standards in section 6.

When it comes to LAV and madVR, the single-layer approach could probably be supported with no changes to LAV and by loading an appropriate 3DLUT in madVR (or waiting for madshi to support the proposed EOTF based on bitstream metadata), as I mentioned in my previous post. The double-layer approach, however, would probably require massive changes to the entire pipeline. In a way the Dolby Vision proposal has the same issue as Dolby Atmos: it just steamrolls over "legacy" infrastructure with complete disregard to compatibility concerns and forces implementers to introduce massive complexity into their systems (not to mention patenting and licensing issues). That said, one could probably find ways to convert a double-layer stream into a single-layer one with little loss of information near the start of the pipeline.

Anyway, I think the best thing to do right now is "wait and see", as nevcairiel said. Both articles seem to have been published in 2014 - the paper is still warm, and if history is any indication, the video world moves very slowly when it comes to significant workflow changes.

nevcairiel

16th July 2015, 22:21

In a way the Dolby Vision proposal has the same issue as Dolby Atmos: it just steamrolls over "legacy" infrastructure with complete disregard to compatibility concerns and forces implementers to introduce massive complexity into their systems (not to mention patenting and licensing issues).

I think you got that backwards. Both Dolby Atmos and Dolby Vision work perfectly on a system not aware of them, they just don't make use of any new data. If you want to support any new tech, you need to add more complexity - but these two allow you to simply opt-out if you wanted to.
FWIW, the Dolby Vision extra layer is a normal feature of HEVC, so its not that crazy.

For HDR, the alternative for Blu-ray is SMPTE 2084 and SMPTE 2086, which is not backwards compatible, and will give you a really terrible image on unaware players.

The UHD Blu-ray spec has SMPTE 2084/2086 as mandatory features, and Dolby Vision as optional, which ties into their compatibility. Any UHD Blu-ray certified player needs to be able to deal with the HDR discs at some level.

Anyway its pointless to discuss this here. LAV will only ever decode the video and not process it.
In the future it'll also pass on the SMPTE 2084 metadata from the HEVC bitstream to any renderer that wants it, and thats that for me.

RenderGuy2

17th July 2015, 04:09

leaving part of the coded range empty instead of using the metadata seems like a weird thing to do.

Agreed! I certainly could be misinterpreting, but it looks as though it may actually work this way as far as the code range goes, very different from standard gamma encoding. The good news is the SMPTE 2084 curve is so deep that roughly the first half of the coded range is devoted to the luminance range from 0ish to 100cd/m^2, so you still get roughly twice the number of gray-scale steps in this range than you do from a normal 8-bit encode. The range from 5000 to 10,000 cd/m^2 only uses the last 7% of the code range. Apparently we're not very good at seeing changes in luminance from bright sources. Here's the full curve:

14892

It gives us lots of bits for dark tones. Anyway, interesting but not relevant here or now.

NikosD

17th July 2015, 08:23

Could someone with an Intel GPU check if LAV filters P010/P016 output of 10bit H.264/H.265 clips is working with Win 10 ?

Because I got an email from Intel that the problem of P010/P016 output is a Microsoft's EVR bug which is fixed in Win 10 only (MS is not going to fix it in previous OS versions)

I'm still with Win 8.1 OS and I can't check it.

huhn

17th July 2015, 10:06

p010 input in EVR crashed MPC-HC and windows media player just showed a black screen and played the audio stream. I used a intel HD 4400 with windows 10 10240

NikosD

17th July 2015, 10:33

Mpc-hc has enabled a special workaround for the issue, which obviously is not working according to your report.

Nevcairiel should probably fix it for all cases.

huhn

17th July 2015, 10:47

i tried mpc-hc build 1.3.1249.

and as far as I know mpc-hc blocked p010 for EVR not lavfilter.

and i forced lavfilter to output p010 aynway.

mastan

17th July 2015, 18:46

Don't have Win10 right now, but Win8.1 on Intel HD 4400 can output 10 bit, at least that's what MediaPlayer.Net shows:
http://s2.postimg.org/jsn1zil55/10bit_out.png

NikosD

17th July 2015, 19:03

Interesting.
I've never used that player.

Which is the decoder used by MediaPlayer ?

CruNcher

17th July 2015, 19:38

@mastan

Does 10 bit output also work Windowed ?

mastan

17th July 2015, 21:16

Interesting.
I've never used that player.

Which is the decoder used by MediaPlayer ?

LAV. Quote from its site (http://forum.doom9.org/showthread.php?t=171120):
LAV Filters must be installed (Media Player .NET is hardcoded to use these filters)

16-bit mode shows bad picture btw.

@mastan

Does 10 bit output also work Windowed ?

No. Quote from MPDN options:
Video Output Bit Depth*

*Applicable in Full Screen Exclusive mode only

huhn

18th July 2015, 00:27

this player is like madVR and not EVR. the problem is EVR has problem with 10 bit and 16 bit inputs but not these renderer.

madVR supports proper 16 bit up to 4:4:4 for years.

windows can't do 10 bit output in window mode using directx that's a simple limitation.

CruNcher

18th July 2015, 10:44

That will go away with Windows 10 as WDDM 2.0 is about to get Native support for it in the move to more 10 bit availabe Consumer Content and Hardware in 2016 timeframe

PS: Amazing how the x64 path of the HEVC Decoder can sustain stable playback framerates where the x86 path crashes down in latency completely

Most common commercial used x86 32 bit decoder in consumer x86 32 bit playback software currently have 0 chance ;)

Cyberlink 32 Bit Hybrid Nvidia Hardware Decoding Geforce GTX 970

http://abload.de/thumb/brakeups09j2u.png (http://abload.de/image.php?img=brakeups09j2u.png)

Lav Filter x86 Software Decoding basically the same MT under utilization result of Cyberlinks x86 as well as x64 code path

http://abload.de/thumb/lavvideo32tnbq8i.png (http://abload.de/image.php?img=lavvideo32tnbq8i.png)

Lav Filter x64 NV12 Forced 10 bit->8bit Decoding

http://abload.de/thumb/supercleani6kmy.png (http://abload.de/image.php?img=supercleani6kmy.png)

Realy nice result on 4 Cores :)

The jittering from the Ultra Video Group Beauty test sequence can only be eliminated here using the Nvidia Cuvid decoder in the .ts version (strange) might be a Nvidia driver issue with DXVA or some parser issue with the .mp4 as well .ts part

DXVA extreme jitter

http://abload.de/thumb/dxvajitteringkuxwi.png (http://abload.de/image.php?img=dxvajitteringkuxwi.png)

DXVA Copyback less jitter

http://abload.de/thumb/dxvacopybacklessjittes4qxw.png (http://abload.de/image.php?img=dxvacopybacklessjittes4qxw.png)

Nvidia Cuvid no jitter

http://abload.de/thumb/fixed0su4v.jpg (http://abload.de/image.php?img=fixed0su4v.jpg)

The same practically with the 80 mbps NX1 Sample only that there the Nvidia DXVA decoder performance completely turns down 6 FPS and only Cuvid/Copyback can hold it up 15 FPS of 30 Fps

P.J

18th July 2015, 22:58

I have noticed that PowerDVD has better audio quality, louder and more clarity.
DTS MA 5.1 to Stereo:

PDVD: http://phota.me/WfTS.png
LAV: http://phota.me/7B5N.png

Anyway to use Cyberlink audio decoder in MPC-HC? I added it but it didn't work for me.

huhn

18th July 2015, 23:14

looks like powerDVD is using normalization which is just bad in term of quality.

lavfilter is supposed to be bit perfect.

P.J

18th July 2015, 23:21

looks like powerDVD is using normalization which is just bad in term of quality.

lavfilter is supposed to be bit perfect.

But PowerDVD has no normalization option for DTS.
I also see some data around 20khz area for PDVD but LAV.

e-t172

19th July 2015, 00:09

I have noticed that PowerDVD has better audio quality, louder and more clarity.
DTS MA 5.1 to Stereo:

PDVD: http://phota.me/WfTS.png
LAV: http://phota.me/7B5N.png

Since you are downmixing, the difference in loudness can simply be explained by a difference in downmixing coefficients. You should be able to achieve a similar result in LAV just by tuning the coefficients in the LAV options. However it's quite possible LAV is doing a better job than PDVD here because it provides you with more protection about potential clipping from the downmixing.

Regarding "better quality" and "more clarity", that would be an expected reaction if you are indeed listening at a louder level - louder is often perceived as better in audio. You need to level match the tracks and do a blind test for proper comparison.

I also see some data around 20khz area for PDVD but LAV.

Most likely that's a red herring - it could simply be caused by the difference in volume which would put the (mostly quiet) content around 20kHz above the threshold of the spectrogram in the louder case. In other words the difference in the spectrogram display could just be the difference in level, and the relative frequency response is (probably) identical.

Finally, at the risk of stating the obvious, you should make sure LAV is decoding DTS-HD, not just the core. My understanding is the most recent LAV version (0.65) will always fully decode DTS-HD out-of-the-box though, thanks to libdcadec integration.