Suggest more configurable script-opts for mouse (wheel) scrollling in Timeline

[crnkv]

I'm a MPV-lazy user. I quite appreciate its uosc config with timeline_step = 1 because I can use LEFT and RIGHT keys for 5s to 60s jumps and use mouse wheel scrolling for quick-and-smooth forward/backward

...except for the fact that MPV almost never exactly seeks +1s or -1s because MPV defaults to keyframes seeks, while most video have keyframes around every 5s.

I tried myself some hacks to implement mouse scrolling for +/-1s exact seeks, turns out to be smooth enough for general 30fps 720P or 1080P video without severe performance impact. (Glitches on 60fps 1080P or 4K)

To do this with uosc script-opts, I suggest use something like mp.commandv('seek', options.timeline_step, options.timeline_scroll_flag) or options.timeline_scroll_mode in Timeline.lua , with timeline_scroll_flag = exact in script-opts.

Furthermore, something like timeline_scrollup_cmd = set pause yes; no-osd seek 1 exact (or timeline_scrolldown_cmd) in script-opts would be preferably even better (this should override timeline_step when it's not nil), for it is even more configurable for users.

What do you think?

[tomasklaen]

Sorry for late reply. Completely forgot about this.

I don't like the suggestions. They over-complicate the options and don't solve an issue, since it's a dynamic per file problem (depending on decoding speed), which can't be solved with a static option.

Wheel on timeline is a high frequency event, and we can't risk it being slow by using exact seeking flags.

The only way I'd use exact seeks on wheel is if we were able to detect how much is the machine struggling with decoding the current file, and we'd enable exact only if it's below some threshold.

Not sure if this is possible. PR welcome.

[crnkv]

I, too, think that auto-detect video decoding effort would be unrealistic.

But what I was suggesting is neither to impose exact seek nor to auto-detect this mode/flag per file.

I was saying that, wheel scrolling on timeline works perfectly fine on default +/-5s keyframe seek, and this ought to be the default. But when I want a +/-1s scrolling experience on a set of video files (that I decide to be easy to decode) (for me, that's nearly all of my video files, I can accept this as a static option), I just couldn't do this without tweaking the lua scripts.

So what I was asking is that when options.timeline_scroll_flag is not set, just do the default mp.commandv('seek', options.timeline_step), otherwise mp.commandv('seek', options.timeline_step, options.timeline_scroll_flag), so that I can customize timeline_scroll_flag = exact as a static option without tweaking the code itself.

[tomasklaen]

Actually, we could just use the exact seek if the timeline_step is small enough, like < 3 or something. What would be a good threshold here? What is the usual distance of key frames in videos?

[crnkv]

Ok that may do. On the usual distance of keyframes, my incomplete observation is that youtube seems to give 2s, bilibili seems to give 5s. As for anime streaming platforms (say, Crunchyroll) (maybe including Netflix) and some anime Raw-releases, keyframe intervals seem to be 1 or 2s. As for subtitled re-encoded animes or movies (usually BDRip), keyframe intervals vary a lot - some give 2-10s varying interval, others give 5-20s varying interval, or even 10-30s.

I'm not sure about the thredshold, but 3s seems reasonable for me.

My only concern is that people might be confused by this implicit shift of logic - at first one may set timeline_step = 3 and experiences +/-5s jumps onto keyframes, and then one may set timeline_step = 2 and suddenly finds mpv doing exact seeks, but unexpectedly at a cost of heavier machine decoding workloads.

It can probably meet most people's needs, I guess. I'm just thinking about bonus explicitness in user configs. (Plus, people cannot do +/-3s exact seeks with this logic and threshold, they can only choose either +/-2s exact seeks or +/- 5s keyframe seeks - but that's just really minor needs.)

[tomasklaen]

Commit above adds ! suffix, so you can do this to enable exact seeks:

timeline_step=1!

I still don't think this is a good solution as you'll suffer on big videos. If anyone knows if it's possible to detect decoding effort, let me know.

[crnkv]

Many thanks! I agree that I may occasionally run into problematic "big videos" (actually most likely on 60fps videos), but on my AMD Radeon 780M laptop the GPU workload during continuous 1s scrolling on 30fps videos is only ~30%, compared to ~13% during normal playback. It means that usually I won't feel noticeable lags on scrolling, and I'm fine with it.