demux_mkv: allow up to 256 MB of extradata to make broken files work

What the flying fuck?

Unfortunately, these are already in the wild.

CC: @mpv-player/stable
ebml: warn if there are too many subelements

Seems like a good idea.
video: rename VOCTRL_GET_WINDOW_SIZE

Make it clear that this accesses the un-fullscreened window size.
build: handle insane libavcodec API bullshit

The oldest supported FFmpeg release doesn't provide
av_vdpau_alloc_context(). With these versions, the application has no
other choice than to hard code the size of AVVDPAUContext. (On the other
hand, there's av_alloc_vdpaucontext(), which does the same thing, but is
FFmpeg specific - not sure if it was available early enough, so I'm not
touching it.)

Newer FFmpeg and Libav releases require you to call this function, for
ABI compatibility reasons. It's the typcal lakc of foresight that make
FFmpeg APIs terrible. mpv successfully pretended that this crap didn't
exist (ABI compat. is near impossible to reach anyway) - but it appears
newer developments in Libav change the function from initializing the
struct with all-zeros to something else, and mpv vdpau decoding would
stop working as soon as this new work is relewased.

So, add a configure test (sigh).

CC: @mpv-player/stable
cosmetics: remove a stray ';'
audio: fix obscure audio resync failure with timelines

Somehow, there was a larger misunderstanding in the code: ao_buffer
does not need to be preserved over audio reinit for proper support of
gapless audio. The actual AO internal buffer takes care of this.

In fact, preserving ao_buffer just breaks audio resync. In the ordered
chapter case, end_pts is used, which means not all audio data in the
buffer is played, thus some data is left over when audio decoding
resumes on the next segment. This triggers some code that aborts resync
if there's "audio decoded" (ao_buffer contains something), but no PTS
is known (nothing was actually decoded yet).

Simplify, and always bind the output buffer to the decoder.

CC: @mpv-player/stable (maybe)
audio: make buffer size configurable

Really only for testing.
malloc+memset(0) to calloc

Signed-off-by: wm4 <wm4@nowhere>
manpage: fix sub_add description

It is in fact selected. The manpage wasn't updated when this was
changed.
audio: fix random crashes on uninit

I added this non-sense earlier this day. Oops.
win32: add tmpfile() replacement

The Windows version of tmpfile is actually pretty broken. It tries to
create the file in the root directory of the current drive, which means
on Vista and up, it normally fails due to insufficient permissions.
Replace it with a version that uses GetTempPath.

Also remove the Windows-specific note about automatic deletion of the
cache file. FILE_FLAG_DELETE_ON_CLOSE is available in NT, and it should
be pretty reliable.
player: check for null in resume config search

Signed-off-by: wm4 <wm4@nowhere>

CC: @mpv-player/stable
audio: correctly initialize output buffer

Just like the previous commit, this takes care of fallout from commit
7ab228, which fixed a bug, but introduced some new ones.

CC: @mpv-player/stable
af_hrtf: cosmetics: reindent misaligned code block
af_hrtf: request required samplerate, instead of erroring out

It seems hrtf works in 48khz only - and if that wasn't the input, the
filter just exited with an error. Make it request the 48khz instead. The
player will insert a resampling filter.

Not sure why it wasn't done like this in the first place.
vo_sdl: fix typo
audio/out: make EOF handling properly event-based

With --gapless-audio=no, changing from one file to the next apparently
made it hang, until the player was woken up by unrelated events like
input. The reason was that the AO doesn't notify the player of EOF
properly. the played was querying ao_eof_reached(), and then just went
to sleep, without anything waking it up.

Make it event-based: the AO wakes up the playloop if the EOF state
changes.

We could have fixed this in a simpler way by synchronously draining the
AO in these cases. But I think proper event handling is preferable.

Fixes: #1069
CC: @mpv-player/stable (perhaps)
sub: fix possible deadlock with --no-sub-ass and similar

This is a deadlock caused by a lock order issue: sub/osd.c locks the OSD
first, then the subtitle decoder lock. player/sub.c does the reverse.

Fix this by discussing away the requirement for locking (see below),
which allows us to drop the broken sub lock. sub_get_text() still
acquires and releases the sub decoder lock, but it's not held at the
same time as the OSD lock anymore, so it should be fine.

Originally, the sub lock was acquired because sub_get_text() returns a
pointer to a mutable string. We simply declare that it's ok to call it
unlocked, as long as only 1 thread accesses it, which works out fine in
this case.
audio/out: remove old things

Remove the unnecessary indirection through ao fields.

Also fix the inverted result of AOCONTROL_HAS_TEMP_VOLUME. Hopefully the
change is equivalent. But actually, it looks like the old code did it
wrong.
mplayer-input.conf: fix broken binding

"#" starts a comment, so the # key needs to be handled specially.
MPlayer has the same issue, but its input.conf is wrong. Or at least I
think it's wrong; looking at the MPlayer code it's doubtful they somehow
special-case and handle this.