core/cfg-mplayer: fix segfault when using DVD subs

The option sub-forced-only was accidentally renamed back to
forcedsubsonly in commit 72205635abe7, causing a segfault in
mp_property_generic_option due to missing option.
stream_dvd: add a stream_seek() call

This fixes use of -chapter together with -correct-pts and demux_lavf and
stream_dvd.
sub: use ffmpeg decoder for DVD subs

Do this only if demux_lavf is used. Using demux_mpg and the ffmpeg DVD
subtitle decoder doesn't work. The problem is probably that demux_mpg
doesn't join split sub packets, while demux_lavf does. The internal
DVD sub decoder (spudec.c) can, while ffmpeg's dvdsub can't. I do not
know whether this is the actual problem.

If DVD playback is used, create "fake" vobsub-style text extradata
(like .idx files) to pass resolution and palette information to the
ffmpeg decoder. We could use the "palette" AVOpt and avcodec_set_dimensions()
instead, but it's actually simpler this way. Note that the decoder
doesn't parse any other fields. Also note that DVD playback still uses
demux_mpg by default, so this code is inactive unless -demuxer lavf is
specified. This is mainly preparation for the case when we manage to get
rid of demux_mpg for DVD playback.
core: improve seeking in external files

This affects streams loaded with -subfile and -audiofile. They could get
out of sync when they were deselected, and the main file was seeked. Add
code to seek external files when they are selected (see
init_demux_stream()).

