aboutsummaryrefslogtreecommitdiffhomepage
path: root/player/client.c
Commit message (Collapse)AuthorAge
* client API: change mpv_create() behavior, run init always on mpv threadGravatar wm42017-06-30
| | | | | | This takes car eof unsubtle bugs if something at init does not work (specifically if mp_new_client() returns NULL). It also removes the need for that PMP MF hack.
* Fix use of ISC licenseGravatar wm42017-04-15
| | | | | | | | | | The license text refers a "above copyright notice", so I guess it'd be good to actually provide such a notice. Add the license to some files that were missing it (since in theory, our Copyright file says that such files are LGPL by default). Remove the questionable remarks about the license in the client API.
* client: call certain external functions outside of client lockGravatar wm42017-02-24
| | | | | | | | | Fixes theoretical lock-order issues found by Coverity. Calling these inside the log is unnecessary anyway, because they have their own locking, and because mpv_detach_destroy() needs to be called by someone who has exclusive access to the mpv_handle (it's basically a destructor function). The lock order issues comes from the fact that they call back into the client API implementation to broadcast events and such.
* player: restructure cancel callbackGravatar wm42017-01-18
| | | | | | | | | | | | As preparation for file prefetching, we basically have to get rid of using mpctx->playback_abort for the main demuxer (i.e. the thing that can be prefetched). It can't be changed on a running demuxer, and always using the same cancel handle would either mean aborting playback would also abort prefetching, or that playback can't be aborted anymore. Make this more flexible with some refactoring. Thi is a quite shitty solution if you ask me, but YOLO.
* scripting: minor logging improvementsGravatar wm42017-01-14
| | | | | | | | Give scripting backends a proper name, instead of calling everything "scripts". Log client exit directly in client.c, as that is more general (doesn't change actual output).
* client API: fix freeze when destroying mpv_handle before mpv_initializeGravatar wm42017-01-12
| | | | | | | | | We have to perform some silly acrobatics to make the playback_thread() exit, as the mpv_command() will error out with MPV_ERROR_UNINITIALIZED. Test case: mpv_terminate_destroy(mpv_create()) Reported by a user on IRC.
* client API: handle missing MPV_FORMAT_BYTE_ARRAY case in compare_valueGravatar wm42017-01-09
| | | | | | Since there's no property yet that uses this type, and the code is used for property change detection only. this is dead code. Add it anyway for completeness.
* client API: fix mpv_set_property() return value before initGravatar wm42017-01-04
| | | | | | Did not return success as success. Fixes #3988.
* client API: turn mpv_suspend() and mpv_resume() into stubsGravatar wm42016-11-22
| | | | | | | | | | | As threatened by the API changes document. This commit also removes or stubs equivalent calls in IPC and Lua scripting. The stubs are left to maintain ABI compatibility. The semantics of the API functions have been close enough to doing nothing that this probably won't even break existing API users. Probably.
* client API: more or less deprecate mpv_set_option()Gravatar wm42016-09-21
| | | | | | | | | | | | | | | | | | | | | | With the merging of options and properties, the mpv_set_option() function is close to being useless, and mpv_set_property() can be used for everything instead. There are certain conflicts remaining, which are explained in depth in the docs. For now, none of this should affect existing code using the client API. Make mpv_set_property() redirect to mpv_set_option() before initialization. Remove some options marked as M_OPT_FIXED. The "pause" and "speed" options cannot be written anymore without the playloop being notified by it, so the M_OPT_FIXED does nothing. For "vo-mmcss-profile", the problem was lack of synchronization, which has been added. I'm not sure what the problem was with "frames" - I think it was only marked as M_OPT_FIXED because changing it during playback will have no effect. Except for pause/speed, these changes are needed to make them writable as properties after mpv_initialize(). Also replace all remaining uses of CONF_GLOBAL with M_OPT_FIXED.
* client API: fix init/destruction race conditionsGravatar wm42016-09-21
| | | | | | | | | | 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.
* client API: revert unintended mpv_wait_event() behavior changeGravatar wm42016-09-21
| | | | | Commit bf385e11 accidentally added some testing changes that were not intended to be committed.
* player: kill associated OSD and key bindings when removing a scriptGravatar wm42016-09-20
| | | | | The former was done already for Lua scripts, but move it to the generic code.
* client API: revert some relaxations about calling mpv_initialize()Gravatar wm42016-09-19
| | | | | | | | | | | | | | | | | | | | | | My original idea was making mpv_initialize() a no-op, but it seems this can't happen after all. The problem is especially with subtle interactions in option parsing (basically all pre-parse options). Instead, I might go into the opposite direction, and add a new API function that takes over the role of mpv_create+mpv_initialize, and which will take a list of options. This list will be for the purpose of setting options that can be set only at initialization time (such as config-dir). This would also make it more uniform with the command- line player initialization. Maybe. In any case, for now revert parts of commit 453fea87 to remove the initialization-related freedoms it added. Fortunately, this wasn't released yet, so we remove it from the API as if it never happened. (The rest of that commit is still fine, just not the additional freedom.)
* player: use better way to wait for input and dispatching commandsGravatar wm42016-09-16
| | | | | | | | | | | | | | | | | | | Instead of using input_ctx for waiting, use the dispatch queue directly. One big change is that the dispatch queue will just process commands that come in (e.g. from client API) without returning. This should reduce unnecessary playloop excutions (which is good since the playloop got a bit fat from rechecking a lot of conditions every iteration). Since this doesn't force a new playloop iteration on every access, this has to be enforced manually in some cases. Normal input (via terminal or VO window) still wakes up the playloop every time, though that's not too important. It makes testing this harder, though. If there are missing wakeup calls, it will be noticed only when using the client API in some form. At this point we could probably use a normal lock instead of the dispatch queue stuff.
* client API: declare mpv_suspend/mpv_resume deprecatedGravatar wm42016-09-16
| | | | | | | They're useless, and I have no idea what they're actually supposed to do (wrt. pending input processing changes). Also remove their implicit uses from the IPC handlers.
* player, ao, vo: don't call mp_input_wakeup() directlyGravatar wm42016-09-16
| | | | | | | | | | | | | Currently, calling mp_input_wakeup() will wake up the core thread (also called the playloop). This seems odd, but currently the core indeed calls mp_input_wait() when it has nothing more to do. It's done this way because MPlayer used input_ctx as central "mainloop". This is probably going to change. Remove direct calls to this function, and replace it with mp_wakeup_core() calls. ao and vo are changed to use opaque callbacks and not use input_ctx for this purpose. Other code already uses opaque callbacks, or has legitimate reasons to use input_ctx directly (such as sending actual user input).
* client API: don't miss property changes after updatesGravatar James Ross-Gowan2016-09-11
| | | | | | | | | | | | | | | | | | When update_prop() successfully fetches a changed property value, it sets prop->changed to true. mark_property_changed() only sets prop->need_new_value if prop->changed is false, so this had the effect of ignoring new property values until prop->changed was set back to false in the next call to gen_property_change_event(). This meant that when a property change event was generated for a property that was not observed with MPV_FORMAT_NONE, it would contain the value associated with the earliest property change, rather than the most recent, and the property change event for the most recent change would never be generated. To fix this, mark_property_changed() should unconditionally set prop->changed and prop->need_new_value, which will cause the property value to be re-fetched and a property change event to be generated for the most recent value.
* client API: fix error code stringGravatar wm42016-09-09
| | | | Said "audio" instead of "video".
* client API: make mpv_opengl_cb_uninit_gl() behavior slightly nicerGravatar wm42016-09-09
| | | | | | Instead of deselecting the video stream plainly, use the slightly more robust error_on_track() function. Also give it an error code (although I'm not sure if this one is confusing, it's better than the one before).
* client API: implement mpv_suspend/resume slightly differentlyGravatar wm42016-09-04
| | | | | | | | Why do these API calls even still exist? I don't know, and maybe they don't make any sense anymore. But whether they should be removed or not is not a decision I want to make now. I want to get rid of mp_dispatch_suspend/resume(), though. So implement the client APIs slightly differently.
* client API: create core thread at an earlier timeGravatar wm42016-09-01
| | | | | | | | | | | | | Create the core thread right in mpv_create(), and reduce what mpv_initialize() does further. This is simpler, and allows the API user to do more before calling mpv_initialize(). The latter is not the real goal, rather we'd like mpv_intialize() reduced to do almost nothing. It still does a lot, but nothing truly special anymore that is absolutely required for basic mpv workings. One thing we want the user to be able to do is changing properties before mpv_initialize() to reduce the special status of mpv_set_option().
* command: add options to property listGravatar wm42016-09-01
| | | | | | | | | | | Now options are accessible through the property list as well, which unifies them to a degree. Not all options support runtime changes (meaning affected components need to be restarted for the options to take effects). Remove from the manpage those properties which are cleanly mapped to options anyway. From the user-perspective they're just options available through the property interface.
* client API: add stream_cb API for user-defined stream implementationsGravatar Aman Gupta2016-08-07
| | | | | | Based on #2630. Some heavy changes by committer. Signed-off-by: wm4 <wm4@nowhere>
* client API: add MPV_ERROR_GENERICGravatar wm42016-08-07
| | | | Because why not.
* build: silence -Wunused-resultGravatar Niklas Haas2016-06-07
| | | | | | | | For clang, it's enough to just put (void) around usages we are intentionally ignoring the result of. Since GCC does not seem to want to respect this decision, we are forced to disable the warning globally.
* command: log property set callsGravatar wm42016-04-15
| | | | | | | And remove the same thing from the client API code. The command.c code has to deal with many specialized M_PROPERTY_SET_* actions, and we bother with a subset only.
* client API: improve mpv_set_property() handling of MPV_FORMAT_NODEGravatar wm42016-04-15
| | | | | | | | | If a mpv_node wrapped a string, the behavior was different from calling mpv_set_property() with MPV_FORMAT_STRING directly. Change this. The original intention was to be strict about types if MPV_FORMAT_NODE is used. But I think the result was less than ideal, and the same change towards less strict behavior was made to mpv_set_option() ages ago.
* client API: handle double->int64 conversion correctlyGravatar wm42016-02-13
| | | | It signalled failure instead.
* player: assume setlocale() returns NULL if locales are not supportedGravatar wm42016-02-10
| | | | | | | | It would make somewhat sense for libcs which don't implement locales at all, such as Bionic. Beyond that, setlocale() is specified that it can return NULL, and we shouldn't crash if that happens.
* global: add client API pointer to library handleGravatar wm42016-01-15
| | | | | | | 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.
* client API: disallow masking MPV_EVENT_SHUTDOWNGravatar wm42015-12-02
| | | | | | | | | This makes no sense, because the client is obligated to react to this event. This also happens to fix a deadlock with JSON IPC clients sending "disable_event all", because MPV_EVENT_SHUTDOWN was used to stop the thread driving the socket connection (fixes #2558).
* client API: change error string if playback fails completelyGravatar wm42015-10-26
| | | | | It can print this if AO/VO initialization fails, which makes the wording a lie. Change it to something more diplomatically safe.
* client API: improve an error messageGravatar wm42015-08-28
| | | | | This refers to media played by mpv, and these don't necessarily have to be files. They can be network resources or entirely abstract URLs too.
* client API: fix mpv_get_property_async() string caseGravatar wm42015-07-10
| | | | | | | The logic for this code didn't survive the previous refactor. It always crashed in async mode. Fixes #2121.
* client API: allow using msg-level option for log messagesGravatar wm42015-06-20
| | | | | | | | | | | | | | | | Client API users can enable log output with mpv_request_log_messages(). But you can enable only a single log level. This is normally enough, but the --msg-level option (which controls the terminal log level) provides more flexibility. Due to internal complexity, it would be hard to provide the same flexibility for each client API handle. But there's a simple way to achieve basically the same thing: add an option that sends log messages to the API handle, which would also be printed to the terminal as by --msg-level. The only change is that we don't disable this logic if the terminal is disabled. Instead we check for this before the message is output, which in theory can lower performance if messages are being spammed. It could be handled with some more effort, but the gain would be negligible.
* client API: fix logging memory leakGravatar wm42015-06-18
| | | | | | Very stupid. Was pointed out in #2056.
* player: fix crashes when adding external tracks before loading main fileGravatar wm42015-05-26
| | | | | | | | | | | | | | | | Adding an external audio track before loading the main file didn't work right. For one, mp_switch_track() assumes it is called after the main file is loaded. (The difference is that decoders are only initialized once the main file is loaded, and we avoid doing this before that for whatever reason.) To avoid further messiness, just allow mp_switch_track() to be called at any time. Also make it do what mp_mark_user_track_selection() did, since the latter requires current_track to be set. (One could probably simply allow current_track to be set at this point, but it'd interfere with default track selection anyway and thus would be pointless.) Fixes #1984.
* threads: use utility+POSIX functions instead of weird wrappersGravatar wm42015-05-11
| | | | | | | There is not much of a reason to have these wrappers around. Use POSIX standard functions directly, and use a separate utility function to take care of the timespec calculations. (Course POSIX for using this weird format for time values.)
* player: use profiles for libmpv and encoding defaultsGravatar wm42015-05-07
| | | | | | | | The client API (libmpv) and encoding (--o) have slightly different defaults from the command line player. Instead of doing a bunch of calls to set the options explicitly, use profiles. This is simpler and has the advantage that they can be listed on command line (instead of possibly forcing the user to find and read the code to know all the details).
* client API: add glue for making full use of mpv_command_node()Gravatar wm42015-04-20
| | | | | Until now, the return value was always MPV_FORMAT_NONE. Now a command can actually set it. This will be used in one of the following commits.
* vo_opengl_cb: deprecate mpv_opengl_cb_render()Gravatar wm42015-04-09
| | | | Its vp parameter made no sense anymore. Introduce a new one.
* vo_opengl_cb: add a function to report vsync timeGravatar wm42015-04-09
| | | | | | | And also let vo.c know of it. Currently, this does not help much, but will facilitate future improvements.
* client API: remove dead assignmentGravatar wm42015-03-23
| | | | | Probably a leftover from an earlier refactoring. Now data is always in the format MPV_FORMAT_NODE.
* vo_opengl_cb: don't render OSD while VO is not createdGravatar wm42015-03-23
| | | | | | | | | | | Unlike other VOs, this rendered OSD even while no VO was created (because the renderer lives as long as the API user wants). Change this, and refactor the code so that the OSD object is accessible only while the VO is created. (There is a short time where the OSD can still be accessed even after VO destruction - this is not a race condition, though it's inelegant and unfortunately unavoidable.)
* player, client API: refactor cplayer init, reduce client API differencesGravatar wm42015-03-05
| | | | | | | | | | | | | Move the command line parsing and some other things to the common init routine shared between command line player and client API. This means they're using almost exactly the same code now. The main intended side effect is that the client API will load mpv.conf; though still only if config loading is enabled. (The cplayer still avoids creating an extra thread, passes a command line, and prints an exit status to the terminal. It also has some different defaults.)
* client API: add mpv_wait_async_requests()Gravatar wm42015-02-02
| | | | | | | | | | | | | | | | | | | | 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.
* client API: check locale, and reject anything other than "C" localeGravatar wm42015-01-20
| | | | | | | | | | | | | | | Sigh... The C locale system is incredibly shitty, and if used, breaks basic string functions. The locale can change the decimal mark from "." to ",", which affects conversion between floats and strings: snprintf() and strtod() respect the locale decimal mark, and change behavior. (What's even better, the behavior of these functions can change asynchronously, if setlocale() is called after threads were started.) So just check the locale in the client API, and refuse to work if it's wrong. This also makes the lib print to stderr, which I consider the lesser evil in this specific situation.
* client API: minor cleanupGravatar wm42015-01-19
| | | | | Try not to put "everything" into mpv_wait_event: move out the code for generating log message events.
* client API: notify API user on event queue overflowGravatar wm42015-01-19
| | | | | | | | | | | | | | | Before this, we merely printed a message to the terminal. Now the API user can determine this properly. This might be important for API users which somehow maintain complex state, which all has to be invalidated if (state-changing) events are missing due to an overflow. This also forces the client API user to empty the event queue, which is good, because otherwise the event queue would reach the "filled up" state immediately again due to further asynchronous events being added to the queue. Also add some minor improvements to mpv_wait_event() documentation, and some other minor cosmetic changes.