LAV Filters - DirectShow Media Splitter and Decoders

[STaRGaZeR]

PS:
For anyone wondering when 0.47 will be released, i only want to finish one feature, and then i would start preparing a release, so if everything goes well, the end of the week!

Good luck with that native implementation :D

[ryrynz]

With 0.27 of the QS decoder, and LAV and ffdshow now using the same settings, the upcoming LAV 0.47 and the latest nightly build of ffdshow perform basically the same, with a very minor loss for ffdshow, but nothing worth noting

Legend.

Didn't we agree to go testing higher resolution material? :)


Yeah I know that's a preference for development but when there's such a large discrepancy between versions with this clip and with it being the content I mostly play I figured I'd keep testing with it.

New test! same file, run 5x with high priority.

ffdshow 4322 egur 1580 FPS
LAV 09212cac599d 1647 FPS

We have a new winner, you've nailed it.

your system is just screwed up.

Guess you fixed it then :D Cheers.

[nevcairiel]

Guess you fixed it then :D Cheers.

Guess so!
Glad the optimizations also fixed your "problem", and i can really close the chapter on this for good.

[ddjmagic]

Quick question, I have a i3 2120 using MPC-HC w Lav Filters/EVR custom renderer. Under Lav Video settings - hardware decoder to use, I have 2 available options, Intel Quicksync or DXVA2 (copy) which option would be best? For BD and Remux playback ?

If your CPU supports it, use QuickSync. A i3 2120 should be fine with it.

Thanks for the help setting it to Quicksync works great.
I did try DXVA (copy) but it completely broke playback, there was blocking on the image and when I switched audio or subs it froze up and I had to restart MPC. Anyone have any idea why this could be?

[nevcairiel]

I did try DXVA (copy) but it completely broke playback, there was blocking on the image and when I switched audio or subs it froze up and I had to restart MPC. Anyone have any idea why this could be?

DXVA2 isn't fully compatible with Intel, i suggest to stick to QuickSync and don't worry about it.

[red5goahead]

Hi.

