Adjust wayland defines
demux_mkv: fix compiler warnings

Make TOOLS/matroska.pl output structs with fields sorted by name in
ebml_types.h to make the order of fields deterministic. Fix warnings in
demux_mkv.c caused by the first struct fields switching between scalar
and struct types due to non-deterministic ebml_types.h field order.
Since it's deterministic now, this shouldn't change anymore.

The warnings produced by the compilers are bogus, but we want to silence
them anyway, since this could make developers overlook legitimate
warnings.

What commits 7b52ba8, 6dd97cc, 4aae1ff were supposed to fix. An earlier
attempt sorted fields in the generated C source file, not the header
file. Hopefully this is the last commit concerning this issue...
playlist: rewrite PLS parser

Somehow the new parser ends up much smaller. Much of it is because we
don't parse some additional information. We just skip it, instead of
parsing it and then throwing it away.

More importantly, we use the physical order of entries, instead of
trying to sort them by entry number. Each "File" entry is followed by a
number that is supposed to be the entry number, and "File1" is first.
(Should it turn out that this is really needed, an additional field
should be added to playlist_entry, and then qsort().)
travis: Update libav stable tarball

Signed-off-by: Timothy Gu <timothygu99@gmail.com>
travis: update ffmpeg stable to 1.2.4 tarball

This is the last release in the 1.2.4 line.
vo_xv: fix compilation of SHM not available
manpage: fix incorrect default for --osc
video: make IMGFMT_RGB0 etc. exist even if libavutil doesn't support it

These formats are helpful for distinguishing surfaces with and without
alpha. Unfortunately, Libav and older version of FFmpeg don't support
them, so code will break. Fix this by treating these formats specially
on the mpv side, mapping them to RGBA on Libav, and unseting the alpha
bit in the mp_imgfmt_desc struct.
vo_opengl/vaapi: use IMGFMT_RGB0

More correct, might make things slightly faster (probably
insignificant).
vo_opengl: redo aspects of initialization, change hwdec API

Instead of checking for resolution and image format changes, always
fully reinit on any parameter change. Let init_video do all required
initializations, which simplifies things a little bit.

Change the gl_video/hardware decoding interop API slightly, so that
hwdec initialization gets the full image parameters.

Also make some cosmetic changes.
vdpau: move device and video surface management from vo_vdpau.c to vdpau.c

The goal is being able to use vdpau decoding independently from
vo_vdpau.c.
vo_opengl: support for vdpau hardware decoding

This uses vdpau OpenGL interop to convert a vdpau surface to a texture.

Note that this is a bit weak and primitive. Deinterlacing (or any other
form of vdpau postprocessing) is not supported. vo_opengl chroma scaling
and chroma sample position are not supported. Internally, the vdpau
video surfaces are converted to a RGBA surface first, because using the
video surfaces directly is too complicated. (These surfaces are always
split into separate fields, and the vo_opengl core expects progressive
frames or frames with weaved fields.)
gl_header_fixes: fix inverted condition

Could possibly leading to failing compilation on systems with headers
that miss the vdpau extension.
input: disallow autorepeat by default for most commands

This drops autorepeated key events for a number of commands. This should
help with slow situations accidentally triggering too many repeats. (I'm
not sure if this actually happened to users - maybe.)

It's not clear whether MP_CMD_COMMAND_LIST (multiple commands on one
binding separated by ';') should be repeated, or whether it should try
to do something clever. For now, disallow autorepeat with it.
input: remove unused key_down_event command

There's no real use-case for this, and is wasn't documented (didn't even
appear on the "undocumented commands" list).
vd_lavc: remove explicit crystalhd support

This removes "--hwdec=crystalhd".

I doubt anyone even tried to use this. But even if someone wants to
use it, the decoders can still be explicitly invoked with e.g.:

    --vd=lavc:h264_crystalhd

The only advantage our special code provided was fallback to
software decoding. (But I'm not sure how the ffmpeg crystalhd
pseudo-decoder actually behaves.)

Removing this will allow some simplifications as soon as we don't need
vdpau_old.c anymore.
ao_oss: make no_persistent_volume volume work when seeking
ao_oss: don't enable -softvol by default on OSSv4