LAV Filters - DirectShow Media Splitter and Decoders

[lvqcl]

Hardware decoding engaged but something is wrong with performance.

Probably because of copyback. Try different renderer, such as madVR or MPC VR.

[VictorLS]

I have the same problem as goldfield with any renderer while playing 4K with hardware acceleration on my weakest possible nVIDIA GTX750 GM206 1GB videoRAM but I know nevcairiel well enough to even don't ask automatic switching ;)
Although we have possibility of manual switching so must say thanks for that - i.e. soon nVIDIA CUVID may becomes not supported by LAV Video Decoder so all nVIDIA's videocards will show "broken streams" with artifacts with hardware acceleration. Using software decoding often leads to not fluent playback even in cases when CPU isn't full load.

[goldfield]

Why even use the HW decoder? Is your CPU so old that it can't handle the decoding?

QB

At least it seems so.
(CPU is an i7-7700 CPU @ 3.60GHz.)

With "Hardware Decoder to use" = None I also have extreme jerking at 60Hz/HDR, and massive dropped frames.
The CPU load is around 70-80%, says my task manager.
With DXVA2 (native) just 20%.

[el Filou]

Why even use the HW decoder? Is your CPU so old that it can't handle the decoding?Maybe to save on useless wasted power and therefore also additional heat and fan noise that comes with it? (Edit: also things like seeking and fast forward are quicker with hardware decode)

[huhn]

you should not generalise these statemants with AMD you are nearly for sure faster with CPU decode.

with 4K you should be better of with hardware decode but even that is not a given.
there are some system which break with copyback and get throttled to no end.
intel hardware decode usually also loads the GPU shaders so using hardware decoding can lower your available resources.

[ryrynz]

Couple of minor releases of Dav1d since it was last updated in LAV, could you update plz? Thanks.

[KoD]

I've just switched from the official release LAVFilters-0.75.1 to the LAVFilters-0.75.1-7 nightly, and run into an issue when playing some bluray ripped ts files over the network (samba shares from another Windows PC). This is with madVR as renderer in MPC-BE 1.5.8.6300 (the most recent 1.5 version). At exactly the same points in the file, the playback starts stuttering massively, queues get depleted to 1-8 in madVR and never recover. These are ts files form a ripped bluray, nothing special about them, they're plain 1080p H264 + pcm 2.0 48KHz files.

The issue does not happen when I play the files from a local SSD, only when playing over the network. I've copied the files on the remote Windows PC from one of its disks to another, but the stutter happens the same way even from the new location, at exactly the same points in the file.

When I transfer the files on the remote Windows PC from one of its disk to another it's a constant >100MB/s transfer rate, so it's not an issue of file fragmentation. When I access the files over the network, it's a constant 80 MB/s transfer rate, with no drops whatsoever. A ping to the Windows PC from the computer that plays the file to the computer that hosts the file shows 2-4ms pings, with no variations. This makes me believe it's not an issue of latency or transfer speed.

And the stutter does not happen with the official 0.75.1, either.

Is there a way to run a debug version of the recent version of lav filters with some tracing enabled to identify where the issue lies?

[ryrynz]

Is there a way to run a debug version of the recent version of lav filters with some tracing enabled to identify where the issue lies?

Most likely the update to ffmpeg, try running LAVFilters-0.75.1-3 and confirm LAVFilters-0.75.1-4 is where the issue begins.

[nevcairiel]

There were no significant changes of any kind since 0.75.1 that should effect such behavior, either in LAV or in FFmpeg, since FFmpeg updates are currently coming from a release branch until the next FFmpeg release, which only contains security fixes.
But all nightly builds are available, so you could try to figure out where it started, if anywhere.

[KoD]

I repeated my tests and I eventually run into the issue when using the official 0.75.1 version of the LavFilters too, even though previously they worked fine.

I noticed the issue did not happen with other video renderers, only with madVR. And it seems to be triggered by a setting in madVR.

The "madVR settings -> rendering -> general settings" contains two options:
- delay playback start until render queue is full
- delay playback start after seeking, too

