There should be some default shortcut to change or skip chapters, now that Matroska chapters are supported.
Have you seen ! and @ ?
What he said. Also, these keys were originally mapped for US keyboards, and they really suck on some other keyboard layouts (since shortcuts go by the character the keys produce, not the location).
Eventually, I want to change the default bindings. Personally, I have previous/next chapter on F11/F12.
Personally, I have previous/next chapter on PGUP/PGDWN (as well as MOUSE_BTN5/MOUSE_BTN6), and also keep previous/next playlist near by as HOME/END. Though such a layout only works well if you have a full keyboard with these keys on their own island.
If you really want to heavily customize your key-bindings, set "no-input-default-bindings" in your config file, download input.conf https://raw.github.com/mpv-player/mpv/master/etc/input.conf if it doesn't already exist, then modify/add/delete bindings as desired.
On a side note, MOUSE_BTN0 & MOUSE_BTN0_DBL are non-functional on Windows, even if you bind them to something --input-test doesn't detect those buttons at all. The following is an example of my complete input.conf, stripped down and customized for easy intuitive accessibility to common functionality which I'd actually use normally.
ESC quit
MOUSE_BTN0 ignore
MOUSE_BTN0_DBL ignore
MOUSE_BTN1 cycle fullscreen
MOUSE_BTN2 cycle pause
MOUSE_BTN3 add volume 1
MOUSE_BTN4 add volume -1
MOUSE_BTN5 add chapter -1
MOUSE_BTN6 add chapter 1
RIGHT seek 10
LEFT seek -10
UP seek -60
DOWN seek 60
Ctrl+RIGHT no-osd seek 1 - exact
Ctrl+LEFT no-osd seek -1 - exact
Ctrl+UP no-osd seek -5 - exact
Ctrl+DOWN no-osd seek 5 - exact
. frame_step
, frame_back_step
[ sub_step -1
] sub_step +1
SPACE cycle pause
0 stop
HOME playlist_prev
END playlist_next
ENTER playlist_next force
PGUP add chapter -1
PGDWN add chapter 1
m cycle mute
d cycle deinterlace
c cycle colormatrix
s cycle sub
F cycle sub-forced-only
V cycle ass-vsfilter-aspect-compat
a cycle audio
v cycle video
TAB cycle program
e cycle edition
A cycle angle
t cycle ontop
f cycle fullscreen
o osd
i show_text "${filename}"
p show_progress
` screenshot
S screenshot video
D cycle framedrop
POWER quit
MENU cycle osd
PLAY cycle pause
PAUSE cycle pause
PLAYPAUSE cycle pause
STOP quit
FORWARD seek 60
REWIND seek -60
NEXT playlist_next
PREV playlist_prev
VOLUME_UP add volume 1
VOLUME_DOWN add volume -1
MUTE cycle mute
CLOSE_WIN quit
CLOSE_WIN {encode} quit
@otommod Didn't know about ! and @, but this really sucks on my Portuguese keyboard since ! is Shift+1 and @ is Alt Gr+2. On my other keyboards (with US and Brazillian Portuguese layouts) it's fine, but there should be other keyboards layouts out there that sucks with this combination too.
The most intuitive I think would be to have next chapters using Page UP/Page Down, but any thing that is common on any keyboard layout would be better.
On a side note, MOUSE_BTN0 & MOUSE_BTN0_DBL are non-functional on Windows
The win32 windowing code does this in order to implement moving the window by clicking and dragging it. Only in fullscreen mode the click is actually left through, or if the ctrl modifier is set. A bit questionable if you ask me.
The most intuitive I think would be to have next chapters using Page UP/Page Down, but any thing that is common on any keyboard layout would be better.
Actually, the keys ins/del/home/end are still free and could be used to map chapter switching.
I would request that you never map "insert key" to anything, since like "num lock" and "scroll lock", those keys can have unintended side-effects with either keyboard indicator lights or global OS functionality.
Since when has that been the case? Is this a windows thing? Traditionally, "insert" toggles between insert and overwrite mode in text fields, so it should be very well useable by applications.
Traditionally, "insert" toggles between insert and overwrite mode in text fields, so it should be very well useable by applications.
I may be mistaken, but I was under the impression that the "insert" key is actually a global keybinding, and the Windows OS is in charge of keeping track of the current on/off state. Even if this is not the case, that it has the default functionality of switching between insert and overwrite modes in text fields, is exactly why I believe it should normally be avoided as a default application binding.
To be continued in issue #103.
Most helpful comment
Have you seen ! and @ ?