Commit 87c13de6 added a fallback to video resolution if the subtitle
resolution is unknown. Apparently this fixed some broken files with
vobsubs.
This broke some DVB subtitles. Apparently .ts captures with 1920x1080
video resolution and 720x576 subtitles do exist. The sample at hand had
some streams with 720x576 resolution and no sub resolution set, and some
streams with 1920x1080 resolution and sub resolution set (both against
the same 1920x1080 video). My conclusion is that 720x576 is the only
reasonable fallback for DVB (but I can't be sure).
The fallback is removed for PGS too. I don't know about the PGS case; it
seems the sub resolution must always be set, so it shouldn't matter.
Fixes#1425.
This is only needed for switching video track with `_`, since Cocoa
automatically handles cleaning up the application's presentation options when
quitting the process.
Fixes#1399
Ever since someone (not me) added some Matroska features which nobody
ever uses (ordered edition or some bullshit), I haven't had a fucking
clue what the fuck is going on in this fucking file. (Still agreed to
it, so it's my fault.)
mplayer2 handled missing chapters correctly (and I suppose in a somewhat
clean/simple manner), but the changed code doesn't. Since I can't even
follow this code because it's so arcanely complicated, just add a hack
that has the same effect.
mpv does 'cascading' configs by overriding options as the config become more
important (bundle -> system level -> user level).
Unfortunately mpv also loads two sets of configs files one after the other [1].
First it looks for 'config', then for 'mpv.conf'. For this reason a mpv.conf in
ANY location will override ANY config files named config (even if the mpv.conf
is in a system path and config in a user path).
[1]: Relevant code in player/configfiles.c
load_all_cfgfiles(mpctx, section, "config");
load_all_cfgfiles(mpctx, section, "mpv.conf");
Fixes: #1361
stream_edl merely makes demux_edl act "special", which checks for the
stream type explicitly and then does something with its URL. If a cache
is added before the stream, it'll try to use the cache's URL (i.e. an
empty string), and will then obviously fail to parse the URL. While this
is slightly stupid, just disabling the entirely useless cache is the
most effective solution.
Fixes#1378.
snd_pcm_prepare() was not always called, which could result in an
infinite loop.
Whether snd_pcm_prepare() was actually called depended on whether the
device was a hw device (or other characteristics; depending on
snd_pcm_hw_params_can_pause()), and required real suspend (annoying for
testing), so it was somewhat tricky to reproduce without knowing these
things.
Most image subtitle formats implicitly terminate the current subtitle
event with the next event (e.g. a new packet read from the demuxer will
instruct the subtitle render to stop display). If the subtitle event is
just trailing, it will be displayed forever. So there's no proper way
of doing this and we just apply an heuristic to avoid annoyances.
The libavcodec PGS decoder sets end_display_time to UINT32_MAX, in an
attempt to signal unknown end time (the API does not allow to signal
this properly, and this was a backwards compatible hack).
While we have no issues with the large value, our code wants to
distinguish between known and unknown end time explicitly.
When setting the ALSA channel map, we never actually set the map we got
from ALSA directly, but convert it to mpv's, and then back to ALSA's.
mpv and ALSA use different conventions for mono, and there is already an
exception for ALSA->mpv, but not mpv->ALSA.
this currently uses a sketchy but apparently working workaround,
which will be removed once the neccessary changes in youtube-dl
are implemented
Fixes#1277
This gives better results with fancy-downscaling. The issue here is that
fancy-downscalign "extends" the filter radius by some amount, which
requires using a larger filter size and shader. Then most of the filter
is "unused", but some filters still return non-0 coefficients, which
create heavy artifacts. Just clamp them off.
I'm not sure if this is the right solution, but at least it's better
than before.
This fixes using the mpv:// custom protocol on Yosemite were apparently
we receive an url which is automatically urlencoded by the system.
/cc mpv-player/stable
Apparently, we treat different tracks as titles, so returning the number
of titles (which is user-visible as "disc-titles" property) is
completely misguided.
In theory, vo_opengl supports operation without framebuffers. But this
has been broken for a while now (commit cc00b3ff is a contender). It
crashed because it unconditionally called gl->BindFramebuffer() (which
is NULL if framebuffers are missing).
Since this function is actually only called to set the default
framebuffer, the simplest way to deal with this is to provide a dummy
function, insteas of uglifying the code with additional if branches.
wm4