demux_mkv: never force output sample rate

Matroska has an output sample rate (OutputSamplingFrequency), which in
theory should be forced instead of whatever the decoder outputs. But it
appears no software (other than mplayer2 and mpv until now) actually
respects this. Even worse, there were broken files around, which played
correctly with (in theory) broken software, but not mplayer2/mpv. Hacks
were added to our code to play these files correctly, but they didn't
catch all cases.

Simplify this by doing what everyone else does, and always use the
decoder's sample rate instead. In particular, we try to handle all
sample rate issues like libavformat's Matroska demuxer does.
demux_mkv: ignore DefaultDuration in some cases

This fixes playback of the sample linked by FFmpeg ticket 2508. The fix
follows ffmpeg commit 6158a3b (although it's not exactly the same).

The problem here is that the file contains an apparently non-sense
DefaultDuration value. DefaultDuration for audio tracks is used to
derive PTS values for packets with no timestamps, like they can happen
with frames inside a laced block. So the first packet of a SimpleBlock
will have a correct PTS, while the PTS values of the following packets
are calculated using DefaultDuration, and thus are broken.

This leads to seemingly ok playback, but broken A/V sync. Not using the
DefaultDuration value will leave the PTS values of these packets unset,
and the audio decoder can derive them from the output instead.

The fix more or less uses a heuristic to detect the broken case: if the
sample rate is 8 KHz (Matroska default, can assume unset), and the codec
is AC3 (as the broken file did), don't use it. I'm not sure why this
should be done only for AC3, maybe the muxing application (mkvmerge
v4.9.1) has known issues with AC3. AC3 also doesn't support 8 KHz as
sample rate natively.

(By the way, I'm not sure why we should honor the DefaultDuration at all
for audio. It doesn't seem to be needed. You can't seek to these frames,
and decoders should always be able to produce perfect PTS values by
adding the duration of the decoded audio to the first PTS.)
sd_ass: fix font aspect ratio with non-ASS subs

For subtitles that were not ASS, the subtitle font aspect was always set
to that of the video, the exact opposite of how it was supposed to
behave.
sd_lavc: don't stretch DVD subtitles to video aspect

I'm not sure what's correct: stretching the DVD subtitles from storage
aspect ratio to video display aspect ratio, or displaying subtitles
using 1:1 PAR. Until now, DVD subtitles (as well as all other bitmap
subtitles) were always stretched to the video. There are good arguments
why this would be the correct behavior: DVDs were made for playback on
TV, which display anamorphic video by adjusting the horizontal refresh
rate, and thus wouldn't even be capable of DVD subtitles with square PAR
(other than resampling the subtitles additionally).

However, I haven't seen a sample yet where subtitles do _not_ look
stretched using this method. Rendering them at 1:1 PAR looks better.
Technically, we render them at display PAR (and not 1:1 PAR). Do this in
a way so that the subtitle area is always inside of the video frame if
display and video aspect ratios mismatch.

For DVB subtitles, the old method looks more correct, so this is special
cased to DVD subtitles.

I might revert this commit if it turns out that it's an disimprovement.
core: move video refresh function to mplayer.c
video: redo how colorspaces are handled

Instead of handling colorspaces with VFCTRLs/VOCTRLs, make them part of
the normal video format negotiation. The colorspace is passed down like
other video params with config/reconfig calls.

Forcing colorspaces (via the --colormatrix options and properties) is
handled differently too: if it's changed, completely reinit the video
chain. This is slower and requires a precise seek to the same position
to perform an update, but it's simpler and less bug-prone. Considering
switching the colorspace at runtime by user-interaction is a rather
obscure feature, this is a good change.

The colorspace VFCTRLs and VOCTRLs are still kept. The VOs rely on it,
and would have to be changed to get rid of them. We'll do that later,
and convert them incrementally instead of in one go.

Note that controlling the output range now always works on VO level.
Basically, this means you can't get vf_scale to output full-range YUV
for whatever reason. If that is really wanted, it should be a vf_scale
option. the previous behavior didn't make too much sense anyway.

This commit fixes a few bugs (such as playing RGB video and converting
that to YUV with vf_scale - a recent commit broke this and forced the
VO to display YUV as RGB if possible), and might introduce some new
ones.
Use /dev/cd0 as default cdrom device on FreeBSD
vo_x11: remove weird inactive code

I guess this code was supposed to handle cases like drawing RGBA as ARGB
by offsetting it by 1 byte.

The code didn't make any sense, though. It used to make sense before mpv
switched internal pixel formats from FourCCs to a simple enum. With the
FourCCs, "fmt | 128" selected the big endian version of a format. Of
course this doesn't work this way with the new pixel formats. It just so
happens that there are no formats with whose values match
IMGFMT_RGB32|128 or IMGFMT_BGR32|128, so this code was inactive.

All involved pixel formats seem to play fine on my setup (though it's
little endian only), and the code strictly matches the mpv pixel formats
against the format of the X image, so I'm not quite sure why this code
was there in the first place.

The original commit that added this was b333ae1 (svn 21602):
  Support for different endianness on client and server with -vo x11
vf_scale: uncrustify
vf_scale: don't byte-swap palette on big endian architectures

ffmpeg's and the internal palette format used to have different
endianess, but that is not the case anymore. This code was forgotten
when that change was made.
vf_scale: try to support all pixel formats

Until now, vf_scale only tried formats listed in the outfmt_list array.
Extend this and try every pixel format supported by mpv if trying
outfmt_list doesn't lead to success.

Also add some checks whether swscale really supports a given input or
output format. This was implicitly done with outfmt_list before.
vf_scale: remove rounding of sizes to 2 with 4:2:0

libswscale doesn't seem to require this (anymore?), and libavfiltert's
vf_scale doesn't do it either. Moreover, this wasn't done for most other
subsampled formats, not even very old ones. So just remove it.

(It'd be quite easy to align on chroma boundaries with all pixel
formats, though.)
sws_utils: refactor swscale wrapper code

This splits the monolithic mp_image_swscale() function into a bunch of
functions and a context struct. This means it's possible to set
arbitrary parameters (e.g. even obscure ones without getting in the
way), and you don't have to create the context on every call.

This code is preparation for removing duplicated libswscale API usage
from other parts of the code.
vf: make sure less important image params are set before/after filters

Image parameters like colorspace, color levels, and chroma location are
generally less important, and many filters don't set them correctly.
Force them instead in the generic VF code, which is probably better and
more convenient over all. So we designate this is a proper solution,
instead of a dirty hack.
vf_scale: use new swscale wrapper
mp_image: one utility function to set image parameters
vo_x11: use new swscale wrapper
sws_utils: remove some old code
sws_utils: don't recursively include libswscale header

Add libswscale includes where they are actually needed instead.
sws_utils: make hq swscale flags available with mp_sws_hq_flags

No need to duplicate this on the call-site.