LAV Filters - DirectShow Media Splitter and Decoders

[kerimcem]

What kind of graphics card and which driver version?

old ati card ati 3650, 60.1(puplic) no problem and -23.02.2014 bulid no problem..24+ problem..(sorry bad english)

[nevcairiel]

Of course its old AMD cards, who else would have such a weird implementation that it doesn't follow the D3D specification. :p

Should be fixed again.

[GTPVHD]

http://blogs.msdn.com/b/vcblog/archive/2014/02/28/avx2-support-in-visual-studio-c-compiler.aspx

[clsid]

That is totally useless since LAV Filters must work on all modern CPUs, not just the ones that support AVX2. Plus, the FFmpeg stuff is compiled with GCC instead of Visual Studio.

[nevcairiel]

Since everyone is always looking for nightly builds, here is the latest:

x86: http://files.1f0.de/lavf/LAVFilters-0.60.1-61-g830839c.zip
x64: http://files.1f0.de/lavf/LAVFilters-0.60.1-61-g830839c-x64.zip

Its pretty close to a release, so if you find any annoying errors in it (especially regressions), let me know.

Maybe I should setup my own automated nightly builds, hmm..

[NikosD]

I saw a huge increase in QuickSync decoder dll in x64 file only.

Is there something new in that ?

Regarding DXVA, nothing really changed from the latest nightly before yours:

MPEG-2

Pauses video for a sec, while playing audio after seeking
http://www.sendspace.com/file/jm10xo - QS plays fine

Doesn't start decoding (MPC-HC is OK)
ftp://helpedia.com/pub/multimedia/x264/testvideos/2010%20-%2009%20-%20DXVA%20benchmarks%20-%20Avivo%20vs%20PureVideo%20vs%20Clear%20Video/test-g1-1.mpg

VC-1/WMV3

Every HW decoder has heavy artifacts, but QS is perfect with external LAV
MPC-HC refuses to decode it in QS!
http://www.sendspace.com/file/aep5vn

H.264

Heavy artifacts after seeking
http://www.sendspace.com/file/9p8xa0

P.S

For me, still DXVA-CB has half performance of DXVAn

[nevcairiel]

Pauses video for a sec, while playing audio after seeking
http://www.sendspace.com/file/jm10xo - QS plays fine

Seems fine here, but its also pretty normal for something like this to happen in .mpg files after seeking.
Seeking is not an exact science in mpeg files, since they don't have a seeking index. It has to fix A/V sync sometimes.


Doesn't start decoding (MPC-HC is OK)
ftp://helpedia.com/pub/multimedia/x264/testvideos/2010%20-%2009%20-%20DXVA%20benchmarks%20-%20Avivo%20vs%20PureVideo%20vs%20Clear%20Video/test-g1-1.mpg

Plays just fine in different players and in GraphStudio for me.


Every HW decoder has heavy artifacts, but QS is perfect with external LAV
MPC-HC refuses to decode it in QS!
http://www.sendspace.com/file/aep5vn


This file uses WMV9 Complex Profile. This profile is not supported in hardware, and QuickSync always falls back to software for me.
I'll add a check to fallback from DXVA2 as well.


Heavy artifacts after seeking
http://www.sendspace.com/file/9p8xa0


This also happens in software mode, seems like a bug in the ffmpeg library.

[NikosD]

Seems fine here, but its also pretty normal for something like this to happen in .mpg files after seeking.
Seeking is not an exact science in mpeg files, since they don't have a seeking index. It has to fix A/V sync sometimes.


OK, but sometimes you do some magic and fix A/V sync.


Plays just fine in different players and in GraphStudio for me.


I try to play/ benchmark it in DXVA Checker and just stalls at the beginning.

Also in x86 version of MPC-HC, the clip has no seeking capability - the slider stalls at the beginning
In x64 version of MPC-HC, the slider moves on normally


This file uses WMV9 Complex Profile. This profile is not supported in hardware, and QuickSync always falls back to software for me.
I'll add a check to fallback from DXVA2 as well.


Thanks.


