RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-12-17 20:34:58 +00:00
Code Issues Releases Wiki Activity
c4f39d2aba
mpv/player/client.h

50 lines
1.6 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"
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);
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);
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
client API: be more lenient about mpv_suspend/resume mismatches Before this commit, this was defined to trigger undefined behavior. This was nice because it required less code; but on the other hand, Lua as well as IPC support had to check these things manually. Do it directly in the API to avoid code duplication, and to make the API more robust. (The total code size still grows, though...) Since all of the failure cases were originally meant to ruin things forever, there is no way to return error codes. So just print the errors.
2014-12-15 13:44:25 +00:00
void mp_resume_all(struct mpv_handle *ctx);
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 osd_state *osd,
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
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