mpv-player / mpv-player/mpv

libmpv: Emit "input-bindings" change event immediately when bindings are changed

Open
#10,275 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

meta:feature-request
Dominant language
C
Stars
37k
Forks
3.5k
Avg merge
1d 10h
Merged PRs (30d)
22

Description

Problem context

I'm a contributor to IINA, a popular video player for MacOS written in Swift but which uses libmpv as a backend via Swift's C translation. Unlike many other frontends for mpv, IINA maintains its own list of key bindings and does not submit keypresses directly to the mpv instance but instead translates the keypresses into mpv commands which it then sends to the mpv instance via mpv_command or other APIs.

I'm working on restoring key input in Lua script. Currently many scripts are unusable because they rely on dynamically assigning and removing key bindings at runtime. IINA's extra key bindings layer blocks keystrokes which it doesn't recognize, which prevents arbitrary keystrokes from reaching mpv. So I need the mpv layer to notify IINA's key bindings layer that a new binding has been added or removed.

I've been using the webm Lua script for my tests, which is a good test case because it's activated by an initial keystroke (default 'W'), whereby it displays an on-screen OSD and sets keybindings via mp.add_key_binding and mp.add_forced_key_binding which represent options for the user to choose. The user can choose an option or type ESC (also dynamically set) to dismiss the OSD, which calls mp.remove_key_binding to remove the bindings and exit the script.

I added a property observer for input-bindings via mpv_observe_property. When scripts call one of the above 3 key binding APIs I expected to immediately receive an MPV_EVENT_PROPERTY_CHANGE event for the input-bindings property. But this doesn't happen right away. I do receive the event but only once the video has been stopped and the mpv instance has gone idle, and then I receive key bindings which are then out-of-date (see logs).

With mpv's debug log enabled, I am able to see Run command: define-section and Run command: enable-section emitted at the right time and which contain the information I need, and I'm already halfway to parsing and extracting this data in IINA via MPV_EVENT_LOG_MESSAGE events, but I know that's "not the right thing to do" ;-)

Expected behavior of the wanted feature

When clients call mp.add_key_binding, mp.add_forced_key_binding, and mp.remove_key_binding, observers should get an MPV_EVENT_PROPERTY_CHANGE event for input-bindings containing an array of only the new and/or removed bindings, with forced set to true/false and any other attributes (repeatable? enabled?)

Alternative behavior of the wanted feature

Same notification behavior as Expected, but would settle for either:

  1. an event with data containing all of the keybindings (not just the deltas), or
  2. an event with no data but with a guarantee that an immediate call to mpv_get_property for input-bindings will return the most up-to-date bindings
Log file

output.txt

Timeline

  • 0.0 Player start
  • 5.793 User presses 'W' to display webm OSD
  • 5.806 webm bindings set
  • 11.379 Player stop

Also attaching the IINA log, which was observing and printing mpv log events (filter lines for mpv log:) but may have relevant client side stuff
iina.log

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the input-bindings property through mpv_observe_property and mpv_get_property, then reproduce the webm script's calls to mp.add_key_binding, mp.add_forced_key_binding, and mp.remove_key_binding. Compare the timing and contents of the resulting MPV_EVENT_PROPERTY_CHANGE event with the expected binding updates; done means observers receive an immediate, current notification.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, lua
Domain
api
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.