Lately I'm trying to add the support for the lav codec into an application for the italiansubs.net community . It's a VisualSubSync modded version of the original one (it wrote in Delphi 7)
(http://www.visualsubsync.org/). Since a long time I use the mpc-hc codec to build a own filtergraph. Lav is an awesome alternative because it have only 3 filters for all container and formats. No problems at all even using filter without any registration.
Only an issue with an mkv with a 6 ch. /ac3 . the center channel seems very lack of volume level . I don't know why. is it a known problem?
some questions:

Is it possibile to have a scaler filter or is it already avaiable?
Is it possibile to have into the audio interface some method to enable or disable some channel? When vss extract the audio to build its graphics wave would be nice enable only the center channel because the subtitles are related to the dialogues.

thanks.

edit: please note . the problem with the center channel is only with Plantronics 626 DSP usb headphone. using the realtek audio on board there are no issues. the same Plantronics 626 DSP do not have any problems with other audio decoder such as mpa audio decoder.
weird.

[nevcairiel]

Sounds like you suffer from missing downmixing, which means you only hear left and right channels, and the center is not mixed into the two.

[red5goahead]

A new question:

why a different channel mapping for lav and ffdshow?

lav->side left/right
ffdshow-> back left/right

http://img839.imageshack.us/img839/4433/ffdshow.th.jpg (http://imageshack.us/photo/my-images/839/ffdshow.jpg/)
http://img59.imageshack.us/img59/7567/lavt.th.jpg (http://imageshack.us/photo/my-images/59/lavt.jpg/)

probably this is the cause in Media Portal and it MP Audio Renderer that with lav I got no sound with my Xonar DX.

thanks.

[Midzuki]

A new question:

why a different channel mapping for lav and ffdshow?

lav->side left/right
ffdshow-> back left/right

...

It's because some people think the back channels are back channels, whereas other people think the back channels should be side channels. :p

BTW, Imageshack sucks terribly. :sly:

[kasper93]

probably this is the cause in Media Portal and it MP Audio Renderer that with lav I got no sound with my Xonar DX.

Have you set proper input/output channel number in Xonar Audio Center?

http://dl.dropbox.com/u/16282309/doom9/XAD.png

[mindbomb]

i dont understand why the asus software asks you to specify how many channels in the input.

seems like there should be an autodetect for that.

[kalston]

Because Asus can down/up mix according to your needs and convert everything to one single format.

[red5goahead]

Have you set proper input/output channel number in Xonar Audio Center?

http://dl.dropbox.com/u/16282309/doom9/XAD.png

Yes. the setup is correct. With ffdshow the Mp audio renderer work fine probably because those side channel is not supported by wasapi mode with the xonar.

[balkerman]

Anyway to enable Quicksync for use with an i3 clarkdale!

[egur]

Anyway to enable Quicksync for use with an i3 clarkdale!

Pre SandyBridge CPUs used a lower API version of the Media SDK.
Though it's probably possible to enable older Nehalem/Westmere era iGPUs, it not easy for me:
* I don't have a system to test this.
* The Media SDK DLL is not shipped with the driver. You'll need to install it (Media SDK 1.5). I can't find it on the web these days.
* The older API means that not everything will work.

I tried and failed to make it work on my Penryn based laptop.

I recommend using a SW decoder (or use your dGPU HW acceleration) for pre SNB systems. Sorry.

[nevcairiel]

Here goes.

http://files.1f0.de/lavf/LAVFilters-0.46-28-g0ad5245-dxva2n.zip

This build features a DXVA2 "native" decoder, which means it delivers the decoded image directly to the renderer, and never copys it back to system memory.
This is in line with all "classic" DXVA2 decoders, has no performance penalities from copying the frame, but instead has some limitations.

For example, the software fallback has to rely on the information it gets in the media type, if the information is incomplete or just plain wrong, and the actual movie is incompatible to DXVA, it will not be able to fallback to software at this point (neither will most other DXVA decoders, so this is nothing new).
Otherwise, it seems to work pretty ok in my limited tests, but i'm looking forward on feedback from other people.

Remember, only works with EVR and only on Vista/7. If you try to use it with any other renderer, it will automatically fallback to software.

Note that this is a beta build, so if you dare to test it, please report how it behaves for you, even if all is just going fine.
If you encounter issues, please always state your GPU and the driver version. Note that NVIDIAs 285 WHQL driver has a bug that breaks DXVA decoding.

[Thunderbolt8]

can the other copy back decoder also stay, because it works with madvr and post processing stuff, unlike the real dxva2 decoder. that one is useless for me.

[nevcairiel]

Why would you think something is being removed?
In that build the copy back decoder is broken, actually, but i'm fixing it. :p

[CruNcher]

Nice really nice though i guess most of the decoding issues with the DXVA copy back decoder also still apply for the native ?

[mbordas]

the new native dxva2 decoder gives me half the gpu usage versus cuvid on my gt 440 w/290.53 driver, at least on 1080p60 samples (~30% vs 16%). Hooray (I think?) How is that possible?

[nevcairiel]

GPU usage itself has nothing to do with the video decoding, its probably just a result from the frame copy that CUVID performs.
Personally, given the choice, i would stick with CUVID. Its developed to match NVIDIA cards perfectly, and thus much less error prone - unless you really have a reason to need that less GPU usage for something.

[noee]

HD6570 Win7 Ult x64: Blazing, works great.
HD6320 Win7 Home x64 (Llano A6): Blazing, works great.

(using MPC-HC with EVR-CP b.4075)

[dead_screem]

would it be possible to support hardware deinterlacing with software decoding either via CUVID or DXVA?

[nevcairiel]

would it be possible to support hardware deinterlacing with software decoding either via CUVID or DXVA?

Possible, yes, but its way too slow to be usable (copying the frame to the surface, and then back to system memory). The video processor surfaces copy way slower then the decoding render targets, for some reason. Blame GPU vendors. :p

[mark0077]

nev, maybe you already have this on your long term todo list. Is it possible to allow selection of certain decoders for certain media types. (Newer nvidia drivers for example don't like CUVID vc-1 decoding so I'd love to use QuickSync for that and CUVID for everything else). Might obviously require a fair bit of GUI work I guess.

[CruNcher]

yep i really wonder what goes wrong with the madoka bitstream http://www.mediafire.com/?b6ru372z4k3k2sn the only ones that playback that correct with DXVA are Arcsoft currently, and partly mirillis but they have still frame issues :)

[dead_screem]

Possible, yes, but its way too slow to be usable (copying the frame to the surface, and then back to system memory). The video processor surfaces copy way slower then the decoding render targets, for some reason. Blame GPU vendors. :p

nuts.

because I coulda swore atleast with DXVA(2 only? idk) that accessing the deinterlacer for software decoding was possible normally and infact done by commercial software already. maybe I'm mistaken...

[VipZ]

Thanks for the update nev :)

