LAV Filters - DirectShow Media Splitter and Decoders

[nautilus7]

Yes, I switched to the internal audio renderer and it works.

So yes, LAV supports DSD playback converted to PCM, at the original high samplerate, and not every audio renderer supports those.

Do you mean that my file is not a DSD file, but a a high sample rate PCM?

[Vasilich]

Do you mean that my file is not a DSD file, but a a high sample rate PCM?
DSD playback requires special hardware (special 1bit DACs), that PCs do not have. So the only way to play it back on PCs is to convert DSD to PCM, what LAV obviously does.

[CruNcher]

@madshi
is gonna use your dithering options (apart from debanding) inside the renderer cause additional overhead if lav video is used or will madvr detect it and disable its internal dithering when lav video is used ?
though this would only work for decoder directly supported right, so if a non supported decoder does internal dithering madvr will apply its own ontop if selected ?

Also any Shaders running (not only inside MadVR) being taken account of in the Rendering Stats ?

http://i1.sendpic.org/t/Gi/GiVjF5MdVhMUWSNaTs8Pm4nGsh.jpg (http://sendpic.org/view/1/i/xl5qjOgQjfIbs0joewDDQcTs6w9.png)

http://i1.sendpic.org/t/rc/rcsjISuF5ZRTBwrHbYBDs6Y8jP9.jpg (http://sendpic.org/view/1/i/rIBn317yuN4GPprN1GqQMPq1HlK.png)


