summaryrefslogtreecommitdiffstats
path: root/player/client.c
Commit message (Collapse)AuthorAgeFilesLines
* client: remove legacy API that is unused nowAkemi2018-03-041-33/+1
| | | | | | this API was introduced in c5e4538 solely for the use with cocoa-cb and was not public. with the port to the new API in 760d471 it is now unused and can safely be removed.
* client API: deprecate opengl-cb API and introduce a replacement APIwm42018-02-281-21/+143
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* cocoa-cb: initial implementation via opengl-cb APIAkemi2018-02-121-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* client: Allow "C.UTF-8" as LC_NUMERIC localesfan52017-11-301-1/+1
| | | | | This is required on newer Android NDKs, as setting LC_NUMERIC to "C" will still return "C.UTF-8" if you query it.
* client API: change mpv_create() behavior, run init always on mpv threadwm42017-06-301-16/+24
| | | | | | 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 licensewm42017-04-151-1/+3
| | | | | | | | | | 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 lockwm42017-02-241-2/+3
| | | | | | | | | 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 callbackwm42017-01-181-1/+1
| | | | | | | | | | | | 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 improvementswm42017-01-141-0/+2
| | | | | | | | 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_initializewm42017-01-121-1/+7
| | | | | | | | | 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_valuewm42017-01-091-0/+6
| | | | | | 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 initwm42017-01-041-0/+1
| | | | | | Did not return success as success. Fixes #3988.
* client API: turn mpv_suspend() and mpv_resume() into stubswm42016-11-221-51/+1
| | | | | | | | | | | 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()wm42016-09-211-2/+11
| | | | | | | | | | | | | | | | | | | | | | 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 conditionswm42016-09-211-4/+14
| | | | | | | | | | 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 changewm42016-09-211-3/+0
| | | | | Commit bf385e11 accidentally added some testing changes that were not intended to be committed.
* player: kill associated OSD and key bindings when removing a scriptwm42016-09-201-0/+5
| | | | | The former was done already for Lua scripts, but move it to the generic code.
* client API: revert some relaxations about calling mpv_initialize()wm42016-09-191-0/+16
| | | | | | | | | | | | | | | | | | | | | | 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 commandswm42016-09-161-0/+1
| | | | | | | | | | | | | | | | | | | 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 deprecatedwm42016-09-161-0/+2
| | | | | | | 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() directlywm42016-09-161-4/+3
| | | | | | | | | | | | | 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 updatesJames Ross-Gowan2016-09-111-5/+3
| | | | | | | | | | | | | | | | | | 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 stringwm42016-09-091-1/+1
| | | | Said "audio" instead of "video".
* client API: make mpv_opengl_cb_uninit_gl() behavior slightly nicerwm42016-09-091-1/+5
| | | | | | 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 differentlywm42016-09-041-6/+15
| | | | | | | | 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 timewm42016-09-011-43/+37
| | | | | | | | | | | | | 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 listwm42016-09-011-2/+2
| | | | | | | | | | | 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 implementationsAman Gupta2016-08-071-0/+61
| | | | | | Based on #2630. Some heavy changes by committer. Signed-off-by: wm4 <wm4@nowhere>
* client API: add MPV_ERROR_GENERICwm42016-08-071-0/+1
| | | | Because why not.
* build: silence -Wunused-resultNiklas Haas2016-06-071-2/+2
| | | | | | | | 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 callswm42016-04-151-8/+0
| | | | | | | 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_NODEwm42016-04-151-34/+18
| | | | | | | | | 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 correctlywm42016-02-131-1/+3
| | | | It signalled failure instead.
* player: assume setlocale() returns NULL if locales are not supportedwm42016-02-101-1/+1
| | | | | | | | 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 handlewm42016-01-151-0/+7
| | | | | | | 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_SHUTDOWNwm42015-12-021-0/+2
| | | | | | | | | 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 completelywm42015-10-261-1/+1
| | | | | 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 messagewm42015-08-281-1/+1
| | | | | 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 casewm42015-07-101-1/+1
| | | | | | | 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 messageswm42015-06-201-0/+3
| | | | | | | | | | | | | | | | 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 leakwm42015-06-181-0/+1
| | | | | | Very stupid. Was pointed out in #2056.
* player: fix crashes when adding external tracks before loading main filewm42015-05-261-1/+1
| | | | | | | | | | | | | | | | 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 wrapperswm42015-05-111-2/+4
| | | | | | | 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 defaultswm42015-05-071-14/+1
| | | | | | | | 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()wm42015-04-201-6/+9
| | | | | 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()wm42015-04-091-1/+6
| | | | Its vp parameter made no sense anymore. Introduce a new one.
* vo_opengl_cb: add a function to report vsync timewm42015-04-091-0/+4
| | | | | | | And also let vo.c know of it. Currently, this does not help much, but will facilitate future improvements.
* client API: remove dead assignmentwm42015-03-231-1/+0
| | | | | 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 createdwm42015-03-231-1/+1
| | | | | | | | | | | 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 differenceswm42015-03-051-3/+1
| | | | | | | | | | | | | 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()wm42015-02-021-8/+12
| | | | | | | | | | | | | | | | | | | | 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" localewm42015-01-201-0/+16
| | | | | | | | | | |