summaryrefslogtreecommitdiffstats
path: root/player/client.c
Commit message (Collapse)AuthorAgeFilesLines
* client API: allow multiple mpv instances with terminal=yeswm42014-12-021-0/+1
| | | | | | | | | | | | | | | This is simply not allowed, and doing it triggered an assertion. It's still not allowed, because the terminal and related functionality is a global resource, and there doesn't seem to be a sane way to manage the signal handlers. But be a bit nicer, and just the terminal if it's already in use. Note that terminal _output_ happens anyway. This becomes usable with this commit. To facilitate logging-only usage further, also explicitly disable terminal input, so that "terminal=yes" can be used for logging without much interference with other things. (It'll still overwrite some signal handlers, though.)
* client API: print version on initializationwm42014-12-021-0/+2
| | | | | A rather big oversight, because a log produced with the client API will not contain the mpv version at all otherwise.
* client API: make sure youtube-dl is not used by defaultwm42014-11-251-0/+1
| | | | | | | Currently, --ytdl is off by default, but even if this is changed, never enable it by default for the client API. It would be inappropriate to start an intrusive external subprocess behind the host application's back.
* input, lua: redo input handlingwm42014-11-231-0/+24
| | | | | Much of it is the same, but now there's the possibility to distinguish key down/up events in the Lua API.
* client API: restrict client nameswm42014-11-231-20/+19
| | | | | | 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 '_'.
* client: remove redundant assignmentwm42014-11-071-1/+0
| | | | This is set by send_reply().
* client API: silence silly clang warningwm42014-11-071-2/+2
| | | | | | | The values compared here happen to be of unsigned enum types - but the test is not supposed to break if we somehow force the enum to signed, or if the compiler happens to use a signed type (as far as I remember, the exact integer type the compiler can use is implementation-defined).
* command: make window-scale property observablewm42014-11-021-1/+1
| | | | | | | | | | | | Add a generic mechanism to the VO to relay "extra" events from VO to player. Use it to notify the core of window resizes, which in turn will be used to mark all affected properties ("window-scale" in this case) as changed. (I refrained from hacking this as internal command into input_ctx, or to poll the state change, etc. - but in the end, maybe it would be best to actually pass the client API context directly to the places where events can happen.)
* player: add an option to abort playback on partial init failureswm42014-10-281-0/+1
| | | | | | This is probably what libmpv users want; and it also improves error reporting (or we'd have to add a way to communicate such mid-playback failures as events).
* client API: better error reportingwm42014-10-281-0/+5
| | | | Give somewhat more information on playback failure.
* command: finish hook execution if client failswm42014-10-241-1/+10
| | | | | Translation: if the (to be added) youtube-dl Lua script crashes, don't wait forever when opening something.
* client API: print properties set with -vwm42014-10-231-0/+7
| | | | | Useful for debugging. Considered doing this in command.c, but it's easier here.
* Set thread name for debuggingwm42014-10-191-0/+2
| | | | | | | | | | Especially with other components (libavcodec, OSX stuff), the thread list can get quite populated. Setting the thread name helps when debugging. Since this is not portable, we check the OS variants in waf configure. old-configure just gets a special-case for glibc, since doing a full check here would probably be a waste of effort.
* command: add a mechanism to allow scripts to intercept file loadswm42014-10-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | A vague idea to get something similar what libquvi did. Undocumented because it might change a lot, or even be removed. To give an idea what it does, a Lua script could do the following: -- type ID priority mp.commandv("hook_add", "on_load", 0, 0) mp.register_script_message("hook_run", function(param, param2) -- param is "0", the user-chosen ID from the hook_add command -- param2 is the magic value that has to be passed to finish -- the hook mp.resume_all() -- do something, maybe set options that are reset on end: mp.set_property("file-local-options/name", "value") -- or change the URL that's being opened: local url = mp.get_property("stream-open-filename") mp.set_property("stream-open-filename", url .. ".png") -- let the player (or the next script) continue mp.commandv("hook_ack", param2) end)
* client API: allow returning float properties as integerswm42014-10-141-0/+4
| | | | | I'm starting to think that being type-strict with this interface actually sucks. This commit is a step towards being less strict.
* client API: check result ptr in mpv_command_nodeJames Ross-Gowan2014-10-121-1/+1
| | | | This follows the docs, which say the result parameter is optional.
* client API: add mpv_command_node[_async]wm42014-10-111-3/+19
| | | | | | | | | Allows passing native types as arguments. Also some minor doc improvements, including giving some (natural) improvements to mpv_free_node_contents(). Note: mpv_command_node_async() is completely untested.
* input: use mpv_node parser for char** command parserswm42014-10-101-3/+2
| | | | Minor simplification, also drops some useless stuff.
* libmpv/cocoa: don't start the event monitorStefano Pigozzi2014-10-091-1/+2
| | | | | | The event monitor is used to get keyboard events when there is no window, but since it is a global monitor to the current process, we don't want it in a library setting.
* libmpv/cocoa: make global events work and get rid of is_cplayerStefano Pigozzi2014-10-091-0/+2
| | | | | | | After @frau's split of macosx_events from macosx_application, `is_cplayer' is not needed anymore. At the moment only global events such as Media Keys and Apple Remote work, because the VO-level ones were hardcoded to be disabled. (that will be fix in a later commit ).
* client API: add an explanatory commentwm42014-10-091-1/+1
| | | | | So someone reading this at least has a chance to find out what this is needed for.
* client API: rename --input-x11-keyboard to --input-vo-keyboardwm42014-10-091-1/+1
| | | | | Apparently we need this for Cocoa too. (The option was X11 specific in the hope that only X11 would need this hack.)
* client API: introduce numeric log levelswm42014-10-081-0/+1
| | | | | | | | | | | | | | | | Maybe using strings for log levels was a mistake (too broad and too impractical), so I'm adding numeric log level at least for the receiver side. This makes it easier to map mpv log levels to other logging systems. I'm still too stingy to add a function to set the log level by a numeric value, though. The numeric values are not directly mapped to the internal mpv values, because then almost every file in mpv would have to include the client API header. Coalesce this into API version 1.6, since 1.6 was bumped just yesterday.
* client API, X11: change default keyboard input handling againwm42014-09-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 64b7811c tried to do the "right thing" with respect to whether keyboard input should be enabled or not. It turns out that X11 does something stupid by design. All modern toolkits work around this native X11 behavior, but embedding breaks these workarounds. The only way to handle this correctly is the XEmbed protocol. It needs to be supported by the toolkit, and probably also some mpv support. But Qt has inconsistent support for it. In Qt 4, a X11 specific embedding widget was needed. Qt 5.0 doesn't support it at all. Qt 5.1 apparently supports it via QWindow, but if it really does, I couldn't get it to work. So add a hack instead. The new --input-x11-keyboard option controls whether mpv should enable keyboard input on the X11 window or not. In the command line player, it's enabled by default, but in libmpv it's disabled. This hack has the same problem as all previous embedding had: move the mouse outside of the window, and you don't get keyboard input anymore. Likewise, mpv will steal all keyboard input from the parent application as long as the mouse is inside of the mpv window. Also see issue #1090.
* client API: use playback abort mechanismwm42014-09-131-0/+5
| | | | | | If you send the "quit" or "stop" command with the client API, it will now attempt to kill network I/O immediately (same as normal input in the previous commits).
* lua: synchronously wait until scripts are loadedwm42014-09-061-0/+22
| | | | | | | | | | | | | | | | | 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.
* client API: fix memory leak with rejected eventswm42014-08-311-35/+36
| | | | | | | | The event was copied early, and wasn't released if it was rejected instead of being added to the event queue. Fix by copying the event at a point when it's certainly added to the event queue. The dup_event_data() function is merely moved.
* player: update cache state only if requestedwm42014-08-281-1/+37
| | | | | | | | | 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.
* client API: directly lock playloopwm42014-08-141-4/+3
| | | | | | | | Until recently, vo_opengl could be accessed from a single thread only, due to the OpenGL API context being thread-specific. This issue doesn't exist anymore, because VOs run on their own thread. This means we can simply lock/unlock the playloop instead of doing something complicated to get the playloop thread to execute our code.
* client API: minor optimizations for property notificationwm42014-08-021-32/+44
| | | | | | | | | | | | | | | | | | | | | 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...)
* client API: fix deadlock when calling mpv_terminate_destroy before initwm42014-07-311-1/+1
| | | | | | | | | | This is perfectly allowed, but was ignored, because it's a corner case. It doesn't actually wait for other clients to be destroyed, but on the other hand I think there's no way to have other clients before initialization. CC: @mpv-player/stable
* audio, client API: check mp_make_wakeup_pipe() return valuewm42014-07-251-3/+4
| | | | Could fail e.g. due to FD exhaustion.
* client API: allow calling mpv_terminate_destroy(NULL)wm42014-07-041-0/+3
| | | | | | This is an oversight and a bug. CC: @mpv-player/stable
* Add more constwm42014-06-111-3/+3
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
* client API: disable LIRC input by defaultwm42014-06-091-0/+1
| | | | | | Not only should using libmpv hog such global resources; it's also very unlikely an application embedding mpv will ever want to make use of this.
* client API: minor documentation fixes/enhancementswm42014-06-081-2/+2
|
* client API: trigger wakeup when creating wakeup pipe/callbackwm42014-06-081-1/+5
| | | | | | | | | Since redundant wakeups are avoided now, it's easy to miss a wakeup when creating/setting the pipe/callback after the client API was signalled. If the client API is signalled, need_wakeup is set to true, and wakeup_client skips writing to the pipe or calling the client API. That this can happen is not very obvious to the client API, so trigger a wakeup right on start in order to remove this special case.
* client API: restructure waiting, do log msg wakeup properlywm42014-06-071-42/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | Until now, availability of new log messages (through the mechanism associated with mpv_request_log_messages()) did not wakeup the client API properly. Commit 3b7402b5 was basically a hack to improve that somewhat, but it wasn't a solution. The main problem is that the client API itself is producing messages, so the message callback would attempt to lock the client API lock, resulting in a deadlock. Even if the lock was recursive, we'd run into lock-order issues. Solve this by using a separate lock for waiting and wakeup. Also, since it's a natural addition, avoid redundant wakeups. This means the wakeup callback as well as the wakeup pipe will be triggered only once until the next mpv_wait_event() call happens. This might make the wakeup callback be invoked in a reentrant way for the first time, for example if a mpv_* function prints to a log. Adjust the docs accordingly. (Note that non-reentrant beheavior was never guaranteed - basically the wakeup callback is somewhat dangerous and inconvenient.) Also remove some traces of unneeded code. ctx->shutdown for one was never set, and probably a leftover of an abandoned idea.
* client API: rename mpv_destroy() to mpv_detach_destroy()wm42014-06-071-4/+3
| | | | | | A bit verbose, but less misleading. In most cases, the API user probably actually wants mpv_terminate_destroy() instead, so the less-useful function shouldn't have a simnpler name anyway.
* client API: add API function that ensures total destructionwm42014-06-071-2/+32
| | | | | | | | | | | | mpv_destroy() should perhaps better be called mpv_detach(), because it destroys only the handle, not necessarily the player. The player is only terminated if a quit command is sent. This function quits automatically, and additionally waits until the player is completely destroyed. It removes the possibility that the player core is still uninitializing, while all client handles are already destroyed. (Although in practice, the difference is usually not important.)
* client API: change mpv_wait_event() timeout semanticswm42014-06-071-1/+4
| | | | | | | | | Now a negative timeout mean an infinite timeout. This is similar to the poll() system call. Apparently this is more intuitive and less confusing than specifying a "very high" value as timeout if you want to wait forever. For callers that never pass negative timeouts, nothing changes.
* client API: enlarge the message buffer if log level is highwm42014-06-061-1/+2
|
* client API: call wakeup callback if there are new messageswm42014-06-061-13/+17
| | | | | | | | | | | | | | | | | | Listening on messages currently uses polling (every time mpv_wait_event() has no new events, the message buffer is polled and a message event is possibly created). Improve this situation a bit, and call the user-supplied wakeup callback. This will increase the frequency with which the wakeup callback is called, but the client is already supposed to be able to deal with this situation. Also, as before, calling mpv_wait_event() from the wakeup callback is forbidden, so the client can't read new messages from the callback directly. The wakeup pipe is written either. Since the wakeup pipe is created lazily, we can't access the pipe handle without creating a race condition or a deadlock. (This is actually very silly, since in practice the race condition won't matter, but for now let's keep it clean.)
* client API: don't update properties in uninitialized statewm42014-06-061-0/+2
| | | | | | If an API user calls mpv_wait_event() and mpv_observe_property() before mpv_initialize(), it could happen that a property was accessed before initialization, which is not ok.
* client API: don't use the mpv config files by defaultwm42014-06-061-0/+1
| | | | | | | | | This was always intended this way, and even documented in client.h. Due to an oversight it was never actually implemented. The intention is that mpv embedded in applications and "real mpv" don't conflict. An API user can undo this by setting the "config" option to "yes", if using the user's mpv config is desired.
* client API: use shared code for creating the wakeup pipewm42014-06-061-12/+2
| | | | Should be equivalent, reduces code duplication.
* client API: fix swapped pipe ends used with mpv_set_wakeup_callbackwm42014-06-061-2/+2
| | | | | This was extremely wrong. It was never tested because nobody ever used it (the feature was added for someone who never tried it in the end).
* client API: report success status when running commandswm42014-06-011-2/+3
| | | | | | Until now, an error was reported only if the command couldn't be parsed. Attempt to do more fine-grained reporting. This is not necessarily perfect, but it's an improvement.
* client API: fix mpv_observe_property with MP_FORMAT_NONEwm42014-05-241-2/+3
| | | | | It returned only 1 change event (after registration), and then went silent. This was accidentally broken some time ago.
* client API: add mpv_load_config_file()wm42014-05-181-0/+15
| | | | | | | This is probably a good idea, because it would make it easier for software embedding mpv to configure the mpv parts, without requiring the host program to provide explicit mechanisms for this (other than calling mpv_load_config_file()).
* options: unify code for setting string and "raw" optionswm42014-05-181-41/+39
| | | | | | | | | The code paths for setting options by string and by direct "raw" value were too different, which resulted in some weird code. Make the code paths closer to each other. Also, use this to remove the weirdness in the mpv_set_option() implementation.
* threads: use mpv time for mpthread_cond_timedwait wrapperwm42014-05-181-2/+2
| | | | | | Use the time as returned by mp_time_us() for mpthread_cond_timedwait(), instead of calculating the struct timespec value based on a timeout. This (probably) makes it easier to wait for a specific deadline.
* client API: fix "missed" property notificationswm42014-05-181-19/+25
| | | | | | | | | | | | | | | | | | If a property is notified as changed, and then again (before the change notification is returned to the client), and the second change is a sporadic change (i.e. nothing actually changed) and the change notification was associated with with a data type, it could happen that a change was "overlooked", because it would detect no change on the second notification. This is actually a pretty annoying corner case, due to the annoying way we do things, so just store both the previously returned _and_ the newly obtained property value. then we always compare with the user value to check for a change, excluding any possibility of a missed change. Note that we don't (can't/shouldn't) care if a value changes, and then changes back; it's fine if that doesn't generate a notification. This is due to how property notifications are supposed to be coalesced.
* player: reorganize how lua scripts are loadedwm42014-05-131-0/+5
| | | | | | 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.
* client API: fix inverted conditionwm42014-05-021-1/+1
| | | | Oops. Sigh.
* client API: add chapter change eventwm42014-04-271-0/+1
| | | | Also works for mpv_observe_property() on the "chapter" property.
* dispatch: move into its own source filewm42014-04-231-0/+1
| | | | | | | This was part of osdep/threads.c out of laziness. But it doesn't contain anything OS dependent. Note that the rest of threads.c actually isn't all that OS dependent either (just some minor ifdeffery to work around the lack of clock_gettime() on OSX).
* client API: make mpv_set_option set options nativelywm42014-04-221-1/+1
| | | | | | |