LAV Filters - DirectShow Media Splitter and Decoders

[fastplayer]

Looks great!
Are you gonna remove the HQ-Format-Conversion checkbox? You've mentioned it a while ago.

[nevcairiel]

Originally Posted by mindbomb

so, in the near future, you can get lav video to do the HQ rgb conversion with cuvid?

Yes.

Originally Posted by mindbomb

if you try to play a 10 bit h264 video, hw decoding will automatically disable itself?

Thats the plan, but not implemented yet. Its one of the things missing before a release.

Originally Posted by fastplayer

Are you gonna remove the HQ-Format-Conversion checkbox? You've mentioned it a while ago.

I probably could, its mostly useless now, but no harm either way.

[SamuriHL]

So this means the LAV CUVID code base is integrated now with LAV Video? Anything we should know about building it? I haven't done a build in a while but was planning on doing one tonight to get the latest code.

[nevcairiel]

Originally Posted by SamuriHL

Anything we should know about building it?

You don't need the CUDA SDK anymore.

[SamuriHL]

Originally Posted by nevcairiel

You don't need the CUDA SDK anymore.

Nifty. I'll try a build a bit later. Thanks!

[nevcairiel]

Note that its not 100% complete yet.

Whats still to do for CUDA/CUVID:
- VC1 decoding will not result in proper timestamps
- Automatic software fallback on unsupported movies (10bit H264, 4:2:2 MPEG-2, etc)

I also axed MPEG4-ASP support for the time being. I don't think its really worth it, the software decoder will do it much better.

[SamuriHL]

Well, I'd like to try it out in MC16 and test it before you release a version that's combined. I'd like to make sure they won't run into any problems since they currently use LAV CUVID in some cases by default.

[nevcairiel]

LAV CUVID itself won't break of course, it just won't be updated much anymore.

[SamuriHL]

Right, but, given how they consume the filters I just want to make sure nothing gets screwy in that configuration. Matt will want to remove LAV CUVID at some point once you do a full release. The question then becomes...does he default MC16 to LAV Video in all cases. I'd personally say yes but that's not my decision. I know on my machines that's what I've been using and have no problems.

[nevcairiel]

They would probably require software deinterlacing before they can make the switch, or use ffdshow as a post-processor.
Well, they can decide how to handle it. I honestly don't care much. There will be a transition period until LAV Video can fully provide a full playback chain with YADIF, but i have to start somewhere, don't I.

After cuvid is done, my next goal is either integrating the MS wmv9 software decoder (for vc-1 interlaced), or a Intel hardware decoder. Not sure yet which to tackle first.

[VipZ]

Awesome work nev.

Originally Posted by nevcairiel

After cuvid is done, my next goal is either integrating the MS wmv9 software decoder (for vc-1 interlaced), or a Intel hardware decoder. Not sure yet which to tackle first.

I vote MS wmv9

[SamuriHL]

I would vote for the MS decoder. That would be quite useful. And yea, I'll maybe start a thread over there to make them away that LAV CUVID code is being integrated into LAV Video and that they may want to start considering switching over to LAV Video for the default. Interlace stuff isn't that big a deal to handle. As you said, there are multiple ways to do it including just using MS decoder for VC1 interlaced content. They can figure that out.

[madshi]

JFMI, what would be the benefit of integrating the MS VC-1 decoder over using the already existing MS DMO?

[nevcairiel]

Alot of DirectShow players have issues disconnecting and re-creating the video decoder/renderer on the fly, so it would be beneficial if there is one good decoder for all needs, which can just switch decoders internally.
This is mostly aimed at future advanced Blu-ray support (title switching, full navigation, even menu support), where the video type can switch on the fly between titles, but nothing really relevant right now.

But alot of people keep asking for it as well, not sure what they want to get out of it, but i have fun doing it, so why not!
I guess it simplifies their filter setup somewhat.

There is also my idea of using hardware deinterlacing with software decoding, but i guess thats only half-valid, as you could as well just use a hardware decoder for VC-1i then.
Maybe i'll go with the Intel decoder first. I already saw a patch for VC-1i decoding with libavcodec. It produces some kind of image, but its still somewhat a WIP. But there is hope.

[SamuriHL]

For MC16 it'd be useful because you could just tell it to use LAV Video for everything and it'll switch internally for whatever content you're playing.

[SeeMoreDigital]

Originally Posted by nevcairiel

There is also my idea of using hardware deinterlacing with software decoding, but i guess thats only half-valid, as you could as well just use a hardware decoder for VC-1i then.

Can a similar idea be incorporated to add AVClossless decoding to your "LAV CUVID" decoder?


Cheers

[CruNcher]

Originally Posted by SeeMoreDigital

Can a similar idea be incorporated to add AVClossless decoding to your "LAV CUVID" decoder?


Cheers

Nope the best way (most efficient though also most complex way) is to dynamically jump between Hardware and Software Decoder cores currently but the different reaction on different renderer (and then you have the different performance, the logic of what is better for your Hardware what gives you the best experience for this Format Hardware Playback or Software (will this 60 fps stream playback fast enough in my setup on the Discreete DSP or will it fail and should i better use the Software Decoder), and the switching logic though in terms of hardware and Renderer limitations that is already good under control) with different input and different behavior for different parser makes this all a pain with dshow inlcuding the Deinterlacing things to keep in mind and then the Interface side without hurting quality in any scenario and there are a lot of Playback Scenarios (content wise).
Just a big complex mess if you aren't doing everything in context from the Player on and in those regards you are heavily dependent on what the Vendors are doing in their Drivers also which Renderer they support with their implementations and so on
And in this equation isn't included the differences between NT 5 and NT 6 behavior, just if you would say only 1 OS keeping complexity small as possible is hard over multiple OS it gets crazy especially if you want to support all 3 major Vendors currently Intel, Nvidia , AMD (their you need to know the limitations then of every of their solutions also to make these decisions efficiently).
So somehow it's understandable that Intel says NT 6 support only :P

The easiest way is forcing EVR (its supported by everyone it supports Shader and with Aero tearing is history but it's not efficient as EVR-CP nor MadVR and then you get into issues again, user demands and hardware issues tearing performance because of Aero not supported or to slow)

[SeeMoreDigital]

Bummer!

[CruNcher]

So my concept was you have a Player and inside it a small benchmark and analyze logic that tests @ first your system Performance and the Performance of the Vendor Hardware your system consists of in your configuration (VPx,UVD,Quicksync) and based on these individual System benchmarks (Vendor API,DXVA) you can do the decisions for the most popular formats and playback scenarios which for every Vendor are the same VC-1,Mpeg-2,H.264. Though obviously this is only a part of the whole "Smart Playback Decisions" thing.

[Mustaffi]

when l play some H264 4:2:2 videos they are rare colors y random artifact all over....

screen: