LAV Filters - DirectShow Media Splitter and Decoders

[NikosD]

It could also be very helpful if someone with an Nvidia or AMD card with hybrid, not pure, HW HEVC decoder could test this clip to compare MS MFT vs LAV in order to check out if it's Intel specific problem or hybrid specifically.

[Manni]

I'm happy to test with my HD7870 and also with the AMD R9 Fury I've ordered which should arrive tomorrow.

I don't know exactly how the HD7870 deals with HEVC, ie if it's CPU only or hybrid (I'm using Crimson 15.1.1), but I too have noticed that MPC-BE_LAV+MadVR (or EVR-CP) struggle more with HEVC files than PowerDVD15. I expect the Fury to use hybrid for 10bits HEVC.

I've noticed that frames tend to drop more at every shot transition, or when a long shot has a slow pan (so a lot of info that changes in each picture).

For example, if you look at the Exodus HEVC HDR 10bits trailer, PDVD 15 plays it almost perfectly, while MPC-BE+LAV struggles at each shot transition and towards the end of the shot with the temple at night, which is a long pan shot. I've set the GPU and CPU to the max (22) in MadVR, it helps but it doesn't get rid of all the stutter.

[nevcairiel]

I don't think the HD7870 supports any kind of HEVC acceleration from the driver side, unless thats a relatively new feature.

[Manni]

I don't think the HD7870 supports any kind of HEVC acceleration from the driver side, unless thats a relatively new feature.

Thanks, that's what I thought. Then is it useful if I test with the upcoming AMD R9 Fury which definitely has hybrid acceleration for HEVC?

[nevcairiel]

I've just pushed VP9 DXVA2 support to LAV, which will be available in the next nightly build tomorrow.
Note that there is some caveats to know about:

- Its limited to 4:2:0 8-bit (Profile 0), like most DXVA2 accelerators
- Its been tested on Intel Braswell only. Skylake will probably also work. Older Intel systems may not.
- While NVIDIA pretends to support VP9 DXVA2 on the GTX960, it does not actually work (black screen). I'm somewhat confident that its a driver problem, since it fails in rather specific ways that it otherwise shouldn't.
- When using DXVA2-Native and playing an unsupported file (4:2:2/4:4.4 or > 8-bits), you may get a black screen, since fallback to software may not catch the unsupported format early enough (Copy-Back does not have this issue, since it can fallback to software at any time)

Due to the limited amount of hardware that can actually make use of this, testing was also limited, so keep that in mind.
Its also disabled by default, due to all this.

[Thunderbolt8]

is it possible to manually update dcadec in LAV filters? I cannot find the .dll file in the installed directories. also, for some reason the DTS-HD bitstreaming field of LAV audio is greyed out for me.

[clsid]

is it possible to manually update dcadec in LAV filters? I cannot find the .dll file in the installed directories. also, for some reason the DTS-HD bitstreaming field of LAV audio is greyed out for me.
DTS-HD gets activated when you enable DTS.

[nevcairiel]

is it possible to manually update dcadec in LAV filters?

LAV is entirely open-source, you can rebuild it with a newer dcadec.
Other kinds of updates are not available.

Note that todays nightly contains the very latest version.

[Thunderbolt8]

DTS-HD gets activated when you enable DTS.right, completely forgot about that -.-

[Nullack]

G'day Hendrik. Very nice to see your commits into FFMPEG in the last few days with VP9 and now on my birthday, a nice little surprise with LAV filters nightly having VP9. I'm on GTX 960 and given your insights into nvidia's drivers I had not expected VP9 dxva2 to work currently. This is indeed the case sir, when playing back VP9 like phfx_4KHD_VP9TestFootage.webm. Using MPC_HC the app exits and will not display. Using MPC-BE the app tries to play, but stops immediately without exiting. Either case, no playback. Im on driver build revision 359.06. Cheers

EDIT: Also the tick in the VP9 checkbox to enable it, in the LAV Video Decoder app, that isnt persisting. I dont know if this is a feature where LAV auto unticks it cos it knows it failed, or if it's a bug where the GUI isnt remembering the user wanting it enabled.

[nevcairiel]

Please try to keep hardware benchmarks separate from this thread (NikosD has a thread dedicated to such things), or at the very least just post numbers and not screen filling screenshots.
Also keep in mind that Braswell is an Atom-CPU, so hybrid decoding of 4K is probably just too much for it.

[sirhaden]

Does the video decoder support decoding faster than real time? It seems that the default settings result in decoded samples being provided based on the sample duration.

[nevcairiel]

Does the video decoder support decoding faster than real time? It seems that the default settings result in decoded samples being provided based on the sample duration.

Content is output as fast as any downstream filter will receive it. Video and Audio renderers of course only receive content in real-time, since they are designed for that.

LAV Audio and LAV Video can deliver content as fast as your CPU can decode it (or your drive read it)

[Manni]

It could also be very helpful if someone with an Nvidia or AMD card with hybrid, not pure, HW HEVC decoder could test this clip to compare MS MFT vs LAV in order to check out if it's Intel specific problem or hybrid specifically.

I have an AMD R9 Fury tonight, it's leaving tomorrow.

Here is what it can do: https://dl.dropboxusercontent.com/u/7097546/LAV/AMD%20R9%20Fury%20DXVA%20Checker.png

When I run the decoding test with LAV set to DXVA copyback, here is what I get:
https://dl.dropboxusercontent.com/u/7097546/LAV/Test%20Fitness%20LAV%20HEVC%20Main.png

Not sure I'm doing it right, first time I'm running these kind of tests.

HEVC Main acceleration seems to work fine, but it looks like it's hardware, so not sure it's what you're after. I have no hybrid acceleration for any Main 10 file, but that might be the way I've set it up.

I can do more tests if you let know what you want me to do tonight, otherwise the GPU is going back tomorrow.

[Manni]

Just to add that I've done some tests with PDVD15 and I seem to get with it some hybrid acceleration for Main10 that I haven't been able to get from LAV.

With PDVD, the CPU is at 50% for my HDR test files of Exodus and even the more demanding Life of Pi one which it plays almost perfectly.
With LAV, CPU is close to 100% and I get dropped frames during transitions with Exodus and unplayable with Life of Pi.

I've set up LAV with DXVA2 copyback (tried native too) and renderer set to EVR-CP.

Maybe it doesn't like 10bits files because it works fine with the fitness test file and many other 8bits files.

[NikosD]

Fury has indeed a pure HW HEVC decoder, not a hybrid one, so it's not the case.

Regarding 10bit HEVC, Fury should have no HW support hybrid or pure HW acceleration.

The cpu usage of 50% of PowerDVD and 100% of LAV is not easy to explain.

DXVA2 copy-back or native with LAV has no difference for 10bit HEVC because they are not actually used with Fury, it falls back to SW.

Try "None" and see of there is any difference.

[Manni]

Fury has indeed a pure HW HEVC decoder, not a hybrid one, so it's not the case.

Regarding 10bit HEVC, Fury should have no HW support hybrid or pure HW acceleration.

The cpu usage of 50% of PowerDVD and 100% of LAV is not easy to explain.

DXVA2 copy-back or native with LAV has no difference for 10bit HEVC because they are not actually used with Fury, it falls back to SW.

Try "None" and see of there is any difference.

Thanks for this, it confirms what I thought. Sorry I couldn't help more.

I knew that the Fury had no hardware acceleration for Main10, but I was hoping for hybrid. As it's not the case - except for some reason with PDVD it seems, which doesn't really matter to me as I'm more interested in MPC-BE+LAV+MadVR performance - I decided last night to keep my HD7870 until Arctic Islands.

As I was only trying to provide the requested data and as the Fury is not relevant to your issue, I won't do more tests, the GPU is packed and going back today :).

[nevcairiel]

PDVD15 implements its own hybrid codec using OpenCL I think.

[Manni]

PDVD15 implements its own hybrid codec using OpenCL I think.

Ah thanks (I couldn't see your post in the other thread).

That explains it then :).

They did a pretty good job, the Main10 videos are anything from stuttering to unplayable without acceleration on my 3770K and play almost perfectly on PDVD with just 50% CPU use (up to about 50mbps).

I wonder how it would have dealt with NikosD's high bandwidth files (crowd run). I couldn't test as the bandwidth is too limited on HDMI 1.4 without the Club3D adapter as the files are 50p.

The best I could do without was 30p.

[huhn]

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

[sirhaden]

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]

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]

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]

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]

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]

http://i.imgur.com/S4NkVJq.png
Hi nevcairiel, I suggest adding a 'Restore Default Settings' option in Start Menu, how about?

[nevcairiel]

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

[foxyshadis]

This has to be one of the most insane demands I've ever heard, but at least you aren't cursing out the people trying to tell you it won't happen this time. When any software says it supports an OS without mentioning service packs, that always means it supports at least the latest service pack, but maybe not anything before it. That's obvious and expected; who would bother to keep around all previous versions, if they could even get hold of them, for the two people in the world who would ever try to install it that way? LAV can't possibly be the only thing that doesn't work on SP2.

[nevcairiel]

As others have mentioned XP SP3 still works fine, however any earlier versions are not supported, as they lack key Windows functions that LAV uses.

[Nullack]

Hi. Ive done some research but Im still confused about LAV Video configuration settings. Help would be great please.

Background: Only today did I realise my Samsung UHD 65" display has a special mode that I could have configured ages ago to do more than 2160P60hz with YUV 420. In this special UHD colour mode I can now do lots more settings. Two cases of note:

Case 1:
3840x2160P 60Hz
Output colour format: RGB
Output colour depth: 8bpc
Output dynamic range: Full 0 - 255

Case 2:
YCbCr444 but dynamic range goes to limited without beeing able to adjust it and 8Bpc stays the same