I had "delay playback start until render queue is full" enabled since forever, and this does not cause any problem.
I have recently enabled "delay playback start after seeking, too", and unfortunately this seems to be the cause of the sudden stutter and queue depletions in madVR after seeking in the file.

In order to reproduce the playback issue, I kept seeking to the file location where I knew the issue would manifest itself, then I paused the playback to refill the madVR buffers (because the madVR queues get depleted right away after seeking when playing a file over the network), and then resumed playback. Playback would resume, but when hitting certain points in the file the madVR queues would suddenly start to deplete and would not resume by themselves anymore. Pausing the playback would refill them, and on resuming playback everything would work again for a while and then the queue depletion would occur once more, and so on.

I can't really explain why the madVR queue depletion would happen at pretty much the same points in the file. What I can say is they don't happen anymore with that second setting disabled.

The issue only manifests itself on high bitrate content (like a 7GB ts file for a 25 minute anime episode), and not on low bitrate content like a 2 GB 45 minutes TV episode DVD file ripped to a mkv. It also does not happen when playing the same high bitrate file from a local SSD. Maybe the issue is triggered when playing from a SSD too, but it recovers too quickly to notice the stutter, while it never recovers when playing over the network.

Additional playback details would be: video decoding is done using D3D11 hardware acceleration in lav video, on automatic setting (so, native decoding). The GPU is a RTX 3090. The CPU is a Ryzen 5900x, so this should not be a bottleneck either. The video player is MPC-BE 1.5.8.6300. The MPC-BE audio renderer is used for WASAPI exclusive playback (using events). All "trade quality for performance" settings in madVR are disabled. madVR is using Direct3D 11 for presentation, but with "present a frame for every VSync" disabled. madVR "automatic fullscreen exclusive mode" is disabled too (as it makes sense no more on Windows 10 anyway). I have the lav video "Deinterlacing mode = Aggressive", because it would otherwise miss deinterlacing old DVD TV episodes (Star Trek Voyager ones, for example), but this should not matter on the progressive material I experienced the issue, and madVR does not do deinterlacing in d3d11 native mode anyway (I have to disable native d3d11 decoding in lav video when watching such deinterlaced material, by selecting explicitly the GPU to use for decoding, as only then madVR deinterlaces the video content).

One more thing is that using in madVR settings "rendering -> windowed mode -> after last render step = flush and wait (loop)" instead of the default "flush & wait (sleep)" makes the stutter events occur less, and allows more intensive scaling algos to work without frame stutters even on the integrated graphics of a i7 4790K CPU in another system (with all "trade quality for performance" settings disabled there, too). More intensive scaling algos in this case means Jinc for upscaling, SSIM for downscaling, and super-xbr for chroma upscaling, using correct linear light-scaling and with the anti-ringing filter enabled.

[clsid]

Increasing the queue settings in LAV Splitter could help in your case.

[KoD]

Increasing the queue size in lav splitter was one of the things I tried without effect, unfortunately.

[vanden]

Hello,
Here are my previous post
https://forum.doom9.org/showthread.php?p=1935458#post1935458
https://forum.doom9.org/showthread.php?p=1935623#post1935623

I have a BUG with Windows 10 Enterprise 1903 1909 2004 20H2 21H1 21h2 ...
All other version (from 1809) works normally.
HP DL580G5 PC (4 x Xeon X7460) 32Go Ram and GTX 650 Ti.
I also tested a GTX 770 with Windows 10 Enterprise 21H1 et 21H2 : Same result.
This PC does not support the GTX 960 and GTX 1060 ... impossible to have a GPU decoding!
Test with Nvidia driver 425.31, 456.71, 472.12.
Sound blaster X-Fi Xtreme Audio sound card in analog 24bits / 96Khz.
it works the same if I choose the SPDIF.
Driver XFXA_PCDRV_LB_WIN8_1_05_0001
The tests below are made with Nvidia driver 425.31 (the last to do 3D).

Testing an UltraHD Blu-ray with Windows 10 Enterprise 1809 :
MPC HC 1.9.16 + LAV 0.75.1.4 + MadVR 0.92.17 :
https://i.ibb.co/3FPDQDN/1809.jpg
I took a fullscreen windowed screenshot, because a Windows 1809 screenshot does not work in Exclusive. But in Exclusive it works well.

