LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

So I tried to build a work-around for the EVR P010 issues ... and EVR is being dumb and not letting me.

The general idea was to simply switch to NV12 if LAV detects that P010 is having issues instead of failing entirely.
However, I encountered an old bug in EVR which I fought with a long time ago already. EVR simply cannot change its input type once connected to a video decoder - which means an on-the-fly change to NV12 is not possible, unfortunately.

One potential solution would be to create a worker thread, stop the DirectShow graph, disconnect and reconnect LAV and EVR, and hope for the best. Its a very disruptive and noisy process, but considering that the only alternative would be to get no image at all, its probably the best.
I'll experiment some more..

Edit:
The alternate solution (which I wanted to avoid) was to outright block P010 with EVR. I would've liked it better if I could detect that its broken and only act then.
But guess thats not going to work. If MS ever fixes this (which I don't expect), a more elaborate check my be warranted.

[ocyl]

So I tried to build a work-around for the EVR P010 issues ... and EVR is being dumb and not letting me.

The general idea was to simply switch to NV12 if LAV detects that P010 is having issues instead of failing entirely.
However, I encountered an old bug in EVR which I fought with a long time ago already. EVR simply cannot change its input type once connected to a video decoder - which means an on-the-fly change to NV12 is not possible, unfortunately.

One potential solution would be to create a worker thread, stop the DirectShow graph, disconnect and reconnect LAV and EVR, and hope for the best. Its a very disruptive and noisy process, but considering that the only alternative would be to get no image at all, its probably the best.
I'll experiment some more..

Edit:
The alternate solution (which I wanted to avoid) was to outright block P010 with EVR. I would've liked it better if I could detect that its broken and only act then.
But guess thats not going to work. If MS ever fixes this (which I don't expect), a more elaborate check my be warranted.
nevcairiel,

Putting speed and quality considerations aside, would deselecting the P010 option in LAV Video settings serve as a valid manual workaround for those who are affected by the issue (not me)?

[nevcairiel]

If you just use EVR anyway, disabling that option is a usable workaround for now. However, ideally it shouldn't be required in the future, on most setups anyway.

[nevcairiel]

So there is some good news! 10-bit HEVC with DXVA2-Native seems to work just fine with EVR on Windows 10, at least on my GTX 960, so yay! Software P010 still fails, but LAV managed to fallback to NV12 now.
I'll have to make sure it doesn't explode badly on other systems though, so some testing will be needed.

[P.J]

So there is some good news! 10-bit HEVC with DXVA2-Native seems to work just fine with EVR on Windows 10, at least on my GTX 960, so yay! Software P010 still fails, but LAV managed to fallback to NV12 now.
I'll have to make sure it doesn't explode badly on other systems though, so some testing will be needed.

It doesn't work for me :confused:

[nevcairiel]

Thats because you assumed that your version of LAV already supports it. :p

[P.J]

Thats because you assumed that your version of LAV already supports it. :p

Ah, I thought it's v0.65.0-43 :D

Can't wait.

[NikosD]

Latest LAV 0.65.43 has fixed the P010 bug with Intel drivers.

I did the tests on Win 10 x64 - Drivers v4256 using 10bit H.265/H.264 clips.

It falls back instantly to NV12.

[nevcairiel]

I pushed a new "nightly" build with DXVA2-Native 10-bit HEVC decoding enabled.
I was only able to test with GTX960 on Windows 10, but with a bit of luck it may even work on Windows 8/8.1 with Intel Broadwell/Skylake hybrid decoders (although NVIDIA seems to not allow it on Windows 8.1)

http://files.1f0.de/lavf/nightly/LAVFilters-0.65.0-45.exe

Note that it won't work with MPC-HC, as MPC-HC blocks P010 with EVR to work-around the bug in EVR. I've already contacted the MPC-HC developers to see if we can't fix that situation.
It also won't work with madVR yet, but hopefully madshi can accomodate us eventually.

[Thunderbolt8]

but if it worked with madvr, would it be recommendable then since its dxva native and not copy back?

[NikosD]

Note that it won't work with MPC-HC, as MPC-HC blocks P010 with EVR to work-around the bug in EVR. I've already contacted the MPC-HC developers to see if we can't fix that situation.


Now that you can handle P010 bug internally in LAV Video, would it be safe for MPC-HC to just remove their workaround for P010 completely ?

[FreeFall]

nevcairiel,

I have a couple more problem Blu-ray Disc samples from Sentai Filmworks. It's the same problem I reported a while ago, playback stalls during the credits and then resumes after a while, DTS-HD audio for the video and credits with no audio. It doesn't seem to be a regression, it's just these two recent releases that have triggered the problem again. The difference is the credits are a part of the main video file instead of being a stand alone video stream like their previous releases.

Using MPC-HC 1.7.9 (x86), both playback ok with VLC and MPC-BE.

tvideo1 playback stalls at ~ 0:58 recovers shortly after
https://www.dropbox.com/s/u6p6fhbll8cdobj/tvideo1.m2ts?dl=0

tvideo2 playback stalls at ~ 1:49 takes longer, over a minute to recover
https://www.dropbox.com/s/zxcfoutcx9mhf63/tvideo2.m2ts?dl=0

Thanks,

FreeFall

[nevcairiel]

Get another audio renderer which keeps advancing the reference clock even if no audio is present. Nothing LAV can really do about it, it only decodes.

There is a lot of factors to consider. The Audio Renderer providing the reference clock, the Video Renderer and its reliance on the refclock, but LAV just outputs the video and audio as it is in the file.
LAV seems to be behaving properly however. If the buffers would be bigger, it might be able to "cheat" the system by buffering until the end of the file and avoid the problem like this, but buffering is limited in LAV right now, so thats not happening. I could imagine MPC-BE managing to "handle" it like that, just bigger buffers.

Maybe I should finally make them configurable to confirm that strategy.

[FreeFall]

Yeah, your probably right, I just tried the MpegSplitter.ax from MPC-BE's x86 standalone filters package and it works without any trouble (LAV Video / LAV Audio / MPC MPEG Splitter). I'm just using MPC-HC's default settings except using the DirectSound S/PDIF output to an older amplifier.

[nevcairiel]

I'll add an option to increase the buffering in LAV Splitter in the next nightly build. Setting it somewhat high will probably allow it to skip over short segments without audio without too much trouble.

[FreeFall]

Thanks, I'll test the new build.

[clsid]

VMR7 also fails with P010, so its probably a good idea to use the new workaround for that too.

[nevcairiel]

VMR7 is DirectX7, its like 20 years old, it should be removed as an option.

[P.J]

Note that it won't work with MPC-HC, as MPC-HC blocks P010 with EVR to work-around the bug in EVR. I've already contacted the MPC-HC developers to see if we can't fix that situation.

Then what player should we use for that? :confused:

[nevcairiel]

Any other? :p

[NikosD]

Then what player should we use for that? :confused:
Try DXVA Checker.

It's not a real player of course but you could try it to see if it actually works.

[P.J]

Try DXVA Checker.

It's not a real player of course but you could try it to see if it actually works.

Yup, it works :)

[NikosD]

Is there any difference in performance compared to DXVA copy-back with Nvidia 960 or in CPU usage ?

[P.J]

Is there any difference in performance compared to DXVA copy-back with Nvidia 960 or in CPU usage ?

Sure, less CPU/RAM :)