Did some testing with native DXVA2, in h264(HD) and VC1 all my test's are identical between native and copy back and play perfectly, also the power consumption is identical between the 2 modes on my system. There seems to be some issues with native mode with SD h264 content and WMV3 where all the same tests work with copy back, the video opens but just doesn't start.

[JarrettH]

There, i finished another round of optimizations in LAV, and benchmarked the QuickSync decoder again - as well as ffdshow for comparison.

Here is the link again:
https://docs.google.com/spreadsheet/ccc?key=0Ajo8vvjNtaZ5dC1abjBSeVlmcnZXSjYwampfamk3ZWc

To summarize:
With 0.27 of the QS decoder, and LAV and ffdshow now using the same settings, the upcoming LAV 0.47 and the latest nightly build of ffdshow perform basically the same, with a very minor loss for ffdshow, but nothing worth noting.

Now i can work on other things again. But first, sleep.

PS:
For anyone wondering when 0.47 will be released, i only want to finish one feature, and then i would start preparing a release, so if everything goes well, the end of the week!

Obviously support for DVDs :D

[NikosD]

Here goes.

http://files.1f0.de/lavf/LAVFilters-0.46-28-g0ad5245-dxva2n.zip

Note that this is a beta build, so if you dare to test it, please report how it behaves for you, even if all is just going fine.
If you encounter issues, please always state your GPU and the driver version. Note that NVIDIAs 285 WHQL driver has a bug that breaks DXVA decoding.

Good job Nevcariel.

It's working fine, very fine on the signature system.
It's working for VLD only, so we have all three formats DXVA accelerated:

H.264(Progressive, Interlaced)
VC-1 (Progressive, Interlaced)
WMV3

Performance numbers are on par with MS DS and the quality is very good.

I didn't do an exchastive test but I only found one case I didn't get HW acceleration.

It's the difficult VC-1 1080\60p sample:
Devil_May_Cry_Gameplay

ftp://helpedia.com/pub/multimedia/x264/testvideos/2010%20-%2009%20-%20DXVA%20benchmarks%20-%20Avivo%20vs%20PureVideo%20vs%20Clear%20Video/Devil_May_Cry_Gameplay.wmv

[nevcairiel]

I didn't do an exchastive test but I only found one case I didn't get HW acceleration.

It's the difficult VC-1 1080\60p sample:
Devil_May_Cry_Gameplay

ftp://helpedia.com/pub/multimedia/x264/testvideos/2010%20-%2009%20-%20DXVA%20benchmarks%20-%20Avivo%20vs%20PureVideo%20vs%20Clear%20Video/Devil_May_Cry_Gameplay.wmv

Simply playing that file in MPC-HC gives me HW accel just fine on my NVIDIA.

[NikosD]

The system tested is the signature's system


UPDATE:
I found out a lot of "similar" VC-1 clips not playing in DXVA on ATI's HW.
Copy-back mode worked fine for those clips.

UPDATE2:
A lot of 720 and 1080 WMV HD clips are not HW accelerated too
Copy-back mode worked fine for those clips.

Looks like a problem with ModeVC1_VLD.

[NikosD]

yep i really wonder what goes wrong with the madoka bitstream http://www.mediafire.com/?b6ru372z4k3k2sn the only ones that playback that correct with DXVA are Arcsoft currently, and partly mirillis but they have still frame issues :)

What exactly is the problem playing that file on ATi's cards in DXVA mode with any decoder (MS DS, LAV, CoreAVC) ?

