RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-12-26 00:42:57 +00:00
Code Issues Releases Wiki Activity
fb56896319
mpv/libmpv/mpv.def

60 lines
1.2 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
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_detach_destroy
mpv_error_string
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
client API: expose OpenGL renderer This adds API to libmpv that lets host applications use the mpv opengl renderer. This is a more flexible (and possibly more portable) option to foreign window embedding (via --wid). This assumes that methods like context sharing and multithreaded OpenGL rendering are infeasible, and that a way is needed to integrate it with an application that uses a single thread to render everything. Add an example that does this with QtQuick/qml. The example is relatively lazy, but still shows how relatively simple the integration is. The FBO indirection could probably be avoided, but would require more work (and would probably lead to worse QtQuick integration, because it would have to ignore transformations like rotation). Because this makes mpv directly use the host application's OpenGL context, there is no platform specific code involved in mpv, except for hw decoding interop. main.qml is derived from some Qt example. The following things are still missing: - a way to do better video timing - expose GL renderer options, allow changing them at runtime - support for color equalizer controls - support for screenshots
2014-12-09 16:47:02 +00:00
mpv_get_sub_api
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_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
vo_opengl_cb: deprecate mpv_opengl_cb_render() Its vp parameter made no sense anymore. Introduce a new one.
2015-04-09 17:31:01 +00:00
mpv_opengl_cb_draw
client API: expose OpenGL renderer This adds API to libmpv that lets host applications use the mpv opengl renderer. This is a more flexible (and possibly more portable) option to foreign window embedding (via --wid). This assumes that methods like context sharing and multithreaded OpenGL rendering are infeasible, and that a way is needed to integrate it with an application that uses a single thread to render everything. Add an example that does this with QtQuick/qml. The example is relatively lazy, but still shows how relatively simple the integration is. The FBO indirection could probably be avoided, but would require more work (and would probably lead to worse QtQuick integration, because it would have to ignore transformations like rotation). Because this makes mpv directly use the host application's OpenGL context, there is no platform specific code involved in mpv, except for hw decoding interop. main.qml is derived from some Qt example. The following things are still missing: - a way to do better video timing - expose GL renderer options, allow changing them at runtime - support for color equalizer controls - support for screenshots
2014-12-09 16:47:02 +00:00
mpv_opengl_cb_init_gl
vo_opengl_cb: add a function to report vsync time And also let vo.c know of it. Currently, this does not help much, but will facilitate future improvements.
2015-04-09 17:30:26 +00:00
mpv_opengl_cb_report_flip
client API: expose OpenGL renderer This adds API to libmpv that lets host applications use the mpv opengl renderer. This is a more flexible (and possibly more portable) option to foreign window embedding (via --wid). This assumes that methods like context sharing and multithreaded OpenGL rendering are infeasible, and that a way is needed to integrate it with an application that uses a single thread to render everything. Add an example that does this with QtQuick/qml. The example is relatively lazy, but still shows how relatively simple the integration is. The FBO indirection could probably be avoided, but would require more work (and would probably lead to worse QtQuick integration, because it would have to ignore transformations like rotation). Because this makes mpv directly use the host application's OpenGL context, there is no platform specific code involved in mpv, except for hw decoding interop. main.qml is derived from some Qt example. The following things are still missing: - a way to do better video timing - expose GL renderer options, allow changing them at runtime - support for color equalizer controls - support for screenshots
2014-12-09 16:47:02 +00:00
mpv_opengl_cb_render
mpv_opengl_cb_set_update_callback
mpv_opengl_cb_uninit_gl
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_resume
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_suspend
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
client API: expose OpenGL renderer This adds API to libmpv that lets host applications use the mpv opengl renderer. This is a more flexible (and possibly more portable) option to foreign window embedding (via --wid). This assumes that methods like context sharing and multithreaded OpenGL rendering are infeasible, and that a way is needed to integrate it with an application that uses a single thread to render everything. Add an example that does this with QtQuick/qml. The example is relatively lazy, but still shows how relatively simple the integration is. The FBO indirection could probably be avoided, but would require more work (and would probably lead to worse QtQuick integration, because it would have to ignore transformations like rotation). Because this makes mpv directly use the host application's OpenGL context, there is no platform specific code involved in mpv, except for hw decoding interop. main.qml is derived from some Qt example. The following things are still missing: - a way to do better video timing - expose GL renderer options, allow changing them at runtime - support for color equalizer controls - support for screenshots
2014-12-09 16:47:02 +00:00
mpv_wakeup
Reference in New Issue Copy Permalink