[ryrynz]

It is not a problem that I have personally, but an option would be useful considering that apparently there are people who do have issues. The tooltip could of course warn about the increased delay.

I agree with that. I've heard about issues with insufficient buffering a lot. Especially with live streams where data flow can be unstable.

Regarding the new maximum queue option that's been recently added, would it be worth specifying different queue sizes for local and web hosted content?

[nevcairiel]

For local content it doesn't really care that much how big the queues are, it works fine with pretty low queues most of the time, which has the lowest memory footprint and peak IO use, and having higher queues will only result in some peak IO activity during opening .. which would only be a problem on old systems where IO can really block the operation of other things.

So if you want higher queues for some content, like from the web, then just increase it overall.

Even a infinitely sized queue (with the memory limit increased appropriately) doesn't seem to cause any issues on a fast system with low-latency IO, so my 1gb media file is buffered into RAM after a couple seconds and thats that.
Of course anything can happen on slower systems with slow IO, or high-latency network connections, so just toy with the value if you experience buffering problems.

[ryrynz]

Thanks, I've been wondering if it would be beneficial to allow the media player to change this dynamically, any thoughts on that?

[nevcairiel]

Its a normal option, the media player could change it if it wanted to. Not sure I see the benefit in dynamic changes though.

[FreeFall]

