Mpv: Cleanup of default key bindings (second try)

[ghost]

This should be eventually done. But this time, my opinion is that we shouldn't gratuitously change bindings just because.

There are some things that _really_ should be changed and everyone agrees about, such as remapping o.

Some suggestions are controversial, like mapping ESC to exit fullscreen.

Anyway, let the bikeshedding begin.

[giselher]

The keys for next and previous chapter (@ and !) should be changed. Those are one of my most use keys and I have remapped them to 'a' and 's' for convenience.

I rather use [ and ] (currently playback speed) or HOME (POS1) and END for this.

[ghedo]

The c key is pretty annoying (the only time I use it is when I hit it by accident). This also came up in the previous discussion IIRC.

The same applies to w and e though they are probably more useful.

[qmega]

For chapters, I use Ctrl-Left/Right and the back/forward buttons on my mouse (BTN7/8), but both of those only work when there's a vo window.

I have HOME no-osd seek 0 absolute-percent exact to go to the beginning of the file. I think that's fairly intuitive and might be worth being default.

As for ESC, I think exiting fullscreen is what people would expect it to do. Personally, I have it mapped to quit_watch_later.

Also, I agree that some of the rarely used things like c should be unmapped or moved.

[divVerent]

My personal list of mosy hated binds:

• change chapters
• change audio track
• change subtitle track

I always have to look these bind up in the manpage before use. Although I
have no constructive more intuitive idea for these...

[otommod]

Maybe change chapters with [ and ] like @giselher proposed and use a/A and s/S to cycle audio/subtitle tracks both ways. But then what about screenshots. Also, non-QWERTY layouts...

[bodayw]

Seems changing chapters is the most frequently used function here. I would also like the keys for previous/next chapter to be changed to more "intuitive" ones.

I don't know how often would people use pgup/pgdn to seek a file back/forward for 10 minutes, but to me it seems much more useful to change those to previous/next chapter.

But, there are no pgup/pgdn keys on a Mac keyboard...Maybe "[" and "]"? They are now binded to changing playback speed, which IMO are quite rarely used for most people.

Maybe also consider change the multimedia keys PREVIOUS and NEXT to changing chapters instead of seeking back/forward for 1 minute.

[ghost]

Removed c, remapped o.

Chapter seek should definitely remapped. Suggestions were:

• [, ] - not so good on all keyboards, and also occupied by speed changes.
• pgdn, pgup - ok, but doesn't exist on mac.
• ctrl+left/right - ok, but doesn't work on terminal

I think Ctrl could be made work on most terminals, though. What keys does the mac have again?

[ChrisK2]

pgdn, pgup is accessible as fn+down, fn+up on small Mac keyboards.

[mia-0]

On Sunday 03 August 2014 12:19:16 wm4 wrote:

pgdn, pgup - ok, but doesn't exist on mac.

Lies. fn+up/down.

I very much support this change. @/! is awful on non-US layouts.

[Hamuko]

Pgdn, pgup are accessible vial Fn on small Mac keyboards and are found standalone on the wired USB keyboard.

[ and ] are hidden behind Alt+8 and Alt+9 on my keyboard.

Also, if I don't remember incorrectly, Ctrl+Left/Right by default switches spaces left and right on OS X (if you have set up spaces).

[Nyx0uf]

p for pause is weird, all media players use space to pause, personally I remapped p to show_progress

[Argon-]

(I did so too)

[qmega]

I also have p mapped to show_progress.

[ghost]

So what does this mean? Is pgup/pgdown good to go for chapters?

[bodayw]

So what does this mean? Is pgup/pgdown good to go for chapters?

Personally it's more preferable to map single keys for seeking chapters, not key combinations, or at least key combinations can be pressed with one hand. So I would agree to make pgup/pgdown for this (which is already much better than shift+!/@), but since I only use mpv on my Mac, I still hope a pair of single keys could be used, ideally would cause minimum conflict with old key bindings while still intuitive (not easy).

Another suggestion aside from [ and ]: what about < and >? They are currently bound to navigating back/forward in the playlist.
Well maybe there are a lot of folks are using this for their playlists...So I really don't know.

