RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/libmpv/mpv.def

53 lines
1.0 KiB
Modula-2
Raw Normal View History

command: add a way to abort asynchronous commands Many asynchronous commands are potentially long running operations, such as loading something from network or running a foreign process. Obviously it shouldn't just be possible for them to freeze the player if they don't terminate as expected. Also, there will be situations where you want to explicitly stop some of those operations explicitly. So add an infrastructure for this. Commands have to support this explicitly. The next commit uses this to actually add support to a command.
2018-05-12 16:46:37 +00:00
mpv_abort_async_command
build: list exported symbols explicitly Instead of using a regex to match names to be exported from the libmpv dynamic shared library, use a libmpv.def file, which lists all exported functions explicitly. This reduces the platform specifics in syms.py. I'm not sure if the separate compile_sym task is still needed (it could probably be collapsed, which would concentrate the platform specifics into one place).
2014-08-05 00:21:29 +00:00
mpv_client_api_version
client API: add a per client unique ID I mostly intend this for internal purposes. Probably pretty useless for external API users, but on the other hand trivial to expose. While it makes a lot of sense internally, I'll probably regret exposing it.
2020-03-26 22:39:35 +00:00
mpv_client_id
build: list exported symbols explicitly Instead of using a regex to match names to be exported from the libmpv dynamic shared library, use a libmpv.def file, which lists all exported functions explicitly. This reduces the platform specifics in syms.py. I'm not sure if the separate compile_sym task is still needed (it could probably be collapsed, which would concentrate the platform specifics into one place).
2014-08-05 00:21:29 +00:00
mpv_client_name
mpv_command
mpv_command_async
libmpv/mpv.def: add mpv_command_node[_async]
2014-10-11 04:57:00 +00:00
mpv_command_node
mpv_command_node_async
client API: add mpv_command_ret This change adds a version of `mpv_command` that also returns a result. The main rationale behind this is `mpv_command_node` requires defining multiple structs before you can even use it, which results in a pretty painful to use interface just to get the result from a command. There isn't really a good name for this function, so I'm open to suggestions on a better name for it.
2019-07-14 00:36:34 +00:00
mpv_command_ret
build: list exported symbols explicitly Instead of using a regex to match names to be exported from the libmpv dynamic shared library, use a libmpv.def file, which lists all exported functions explicitly. This reduces the platform specifics in syms.py. I'm not sure if the separate compile_sym task is still needed (it could probably be collapsed, which would concentrate the platform specifics into one place).
2014-08-05 00:21:29 +00:00
mpv_command_string
mpv_create
client API: add function to create new mpv_handles from existing ones This may or may not be useful for client API users. Fold this API extension into the previous API bump. The previous bump was only yesterday, so it's ok.
2014-12-31 19:32:35 +00:00
mpv_create_client
client API: add mpv_create_weak_client()
2018-03-09 05:00:51 +00:00
mpv_create_weak_client
client API: rename mpv_detach_destroy() to mpv_destroy() Since this has clearer semantics now, the old name is just clunky and confusing.
2018-03-09 05:05:50 +00:00
mpv_destroy
build: list exported symbols explicitly Instead of using a regex to match names to be exported from the libmpv dynamic shared library, use a libmpv.def file, which lists all exported functions explicitly. This reduces the platform specifics in syms.py. I'm not sure if the separate compile_sym task is still needed (it could probably be collapsed, which would concentrate the platform specifics into one place).
2014-08-05 00:21:29 +00:00
mpv_error_string
client API, lua, ipc: unify event struct return Both Lua and the JSON IPC code need to convert the mpv_event struct (and everything it points to) to Lua tables or JSON. I was getting sick of having to make the same changes to Lua and IPC. Do what has been done everywhere else, and let the core handle this by going through mpv_node (which is supposed to serve both Lua tables and JSON, and potentially other scripting language backends). Expose it as new libmpv API function. The new API is still a bit "rough" and support for other event types might be added in the future. This silently adds support for the playlist_entry_id fields to both Lua and JSON IPC. There is a small API change for Lua; I don't think this matters, so I didn't care about compatibility. The new code in client.c is mashed up from the Lua and the IPC code. The manpage additions are moved from the Lua docs, and made slightly more "general". Some danger for unintended regressions both in Lua and IPC. Also damn these node functions suck, expect crashes due to UB. Not sure why this became more code instead of less compared to before (according to the diff stat), even though some code duplication across Lua and IPC was removed. Software development sucks.
2020-03-21 18:31:58 +00:00
mpv_event_to_node
build: list exported symbols explicitly Instead of using a regex to match names to be exported from the libmpv dynamic shared library, use a libmpv.def file, which lists all exported functions explicitly. This reduces the platform specifics in syms.py. I'm not sure if the separate compile_sym task is still needed (it could probably be collapsed, which would concentrate the platform specifics into one place).
2014-08-05 00:21:29 +00:00
mpv_event_name
mpv_free
mpv_free_node_contents
mpv_get_property
mpv_get_property_async
mpv_get_property_osd_string
mpv_get_property_string
mpv_get_time_us
mpv_get_wakeup_pipe
client API: add a first class hook API, and deprecate old API As it turns out, there are multiple libmpv users who saw a need to use the hook API. The API is kind of shitty and was never meant to be actually public (it was mostly a hack for the ytdl script). Introduce a proper API and deprecate the old one. The old one will probably continue to work for a few releases, but will be removed eventually. There are some slight changes to the old API, but if a user followed the manual properly, it won't break. Mostly untested. Appears to work with ytdl_hook.
2018-03-23 15:24:49 +00:00
mpv_hook_add
mpv_hook_continue
build: list exported symbols explicitly Instead of using a regex to match names to be exported from the libmpv dynamic shared library, use a libmpv.def file, which lists all exported functions explicitly. This reduces the platform specifics in syms.py. I'm not sure if the separate compile_sym task is still needed (it could probably be collapsed, which would concentrate the platform specifics into one place).
2014-08-05 00:21:29 +00:00
mpv_initialize
mpv_load_config_file
mpv_observe_property
client API: deprecate opengl-cb API and introduce a replacement API The purpose of the new API is to make it useable with other APIs than OpenGL, especially D3D11 and vulkan. In theory it's now possible to support other vo_gpu backends, as well as backends that don't use the vo_gpu code at all. This also aims to get rid of the dumb mpv_get_sub_api() function. The life cycle of the new mpv_render_context is a bit different from mpv_opengl_cb_context, and you explicitly create/destroy the new context, instead of calling init/uninit on an object returned by mpv_get_sub_api(). In other to make the render API generic, it's annoyingly EGL style, and requires you to pass in API-specific objects to generic functions. This is to avoid explicit objects like the internal ra API has, because that sounds more complicated and annoying for an API that's supposed to never change. The opengl_cb API will continue to exist for a bit longer, but internally there are already a few tradeoffs, like reduced thread-safety. Mostly untested. Seems to work fine with mpc-qt.
2018-02-20 12:30:18 +00:00
mpv_render_context_create
mpv_render_context_free
client API: add some render API extensions for timing Attempts to enable the following things: - let a render API user do "proper" audio-sync video timing itself - make it possible to not re-render repeated frames if the API user has better mechanisms available (e.g. waiting for a DisplayLink cycle instead) - allow the user to delay or skip redraws if it makes sense Basically this information will be needed by API users who want to be "clever" about optimizing timing and rendering.
2018-04-20 22:26:58 +00:00
mpv_render_context_get_info
client API: deprecate opengl-cb API and introduce a replacement API The purpose of the new API is to make it useable with other APIs than OpenGL, especially D3D11 and vulkan. In theory it's now possible to support other vo_gpu backends, as well as backends that don't use the vo_gpu code at all. This also aims to get rid of the dumb mpv_get_sub_api() function. The life cycle of the new mpv_render_context is a bit different from mpv_opengl_cb_context, and you explicitly create/destroy the new context, instead of calling init/uninit on an object returned by mpv_get_sub_api(). In other to make the render API generic, it's annoyingly EGL style, and requires you to pass in API-specific objects to generic functions. This is to avoid explicit objects like the internal ra API has, because that sounds more complicated and annoying for an API that's supposed to never change. The opengl_cb API will continue to exist for a bit longer, but internally there are already a few tradeoffs, like reduced thread-safety. Mostly untested. Seems to work fine with mpc-qt.
2018-02-20 12:30:18 +00:00
mpv_render_context_render
mpv_render_context_report_swap
mpv_render_context_set_parameter
mpv_render_context_set_update_callback
client API: preparations for allowing render API to use DR etc. DR (letting the decoder allocate texture memory) requires running the allocation on the render thread. This is rather hard with the render API, because the user controls this thread and when it's entered. It was not possible until now. This commit adds a bunch of infrastructure to make this possible. We add a new optional mode (MPV_RENDER_PARAM_ADVANCED_CONTROL) which basically lets the user's render thread and libmpv agree how this should be done. Misuse would lead to deadlocks. To make this less likely, strictly document thread safety/locking issues. In particular, document which libmpv functions can be called without issues. (The rest has to be assumed unsafe.) The worst issue is destruction of the render context while video is still active. To avoid certain unintended recursive locks (i.e. deadlocks, unless we'd make the locks recursive), make the update callback lock separate. Make "killing" the video chain asynchronous, so we can do extra work while video is being destroyed. Because losing wakeups is a big deal, setting the update callback now triggers a wakeup. (It would have been better if the wakeup callback were a parameter to mpv_render_context_create(), but too late.) This commit does not add DR yet; the following commit does this.
2018-04-20 17:26:04 +00:00
mpv_render_context_update
build: list exported symbols explicitly Instead of using a regex to match names to be exported from the libmpv dynamic shared library, use a libmpv.def file, which lists all exported functions explicitly. This reduces the platform specifics in syms.py. I'm not sure if the separate compile_sym task is still needed (it could probably be collapsed, which would concentrate the platform specifics into one place).
2014-08-05 00:21:29 +00:00
mpv_request_event
mpv_request_log_messages
mpv_set_option
mpv_set_option_string
mpv_set_property
mpv_set_property_async
mpv_set_property_string
mpv_set_wakeup_callback
client API: add stream_cb API for user-defined stream implementations Based on #2630. Some heavy changes by committer. Signed-off-by: wm4 <wm4@nowhere>
2016-08-07 16:10:05 +00:00
mpv_stream_cb_add_ro
build: list exported symbols explicitly Instead of using a regex to match names to be exported from the libmpv dynamic shared library, use a libmpv.def file, which lists all exported functions explicitly. This reduces the platform specifics in syms.py. I'm not sure if the separate compile_sym task is still needed (it could probably be collapsed, which would concentrate the platform specifics into one place).
2014-08-05 00:21:29 +00:00
mpv_terminate_destroy
mpv_unobserve_property
client API: add mpv_wait_async_requests() This does what it's documented to do. The implementation reuses the code in mpv_detach_destroy(). Due to the way async requests currently work, just sending a synchronous dummy request (like a "ignore" command) would be enough to ensure synchronization, but this code will continue to work even if this changes. The line "ctx->event_mask = 0;" is removed, but it shouldn't be needed. (If a client is somehow very slow to terminate, this could silence an annoying queue overflow message, but all in all it does nothing.) Calling mpv_wait_async_requests() and mpv_wait_event() concurrently is in theory allowed, so change pthread_cond_signal() to pthread_cond_broadcast() to avoid missed wakeups. As requested in issue #1542.
2015-02-02 16:24:33 +00:00
mpv_wait_async_requests
build: list exported symbols explicitly Instead of using a regex to match names to be exported from the libmpv dynamic shared library, use a libmpv.def file, which lists all exported functions explicitly. This reduces the platform specifics in syms.py. I'm not sure if the separate compile_sym task is still needed (it could probably be collapsed, which would concentrate the platform specifics into one place).
2014-08-05 00:21:29 +00:00
mpv_wait_event
libmpv: remove opengl_cb API and other deprecated symbols Not all deprecated symbols were removed. Only three events were removed for now since these are not used internally. This bumps the library version to 2.0.
2021-11-29 12:12:02 +00:00
mpv_wakeup