Unwanted Forced Dithering (LAV Video Decoder).

[James Freeman]

Ill post the problem (images) first then explain.

http://www.mediafire.com/convkey/bedb/nrgvdnnfv9zkjbbfg.jpg?size_id=a

http://www.mediafire.com/convkey/8205/74b55dt4449b92afg.jpg

http://www.mediafire.com/convkey/d3fe/m6ys72iz5ajgizqfg.jpg

It seems that when playing 16-bit video in MPC-HC with LAV Video Decoder & MadVR, there is a forced dithering in some Output Formats (LAV Video Decoder).

I'll try to explain what I see and what I'm trying to test:

When I disable Y416, the decoder goes to the closest lower next one: v410.
When v410 is disabled it goes to Y410, and so on till YV24.
Each of these levels has DIFFERENT forced dithering pattern !!!

When all the 4:4:4 row is disabled it goes to the 16-bit RGB -> RGB48 which is not dithered at all.
That is what we are striving for, to let MadVR do the heavy lifting.

I want to test if this forced dithering is somehow related to Nvidia or LAV filters with various formats of video.
These videos should be extremely useful to all video testing, not only this case.

Try to replicate this by downloading this video: 16bit Greyscale Video (http://www.mediafire.com/download/eh01w3vrfshk5oe/gradient-perceptual-v2.mkv)
In MadVR: disable all dithering and 3DLUT's
In MPC-HC: Turn Miscellaneous -> Brightness to 100.

What do you see?



EDIT:

All is OK !!
DeInterlacing was the culprit.

If you play 10-bit or 16-bit content, don't forget to disable deinterlacing or it will be forcefully dithered !!!

This may impact you 10-bit Anime fellows.

[vivan]

Why are you using DXVA deinterlacing? o_O All those DXVA-things are 8-bit only.

[James Freeman]

Thanks Vivan !!!!!!

Thread will be removed at once. :o

Boy, I feel stupid.

[Guest]

Thread re-opened. James, we don't like members to delete entire threads after others have answered. Also, others may have the same problem and would benefit from this.

[XMonarchY]

Should I stop using CUVID with madVR and LAV Video? Its just a DXVA wrapper for nVidia AFAIK... I didn't think it could cause issues.

[cyberbeing]

As vivan already implied, first screenshot here was because madVR deinterlacing was enabled on a 16bit 4:4:4 Y416 video. The second was because LAV Video dithered the 16bit Y416 video to 8bit YV24, and then madVR deinterlaced it. DXVA deinterlacing causes madVR to convert the video to 8bit 4:2:0 NV12, loosing both bitdeph and color information in this case. It would be slightly less lossy if 8bit 4:2:2 DXVA deinterlacing was used instead, but madVR does not support this. That said, the sample which James Freeman was playing is progressive FFV1, so he must have manually forced Deinterlacing on, via settings or keybinds, by mistake.

CUVID and DXVA decoding doesn't have anything directly to do with this, other than having similar bitdeph and color format limitations. LAV Video automatically fallsback to software decoding in such cases that the video bitdeph and color format are not supported.

The last screenshot was because LAV Video performed color conversion from 16bit 4:4:4 Y416 video to 16bit RGB using swscale, instead of allowing madVR to perform a higher quality color conversion itself.

When using LAV Video, it's recommended to not disable any of the default Output Formats, to prevent it from performing color conversions and dithering itself unless absolutely necessary. Only a few such routines are actually high-quality and written by nevcairiel, with the rest left at the whim of swscale.

[pirlouy]

About deinterlacing, if madVR DXVA solution is not perfect, is it better to use YADIF 50/60 from LAV Filters ?

[cyberbeing]

madVR's DXVA solution supports IVTC + Decimation for Film content, where with LAV video you'll have duplicates. On such content, it's a clear win for madVR.

On fully interlaced Video content, it's likely down to personal preference between GPU DXVA & Yadif. I will say it's rather rare to find 4:2:2 interlaced material outside of the professional broadcast space, so unless you have need to playback such content in a non-lossy way, I wouldn't take that factor into consideration.

[James Freeman]

I see the mods resurrected this shortly lived thread.

Hope my mistakes will help someone.

If you play 10-bit or 16-bit content, don't forget to disable deinterlacing or it will be forcefully dithered by the GPU !!!
You 10-bit Anime fellows.

[madshi]

It would be slightly less lossy if 8bit 4:2:2 DXVA deinterlacing was used instead, but madVR does not support this.
Last time I checked neither NVidia nor AMD supported the highest quality deinterlacing algorithm with 4:2:2 input. So if madVR fed 4:2:2 to DXVA, a lower quality deinterlacing algorithm would be used.

[nevcairiel]

If you play 10-bit or 16-bit content, don't forget to disable deinterlacing or it will be forcefully dithered by the GPU !!!
You 10-bit Anime fellows.

Its actually madVR which does the dithering, because the GPU doesn't allow 10 or 16-bit deinterlacing, so it converts to 8-bit, but I guess it always uses its random dithering for this step.

[madshi]

If you play 10-bit or 16-bit content, don't forget to disable deinterlacing or it will be forcefully dithered by the GPU !!!
Usually 10bit and 16bit content is not deinterlaced, so deinterlacing should be disabled by default.

Its actually madVR which does the dithering, because the GPU doesn't allow 10 or 16-bit deinterlacing, so it converts to 8-bit, but I guess it always uses its random dithering for this step.
Correct.

[cyberbeing]

Last time I checked neither NVidia nor AMD supported the highest quality deinterlacing algorithm with 4:2:2 input. So if madVR fed 4:2:2 to DXVA, a lower quality deinterlacing algorithm would be used.

Even if deinterlacing quality suffered, the difference between 4:2:0 and 4:2:2 on interlaced encoded content especially is not insignificant. Who is to say which is a better trade-off. I still think it would be useful for madVR to gain a "use 4:2:2 DXVA deinterlacing on 4:2:2 & 4:4:4 content (may result in lower deinterlacing quality)" option at some point in the future, even if it has to wait until after madVR version 1.0 is released.

[madshi]

My plan is to create my own deinterlacing solution (without DXVA) at some point (not soon), which of course will not be limited in either bitdepth or chroma subsampling. So there is no need to offer a 4:2:2 DXVA deinterlacing option in the long run.

[cyberbeing]

Sounds good.

[turbojet]

Deinterlacing based on nnedi3?

It's quite fast considering it's quality.