LAV Filters - DirectShow Media Splitter and Decoders

[andybkma]

Originally Posted by sneaker_ger

Have you already tried the latest nightly (0.66.0-31)? If so, provide samples.

Not sure if you are responding to my post above yours because I obviously provided samples in my post (with download link)... but yes, the .66-31 has the same wmv splitter problems as .66

[sneaker_ger]

Yes, I was responding to you. (I overlooked the samples)
For me 478_SPV_.wmv plays&seeks using 0.66.0-31 but seeking takes very long (like 20 seconds). 489_SPV_.wmv plays but falls back to start on seeking attempt. No problem using Microsoft splitter. VLC seeks fast but playback seems stuttery or too slow.

[andybkma]

Originally Posted by sneaker_ger

Yes, I was responding to you. (I overlooked the samples)
For me 478_SPV_.wmv plays&seeks using 0.66.0-31 but seeking takes very long (like 20 seconds). 489_SPV_.wmv plays but falls back to start on seeking attempt. No problem using Microsoft splitter. VLC seeks fast but playback seems stuttery or too slow.

Yes my testing exactly... using LAV .65 also works great. It's that new wmv demuxer in LAV .66

[nevcairiel]

There is a long list of samples that didn't work so great on the old one, so its not so easy to judge. The goal is to fix/improve the new one, and not just switch back.
Anyway, my finding is that the first file works fine in playback, just seeking is slow. The second file stops playback after about 11 seconds and also doesn't seek beyond this point. Will see what can be done.

[LigH]

Although I replaced the MPC-HC internal copy of LAV filters with a just even also installed "nightly" (0.66.0-31) – so both available LAV filters, internal and external-DS, are most recent – MPC-HC just skips a webm created with vpxenc (v1.4.0-1562-g56cfbee) using VP10. Does it not yet contain a matching decoder? Or is the issue rather outside LAV Filters?

[nevcairiel]

What made you think VP10 would even be remotely supported?
Its bitstream is not even finalized yet, and of course there is no decoder in ffmpeg yet.

[LigH]

I didn't know any details about the specs development... was just surprised that VP10 could be enabled in vpxenc at all, already. So for now, the only way to test it seems to be in conjunction with vpxdec. Alright, will stay curious and look forward to reading about news "when it's done".

[andybkma]

Originally Posted by nevcairiel

There is a long list of samples that didn't work so great on the old one, so its not so easy to judge. The goal is to fix/improve the new one, and not just switch back.
Anyway, my finding is that the first file works fine in playback, just seeking is slow. The second file stops playback after about 11 seconds and also doesn't seek beyond this point. Will see what can be done.

Hi nev, thanks for taking a look at this. Also just noticed another problem with the new wmv demuxer in LAV .66... it has broken slow-motion with wmv files. With LAV .65, in Zoom Player I can press L while the wmv video is playing and it plays slow-motion. But with LAV .66 nothing happens... it still keeps playing at normal speed.

Thanks again

[thomponth]

Hi,

I am trying to build the LAV filters under Visual Studio 2015.

First, I have downloaded the source code of the LAV filters (v0.66).

Then, as indicated in the README file of LAV filters' source code, I have downloaded:
- the fork of ffmpeg from http://git.1f0.de/gitweb?p=ffmpeg.git;a=summary
- libblurray from http://git.1f0.de/gitweb?p=libbluray.git;a=summary
- IntelQuickSyncDecoder from sourceforge

However, Visual Studio 2015 does not find a file called "config.h" which is included in ffmpeg\libavcodec\mathops.h

I have searched on the Internet and I couldn't find any solution for this 'config.h" problem.

I guess some of you guys know how to build the LAV filters.

So could you please tell me how to fix this problem? Where is the config.h file that I should include.

Thanks in advance!

[nevcairiel]

config.h is auto-generated, use build.bat to build everything properly. Please note that I can't really give support to people trying to setup their own dev environment. LAV doesn't require anything special though.

[NTSky]

Hi,

I supported application that is using DirectShow Editing Services (DES) and it internally creates graph with circle connections and when LAV video decoder is used, the application is crashing, due to stack overflow.

