LAV Filters - DirectShow Media Splitter and Decoders

[sirhaden]

Originally Posted by nevcairiel

Content is output as fast as any downstream filter will receive it.

I have 2 video streams in a proprietary container that get demuxed in a custom demuxer and sent downstream to 2 separate instances of the LAV video decoder. One of the video streams is 30 fps and the second is 5 fps. The decoded streams are sent downstream to a custom picture-in-picture filter where synchronized PIP is performed before outputting a single image for rendering.

The problem is that the 5 fps stream arrives at the PIP filter out of sync, behind the 30 fps stream. A short delay is applied to the faster stream to allow the slower stream to catch up.

What is happening is that the slower stream's packets are not arriving fast enough from the LAV video decoder in order to resync the streams. Using an older version of ffdshow in the same exact architecture does not exhibit this behavior and the slower stream's packets are decoded and delivered fast enough to sync the streams and perform PIP.

Could this be due to the use of 2 instances of the LAV video decoder? Are there any known issues running multiple instances of the LAV video decoder?

[nevcairiel]

LAV Video does not implement any rate limiting at all. Like I outlined in my earlier post, it'll decode content as fast as it gets it from the source and the renderer accepts it.
Note that decoding can have a delay based on number of threads used and some codec properties, so you may allow for a bit more buffering to sync a low fps stream up properly to account for the delay.

There are no known issues running multiple instances at the same time.

[Manni]

Originally Posted by huhn

just set the display to 1080p60 for such a test.

I'm only interested in UHD HEVC Main10 decoding, so have no interest in testing anything at 1080p.

[nevcairiel]

The resolution or refresh rate is irrelevant if you just want to test *decoding*

[Manni]

Originally Posted by nevcairiel

The resolution or refresh rate is irrelevant if you just want to test *decoding*

You're right, I should have said I'm interested in playback performance at native resolution, so downscaling to a lower resolution doesn't really help to assess that.

Plus it's only with PowerDVD, and I care even less about that

[LigH]

To (more or less) "benchmark" AviSynth decoders, AVSmeter is quite useful. If DirectShow doesn't have similar tools, one may as well use it with a DirectShowSource script, despite a little overhead.

[NikosD]

DXVA checker can measure both DirectShow and MediaFoundation decoders, in both pure decoding mode (without renderer) and in playback mode using EVR at arbitrary resolutions.

[dansrfe]

How is the appropriate LFE mix level determined for a stereo output to satellite speakers which separates and routes low frequencies to a small sub?

[foxyshadis]

Originally Posted by dansrfe

How is the appropriate LFE mix level determined for a stereo output to satellite speakers which separates and routes low frequencies to a small sub?

Your sound card or speakers handles all of that. LAV doesn't do upmixing.

[Nullack]

Something unexpected is happening with VP9 playback on my Nvidia GTX 960

When testing this file phfx_4KHD_VP9TestFootage.webm I had expected to see LAV Filters nightly x64 slam the CPU since I have both VP9 DXVA 2 decoding disabled in the latest nightly of LAV filters, but also because AFAIK the Nvidia VP9 hybrid mode isnt working in current drivers. What I found in MPC-BE is that playing that test 4K VP9 file back, even though the renderer said that it wasnt using DVXA, I was seeing 48% GPU utilisation. I dont know how the GPU got so busy in assisting the playback of the VP9 file. The end result was that the 4K VP9 video played back smooth as silk.

[nevcairiel]

The VP9 software decoder is pretty well optimized, I wouldn't be surprised if it just managed to decode it on its own. Stuff doesn't magically get accelerated even though its all turned off.
The GPU usage was likely just from processing the video.

[Nullack]

Thanks. I wonder what processing it is doing then on the GPU? Its progressive so no deinterlacing needed. Maybe its some sort of colour conversion but I dunno cos I run a HTPC TV display in YCbCr 4:2:0 so I thought it just got all pushed through without fiddling for most content. And the source video is 4K, my display is 4K, so image scaling doesnt seem necessary. I tried to use mediainfo to see the source colour infos and so on but its not listing that information. Maybe the source colour is something strange. Still using a whole 48% of my GPU seems allot, thats like what I see with HEVC L52 DXVA 2 decoding.

[nevcairiel]

PCs don't operate in YCbCr, there will generally always be a RGB step, which is why YCbCr output is generally flawed.
So in your case, there is actually two conversions then, YCbCr from the video -> RGB in the renderer -> YCbCr for output.

[Manni]

Originally Posted by nevcairiel

PCs don't operate in YCbCr, there will generally always be a RGB step, which is why YCbCr output is generally flawed.
So in your case, there is actually two conversions then, YCbCr from the video -> RGB in the renderer -> YCbCr for output.

True, but if you send RGB to the display most of the time (at least with TVs and Projectors, not necessarily with PC Monitors) there will be an internal conversion to YCB first to apply controls like color and tint which can't be applied in RGB, then another conversion to RGB internally.

The best way to test for this is to see if you can still change color and tint on the display when sending RGB. If you can, then the display is doing an RGB > YCB > RGB internal conversion.

In that case sending YCB to the display means there is one less RGB > YCB conversion.

If color/tint are locked, then the display accepts RGB directly without any further internal conversion, and it can be better to send RGB from the PC as in that case you do get less conversions.

So it's usually a good idea to test what works best for each display.

[wanezhiling]

Hi nevcairiel, I suggest adding a 'Restore Default Settings' option in Start Menu, how about?

[nevcairiel]

Originally Posted by Manni

In that case sending YCB to the display means there is one less RGB > YCB conversion

Not really, you just do the conversion in the GPU instead of the display, still same amount of conversions. I'm not sure which would be of better quality.
In the case of YCbCr output from the GPU you have to hope that the conversion matrix and the inverse matrix in the TV are the same. If its all done inside the TV, you could probably safely assume that its the same.

[Isochroma]

Still no fix for the Doom9 fiefdom's censors, and still no fix or word from the author of buggy LAV Filters which won't install LAVvideo.ax on WinXP SP2.

It errors out instead, complaining about being unable to register the file.

Turns out - after I wasted half my precious afternoon investigating due to complete lack of documentation or software explanation - that the file is dependent on a certain function in Windows implemented in SP3+. That function is called GetLogicalProcessorInformation().

GetLogicalProcessorInformation() is un-necessary for the work performed by LAVvideo.ax. Instead it is another useless dependency designed to force users to change their entire operating system and undocumented on either of the author's websites and not checked for by the installer during installation, thus leaving users with a cryptic error message at the end and a nonfunctional video decoder.

There is no explanation on either of the software's websites and no specification of OS requirements.

The software does no checking during installation and instead trips all over itself finally falling apart on the last mile.

It's time the author took responsibility for his poor software coding and fixed it.

If he doesn't then he will never hear the end of this issue on a certain other site.

[davidsama]

I am pretty sure nevcairiel has said that he no longer supports windows xp or xp sp2 or xp sp3. Just because you refuse to upgrade to windows 7 does not mean that you can try to force other people to still support your 20+ year old os.

[Sparktank]

It is open source, afterall.

Nothing stopping anyone from forking the source to emphasise support for XP (esp. outdated service packs).

Surely, there must be some site out there that specializes in updates for XP ( <SP2 ) compatibility.

[manolito]

The current LAV filters install and work nicely under WinXP SP3. I still am a big fan of XP (but of course I also have a Win7 installation for the ever growing number of software which does not work under XP).

But I really don't see any good reason not to install SP3 under XP. At least for me and everyone I know the SP3 does not break anything.

@ Isochroma
You sure could use a little improvement of your netiquette...


Cheers
manolito