You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apparently, the filter decodes every frame since the last keyframe (k) to the current frame (i). But it caches none of these intermediate frames, so when asking for the previous frame (i - 1) it decodes all frames from k to i - 1 again. And on top of that, it doesn't seem to use more than 2 threads, so it doesn't take advantage of the hardware concurrency.
It would be great if something could be done about this.
Cheers.
The text was updated successfully, but these errors were encountered:
Regarding the 2 cpu limit, it seems ffmpeg's libavcodec vp9 decoder could
only use at most 2 cpus, even if playing forward.
Caching previous decoded frames when seeking could be done, but it will
only help your specific case of playing backwards, and it will actually be
detrimental to the most common use case, i.e. playing forwards after the
seek.
In fact, I believe this is better addressed at the AVS/VS level. It could
detect that you're going to request frames from a source filter backwards
and reorder the requests and cache them accordingly.
Hi,
To reproduce this issue you can use any high resolution video from YouTube. For example:
yt-dlp -f 308 https://www.youtube.com/watch?v=LXb3EKWsInQ
(webm, VP9, 1440p)Then load it into AviSynth and play it backwards:
For me, it runs painfully slow.
Apparently, the filter decodes every frame since the last keyframe (
k
) to the current frame (i
). But it caches none of these intermediate frames, so when asking for the previous frame (i - 1
) it decodes all frames fromk
toi - 1
again. And on top of that, it doesn't seem to use more than 2 threads, so it doesn't take advantage of the hardware concurrency.It would be great if something could be done about this.
Cheers.
The text was updated successfully, but these errors were encountered: