diff options
Diffstat (limited to 'DOCS/man/lua.rst')
| -rw-r--r-- | DOCS/man/lua.rst | 332 |
1 files changed, 180 insertions, 152 deletions
diff --git a/DOCS/man/lua.rst b/DOCS/man/lua.rst index 10da40016c..cdbe7498c2 100644 --- a/DOCS/man/lua.rst +++ b/DOCS/man/lua.rst @@ -1,12 +1,7 @@ LUA SCRIPTING ============= -mpv can load Lua scripts. Scripts passed to the ``--script`` option, or found in -the ``scripts`` subdirectory of the mpv configuration directory (usually -``~/.config/mpv/scripts/``) will be loaded on program start. mpv also appends the -``scripts`` subdirectory to the end of Lua's path so you can import scripts from -there too. Since it's added to the end, don't name scripts you want to import -the same as Lua libraries because they will be overshadowed by them. +mpv can load Lua scripts. (See `Script location`_.) mpv provides the built-in module ``mp``, which contains functions to send commands to the mpv core and to retrieve information about playback state, user @@ -30,6 +25,55 @@ A script which leaves fullscreen mode when the player is paused: mp.observe_property("pause", "bool", on_pause_change) +Script location +--------------- + +Scripts can be passed to the ``--script`` option, and are automatically loaded +from the ``scripts`` subdirectory of the mpv configuration directory (usually +``~/.config/mpv/scripts/``). + +A script can be a single file. The file extension is used to select the +scripting backend to use for it. For Lua, it is ``.lua``. If the extension is +not recognized, an error is printed. (If an error happens, the extension is +either mistyped, or the backend was not compiled into your mpv binary.) + +mpv internally loads the script's name by stripping the ``.lua`` extension and +replacing all nonalphanumeric characters with ``_``. E.g., ``my-tools.lua`` +becomes ``my_tools``. If there are several scripts with the same name, it is +made unique by appending a number. This is the name returned by +``mp.get_script_name()``. + +Entries with ``.disable`` extension are always ignored. + +If a script is a directory (either if a directory is passed to ``--script``, +or any sub-directories in the script directory, such as for example +``~/.config/mpv/scripts/something/``), then the directory represents a single +script. The player will try to load a file named ``main.x``, where ``x`` is +replaced with the file extension. For example, if ``main.lua`` exists, it is +loaded with the Lua scripting backend. + +You must not put any other files or directories that start with ``main.`` into +the script's top level directory. If the script directory contains for example +both ``main.lua`` and ``main.js``, only one of them will be loaded (and which +one depends on mpv internals that may change any time). Likewise, if there is +for example ``main.foo``, your script will break as soon as mpv adds a backend +that uses the ``.foo`` file extension. + +mpv also appends the top level directory of the script to the start of Lua's +package path so you can import scripts from there too. Be aware that this will +shadow Lua libraries that use the same package path. (Single file scripts do not +include mpv specific directory the Lua package path. This was silently changed +in mpv 0.32.0.) + +Using a script directory is the recommended way to package a script that +consists of multiple source files, or requires other files (you can use +``mp.get_script_directory()`` to get the location and e.g. load data files). + +Making a script a git repository, basically a repository which contains a +``main.lua``` file in the root directory, makes scripts easily updateable +(without the dangers of auto-updates). Another suggestion is to use git +submodules to share common files or libraries. + Details on the script initialization and lifecycle -------------------------------------------------- @@ -127,12 +171,19 @@ The ``mp`` module is preloaded, although it can be loaded manually with ``mp.command_native_async(table [,fn])`` Like ``mp.command_native()``, but the command is ran asynchronously (as far - as possible), and upon completion, fn is called. fn has two arguments: - ``fn(success, result, error)``. ``success`` is always a Boolean and is true - if the command was successful, otherwise false. The second parameter is - the result value (can be nil) in case of success, nil otherwise (as returned - by ``mp.command_native()``). The third parameter is the error string in case - of an error, nil otherwise. + as possible), and upon completion, fn is called. fn has three arguments: + ``fn(success, result, error)``: + + ``success`` + Always a Boolean and is true if the command was successful, + otherwise false. + + ``result`` + The result value (can be nil) in case of success, nil otherwise (as + returned by ``mp.command_native()``). + + ``error`` + The error string in case of an error, nil otherwise. Returns a table with undefined contents, which can be used as argument for ``mp.abort_async_command``. @@ -240,7 +291,9 @@ The ``mp`` module is preloaded, although it can be loaded manually with an example). The name should be unique across other bindings in the same script - if not, the previous binding with the same name will be overwritten. You can omit the name, in which case a random name is generated - internally. + internally. (Omitting works as follows: either pass ``nil`` for ``name``, + or pass the ``fn`` argument in place of the name. The latter is not + recommended and is handled for compatibility only.) The last argument is used for optional flags. This is a table, which can have the following entries: @@ -251,11 +304,25 @@ The ``mp`` module is preloaded, although it can be loaded manually with ``complex`` If set to ``true``, then ``fn`` is called on both key up and down events (as well as key repeat, if enabled), with the first - argument being a table. This table has an ``event`` entry, which - is set to one of the strings ``down``, ``repeat``, ``up`` or - ``press`` (the latter if key up/down can't be tracked). It further - has an ``is_mouse`` entry, which tells whether the event was caused - by a mouse button. + argument being a table. This table has the following entries (and + may contain undocumented ones): + + ``event`` + Set to one of the strings ``down``, ``repeat``, ``up`` or + ``press`` (the latter if key up/down can't be tracked). + + ``is_mouse`` + Boolean Whether the event was caused by a mouse button. + + ``key_name`` + The name of they key that triggered this, or ``nil`` if + invoked artificially. If the key name is unknown, it's an + empty string. + + ``key_text`` + Text if triggered by a text key, otherwise ``nil``. See + description of ``script-binding`` command for details (this + field is equivalent to the 5th argument). Internally, key bindings are dispatched via the ``script-message-to`` or ``script-binding`` input commands and ``mp.register_script_message``. @@ -343,13 +410,21 @@ The ``mp`` module is preloaded, although it can be loaded manually with of times in a row, only the last change triggers the change function. (The exact behavior depends on timing and other things.) + If a property is unavailable, or on error, the value argument to ``fn`` is + ``nil``. (The ``observe_property()`` call always succeeds, even if a + property does not exist.) + In some cases the function is not called even if the property changes. - Whether this can happen depends on the property. + This depends on the property, and it's a valid feature request to ask for + better update handling of a specific property. If the ``type`` is ``none`` or ``nil``, sporadic property change events are possible. This means the change function ``fn`` can be called even if the property doesn't actually change. + You always get an initial change notification. This is meant to initialize + the user's state to the current value of the property. + ``mp.unobserve_property(fn)`` Undo ``mp.observe_property(..., fn)``. This removes all property handlers that are equal to the ``fn`` parameter. This uses normal Lua ``==`` @@ -404,8 +479,8 @@ The ``mp`` module is preloaded, although it can be loaded manually with (``true``). This value is used when the timer expires (but before the timer callback function fn is run). - Note that these are method, and you have to call them using ``:`` instead - of ``.`` (Refer to http://www.lua.org/manual/5.2/manual.html#3.4.9 .) + Note that these are methods, and you have to call them using ``:`` instead + of ``.`` (Refer to https://www.lua.org/manual/5.2/manual.html#3.4.9 .) Example: @@ -431,11 +506,16 @@ The ``mp`` module is preloaded, although it can be loaded manually with Return the name of the current script. The name is usually made of the filename of the script, with directory and file extension removed. If there are several scripts which would have the same name, it's made unique - by appending a number. + by appending a number. Any nonalphanumeric characters are replaced with ``_``. .. admonition:: Example - The script ``/path/to/fooscript.lua`` becomes ``fooscript``. + The script ``/path/to/foo-script.lua`` becomes ``foo_script``. + +``mp.get_script_directory()`` + Return the directory if this is a script packaged as directory (see + `Script location`_ for a description). Return nothing if this is a single + file script. ``mp.osd_message(text [,duration])`` Show an OSD message on the screen. ``duration`` is in seconds, and is @@ -447,18 +527,6 @@ Advanced mp functions These also live in the ``mp`` module, but are documented separately as they are useful only in special situations. -``mp.suspend()`` - This function has been deprecated in mpv 0.21.0 and does nothing starting - with mpv 0.23.0 (no replacement). - -``mp.resume()`` - This function has been deprecated in mpv 0.21.0 and does nothing starting - with mpv 0.23.0 (no replacement). - -``mp.resume_all()`` - This function has been deprecated in mpv 0.21.0 and does nothing starting - with mpv 0.23.0 (no replacement). - ``mp.get_wakeup_pipe()`` Calls ``mpv_get_wakeup_pipe()`` and returns the read end of the wakeup pipe. This is deprecated, but still works. (See ``client.h`` for details.) @@ -513,6 +581,42 @@ are useful only in special situations. Undo a previous registration with ``mp.register_script_message``. Does nothing if the ``name`` wasn't registered. +``mp.create_osd_overlay(format)`` + Create an OSD overlay. This is a very thin wrapper around the ``osd-overlay`` + command. The function returns a table, which mostly contains fields that + will be passed to ``osd-overlay``. The ``format`` parameter is used to + initialize the ``format`` field. The ``data`` field contains the text to + be used as overlay. For details, see the ``osd-overlay`` command. + + In addition, it provides the following methods: + + ``update()`` + Commit the OSD overlay to the screen, or in other words, run the + ``osd-overlay`` command with the current fields of the overlay table. + Returns the result of the ``osd-overlay`` command itself. + + ``remove()`` + Remove the overlay from the screen. A ``update()`` call will add it + again. + + Example: + + :: + + ov = mp.create_osd_overlay("ass-events") + ov.data = "{\\an5}{\\b1}hello world!" + ov:update() + + The advantage of using this wrapper (as opposed to running ``osd-overlay`` + directly) is that the ``id`` field is allocated automatically. + +``mp.get_osd_size()`` + Returns a tuple of ``osd_width, osd_height, osd_par``. The first two give + the size of the OSD in pixels (for video outputs like ``--vo=xv``, this may + be "scaled" pixels). The third is the display pixel aspect ratio. + + May return invalid/nonsense values if OSD is not initialized yet. + mp.msg functions ---------------- @@ -543,14 +647,27 @@ command-line. All you have to do is to supply a table with default options to the read_options function. The function will overwrite the default values with values found in the config-file and the command-line (in that order). -``options.read_options(table [, identifier])`` +``options.read_options(table [, identifier [, on_update]])`` A ``table`` with key-value pairs. The type of the default values is important for converting the values read from the config file or command-line back. Do not use ``nil`` as a default value! The ``identifier`` is used to identify the config-file and the command-line options. These needs to unique to avoid collisions with other scripts. - Defaults to ``mp.get_script_name()``. + Defaults to ``mp.get_script_name()`` if the parameter is ``nil`` or missing. + + The ``on_update`` parameter enables run-time updates of all matching option + values via the ``script-opts`` option/property. If any of the matching + options changes, the values in the ``table`` (which was originally passed to + the function) are changed, and ``on_update(list)`` is called. ``list`` is + a table where each updated option has a ``list[option_name] = true`` entry. + There is no initial ``on_update()`` call. This never re-reads the config file. + ``script-opts`` is always applied on the original config file, ignoring + previous ``script-opts`` values (for example, if an option is removed from + ``script-opts`` at runtime, the option will have the value in the config + file). ``table`` entries are only written for option values whose values + effectively change (this is important if the script changes ``table`` + entries independently). Example implementation:: @@ -640,7 +757,7 @@ strictly part of the guaranteed API. ``mtime`` time of last modification ``ctime`` - time of last metadata change (Linux) / time of creation (Windows) + time of last metadata change ``is_file`` Whether ``path`` is a regular file (boolean) ``is_dir`` @@ -652,7 +769,7 @@ strictly part of the guaranteed API. The booleans ``is_file`` and ``is_dir`` are provided as a convenience; they can be and are derived from ``mode``. - On error (eg. path does not exist), ``nil, error`` is returned. + On error (e.g. path does not exist), ``nil, error`` is returned. ``utils.split_path(path)`` Split a path into directory component and filename component, and return @@ -661,7 +778,7 @@ strictly part of the guaranteed API. ``utils.join_path(p1, p2)`` Return the concatenation of the 2 paths. Tries to be clever. For example, - if ```p2`` is an absolute path, p2 is returned without change. + if ``p2`` is an absolute path, ``p2`` is returned without change. ``utils.subprocess(t)`` Runs an external process and waits until it exits. Returns process status @@ -683,6 +800,8 @@ strictly part of the guaranteed API. directly, instead of calling this legacy wrapper. It is for compatibility only. + See the ``subprocess`` documentation for semantics and further parameters. + ``utils.subprocess_detached(t)`` Runs an external process and detaches it from mpv's control. @@ -701,6 +820,10 @@ strictly part of the guaranteed API. Returns the process ID of the running mpv process. This can be used to identify the calling mpv when launching (detached) subprocesses. +``utils.get_env_list()`` + Returns the C environment as a list of strings. (Do not confuse this with + the Lua "environment", which is an unrelated concept.) + ``utils.parse_json(str [, trail])`` Parses the given string argument as JSON, and returns it as a Lua table. On error, returns ``nil, error``. (Currently, ``error`` is just a string @@ -746,116 +869,7 @@ Example: mp.register_event("file-loaded", my_fn) - - -List of events --------------- - -``start-file`` - Happens right before a new file is loaded. When you receive this, the - player is loading the file (or possibly already done with it). - -``end-file`` - Happens after a file was unloaded. Typically, the player will load the - next file right away, or quit if this was the last file. - - The event has the ``reason`` field, which takes one of these values: - - ``eof`` - The file has ended. This can (but doesn't have to) include - incomplete files or broken network connections under - circumstances. - - ``stop`` - Playback was ended by a command. - - ``quit`` - Playback was ended by sending the quit command. - - ``error`` - An error happened. In this case, an ``error`` field is present with - the error string. - - ``redirect`` - Happens with playlists and similar. Details see - ``MPV_END_FILE_REASON_REDIRECT`` in the C API. - - ``unknown`` - Unknown. Normally doesn't happen, unless the Lua API is out of sync - with the C API. (Likewise, it could happen that your script gets - reason strings that did not exist yet at the time your script was - written.) - -``file-loaded`` - Happens after a file was loaded and begins playback. - -``seek`` - Happens on seeking. (This might include cases when the player seeks - internally, even without user interaction. This includes e.g. segment - changes when playing ordered chapters Matroska files.) - -``playback-restart`` - Start of playback after seek or after file was loaded. - -``idle`` - Idle mode is entered. This happens when playback ended, and the player was - started with ``--idle`` or ``--force-window``. This mode is implicitly ended - when the ``start-file`` or ``shutdown`` events happen. - -``tick`` - Called after a video frame was displayed. This is a hack, and you should - avoid using it. Use timers instead and maybe watch pausing/unpausing events - to avoid wasting CPU when the player is paused. - -``shutdown`` - Sent when the player quits, and the script should terminate. Normally - handled automatically. See `Details on the script initialization and lifecycle`_. - -``log-message`` - Receives messages enabled with ``mp.enable_messages``. The message data - is contained in the table passed as first parameter to the event handler. - The table contains, in addition to the default event fields, the following - fields: - - ``prefix`` - The module prefix, identifies the sender of the message. This is what - the terminal player puts in front of the message text when using the - ``--v`` option, and is also what is used for ``--msg-level``. - - ``level`` - The log level as string. See ``msg.log`` for possible log level names. - Note that later versions of mpv might add new levels or remove - (undocumented) existing ones. - - ``text`` - The log message. The text will end with a newline character. Sometimes - it can contain multiple lines. - - Keep in mind that these messages are meant to be hints for humans. You - should not parse them, and prefix/level/text of messages might change - any time. - -``get-property-reply`` - Undocumented (not useful for Lua scripts). - -``set-property-reply`` - Undocumented (not useful for Lua scripts). - -``command-reply`` - Undocumented (not useful for Lua scripts). - -``client-message`` - Undocumented (used internally). - -``video-reconfig`` - Happens on video output or filter reconfig. - -``audio-reconfig`` - Happens on audio output or filter reconfig. - -The following events also happen, but are deprecated: ``tracks-changed``, -``track-switched``, ``pause``, ``unpause``, ``metadata-update``, -``chapter-change``. Use ``mp.observe_property()`` instead. +For the existing event types, see `List of events`_. Extras ------ @@ -869,8 +883,22 @@ guarantee a stable interface. their result (normally, the Lua scripting interface is asynchronous from the point of view of the player core). ``priority`` is an arbitrary integer that allows ordering among hooks of the same kind. Using the value 50 is - recommended as neutral default value. ``fn`` is the function that will be - called during execution of the hook. + recommended as neutral default value. + + ``fn(hook)`` is the function that will be called during execution of the + hook. The parameter passed to it (``hook``) is a Lua object that can control + further aspects about the currently invoked hook. It provides the following + methods: + + ``defer()`` + Returning from the hook function should not automatically continue + the hook. Instead, the API user wants to call ``hook:cont()`` on its + own at a later point in time (before or after the function has + returned). + + ``cont()`` + Continue the hook. Doesn't need to be called unless ``defer()`` was + called. See `Hooks`_ for currently existing hooks and what they do - only the hook list is interesting; handling hook execution is done by the Lua script |