Just finished testing the new build, using the values below fixed the problem with those two disc's allowing them to playback smoothly from start to finish.

Maximum Queue Memory: 1792
Maximum Queue Packets: 2450

Seven times the default values, lucky seven.

Cheers.

[nevcairiel]

On a quick glance, MPC-BE uses a default queue size of over 3000, so that would explain why theirs works out of the box.

[FreeFall]

In that case I might just bump the Queue's up another notch and make it an even 8 times the defaults to allow for a little extra headroom (Memory: 2048 / Packets: 2800). I'm not sure if the Memory Queue needs to be that high, that value just caps memory usage doesn't it?

[Aleksoid1978]

On a quick glance, MPC-BE uses a default queue size of over 3000, so that would explain why theirs works out of the box.

Now in MPC-BE we change working with queue - remove memory/packet's count limit. Now we use duration for queue limit. And - it's better, greatly reduce memory use ...

[clsid]

In that case I might just bump the Queue's up another notch and make it an even 8 times the defaults to allow for a little extra headroom (Memory: 2048 / Packets: 2800). I'm not sure if the Memory Queue needs to be that high, that value just caps memory usage doesn't it?
The default 256 MB is more than enough already for a packet queue of 2800.

50 packets is 1 second of audio and ~2 seconds of video.

[FreeFall]

Ok, thanks clsid.

[NikosD]

Hi Nev,

With videos from TV capture (and only from TV capture: live TV or recordings) I have macroblocs during fast motions in DXVA-native with EVR, EVR-Custom and madVR.
Everything is fine with Microsoft DTV-DVD Video Decoder.

I didn't had this problem with Windows 7 but I was with 15.28.23 drivers, now with Windows 10 it's 15.28.24.
This is a sample (1 min, 47 MB): http://www.mediafire.com/watch/v4o6ig9qhccvjko/M6HD-Capital.2015-08-09.20-58-012.mkv

My system:
Intel HD3000 (Sandy Bridge), drivers 15.28.24 (video driver 9.17.10.4229)
Windows 10 x64

Thanks

Latest Intel drivers on Windows 10 are known to have many problems with DXVA.

Plays perfectly here with Haswell iGPU 4600 - Win 10 x64 - Latest Windows Update drivers 10.18.15.4256.

I tried DXVA native with EVR and EVR-CP.

There are only some glitches at the very first few frames, but these are known occasional small issues with LAV Video decoder from the past.

MS DS/MFT is perfect once again, even at the very beginning of the clip.

I'll try with my Sandy HD 2000 on Windows 10 on Saturday.

If you haven't already done it, I would recommend a clean install of Win 10 - as always with any new OS.

MS DS decoder is using the exact same decoder device like LAV.

If MS plays fine, why LAV shouldn't ?

From the problems being mentioned in Intel forums regarding DXVA, I have none.

With Sandy's iGPU HD 2000 under Win 10 and latest drivers there are macroblocks not only using DXVA native but LAV DXVA copy-back too.

Both MS DS/MFT decoders are fine.

And because QuickSync decoder plays that file perfectly like MS, I think LAV's DXVA decoders probably need a little fine-tuning for Sandy.

@XinHong
Select QuickSync decoder from within LAV Video properties and you will be fine.

[nevcairiel]

If it worked on 7 or 8.1 and only broke after upgrading to 10, then I'm still going to wait for Intel to fix their other driver problems before caring, though. Broken on one OS only is usually a clear sign to some driver influence.

[baii]