Use avformat_seek_file() under certain circumstances. Both av_seek_frame()
("old" API) and avformat_seek_file() ("new" API) seem to be broken with
some formats. At least the vobsub demuxer doesn't implement the old API
(and the old API doesn't fallback to the new API), while the fallback
from new API to old API gives bad results. For example, seeking forward
with small step sizes seems to fail with the new API (tested with
Matroska by trying to seek 1 second forward relative to priv->last_pts).
Since only subtitle demuxers implement the new API anyway, checking
whether iformat->read_seek2 is set to test whether the old API is not
supported gives best results. This is a hack at best, but makes things
work.

Remove backwards seeking on seek failure. This was annoying, and only
was there to compensate for obscure corner cases (see 1ad332). In
particular, files with completely broken seeking that used to skip back
to the start on every seek request may now terminate playback.
sub: remove vobsub reader in favor of ffmpeg vobsub demuxer

ffmpeg recently added a demuxer that can read vobsubs (pairs of .sub and
.idx files). Get rid of the internal vobsub reader, and use the ffmpeg
demuxer instead.

Sneak in an unrelated manpage change (autosub default).
stream: handle mms streaming with ffmpeg

Use ffmpeg (stream_lavf) instead of internal mms support (asf_streaming.c)
for mms://, mmsh://, mmst:// URLs.

The old implementation is available under mp_mms:// etc.

There are some caveats with this:
- mms:// now always maps to mmsh://. It won't try mmst://. (I'm not sure
  if mms:// URLs really can use the mmst protocol, though.)
- MMS streams under the http:// prefix are not handled. (ffmpeg ticket
  #2001.) (Was already broken in mpv since c02f25.)
- It downloads all video streams now. MMS streams often have redundant
  video streams, which encode the main stream at different quality. The
  client is supposed to select one according to its bandwidth
  requirements. (Explicit MMS stream selection has been broken in mpv
  for a while, because MPOpts.vid maps to the stream number, not the
  demuxer's stream ID - but the old logic doesn't work anyway when
  using demuxer_lavf as opposed to demux_asf.)
configure: remove --disable-sortsub

Apparently this was for debugging. There was a patch to remove it years
ago, but it has been forgotten.
demux_lavf: make minimum probe score customizable, remove lavf_preferred

libavformat wants to read a full ~400KB of data to determine whether
it's really AAC. This causes slow startup with AAC web radio streams [1]
(possible due to a broken initial packet). There are similar issues
with other file formats.

Make the probe "score" (libavformat's mechanism for testing file
formats) configurable with the -lavfdtops:probescore option. This allows
lowering the amount of data read on probing. If the probe score is below
the probescore option value, demux_lavf will try to get a higher score
by feeding more data to libavformat, until the required score or the
max. probe size is reached.

Remove the lavf_preferred demuxer entry. This had a purpose in
mplayer-svn, but now there doesn't seem to be any good reason for it
to exist. Make sure that our native "good" demuxers are above
demux_lavf in demuxer_list[] instead (so that they are preferred).

[1] http://lr2mp0.latvijasradio.lv:8000
stream_lavf/demux_lavf: export/use HTTP MIME type

This is a fix for web radio streams that send raw AAC [1]. libavformat's
AAC demuxer probe is picky enough to request hundreds of KBs data, which
makes for a slow startup. To speed up stream startup, try use the HTTP
MIME type to identify the format. The webstream in question sends an AAC
specific MIME type, for which demux_lavf will force the AAC demuxer,
without probing anything.

ffmpeg/ffplay do the same thing. Note that as of ffmpeg commit 76d851b,
av_probe_input_buffer() does the mapping from MIME type to demuxer. The
actual mapping is not publicly accessible, and can only be used by
calling that function. This will hopefully be rectified, and ideally
ffmpeg would provide a function like find_demuxer_from_mime_type().

[1] http://lr2mp0.latvijasradio.lv:8000
mplayer: make --length work if --start is missing

In this case, --start should default to 0 obviously.
windows support: fix compilation with pthreads

This caused errors like:

    core/mplayer.c:4308:5: error: implicit declaration of function 'pthread_win32_thread_detach_np' [-Werror=implicit-function-declaration]

It turns out a pthread.h include was missing. It's not clear why this
used to work (or rather, why it happens only sometimes). Possibly some
libraries or system headers recursively include pthread.h under certain
circumstances or configurations.

Fix missing quoting in configure, which led to broken terminal output.

Closes #6.
audio/decode: remove ad_pcm and use ad_lavc for PCM

Since libavcodec doesn't have a "generic" PCM decoder, we have to go out
of out way to make it look like ad_lavc provides one: make it provide a
pseudo "pcm" decoder, which maps some format tags manually to the
individual libavcodec PCM decoders.

Format tags which uniquely map to one libavcodec could be mapped via
codecs.conf. Since defining these in tag_map[] is much shorter (one line
vs. a full codec entry in codecs.conf), and since we need tag_map[]
anyway, we don't use codecs.conf for these.

ad_pcm is evil because it still does partial packet reads (with
demux_read_data()), and it's redundant to libavcodec anyway.
audio/decode: remove ad_dvdpcm and use ad_lavc for DVD PCM

ad_dvdpcm reads MPEG specific headers directly (passed through codecdata
by demux_mpg), so you couldn't use ffmpeg's "pcm_dvd" with demux_mpg.
Change demux_mpg to set the correct audio parameters directly. The code
for this is taken from ad_dvdpcm.

ad_dvdpcm is evil because it still does partial packet reads (with
demux_read_data()), and it's redundant to libavcodec anyway.
audio: remove support for native alaw/mulaw/adpcm output

This is considered a worthless feature. Note that alaw/mulaw/adpcm input
is unaffected: such data is handed to libavcodec and "decoded" to linear
PCM.
core: allow disabling display of "album art" in audio files

ffmpeg pretends that image attachments (such as contained in ID3v2
metadata) are video streams. It injects the attached pictures as packets
into the packet stream received with av_read_frame().

Add the --audio-display option to allow configuring whether attached
pictures should be displayed. The default behavior doesn't change
(images are displayed).

Identify video streams, that are actually image attachments, with "[P]"
in the terminal output.

Modify the default stream selection such that real video streams are
preferred over attached pictures. (This is just for robustness; I do not
know of any samples where images are added before actual video streams
and could lead to bad default stream selection with the old code.)
demux: fix behavior with files that have sparse video packets

Improve EOF handling in ds_fill_buffer for the case where one stream ends
much earlier than the others, in particular make sure the "too many ..."
message is not printed over and over.

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@32823 b3059339-0415-0410-9bf9-f77b7e298cf2

Conflicts:
	libmpdemux/demuxer.c

Try to improve seeking in files with only few video packets,
in particular files with cover art.

This might cause issues with badly interleaved files, particularly
together with -audio-delay, even though I did not see issues
in my very limited testing.

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35486 b3059339-0415-0410-9bf9-f77b7e298cf2

Conflicts:
	libmpdemux/demuxer.c
	libmpdemux/demuxer.h

Fix code that detects streams temporarily lacking data to work
properly with e.g. DVDs.

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35499 b3059339-0415-0410-9bf9-f77b7e298cf2

Conflicts:
	libmpdemux/demuxer.c

Make stream eof detection less sensitive.

Fixes bug #2111.

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35543 b3059339-0415-0410-9bf9-f77b7e298cf2

Conflicts:
	libmpdemux/demuxer.c
mplayer: prefer audio PTS over video PTS for status line

This slightly improves display of the current playback time in files
with sparse video packets (like video tracks containing a slow MJPG
slideshows as in [1]), or audio files with cover art image attachments.
While the video PTS is always "stuck" at the last frame displayed or
the last seek, audio is usually continuous. Given sane samplerates and
working audio drivers (to query how much of the current audio buffer has
been played), the audio PTS should always be more reliable.

[1] http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/rtpodcast/Rooster_Teeth_Podcast_191.m4a
manpage: mark HTTP related options as deprecated/broken

Commit c02f25 switched the "http://" protocol to use ffmpeg's HTTP
implementation (stream_lavf.c), instead of the mplayer internal one
(http.c). Unfortunately, it turns out that there are some network
related options that are not respected by stream_lavf.c, and
consequently do not work anymore for "http://" URLs. This might be
fixed later. Mark them as deprecated for now, as it might take
arbitrarily long until this is taken care of.
sub: add --ass-style-override=force option

This allows overriding native ASS script subtitle styles with user
provided overrides. This is disabled by default, and needs explicit
configuration by the user.

Requires the branch style_overrides from https://github.com/wm4/libass.git
The functionality is silently disabled if the libass used to compile
mpv doesn't include the patch.

Example for ~/.mpv/config:

ass-force-style="*Fontname=Whatever Font,*Fontsize=55,*Primarycolour=&H00EEFFFF
,*Secondarycolour=&H00FEEFFF,*Outlinecolour=&H00FF00FF,*Backcolour=&HC0000000,*O
utline=2,*BorderStyle=1,*Shadow=2,ScaledBorderAndShadow=1"

(This is just an example, and probably something extremely ugly.)

Some other style options can be overridden as well, but not all. The
script-resolution dependent attributes like Fontsize are scaled to
PlayResY=720, rather than the actual script resolution.

Should be in ~/.mpv/input.conf, because overriding can easily break:

KEY cycle ass-style-override

Note: ASS should be considered a vector format rather than a subtitle
format. There is no easy or reliable way to determine whether the style
of a given subtitle event can be changed without destroying visuals or
not. This patch relies on a simple heuristic, which often works and
often breaks.
sub: set PlayResY=720 for text subs

Why? When specifying a font size with *Fontsize in ass-force-style,
this font size should be always the same, regardless whether SRT or
ASS subs (with override) are used. Since the override code in libass
assumes a vertical resolution of 720, do the same on the mpv side when
rendering SRT with libass. 720 is an arbitrary value, but both sides
have to use the same for consistency.