Feature request: manual buffers adjustment

[Usulyre]

Can there be both auto and manual buffer adjustment? Just would be nice to have manual buffer adjustment for more experience d users.

[CrendKing]

What problem are "more experienced users" trying to solve with manual buffer size?

[Usulyre]

I guess, if one wants to manually enter a buffer size

[CrendKing]

I'm asking the reason to change buffer size. So let's assume I add a option box as "buffer size". What value would user want to enter? If user enters something like "100", what change would user expect to happen?

I ask because if there is specific problem that user is facing, we should tackle that problem directly. If after investigation we found that the problem can be solved with larger or smaller buffer size, I can add an option box for buffer size. But if the problem has nothing to do with buffer size, or we can determine optimal buffer size automatically, then adding buffer size option box just wastes time.

[Usulyre]

If I remember right, the earliest versions had a option to change buffer size manually, not automatic at the time. Though I'd like both. In my case, though I'm not totally sure, would manually inputting a buffer size bring video and audio in sync and latency to as minimal as possible? I'm using a capture card which I can set to 24 fps. According to what I know, if you have native 24 fps in video using something like svp works better (more soap opera effect) than a video that is 29.97. The smoothing effect is greatly noticeable. I'm using the capture card and testing live video playback and using a gaming console, I need to have video and audio in sync and latency as minimal as possible so the controller inputs on the gaming console are in realtime with no input lag so I can experience smooth motion in anything that i can hook up to the capture card and operate that device with no delay. So, I can play or watch anything in smooth motion in realtime with no problems. In ffdshow you can manually adjust buffers, i think this effects smoothness and that delay in a way, but I'm not totally sure.

[CrendKing]

Well, we had lengthy discussion at https://github.com/CrendKing/avisynth_filter/issues/26, and unfortunately I can't figure out how to solve the problem without having the exactly same setup as you. Yes the earlier versions of this filter has input and output buffer size, but the code has changed dramatically since then. There is no output buffer, and the input "buffer size" is somewhat unimportant.

But anyways I hacked a version that you can manually change the input buffer size yourself, feel free to try. Create registry or ini value named "BufferSize" and specify a positive number. The default value is 7.

AviSynthFilter.zip

[Usulyre]

Tried the above version. If editing the registry value, one doesn't have to restart computer every time, right? I tried values lower than 7 like 1, delay is reduced compared to a value like 10.

[CrendKing]

No need to restart. Just restart the video player.

That value control how much extra frames can upstream can send before downstream can consume, much like the "queue size" in madVR. For example, suppose you have a super beefy camera which can send thousands of frames per second. But you have a very low-end graphic card which can only render a few frames per second. If there is no such limit, your memory will very soon be filled with frames that are not gonna be rendered any time soon.

Now imagine we have exactly opposite situation where you have shitty camera and beefy renderer. If you set that number too low, like 1, the renderer will almost always be hungry of frames to render.

So a bigger value would delay a bit at the beginning of the video or after each seek, but shouldn't have any effect on sync offset. A very small value would most likely make lower end computer stutter. 7 is a middle ground I choose.

If you are interested, you can check the log files (or upload here) when you change that value and actually perceive a difference in delay. The value you should look at is those "Frame time drift:" lines. Ideal number should always be 0, meaning the audio and video are perfectly aligned.

[Usulyre]

Here is the log file:

https://gist.github.com/Usulyre/b821860749f021f2a2895270bb4773c2

[CrendKing]

I see a bit of drift for 2 seconds, then no drift any more. Everything seems fine. Most of the time the input queue size is 4 and output 9. There is no limit on how much these queues can grow. Mostly they are controlled by the value we were talking about.

Do you actually feel any stutter or audio desync? What is the value for this log file? If this is generated with the default value 7, upload another log with value 1 and you might see some interest differences.

[Usulyre]

No stutter or audio desync. The value is actually 1

[CrendKing]

OK. Change it to 7 and see if you have stutter, desync or drift. If yes, upload log.

[Usulyre]

There is video delay/input lag. Log attached.

https://gist.github.com/Usulyre/f32be62af786572bd4f131b46d26c5a8

[CrendKing]

There's some drift at beginning, but corrected itself after 13th second. As expected, the input queue size is around 12, tripled the one with value 1. Output queue size is around 57, 6 times of value 1. I don't know if this number is "too large" or not, as there is no "standard" queue size to be expected. I wonder if you can decrease that size by increasing the "OutputThreads" settings from 1 to 2 or 3. Of course, that is assuming you are CPU bound. If I/O bound that won't do anything. Also, if you know how, play with the number of avs prefetchers see if that changes anything.

Again, I don't know the exact setup of your hardware and software, especially the capture card, so I can't replicate everything from my end. Typical use has shown that the default value is fine. But if you have exhausted all other avenues and still can't solve your problem without tinkering the "value", I can add a secret setting for the "value". But be warned, since this is very implementation specific, I can't promise any backward compatibility about it. Use with your own discretion.

[Usulyre]

Just wondering, in the registry, I see "BufferAhead" and "BufferBack" , does changing those do anything?

[CrendKing]

Those are obsolete values. They are no longer used.

[Usulyre]

For "OutputThreads", how much can one adjust the setting?

Changing the number of avs prefetchers seems to desync video/audio and input lag is added.

[CrendKing]

Default is 1. Usually good enough. You can try 2 or 3.

[Nuihc88]

Decided to test this build out and found that on my system 'BufferSize' of '4' or smaller reduces the frequency of presentation glitches reported by MadVR during first minute of playback, regardless of any combination of 'Prefetch()'s. That would suggest that there is a minor latency-bottleneck there; perhaps tied to the number of available CPU-cores/threads? Thus i hope that BufferSize will remain adjustable in future builds, at least until that bottleneck is better addressed.

[CrendKing]

the frequency of presentation glitches reported by MadVR during first minute of playback

I can't draw any conclusion from the presentation glitches (PG) stats. It seems random, and related to the script and video. Sometimes it could be 0 even I have SVP and value 7, other times it could be 20 with the minimum script and 2.

Also, what is the meaning of PG? Each time I alt tab in and out of the player, it increase by 10, but I don't notice any visual glitch. Do you see any actual glitch when PG goes up? If it is something self correctable, then it doesn't matter.

latency-bottleneck

Please help find some reliable source that explains the meaning of PG, how to reliably avoid/eliminate it, then we can think of a targeted solution. Currently all we have is some weak correlation. Also, please create new ticket for PG elimination.

[Usulyre]

I don't think the "OutputThreads" did anything noticeable. However, can you add "BufferSize" to the filter anyways?

[CrendKing]

Fine.

AviSynthFilter.zip

I changed the implementation a bit. The new "official" setting name is ExtraSourceBuffer. Valid value is any non-negative integer. 0 means no extra buffer, giving you the minimum latency. Currently the default value is 3 (instead of previous 7).

If you use small number like 0 and experience freeze, try increase the number.

[Nuihc88]

I can't draw any conclusion from the presentation glitches (PG) stats. It seems random, and related to the script and video. Sometimes it could be 0 even I have SVP and value 7, other times it could be 20 with the minimum script and 2.

Also, what is the meaning of PG?

It is somewhat connected to video frame rate, display refresh rate and also dependent on system drivers and rendering mode used, so basically a Presentation Glitch means that MadVR received and rendered the frame before it was meant to be displayed, but system driver was still late in reporting back to MadVR that the frame has been displayed correctly. In some system configurations that could lead to sync issues or tearing (especially in a window split across multiple monitors), but far more commonly it causes a delayed or dropped frame.

Each time I alt tab in and out of the player, it increase by 10, but I don't notice any visual glitch.

Alt+Tab presentation glitches are to be expected as Desktop Window Manager is briefly hogging lots of extra system resources.

Do you see any actual glitch when PG goes up? If it is something self correctable, then it doesn't matter.

These are usually not noticeable, but sometimes i might spot a jerky transition in panning scenes without any Dropped Frames reported; occasional Presentation Glitches are also fairly normal and not very serious, but for smoother experience it's always better to minimize the potential for these where ever possible.

I've also occasionally encountered what seem like non-self-correctable infinite pileups of Presentation Glitches with no Dropped Frames reported, but since these can usually be solved by seeking/reloading the video or switching to a lighter script, i suspect that these are driver and hardware I/O issues unrelated to any filter.

Please help find some reliable source that explains the meaning of PG, how to reliably avoid/eliminate it, then we can think of a targeted solution. Currently all we have is some weak correlation.

While i can find plenty of posts with Madshi talking about the subject, i can't seem to find an instance of him defining the term. I also don't believe that presentation glitches can be reliably eliminated as avoiding them is simply about minimizing overall system latency, to which there are numerous factors.

Also, please create new ticket for PG elimination.

As completely removing Presentation Glitches seems to be a fundamentally unsolvable problem and i have no idea if the latency-bottleneck is even still there after setting 'ExtraSourceBuffer' to '0', or how you could further reduce it if it is, i don't think it requires a new ticket.

[CrendKing]

Anyways, now you have the setting, maybe try 0 or 1 ExtraSourceBuffer on different videos, and tell me if you experience any problem. I remember when the value was too low, sometimes I experience freeze. That's why I have it default to 7. Much of implementation have changed since then. Maybe the problem no longer exists. Then we can set it back to 0.

[Nuihc88]

Anyways, now you have the setting, maybe try 0 or 1 ExtraSourceBuffer on different videos, and tell me if you experience any problem. I remember when the value was too low, sometimes I experience freeze. That's why I have it default to 7. Much of implementation have changed since then. Maybe the problem no longer exists. Then we can set it back to 0.

I have been testing this build for a few days and haven't yet encountered a single video or script in which a value >0 would perform better than 0. Also experimented in various combinations with Prefetch & OnCPU, MadVR buffer sizes and briefly even double checked with EVR (C/P). I also haven't yet encountered any freezing issues while testing.

On a somewhat related sidenote, i have been seeing some non-self-correcting Dropped Frame pileups in MadVR stats with recent builds while playing 10bit HEVC videos, but i can't yet rule out AVS-script or MadVR misconfiguration as a cause (not encountering anything similar with EVR); also seeing a lower composition rate and different color spaces than usual (29.970Hz instead of 59.940Hz & I420 instead of NV12) in MadVR's OSD (with only YV12 enabled in AviSynth Filter). If it's actually related to AviSynth Filter i'll create a new ticket, assuming i can eventually narrow that issue down to something more specific. More relevantly, i can already tell that increasing ExtraSourceBuffer makes these pileups more frequent as well.

In summary: My impression is that the current implementation of this buffer is very likely obsolete and only detrimental to performance, but i have no idea if it can still function as a workaround for some issues i simply haven't personally encountered.

[CrendKing]

For bug finding, you can bisect to specific version to narrow down. For the buffer impl, we need more data.

[CrendKing]

I changed internal now the extra buffer is default to 0. If you have time, try it and see if there's any regression.

v0.9.5