Test with Windows 10 Windows 10 Enterprise 21H1 (update from Windows 10 2004) :
MPC HC 1.9.16 + LAV 0.75.1.4 + MadVR 0.92.17 :
https://i.ibb.co/Jr4v6K8/21h1-16.jpg
https://i.ibb.co/0hCR3r5/21h1-32.jpg
https://i.ibb.co/5rTVT8b/21h1-128.jpg
I made screenshots in Fullscreen windowed, Windows 21h1 works well in Exclusive. I could have made an exclusive screenshot.
I tried several values for "decoder queue", "upload / dxva / render queue" and "present queue".

I did a clean installation (blank disk / USB key Windows 10 21H2) same results !
MPC HC 1.9.16 + LAV 0.75.1.4 + MadVR 0.92.17 :
https://i.ibb.co/9s6rCFD/21h2-16.jpg

Test with Windows 11 Enterprise 22000.194 ((update from Windows 10 21H1) update from Windows 10 2004) :
MPC HC 1.9.16 + LAV 0.75.1.4 + MadVR 0.92.17 :
https://i.ibb.co/3CcKYNC/22000-194.jpg
When it works it's OK ... but sometimes there is nothing to do, even after a reset of the graphics card (reset CRU Or MadVR "Custom modes" "remains GPU") you have to restart for it to work ...

I did a clean installation (blank disk / USB key WIndows 11 22468) …
MPC HC 1.9.16 + LAV 0.75.1.4 + MadVR 0.92.17 :
https://i.ibb.co/vLw7Nt3/22468.jpg
And the miracle it works nickel! even a little better than Windows 10 1809 !! a little less resource on the cpu.

I did a clean installation (blank disk / USB key WIndows 11 22000.282) it works the same (WIndows 11 22468).
MPC HC 1.9.16 + LAV 0.75.1.4 + MadVR 0.92.17 :
https://i.ibb.co/HrTM4jZ/22000-282.jpg

The only solution is to switch from Window 10 1809 to Windows 11 ... if this is possible with the final version ... ??

[clsid]

Test with DXVA Checker:
https://bluesky-soft.com/en/DXVAChecker.html

In your Windows 10 screenshots the GPU is labelled as "GPU 2" and "GPU 1". So there might be an unwanted GPU 0 with generic MS driver.

Tip: with D3D11 hardware acceleration in LAV you can choose the GPU that it should use.

[vanden]

Test with DXVA Checker:
https://bluesky-soft.com/en/DXVAChecker.html

In your Windows 10 screenshots the GPU is labelled as "GPU 2" and "GPU 1". So there might be an unwanted GPU 0 with generic MS driver.
Tip: with D3D11 hardware acceleration in LAV you can choose the GPU that it should use.it's the same with windows 10 1809 ...
I redid the test in GPU0: it still works well.
https://i.ibb.co/CJ752kS/1809-GPU0-128.jpg
I redid the test with Windows 10 21H2 in GPU0: it doesn't work better ...
https://i.ibb.co/TkKk8Zq/21h2-GPU0.jpg
https://i.ibb.co/MsBdm6N/21h2-GPU0-16.jpg

But I wonder where it came from ... in fact it's CRU (Custom Resolution Utility) (https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU). When I do restart64 the GPU increases by 1 ...

[clsid]

Your "working" 1809 screenshots show high CPU usage. So why do you think hardware accelerated DECODING is active there? Are you just looking at the GPU usage graph in task manager? That is WRONG!!! The newer Win10 versions do not show all activity in the graph. Change DXVA scaling in madVR to something else, and you will probably see the GPU 3D usage increase.

MPC-HC will show "H/W" in the status bar when hardware accelerated decoding is active. It is as simple as that.

[nevcairiel]

A 650 Ti is far too old for HEVC hardware acceleration. In general HEVC isn't supported before Pascal (1000 series), with one exception, the GM206 chip used in the 950/960 (but no other 900 series cards). Most definitely not in 600 series.

[vanden]

Your "working" 1809 screenshots show high CPU usage. So why do you think hardware accelerated DECODING is active there? Are you just looking at the GPU usage graph in task manager? That is WRONG!!! The newer Win10 versions do not show all activity in the graph. Change DXVA scaling in madVR to something else, and you will probably see the GPU 3D usage increase.

MPC-HC will show "H/W" in the status bar when hardware accelerated decoding is active. It is as simple as that.

This PC does not support the GTX 960 and GTX 1060 ... impossible to have a GPU decoding!

A 650 Ti is far too old for HEVC hardware acceleration. In general HEVC isn't supported before Pascal (1000 series), with one exception, the GM206 chip used in the 950/960 (but no other 900 series cards). Most definitely not in 600 series.
Yes that's it and as already said 900 and 1000 impossible on it.

[el Filou]

There were changes to the CPU scheduler in 1903 (notably to better support architectures like Ryzen that can have different latencies between different cores from the same socket), this definitely looks like a Windows scheduler issue. I don't know if it would even be possible for the application (LAV + madVR) to fix that.
Maybe the fact it's Windows Enterprise has something to do with it too, of course using Pro you would only get half the sockets.
I would try posting this in a more general-purpose Windows forum to see if maybe people know settings to fine-tune the CPU scheduler to make it behave more like 1809.
That Xeon won't be officially supported by Windows 11, but maybe with a clean install from a ISO it will install.

[nevcairiel]

The decoder queue appears to be full, thats where LAVs involvement ends. In any case, LAV is not designed for multi-CPU systems, and I do not plan to put any effort into such setups either. You could try to externally constrain it to one CPU to avoid high latency between CPUs, but thats all I got.

[vanden]

There were changes to the CPU scheduler in 1903 (notably to better support architectures like Ryzen that can have different latencies between different cores from the same socket), this definitely looks like a Windows scheduler issue. I don't know if it would even be possible for the application (LAV + madVR) to fix that.
Maybe the fact it's Windows Enterprise has something to do with it too, of course using Pro you would only get half the sockets.
I would try posting this in a more general-purpose Windows forum to see if maybe people know settings to fine-tune the CPU scheduler to make it behave more like 1809.
That Xeon won't be officially supported by Windows 11, but maybe with a clean install from a ISO it will install.Yes I read that: https://borncity.com/win/2019/06/30/windows-10-v1903-optimization-for-zen-based-amd-cpus/
https://www.reddit.com/r/intel/comments/dbya11/windows_10_19h2_update_to_include_favored_cpu/
https://www.anandtech.com/show/11550/the-intel-skylakex-review-core-i9-7900x-i7-7820x-and-i7-7800x-tested/7
https://www.tomshardware.fr/windows-10-la-mise-a-jour-2h9-disponible-meilleure-gestion-du-cpu/


https://i.ibb.co/RvQ1zqk/1809-21-H2-22000.jpg
the 1st difference between (1507 to 1809), (1903 to 21H2) and Windows 11 is that the processors are not managed the same.
the second difference is also the use of the GPU (45% 1809, 31% Windows 11) when at (1903 at 21H2) it does not go up because : dropped frames ...

The decoder queue appears to be full, thats where LAVs involvement ends. In any case, LAV is not designed for multi-CPU systems, and I do not plan to put any effort into such setups either. You could try to externally constrain it to one CPU to avoid high latency between CPUs, but thats all I got.
I can select the number of cpu (By LAV or by the task manager) = it's worse !
it works very well with Windows 10 (1507 to 1809) and also with some Preview and developer of Windows 11.


but in my old post I tested EVR in bilinear algorithm:
http://vandenk.free.fr/Evr.jpg
On 1809 it works well :
http://vandenk.free.fr/1809-EVR-Bill-FSdirec3d.jpg
On 20H2 it works as well :
http://vandenk.free.fr/20h2-EVR-Bill-FSdirec3d.jpg

But look at the diferentes GPU usage 1809=44% 20H2=90% ...

[chros]

