summaryrefslogtreecommitdiffstats
path: root/input/ipc.c
Commit message (Collapse)AuthorAgeFilesLines
* json: unify json_parse depth to MAX_JSON_DEPTH=50cvzi2023-07-081-1/+1
|
* various: drop unused #include "config.h"Thomas Weißschuh2023-02-201-2/+0
| | | | | | Most sources don't need config.h. The inclusion only leads to lots of unneeded recompilation if the configuration is changed.
* ipc: fix recently added memory leakwm42020-03-271-1/+3
| | | | Sucks.
* client API, lua, ipc: unify event struct returnwm42020-03-211-99/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* ipc: allow sending commands with named argumentswm42020-02-241-23/+22
| | | | | | | | | | | | | | This has been part of the libmpv for a while, so the implementation in the IPC code is quite simple: just pass the mpv_node representing the value of the "command" field without further checks to mpv_command_node(). The only problem are the IPC-specific commands, which essentially have their own dispatch mechanism. They expect an array. I'm not going to rewrite the dispatch mechanism, so these still work only with an array. I decided make the other case explicit with cmd==NULL. (I could also have set cmd=="", which would have avoided changing each if condition since "" matches no existing command, but that felt dirty.)
* ipc: implement asynchronous commandswm42020-02-241-8/+58
| | | | | | | | | | | I decided to make this explicit. The alternative would have been making all commands asynchronous always, like a small note in the manpage threatened. I think that could have caused compatibility issues. As a design decision, this does not send a reply if an async command started. This could be a good or bad idea, but in any case, it will make async command look almost like synchronous ones, except they don't block the IPC protocol.
* ipc: some user-visible changes to prepare for making all commands asyncwm42018-05-241-0/+6
| | | | | | | | | | | | | | | I wanted to put all commands through mpv_command_node_async() instead of mpv_command_node(). Using synchronous commands over a synchronous transport doesn't make sense anyway. This would have used the request_id field in IPC requests as reply ID for the async commands. But the latter need to be [u]int64, while the former can be any type. To avoid that we need an extra lookup table for mapping reply IDs to request_id values, we now require that request_id fields are integers. Since this would be an incompatible change, just deprecate non-integers for now, and plan the change for a later time.
* ipc: cosmetic: switch a negated if/elsewm42018-05-241-3/+3
|
* ipc: alias set_property_string to set_propertywm42018-05-241-20/+3
| | | | | | | | | The only effective difference is that the former explicitly checks whether the JSON value type is string, and errors out if not. The rest is exactly the same (mpv_set_property_string is mpv_set_property with MPV_FORMAT_STRING). It seems silly to keep this, so just remove it.
* node: move a mpv_node helper from ipc.c to shared codewm42018-05-241-14/+3
| | | | This particular one is needed in a following commit.
* ipc: raise json nesting limitwm42017-05-031-2/+2
| | | | Fixes the issue pointed out in #4394.
* client API: turn mpv_suspend() and mpv_resume() into stubswm42016-11-221-6/+0
| | | | | | | | | | | 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.
* ipc: add Windows implementation with named pipesJames Ross-Gowan2016-03-231-427/+39
| | | | | | | | | | | | | | | This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
* ipc: fix uninitialized fieldwm42016-02-121-1/+1
| | | | | | | The sockaddr_un.sun_len field was not initialized. It seems our API use is correct by simply making sure it's 0. Fixes CID 1350075.
* Change 3 more files to LGPLwm42016-01-201-7/+7
|
* ipc: fix undefined behavior in some error caseswm42015-07-061-1/+2
| | | | goto jumping over an initialization.
* ipc: add request_id to jsonPreston Hunt2015-07-031-0/+10
| | | | | | | | | | | | If the request contains a "request_id", copy it back into the response. There is no interpretation of the request_id value by mpv; the only purpose is to make it easier on the requester by providing an ability to match up responses with requests. Because the IPC mechanism sends events continously, it's possible for the response to a request to arrive several events after the request was made. This can make it very difficult on the requester to determine which response goes to which request.
* ipc: avoid SIGPIPEwm42015-05-121-1/+5
| | | | | | | | | Until now, we just blocked SIGPIPE globally. Fix it properly to get away from it. MSG_NOSIGNAL should be widely available and is part of the POSIX.1-2008 standard. But it's not available on OSX, because Apple is both evil and retarded. Thus we continue to ignore the problem on such shitty systems.
* ipc: silence some common info messageswm42015-05-051-3/+3
| | | | | | They are not really interesting. At least one user complained about the noise resulting from use with shell scripts, which connect and disconnect immediately.
* input: handle closed pipe correctlywm42015-02-261-1/+1
|
* input: if FD is not writable, just don't write to the FDwm42015-02-261-6/+11
| | | | This is for the case if the FD is a uni-directional pipe.
* input: allow passing FDs to --input-filewm42015-02-261-3/+12
|
* input: avoid creating world-writeable file with --input-unix-socketwm42015-02-261-0/+4
| | | | | This requires fchmod(), which is not necessarily available everywhere. It also might not work at all. (It does work on Linux.)
* ipc: put playback core to sleep while dequeuing commandswm42015-02-131-1/+7
| | | | | | | Happens to fix #1581 due to an unfortunate interaction with the way the VO does not react to commands for a while if a video frame is queued. Slightly improves other situations as well, if the client spams mpv with commands during playback.
* ipc: add enable_event and disable_event commandswm42014-12-241-0/+33
| | | | This was requested.
* ipc: report some user errors betterwm42014-12-241-2/+5
| | | | | | | | | | | | | | | Using the IPC with a program, it's not often obvious that a newline must be sent to terminate a command. Print a warning if the connection is closed while there is still uninterpreted data in the buffer. Print the OS reported error if reading/writing the socket fails. Print an erro if JSON parsing fails. I considered silencing write errors if the write end is closed (EPIPE), because a client might send a bunch of commands, and then close the socket without wanting to read the reply. But then, mpv disconnects without reading further commands that might still be buffered, so it's probably a good idea to always print the error.
* client API: be more lenient about mpv_suspend/resume mismatcheswm42014-12-151-16/+4
| | | | | | | | | | | | 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.
* lua, ipc: remove leftoverswm42014-11-241-9/+0
| | | | | | MPV_EVENT_SCRIPT_INPUT_DISPATCH is now unused/deprecated. Also remove a debug-print from defaults.lua.
* ipc: fix confusion of write() return value and errnowm42014-11-211-3/+3
| | | | Found by Coverity.
* ipc: make sure --input-file=/dev/stdin always workswm42014-11-071-7/+20
| | | | It's not necessarily available on Unix systems other than Linux (sigh).
* ipc: make it possible to receive log messageswm42014-11-011-0/+13
| | | | | The receiving part was implemented, but since no messages are enabled by default, it couldn't be used.
* ipc: add a command to retrieve API versionwm42014-11-011-0/+4
|
* ipc: verify resume/suspend commandswm42014-11-011-4/+16
| | | | | Calling mpv_resume() too often is considered an API usage violation, and will trigger an internal assertion somewhere.
* input: resolve ~ and similar for --input-filewm42014-10-241-2/+3
| | | | Because why not.
* Set thread name for debuggingwm42014-10-191-0/+5
| | | | | | | | | | 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.
* ipc: skip empty and commented lineswm42014-10-191-2/+4
|
* ipc: accept both JSON and "old" commandswm42014-10-191-30/+27
| | | | Minimizes the differences between --input-file and --input-unix-socket.
* ipc: fix minor error cleanup issueswm42014-10-191-8/+8
| | | | | | | | | | | | | | The ipc_thread can exit any time, and will free the mp_ipc_ctx when doing this, leaving a dangling pointer. This was somewhat handled in the original commit by setting mpctx->ipc_ctx to NULL when the thread exited, but that was still a race condition. Handle it by freeing most things after joining the ipc_thread. This means some resources will not be freed until player exit, but that should be ok (it's an exceptional error situation). Also, actually close the pipe FDs in mp_init_ipc() on another error path.
* ipc: decouple from MPContextwm42014-10-191-41/+43
| | | | Just a minor refactor to keep unneeded dependencies on the core low.
* ipc: fix a small memory leakwm42014-10-171-1/+2
|
* input: implement --input-file on unix using the IPC supportAlessandro Ghedini2014-10-171-11/+55
|
* input: implement JSON-based IPC protocolAlessandro Ghedini2014-10-171-0/+723