Recently update mpc-hc nighties and notice there is a hardware quick sync/cuvid de-interlace option (maybe I was blind and didn't notice it), does this option have any difference compare to hardware de-interlace called from madvr? And is there any reason Amd is not available yet?

Sent from my 306SH

[XinHong]

@XinHong
Select QuickSync decoder from within LAV Video properties and you will be fine.

Thanks but I have switched DVBViewer to MS decoder, I want to keep DXVA because deinterlace and scaling seems to be better.

[NikosD]

Deinterlace and scaling should be exactly the same, because QuickSync decoder uses exactly the same algorithms and HW as it is essentially DXVA covered by Intel's MediaSDK.

[James Freeman]

When playing an HEVC file using DXVA2 copy-back (Active Decoder: dxva2cb direct) and ticking HEVC (enabled) with a non capable gpu like GTX660, I have a lot of presentation glitches (D3D9) or the backbuffer (overlay mode) empties every 2 seconds.
But when I disable HEVC (unticked) everything is back to normal.

[nevcairiel]

The hybrid decoding on those GPUs may cause issues, possibly due to memory bandwidth, nothing I can do.

Reliability of HW decoding is always at the mercy of a lot of external factors.

[James Freeman]

Hybrid?
It's not using the GPU at all, VPU is at 0% and still it says "Active Decoder: dxva2cb direct", resulting in a lot of glitches.

[nevcairiel]

Hybrid?
It's not using the GPU at all, VPU is at 0% and still it says "Active Decoder: dxva2cb direct", resulting in a lot of glitches.

VPU doesn't really show any activity for hybrid decoding.

In any case, if dxva2 is active, then some GPU must be offering to decode it. I can't help that this offer doesn't work properly. There is a checkbox to turn off HEVC DXVA2 for such cases.

[James Freeman]

Okay, thank you.
Maybe next gen GPUs will have full support?

[LigH]

GPU activity is only reported for the shader units, but not for the separate decoder chip. Please start to understand that there are many different chips (or at least chip areas) on a graphic card...

[nevcairiel]

Maybe next gen GPUs will have full support?

The GTX960 already does, as will the GTX950 which will release shortly, but those two are the only GPUs with full HEVC support (both 8 and 10-bit). Intel and AMD only have 8-bit decoders so far (and Hybrid for 10-bit).

[NikosD]

When playing an HEVC file using DXVA2 copy-back (Active Decoder: dxva2cb direct) and ticking HEVC (enabled) with a non capable gpu like GTX660, I have a lot of presentation glitches (D3D9) or the backbuffer (overlay mode) empties every 2 seconds.
But when I disable HEVC (unticked) everything is back to normal.

What HEVC clip, 8bit or 10bit ?

Does your driver install both HEVC_VLD_Main and HEVC_VLD_Main10 ?
You can use DXVA Checker to find out.

Why don't you use DXVA native and report back your results by monitoring GPU usage ?

Also check your CPU usage during SW decoding and DXVA (native or copy-back decoding).
Is it any different between all these modes ?

GPU activity is only reported for the shader units, but not for the separate decoder chip. Please start to understand that there are many different chips (or at least chip areas) on a graphic card...

He is reporting the right monitoring parameter - which is GPU usage in his case - since he doesn't have a pure HW HEVC decoder in his GPU in order to use it and he can only decode HEVC in hybrid mode using shaders.

You weren't so careful reading his post.

[foxyshadis]

Hybrid?
It's not using the GPU at all, VPU is at 0% and still it says "Active Decoder: dxva2cb direct", resulting in a lot of glitches.

Which GPU? Since you have two, the other one is probably doing the decoding. Make sure to check both.

[NikosD]

Which GPU? Since you have two, the other one is probably doing the decoding. Make sure to check both.
Ivybridge iGPU doesn't support HEVC, not even in hybrid mode.

[James Freeman]

What HEVC clip, 8bit or 10bit ?
8bit.
Does your driver install both HEVC_VLD_Main and HEVC_VLD_Main10 ?
HEVC_VLD_Main only.

Why don't you use DXVA native and report back your results by monitoring GPU usage ?
Native glitches less frequently, but still does.

Also check your CPU usage during SW decoding and DXVA (native or copy-back decoding).
Is it any different between all these modes ?
All three modes use the same amount of CPU for decoding.

P.S
The intel on chip gpu is permanently disable in the bios.
I talk strictly about the GTX600, In P8 State! which is downclocked to around 320 Mhz for both GPU and MCU.

In full power P2/P0 (full power) copy-back it is glitch free.
In P8 state, a glitch free presentation is only in SW (none) mode, or when HEVC is disabled.
So it does seem like the GPU is trying to do something and fails because of the low clock speeds thus resulting in presentation glitches.
All this with rendering times in the 20ms range (P8).