search

CrendKing / avisynth_filter

DirectShow filters that put AviSynth and VapourSynth into video playing
MIT License
108 stars 8 forks source link

Vapoursynth filter performance drop #56

Closed ssssssbbb closed 3 years ago

ssssssbbb commented 3 years ago

Environment

Describe the bug

FPS dropped when speeding up, it looks stutters. Problems don't come with all videos. "fear.the.walking.dead.s06e16.internal.1080p.web.h264-whosnext" stutters. "Game.of.Thrones.S01E10.2011.BluRay.1080p.DTS.x264-CHD" stutters. "Spectre.2015.1080p.BluRay.x264-SPARKS" is OK. You can find them on RARBG.

To Reproduce

1.Potplayer+madVR/EVR+Vapoursynth filter: open the video, start and play with 1.5x or faster speed, fps drops 2.MPC-HC 1.9.13+ madVR/EVR+Vapoursynth filter: open the video, start and play with 1.5x or faster speed, fps drops 3.Potplayer+madVR/EVR+Avisynth filter: OK 4.MPC-HC 1.9.13+ madVR/EVR+Avisynth filter:OK

I don't know what the green line means, but it raised with the stutter. 1

CrendKing commented 3 years ago
  1. Do you use any script/SVP?
  2. You are saying MPC-HC + madVR +VPSF has the problem. Do you see frames dropped in madVR's OSD? I don't know what's that MPC-HC version in your screenshot. Mine don't have the fancy graphs.
  3. For MPC-HC + EVR, there's the "Statistics" section, which should show the dropped frames. Do you see any?

I can't repro any of your use case.

ssssssbbb commented 3 years ago
  1. Using SVP, the "24fps" on the left bottom is showed occasionally, it's changing, not meaning without FRC. In fact the number on the left top shows it's 68fps.
  2. Yes, dropped frames kept increasing with repeated frames at first for a moment, than stoped, after speeding up for a while it increased again and this time it didn't stop. I'm using MPC-HC 1.9.13, press Ctrl+J(EVR) to show this graph and the data on the left top.

Note: Dropped frames increasing seems to be normal while hasting. I'm not sure whether the quantity of dropped frames in this issue is larger since it's hard to count.

  1. Yes as well.
CrendKing commented 3 years ago
  1. Try to repro the issue with the simplest setup, i.e. no SVP, no PotPlayer, just MPC-XX + VPFS + madVR/EVR. When diagnosing issue, involve as little as components. If SVP is required to repro, then we can focus on SVP.
  2. I didn't know about the Ctrl+J OSD. Thanks.
  3. Does it drop without speeding? Does it drop with < 1 speed?
CrendKing commented 3 years ago

Try https://github.com/CrendKing/avisynth_filter/actions/runs/962360064?

ssssssbbb commented 3 years ago

Try https://github.com/CrendKing/avisynth_filter/actions/runs/962360064?

Made no visuable change.

It's normal without SVP.

When using madVR with SVP, with 1x speed it sitll drops 1 frame every 2 seconds. With < 1 speed, both EVR and madVR are normal and the graph is OK.

CrendKing commented 3 years ago

OK. To summarize, you can get 1 frame drop every 2 seconds with MPC-HC + VPSF + madVR without speed change, consistently? So far this is the simplest setup, so let's focus on this. Is it specific to video file? Is the walking dead one good? Can you provide log file, SVP settings and screenshot (madVR OSD, when dropping frames)? Also, change SVP around to see if there's another bug like the other one, e.g. 75FPS -> 60FPS.

Also, how much of CPU/GPU you use when doing SVP on these videos? If it's like over 50%, then that explains the frame drop. But then if AVSF doesn't have this symptom, we need to see why.

ssssssbbb commented 3 years ago

Frame drops consistently with 3 videos mentioned above, walking dead included.

CPU used 34% and GPU 16%. It doesn't drop frames when playing with 60FPS and origin speed, but drops after speeding like 75FPS.

Tried using SVP's "auto" profile and got same result, and it seems to be varying with hardware? Here's my SVP settings: put them into C:\Users\%username%\AppData\Roaming\SVP4\settings after backing up yours settings.zip

1.0 speed log: 1x.log

1.0 speed screenshot: 1x

1.5x speed log: 1.5x.log

1.5x speed screenshot: 1 5x

CrendKing commented 3 years ago

I can repro now. This might require some bigger changes.

CrendKing commented 3 years ago

Does https://github.com/CrendKing/avisynth_filter/actions/runs/969690201 fix the problem?

BTW, you might need to register this filter separately since it's a "Debug" version.

ssssssbbb commented 3 years ago

Yes ,it works. With normal speed, it doesn't drop 1/2 fps any more. But 1.5x is still stuttering.

But I found something new here. Both AVSF and VPSF still drop frames when playing with normal speed, but much slower than 1/2 fps, it's hard to count, but sometimes it get faster. And I did the test as below: 1.MPC-HC + madVR + SVP 75FPS at 1x speed: dropped frames increases slowly 2.MPC-HC + EVR + SVP 75FPS at 1x speed: dropped frames increases slowly 3.MPC-HC + madVR + SVP 60/72FPS at 1x speed: 0 dropped frames and stuttering is gone wiht 1.5x 4.MPC-HC + EVR + SVP 60/72FPS at 1x speed: 0 dropped frames and stuttering is gone wiht 1.5x

And……I set FRC to 74.9 fps by modifying the profiles.cfg in AppData\Roaming\SVP4\settings, change the value of "fi_target" to 74.9. There is no stuttering even with 2x speed.

CrendKing commented 3 years ago

The slow frame drop is probably due to the mismatch between FRC and monitor refresh rate. chainikdn still has that weird 22/7 for your monitor refresh rate.

As long as it's not dropping massively and AVSF and VPSF show the same result, I consider this issue fixed.

ssssssbbb commented 3 years ago

Yes, it's refresh rate related, but 25/8 and 22/7 have the same problem. MadVR's OSD shows my refresh rate is 74.923Hz, as long as fps is larger than this it stutters.

The 1.5x stuttering problem which is disappered with 74.9fps, comes only with VPSF, could it still be the bug of VPSF?

BTW, is VPSF better than AVSF? It seems the CPU/GPU usage are lower. Is there any other difference?

ssssssbbb commented 3 years ago

OK, v1.13 fixed it completely, perfect!

CrendKing commented 3 years ago

BTW, is VPSF better than AVSF? It seems the CPU/GPU usage are lower. Is there any other difference?

VapourSynth has better concurrency model, supports async request, meaning it requires less thread and buffering to achieve the same performance than AviSynth+. Also, Python is a better language to write scripts.

The difference is most cases would be trivial, as the core idea of the two are the same. But if you have to pick one, VPSF is better in general.

ssssssbbb commented 3 years ago

The VPSF stuttering comes with speeding is back, since 3e17039, this time I tried recent versions one by one. Now it need a faster speed to trigger, such as 2.0x.

And...even v1.13, the former pefect version, about 3.5x speed will trigger the stuttering while AVSF is OK with at least 5.0x. Is it a limit of wasting performance or a bug?

Maybe my usage is somehow wierd. I used so fast a speed because I'm used to skipping some sections by speeding up, but when I slow down, the video is delayed, that's the problem. So it's kind of normal use and it's the indication of performance.

Note: SVP is now 74.9fps so there is no interferece.

CrendKing commented 3 years ago

It is sort of expected. Let me explain.

What https://github.com/CrendKing/avisynth_filter/commit/3e170397e79a2aeebee772df8dc162efee242c74 does is to control the input rate based on how much difference between the actual input rate vs the video's theoretical input rate. For example, if the video is supposed to have 30fps, but you are having 10fps, VPSF will gradually lower the input clamp until the two number matches, or a threshold is hit. "Slowly" because we don't want temporary hiccups to mess up the input rate.

Increasing play speed basically demands more input. It takes time for the rate control to kick in. However, if suddenly you go back to normal speed, the pressure disappears, the clamp will restore back down.

The only way to solve your specific problem is probably putting up a loose static clamp and forget about it. This way you never run of source frames, but also waste resource when you don't super speed the video. I could add that option back for you to try.

EDIT: Try https://github.com/CrendKing/avisynth_filter/actions/runs/999412533, increase MinExtraSourceBuffer

ssssssbbb commented 3 years ago

I understood the logic now. I'll try that later.

"Slowly" because we don't want temporary hiccups to mess up the input rate

You said "hiccups" did you mean the one of the player or the global one? As far as I know, mpc-hc always stutters when changing speed, meantime reset the dropped frames to 0, this may be its own way to match this two numbers. So we might not need another way to stop messing?

As to potplayer, it's 100% smooth when changing speed, that's why I like it. But the rate messing problem may exist. So, could this clamp be dynamic, self adaptive with a wiser logic? Of course, if it's not a good choice, static or changable static is OK.

CrendKing commented 3 years ago

hiccup means something in the background of your system suddenly requires resource to do something. For example, your browser receives a message and start rendering stuff, or caching stuff, using CPU and disk. It could affect how fast the source frames deliver. I don't understand your second sentence. The dropped frame count in the player doesn't matter.

The clamp is dynamic, self adaptive. I'm adding the static for you to test.

ssssssbbb commented 3 years ago

I'm a layman. Anyway, thanks!

ssssssbbb commented 3 years ago

Solved by increasing MinExtraSourceBuffer to 15 and MaxExtraSourceBuffer to 20.

AVSF is OK without modifing these options.

CrendKing commented 3 years ago

If you go to the Status page, you can compare the "Input buffer size" between AVSF and VPSF, after you adjust the extra source buffer. Please let me know if the VPSF one is way higher than AVSF when you can't reduce MinExtraSourceBuffer any further without stuttering.

ssssssbbb commented 3 years ago

I set min to 5 (4 causes stuttering) and max to 15. The input buffer size of VPSF is 7, the one of AVSF is 18.

The min and max parameters did nothing to AVSF, the input buffer size is always 18.

CrendKing commented 3 years ago

So it proves VPSF requires less resource to have the same performance as AVSF. That 18 is mainly determined by how many prefetcher you use in the avs script.

The parameter has the same effect in both filters. Try raise the min to something like 20, then it might change to something like 23-25.

ssssssbbb commented 3 years ago

Yes, but that 18 was expected to be limmited to 15 by the max value, wasn't it?

CrendKing commented 3 years ago

No. The "15" is extra, which starts at 0. AVSF's original "overhead" is already 18, while VPSF is probably 4.

ssssssbbb commented 2 years ago

It stutters at 3.0x speed again. Increasing min buffer size to 30 can't even handle, so far I don't know how big it should be.

Is this change related? https://github.com/CrendKing/avisynth_filter/actions/runs/1475957293

BTW, now I am using Vaporsynth R57 and the newest VPSF, SVP 4.5.0.213 solved this https://github.com/CrendKing/avisynth_filter/issues/62

ssssssbbb commented 2 years ago

Forget it... it was due to the high video bitrate which is unnoticable.

CrendKing commented 2 years ago

Please try this version: https://github.com/CrendKing/avisynth_filter/actions/runs/1514315473

Revert everything about the extra source buffer in your settings to default. Then set ExtraSourceDecreaseStep to 0 (default is 1). This will make the buffer never shrink. Let me know if it fixes the problem. I'll explain why it works.

ssssssbbb commented 2 years ago

Sorry for bothering you because it's my problem. Last time I played videos which resolutions are 3840×1600 but have low bitrates and got no problem. I thought 1600 is much smaller than 2160 is the reason(2160P stutters when speeding), but it turns out the smaller bitrate is the actual reason. So this time, with 30+MBps bitrate, my CPU become the bottleneck.

Anyway I tried, default is 0 for min and 15 for max, that's not enough for the video in this case. But ExtraSourceDecreaseStep = 0 is still better, 1 causes actual buffer size dropping with same min and max value, which forcing me to increase the min value. 0 is visable smoother.

CrendKing commented 2 years ago

Yes. Forgot to mention, if you are hardware bottlenecked, you need to raise the max value respectively. The min value only affects the initial state, and since decrease step is 0 now, it should not matter if you are playing a long video.

The reason this works is because when you play in 4x playback rate, the input frame rate is way over the average fps stored in the video (e.g. 30fps). VPSF thinks you are over-buffered, so it tries to decrease the extra source buffer to conserve resource, until the buffer size reaches 0. Once there, it's only a matter of time when the input rate falls behind the output rate, causing frame drop and jitter.

By setting the decrease step to 0, the buffer never shrinks, so you will always have the buffer for the high playback rate. This trick is specifically tailored for your "play fast instead of seek" style. People who do seekings should not do this.

ssssssbbb commented 2 years ago

Thanks for the tailoring!!

ssssssbbb commented 2 years ago

Emm... Tried another video which doesn't occupy 100% CPU, v1.30 indeedly has better performance than newer versions.

CrendKing commented 2 years ago

Please review https://github.com/CrendKing/avisynth_filter/wiki/Configuration. You might want to change some setting names.

ssssssbbb commented 2 years ago

Please review https://github.com/CrendKing/avisynth_filter/wiki/Configuration. You might want to change some setting names.

It works, thanks!