LAV Filters - DirectShow Media Splitter and Decoders

[aufkrawall]

Originally Posted by wanezhiling

Well, you can make LAV CUVID active on win8 CP with 295.73 or previous drivers?

I don't know, I just installed the driver on Windows 7.
So, CUVID doesn't work with 295.73 on Windows 8?

[wanezhiling]

http://forum.doom9.org/showpost.php?...postcount=9556

[mastan]

Originally Posted by aufkrawall

I don't know, I just installed the driver in Windows 7.
So, CUVID doesn't work with 295.73 on Windows 8?

No.
GPU-Z shows that only DirectCompute 5.0 is available.

[wanezhiling]

nev, LAV SW decoder and CUVID decoder(HQP unchecked) use the same deinterlacer(renderer deinterlacing)?

[nevcairiel]

Originally Posted by wanezhiling

nev, LAV SW decoder and CUVID decoder(HQP unchecked) use the same deinterlacer(renderer deinterlacing)?

The renderer probably always does the same as with High Quality processing enabled.

[wanezhiling]

I see, thanks.

How to make madVR take over the deinterlacing work in CUVID mode?

[Pat357]

Originally Posted by wanezhiling

I see, thanks.

How to make madVR take over the deinterlacing work in CUVID mode?

Just disable all interlacing in Lav-video : set the algorithm on "none (Weave)".
MadVR will now see an interlaced stream and should start it's internal interlacing.

Nev,
Can you explain the impact of the 3 options related to interlacing in Lav-video if I use MadVR ?

What does "force deinterlace" do when using madVR ?
The same question for "aggressive deinterlacing" and "tread as progessive"
It's currently very unclear to me how these options go along with MadVR's internal logic and the Madvr options to change deinterlacing behavior.

[nevcairiel]

Originally Posted by Pat357

Nev,
Can you explain the impact of the 3 options related to interlacing in Lav-video if I use MadVR ?

What does "force deinterlace" do when using madVR ?
The same question for "aggressive deinterlacing" and "tread as progessive"
It's currently very unclear to me how these options go along with MadVR's internal logic and the Madvr options to change deinterlacing behavior.

madVR seems to generally not trust what decoders say (apparently having access to the full encoded bitstream doesn't mean much), so those options will most likely not do anything with it.
You should rather ask madshi about those things. I know what they do, and you can easily see what they do with EVR, but what madVR does with the information the decoder provides, i don't know.

For the record:
- "Force Deinterlacing" sets interlace flags on all files and all frames, no matter what.
- "Aggressive Deinterlacing" sets interlaced flags on all frames when the file itself is marked interlaced (from the stream header or such)
- "Tread as Progressive" marks all frames as progressive, and never anything as interlaced.

[madshi]

Let me explain how things are from the view point of a video renderer. The renderer must deal with a wide number of decoders and they all behave differently. Some decoders always set interlaced flags, others never set interlaced flags, again others set them sometimes and sometimes not, depending on user configuration (and the user doesn't always know what he's doing), or depending on the weather or the configuration of the planets. There are typically 2 things that I've seen decoders do:

(1) Either the decoder sets the interlaced flags to 0. If that happens, madVR doesn't know if that is supposed to mean "this file is progressive", or if the decoder is not in the mood to share information, because 0 is also the non-initialized value used by all decoders which never properly fill in these values (like CoreAVC).

(2) Or the decoder sets the flags to "AMINTERLACE_DisplayModeBobOrWeave". Again, this information is more or less useless, because by definition is means "the stream could be totally progressive, or totally interlaced, or a mixture of both". In other words, by setting "AMINTERLACE_DisplayModeBobOrWeave", the decoder pretty much says: "I've no idea whether this file is interlaced or progressive or whatever".

Even though all of the above is quite bad, madVR *still* tries to behave identical to VMR/EVR, which means that if the interlace flags are set to 0, madVR will by default not activate deinterlacing, and if the flags are set to "AMINTERLACE_DisplayModeBobOrWeave", madVR will by default activate deinterlacing, but only after the first interlaced video frame is received. I don't consider this behaviour really alright, but since VMR/EVR are doing it this way, I'm trying to have madVR behave identical.

There is one thing that makes madVR's behaviour different from VMR/EVR: While VMR/EVR always blindly trust the decoder (and thus will stumble when decoders don't set the flags correctly, or not at all), madVR gets itself access to the video bitstream to make its own analyzation of whether deinterlacing is needed or not. If the video bitstream clearly says whether deinterlacing is necessary or not, madVR will value this information higher than the rather non-specific flags described above. I believe this is a good thing, and I challenge anyone to argue otherwise.

