input: don't autorepeat cycle_values command

Not sure why this was originally added as autorepeated. It makes no
sense, because switching between choices should never autorepeat. (For
the normal "add"/"cycle" commands, autorepeat is usually enabled, but
command.c tries to disable it specifically for choice properties.)
player: fix idle mode event handling

Idle mode went to sleep too early, e.g. just pressing "ESC" did nothing,
until the next event happened. This was because it directly went to
sleep after processing commands. What we should do instead is rechecking
all state after processing commands, redraw OSD, and then go to sleep.
This also fixes some strange OSD-related behavior.

Also move some other code around to separate idle mode initialization
from the normal run loop.
m_config: fix theoretic undefined behavior

The memcpy() is actually not enough: the types are incompatible, and no
memcpy, union, etc. will change that. (Although no real compiler will
ever break this.) Attempt to make this theoretically correct by actually
using a struct pointer. It's not the same struct type, but supposedly
it's ok, because all struct pointers always have the same size and
representation in standard C.
options: add M_OPT_FILE flag to mark options that want a file(list)
TOOLS/zsh.pl: complete options that take file names
input: "quit_watch_later" and "stop" are abort commands

This means they get special handling for asynchronously aborting
playback, even if the player is "stuck".

Also document "stop". It seems somewhat useful for client API users
(although that will be implemented properly only in the following
commits.)
stream: redo playback abort handling

This mechanism originates from MPlayer's way of dealing with blocking
network, but it's still useful. On opening and closing, mpv waits for
network synchronously, and also some obscure commands and use-cases can
lead to such blocking. In these situations, the stream is asynchronously
forced to stop by "interrupting" it.

The old design interrupting I/O was a bit broken: polling with a
callback, instead of actively interrupting it. Change the direction of
this. There is no callback anymore, and the player calls
mp_cancel_trigger() to force the stream to return.

libavformat (via stream_lavf.c) has the old broken design, and fixing it
would require fixing libavformat, which won't happen so quickly. So we
have to keep that part. But everything above the stream layer is
prepared for a better design, and more sophisticated methods than
mp_cancel_test() could be easily introduced.

There's still one problem: commands are still run in the central
playback loop, which we assume can block on I/O in the worst case.
That's not a problem yet, because we simply mark some commands as being
able to stop playback of the current file ("quit" etc.), so input.c
could abort playback as soon as such a command is queued. But there are
also commands abort playback only conditionally, and the logic for that
is in the playback core and thus "unreachable". For example,
"playlist_next" aborts playback only if there's a next file. We don't
want it to always abort playback.

As a quite ugly hack, abort playback only if at least 2 abort commands
are queued - this pretty much happens only if the core is frozen and
doesn't react to input.
input: distinguish playlist navigation and quit commands for abort

Refine the ugly hack from the previous commit, and let the "quit"
command and some others abort playback immediately. For
playlist_next/playlist_prev, still use the old hack, because we can't
know if they would stop playback or not.
client API: use playback abort mechanism

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).
stream: fix build with emulated atomics

This code was legal with C11 atomics, but it fails with our
compatibility wrapper.
input: fix nested commands

Regression from today.
player: shorten skip heuristic for playlist_prev to 1 second

See issue #1084.
x11: remove unused function
input: use libwaio for pipe input on Windows

Use libwaio to read from pipes (stdin or named pipes) on Windows. This
liberates us from nasty issues, such as pipes (as created by most
programs) not being possible to read in a non-blocking or event-driven
way. Although it would be possible to do that in a somewhat sane way
on Vista+, it's still not easy, and on XP it's especially hard. libwaio
handles these things for us.

Move pipe.c to pipe-unix.c, and remove Windows specific things. Also
adjust the input.c code to make this work cleanly.
sanitizer: avoid divide-by-zero instances

Merges pull request #1094, with some minor changes. mpv expects IEEE,
and IEEE allows divisions by 0 for floats, so these shouldn't actually
be a problem, but do it anyway for the sake of clang.

Signed-off-by: wm4 <wm4@nowhere>
img_convert: sanitizer: avoid invalid left-shifts

(a << 24) is not in the valid int range when a is 255, so use an
unsigned instead.

Signed-off-by: wm4 <wm4@nowhere>
manpage: clarify description of dwidth/dheight
DOCS/client_api_examples: qtexample: resize to video size

This is pretty imperfect, but it's just a demo.

The main purpose is clarifying how and when to get the video size.

In theory, retrieving the properties this way has a race condition:
after reading dwidth, the video could resize again. But the worst that
can happen are mismatching dwidth/dheight values, and the
MPV_EVENT_VIDEO_RECONFIG event would be immediately received again,
which would fix the mismatch. You could read the full video-out-params
property to absolutely avoid it, but it's not worth the trouble.
x11: if the WM supports _NET_FRAME_EXTENTS, don't wait for map

Some window managers can prevent mapping of a window as a feature. i3
can put new windows on a certain workspace (with "assign"), so if mpv is
started on a different workspace, the window will never be mapped.

mpv currently waits until the window is mapped (blocking almost all of
the player), in order to avoid race conditions regarding the window
size. We don't want to remove this, but on the other hand we also don't
want to block the player forever in these situations.

So what we need is a way to know when the window manager is "done" with
processing the map request. Unfortunately, there doesn't seem to be a
standard way for this. So, instead we could do some arbitrary
communication with the WM, that may act as "barrier" after map request
and the "immediate" mapping of the window. If the window is not mapped
after this barrier, it means the window manager decided to delay the
mapping indefinitely. Use the _NET_REQUEST_FRAME_EXTENTS message as such
a barrier. WMs supporting this message must set the _NET_FRAME_EXTENTS
property on the mpv window, and we receive a PropertyNotify event. If
that happens, we always continue and cancel waiting for the MapNotify
event.

I don't know if this is sane or if there's a better mechanism. Also,
this works only for WMs which support this message, which are not many.
But at least it appears to work on i3. It may reintroduce flickering on
fullscreen with other WMs, though.
ao_oss: fix incorrect comments using bytes instead of samples

MPlayer uses bytes, mpv uses sample counts in the AO API.