| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Fixes the issue pointed out in #4394.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
goto jumping over an initialization.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
They are not really interesting. At least one user complained about the
noise resulting from use with shell scripts, which connect and
disconnect immediately.
|
| | |
|
| |
|
|
| |
This is for the case if the FD is a uni-directional pipe.
|
| | |
|
| |
|
|
|
| |
This requires fchmod(), which is not necessarily available everywhere.
It also might not work at all. (It does work on Linux.)
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This was requested.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
MPV_EVENT_SCRIPT_INPUT_DISPATCH is now unused/deprecated.
Also remove a debug-print from defaults.lua.
|
| |
|
|
| |
Found by Coverity.
|
| |
|
|
| |
It's not necessarily available on Unix systems other than Linux (sigh).
|
| |
|
|
|
| |
The receiving part was implemented, but since no messages are enabled
by default, it couldn't be used.
|
| | |
|
| |
|
|
|
| |
Calling mpv_resume() too often is considered an API usage violation,
and will trigger an internal assertion somewhere.
|
| |
|
|
| |
Because why not.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Minimizes the differences between --input-file and --input-unix-socket.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Just a minor refactor to keep unneeded dependencies on the core low.
|
| | |
|
| | |
|
| |
|
wm4
James Ross-Gowan
Preston Hunt
Alessandro Ghedini