A hook is like a synchronous event that blocks the player. You register
a hook handler with this function. You will get an event, which you need
to handle, and once things are ready, you can let the player continue with
mpv_hook_continue().
Currently, hooks can't be removed explicitly. But they will be implicitly
removed if the mpv_handle it was registered with is destroyed. This also
continues the hook if it was being handled by the destroyed mpv_handle (but
this should be avoided, as it might mess up order of hook execution).
Hook handlers are ordered globally by priority and order of registration.
Handlers for the same hook with same priority are invoked in order of
registration (the handler registered first is run first). Handlers with
lower priority are run first (which seems backward).
See the "Hooks" section in the manpage to see which hooks are currently
defined.
Some hooks might be reentrant (so you get multiple MPV_EVENT_HOOK for the
same hook). If this can happen for a specific hook type, it will be
explicitly documented in the manpage.
Only the mpv_handle on which this was called will receive the hook events,
or can "continue" them.
@param reply_userdata This will be used for the mpv_event.reply_userdata
field for the received MPV_EVENT_HOOK events.
If you have no use for this, pass 0.
@param name The hook name. This should be one of the documented names. But
if the name is unknown, the hook event will simply be never
raised.
@param priority See remarks above. Use 0 as a neutral default.
@return error code (usually fails only on OOM)
A hook is like a synchronous event that blocks the player. You register a hook handler with this function. You will get an event, which you need to handle, and once things are ready, you can let the player continue with mpv_hook_continue().
Currently, hooks can't be removed explicitly. But they will be implicitly removed if the mpv_handle it was registered with is destroyed. This also continues the hook if it was being handled by the destroyed mpv_handle (but this should be avoided, as it might mess up order of hook execution).
Hook handlers are ordered globally by priority and order of registration. Handlers for the same hook with same priority are invoked in order of registration (the handler registered first is run first). Handlers with lower priority are run first (which seems backward).
See the "Hooks" section in the manpage to see which hooks are currently defined.
Some hooks might be reentrant (so you get multiple MPV_EVENT_HOOK for the same hook). If this can happen for a specific hook type, it will be explicitly documented in the manpage.
Only the mpv_handle on which this was called will receive the hook events, or can "continue" them.
@param reply_userdata This will be used for the mpv_event.reply_userdata field for the received MPV_EVENT_HOOK events. If you have no use for this, pass 0. @param name The hook name. This should be one of the documented names. But if the name is unknown, the hook event will simply be never raised. @param priority See remarks above. Use 0 as a neutral default. @return error code (usually fails only on OOM)