[ghost]

what about < and >?

No, they're terrible. Some keyboards have them on the same key, and without shift it produces < (which is bad intuitively, because without modifiers you'd expect it to go forwards, not back). In fact, playlist navigation could use new bindings too.

[divVerent]

From my side - yes. Just like a for switching audio and s for subtitles.

BTW the av/as delay shortcuts can go. The few who need them (I sometimes
do) can use input.conf for them, and the end users better not be able to
accidentally screw up sync (as restoring to 0 is nontrivial).
Am 05.08.2014 01:21 schrieb "wm4" [email protected]:

So what does this mean? Is pgup/pgdown good to go for chapters?

—
Reply to this email directly or view it on GitHub
https://github.com/mpv-player/mpv/issues/973#issuecomment-51131149.

[Yomi0]

This should be eventually done. But this time, my opinion is that we shouldn't gratuitously change bindings just because.

There are some things that really should be changed and everyone agrees about, such as remapping o.

Some suggestions are controversial, like mapping ESC to exit fullscreen.

Anyway, let the bikeshedding begin.

What if when mpv was full screened, ESC would go back to being windowed, and pressing ESC again while windowed would exit mpv?

[ghost]

Remapped pgup/dwn, keeping the old chapter bindings.

What if when mpv was full screened, ESC would go back to being windowed, and pressing ESC again while windowed would exit mpv?

Perhaps, but then the bindings would be stateful, which would require additional code and more effort from the user to understand how it works.

[ghost]

Removed some bindings I deemed too obscure with commit 90ec333417.

[Bilalh]

I also have p mapped to show_progress.

[ghost]

I also have p mapped to show_progress.

It'd be weird to have both o and p and P have mapped to the same key...

Why not restore 10min seek as Shift+PGUP and Shift+PGDWN ?

Opinions?

[bodayw]

For seeking I would prefer Left and Right mapped to 5 s back/forward instead of 10 s seeking. 5 s seeking back is ideal when you missed a line or a comment and want to go back, while 10 s is a bit too long.

[Hamuko]

I replaced 10 second Left and Right seeking with 5 second seek as well. 10 seconds is pretty long when you just need to get a quick glimpse at something. And it's not like you can't press the key twice.

[Bilalh]

I actually like Left and Right being 10s.

Also I use sub_seek all the time since it very useful when you miss a subtitle. I think it should have a mapping.

e.g I bound Shift+RIGHT no- sub_seek 1 and Shift+LEFT no-osd sub_seek -1

[ghost]

I'd be fine with reducing normal seeking to 5s (Personally I use 1s, which effectively make sit skip to the next/previous keyframes, but it sometimes gets "stuck" with some formats.)

e.g I bound Shift+RIGHT no- sub_seek 1 and Shift+LEFT no-osd sub_seek -1

I agree it should get a default binding, but I think these keys should remain normal precise seeks.

[Bilalh]

Also could you keep, the bindings for next and previous chapter (@ and !), since you can not press fn+up or fn+down (on a mac) with one hand.

[ghost]

Why not restore 10min seek as Shift+PGUP and Shift+PGDWN ?

Someone on IRC made the same suggestion, so I made the change.

[ghost]

I'll change the default seek range to 5s for left/right. Does anyone actually like the 60s seek on the up/down keys?

[giselher]

I'll change the default seek range to 5s for left/right. Does anyone actually like the 60s seek on the up/down keys?

I use them often. How would you change the bindings?

[polyzen]

I've grown accustomed to using short/medium/long seeks.

[ghost]

Changed the left/right keys. I guess we won't touch up/down, then.

[ghost]

Some other things that need to be discussed:

• Should ESC leave fullscreen? Apparently it's a convention not only on OSX, but also on Windows.
• Playlist prev/next should be remapped. The current keys don't work well on all keyboard layouts.
• Whatever else may come up.

[otommod]

I think ESC to leave fullscreen is reasonable and probably least surprising compared to exiting.

[ghost]