The reason is "CLAVVideo::ReconnectOutput" method, that recursively enumerate filters through their connections, and as DES creates circle connection, recursion become infinite.

Need some help.

[nevcairiel]

What LAV Video does in that function is pretty standard dynamic reconnection for format changes, you should make your application deal with that. It cannot be disabled.

[NTSky]

"CLAVVideo::ReconnectOutput" method contains 2 calls of "CLAVVideo::FilterInGraph" method to check if "CLSID_madVR" or "CLSID_OverlayMixer" filters exist in a graph. But in "FindFilterSafe" function we have recursive call of itself with filters it is connected to, which cause infinite recursive in case of circle connections in a graph, that is not forbidden by DirectShow and work fine with other decoders.

[nevcairiel]

How would a circular connection make sense, you would never get any data out of the graph at the end, it would just roam in circles.
There is even an error code for this, namely VFW_E_CIRCULAR_GRAPH, which would suggest circular graphs are not all what you are making them out to be.

Tracking circular connections in those functions would be somewhat complex since they are recursive, so for now I'll just call it unsupported.

[andybkma]

Originally Posted by andybkma

Hi nev, thanks for taking a look at this. Also just noticed another problem with the new wmv demuxer in LAV .66... it has broken slow-motion with wmv files. With LAV .65, in Zoom Player I can press L while the wmv video is playing and it plays slow-motion. But with LAV .66 nothing happens... it still keeps playing at normal speed.

Thanks again

Hi nev, just want to make sure that the above report that the new wmv splitter has broken slow-motion didn't get lost in the shuffle. Thanks

[aufkrawall]

Hello,
DXVA2 CB requires more PCIe bandwidth than software decoding, or am I mistaken?
The frame has to be copied twice and decoded 4k 10 Bit should be quite huge. Especially bandwidth needed increases with frame rate.
Do you think PCIe 2.0 is sufficient for 10 bit 4k 60fps?
Would the bandwidth needed even increase more with BT.2020?

[nevcairiel]

I just build software, I don't really want to give hardware advice. You can calculate the bandwidth requirements yourself quite easily. 4k 10-bit is 3840x2160x3 (10-bit uses 24-bit for every 4:2:0 pixel, or 3 byte) bytes for every frame.
BT.2020 does not change anything on the memory requirements.

Personally I would never use something antiquated like PCIe 2.0, but thats just me. A system which still has PCIe 2.0 is way old as it is, and leaves no room to grow.

[aufkrawall]

Those calculations seem tricky, as I can hardly say if in practice the bandwidth for the 2x copy would be needed at once or if the requirements would be lower since the frame is copied serialized.
So I think practice will have to show this next year with new GPUs (I doubt anyone will test it before).

I just can tell you that in games (which are usually most critical regarding PCIe) PCIe 2.0 is hardly limiting at all.
My 2500k@4.8Ghz gave me ~117fps minimum in an absolute CPU limit in Star Wars Battlefront beta, while frametimes were absolutely perfect and no texture streaming was visible.
There were also some comparisons of Digital Foundry with several Intel gens at the same clock and several games and the performance gain of Ivy Bridge over Sandy Bridge was mostly not existing (no advantages for frametimes either).

[nevcairiel]

Games are usually not that limited by PCIe bandwidth. Tests have shown that running your GPU in x8 mode (say when running two GPUs) practically costs no performance at all, and even going down to x4 will only be a very marginal change in FPS - in current gen at least.
If I were to build a 4K HTPC right now, I would certainly make sure not to use PCIe 2.0 just to be on the safe side. I prefer to build with headroom rather than save a few euros.

But with the sad situation 4K TVs are still in this year (BT.2020, whats that?), and the lack of content, I postponed all that to next year anyway!

[aufkrawall]

It's out of question to buy a PCIe 3.0 able platform if you buy now or in future, yes. However, with Sandy Bridge it's very unattractive to change the CPU/MB yet.
But nothing to do about it if bandwidth really wouldn't be sufficient.

I suppose nobody here as a Sandy Bridge + GTX 960 system?