player: don't use OSD message stack for term OSD subs

Showing subtitles on terminal used the OSD message stack (which uses a
stack to "pile up" messages that were displayed at the same time). This
had a bunch of weird and annoying consequences. This accessed a certain
osd_state field, which is a minor annoyance since I want to make that
struct opaque. Implement this differently.
player: remove OSD stack

If certain OSD messages were displayed at the same time, the hidden
messages were put on the stack, and displayed again once the higher
priority messages disappeared. The idea was probably that lower priority
messages could not hide higher priority ones, and also that the lower
messages did not get lost.

But in practice, this gives confusing results with OSD messages randomly
reappearing for a brief time. Remove it.
player: remove OSD message IDs

These were needed before the last commit, but now they don't do anything
anymore. (They were used to decide whether to replace or stack the
previous OSD message when a new one was displayed.)
sub: uglify sub decoder with locking

The plan is to make the whole OSD thread-safe, and we start with this.

We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.

There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.

To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().

One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
sub: uglify OSD code path with locking

Do two things:
1. add locking to struct osd_state
2. make struct osd_state opaque

While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses
lots of osd_state (and osd_object) members. To make sure everything is
accessed synchronously, I prefer making osd_state opaque, even if it
means adding pretty dumb accessors.

All of this is meant to allow running VO in their own threads.
Eventually, VOs will request OSD on their own, which means osd_state
will be accessed from foreign threads.
osd: fix dvdnav highlights

Broken by previous commit.
mkv.desktop: add two more mime types

Stolen from github issue #484. No idea whether they're needed.
player: prevent null pointer deref on uninit after -V

Caused by the OSD changes. Fixes #490.
mpv.desktop: add some more mimetypes

Again from github issue #484.

Also, sorry for the typo in the earlier commit message.
vcd_read: Fix sizeof argument.

The struct we need to copy is actually a cdrom_msf0, not cdrom_msf.
Even though the kernel for no good reason reads it in as a
cdrom_msf struct, but only uses the part shared with cdrom_msf0 -
this is probably a kernel bug.

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36622 b3059339-0415-0410-9bf9-f77b7e298cf2
cookies.c: cols must (and does) have 7 elements.

Doesn't affect the generated code, but avoids confusion
in both humans and newer Coverity versions.

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36623 b3059339-0415-0410-9bf9-f77b7e298cf2
w32: use the w32_common keymap in terminal-win too
af: fixed out-of-bounds accesses caused by NUM_FMT and co.

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

This merges pull request #496. The problem was that at least the
initialization of the distance[] array accessed af_fmtstr_table[]
entries that were out of bounds. Small cosmetic changes applied to
the original pull request.
demux_playlist: handle stream_read_line() errors

As of this commit, stream_read_line() can't actually error (except in
the case the passed in buffer is 0, which never happens here). This
commit is preparation for the following commit, which checks harder
whether the read data is actually text. Before this commit, an error
was treated as end-of-file, but the data read so far was considered
valid.
stream: redo stream_read_line()

This simplifies the implementation and should make it more robust. For
example, we return an error if a line is longer than the provided buffer
(instead of splitting the line).

The code is much shorter, because now finding the new line and reading
characters is done in one go.
stream: treat embedded 0 bytes as error in stream_read_line

Text files should never contain these.
stream: print stream_read_line warnings by default

This is probably ok. Probing could hit this case very often, since it'll
mean running this function on potentially binary data, but on the other
hand, probing usually uses a memory stream (to limit the amount of data
read), and memory streams have s->log silenced (details see
open_memory_stream()).
demux_playlist: move parser for plaintext playlists

This was implemented in playlist_parser.c. To make it use the improved
implementation of stream_read_line(), move it to demux_playlist.c.
manpage: fix af_equalizer syntax

This doesn't need quoting, for some reason.
cocoa: sort files opened from Finder the same way Finder does

Fixes #497