What should ESC do when mpv is already windowed (i.e. not fullscreened)? There was a suggestion to make ESC exit the player in this case. But it would require extra complication (either a new command, or a messy mechanism to switch key bindings depending on fullscreen state), and I'm not sure if it's worth the trouble. The alternative is effectively ignoring the key in windowed mode.

[Nyx0uf]

I'd say ignore when not in fullscreen, otherwise I think it's confusing.

[mia-0]

On Friday 12 September 2014 02:48:43 wm4 wrote:

The alternative is effectively ignoring the key in windowed mode.

+1

[ghost]

Made the ESC change.

[qmega]

The other day a friend of mine was using mpv and expected there to be a way to seek to the beginning of the file, so I thought I'd bring it up again. I use HOME for this; the command I use is no-osd seek 0 absolute-percent exact, though I don't know if that's the ideal command for the purpose. (The percent is in case of files that don't start at 0.) I think it's fairly intuitive and I don't see what else you'd use Home for, so it shouldn't hurt to make it default.

[ghost]

Things that still need to be done:

• better playlist navigation
• integrate the seek undo command (revert_seek)
• maybe remap the brightness controls etc. to something more obscure

By the way, I added an input.conf example that allows users to easily restore old bindings:
https://github.com/mpv-player/mpv/blob/master/etc/restore-old-bindings.conf

[Wyatts]

Okay, I can deal with all of this so far. As far as where to put those other things, the vim user in me is thinking u is a good place for undoing things. Looks like it's currently unbound? In most usage scenarios I've seen, playlist stepping tends to be something that happens in bursts, but infrequently; maybe ctrl+PGUP and ctrl+PGDWN? If they don't need to be adjacent, and simply being mnemonic is sufficient, n and p might work, though I don't really like that.

I've never intentionally used the brightness, saturation, and contrast controls. Are they well-exercised by other users? I have a sneaking suspicion that it'd be safe to just unbind them, or replace them with percentage-wise seeks (cf. Youtube). Though that conflicts with volume on 9 and 0... Hmm.

Come to think of it, are the function keys not allowed? That's a whole dozen useful keys! Also insert, delete, and backspace don't look to be mapped.

[ghost]

u

Undoing what?

ctrl+PGUP

Nice idea, but apparently combinations with ctrl are a problem, on osx (they get caught by he system).

brightness controls

Yeah, these could probably be replaced. But not sure if I want to "waste" them on percent-seeks.

function keys

There was a problem with them too.. don't remember.

[Wyatts]

Undoing what?

I was referring to this:

• integrate the seek undo command (revert_seek)

(Worth noting, I had no idea that was even a feature.)

combinations with ctrl are a problem, on osx

Ugh, why am I not surprised? A bit unorthodox, but would it work to use a different modifier for the defaults on Mac? i.e. everything would be the same only using... uh... what bucky bits do they have again? There's "command", that silly squiggle thing, a "control" that actually behaves like meta (IIRC) and...?

not sure if I want to "waste" them on percent-seeks.

I'm not amazingly fond of that myself, but I think they have a problem of signifying, otherwise. Like right now they're bound in pairs, but those pairs are sort of arbitrary and you just have to remember what they do by rote. It's pretty suboptimal.

I _could_ see them being used as toggles for boolean state of something, with the mnemonic being tied to their shifted form (cf. =/- and 9/0). But I'm not sure if a) there are enough desirable functions to bind this way, and b) if any of them could be sensibly associated with those symbols.

That's why I settled for percent seeking as an idea, as it's relatively intuitive and has precedent in a (terrible) player that everyone and their mother has used (granted, probably very few people know about that feature...).

[Hamuko]

Nice idea, but apparently combinations with ctrl are a problem, on osx (they get caught by he system).

What ctrl combinations are a problem on OS X? Because as far as I was aware, the only issue that was being discussed was combining ctrl and the right and left arrow keys, as those are by default bound to Mission Control and are active throughout the system.

Only other problematic ctrl combination that I can quickly think of is ctrl+mouse click, as that is an alternative way to perform right click on OS X.

[ghost]