This also happens in software mode, seems like a bug in the ffmpeg library.

Thanks for the info.

[NikosD]

What about UVD/UVD+ and this post ?



@nev

After upgrading my old system (AthlonXP - Radeon 3650 AGP (UVD+) - Cat. 13.9) from Windows XP to Windows Vista (unfortunately it can't take Win 7 due to driver conflict), I had the opportunity to try LAV Video and MPC-HC 1.7.3 for the first time using DXVA with UVD+ (because LAV filters don't support Windows XP DXVA1)

I can say that I had a better experience than using PotPlayer for all the clips that UVD+ and LAV Video DXVA can decode.

BUT once again like UVD2.2 (Radeon 4000/5000 series) there were a lot of restrictions for clips that UVD+ could decode:
Codec restriction, Resolution restriction, ReF number restriction - it's like you follow exactly the BluRay specs for H.264

The main restrictions are:

1) No WMV3 HW acceleration (it's disabled for unknown reason)

2) No above 1080p H.264 HW acceleration - like 2048 x 1280

3) No H.264 1080p Ref 5/6 HW acceleration (it's restricted to Ref 4)

4) No H.264 720p Ref 12 HW acceleration (it's restricted to Ref 9)

All of the above files play flawlessly with PotPlayer in DXVA mode and UVD+, so those are not driver/ HW restrictions, only LAV Video restrictions.

So, if you don't want to leave driver to handle those situations by default and you don't want to test every possible combination of ATI HW decoder (UVD, UVD+, UVD2, UVD2.2) and various clips, resolutions etc I have a suggestion for you.

Make a "secret/ hidden" button named "Use DXVA anyway" or "Force HW acceleration" or something like that, in order to give power users a chance to test - in their own responsibility - DXVA acceleration in their systems in situations where you decided to disable it.

That option should have no restriction/ limitation by LAV Video and should leave everything to the driver and the other DXVA options of LAV Video (like codecs and resolution)

I think you have to loose some restrictions and gain more flexibility and options for the people who know what they do.

Of course that option will be disabled by default.

[nevcairiel]

I may add options later to disable compatibility checks, but for now from all I've tested and users reported, UVD/UVD+ likes to fail a lot on clips over L4.1.

PS:
No player I ever tested had working WMV3 HW Accel on my 3650 PCIe - including PotPlayer, just falls back to software.

[NikosD]

This is generally true, UVD/UVD+ is a restricted HW decoder, but can play some > L4.1 clips

Also, I think you could enable WMV3 HW acceleration without problems and besides compatibility checks you could remove some resolution restrictions too for all ATI products which are capable of 2K HW decoding.

[nevcairiel]

I just tested WMV3 two weeks ago on the 3650, after fixing all the issues with decoding on Intel, but it still only outputs artifacts, no use in activating that.

[hoborg]

This is generally true, UVD/UVD+ is a restricted HW decoder, but can play some > L4.1 clips

Hi.
If i remember correctly, there is limit in ref. frames for L5.1, i think it was 8, but not sure.

[NikosD]

This is an "interesting" file in which the first 32 frames say that is Sorenson Spark, but after that it's all H.264!

http://www.sendspace.com/file/qcd0zq

Is it possible to "skip" those first 32 frames and look further in the file in order to be treated as a HW accelerated clip ?

It's a 4096x3072@118fps clip !!

Hi.
If i remember correctly, there is limit in ref. frames for L5.1, i think it was 8, but not sure.

Yes, something like that. I have tested 1080p L5.1 Ref 5 and 6 clips and play fine with UVD+.

[nevcairiel]

you could remove some resolution restrictions too for all ATI products which are capable of 2K HW decoding.

I changed the check today so that its based on number of macroblocks, and not individual dimensions. It should allow for more 2K resolutions, while still blocking 4K.

Remember that any resolutions over FullHD require the UHD checkbox to be checked in LAV Video settings, that includes those 2K clips over 1920x1080

[NikosD]

Great, looking forward to test it.

[NikosD]

Maybe I should setup my own automated nightly builds, hmm..

That would be best practice for all.

[NikosD]

Remember that any resolutions over FullHD require the UHD checkbox to be checked in LAV Video settings, that includes those 2K clips over 1920x1080

Maybe that should be enabled by default, in case doesn't harm VP4, Sandy or older HW decoders that can't do more than FullHD.

Because a lot of people even with VP5 or Ivy/ Haswell don't know that they have to enable it in order to get 4K HW acceleration.

[GTPVHD]

http://us.download.nvidia.com/XFree86/Linux-x86/334.21/README/supportedchips.html

GeForce GTX 750 Ti 0x1380 E
GeForce GTX 750 0x1381 E
GeForce GTX 745 0x1382 E

Nvidia has confirmed the Maxwell hardware decoder is Feature Set E, Kepler is Feature Set D.

GPUs with VDPAU feature set E support an enhanced error concealment mode which provides more robust error handling when decoding corrupted video streams. This error concealment is on by default, and may have a minor CPU performance impact in certain configurations. To disable this, set the environment variable VDPAU_NVIDIA_DISABLE_ERROR_CONCEALMENT to 1.

[NikosD]

Maybe I should setup my own automated nightly builds, hmm..

Another very helpful issue regarding nightly builds, would be an extra number after the main version.

For example 0.60.1.78, this is what MPC-HC is doing with LAV internal filters.

Because as it is right now, you can't really know which exactly nightly version is registered in your system.

They all are 0.60.1

[Snowknight26]

Because as it is right now, you can't really know which exactly nightly version is registered in your system.

Sure you can. Check the DLL properties.

[kasper93]

Because as it is right now, you can't really know which exactly nightly version is registered in your system.

Probably because there isn't any nightly builds of LAV. Why do you just trying to find problems with everything? As you noticed yourself LAV shipped with MPC-HC have build number and I'm not aware of any other source of LAV builds. Except rare test build posted in this thread. It's distributor responsibility to care about such things, and since LAV doesn't have official nighties distributions it's not needed until it have.

But you know you can always send a patch it's open source project after all. And saying to others what they could and couldn't do is not the best way of doing things. Especially when you're talking about non existing features.

But well I don't care, I just find it little bit annoying that you send few posts in row, quote own posts and so on. If you have bugs just send them to https://code.google.com/p/lavfilters/issues/list rather than reposting over and over same things... (but only if there is really a need to do so...)

Snowknight26: +1

[Mercury_22]

@ NEV I see you've done some work on the DXVA but this (seeking) problem LAVVideo DXVA (N&CB) has big problems (big image "glitches") with this AVC (L3.2) file (http://www.multiupload.nl/OKHM9WLH69) on subtitle (PGS) enable / change and on seeking

P.S. Latest LAV git here still exist, at my end at lest.
It's just me ?

[nevcairiel]

Seeking works fine for me on that sample, at least in the first 100mb, your file hosts are slooow.

[NikosD]

I installed latest *non-existent* nightly build from betaking and I decided to run a thorough test of my ~600 HW accelerated samples (H.264, MPEG2, VC-1, WMV3) using DXVA native and latest nightly of MPC-HC 1.7.3.72 with LAV internal 0.60.1.40

I had 4K option enabled in both LAV and MPC-HC for all systems.

1st system is a Win 8.1 Pro x64 with Nvidia GT440 (VP4) PC

Not a single bug or artifact, flawless decoding and it really decodes everything up to 1080p60.

2nd system is a Win 8.1 Pro x64 with Radeon 5750 (UVD2.2) PC

Not a single bug or artifact, but surely not flawless decoding even for "easy" clips.

It's the first time that LAV is on par with MS DS/MFT and PotPlayer regarding resolution restrictions on AMD HW.

I can play those H.264 above FullHD movie trailers at 2048x1280 for the first time using LAV and DXVA!

But the decoding of most of my H.264 files are not as flawless as Nvidia using MPC-HC 1.7.3.72.
Maybe the next update of MPC-HC to LAV latest version could help, but I think the problem is somewhere else.

For every seek and every move of the slider, forward or backward I had a lot of frames dropped and even when I had zero dropped frames, the fluidity of decoding was inferior to VP4, even for easy clips.

Driver's imperfection ?
Less worked code for AMD HW ?

I don't know...

3rd system is a Vista x86 with Radeon 3650 (UVD+)

Not a single bug or artifact like the other systems, but not as fluid as Nvidia.

It has a feeling of better fluidity than UVD2.2 ! and less dropped frames.

I can play those H.264 above FullHD movie trailers at 2048x1280 for the first time using LAV and DXVA with that 2007 card too!

It has one bug though in VC-1 files.

It seems that the removal of resolution restrictions allows 3D VC-1 files with resolutions like 1024 x 1536 or 1280 x 1440 to be HW accelerated in DXVA but with artifacts.

Same resolutions in H.264 format are decoded without errors by UVD+

I will go back to original 0.60.1 to see if that happens too when 4K is enabled or it is something new.

[nevcairiel]

Seeking is less fluid when the decoder is slower. Even VP4 is quite a bit faster then UVD2.2, which may account for this.
Seeking is generally better in MP4/MKV files, and worse in TS/MPG files.

Regarding the VC-1 errors, you wanted to let the decision up to the driver which files to play. Looks like the driver doesn't know what it can actually play. :p
Luckily the drivers for the newer cards (ie. not-legacy) apparently has learned to not accept out of range resolutions.

I suppose I could add the old check back for VC-1, and only allow higher for H.264.

[NikosD]

Seeking is less fluid when the decoder is slower. Even VP4 is quite a bit faster then UVD2.2, which may account for this.
Seeking is generally better in MP4/MKV files, and worse in TS/MPG files.


True, but the whole experience and feeling is not on par with Nvidia.
It's not about performance, I had that feeling for easy 24p or 25p clips.


Regarding the VC-1 errors, you wanted to let the decision up to the driver which files to play. Looks like the driver doesn't know what it can actually play. :p
Luckily the drivers for the newer cards (ie. not-legacy) apparently has learned to not accept out of range resolutions.

I prefer this situation than restricted resolution for H.264 :p
If you could close VC-1, without closing H.264 would be best case scenario :D
I've just read your updated answer, it's exactly what I wrote you above :)