Additional playback details would be: video decoding is done using D3D11 hardware acceleration in lav video, on automatic setting (so, native decoding). The GPU is a RTX 3090. The CPU is a Ryzen 5900x, so this should not be a bottleneck either. The video player is MPC-BE 1.5.8.6300. The MPC-BE audio renderer is used for WASAPI exclusive playback (using events). All "trade quality for performance" settings in madVR are disabled. madVR is using Direct3D 11 for presentation, but with "present a frame for every VSync" disabled. madVR "automatic fullscreen exclusive mode" is disabled too (as it makes sense no more on Windows 10 anyway)...

One more thing is that using in madVR settings "rendering -> windowed mode -> after last render step = flush and wait (loop)" instead of the default "flush & wait (sleep)" makes the stutter events occur less, and allows more intensive scaling algos to work without frame stutters even on the integrated graphics of a i7 4790K CPU in another system (with all "trade quality for performance" settings disabled there, too). More intensive scaling algos in this case means Jinc for upscaling, SSIM for downscaling, and super-xbr for chroma upscaling, using correct linear light-scaling and with the anti-ringing filter enabled.
After last render step -> "flush & wait (sleep)" uses more CPU (visible in task manager), try out "don't flush" everywhere first (according to madshi's recommendation (https://forum.doom9.org/showthread.php?p=1405640#post1405640)), it works fine here with discrete GPU (see my signature), although the performance gain is negligible with this fast GPU (I can't use e.g. NGU Sharp low vs med for chroma with HDR10 pixelshader) and there's no rendering avg/max stats on OSD (but I consider this cosmetics).

[vanden]

The decoder queue appears to be full, thats where LAVs involvement ends. In any case, LAV is not designed for multi-CPU systems, and I do not plan to put any effort into such setups either. You could try to externally constrain it to one CPU to avoid high latency between CPUs, but thats all I got.
Well finally I redid the test, is it working !!
I was wrong !

but by LAV that is not enough, it must be done with the task manager on MPC HC like this :
https://i.ibb.co/QDcGvcz/Affinit-2.jpg
After you have to find the core that is the least used and we can re-light 1 ... impossible to do directly.
https://i.ibb.co/YjQhBWq/Affinit-3.jpg
The result under Windows 10 21H2 :
https://i.ibb.co/LQD7W3b/21H2OK.jpg

[KoD]

After last render step -> "flush & wait (sleep)" uses more CPU (visible in task manager), try out "don't flush" everywhere first (according to madshi's recommendation (https://forum.doom9.org/showthread.php?p=1405640#post1405640)), it works fine here with discrete GPU (see my signature), although the performance gain is negligible with this fast GPU (I can't use e.g. NGU Sharp low vs med for chroma with HDR10 pixelshader) and there's no rendering avg/max stats on OSD (but I consider this cosmetics).

It's normal to see increased CPU usage, because it uses a loop to check for the D3D device flush to be completed instead of yielding the thread execution and letting the OS to wake the thread when it's done. Using "flush & wait (loop)" is definitely more responsive than (sleep) though, so I'll keep using it. The stutters happen with "flush & wait (sleep)" too, anyway. It's trying to fix this issue that made me switch to "flush & wait (loop)" in the end.

Regarding the stutter issues, they happen no matter what I do. The solution I thought I found was no solution at all, the stutter-after-skip-forward still happens. And it happens with MPC-VR as well, it's not just with madVR.

The buffer-depletion causing stutters happen as soon as I skip forward in a high-bitrate file in MPC, like when I play ts ripped BluRay files. All files with LPCM 2.0 audio have this issue. Pressing quickly arrow up 4 times (forward 20 sec for each press) and right once (forward 5 sec for a press) is enough to trigger the stutter. The video renderer queues get depleted, and the file stutters. Pausing the file and letting the buffers fill again and then resuming playback works for a while, but soon it starts happening again out of the blue. I can repeat this pause and resume playback many times, but as long as I don't close the file for playback, the stutters come back after a while.

The only way to keep watching the file stutter-free is to close the file and open it again (I have "Remember File position enabled in the player settings, so it starts playback from the location where I closed the player). As long as I don't skip forward or backward in the file, the stutters don't happen anymore until the end of the playback.

I tried many things, but nothing gets rid of this behavior when playing files over the network in MPC-BE or MPC-HC. I thought it might be my external USB DAC, but playing sound over the TV speakers has the same issue. I thought it might be a bug in the MPC audio renderer, but using the DirectSound audio renderers has exactly the same issue.

I thought there might be an issue with the server or the network connectivity but that's not it either. Latency measurements to the network server while playing a file shows no variations in latency at all. The transfer speed is as high as a Gbit connection allows. CPU usage monitoring on the server shows minimal usage (not surprisingly as it's an overpowered Windows PC for a file server task, running Windows Server).

