Take advantage of the fact that list_devs is called with a
hotplug_inited ao. Also eliminate unnecessary nested function
abstraction of hotplug_(un)init and list_devs. However, keep list_devs
in ao_wasapi_utils.c since it uses the private functions get_device_id,
get_device_name and exposing these would require including headers for
IMMDevice in ao_wasapi_utils.h.
Create a second copy of the change_notify structure for the hotplug
ao. change_notify->is_hotplug distinguishes the hotplug version from
the regular one monitoring the currently playing ao. Also make the
change notification less verbose now that there might be two of them around.
Rarely used and essentially useless. The only VO for which this was
implemented correctly and for which this did anything was vo_xv, but you
shouldn't use vo_xv anyway (plus it support BT.601 only, plus a vendor
specific extension for BT.709, whose presence this function essentially
reported - use xvinfo instead).
Remove the colorspace-related top-level options, add them to vf_format.
They are rather obscure and not needed often, so it's better to get them
out of the way. In particular, this gets rid of the semi-complicated
logic in command.c (most of which was needed for OSD display and the
direct feedback from the VO). It removes the duplicated color-related
name mappings.
This removes the ability to write the colormatrix and related
properties. Since filters can be changed at runtime, there's no loss of
functionality, except that you can't cycle automatically through the
color constants anymore (but who needs to do this).
This also changes the type of the mp_csp_names and related variables, so
they can directly be used with OPT_CHOICE. This probably ended up a bit
awkward, for the sake of not adding a new option type which would have
used the previous format.
It was "by design" possible to make mpv crash if the parameters didn't
make enough sense, like "format=rgb24:yuv420p". While forcing the format
has some minor (rather questionable) use for debugging, allowing it to
crash is just stupid.
It was already accidentally used unconditionally by command.c.
Apparently this worked well for us, so don't change anything about,
but should it be unavailable, fail at configure time instead of compile
time.
This requires FFmpeg git master for accelerated hardware decoding.
Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav
will also work.
Most things work. Screenshots don't work with accelerated/opaque
decoding (except using full window screenshot mode). Subtitles are
very slow - even simple but huge overlays can cause frame drops.
This always uses fullscreen mode. It uses dispmanx and mmal directly,
and there are no window managers or anything on this level.
vo_opengl also kind of works, but is pretty useless and slow. It can't
use opaque hardware decoding (copy back can be used by forcing the
option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend
is preferred over the X11 ones in case you're trying on X11; but X11
is even more useless on RPI.
This doesn't correctly reject extended h264 profiles and thus doesn't
fallback to software decoding. The hw supports only up to the high
profile, and will e.g. return garbage for Hi10P video.
This sets a precedent of enabling hw decoding by default, but only
if RPI support is compiled (which most hopefully it will be disabled
on desktop Linux platforms). While it's more or less required to use
hw decoding on the weak RPI, it causes more problems than it solves
on real platforms (Linux has the Intel GPU problem, OSX still has
some cases with broken decoding.) So I can live with this compromise
of having different defaults depending on the platform.
Raspberry Pi 2 is required. This wasn't tested on the original RPI,
though at least decoding itself seems to work (but full playback was
not tested).
There's actually no reason why we should assert. It's unexpected and
"should" not happen, but actually there are several ways to make it
happen.
Still, add a check m_config_get_co(), to avoid matching pseudo-entries
with no name.
Currently, the code just skipped CMS completely. This commit treats them
as sRGB by default, instead.
This also refactors much of the color management code to make it more
generalized and re-usable.
Mktemp on BSDs (at least on OpenBSD) don't have "--tmpdir" option.
Set temporary directory to /tmp by default. Use of ${TMPDIR:=/tmp} allows
overriding temporary directory via environment if needed. (And is indeed needed
in OpenBSD ports infrastructure.)
Signed-off-by: wm4 <wm4@nowhere>
More clearly separate the exclusive and shared mode format discovery.
Make the exclusive mode search more systematic in particular about
channel maps (i.e., use chmap_sel). Assume that the same sample format
/ sample rates work for all channels to narrow the search space.
The code actually uses blocking mode, so opening sound device in non-blocking
mode results in choppy sound. Also, inflating the buffer isn't necessary in
blocking mode, so the function may simply return without doing anything.
This is a minor precaution, because in some cases the number of shader
programs can already hit 10. (chroma merging + separated cscale/scale +
+ sub blending (interpolated) + sub blending (non-interpolated)
+ output (interpolated) + output (non-interpolated) + OSD)
This has a number of user-visible changes:
1. A new flag blend-subtitles (default on for opengl-hq) to control this
behavior.
2. The OSD itself will not be color managed or affected by
gamma controls. To get subtitle CMS/gamma, blend-subtitles must be
used.
3. When enabled, this will make subtitles be cleanly interpolated by
:interpolation, and also dithered etc. (just like the normal output).
Signed-off-by: wm4 <wm4@nowhere>
Bilinear scaling is not a suitable default for something named "hq"; the
whole reason this was done in the past was because cscale used to be
obscenely slow. This is no longer the case, with cscale being nearly
free.
Handling this perfectly with VapourSynth is probably not possible: you
either need to tell it the total number of input frames in advance, or
deliver an infinite stream. With playback, EOF can happen at an
unpredictable point, for which the VapourSynth API has no mechanism at
all. We handle EOF by returning an error to the filter, which will the
filter return all pending frame callbacks.
We still can try to handle it approximately: if the filter requests a
frame past EOF, then send it an error. This seems to work relatively
well with filters which don't request future frames.
With the previous commit, we have no need anymore to check a part of an
extension string (for ignoring a prefix). So check the extension string
properly, instead of just using the broken old strstr() method, which
could accidentally ignore prefixes or suffixes. Do this by extending
the check to whether the extension name is properly delimited by spaces
or string start/end.