UVD2.2 can play those 3D VC-1 files with no artifacts at all, so if you could choose only UVD+ to close it.

[NikosD]

I suppose I could add the old check back for VC-1, and only allow higher for H.264.

I've just tested 0.60.1 official and even with 4K enabled, it doesn't allow VC-1 to be decoded in DXVA.

So, the best solution is to close only VC-1 for only UVD/UVD+ above FullHD.

I just tested WMV3 two weeks ago on the 3650, after fixing all the issues with decoding on Intel, but it still only outputs artifacts, no use in activating that.

Just tested my 3650 with latest Catalyst 13.9 using PotPlayer and decodes every WMV3 flawlessly in HW.

Maybe different driver version than yours ?

[nevcairiel]

Last time i tried PotPlayer, it used software decoding. Are you sure it uses hardware?

[NikosD]

Yes I can see it displaying DXVA in OSD and UVD+ clocks go to maximum while CPU usage goes to minimum.

With my AthlonXP 2600+, DXVA is the only way to decode 1080p WMV3 clips.

[sneaker_ger]

True, but the whole experience and feeling is not on par with Nvidia.
It's not about performance, I had that feeling for easy 24p or 25p clips.
User experience on seeking is highly influenced by performance. The longer the distance to a key frame the worse it gets.

[NikosD]