Oh ok seems to be overall taken into account so the denoiser causes the frame drops, a graphical Sync display (Graph) like in EVR Sync or EVR Custom would be a really nice addition so occuring 1ms jitter interupts (that doesn't have to cause frame drops) could be immediately detected as well EVR Sync does that nicely :)

Could you add the achieved Render Framerate as FPS as well to the Stats that's shown in MPC-BE Statistics Window ?

http://i1.sendpic.org/t/qD/qDnmdOMhM8nHF2MqQZUaYzZcL0i.jpg (http://sendpic.org/view/1/i/8IoZh1slYF2fznUGTPb0AHVqq43.png)

Though i wonder why it doesn't get in Sync with the Render Stats at all it is really slow updating overall, motion and that Render Stats and actually shown FPS doesn't match at all.

[huhn]

dithering is used for conversation where the bit deep is lowered.
so it doesn't really matter if lavfilter or any other "decoder" is dithering before.

even a YCbCr -> RGB conversation creates float point data and needs dithering.

in term of "over" head lavfilter is using the CPU for conversations madVR the GPU and this can't be compared.

[CruNcher]

Yes but there is a dithering option in MadVR and i wonder if those would overlay each other once from the decoder and once from MadVR if the decoder doesn't do any dithering at all (most are stupid) that would be no problem leaving it all the time enabled then but if a decoder does it like lav video what happens then if MadVRs dithering is enabled additionally, theoreticaly the logic would be they interfer with each other in case of Lav Video that has being avoided ?


Lav Video for example takes p010->dither->nv12 on a 8 bit output, now if in MadVR the dithering option is selected what happens then another dithering step ontop ? (didn't test it yet), and yeah what you say is perfect having that capability to chose where todo the dithering actually on (and which) but Lav Video would force it's CPU dithering most probably first if their is no logic in MadVR avoiding it telling Lav Video to disable it's CPU dithering (either Random or Ordered), yourself can't disable it manually in Lav Video there is no option for it.

[nautilus7]

DSD playback requires special hardware (special 1bit DACs), that PCs do not have. So the only way to play it back on PCs is to convert DSD to PCM, what LAV obviously does.

Yes, I know that PCs don't have DSD DACs.

I got confused (with the way Nev put it) that my file was not actual DSD, but PCM at 352KHz and LAV filters only convert it to 48KHz or 96KHz or whatever...

[sneaker_ger]

Lav Video for example takes p010->dither->nv12 on a 8 bit output, now if in MadVR the dithering option is selected what happens then another dithering step ontop ?
Yes, madVR will dither as well even then (like huhn said). madVR does a lot of processing in high-bitdepth so at the end of the whole scaling/filtering chain it has a high-bitdepth picture even with 8 bit input so it needs to dither again to downconvert before sending it to the display.

(didn't test it yet), and yeah what you say is perfect having that capability to chose where todo the dithering actually on (and which) but Lav Video would force it's CPU dithering most probably first if their is no logic in MadVR avoiding it telling Lav Video to disable it's CPU dithering, youself can't disable it manually in Lav Video there is no option for it.
You need dithering every time you downconvert from a high bitdepth so as to not create banding. The dither in madVR doesn't remove banding, it just avoids creating it. There is no reason for madVR to tell LAV to turn it off. As long as you don't turn off any output formats in LAV it will output the video as is without dithering.

[Asmodian]

There is nothing wrong with double dithering either, it isn't ideal but it is much better than rounding instead. The only downside is the increased noise.

[Pat357]

A wise man told me that if the signal needs further processing with (more) conversions/dithering one should use dithering based on triangular PDF(Probability Density Function) noise.
This is to avoid increasing the noise floor to much and to avoid some colors from bleeding out from their frequencies.

Anyone knows what kind of dithering Nev uses in LAV-video ?

[nevcairiel]

TPDF is generally more useful with audio, imho, since the built-in high pass helps to shift noise into higher frequencies, for video I don't think the same principles apply as such.

LAV uses standard random dithering, or ordered dithering, depending on the settings, and both as weak as possible, ie. only affecting any high bit depth data that would be cut off otherwise, and as such only ever modifying at most one bit in the output.

When I introduced these two modes they have shown to be quite effective without a perceived increase in noise. That said, if you use a modern renderer like madVR, LAV wouldn't ever be in a situation where it even had to perform dithering, as the image can be passed to the renderer untouched.

[SeeMoreDigital]

...I got confused (with the way Nev put it) that my file was not actual DSD, but PCM at 352KHz and LAV filters only convert it to 48KHz or 96KHz or whatever...Yes it's a DSD stream. Which has been transcoded by LAV to a PCM stream.

Over the years there's been loads of heated discussions on various forums about 'the best way' to transcode DSD to PCM along with which sample rates and bit-depths should be used.

Personally, I'm just happy that after many years it's now possible to actually play 2-channel and multi-channel DSD streams using a software player on a PC.

Refinement of the DSD-to-PCM process probably deserves a topic of its own ;)

[CruNcher]

TPDF is generally more useful with audio, imho, since the built-in high pass helps to shift noise into higher frequencies, for video I don't think the same principles apply as such.

LAV uses standard random dithering, or ordered dithering, depending on the settings, and both as weak as possible, ie. only affecting any high bit depth data that would be cut off otherwise, and as such only ever modifying at most one bit in the output.

When I introduced these two modes they have shown to be quite effective without a perceived increase in noise. That said, if you use a modern renderer like madVR, LAV wouldn't ever be in a situation where it even had to perform dithering, as the image can be passed to the renderer untouched.

But is this also currently happening in the exact scenario you describe here between Lav-Video->MadVR ?

So Lav-Video isn't going to dither then on the CPU and leaves the decision up to the Renderer in this case MadVR (so a dynamic pass it Untouched is being done and any Lav-Video dithering setting ignored automatically) ?

[nevcairiel]

LAV only ever dithers if it reduces the bitdepth of the image in any way. This just does not happen when you use madVR (and you didn't change the LAV default settings, ie. turned off output formats).
Even with other renderers it doesn't happen with the majority of content, ie. if you output normal 4:2:0 8-bit content as NV12 or YV12 to EVR, there is no dithering in LAV, because its not needed.

Thats the most basic thing about dithering, its entire purpose is to spread the "error" when you reduce the bitdepth of a signal. If you don't reduce the bitdepth, you don't dither.

[CruNcher]

so if the case is

Main10->p010->MadVR->Driver 8 bit out

CPU dithering will not take place from Lav-Videos side ?

Main10->p010->nv12/yv12->MadVR->Driver 8 bit out

CPU dithering will take place from Lav-Videos side ?

[nevcairiel]

No, since P010 is full untouched 10-bit 4:2:0.

[CruNcher]

But if you disable p010 as output format which then does a nv12/yv12 conversion so the second case then yes not No ?

in this case here Lav Video dithering takes place in this example Ordered Dithering ?

http://i1.sendpic.org/t/qN/qNp21VEy0PUIu6IDUlQS2R6NMzv.jpg (http://sendpic.org/view/1/i/xj9P8AEP86Pyv97W6mjGN4Gd2D4.png)

And in this case you can't avoid the dithering you just doesn't allow it to be untouched because if would cause severe visible banding in this specific example, do i understand it right and the logic behind your GUI decisions and the enforcement of the dithering option ?

[nevcairiel]

Like I said, if LAV reduces the bitdepth, then it dithers. And only then. Its really not any more complex.

[CruNcher]

Ok at least things i posted previously where valid then and i understood it correctly whats going on :)

Would be still nice to have the option to avoid the CPU dithering entirely in that case and get the pure untouched 8 bit output, that should look more like this untouched by the dithering ;)

http://i1.sendpic.org/t/dn/dnEDaw3QhkHecbyG2fVCMdLFygN.jpg (http://sendpic.org/view/1/i/52tEVVFThc2qs34EFnTS1TjjmqB.png)

[huhn]

seriously for what?

outputting P010 is faster and cheaper...

[nevcairiel]

Would be still nice to have the option to avoid the CPU dithering entirely in that case and get the pure untouched 8 bit output, that should look more like this untouched by the dithering ;)

