Keyboard/seek performance

[mbs]

I have a lot of issues to go through, so in order to make it easier for me to help you, I ask that you please try these things first

• Try with the newest version from GitHub (also it might have been fixed in latest nightly build)
• Read the documentation and FAQ, Known issues, Troubleshooting
• Search for your problem under Issues or Discussions
• If you have a problem only with a particular file (or file type), use this form instead
• Windows 7, 8 and 8.1 are no longer supported. This is not a question about Windows 8.1 or older.

Operating System

Windows 10

Steps to reproduce

In 3.59.1 I'm getting poor keyboard seek performance similar to the old one in closed issue #1097 . Holding keyboard button for seek works for a bit but then stalls indefinitely if the button is held. Issue appears to be worse the later in a file we are, doesn't appear for a bit at the beginning of the file. Later in the file it often only shows one or two frames before stalling.

Expected behavior

Keyboard seek on button press is wanted at good performance without stalling.

Actual behavior

Position stalls when keyboard button is held for seeking.

Share log

No response

[mbs]

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).

[mifi]

is it the same as #1727 ?

[mbs]

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)

[mifi]

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?

[mbs]

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.

[mifi]

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

Screen.Recording.2024-02-10.at.18.28.53-00.00.04.579-00.00.10.625.mov

[mifi]

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

[mbs]

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.

[mifi]

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

[mifi]

I have done some experimentation with the html5 video tag and found that when waiting for the seeked event after seeking, the scrubbing can become much smoother, so it's something to look into implementing.

[mbs]

For my own purposes, I would like to see a “pessimistic” seeking, where we wait until the seeking completes before letting the seek-request position keep moving forward.

…

On Sun, Apr 21, 2024 at 04:48 Mikael Finstad ***@***.***> wrote: I have done some experimentation with the html5 video tag and found that when waiting for the seeked event after seeking, the scrubbing can become much smoother, so it's something to look into implementing. — Reply to this email directly, view it on GitHub <#1881 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMLIBONDBIQSHF3RGC2WTY6ODQBAVCNFSM6AAAAABCY7T4JSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXHE4DGMJZHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Mrnofish]

Following up the comments from #1957 after the 3.61 update:

The changes introduced appear to have improved the performance in the latter parts of longer files, although more testing will be needed to ensure this is always the case.

Nevertheless, I still have to set the seek interval at 0.9 (possibly every value <1 is OK but I've not tested it) for the video viewport to keep getting updated.

Bumping it up to 1, causes the previously observed issue, where the viewport only gets updated for a short time, and releasing the seek key is necessary in order to get it to update again.

[mifi]

I have done some experimentation with the html5 video tag and found that when waiting for the seeked event after seeking, the scrubbing can become much smoother, so it's something to look into implementing.

this was already implemented and seeking is now much smoother - closing.