If LAV wants to force deinterlacing to on/off, it's easy enough to do that with madVR. There are interlace flags available for that, described by Microsoft, which madVR properly honors. "AMINTERLACE_DisplayModeBobOnly" asks for the whole video stream (every frame) to be deinterlaced, so that would be the correct flag to set to force the renderer to turn deinterlacing on. And "AMINTERLACE_DisplayModeWeaveOnly" asks for the whole video stream to not be deinterlaced, so that would be a good flag to set to force the renderer to turn deinterlacing off. If LAV used these flags, madVR would obey. madVR has supported these flags from the first version deinterlacing was introduced.

[dukey]

Guessing whether a stream is interlaced or not will always produce errors. I've often seen progressive content with interlaced fades or overlays etc. It's never ending, especially for videos like music videos. In the end the only safe thing to do is deinterlace everything marked as interlaced. My TV tries to be clever and guess what is interlaced, and I regularly see it mess up.

[Asmodian]

Originally Posted by dukey

In the end the only safe thing to do is deinterlace everything marked as interlaced.

This isn't safe either, if you deinterlace progressive content you damage it and a lot of progressive content has some kind of interlaced flag set. You might not notice it but I do. IMO the only safe way is to set it yourself after examining the video (not very automatic ).

If all (or most, some, only LAV ) decoder(s) could output a standard set of flags that were specific (interlaced = yes, no, maybe) and that MadVR also understood it would be great!

We could then set MadVR to deinterlace only the "Yes", both "Yes" and "Maybe", or force deinterlace everything. If you enabled deinterlacing in LAV I assume it would set the interlaced flag to "No" so the renderer doesn't re-deinterlace?

[Andy o]

I'm wondering if anyone's using an AMD 7750 yet to see if it improves DXVA copyback performance with madVR? I could never get it to work well even with the 5770 and I'm scraping to get the best bang for buck GCN card I can.

[mindbomb]

question:

For a file that is being sequentially downloaded, lets say you have the first 10% of it. If you open it up, and try to play it, even if it finishes downloading before you hit the 10% mark, your video just freezes at the 10% mark.

Can anything be done about this?

[nevcairiel]

Originally Posted by madshi

Even though all of the above is quite bad, madVR *still* tries to behave identical to VMR/EVR, which means that if the interlace flags are set to 0, madVR will by default not activate deinterlacing, and if the flags are set to "AMINTERLACE_DisplayModeBobOrWeave", madVR will by default activate deinterlacing, but only after the first interlaced video frame is received. I don't consider this behaviour really alright, but since VMR/EVR are doing it this way, I'm trying to have madVR behave identical.

Actually, madVR does not behave 100% like EVR here.
I have a file which is marked as interlaced, however the frame-flag is missing on some frames. EVR will not deinterlace the frames where this is missing, madVR will.
Even if the behaviour of deinterlacing the frames in this file is correct, extrapolating from that, any file which is mixed interlaced and progressive content, even the progressive frames will all be deinterlaced.

There is also no other set of flags i could set, AMINTERLACE_DisplayModeBobOrWeave is the only flag that allows mixed interlaced and progressive content.

Anyway, that seems to be the only case thats inconsistent.

Originally Posted by madshi

If LAV wants to force deinterlacing to on/off, it's easy enough to do that with madVR. There are interlace flags available for that, described by Microsoft, which madVR properly honors. "AMINTERLACE_DisplayModeBobOnly" asks for the whole video stream (every frame) to be deinterlaced, so that would be the correct flag to set to force the renderer to turn deinterlacing on. And "AMINTERLACE_DisplayModeWeaveOnly" asks for the whole video stream to not be deinterlaced, so that would be a good flag to set to force the renderer to turn deinterlacing off. If LAV used these flags, madVR would obey. madVR has supported these flags from the first version deinterlacing was introduced.

AMINTERLACE_DisplayModeBobOnly doesn't work with madVR. I tried to set it, but the OSD still claims "deinterlacing off (says bitstream)". Note that BobOnly has the value 0, so if you check for it with a &, it wouldn't work.

Even though i don't agree with setting WeaveOnly for progressive (progressive is defined as the absence of flags), it seems to work.

[madshi]

Originally Posted by nevcairiel

Actually, madVR does not behave 100% like EVR here.
I have a file which is marked as interlaced, however the frame-flag is missing on some frames. EVR will not deinterlace the frames where this is missing, madVR will.
Even if the behaviour of deinterlacing the frames in this file is correct, extrapolating from that, any file which is mixed interlaced and progressive content, even the progressive frames will all be deinterlaced.

You're right. Older madVR builds still behaved the same as EVR there, but I recently changed that because otherwise "forcing" deinterlacing inside of madVR didn't work properly. Do you think I should change this back and find a different solution for the forcing?

Originally Posted by nevcairiel

There is also no other set of flags i could set, AMINTERLACE_DisplayModeBobOrWeave is the only flag that allows mixed interlaced and progressive content.

Yes, in normal mode, that's what LAV should use. But if LAV is configured to force deinterlacing on/off, "mixed" is not needed anymore. So in forced mode, you can use something other than AMINTERLACE_DisplayModeBobOrWeave.

Originally Posted by nevcairiel

AMINTERLACE_DisplayModeBobOnly doesn't work with madVR. I tried to set it, but the OSD still claims "deinterlacing off (says bitstream)". Note that BobOnly has the value 0, so if you check for it with a &, it wouldn't work.

Ooooops. Will fix that in the next build. Wasn't aware of that the value was 0.

Originally Posted by nevcairiel

Even though i don't agree with setting WeaveOnly for progressive (progressive is defined as the absence of flags), it seems to work.

What other flag combination would you suggest to indicate "progressive"? 0 would make sense, but unfortunately it's the same as "not initialized", so we can't really use that.

[Skibicki]

I use Lav Filters for mp3 in PotPlayer and this file did not play. It froze with the album art and showed up as mjpg in file info. Plays fine in WMP.

http://www.mediafire.com/download.php?251j501nbv8vjxx

PotPlayer 1.5.32338 x86
Lav Filters 0.48 1dc4df4

[nevcairiel]

Originally Posted by madshi

Do you think I should change this back and find a different solution for the forcing?

Maybe at least an option to control this might be nice.

Originally Posted by madshi

What other flag combination would you suggest to indicate "progressive"? 0 would make sense, but unfortunately it's the same as "not initialized", so we can't really use that.

If 0 is out, then thats the only flags that do seem to make sense.

Originally Posted by Skibicki

I use Lav Filters for mp3 in PotPlayer and this file did not play. It froze with the album art and showed up as mjpg in file info. Plays fine in WMP.

Fixed

[DragonQ]

nevcairiel and madshi, this is nothing really to do with LAV Filters or MadVR but I figure you might know something about this:

In MKVMerge, is it preferable to set the Aspect Ratio or Display Width/Height? The combinations of LAV + EVR and LAV + MadVR both seem to work fine with either option but I'm just thinking about maximum portability of MKV files on other machines with other filters, decoders and renderers.

[nevcairiel]

MKV only has the Display Width/Height fields internally, so whatever you set, it'll end up in those fields.
If you want portability, i would recommend to make sure that the Aspect Ratio is also properly set in the video headers, at least H264, VC1 and MPEG2 have fields for that. A lot of players ignore the container values.

[The SphereX]

Hi there !!!

I got the following two problems with the "LAV Video Decoder":

1.) When playing HD movies in MPC-HC, that have been x-cropped (e. g. from 1920 to 1808), it results in a stuttering playback with asynchronous audio. However, when movies are y-cropped everything's fine.
2.) 50p Full-HD video from a "Panasonic HDC-SD909" camcorder is played back at only about 30-32 FPS.

Hopefully someone's got an idea of how to fix these problems, because until now I always have to reencode the two problematic formats to 1.) 1920x1080 and 2.) 720p @ 50 FPS to play them back flawlessly.

Motherboard: Zotac ION ITX D
Chipset: NVidia ION (video decoder is set to use "Nvidia Cuvid")
CPU: Intel Atom N330 Dual Core @ 1,6 GHz
Player: MPC-HC
Splitter: Haali Media Splitter
Renderer: VMR-7
OS: Windows XP Professional (SP3)

Greetz,
The SphereX