There is no "pure untouched 8 bit output" if the file is 10-bit, you have to touch it in some way to make it 8-bit, and the correct way to do that is by dithering. Disabling dithering is just wrong and should never be done, hence LAV will never allow it.
If you don't want LAV to dither, then output the proper bitdepth.

[CruNcher]

Ok i meant non dithered 8 bit output that shows banding untouched was just meant in the way of non dithered not non converted testing the debanding this way seems interesting as its very high quality banding that you can straight process with it :)

[nussman]

Ok i meant non dithered 8 bit output that shows banding untouched was just meant in the way of non dithered not non converted testing the debanding this way seems interesting as its very high quality banding that you can straight process with it :)
And that "would be still nice to have"? Why?
Your posts about dithering all over doom9 are really hard to unterstand (pure nonsense imho).

[bongobarry]

Question on output levels for full range (0-255)

I have my TV set to accept levels from 0-255 - I know that my TV can accept and display these levels because I've sucessfully tried the AVS HD709 calibration disc on two separate blu-ray players.

However, when playing AVS HD709 files via LAV filters and MadVR, only limited range is played. I have an NVIDIA GT640, which I know is outputting full range 0-255 as desktop - I've tested it.

When I do a CTRL+J during play-back of the BTB and WTW levels on AVS HD709, MadVR reports that the input levels are Limited (says upstream).

Is LAV Video incorrectly reporting the output levels of this test file?

[huhn]

no everything is working as intended.

the video file is flagged as limited range and madVR is doing the rest.

the AVS HD709 black clipping file is created in a way that it is reporting limited range but the video signal holds full range data.
16 and lower are black else your setup is wrong.

the lavfilter range setting has nothing todo with that this is only used when lavfilter is converting to RGB and that is something that is not going to happen with madVR so it doesn't matter what you select there.

[bongobarry]

I'm not sure that I understand. The black clipping file contains video signal which goes below 16 (ie BTW). On my setup currently (LAV & MadVR), I'm unable to see 16 and below

If the signal is there in the file, why am I unable to see it on my TV? The signal from 16 and below is presented when I play the same file on a blu-ray player.

[nussman]

Unable to see 16 and below is right.

Your bluray player sends limited range (?) and you tell your TV to expect full range (=> 16 and below is visible => wrong).
If you set up your TV to expect limited range it should be ok with your bluray player (16 and below = black)

[huhn]

than your BD player chain is setup wrong.

if your BD player is outputting limited range and your TV is setup to full range you would see 16 and below.

just as a reminder this is wrong 16 and low is supposed to be black.

this has nothing todo with lavfilter.

[bongobarry]

My TV is set to expect full range. My NVIDIA card is set to output full range. MadVR is set to output full range. The AVS HD709 file contains full-range content.

If I turn-up the brightness on my TV, the black bands below 16 should be visible, if the player is outputting 0-255.

If the BTB (0-16) video content is there in the file, why is it not being sent to my TV?

[clsid]

The BTB content is present in that file so you can see if your playback chain is configured correctly or not. If it is all black then things are correct. If you can see those bars then things are configured incorrect!

[nevcairiel]

My TV is set to expect full range. My NVIDIA card is set to output full range. MadVR is set to output full range. The AVS HD709 file contains full-range content.

Technically, the AVS HD709 files contain limited-range with BTB/WTW content. Its a distinction to actual full-range content.

Its meant to be played as limited range, so you can use BTB/WTW to calibrate the black point (ie. tune it in such a way that 1-16 all look the same - black). However, if you use full-range output, there is no room for BTB/WTW anymore, since you use the full range for the relevant image signal - and you can tune the blackpoint differently, ie. by tuning brightness so that you can barely make out the distinction between 0 and 1.

As others have said, it contains the BTB content so you can test if your playback system is setup properly - and "proper" here is that you cannot actually see 1-16, its meant to be invisible.

[Whiter]

:helpful:

Hello.
Can anyone help? Problem in building the "release" of the new version.

By script "build_ffmpeg" build ffmpeg. In VS2015 build .ax. "debug" without problem, but release ....

http://forum.doom9.org/attachment.php?attachmentid=15717&d=1484631317

[Artofeel]

LAV Video currently does not allow "processing" the 3D video in any way, it can only output it to a 3D aware video renderer - madVR 0.90 or later. In the future it might be possible to have LAV Video render the video as Side-by-Side, but not in this release.
please add support for SbS\TB output
it will be possible to use anaglyph shaders in MPC (with madVR it not working, because shaders applies before render)
also it will be easy to convert video with avisynth

[Ajvar]

Guys, I just jumped back on Nvidia and suddenly no more see an option for choosing gt 650m as DXVA-copy-back or Cu-vid device. Is this connected to driver version (372)?
Did nvidia ditched not just encoder by now but DECODER too?
Thanks.

[nevcairiel]

On Optimus devices you only get access to the GPU your player is configured to run on, which is most typically the Intel GPU for power saving reasons.

[andybkma]

Guys, I just jumped back on Nvidia and suddenly no more see an option for choosing gt 650m as DXVA-copy-back or Cu-vid device. Is this connected to driver version (372)?
Did nvidia ditched not just encoder by now but DECODER too?
Thanks.

Ah finally, a question that I can help with :-)

