These were found by the cppcheck and scan-build static analyzers. Most
of these aren't interesting (the 2 previous commits fix some interesting
cases found by these analyzers), and they don't nearly fix all warnings.
(Most of the unfixed warnings are spam, things MPlayer never cared
about, or false positives.)
This caused all formats with fewer than 8 bits per component marked as
little endian. (Normally, only some messed up packed RGB formats are
endian-specific in this case.)
This allows using the vdpau decoders with -vd without having to use
the -hwdec switch (basically like in mplayer).
Note that this way of selecting the hardware decoder is still
deprecated. libavcodec went away from adding special decoder entries
for hardware decoding, and instead makes use of the "hwaccel"
architecture, where hardware decoders use the same decoder names as
the software decoders. The old vdpau special decoders will probably
be deprecated and removed in the future.
YCgCo can be manually selected, but will also be used if the decoder
reports YCgCo. To make things more fun, files are sometimes marked
incorrectly, which will display such broken files incorrectly starting
with this commit.
Useful for the j2k decoder.
Matrix taken from http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
(XYZ to sRGB, whitepoint D65)
Gamma conversion follows what libswscale does (2.6 in, 2.2 out).
If linear RGB is used internally for scaling, the gamma conversion
will be undone by setting the exponent to 1. Unfortunately, the two
gamma values don't compensate each others exactly (2.2 vs. 1/0.45=2.22...),
so output is a little bit incorrect in sRGB or color-managed mode. But
for now try hard to match libswscale output, which may or may not be
correct.
We only print an error message when POLLERR or POLLHUP occurrs, as the
something did go horribly wrong and the server will either deal with it or
crash.
Also add POLLOUT to the events.
Bump xkbcommon version and use the new xkb_keymap_from_buffer. This is more
secure, because the from_string expects a 0 terminated string, but this cannot
be guaranteed with mmap.
This commit remove a lot of linux specific code, like epoll. It also reduces
the complexity of the code. Instead of epoll we use poll which makes the
wayland backend more portable to other platforms.
This removes a good chunk of code trying to recreate key repeat.
Because the wayland protocol and xkbcommon don't have an interface for
auto-repeating pressed keys.
The code was attempting to get the ceiling of the double. Too bad NSSize has
floats inside of it and the int cast is nowhere to be seen. This caused
rounding errors by one pixel in the window size.
libavcodec decoder initialization failure caused a segfault, because it
wasn't properly reported back in init().
Also remove the return value from init_avctx(), which actually makes
things simpler. Instead, ctx->avctx can be checked to see whether
initialization was ok.
libavfilter changed the way a format list is passed to vf_format. Now
you have to separate formats with "|" instead of ":". If you use "|",
it prints an annoying message on every reinit:
[format @ 0x8bbaaa0]This syntax is deprecated. Use '|' to separate the list items.
...and it will probably stop working without warning at some point in
the future.
We need some very annoying ifdeffery to detect this case, because
libavfilter version numbers are just plain incompatible between Libav
and ffmpeg. There is no other way to detect this.
(Sometimes I wonder whether ffmpeg and especially Libav actually like
causing unnecessary pain for their users, and intentionally break stuff
in the most annoying way possible. Sigh...)
Resetting the filter graph helps dealing with filters which save state
between frames. This is important especially if they modify frame timing
or emit additional frames.
Unfortunately the libavfilter API doesn't have a way to do this
directly, so we have to use a dirty trick: we recreate the whole graph,
including format negotiation down and filter string parsing. ffplay does
this too. If libavfilter somehow decides to change output format or size
from what the first run in config() returned, mpv will explode. The same
applies to vf_next_query_format() return values (although this could be
mitigated, should it really happen).
Block X11's native key repeat, and use mpv's key repeat handling in
input.c instead.
No configure check for XKB. Even though it's an extension, it has been
part of most (all?) xlibs since 1996. If XKB appears to be missing,
just refuse enabling x11.
This is a potentially controversial change. mpv will use its own key
repeat rate, instead of X11's. This should be better, because seeking
will have a standardized "speed" (seek events per seconds when keeping
a seek key held down). It will also allow disabling key repears for
certain commands, though this is not done anywhere yet.
The new behavior can be disabled with the --native-keyrepeat option.
The VO warns by default that the nomanyfmts option should be used if
video display fails. This is almost completely useless, but people
keep asking what it means.
Requires recent FFmpeg/Libav git versions. Earlier versions will not
be supported, as the API is different. (A libavfilter version that
uses AVFrame instead of AVFilterBuffer is needed.)
Note that this is sort of useless, because the option parser prevents
you from making use of the full libavfilter graph syntax. This has to be
fixed later.
Most of the filter creation code (half of the config() function) has
been taken from avplay.c.
This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't
compile as it hasn't been updated through multiple libavfilter API
changes, making it completely useless as a starting point.
This refactor makes the code easier to understand. Also corrects a bug that
caused the window to move to the left when the new size was bigger than the
visible frame.
It is now possible to show images and videos with alpha information correctly.
This was disalbed before, because there was a bug that made black parts of
videos also transparent.
The previous attempt was missing some code paths, so there were still
shaders generated that triggered the shader compilation error. Fix it
instead by special handling USE_CONV in the shader.
By the way, the shader compiler did not accept:
#if defined(USE_CONV) && (USE_CONV == ...)
In my opinion this should be perfectly fine, but it gives the same
error as before. So test USE_CONV separately with #ifndef.
The OSX shader compiler was giving this error:
ERROR: 0:235: '' : syntax error incorrect preprocessor directive
on this line:
[235] #if USE_CONV == CONV_PLANAR
USE_CONV was undefined in some cases. The expected behavior is that the
shader preprocessor interprets this as branch not taken (AFAIK exactly
as in C), which is probably what the standard would dictate. This is
possible an OSX bug. But admittedly, I'm not sure whether this is really
standard behavior (in C or GLSL), and doing this is extremely weird at
best, so make sure that USE_CONV is always defined.
Should fix behavior on OSX.
Allows playing video with alpha information on X11, as long as the video
contains alpha and the window manager does compositing. See vo.rst.
Whether a window can be transparent is decided by the choice of the X
Visual used for window creation. Unfortunately, there's no direct way to
request such a Visual through the GLX or the X API, and use of the
XRender extension is required to find out whether a Visual implies a
framebuffer with alpha used by XRender (see for example [1]). Instead of
depending on the XRender wrapper library (which would require annoying
configure checks, even though XRender is virtually always supported),
use a simple heuristics to find out whether a Visual has alpha. Since
getting it wrong just means an optional feature will not work as
expected, we consider this ok.
[1] http://stackoverflow.com/questions/4052940/how-to-make-an-opengl-rendering-context-with-transparent-background/9215724#9215724
When displaying YUV with alpha plane (an extremely rare special case),
we didn't upload the alpha plane, because we don't do anything with it.
This actually created some annoying special cases, so upload the alpha
planes as well, even if they're unused.