summaryrefslogtreecommitdiffstats
path: root/player/client.c
Commit message (Collapse)AuthorAgeFilesLines
* client API: report IDs of inserted playlist entries on loading playlistwm42020-03-271-0/+6
| | | | | | May or may not help when dealing with playlist loading in scripts. It's supposed to help with the mean fact that loading a recursive playlist will essentially edit the playlist behind the API user's back.
* scripting: remove race condition when toggling internal scriptswm42020-03-261-8/+0
| | | | | | | | | | Scripts such as the OSC can be loaded and unloaded at runtime by toggling the option that enables them. (It even works, although normally it's only used to control initial loading.) Unloading was racy because it used the client name; fix this. The load-script change is an accidental feature. And probably useless.
* command: use client IDs for hookswm42020-03-261-2/+10
| | | | | Removes weird potential race conditions when a client is removed and a new one with the same name is created.
* client API: add a per client unique IDwm42020-03-261-0/+27
| | | | | | I mostly intend this for internal purposes. Probably pretty useless for external API users, but on the other hand trivial to expose. While it makes a lot of sense internally, I'll probably regret exposing it.
* client API, lua: unify event code furtherwm42020-03-211-0/+10
| | | | | | | | | Move some parts that can be generic to the client API code. It turns out lua.c doesn't need anything special. This adds the "id" field. I think this was actually missing from the JSON IPC code (i.e. it's a very recent regression that is fixed with this commit).
* client API, lua, ipc: unify event struct returnwm42020-03-211-0/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both Lua and the JSON IPC code need to convert the mpv_event struct (and everything it points to) to Lua tables or JSON. I was getting sick of having to make the same changes to Lua and IPC. Do what has been done everywhere else, and let the core handle this by going through mpv_node (which is supposed to serve both Lua tables and JSON, and potentially other scripting language backends). Expose it as new libmpv API function. The new API is still a bit "rough" and support for other event types might be added in the future. This silently adds support for the playlist_entry_id fields to both Lua and JSON IPC. There is a small API change for Lua; I don't think this matters, so I didn't care about compatibility. The new code in client.c is mashed up from the Lua and the IPC code. The manpage additions are moved from the Lua docs, and made slightly more "general". Some danger for unintended regressions both in Lua and IPC. Also damn these node functions suck, expect crashes due to UB. Not sure why this became more code instead of less compared to before (according to the diff stat), even though some code duplication across Lua and IPC was removed. Software development sucks.
* client API: actually warn against enabling any deprecated eventswm42020-03-211-2/+18
| | | | | | Like it was done for the "tick" event, but for all deprecated events. Not entirely effective, since the C API enables all events by default.
* client API: fix MPV_FORMAT_DOUBLE => MPV_FORMAT_INT64wm42020-03-181-1/+3
| | | | (Why can it do this conversion at all? This is shitshow anyway.)
* client API: always reset new_property_events fieldswm42020-03-071-1/+2
| | | | | | This was not reset in the num_properties==0 case. This didn't really matter, but for debugging it's slightly nicer to see new_property_events reset once the client thread is done with it.
* client API: provide ways to finish property changes on file changeswm42020-03-071-3/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the current file changes (or rather, when starting/finishing playback of a playlist entry), clients tend to have the problem that it's hard to tell whether a property change notification (via mpv_observe_property() and mechanisms layered on top of it) is from the previous or new playlist entry. The previous commit probably helps, but all the asynchronity is still a bit unhelpful. Try to make this better by adding new hooks, that are run before/after playback init/deinit. This is similar to the existing hooks, except they're outside of "initialized" playback, which excludes that you might accidentally get an overlap between the current and the previous/next playlist entry. That still doesn't seem quite enough, since normally, property change notifications come after the hook event. So basically a client would have to explicitly "drain" the event queue within the hook, and make the hook continue only after that is done. Knowing when property notifications are done is another asynchronous nightmare (how exactly it works keeps changing within client.c, and an API user probably can't tell anymore when all pending properties are truly done). So introduce another guarantee: properties that were changed before the hook happens will be returned before the hook event is returned. That means the client will have received all pending property notifications from the previous playlist entry (or whatever) before the hook is entered. As another minor complication, we shouldn't just keep the hook pending until _all_ property notifications are done, since the client's hook could produce new ones. (Or just consider things like the demuxer thread hammering the client with cache update events, while the "on_preloaded" hook is run.) So there is some extra untested, fragile logic in client.c to handle this (the waiting_for_hook flag). This probably works, but was barely tested. Not sure if this helps anyone, but I think it's fine for my own purposes. (I really hated this aspect of the API whenever I used it myself.)
* client API: avoid returning stale value on property notificationswm42020-03-061-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | This could happen if a property was flagged as changed, then updated, then flagged again, but gen_property_change_event() was called before the value was updated a second time. Then the function simply returned the old value, and would later trigger a new change event again. This was considered acceptable before, since property notifications are asynchronous anyway (so they may always be "outdated", it just mattered whether the most recent value was eventually delivered). But consider ordering with events. It seems desirable that specific important events (e.g. MPV_EVENT_START_FILE) should not be followed by property updates that happened before it, because that would make application logic really a mess, and property notification near-useless in certain cases. Avoid this by never returning a value if it was marked changed, but not updated yet. Unfortunately, this could lead to clients never receiving a value (or receiving it with a high random delay), if they're too slow to read it (or the property simply updates too often). Note that this is done for _all_ property notifications, not just returned events. Hopefully not a problem in practice. If it turns out to be one, this mechanism could be restricted to actually returned events, for which this really matters.
* command: remove legacy hook APIwm42020-03-061-1/+1
| | | | | Hopefully nothing uses this. (I know one exception, but, well, what can I do.)
* ta: remove two pointless wrapperswm42020-02-231-1/+1
|
* client API: fix race condition on client exitwm42020-02-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The relatively recently added property update code has a race condition when clients exit. It still tried to access mpv_handle during and after it was destroyed. The reason is that it unlocks the lock for the mpv_handle list (while mpv_handle is locked), but nothing in mp_destroy_client() cares about this case. The latter function locks mpv_handle only before/while it makes sure all of its activity is coming to an end, such as asynchronous requests, and property updates that are in progress. It did not include the case when mp_client_send_property_changes() was still calling send_client_property_changes() with mpv_handle locked. Fix this by checking the mpv_handle.destroying field. This field can be set only when mpv_handle is locked. While we're checking the lock, the mpv_handle list is still locked, so at worst we might be at the point before mp_destroy_client() locks the list again and finally destroys the mpv_handle. This is a hard to reproduce race condition which I spotted only once in valgrind by chance, so the fix is unconfirmed.
* scripting: load scripts from directorieswm42020-02-011-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | The intention is to provide a slightly nicer way to distribute scripts. For example, you could put multiple source files into the directory, and then import them from the actual script file (this is still unimplemented). At first I wanted to require a config file (because you need to know at least which scripting backend it should use). This wouldn't have been too hard (could have reused/abused the mpv config file parsing mechanism, and I already had working code that was just 2 function calls). But probably better to do this without new config files, because it might become a pain in the distant future. So this just probes for "main.lua", "main.js", etc., until an existing file is found. Another important change is that this skips all directory entries whose name starts with ".". This automatically excludes the "." and ".." special directories, and is probably useful to exclude random crap that might be lying around in the directory (such as editor temporary files, or OSX, in its usual hrmful, annoying, and idiotic modus operandi, sharting all over any directories opened by "Finder"). Although the changelog mentions the docs, they're added only in a later commit.
* client API: fix property notification from non-playloop sourceswm42020-01-091-2/+4
| | | | | | | | | | | | | | | This code assumed that the function is only called from the playloop itself (and since property notification is done at the end of it, i.e. before sleeping, it obviously would not have needed to wake up the core). But this function is actually called from some comments (such as playlist-move), so this assumption was incorrect. Use the same method as the other function. Untested. Fixes: #7339 (probably)
* client API: change event mask to event number in one placewm42020-01-091-4/+5
| | | | Cosmetic change. Slightly more convenient/readable.
* osd: fix possible misses of osd-dimensions property updateswm42020-01-081-0/+11
| | | | | | | | | | | | | check_obj_resize() in sub/osd.c calls mp_client_broadcast_event(), which calls notify_property_events(). This is pretty unexpected, because check_obj_resize() may be called from the VO thread. While that's sort of awful, it seems to be OK locking-wise. But it breaks an assumption in notify_property_events() that the core doesn't need to be woken up, which could possibly lead to a missed/delayed property update (although rather unlikely). Fix this by explicitly waking up the core when it's called from the OSD code.
* client API, lua: add new API for setting OSD overlayswm42019-12-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Lua scripting has an undocumented mp.set_osd_ass() function, which is used by osc.lua and console.lua. Apparently, 3rd party scripts also use this. It's probably time to make this a public API. The Lua implementation just bypassed the libmpv API. To make it usable by any type of client, turn it into a command, "osd-overlay". There's already a "overlay-add". Ignore it (although the manpage admits guiltiness). I don't really want to deal with that old command. Its main problem is that it uses global IDs, while I'd like to avoid that scripts mess with each others overlays (whether that is accidentally or intentionally). Maybe "overlay-add" can eventually be merged into "osd-overlay", but I'm too lazy to do that now. Scripting now uses the commands. There is a helper to manage OSD overlays. The helper is very "thin"; I only want to force script authors to use the ID allocation, which may help with putting multiple scripts into a single .lua file without causing conflicts (basically, avoiding singletons within a script's environment). The old set_osd_ass() is emulated with the new API. The JS scripting wrapper also provides a set_osd_ass() function, which calls internal mpv API. Comment that part (to keep it compiling), but I'm leaving it to @avih to finish the change.
* client API: deprecate tick eventwm42019-12-221-0/+2
| | | | | This is conceptually outdated and should not exist. This affects Lua scripting and JSON IPC too.
* client API: rewrite property observation (again)wm42019-12-191-137/+192
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I intend to rewrite this code approximately every 2 months. Last time, I did this in commit d66eb93e5d4 (and 065c307e8e7 and b2006eeb74f). It was intended to remove the roundabout synchronous thread "ping pong" when observing properties. At first, the original async. code was replaced with some nice mostly synchronous code. But then an async. code path had to be added for vo_libmpv, and finally the sync. code was dropped because it broke in other obscure cases (like the Objective-C Cocoa backend). Try again. This time, update properties entirely on the main thread. Updates get batched out on every playloop iteration. (At first I wanted it to make it every time the player goes to sleep, but that might starve API clients if the playloop get saturated.) One nice thing is that clients only get woken up once all changed events have been sent, which might reduce overhead. While this sounds simple, it's not. The main problem is that reading properties must not block the client API, i.e. no client API locks can be held while reading the property. Maybe eventually we can avoid this requirement, but currently it's just a fact. This means we have to iterate over all clients and then over all properties (of each client), all while releasing all locks when updating a property. Solve this by rechecking on each iteration whether the list changed, and if so, aborting the iteration and redo it "next time". High risk change, expect bugs such as crashes and missing property updates.
* client API: remove some dead codewm42019-12-171-6/+0
| | | | | This was for the "suspend" API, which has been removed (turned into stubs) a long time ago.
* player: remove mechanisms for better logging with repl.luawm42019-11-181-7/+22
| | | | | | | | | | | | | | | | | | | | | | As preparation for making repl.lua part of the core (maybe), add some mechanisms which are supposed to improve its behavior. Add a silent mode. Calling mpv_request_log_messages() with the log level name prefixed with "silent:" will disable logging from the API user's perspective. But it will keep the log buffer, and record new messages, without returning them to the user. If logging is enabled again by requesting the same log level without "silent:" prefix, the buffered log messages are returned to the user at once. This is not documented, because it's far too messy and special as that I'd want anyone to rely on this behavior, but it will be perfectly fine for an internal script. Another thing is that we record early startup messages. The goal is to make the repl.lua script show option and config parsing file errors. This works only with the special "terminal-default" log level. In addition, reduce the "terminal-default" capacity to only 100 log messages. If this is going to be enabled by default, it shouldn't use too much resources.
* client API: remove sync. property notification code againwm42019-11-161-41/+14
| | | | | | | | | | | | It's too easy to introduce unintended circular lock dependencies. Just now we found that the (old) cocoa vo_gpu backend is also affected by this, because it waits on the Cocoa main thread, which in turn uses libmpv API for OSX... stuff. Also fix a missing initial property update after observe. This leaves me unhappy, because it just leads to a stupid thread ping pong. Will probably rewrite this later.
* options: remove M_SETOPT_RUNTIMEwm42019-11-101-5/+2
| | | | | | | Used to contain flags for "save" setting of options at runtime. Now there is nothing special needed anymore and it's 0. So drop it completely, and remove anything that distinguishes between runtime and initialization time.
* client API: reduce log level of client exitingwm42019-11-011-1/+1
| | | | See previous commit message.
* client API: copy instead of move old value on async pathwm42019-10-251-4/+1
| | | | | | | | In theory, it's better to keep the old value, because that's more consistent with the logic of using change timestamps. With the current code, the old value will probably never be used (instead it will fetch a new value on every change), so this shouldn't make a difference in practice.
* client API: add async path; fix deadlock for vo_libmpv userswm42019-10-251-9/+95
| | | | | | | | | | | | | | | | | | | | | | In commit 065c307e8e7db, I broke everything. It seemed like a nice idea, but it explicitly broke an assumption vo_libmpv were explicitly allowed to make: that observing properties does not lock the core. The commit did just that and locked the core for property updates. This made for example mpv's own OSX backend freeze (it uses vo_libmpv for convenience to make up for Apple's incredibly broken OpenGL shit). I don't want to revert that commit just because vo_libmpv's design is horrible. So instead add an optional asynchronous path, that is only used if vo_libmpv is in use (best idea ever?). Interestingly, this isn't so hard. It adds about 90 lines of code, which are only run on OSX and libmpv users, so I don't have to care about the crashes and weird behavior this might cause. It even worked on the first try except for a quickly fixed memory leak. The code path can be tested anywhere by just turning the uses_vo_libmpv condition into always true. The atomic is out of laziness. Saves some thinking how to get around the locking order.
* client API: avoid lost wakeupswm42019-10-241-3/+7
| | | | | | | | | | | | The commit linked below added temporary unlocking to update_prop(), which is indirectly called by mpv_wait_event(). If an unlock happens, and no property change event is returned, we must re-poll the event queue. Rechecking the state on unlocks is basically a standard requirement for code using condition variables. Untested beyond a simple test. Fixes: 065c307e8e7dbf
* client API: simplify (?) property change notification generationwm42019-10-241-75/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Property change notification works by having the mpv core wake up all clients observing a property when the property potentially changes. The clients then read the property's value, and determine if there was an actual change. (The latter part depends what the property returned for the previous change notification, so it depends on the client, and cannot be generated by the core itself.) Until now, reading the property value was done in a pseudo-async way by queuing a callback back to the core, running it there, and then waking up the client thread again. I cannot comprehend why this was done in such a complicated, fragile way. Maybe it's a leftover from times when client.c had to do this (in short, because properties could access vo_opengl, which has thread-local state). One past idea was to make the implementation of true async properties easier (for which you would need such a state machine anyway). But they don't exist yet, and I doubt the current mess would be really helpful when actually implementing them. Simplify this, and run the update in the client's thread directly. In addition to the fundamental change, many roundabout things can be removed as a consequence. Unfortunately, I noticed that lock order issues force you to release ctx->lock before doing so, which makes things more complex due to possible concurrent mpv_unobserve_property() calls. Solve this by removing properties lazily, which means you may have to do multiple mpv_wait_event() calls before the property entry is actually destroyed. This should not matter in practice, and does not affect the semantics. It could also cause "leaks" by observing/unobserving properties in a loop, without ever calling mpv_wait_event(). Just don't do this, duh. (I considered making this dependent on whether the previous mpv_wait_event() call returned the property being removed, but a separate code path seemed too complicated. I also considered copying the name and property data when returning a MPV_EVENT_PROPERTY_CHANGE, but actually this doesn't solve the problem of update_prop() being interrupted by mpv_unobserve_property(); there are ways around it, but I just said no.) This was made using the cowboy coding software engineering methodology. If you find any bugs, keep them yourself.
* client API: move a functionwm42019-10-241-7/+7
| | | | May reduce the diff of the next commit.
* client API: remove unused global event maskwm42019-10-241-35/+0
| | | | | | Apparently this was only added and used for cache update stuff, which was changed in commit 8dbc93a94cdc3c. Now it's unused, messy, ugly, and is in the way, so get rid of it.
* client API: add mpv_command_retDark2019-09-211-0/+9
| | | | | | | | | | This change adds a version of `mpv_command` that also returns a result. The main rationale behind this is `mpv_command_node` requires defining multiple structs before you can even use it, which results in a pretty painful to use interface just to get the result from a command. There isn't really a good name for this function, so I'm open to suggestions on a better name for it.
* client API: fix missing property change events after property updatesGunnar Marten2019-09-201-24/+28
| | | | | | | | | | | | | | | | | | | | | | | | | When update_prop() successfully fetched a changed property value, it set prop->changed to true to indicate the success. mark_property_changed() also always set prop->changed to true and additionally prop->need_new_value to true This is the case since 6ac0ef78 If the observed property changes every frame and then due to timing the next mark_property_changed() is called before gen_property_change_event() and therefore directly after update_prop(), prop->need_new_value was again true and indicated that a new value has to be retrieved with update_prop(). As a result the event for the last successful update_prop() was never triggered. This meant that a property change event were never generated for frame-based properties only for properties that were observed with MPV_FORMAT_NONE or when the timing was different and gen_property_change_event() was called after update_prop(). To fix this, mark_property_change() and update_prop() should not use the same flag to indicate different things and therefore a new flag for successfully update a property is introduced. But with the now decoupled property changed and updated the need_new_value flag is redundant and removed completely. Fixes #4195
* render api: fix use-after-freewnoun2019-09-201-19/+3
| | | | | | | | render api needs to wait for vo to be destroyed before frees the context. The purpose of kill_cb is to wake up render api after vo is destroyed, but uninit did that before kill_cb, so kill_cb tries using the freed memory. Remove kill_cb to fix the issue as uninit is able to do the work.
* client: fix potential mpv_cmd/async leakdudemanguy2019-07-081-4/+8
|
* player: make playback termination asynchronouswm42018-05-241-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, stopping playback aborted the demuxer and I/O layer violently by signaling mp_cancel (bound to libavformat's AVIOInterruptCB mechanism). Change it to try closing them gracefully. The main purpose is to silence those libavformat errors that happen when you request termination. Most of libavformat barely cares about the termination mechanism (AVIOInterruptCB), and essentially it's like the network connection is abruptly severed, or file I/O suddenly returns I/O errors. There were issues with dumb TLS warnings, parsers complaining about incomplete data, and some special protocols that require server communication to gracefully disconnect. We still want to abort it forcefully if it refuses to terminate on its own, so a timeout is required. Users can set the timeout to 0, which should give them the old behavior. This also removes the old mechanism that treats certain commands (like "quit") specially, and tries to terminate the demuxers even if the core is currently frozen. This is for situations where the core synchronized to the demuxer or stream layer while network is unresponsive. This in turn can only happen due to the "program" or "cache-size" properties in the current code (see one of the previous commits). Also, the old mechanism doesn't fit particularly well with the new one. We wouldn't want to abort playback immediately on a "quit" command - the new code is all about giving it a chance to end it gracefully. We'd need some sort of watchdog thread or something equally complicated to handle this. So just remove it. The change in osd.c is to prevent that it clears the status line while waiting for termination. The normal status line code doesn't output anything useful at this point, and the code path taken clears it, both of which is an annoying behavior change, so just let it show the old one.
* misc: move some helper code from client.cwm42018-05-241-49/+2
| | | | | (Slightly oddly function names, because I want to avoid starting them with mpv_*, which is reserved for public API.)
* client API: kill async commands on terminationwm42018-05-241-13/+41
| | | | | | | | | | | This affects async commands started by client API, commands with async capability run in a sync way by client API (think mpv_command_node() with "subprocess"), and detached async work. Since scripts might want to do some cleanup work (that might involve launching processes, don't ask), we don't unconditionally kill everything on exit, but apply an arbitrary timeout of 2 seconds until async commands are aborted.
* command: add a way to abort asynchronous commandswm42018-05-241-3/+33
| | | | | | | | | | | | Many asynchronous commands are potentially long running operations, such as loading something from network or running a foreign process. Obviously it shouldn't just be possible for them to freeze the player if they don't terminate as expected. Also, there will be situations where you want to explicitly stop some of those operations explicitly. So add an infrastructure for this. Commands have to support this explicitly. The next commit uses this to actually add support to a command.
*