Sure, you are right but I'm talking about a slight stuttering even in normal playback of easy clips that gets worse when seeking.

I don't know, maybe the use of Intel's DXVA and VP5 has raised my standards too high :)

Or maybe it was the refresh rate of the display, it was a different display than VP4 tests.

I will repeat the tests again sometime, just to be sure.

[NikosD]

Sure you can. Check the DLL properties.

Which DLL exactly and what properties ?
File properties ? Looking for what ?

Probably because there isn't any nightly builds of LAV. Why do you just trying to find problems with everything? As you noticed yourself LAV shipped with MPC-HC have build number and I'm not aware of any other source of LAV builds. Except rare test build posted in this thread. It's distributor responsibility to care about such things, and since LAV doesn't have official nighties distributions it's not needed until it have.

But you know you can always send a patch it's open source project after all. And saying to others what they could and couldn't do is not the best way of doing things. Especially when you're talking about non existing features.

But well I don't care, I just find it little bit annoying that you send few posts in row, quote own posts and so on. If you have bugs just send them to https://code.google.com/p/lavfilters/issues/list rather than reposting over and over same things... (but only if there is really a need to do so...)


"Officially" there are no nighlty builds, but there are people compiling LAV filters almost after every code change.

And because nevcairiel said that he could offer nightly builds himself, I suggested to put an easy identified numbering scheme for easy reference of the new version.

