E.g. "mouse 100 100 1 double" did not actually process the double-click,
because double-click emulation is on by default. So the user would have
to send two successive clicks instead. This is probably not expected, so
disable this weird logic for artificial input.
Fixes#2899.
The default security descriptor for named pipes in Windows allows the
pipe to be opened for read access by the Everyone group and Anonymous
account, as well as low-integrity processes (like web browser renderer
processes.) This does not allow commands to be ran, but it does allow
events to be received.
I don't think any sensitive data is exposed by events, but that may not
always be the case and Lua plugins might change this, since they can
broadcast their own events with script-message. To be safe, this commit
sets a custom security descriptor on the named pipe which only allows
access from processes running under the same user account with an
integrity level greater than or equal to the one used by mpv.
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.
Drag&drop mechanisms typically support multiple types for the drop data.
Move most of the logic which types are accepted and preferred to
event.c, where the data is also interpreted.
(Maybe sorting the types by assigning scores is over-engineered, since
they're already sorted by preference, but it's actually not much more
code.)
Not very interesting/meaningful yet, but preparation for the next
commit.
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
The "script-binding" command is used by the Lua scripting wrapper to
register key bindings on the fly. It's also the only way to get fine-
grained information about key events (such as separate key up/down
events). This information is sent via a "key-binding" message when the
state of a key changes.
Extend it to send name of the mapped key itself. Previously, it was
assumed that the user just uses an unique identifier for the binding's
name, so it wasn't needed. With this change, a user can map exactly the
same command to multiple keys, which is useful especially with the next
commit.
Part of #2612.
libwaio was added due to the complete inability to cancel synchronous
I/O cleanly using the public Windows API in Windows XP. Even calling
TerminateThread on the thread performing I/O was a bad solution, because
the TerminateThread function in XP would leak the thread's stack.
In Vista and up, however, this is no longer a problem. CancelIoEx can
cancel synchronous I/O running on other threads, allowing the thread to
exit cleanly, so replace libwaio usage with native Vista API functions.
It should be noted that this change also removes the hack added in
8a27025 for preventing a deadlock that only seemed to happen in Windows
XP. KB2009703 says that Vista and up are not affected by this, due to a
change in the implementation of GetFileType, so the hack should not be
needed anymore.
There was a complaint that the naming is inaccurate. That's probably
right. Just use the official name instead, which is a bit clunky, but
surely correct.
This was in sub/, because the code used to be specific to subtitles. It
was extended to automatically load external audio files too, and moving
the file and renaming it was long overdue.
The value 0 was treated specially, and effectively forced the increment
to 1. Interestingly, passing 0 or no value also does not include the
scale (from touchpads etc.), but this is probably an accidental behavior
that was never intentionally added.
Simplify it and make the default increment 1. 0 now means what it
should: the value will not be changed. This is not particularly useful,
but on the other hand there is no need for surprising and unintuitive
semantics.
OARG_CYCLEDIR() failed to apply the default value, because
m_option_type_cycle_dir was missing a copy handler - add this too.
This was completely broken. It was checked manually in some config
loading paths, so it appeared to work. But the intention was always to
completely disable reading from the normal config dir. This logic was
broken in commit 2263f37d.
The manual checks are actually redundant, and are not needed if
--no-config is implemented properly - remove them.
Additionally, the change to load the libmpv defaults from an embedded
profile also failed to set "config=no". The option is marked as not
being settable by a config file, and the libmpv default profile is
parsed as a config file, so this option was rejected. Fix it by removing
the CONF_NOCFG flag. (Alternatively, m_config_set_profile() could be
changed not to set the "config file" flag by default, but I'm not
bothering with this.)
This puts in place the machinery to merely append dropped file to the playlist
instead of replacing the existing playlist. In this commit, all front-ends
set this to false preserving the existing behaviour.
Removes some more internal API calls from the Lua scripting backend.
Which is good, because ideally the scripting backend would use libmpv
functions only.
One awkwardness is that mouse sections are still not supported by the
public commands (and probably will never), so flags like allow-hide-
cursor make no sense to an outside user.
Also, the way flags are passed to the Lua function changes. But that's
ok, because they're only undocumented internal functions, and not
supposed to be used by script users. osc.lua only does due to historical
reasons.
This was requested. It was more or less present internally already and
used for Lua scripting. Lua will switch to the "public" functions in
the following commits.
Nobody wanted to restore this, so it gets the boot.
If anyone still wants to volunteer to restore menu support, this would
be welcome. (I might even try it myself if I feel masochistic and like
wasting a lot of time for nothing.) But if it does get restored, it
should be done differently. There were many stupid things about how it
was done. For example, it somehow tried to pull mp_nav_events through
all the layers (including needing to "buffer" them in the demuxer),
which was needlessly complicated. It could be done simpler.
This code was already inactive, so this commit actually changes nothing.
Also keep in mind that normal DVD/BD playback still works.
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.
So successful playback and user quit can be distinguished, for whatever
reason you may want to do this.
Normally, the "quit" command can be customized, but this does not work
for quit commands sent by the terminal signal handler. One solution
would be introducing something like "ON_SIGNAL" (equivalent to
"CLOSE_WIN"), but considering there are a bunch of possible signals, I'd
rather not get into this. So go with the dumb solution.
Probably fixes#2029.
This command has been deprecated in the 0.8.x and 0.9.x releases - get
rid of it. Its only point ever was MPlayer compatibility, which broke
years ago anyway.
Wnile it seems quite logical to me that commands use _ as word
separator, while properties use -, I can't really explain the
difference, and it tends to confuse users as well. So always
prefer - as separator for everything.
Using _ still works, and will probably forever. Not doing so would
probably create too much chaos and confusion.
Only absolute percentage seeking was permitted first. It is now also
possible to seek by relative percentage.
MPSEEK_FACTOR is used as seek_type.
Fixes#1950.
Signed-off-by: wm4 <wm4@nowhere>
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.
Now the rescan_external_files command will by default reselect the audio
and subtitle streams. This should be more intuitive.
Client API users and Lua scripts might break, but can be fixed in a
backward-compatible way by setting the mode explicitly.
Why did this exist in the first place? Other than being completely
useless, this even caused some regressions in the past. For example,
there was the case of a laptop exposing its accelerometer as joystick
device, which led to extremely fun things due to the default mappings of
axis movement being mapped to seeking.
I suppose those who really want to use their joystick to control a media
player (???) can configure it as mouse device or so.
This gets rid of the need for a second (or more) parameters; instead it
can be all in one parameter. The (now) redundant parameter is still
parsed for compatibility, though.
The way the flags make each other conflict is a bit tricky: they have
overlapping bits, and the option parser disallows setting already set
bits.
MPlayer requires numeric values for input command parameters. mplayer2
also did. mpv changed these to choices using symbolic strings a long
time ago, but left numeric choices for compatibility.
Add MP_KEY_MOUSE_ENTER to the ignored input if the user has disabled
mouse input. Remove one instance of code duplication, and add a
MP_KEY_IS_MOUSE_MOVE macro to summarize events that are caused by moving
the mouse.
Makes all keys documented in XF86keysym.h mappable. This requires the
user to deal with numeric keycodes; no names are queried or exported.
This is an easy way to avoid adding all the hundreds of XF86 keys to
our X11 lookup table and mpv's keycode/name list.
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.
These commands are counterparts of sub_add/sub_remove/sub_reload which
work for external audio file.
Signed-off-by: wm4 <wm4@nowhere>
(minor simplification)
New command `mouse <x> <y> [<button> [single|double]]` is introduced.
This will update mouse position with given coordinate (`<x>`, `<y>`),
and additionally, send single-click or double-click event if `<button>`
is given.
Closing the video window sends CLOSE_WIN, which is normally mapped to
the "quit" command. The client API normally disables all key bindings,
and closing the window does nothing. It's simply left to the application
to handle this. This is fine - an embedded window can not be destroyed
by user interaction.
But sometimes, the window might be destroyed anyway, for example because
the containing window is destroyed. If this happens, CLOSE_WIN should
better not be ignored. We can't expect client API users to handle this
specially (by providing their own input.conf), so provide some fallback
for this pseudo key binding. The "quit" command might be too intrusive
(not every client necessarily handles "unexpected" MPV_EVENT_SHUTDOWN),
but I think it's still reasonable.
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.
If the user has LEFT/RIGHT/etc. bound in his input.conf, then these were
overriding the menu keys in dvdnav mode.
This hack works because the dvdnav crap happens to be the only user of
MP_INPUT_ON_TOP. If it finds a default key binding in the dvdnav menu
section, it will use that, instead of continuing search and possibly
finding the user key bindings meant for normal playback.
...because everything is terrible.
strerror() is not documented as having to be thread-safe by POSIX and
C11. (Which is pretty much bullshit, because both mandate threads and
some form of thread-local storage - so there's no excuse why
implementation couldn't implement this in a thread-safe way. Especially
with C11 this is ridiculous, because there is no way to use threads and
convert error numbers to strings at the same time!)
Since we heavily use threads now, we should avoid unsafe functions like
strerror().
strerror_r() is in POSIX, but GNU/glibc deliberately fucks it up and
gives the function different semantics than the POSIX one. It's a bit of
work to convince this piece of shit to expose the POSIX standard
function, and not the messed up GNU one.
strerror_l() is also in POSIX, but only since the 2008 standard, and
thus is not widespread.
The solution is using avlibc (libavutil, by its official name), which
handles the unportable details for us, mostly. We avoid some pain.
Simpler, and leaves the decision to repeat or not fully to the script
(instead of requiring the user to care about it when remapping a script
binding).
Otherwise, mouse button bindings added by mp.add_key_binding() would be
ignored.
It's possible that this "breaks" some older scripts using undocumented
Lua script functions, but it should be safe otherwise.
Fixes#1283.
The fact that it's a generic command prefix that is parsed even when
using the client API is a bit unclean (because this flag makes sense
for actual key-bindings only), but it's less code this way.
This command was actually requested on IRC ages ago, but I forgot about
it.
The main purpose is that the decoding state can be reset without issuing
a seek, in particular in situations where you can't seek.
This restarts decoding from the middle of the packet stream; since it
discards the packet buffer intentionally, and the decoder will typically
not output "incomplete" frames until it has recovered, it can skip a
large amount of data.
It doesn't clear the byte stream cache - I'm not sure if it should.
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.