I also have a laptop with optimus and happen to have the same video card (though that last part doesn't matter). All you have to do is start your media player as the "high performance video processor" which will then give you all the nvidia cuda & copy back options you seek. This can be done either one of two ways. 1) Right click on the shortcut you use to access the media player and select "high performance... " under the Run with graphics processor option or 2) set your media player to always run with nvidia high performance under the nvidia options. Easy :-)

Of course this all will only work if you actually have the Nvidia drivers installed. I have the most recent drivers GeForce 650M drivers installed (Version: 376.33 WHQL
Release Date: 2016.12.14) which can found on Nvidia's site and all is good.

[andybkma]

On Optimus devices you only get access to the GPU your player is configured to run on, which is most typically the Intel GPU for power saving reasons.

nev, you can actually either manually select which video card you want to use with your video player or you can set it up in the Nvidia options which card to always use. I have mine set up in Nvidia options to always use Nvidia as I am not trying to save power and prefer Cuvid over Quicksync. Plus had to overclock my 650M a bit to use with mVR

[Ajvar]

@nevcariel and @andybkma, Thank you but something is still wrong. Nvidia GPU is perfectly being used by PotPlayer x86 when I set Nvidia CUDA decoder in built-in codec/transform option (even though option to pick preferred GPU in NVCP is greyed out for PotPlayerMini.exe). But even though PotPlayer is running on Nvidia, the Nvidia GPU is still missing in DXVA CopyBack (built-in codec/transfom in addition to LAV decoder).
So yes, looks like it's not LAV problem, for some reason my OS doesn't let me choose Nvidia GPU as DXVA CopyBack device. Strange.


P.S. DXVA checker shows no supported accelerations for device GT 650M. Nobody ever heard about anything like this?

P.P.S. OK, for some freaking reason my OS believes that Intel HD4000 device is nvumdshim.dll which clearly means that it calls my Nvidia GPU as an Intel GPU. Is it Intel drivers fault or Nvidia - I don't know. Nobody ever met this problem?

[nevcairiel]

nev, you can actually either manually select which video card you want to use with your video player or you can set it up in the Nvidia options which card to always use. I have mine set up in Nvidia options to always use Nvidia as I am not trying to save power and prefer Cuvid over Quicksync. Plus had to overclock my 650M a bit to use with mVR

Of course you can, but only one at a time, hence why I said "your player is configured to run on" - set it up to run on NVIDIA, and you can run it on that, but by default the profiles usually put media players on the Intel.

[andybkma]

@nevcariel and @andybkma, Thank you but something is still wrong. Nvidia GPU is perfectly being used by PotPlayer x86 when I set Nvidia CUDA decoder in built-in codec/transform option (even though option to pick preferred GPU in NVCP is greyed out for PotPlayerMini.exe). But even though PotPlayer is running on Nvidia, the Nvidia GPU is still missing in DXVA CopyBack (built-in codec/transfom in addition to LAV decoder).
So yes, looks like it's not LAV problem, for some reason my OS doesn't let me choose Nvidia GPU as DXVA CopyBack device. Strange.


P.S. DXVA checker shows no supported accelerations for device GT 650M. Nobody ever heard about anything like this?

P.P.S. OK, for some freaking reason my OS believes that Intel HD4000 device is nvumdshim.dll which clearly means that it calls my Nvidia GPU as an Intel GPU. Is it Intel drivers fault or Nvidia - I don't know. Nobody ever met this problem?


The only problem I have ever had using PotPlayer with my Optimus laptop is that I had to rename the default PotPlayerMini.exe to just PotPlayer. Then set PotPlayer.exe to use with Nvidia. Then all was fine. Perhaps this may help your problem? Wouldn't that be nice....

[P.J]

Is 1050Ti 4GB better than 1060 6GB for 4K/8K HEVC (10bit)?

Ah sorry, wrong topic =/

[JoeyMonco]

Is 1050Ti 4GB better than 1060 6GB for 4K/8K HEVC (10bit)?

Unlikely especially with a narrower memory interface (128bit vs 192bit) and lower memory bandwidth (112 GB/sec vs 192GB/sec).

[TheShadowRunner]

@nev Do you have plans to implement the TRACKSET/TRACKSETEX (http://forum.doom9.org/showpost.php?p=1703159&postcount=18366) feature for Matroska in LAV Splitter?
It's really a must for multi-language!

[hubblec4]

@nev Do you have plans to implement the TRACKSET/TRACKSETEX (http://forum.doom9.org/showpost.php?p=1703159&postcount=18366) feature for Matroska in LAV Splitter?
It's really a must for multi-language!

I have ask this too for a long time, and I get never an answer.

[hubblec4]

Hi nevcairiel

I have a feature request and maybe it is possible and not so much work.

I have some Matroska menu files with a lot of chapters inside. When I use the tray icon to select a chapter it takes a lot of time, cause I must scroll down a while to find the correct chapter.

Is it possible to make a small arrangement for the chapters?
What I like to have is, that nested chapters are displayed as a sub-menu of a chapter with level 1.

Here you find such a menu-mkv. (http://forum.gleitz.info/attachment.php?attachmentid=99279&d=1485686941)

Best regards

[egandt]

I have a 7700K, and a Nvidia 1070 GTX, normally I use the GTX for all decoding, but when I hit 4K HDR, using the 1070 for both LAV and MadVR is to much for teh card, as such I want to be able to use the QuickSync for this use case.

I have the system set as follows:
1070 HDMI -> 4K (1)
1070 DVI -> 1080P (2)
Intel HDMI -> 1080P (3): currently I'm using a Genfen sink so I do not need a physical monitor, but so that Windows thinks it exists.

This all works, I have 2 and 3 shared and 1 as a seperate ouput, the Intel driver is loaded and running, however LAV states that QuickSync is not is NA. What am I doing wrong as QuickSync is not being disabled as enabled?

Intel Driver 21.20.16.4550 is currently installed and running.

Thanks,
ERIC

[huhn]

DXVA decoding shouldn't put any stress on the GPU.

[nevcairiel]

If QuickSync doesn't work, its usually either that the driver install wasn't quite right, make sure to get a package directly from Intel and not a Windows Update driver, as it lacks QS parts sometimes, or the GPU isn't actually active.
But as huhn said, DXVA decoding impact is minimal at best, it should not have any real impact on madVRs capabilities to render the image.

All that said, QuickSync wouldn't work for you either way. It doesn't support HEVC, and even if that were implemented one day, it also doesn't have the ability to export the HDR metadata required by madVR for proper HDR handling.
QuickSync should generally be considered "on life support", and DXVA2 decoding should generally be favored. If your Intel GPU is properly setup and active, it could however even be used for DXVA2 decoding, and wouldn't require QuickSync.

[madshi]

I'm having trouble with the LAV VC-1 decoder. No problems at all with MPEG2 or h264.

Recently I noticed that when playing VC-1 movies with my new Windows 10 HTPC, for a while (can be a minute or 2) things appear to run smoothly. But then audio/video sync gradually desyncs until finally there is some heavy stuttering and sync corrects itself. Also audio plays with some crackling noise in it sometimes, and when all this spook happens, the madVR OSD suddenly reports a big jump up in audio clock deviation. So as a test I've disabled the LAV VC-1 decoder. As a result the MS DMO becomes active, and all problems have totally vanished. With the MS DMO playback works perfectly, same as LAV with MPEG2/h264.

I'm not fully sure how a software decoder can result in audio crackling noise etc, it seems weird to me. Maybe we should ignore that. My best guess why the audio/video sync problems might occur is that the decoder might output weird (shuffled) timestamps somehow. madVR tries to detect that problem and correct it, but it doesn't always work perfectly. FWIW, all this is with VC-1 MKV files, I haven't tested with m2ts files.

Does any of this ring any bells?

I suppose I'm fine with leaving VC-1 disabled in LAV, so I don't really depend on a fix. But I thought I should report it, in case it's something you want to look into?

[nevcairiel]

Doesn't sound like something that happened to me. I have a bunch of Blu-ray sourced VC-1 MKV files (made with MakeMKV), and I don't remember ever seeing any troubles with them. Thats basically all the VC-1 content i generally watch, however.
I assume you don't use any HW codecs, and didn't disable the MS DMO checkbox in the LAV Video -> Formats settings? (or in other words active decoder reports "wmv9 mft" when playing such a file?)

How big of a jump does your OSD show? On a quick check, I sometimes see jumps from 0.000x to 0.03x, which seems like a huge difference, but couldn't really spot desync yet.

[huhn]

Recently I noticed that when playing VC-1 movies with my new Windows 10 HTPC, for a while (can be a minute or 2) things appear to run smoothly. But then audio/video sync gradually desyncs until finally there is some heavy stuttering and sync corrects itself. Also audio plays with some crackling noise in it sometimes, and when all this spook happens, the madVR OSD suddenly reports a big jump up in audio clock deviation. So as a test I've disabled the LAV VC-1 decoder. As a result the MS DMO becomes active, and all problems have totally vanished. With the MS DMO playback works perfectly, same as LAV with MPEG2/h264.

this kind of reminds me of a problem with MPDN.
using latencymon i had DPC spikes in the 10000.
tool link: http://www.resplendence.com/downloads

maybe something worth checking.