celluloid
celluloid copied to clipboard
celluloid-player
Arrow key navigation steps are sometimes too big
Overview Description:
Using the arrow keys sometimes leads to far too big steps. Normally it does 10-second-steps, but in a lot of cases it jumps in 15 seconds or 5-minute-steps, or sometimes even others.
Steps to Reproduce:
Just press the ArrowLeft or ArrowRight key while media plays. It’s easy to reproduce, at least with VP9 and x264.
Actual Results:
Steps not consistent, video is really hard to navigate.
Expected Results:
Consistent 10-second-steps, other intervals via usage of Alt + Arrow or Shift + Arrow.
Version:
v0.15-Flatpak
My issue on this got closed for being duplicate so just commenting that I have the same issue. EDIT: Something I didn't mention in my issue was that I was playing MKV files.
I have the same issue every now and then, but also do have unexpected key repeats in other places, that I can't really put anywhere. Looks like a error in the GNOME Shell/Wayland stack.
@thebitstick @fbruetting Are you using GNOME Shell? Which version and system? Wayland or Xorg?
GNOME Wayland, 3.30.2, on F29. Mentioned this in my closed issue but I am using the Flatpak version from Flathub.
I tested this under Xorg and could not reproduce it at all, so the error is probably not in gnome-mpv, but in GTK or libinput. I reported it here
Not sure if it helps but I'm also experiencing this issue on Fedora 29 Gnome. However the issue does not present if I open the videos in MPV.
This is resolved for me with libinput 1.14.1 and mutter 3.34.0, if anyone can confirm I would suggest closing this issue.
For me on Fedora Silverblue 31 beta it’s sadly still not fixed (with exactly those versions). Sometimes it jumps 5s, sometimes 7s, sometimes 20s and sometimes directly to the end. I also don’t understand what libinput or mutter does have to do with time skipping? I would asume that time skipping is a pure application-internal function…?
Libinput is the library that handles the key presses, which are then passed on to Celluloid/GNOME-MPV. You can find the version number with libinput --version and mutter --version. Are they lower than the listed libinput 1.14.1 and mutter 3.34.0?
Ditto not fixed on Debian Testing/Bullseye. Mutter is 3.34, libinput is 1.14.1, but the steps in the player are just as inconsistent as before.
Note: the issue also occurs when running the player in Weston. I would say it's most likely not related to Mutter.
Libinput may handle key presses, but I can’t image that pressing a key once, gives various amounts of keypresses solely to Celluloid, whereas it works perfectly fine everywhere else.
Additionally, the varying steps are not multiplyers of a base value, like 5/10/15, but totally arbitrary like 7 or 10 seconds. In the end it’s Celluloid itself, which translates key presses into an amount of time to skip. And I suspect the bug to crawl around there.
Agreed with above. If mutter is not the problem, that leaves either libinput or GTK. I can't see something as fundamental as keypresses being broken in libinput without system-wide repercussions, and as for GTK, I have tested playing videos in Wayland Firefox and could not reproduce this issue. The problem is most likely in Celluloid.
@fbruetting, @SimonPilkington: Can you check if this still happens with --input-ar-rate=0?
❯ io.github.celluloid_player.Celluloid --input-ar-rate=0
Unknown option --input-ar-rate=0
❯ io.github.celluloid_player.Celluloid --input-ar-rate=0 Unknown option --input-ar-rate=0
It goes either in your mpv.conf or in the additional mpv options in the Celluloid configuration dialog.
In my short testing, it then still jumps in unpredictable intervals between 5 and 10 seconds. And it’s really arbitrary, as when you repeatedly skip backwards and immediately afterwards skip forwards, there might be up to a ten seconds displacement (i.e. 1:30 (arrow left)⇒ 1:25 (arrow right)⇒ 1:37, where the last value shout rather be 1:30 or 1:31)
This is due to keyframes seeking, and is expected. If you wish to have exact seeking like you described, you must rebind your left and right arrows to use exact seeking. By your description, input-ar-rate=0 fixes the problem for you as well.
I did exactly that. I put that into the appropriate configuration dialog field you mentioned.
You can't rebind keys in the configuration dialog. You must use an input.conf with this content:
LEFT seek -10 exact
RIGHT seek 10 exact
The issue is still present on Arch Linux as of 2020-04-23.
Please note that mpv itself is not affected by the issue.
It seems to me when such a wrong long-seek occurs, that there is a greater time span between e.g. arrow-right-keydown and the video resuming playback at the new location, compared to a step that seeks for the correct amount.
Therefore my hypothesis is that the bug is triggered when seeking takes more time, for example when by chance more video data needs to be read to complete the seek. The cause would then be that the arrow-right-keyup event is not processed while this seeking/reading is taking place, instead only afterwards with a delay, which then causes the auto-repeat to kick in and not only a single step is seeked, but multiple steps.
This would be consistent with these observations:
-
input-ar-rate=0works around the issue - seeking with the mouse wheel on the seek bar does not exhibit the buggy behavior
- the faulty long-seeks appear to be of various, seemingly arbitrary lengths
Arch Linux celluloid package, version 0.18-1, build date 2019-11-09
GNOME Shell 3.36.1 on Wayland, Linux 5.6.6-arch1-1 x86_64
@gnome-mpv this is definitely your bug see comment of eomanis, I can reproduce in Manjaro KDE
I agree with eomanis' analysis, but we still need to figure out if the key event is being delayed in Celluloid or mpv.
Celluloid sends key events to mpv using the keyup/keydown input commands, so there are a few possibilities here. There could be a delay in Celluloid causing the input commands to be sent late, or mpv takes too long to process the commands, or a combination of both.
Confirming this is an issue for me as well.
Pressing the seek keys (left and right arrows) will seek arbitrarily, same for 1 second seek (with shift). It even occured that it would seek for so long that I would be "stuck" in full screen (and it wouldn't respond to any other input).
Kernel: 5.4.0-42-generic
DE: Plasma
WM: KWin
CPU: AMD Ryzen 7 3700X (16) @ 3.600GHz
GPU: AMD ATI Radeon RX 5600 OEM/5600 XT / 5700/5700 XT
Memory: 11069MiB / 15991MiB
Same problem on openSUSE Tumbleweed, Gnome 40 at Wayland and 0.20 version of celluloid.
It is very frustrating to navigate on video with constantly random time jumps.
Is there any downside to binding the left and right keys to seek exactly by default (like what @SimonPilkington does above)?
Is there any downside to binding the left and right keys to seek exactly by default (like what @SimonPilkington does above)?
@j-james: Seeks might take longer on slower machines, and if @eomanis's analysis is correct, that could make the problem worse in some cases. input-ar-rate=0 should be a more reliable workaround, but then you won't be able to hold a key down to do multiple seeks.