RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-12-25 16:33:02 +00:00
Code Issues Releases Wiki Activity
c5e4538bc4
mpv/player/client.h

63 lines
2.4 KiB
C
Raw Normal View History

Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
#ifndef MP_CLIENT_H_
#define MP_CLIENT_H_
#include <stdint.h>
lua: strictly free memory on errors Thanks to the recently introduced mp_lua_PITA(), this is "simple" now. It fixes leaks on Lua errors. The hack to avoid stack overflows manually isn't needed anymore, and the Lua error handler will take care of this.
2014-10-19 03:46:16 +00:00
#include <stdbool.h>
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
#include "libmpv/client.h"
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
#include "libmpv/stream_cb.h"
cocoa-cb: initial implementation via opengl-cb API this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
2018-02-12 11:28:19 +00:00
#include "misc/bstr.h"
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
struct MPContext;
struct mpv_handle;
struct mp_client_api;
struct mp_log;
client API: restrict client names Use a fixed size array for the client name, which also limits the client name in size. Sanitize the client name string, and replace characters that are not in [A-Za-z0-9] with '_'.
2014-11-23 12:40:52 +00:00
// Includes space for \0
#define MAX_CLIENT_NAME 64
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
void mp_clients_init(struct MPContext *mpctx);
client API: fix init/destruction race conditions mp_new_client() blatantly accessed some mutex-protected state outside of the mutex. The destruction code is in theory OK, but with changes in the following commits it'll be a bit hard to guarantee that it stays this way. Add a simple flag that makes adding new clients impossible, so that having no clients after shutdown_clients() remains guaranteed.
2016-09-21 13:55:34 +00:00
void mp_client_enter_shutdown(struct MPContext *mpctx);
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
void mp_clients_destroy(struct MPContext *mpctx);
int mp_clients_num(struct MPContext *mpctx);
lua: synchronously wait until scripts are loaded This makes the player wait until each script is loaded. Do this to give the script a chance to setup all its event handlers. It might also be useful to allow a script to change options that matter for playback. While waiting for a script to be loaded, the player actually accepts input. This is needed because the scripts can execute player commands anyway while they are being "loaded". The player won't react to most commands though: it can't quit or navigate the playlist in this state. For deciding whether a script is finally loaded, we use a cheap hack: if mpv_wait_event() is called, it's considered loaded. Let's hope this is good enough. I think it's better than introducing explicit API for this. Although I'm sure this will turn out as too simplistic some time in the future, the same would probably happen with a more explicit API.
2014-09-06 15:02:47 +00:00
bool mp_clients_all_initialized(struct MPContext *mpctx);
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
command: finish hook execution if client fails Translation: if the (to be added) youtube-dl Lua script crashes, don't wait forever when opening something.
2014-10-24 19:52:16 +00:00
bool mp_client_exists(struct MPContext *mpctx, const char *client_name);
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
void mp_client_broadcast_event(struct MPContext *mpctx, int event, void *data);
int mp_client_send_event(struct MPContext *mpctx, const char *client_name,
int event, void *data);
input, lua: redo input handling Much of it is the same, but now there's the possibility to distinguish key down/up events in the Lua API.
2014-11-23 14:08:49 +00:00
int mp_client_send_event_dup(struct MPContext *mpctx, const char *client_name,
int event, void *data);
player: update cache state only if requested Add a mechanism to the client API code, which allows the player core to query whether a client API event is needed at all. Use it for the cache update. In this case, this is probably a pure microoptimization; but the mechanism will be useful for other things too.
2014-08-28 15:35:50 +00:00
bool mp_client_event_is_registered(struct MPContext *mpctx, int event);
client API: minor optimizations for property notification Internally, there are two mechanisms which can trigger property notification as used with "observed" properties in the client API. The first mechanism associates events with a group of properties that are potentially changed by a certain event. mp_event_property_change[] declares these associations, and maps each event to a set of strings. When an event happens, the set of strings is matched against the list of observed properties of each client. Make this more efficient by comparing bitsets of events instead. This way, only a bit-wise "and" is needed for each observed property. Even better, we can completely skip clients which have no observed properties that match. The second mechanism just updates individual properties explicitly by name. Optimize this by using the property index instead. It would be nice if we could reuse the first mechanism for the second one, but there are too many properties to fit into a 64 bit mask. (Though the limit on 64 events might get us into trouble later...)
2014-08-01 23:39:28 +00:00
void mp_client_property_change(struct MPContext *mpctx, const char *name);
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
struct mpv_handle *mp_new_client(struct mp_client_api *clients, const char *name);
struct mp_log *mp_client_get_log(struct mpv_handle *ctx);
player: reorganize how lua scripts are loaded Make loading of scripts independent of Lua. Move some of the loading code from lua.c to scripting.c, and make it easier to add new scripting backends.
2014-05-12 23:14:07 +00:00
struct MPContext *mp_client_get_core(struct mpv_handle *ctx);
global: add client API pointer to library handle Makes the next commit simpler. It's probably a bad idea to add more fields to the global state, but on the other hand the client API state is pretty much per-instance anyway. It also will help with things like the proposed libmpv custom stream API.
2016-01-15 21:49:10 +00:00
struct MPContext *mp_client_api_get_core(struct mp_client_api *api);
cocoa-cb: initial implementation via opengl-cb API this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
2018-02-12 11:28:19 +00:00
void *mp_get_sub_api2(mpv_handle *ctx, mpv_sub_api sub_api, bool lock);
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
lua: strictly free memory on errors Thanks to the recently introduced mp_lua_PITA(), this is "simple" now. It fixes leaks on Lua errors. The hack to avoid stack overflows manually isn't needed anymore, and the Lua error handler will take care of this.
2014-10-19 03:46:16 +00:00
// m_option.c
void *node_get_alloc(struct mpv_node *node);
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
// vo_opengl_cb.c
struct mpv_opengl_cb_context;
struct mpv_global;
struct osd_state;
struct mpv_opengl_cb_context *mp_opengl_create(struct mpv_global *g,
vo_opengl_cb: simplify API uninitialization Until now, calling mpv_opengl_cb_uninit_gl() at a "bad moment" could make the whole thing to explode. The API user was asked to avoid such situations by calling it only in "good moments". But this was probably a bit too subtle and could easily be overlooked. Integrate the approach the qml example uses directly into the implementation. If the OpenGL context is to be unitialized, forcefully disable video, and block until this is done.
2014-12-31 19:31:19 +00:00
struct mp_client_api *client_api);
void kill_video(struct mp_client_api *client_api);
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
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
bool mp_streamcb_lookup(struct mpv_global *g, const char *protocol,
void **out_user_data, mpv_stream_cb_open_ro_fn *out_fn);
cocoa-cb: initial implementation via opengl-cb API this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
2018-02-12 11:28:19 +00:00
typedef int (*mpv_opengl_cb_control_fn)(void *cb_ctx, int *events, uint32_t request, void *data);
void mp_client_set_control_callback(struct mpv_opengl_cb_context *ctx,
mpv_opengl_cb_control_fn callback,
void *callback_ctx);
void mp_client_set_icc_profile(struct mpv_opengl_cb_context *ctx, bstr icc_data);
void mp_client_set_ambient_lux(struct mpv_opengl_cb_context *ctx, int lux);
Add a client API Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
2014-02-10 20:01:35 +00:00
#endif
Reference in New Issue Copy Permalink