I assume case 1 would be better as a config? Since I get full dynamic range in RGB?

Now onto LAV Video specific settings.

RGB Output levels (for YUV -> RGB Conversion): I have it set currently to PC 0-255? Or should it be untouched?

And output formats. At the moment I have just RGB32 enabled. I'm confused though since 8Bpc on each R G B would be 24. For some reason the TV displays RGB32 output even though the nvidia control panel says it can only do 8Bpc. Should RGB24 be enabled, and RGB32 turned off, or both on as well? And given 8Bpc I think RGB48 should be disabled?

[nevcairiel]

You should generally not have LAV convert video to RGB, especially on UHD content its just going to be rather slow because it uses the CPU for that. Let your GPU do the conversion, its going to do it anyway, much faster at that.
RGB32 and RGB24 are both 8-bit RGB, the reason for 32 is that having data be aligned on powers of 2 is more efficient to work on, so it gets 8-bit of unused data added.

[Nullack]

Ok thanks. Ive set YUV to RGB as leave untouched and stuck with LAV video just having RGB32 as the only ticked output. As I assume that since Im outputting RGB 8Bpc full dynamic range to the display, thats what the display wants to see. Im trying to understand your response, I assume case 1 config is the right config to use for the display and hence I should set lav to just do RGB32 as the only output?

With playing back:

4K HEVC 10 Bit P010: Mixer Output RGB32, Input Type P010 : all seems OK playing this stuff. But then on this:

4K HEVC YUV 420: Input type NV12, Mixer Output NV12 Type NV12

So is that a bug? I told LAV to use RGB32 as the only allowed output yet it says its outputting NV12 for 8 bit HEVC?

Sorry if this is not a bug and its complex than I realise - Im trying to learn this stuff and Im a bit confused. :)

[nevcairiel]

If you use DXVA2-Native, then the output settings have no effect.
And you didn't seem to understand my response, since I said its better to not try to output RGB from LAV. :) The best quality and performance is usually achieved by not disabling any of the output formats and just letting the renderer handle the necessary conversions.
The options are only provided for testing and for renderers which have broken conversions - but many of the conversions in LAV are relatively slow. The CPU is just much slower at processing raw image data than a GPU would be.

[Nullack]

Thanks. So in DXVA 2 native none of the output settings matter. So even if I wanted to do something not recommended like get LAV to do RGB conversion, since Im in native mode it wont ever happen.

Since none of the settings will be obeyed, can I politely suggest it would be less confusing for the user just to disable that whole section of the GUI by greying it out when native is set? :)

I therefore assume when in DXVA native mode, the output mode
is "whatever it is" that gets forced in the whole stack and the user has no choice or decision to make.

[nevcairiel]

Since none of the settings will be obeyed, can I politely suggest it would be less confusing for the user just to disable that whole section of the GUI by greying it out when native is set?

Not every video can be decoded by DXVA2, since DXVA2 only supports a small range of video codecs.
Therefor disabling the settings makes no sense.

[Nullack]

Oh yes, I see ofcourse thats a global setting whereas for example some video codecs will go back to software. Thanks, you really are the master of this stuff :) I appreciate all the insights.

[Nullack]

Hi. Below in this thread is a description of a bug I had assumed to be a MPC-BE / MPC-HC problem. One of the MPC-BE Developers is saying I should raise it for the LAV Filters project. Basically on all three configuration tools for LAV, it works fine in high DPI and 4K situations when the three config tools are run by themselves. WHen however MPC-BE or MPC-HC is playing a video, and I right click into filters then one of the LAV configurators, the formats tab is all garbled up. Screenshots in the below link:

http://forum.doom9.org/showthread.php?p=1749525#post1749525