@Wyatts: ok. I don't overly like the idea for binding u on revert_seek - it's simply too much in the "nowhere" on the keyboard for something you'd press on impulse. Also, undo is usually on ctrl+z.

@Hamuko: if that is so, then ctrl is probably free to go. But it still should be used for features that make sense with video only, because you can't use most ctrl combinations on the terminal.

[Jessidhia]

Ctrl+arrows on OS X are all bound by default (up for mission control, down for single app exposé, left/right for switching desktops), so those are out :(

Also, Ctrl+Mouse1 is identical to Mouse2. There probably are other system-wide Ctrl combinations too.

The remaining bucky bits are Shift, Command (Super/Win key) and Option (Alt); however, Option+(letter) or Shift+Option+(letter) actually send special characters / deadkey accents. I think it's possible to disable that Option key behavior for your window though (at least iTerm has an option to change how it behaves).

A possible hack for OS X is to simply swap Command/Ctrl on the VO window. Some cross-platform apps do that in their respective OS X or Windows port (e.g. iTunes has ⌘, for preferences on OS X, while it's Ctrl+, on Windows).

[ghost]

So do we need an alias or something that maps to ctrl or alt on sane systems, and to command on OSX?

[ghost]

Someone requested alt+enter to be mapped to playlist_prev.

[luke-jr]

I recently updated from 0.3.11 to 0.8.3 and found Enter no longer closes MPV. Is this intentional?

[ChrisK2]

Enter was just supposed to advance to the next file in the playlist and mpv exited when It was at the last file. This was changed since exiting applications on enter is not really intuitive.

See https://github.com/mpv-player/mpv/blob/master/etc/restore-old-bindings.conf on how to restore the old behavior.

[felixq]

I use intensively the brightness controls. contrast, ect. Not everyone watch videos in HD or YouTube.
I also use the speed controls '[ ] backspace'.

[ghost]

We could keep them on more obscure key bindings.

[felixq]

While not remove it's fine with me. I can put them back where they were.

[kevmitch]

Toggling the framedrop with an unmodfied "d" seems kind of unnecessary given that the manpage suggests not to touch it. In contrast deinterlace toggling is far more commonly used and requires a SHIFT+"d". This should probably be inverted.

[ghost]

Done. But I dropped cycling framedrop entirely. It's just entirely useless, because vo framedropping works well enough, and decoder framedropping barely works and is usually not needed. Those who really want it can add it to their custom config.

Next I want to do:

• unmap x and z (changing subtitle delay)
• map R and T to changing subtitle delay
• map ctrl+r and ctrl+t to sub-step

Does anyone not like this?

[pigoz]

• unmap x and z (changing subtitle delay)
• map R and T to changing subtitle delay

Why? Just to free up lowercase bindings?

[ghost]

x/z make no sense on QWERTZ keyboards. The new bindings would make sense on all QWERT keyboads.

Also, I thought it'd be a good idea to require at least a modifier for such keys which are not used that often, but are relatively disruptive to playback. Or maybe that doesn't apply here.

[felixq]

Why do you say that the decoder framedrop is entirely useless? In my case it works better than vo. The vo discards entire blocks of frames while the decoder discards frames every so often, the result is visually more pleasing. I'm not saying do not change it, it's just a comment on framedrop.

On the other hand, as my native language is not English, I use subtitles constantly so it rare I find you put more difficult to use them. I do not understand this: 'x/z make no sense on QWERTY keyboards'.

[bodayw]

I do not understand this: 'x/z make no sense on QWERTY keyboards'.

I think he meant to say it makes no sense on QWERTZ keyboards.

[ghost]

Why do you say that the decoder framedrop is entirely useless? In my case it works better than vo. The vo discards entire blocks of frames while the decoder discards frames every so often, the result is visually more pleasing.

The decoder framedrop code doesn't make too much sense. For example, it still uses the container FPS, which can be wrong. And one old problem with this code was actually that it dropped too much in a row. (This also depends on how many frames are in the video streams which the decoder can safely drop.)

I think he meant to say it makes no sense on QWERTZ keyboards.

Right. I edited it.

[2vek]

In mpv manual, enter key is described as 'go forward in the playlist'.

But,

1. When playing single file, enter exits mpv.
2. When playing two or more files or a playlist, enter play next file, but does not exit mpv on last file of that playlist.
   This behavior is very confusing, especially when first time you encounter it.

I propose that enter key's behavior should be either one of these,

1. "play next or exit".
2. "play next only in playlist" and _never_ exit.

Personally, I think second behavior will be consistent with manual but first one will be more convenient.

[ghost]

I can't reproduce this behavior. "enter" never exits. Are you sure you don't have a non-working playlist entry? If the last entry doesn't contain a file that is playable, mpv will switch to it anyway, and then exit.

[2vek]

Oops, my mistake.

I upgraded my main laptop from debian stable to testing last week. That means mpv got upgraded from 0.6.2 to 0.9.2. While other laptop is still on debain stable.

After testing with some files and playlist, looks like old mpv shows behavior 1 and new mpv show behavior 2. And I mixed them up because I was using both of them yesterday.

I should have verified first before posting.
Sorry.

[ghost]

Yep, we intentionally changed this behavior.

[FichteFoll]

As others have mentioned in https://github.com/mpv-player/mpv/issues/103 already, having the mouse wheel seek is really annoying and I'd rather have it control volume (like in other players) or do nothing instead.

The reason being that the mpv window might be active but the mouse pointer not on-top of it. Some applications (like web browsers) will not scroll when the mouse pointer is not within their window, which makes it a safe thing to do when your mouse is over a different window. For mpv, this is not the case and hitting the mouse wheel a few times will make you seek to a different part of a video and you don't know where you initially came from.

[rossy]

The reason being that the mpv window might be active but the mouse pointer not on-top of it. Some applications (like web browsers) will not scroll when the mouse pointer is not within their window, which makes it a safe thing to do when your mouse is over a different window. For mpv, this is not the case and hitting the mouse wheel a few times will make you seek to a different part of a video and you don't know where you initially came from.

As I said in #103, I totally agree with making the mouse wheel do nothing by default, though it's worth mentioning that this specific behaviour of scrolling the window with keyboard focus rather than the window under the mouse pointer is Windows-specific (X11 doesn't do it) and it differs between Windows versions. For a while, the Windows UX guidelines said to scroll the window under the mouse, but Windows itself dispatched scroll events to the window with keyboard focus. Web browsers and a few other big programs (like Office) have some code to reroute the scroll events back to the window under the mouse (if it's owned by them,) but smaller programs like mpv just handle all the scroll events that Windows gives them.

In Windows 10, Microsoft added a setting to dispatch scroll events to the window under the mouse for all programs (pictured below.) In the November update (I think,) they made it default, so mpv on Windows 10 no longer has this problem. We could probably fix it for Windows 7 as well by ignoring scroll events when the cursor is outside the window, but this would have the effect of disobeying the user's settings on Windows 10.

[mvhulten]

It is great to see active development on a video player. I am an mplayer user and starting/occasional mpv user. I am probably expecting too much similarity between mpv and mplayer (as it is a different video player), and my critique comes a bit late, but I think that the following ideas may be worth putting into the discussion as mpv does not, it appears, stop being developed, which is a good thing!

Were there important reasons to remove keys for adjusting contrast, brightness and so on? I have seen the statement that it is better to change it on the hardware, but that is not really an argument to remove the functionality. If it resulted in less code to maintain, this is a good (but not sufficient) argument.

In general, my opinion is that there should be a very good reason for any change in the user interface, for any program. In this sense I also do not understand why it was necessary to change the 'o' key binding (OSD), or the ←/→ from a 10 s to a 5 s change. When any improvement is subjective or minor, I tend to respect the legacy. Am I getting old?

[FichteFoll]

Some things should be changed eventually to make them better. You'll never leave legacy or tech debt behind if you're resistant to change. While the whole key binding file could probably use an evaluation for each key, which would make adaption of that way easier (through a config option that uses the legacy bindings by default during some adaptation period, for example), some small band-aids are always nice if they don't hurt.

The bindings to cycle video, audio (and subtitle) tracks for example are kind of obscure. I can never remember audio. And some bindings would probably benefit from having their opposite action with a shift modified (like cycling subtitles).

[rossy]

@mvhulten The bindings are gone, but the functionality is still there, so you can restore them if you want. mpv provides a sample input.conf file that restores some of MPlayer's bindings:
https://github.com/mpv-player/mpv/blob/master/etc/mplayer-input.conf

[AirPort]

Were there important reasons to remove keys for adjusting contrast, brightness and so on?

AFAIK they were not touched in the end. You can still change contrast, brightness and so on with 1-8 keys by default, and as far as I remember those were also the exact same keys used in mplayer.

[rossy]

@AirPort Oh, you're right. I assumed they were gone because they were in mplayer-input.conf, but it looks like they're mostly still there. I guess the hue controls were replaced with gamma controls.

[mvhulten]

Thank you all for the useful comments, both on the more philosophical issue (@FichteFoll) and for the practical tip (@rossy).

@AirPort, you are right; I had the experience in the past that by default 0—8 don't do anything in mpv, but that is not the case now (mpv 0.14 on Ubuntu), so it's not an issue.

[ghost]

The bindings to cycle video, audio (and subtitle) tracks for example are kind of obscure. I can never remember audio. And some bindings would probably benefit from having their opposite action with a shift modified (like cycling subtitles).

The current state is not too bad, while changing the bindings would basically confuse every existing mpv user. But I'm still open for a redesign that makes the bindings significantly saner. But I feel like we can't just incrementally reassign individual keys over a couple of releases.

I guess the hue controls were replaced with gamma controls.

Gamma was considered more useful.

[FichteFoll]

But I feel like we can't just incrementally reassign individual keys over a couple of releases.

Indeed, that would be awful.

I believe it has to be an "everything at once" approach with the deprecation periods known by other software. As in, you add the new feature but it's disabled by default. Later (or at the same time) you add deprecation notices so that people have time to adapt. Then you change the default but have the old option still for some users until it gets completely removed at a later time.

I still like the draft by @lachs0r in the other issue a lot: https://github.com/mpv-player/mpv/issues/103#issuecomment-30597806 (with a couple minor adjustments). This could definitely be used as a base.

(Btw, am I the only one who prefers their down key to seek foward and their up key to seek backward? Same for chapters on page up/down. I mean, that's how they usually work with scrolling.)

[Tratoschek]

Another suggestion: Since page down and page up was mapped to chapters (good mapping btw), on media files without chapters there are meaningless. What about (re)map page down and page up to 10 minutes seek, but only if there are no chapters present? So they can always be used to navigate quickly in the media.

[thebombzen]

Is this still relevant at this point, or are the keybindings pretty stable as of now? I personally do not think they need to be changed at this point.

[Tratoschek]

Do you refer to my post? This change does not force the user to change old behaviour, but instead provides more functionality in some cases, so I'd say this don't break any stable behaviour, but is simply a feature.

[kevmitch]

Do you refer to my post? This change does not force the user to change old behaviour, but instead provides more functionality in some cases, so I'd say this don't break any stable behaviour, but is simply a feature.

mpv doesn't currently offer a way to make state-dependent keybindings outside of scripts. I'm not sure if it should either beyond the current toggle / cycle functionality.

[FichteFoll]

I thought that crossed my mind yesterday were key chords, where a sequence of keys could be assigned to an action much like vim bindings. I.e. zs to toggle subtitles, za to toggle audio, zd to toggle debanding. Furthermore, actions could be multiplied by pressing number keys before them, i.e. 10RIGHT would invoke the action on the right key 10 times (precompute what would happen as opposed to actually seeking 10 times).

A problem with that might be that currently the number keys are already occupied. If modal bindings existed, comparable to i3wm, they could be grouped into an "adjustments" mode or similar. Except for volume, as that needs to remain accessible.

I know this is talking big as the implementation and the required changed to key bindings are considerably significant, but this is all about brainstorming imo. mpv just has a lot of commands and binding even a subset of that to a single set of keys seems difficult.

---

Regarding the current state of key bindings: I'm not too happy with the defaults, hence why my input.conf has many bindings to tweak them to my liking. I haven't overhauled the whole thing though and only iterate on it when I need a certain binding. Imo my ideas above would help with the jungle of bindings greatly.

[garoto]

[...] where a sequence of keys could be assigned to an action much like vim bindings. I.e. zs to toggle subtitles, za to toggle audio, zd to toggle debanding.

It's also possible to bind a command to a sequence of keys:
a-b-c show-text "command run after a, b, c have been pressed"

Already a feature no?

[FichteFoll]

Indeed, it looks like it. This is great and probably something the default bindings could benefit from.

[ipatch]

Am I the only one thinking that scroll up & scroll down on a touchpad should respectively raise & lower the volume 🔈 of the playback?

And that moving from left to right on the trackpad should scrub through the playback of whatever is being played with mpv?

As it currently stands with mpv 0.28.0 scrolling up & down scrubs through the playback, and scrolling left / right adjusts the volume of the playback. ¯\_(ツ)_/¯

I am aware these settings can be changed in the input.conf file, but I strongly suggest my suggestions would make for a more sane 👩‍⚕️ overall default experience

Just harping 🎵 on that attention to detail thing.

[FichteFoll]

FWIW, here are my bindings:

https://github.com/FichteFoll/dotfiles/blob/master/mpv/.config/mpv/input.conf

• Cycling tracks uses a key that makes sense (i.e. a for audio, v for video, e for edition, u for subtitles (s is for screenshots)) and the same key with shift to cycle backwards.
• Arrow down and page down seek forward, arrow up and page up seek backward.
• Home and end bindings.
• Volume on mouse wheel.
• I use z-* (where * is some other key) for toggling most things, including visibility of subtitles or debanding. Also for cycling some less commonly used properties like tscale.

The rest is pretty uninteresting in the general sense and just some personal preferences.

[ipatch]

@FichteFoll thanks for sharing. I saw you remapped the scroll up / down to adjust the volume 👍

However, I didn't see a scroll left / right? I don't use a mouse per se as I am on a portable 💻 so I end up using the trackpad / touchpad 99% of the time, so being able to scrub the playback using two fingers ✌🏾 to the left or to right is crucial for my situation.

Thanks again for sharing.

cheers 🍻
Chris

[FichteFoll]

I use this config primarily on my desktop, which has a standard mouse and is not capable of scrolling left and right. I could test if it works for my laptop, but I think I'd end up using the arrow keys to seek anyway.

[ipatch]

@FichteFoll

I now have my trackpad / touchpad setup to the way that seems sane 👩‍⚕️ to my liking. I ended up adding the below to my input.conf

AXIS_UP add volume 2
AXIS_DOWN add volume -2

AXIS_LEFT seek 5 exact
AXIS_RIGHT seek -5 exact

Not exactly sure why the -5 scrubs the playback forward in time 🤔 but moving my two fingers to the right progresses forward in playback, and moving my two fingers to the left scrubs the playback back in time.

[kevmitch]

There was a request over in #5466 for

y sub-step +1 # immediately display next subtitle
g sub-step -1 # immediately display previous subtitle

[ghost]

These were removed once. If they're readded, I think they should use more logical keys.

[Asinin3]

I would really like to see mouse side buttons skipping to next/previous chapters with the default bindings. Almost all other media players I've used do this by default or skip to the next file.

MOUSE_BTN8 add chapter 1 # skip to next chapter
MOUSE_BTN7 add chapter -1 # skip to previous chapter

[xantoz]

From #6361:

Consider using = instead of (or perhaps in addition to) + in some places to avoid having to shift (e.g. on standard US QWERTY layout) for +.

E.g.

ctrl++ add audio-delay 0.100           # this changes audio/video sync
ctrl+= add audio-delay 0.100           # convenience, no stretching for shift
ctrl+- add audio-delay -0.100

Alt++     add video-zoom   0.1
Alt+=     add video-zoom   0.1
Alt+-     add video-zoom  -0.1