What's the big deal ?

It's only a suggestion and if he feels that it's not easy or worth to do it, he won't do it.

Nevcairiel doesn't need laywers or representatives to speak instead of him.

[Snowknight26]

Which DLL exactly and what properties ?
File properties ? Looking for what ?

Any DLL that is compiled for LAV Filters. Check the Product version property of the file.

[XadoX]

Since I changed my HTPC system to Haswell from ATI. Sould I stick with QuickSync for now or should I still prefere DXVA?

[nevcairiel]

I prefer DXVA2, Native if possible, but Copy-Back also works quite nicely on Intel systems (at about the same performance of QuickSync now)

[XadoX]

Are there any benefits in using QuickSync.
The power consumption seems to be a little bit higher @QuickSync (around 0.8 Watt in my Case).

[NikosD]

@nev

Latest nightly works perfectly with my UVD+.
2K for H.264, FullHD for VC-1.

Only reference frames restrictions still exist and WMV3 acceleration to call it perfect decoder :)

Also I saw a "silent" update for QS decoder, from 0.44 to 0.45

Any DLL that is compiled for LAV Filters. Check the Product version property of the file.

It doesn't seem to work because almost every 0.60.1.x version says "2.1.git", only the latest says "2.2.git"

Also it's extremely inconvenient.

Sure, you are right but I'm talking about a slight stuttering even in normal playback of easy clips that gets worse when seeking.

I don't know, maybe the use of Intel's DXVA and VP5 has raised my standards too high :)

Or maybe it was the refresh rate of the display, it was a different display than VP4 tests.

I will repeat the tests again sometime, just to be sure.

Problem solved with ATI hardware and MPC-HC (LAV filters internal)

I had to change the renderer from EVR to EVR-CP, which is the default for MPC-HC.

It seems that slight stuttering and not perfect decoding appeared after the EVR selection instead of the default EVR-CP.

I'll wait for the new MPC-HC with latest LAV inside (because it's still 0.60.1.40) to do another round of tests, just to be 100% sure.

[nevcairiel]

LAV Filters 0.61.0

LAV Splitter
- NEW: Support for "demuxing" AviSynth scripts (requires AviSynth, 2.6 recommended)
- NEW: Support for reading ICY stream metadata from ShoutCast streams
- Fixed: The duration of DVB MPEG-TS files is being detected more reliably
- Fixed: The ITrackInfo interface was not available in the last few versions
- Fixed: The duration of certain Ogg Vorbis streams was wrong
- Changed: DTS-HD audio tracks are now exposed using the official DTS-HD media type, in addition to the old DTS type
- Workaround: Block WMP/WMC from always overwriting the initial track selection

