search

mifi / lossless-cut

The swiss army knife of lossless video/audio editing
GNU General Public License v2.0
23.24k stars 1.18k forks source link

Keyboard/seek performance #1881

Open mbs opened 4 months ago

mbs commented 4 months ago

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

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 commented 4 months ago

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 commented 4 months ago

is it the same as #1727 ?

mbs commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

https://github.com/mifi/lossless-cut/assets/402547/f67e0a24-1903-490c-bbf7-e6466cbf6e57

mifi commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 2 months ago

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 commented 2 months ago

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 https://github.com/mifi/lossless-cut/issues/1881#issuecomment-2067983198, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMLIBONDBIQSHF3RGC2WTY6ODQBAVCNFSM6AAAAABCY7T4JSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXHE4DGMJZHA . You are receiving this because you authored the thread.Message ID: @.***>

Mrnofish commented 1 month ago

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.