I didn't see any.

[nevcairiel]

nev, maybe you already have this on your long term todo list. Is it possible to allow selection of certain decoders for certain media types. (Newer nvidia drivers for example don't like CUVID vc-1 decoding so I'd love to use QuickSync for that and CUVID for everything else). Might obviously require a fair bit of GUI work I guess.

I would suggest to get a newer NVIDIA card which has full VC-1 acceleration, and no problems anymore. :p

Anyway, i put that request onto my tracker, and maybe i'll do it some time, although i can't even picture how an UI would look. :/

[mark0077]

:D thanks v much nev, performance is fantastic in latest builds

[DragonQ]

Had an opportunity to test DXVA2 Copyback from LAV 0.46 on my i5-430M (pre-SB) laptop. CPU usage is as follows:

1080p24 AVC @ 9 Mbps: 11-12%
1080p24 AVC @ 24 Mbps: 15-16%
1080p24 VC-1 @ 19 Mbps: 20-22%

I have to use all output modes because if I leave just RGB32 ticked, CPU usage nearly doubles. I guess because there's simply more information to copy.

DXVA2 Copy-Back still doesn't like my 1080i25 AVC HDTV rips at all. Very slow and erratic playback, green areas appearing on the video, MPC-HC crashing, even IGP drivers crashing. These files play perfectly fine on my other machines using 0.46's CUVID and they also play decently on this laptop in software mode (~40% CPU usage, plays at 50 fps mostly but sometimes drops to ~40 fps with dropped frames, which is why I'd love a working hardware acceleration solution!).

[Snowknight26]

Works beautifully with every file I throw at it, even over RDP.

[Volfield]

I would suggest to get a newer NVIDIA card which has full VC-1 acceleration, and no problems anymore. :p

Anyway, i put that request onto my tracker, and maybe i'll do it some time, although i can't even picture how an UI would look. :/

What do you think about this: http://i39.tinypic.com/wl4qbc.png ?

[Aleksoid1978]

DXVA2 Native also bad playback H.264 MBAFF and Interlaced on Intel(Intel HD, without support QuickSync)

[RBG]

What do you think about this: http://i39.tinypic.com/wl4qbc.png ?

Looks fine to me. I am glad that I'm not the only one who is interested in separate profiles.:)

[wanezhiling]

Here goes.

http://files.1f0.de/lavf/LAVFilters-0.46-28-g0ad5245-dxva2n.zip

This build features a DXVA2 "native" decoder, which means it delivers the decoded image directly to the renderer, and never copys it back to system memory.
This is in line with all "classic" DXVA2 decoders, has no performance penalities from copying the frame, but instead has some limitations.

For example, the software fallback has to rely on the information it gets in the media type, if the information is incomplete or just plain wrong, and the actual movie is incompatible to DXVA, it will not be able to fallback to software at this point (neither will most other DXVA decoders, so this is nothing new).
Otherwise, it seems to work pretty ok in my limited tests, but i'm looking forward on feedback from other people.

Remember, only works with EVR and only on Vista/7. If you try to use it with any other renderer, it will automatically fallback to software.

Note that this is a beta build, so if you dare to test it, please report how it behaves for you, even if all is just going fine.
If you encounter issues, please always state your GPU and the driver version. Note that NVIDIAs 285 WHQL driver has a bug that breaks DXVA decoding.
:thanks:Nice nice!

I found a problem, WM ASF Reader --> DXVA2(native) , works for WMV(VC1) but not for WMV(WMV3).

And we know mpc-hc doesnt offer a option for ASF, so I got a blackscreen like this:
http://i.imgur.com/8MHlE.png (DXVA2 native is active.)

With Potplayer which I could use LAV Splitter Source for ASF, works fine.http://i.imgur.com/2Y5ZM.png


I download the wmv from microsoft.
http://download.microsoft.com/download/a/9/3/a9327df4-aeb5-46de-b438-d0f60da6fb54/Coral_Reef_Adventure_1080.exe


Edit:WM ASF Reader --> DXVA2(native) , not for all WMV(VC1), this (http://forum.doom9.org/showpost.php?p=1552284&postcount=8302) failed too(blackscreen).
http://i.imgur.com/SQtRY.png (DXVA2 native is active.)

[nevcairiel]

You can force MPC-HC to use LAV for wmv if you add the WM ASF Reader to the external filter list and set it to "Blocked".

I'll test with the WM ASF Reader when i get home, thanks for the hint that its causing the issues.

[wanezhiling]

You can force MPC-HC to use LAV for wmv if you add the WM ASF Reader to the external filter list and set it to "Blocked".


:thanks:a good way, now it works fine.~~
http://i.imgur.com/xunLm.png
http://i.imgur.com/fuU4E.png

[turbojet]

I'm using LAVF to serve avisynth for encoding but I'm noticing blocks with progressive VC-1 with a 9600GT (VP2) cuda enabled, here's a sample (http://www.mediafire.com/?mf493kovfh9da0p). All MPEG2 and AVC is fine and 99% of VC-1 is fine with cuda but always have at least a few blocky frames with every file. I've tried LAVF 0.45 and 0.46 with same results. I also tried nvidia drivers 285.62 and 270.61. Disabling cuda for VC-1 has no blocks but it's a ~30% slower encode. Playing the sample file in graphstudio or MPC-HC with LAVF there's no blocks, DGNV also has no blocks. Any idea what's going on?

Also encoded files decoded with LAVF are a little larger, sometimes significantly larger then files decoded with ffdshow, dgnv, microsoft. Is this dithering or something else? Is there any way to disable this?

[nevcairiel]

Any idea what's going on?
Nope, there is no reason the decoder should behave differently when used with AviSynth.

Also encoded files decoded with LAVF are a little larger, sometimes significantly larger then files decoded with ffdshow, dgnv, microsoft. Is this dithering or something else? Is there any way to disable this?

Dithering is not used for 8-bit material, unless you ask it to output RGB (but for encoding that wouldn't make much sense, i guess). Maybe those files are interlaced and LAV is deinterlacing them and outputting double framerate?

[turbojet]

The blocks are showing up when high-quality processing is enabled. Disabled they don't show on that sample, should one expect lower quality with it disabled when not deinterlacing?

The file size differences seem to depend on cuda. With it disabled LAVF is the same size as ffdshow, microsoft, and dgnv. Just did another short test and it's not always larger, lav-cuda was 8 KB smaller then the aforementioned decoders. The few times I've noticed different sizes with same x264 crf settings there's been an issue but this still looks fine.

One more thing, I was planning on using 64 bit for deinterlacing and 32 bit for ivtcing (or vice versa) but cuda deinterlaced output is not good for decimating and there's many missing/dupe frames but LAVF 32 and 64 bit properties are shared is there any chance to have them separated in a future version?

[nevcairiel]

The blocks are showing up when high-quality processing is enabled. Disabled they don't show on that sample, should one expect lower quality with it disabled when not deinterlacing?
No, it only matters for deinterlacing.


One more thing, I was planning on using 64 bit for deinterlacing and 32 bit for ivtcing (or vice versa) but cuda deinterlaced output is not good for decimating and there's many missing/dupe frames but LAVF 32 and 64 bit properties are shared is there any chance to have them separated in a future version?

In the future, maybe. Its yet undetermined.

[AJ73]

The x86 version of the LAV video decoder makes the graphedt.exe from the Windows SDK crash when clicking on "DirectShow Filters" in the filter selection dialog. This is not the case for the x64 version.

[nevcairiel]

The x86 version of the LAV video decoder makes the graphedt.exe from the Windows SDK crash when clicking on "DirectShow Filters" in the filter selection dialog. This is not the case for the x64 version.

Why do i have a FAQ? :)


Q: GraphEdit crashes after i installed LAV Video!
A: This is a GraphEdit bug. It will crash as soon as one filter supports more then 100 formats. There is nothing to be done. Personally, i suggest using GraphStudio instead!

[ajp_anton]

What do you think about this: http://i39.tinypic.com/wl4qbc.png ?
Was thinking the same, except skip the check boxes and just add a "None" as the top choise, as it is right now.