Keyboard/seek performance about lossless-cut HOT 9 CLOSED

Issue is there in 3.54 but not as bad (gets through more of the file when seeking from the beginning before stalling behavior starts).

from lossless-cut.

is it the same as #1727 ?

from lossless-cut.

is it the same as #1727 ?

It sounds similar but I’m getting it while seeking freshly-opened files (i.e. one segment defined that’s the full file length)

from lossless-cut.

ok, so the issue is the same as recorded in this video? https://www.youtube.com/watch?v=LB20fyxMDU4 e.g. the "main" cursor occationally freezes for a second before continuing?

from lossless-cut.

Similar, but on my machine the performance issue is much worse. It never catches up again once the playback and seek position cursors get out of sync if the cursor button is held.

from lossless-cut.

what kind of hardware do you have? on my macbook air m2 the seeking is smooth as butter:

from lossless-cut.

i realize though that macbook m2 is one of the fastest pc's that money can buy, so i've done some changes that might hopefully improve the situation

from lossless-cut.

what kind of hardware do you have? on my macbook air m2 the seeking is smooth as butter:

The hitching-up/non-smooth behavior is also seen in your video here, but I see it is catching up. I have the acceleration set to 1.0 in my case as I prefer a constant rate of seeking with keys held.

i’ve got middling pc hardware. 3.4ghz i7-6700, GTX 1060, 16g ram, samsung 950 ssd.

I went looking at metrics while issue is occurring and found GPU video decode pegged. I guess maybe this is just a hardware limitation.

from lossless-cut.

oh if you're talking about the video picture not keeping up with the timeline cursor seek, then that's probably due to the computer not able to decode fast enough yea. i'm not sure how to improve that situation, because video playback is offloaded to html5 so i don't control that

from lossless-cut.