LAV Video
- NEW: Support for Duck TrueMotion 1/2
- NEW: Support for BT.2020 in YCbCr -> RGB conversions
- Fixed: Format conversion could cause out of memory errors when converting high-resolution videos
- Fixed: The decoder could crash if DXVA2 decoding failed and the software decoder is unavailable
- Fixed: Reduced binary bloat caused by the YCbCr -> RGB converter, reducing binary size to nearly half
- Fixed: Playback of RV30/RV40 was not smooth in 0.60
- Fixed: Video corruption when using DXVA2 on Intel GPUs when decoding certain VC-1 or MPEG-2 clips
- Fixed: Decoding WMV3 Complex profile automatically falls back to software, since hardware decoding is unsupported
- Faster: DXVA2 Copy-Back decoding on Intel GPUs is significantly faster
- Changed: If the wmv9dmo decoder is unavailable, the FFmpeg decoder is automatically used instead
- Changed: Updated QuickSync decoder to the latest version, fixes a few timestamp issues
- Changed: Relaxed the resolution checks for H.264 decoding on AMD GPUs, allowing files with 2K resolutions to be decoded (ie. 2048x1280, etc.)

LAV Audio
- NEW: Support for ATRAC3+
- Fixed: Decoding AC3 audio could produce glitches in playback due to too aggressive error checking


Download: Installer (both x86/x64) (http://files.1f0.de/lavf/LAVFilters-0.61.exe) -- Zips: 32-bit (http://files.1f0.de/lavf/LAVFilters-0.61.zip) & 64-bit (http://files.1f0.de/lavf/LAVFilters-0.61-x64.zip)

This release contains mostly a collection of small features, fixes and improvements, with a bit of focus on DXVA2 improvements, especially for (but not limited to) Intel GPUs.
Nothing big really worth mentioning, otherwise.

As you can see, I've taken a cleaner approach at writing the changelog, the unorganized entries in the past always bugged me a bit, but not enough to do something about it. :)

A small announcement: Since Google Code has shut down its file hosting, I'm looking into setting up my own website for LAV where I can host builds in a more orderly fashion, with version archives and everything.
I'm not sure when I'll actually get to do that, but for the people that get it from Doom9, nothing much will be changing anyway.

In the interim, the latest builds are also available from GitHub now, and the older builds are still on Google Code.

Have fun!

[DragonQ]

Do you have any milestones you're waiting for before incrementing the version to 1.0?

[wanezhiling]

http://i1.tietuku.com/05d31b75e0014571.png
Oops! What's wrong? :devil:

[nevcairiel]

Not a admin prompt?

[wanezhiling]

Not a admin prompt?

Admin, UAC is totally off.
And 0.60 is fine.

[Snowknight26]

Not a admin prompt?

It's because LAVFilters.Dependencies.manifest is missing from the zip for the 32-bit version.

On a related note, install_all.bat is missing from the zip for the 64-bit version.

[nevcairiel]

install_all.bat was never meant to be included really, I must've accidentally included it instead of the manifest ... I wonder how that happened o.o

I uploaded a new zip file, no reason to post an entire new version for that.

[vood007]

I wonder how that happened o.o


Its Murphys Law. You can beta test for 7 years, your will find a breaking bug 5 minutes after release ;)

[Toku]

LAV Filters 0.61.0
LAV Video
- Fixed: Format conversion could cause out of memory errors when converting high-resolution videos

Ohh wow, glad to see this. Been having issues with out of memory errors every now and then with mpc-hc recently, even though I have plenty of memory free. Hopefully this was my issue...

[nevcairiel]

Ohh wow, glad to see this. Been having issues with out of memory errors every now and then with mpc-hc recently, even though I have plenty of memory free. Hopefully this was my issue...

Somehow I doubt it.
Its not easy to actually trigger this issue, it requires some special interaction with the decoder, which can be triggered by some post-processing filters, or some really bad renderers, but default out-of-the-box playback wasn't affected.

[Toku]

Somehow I doubt it.
Its not easy to actually trigger this issue, it requires some special interaction with the decoder, which can be triggered by some post-processing filters, or some really bad renderers, but default out-of-the-box playback wasn't affected.

Oh okay, well If this issue comes up again I guess I'll start experimenting to see if I can figure out what's actually causing it.

[XadoX]

Sorry for bugging.
Are there any benefits in using QuickSync.
The power consumption seems to be a little bit higher @QuickSync (around 0.8 Watt in my Case).