The playback PC is again too overpowered to have this kind of issue. And it happens with no other processes in the background (I don't have social media apps or such running in the background, nor hardware monitoring software).

I simply don't understand why network playback has such kind of issues on such hardware, but that's how it is.

This is not a recent issue. It's been happening for years, but I had a i7 4790K system until this year, and thought that maybe it was due to that. It was not, apparently. Network playback is just as unreliable on the new system as it was on the old one when using MPC, lav filters and madVR.

[clsid]

Are you playing actual .ts files? Then the solution would be to remux into .mkv.

MPEG-TS container does not have a seek index for quick seeking, so the splitter needs to parse a lot more data when seeking.

[flossy_cake]

Hello

Is my understanding correct that: LAV Video D3D11 hardware acceleration could work to accelerate decoding of HEVC on older GPUs which don't natively support HEVC decoding?

I am trying to get accelerated HEVC decoding on an old R9 380 which doesn't support it natively.

Thanks

[lvqcl]

Is my understanding correct that: LAV Video D3D11 hardware acceleration could work to accelerate decoding of HEVC on older GPUs which don't natively support HEVC decoding?

No, it's absolutely incorrect. Basically, D3D11 is a new programming interface to the same old hardware decoding blocks.

D3D11 can't do anything if your video card doesn't have hardware blocks to decode HEVC.

[strumf666]

win11, MPC-BE, lav filter and madvr; using latest nightly, D3D11 seems to be broken with latest amd drivers on 5700xt, dxva2 cb or software works. I tried playing a 1080p and 2160p with HDR .mkv but it immediately pauses/black screen.

[huhn]

Hello

Is my understanding correct that: LAV Video D3D11 hardware acceleration could work to accelerate decoding of HEVC on older GPUs which don't natively support HEVC decoding?

I am trying to get accelerated HEVC decoding on an old R9 380 which doesn't support it natively.

Thanks

no. it's one of many ways to access the hardware decoder not to accelerate unsupport formats.

[flossy_cake]

Thanks. In that case I might look into a new GPU which can decode HEVC.

I wonder though if it's possible in theory to implement the decoder in OpenCL which is supported by all GPUs. It wouldn't be as efficient as having the hardware decoding blocks, but maybe it could still exploit the parallelism of the GPU to achieve some acceleration that would make 4k HEVC playable?

[huhn]

it's but GPUs are absolutely terrible at this and a CPU is usually much better.

there are even cards that do that.

[clsid]

You need to get a newer GPU. END OF DISCUSION.

[ryrynz]

Thanks. In that case I might look into a new GPU which can decode HEVC.


That's the only solution for you as CLSID said above.


I wonder though if it's possible in theory to implement the decoder in OpenCL which is supported by all GPUs. It wouldn't be as efficient as having the hardware decoding blocks, but maybe it could still exploit the parallelism of the GPU to achieve some acceleration that would make 4k HEVC playable?

Pipedream. No market for this worth anyone's time to code it. When your software needs outgrow your hardware you upgrade your hardware. It won't be the last time..

[DMU]

What could be the reason for the decoding failure when playing some AVC video? Decoding breakdown occurs when jumping forward and continues until the video scene changes. Video playback at this time stutters, although MADVR does not show drop frames.

Pic. (https://drive.google.com/file/d/1eZ4kbUsCvTQ-q7fgZZis8rmm_qP1c_ko/view?usp=sharing)
Video sample. (https://drive.google.com/file/d/14enCzfnygnsD4dEvX6BjbxL0EvKkcUgu/view?usp=sharing)

[lvqcl]

What could be the reason for the decoding failure when playing some AVC video?

Does software decoding work?

[DMU]

Yeah, when using avcodec everything is fine.

[flossy_cake]

What could be the reason for the decoding failure when playing some AVC video? Decoding breakdown occurs when jumping forward and continues until the video scene changes. Video playback at this time stutters, although MADVR does not show drop frames.

Pic. (https://drive.google.com/file/d/1eZ4kbUsCvTQ-q7fgZZis8rmm_qP1c_ko/view?usp=sharing)
Video sample. (https://drive.google.com/file/d/14enCzfnygnsD4dEvX6BjbxL0EvKkcUgu/view?usp=sharing)

Sounds like something to do with waiting for the next keyframe, maybe the GPU doesn't handle that scenario well.

[sofakng]

What's the difference between the following D3D11 decoding modes?

d3d11 cb
d3d11 cb direct
d3d11 native

d3d11 cb appears to mean D3D11 Copy-Back and is automatically enabled when AviSynth Filter is inserted into the graph.
d3d11 cb direct is more confusing but it is automatically enabled when I use EVR with D3D11 which isn't compatible so it's translating (?) it?
d3d11 native is self explanatory and appears to only work with madVR renderer. (ie. entire video frame/processing is done on GPU)

[nevcairiel]

"direct" is more efficient/faster, but only works if the next filter in the chain provides compatible video buffers and accepts the correct format. Most video renderers do. The AviSynth filter apparently does not.

[sofakng]

Is this something that I could ask the AVISynth Filter author to add support for? ...or is it really only applicable to renderers?

Adding support for something faster/more efficient would be nice.

[LordX2]

So, finally sat down just to enjoy a flick after getting MadVR and MPC-HC all sorted, and had something wackily different happen to me.

After about an hour and 15 minutes of straight watching, I noticed a 'click' in the sound - like a sound glitch. BTW I am bit-streaming through my Denon. This encode had Atmos.

Then, out of the blue, ALL the sound started coming out of just one of my rear speakers. I put the movie back 10 seconds, and bam, all sound normal again.

Could maybe just be the encode I was watching - but does this scream anything else to anyone? Never experienced anything like it before, but haven't really gotten to sit down and watch something more than 20 mins in a while.

[LordX2]

Watched a stereo encoded file with the kids tonight - at one point, it sped up the audio hilariously - like chipmunked it out.

I randomly unchecked Convert channels to standard layout - and that seemed to fix the problem.

Does that make any sense? Why did that solve it?

[LordX2]

Realized I was on a pretty outdated LAV filter version. Updated that - solved!

[LordX2]

Bitstreaming is causing a dropped/repeat frame now. It is a repeatable error at certain points in movies. Disabling bitstreaming stops the frame drops. But I LOVE my bitstreamed audio. Any ideas or suggestions would be greatly appreciated!

I lowered my version of MPC-HC to last year - .74 LAV Filters.... now no more dropped/repeat frames. What is in the newer versions that could cause this?

[benus]

A 650 Ti is far too old for HEVC hardware acceleration. In general HEVC isn't supported before Pascal (1000 series), with one exception, the GM206 chip used in the 950/960 (but no other 900 series cards). Most definitely not in 600 series.

Well to be 100% correct we should mention the pre-Pascal GeForce GTX 750 SE made for Asian market that had HEVC hardware decoding fully implemented :sly:

[nevcairiel]

Well to be 100% correct we should mention the pre-Pascal GeForce GTX 750 SE made for Asian market that had HEVC hardware decoding fully implemented :sly:

That uses the GM206 chip I already mentioned. No need to list every single model, especially when its very obscure. :p

[PCU]

That uses the GM206 chip I already mentioned. No need to list every single model, especially when its very obscure. :p

Hi nev
I have good news for you: I talked to developers in the official IRC FFmpeg chat, giving the source code to decode the Bink 2 format, which is open source, can be downloaded here:

https://git.nihav.org/?p=nihav.git;a=summary

That contains AGPL decoder for Bink2

I hope I helped you.

[lvqcl]

I hope I helped you.
You didn't.

[PCU]

You didn't.

What do you mean!?

[nevcairiel]

AGPL is a useless nonsense license, it makes it useless, and even then i'm not interested in some external library for some game codec. If FFmpeg supports it, then so will LAV, otherwise it just won't.