sd_lavc: remove ineffective code

It makes no sense to set the packet duration, because libavcodec doesn't
know the timebase. And in fact, no subtitle decoder accesses the packet
duration, except text subtitle converters, which are not relevant here.
So this code did nothing - drop it.

Also fix a blatantly incorrect comment.
demux: avoid unnecessary wakeups

If a packet is appended to a stream, and there were already packets
queued, nothing about the state changed, as far as the user (i.e. the
player) is concerned. Thus no wakeup is needed.

The pthread_cond_signal() call following this is not interesting - it
will simply be a NOP if there are actually no waiters.
win32: correct HANDLE type

The correct type is HANDLE, not HANDLE*, though this change shouldn't
affect functionality.
win32: correct SGR sequence handling

This should get colour working again on the Windows console.

Fixes #1032.
demux: always use AVPacket

This is a simplification, because it lets us use the AVPacket
functions, instead of handling the details manually.

It also allows the libavcodec rawvideo decoder to use reference
counting, so it doesn't have to memcpy() the full image data. The change
in av_common.c enables this.

This change is somewhat risky, because we rely on the following AVPacket
implementation details and assumptions:
- av_packet_ref() doesn't access the input padding, and just copies the
  data. By the API, AVPacket is always padded, and we violate this. The
  lavc implementation would have to go out of its way to make this a
  real problem, though.
- We hope that the way we make the AVPacket refcountable in av_common.c
  is actually supported API-usage. It's hard to tell whether it is.

Of course we still use our own "old" demux_packet struct, just so that
libav* API usage is somewhat isolated.
vo_opengl: don't cut off feature list output
input: change verbosity of some message levels

For --input-test, print messages on terminal by default.

Raise message level for enabling input sections, because the OSC makes
this very extremely annoying.
options: compatibility hack for --slave-broken

Seems some programs were still relying on it. Whatever, it's not hard to
support.

CC: @mpv-player/stable
command: change OSD formatting of "speed" property

The "x   " prefix annoyed some users.
msg: allow duplicating a mp_log

Trivial; this is mostly just reindenting the normal codepath.
input: redo how --input-file is handled

Abandon the "old" infrastructure for --input-file (mp_input_add_fd(),
select() loop, non-blocking reads). Replace it with something that
starts a reader thread, using blocking input.

This is for the sake of Windows. Windows is a truly insane operating
system, and there's not even a way to read a pipe in a non-blocking
way, or to wait for new input in an interruptible way (like with
poll()). And unfortunately, some want to use pipe to send input to
mpv. There are probably (slightly) better IPC mechanisms available
on Windows, but for the sake of platform uniformity, make this work
again for now.

On Vista+, CancelIoEx() could probably be used. But there's no way on
XP. Also, that function doesn't work on wine, making development
harder. We could forcibly terminate the thread, which might work, but
is unsafe. So what we do is starting a thread, and if we don't want
the pipe input anymore, we just abandon the thread. The thread might
remain blocked forever, but if we exit the process, the kernel will
forcibly kill it. On Unix, just use poll() to handle this.

Unfortunately the code is pretty crappy, but it's ok, because it's late
and I wanted to stop working on this an hour ago.

Tested on wine; might not work on a real Windows.
coreaudio_device: fix overwriting of user input

Fixes #1030
player: minor changes

This shouldn't change anything functionally.

Change the A/V desync message. --framedrop is enabled by default now, so
the text must be changed a little. I've never heard of audio outputs
messing up A/V sync recently, so remove that part.

Remove the unused ao_pts field.

Reorder 2 A/V sync related expressions so that they look the same.
input: stdin is 0, not 1

Oops. I can never remember this right.
manpage: mention that mp.commandv doesn't expand properties

The little lua snippet at #488 as well as the actual implementation
seems to indicate that not expanding properties is indeed the correct
behavior.  Document that.

Signed-off-by: wm4 <wm4@nowhere>
input: make all modifier flags unsigned
input: make key bindings like "Shift+X" work (for ASCII)

"Shift+X" didn't actually map any key, as opposed to "Shift+x". This is
because shift usually changes the case of a character, so a plain
printable character like "X" simply can never be combined with shift.

But this is not very intuitive. Always remove the shift code from
printable characters. Also, for ASCII, actually apply the case mapping
to uppercase characters if combined with shift. Doing this for unicode
in general would be nice, but that would require lookup tables. In
general, we don't know anyway what character a key produces when
combined with shift - it could be anything, and depends on the keyboard
layout.
player: fix weird behavior when framestepping over format changes

When video format changes, the frame before the frame with the new
format sets video_status briefly to STATUS_DRAINING. This caused the
code to handle the EOF case to kick in, which just pauses the player
when trying to step past the last frame. As a result, trying to
framestep over format changes resulted in pausing the player.

Fix by testing against the correct status.
TOOLS: youtube wrapper: allow overriding mpv binary
vo_opengl: add spline64 filter kernel

The coefficients are taken from fmtconv plugin for vapoursynth:
https://github.com/vapoursynth/fmtconv/blob/master/src/fmtc/ContFirSpline64.cpp

The package is licensed under WTFPL, and it's from the same author
of Dither plugin for avisynth.