LAV Filters - DirectShow Media Splitter and Decoders

[Snowknight26]

Originally Posted by NikosD

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]

Originally Posted by NikosD

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

Originally Posted by Mercury_22

LAVVideo DXVA (N&CB) has big problems (big image "glitches") with this AVC (L3.2) file 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.
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]

Originally Posted by 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.

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.

Originally Posted by nevcairiel

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.
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
If you could close VC-1, without closing H.264 would be best case scenario
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]

Originally Posted by nevcairiel

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.

Originally Posted by 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.

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]

Originally Posted by NikosD

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]

Originally Posted by Snowknight26

Sure you can. Check the DLL properties.

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

Originally Posted by kasper93

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]

Originally Posted by NikosD

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

Originally Posted by Snowknight26

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.

Originally Posted by 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.

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) -- Zips: 32-bit & 64-bit

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?