A recent behavior change in libavcodec's h264 decoder keeps at least 1
surface even after avcodec_flush_buffers() has been called. We used to
flush the decoder in order to make sure all surfaces are free'd, so that
the hw decoder can be safely uninitialized. This doesn't work anymore.
Fix it by closing the AVCodecContext before the hw decoder is
uninitialized. This is actually simpler and more robust. It seems to be
well-supported too.
Fixes invalid read accesses with vaapi-copy and dxva2-copy. These
destroyed the hwdec API fully on uninit, and could not deal with
surfaces surviving the decoder.
Probably fixes#1587.
Makes all keys documented in XF86keysym.h mappable. This requires the
user to deal with numeric keycodes; no names are queried or exported.
This is an easy way to avoid adding all the hundreds of XF86 keys to
our X11 lookup table and mpv's keycode/name list.
Filters which merely wrap libavfilter (for user-compatibility) like
vf_gradfun had a "lavfi-enable" suboption, which could disable
libavfilter usage. Since none of these filters has an internal
implementation anymore, this was completely useless.
Remove the confusing crap that allowed a filter using the libavfilter
bridge to be compiled without libavfilter. Instead, compile the wrappers
only if libavfilter is enabled at compile time.
The only filter which still requires it is vf_stereo3d (unfortunately).
Special-case this one. (The whole filter and how it interacts with lavfi
is pure braindeath anyway.)
This reverts commit a33b46194c.
It turns out FFmpeg really considers this a bug, and fixed it by making
the decoder output the correct pixel format.
Fixes#1565. Reverts the fix#1528, though it should work fine with
a recent git master FFmpeg.
The intention is that we can test vo_opengl with high bit depth PNGs
better. This throws libswscale completely out of the loop, which before
was needed in order to convert from big endian to little endian.
Also apply a minimal cleanup to fmt-conversion.c (unrelated).
This introduces a new option linear-scaling, which is now implied by
srgb, icc-profile and sigmoid-upscaling.
Notably, this means (sigmoidized) linear upscaling is now enabled by
default in opengl-hq mode. The impact should be negligible, and there
has been no observation of negative side effects of sigmoidized scaling,
so it feels safe to do so.
Apparently CoreGraphics reports the actual refresh rate. DisplayLink can also
query the nominal refresh rate of the display so we use that as fallback
instead of the fugly 60fps hardcode added in aeb1fca0d.
Props to people on https://github.com/glfw/glfw/issues/137
Comment explains why I have been so doubtful at adding this. The Apple docs
say CGDisplayModeGetRefreshRate is supposed to work only for CRTs, but it
doesn't, and actually works for LCD TVs connected over HDMI and external
displays (at least that's what I'm told, I don't have the hardware to test).
Maybe Apple docs are incorrect.
Since AFAIK Apple doesn't want to give us a better API – maybe in the fear we
might be able to actually write some useful software instead of "apps" –
I decided not to care as well and commit this.
This reverts the default behavior introduced in commit 93feffad. Way too
often libavcodec will return RGB data that has an alpha channel as per
pixel format, but actually contains garbage.
On the other hand, this will actually render garbage color values in
e.g. PNG files (for pixels with alpha==0, the color value should be
essentially ignored, which is what the old alpha blend mode did).
This "fixes" #1528, which is probably a decoder bug (or far less likely,
a broken file).
Make the lazy gamma initialization less weird, and make the default
value of the "gamma" sub-option 1.0. This means --vo=opengl:help will
list the actual default value.
Also change the lower bound to 0.1 - avoids a division by zero (I don't
know how shaders handle NaN, but it's probably not a good idea to give
them this value).
There was some code accounting for different gamma values for R/G/B.
It's inherited from an old, undocumented MPlayer feature, which was at
some point disabled for convenience by myself (meaning you couldn't
actually set separate gamma because it was removed from the property
interface - mp_csp_copy_equalizer_values() just set them to the same
value). Get rid of these meaningless leftovers.
Before this, enabling :gamma in combination with :sigmoid and probably a few
other things results in ugly artifacts because the video isn't clamped until
after the :gamma was applied (or at all, if the cms_matrix is unused).
At least the opengl-hq VO allocates additional resources when
downscaling a lot, which is just a waste.
Also see #1547 (although I doubt that this is the cause; if it is,
a real fix will be required).
This is somewhat imperfect, because detection of hw decoding APIs is
mostly done on demand, and often avoided if not necessary. (For example,
we know very well that there are no hw decoders for certain codecs.)
This also requires every hwdec backend to identify itself (see hwdec.h
changes).
Resizing was happening before reconfig, so src_rect_rot was outdated and
didn't include the rotation. This resulted in corrupted rendering on
initial display, which fixed itself after the first time the window was
somehow resized.
A small simplification. Couldn't be done before, because it was also
used by the OSD code, which required disjoint quads in a single draw
call.
Also mess with the unrelated code in gl_osd.c to simplify it a little
as well.
Hardware decoding/displaying with vo_opengl is done by replacing the
normal video textures with textures provided by the hardware decoding
API OpenGL interop code. Often, this changes the format (vaglx and vdpau
return RGBA, vda returns packed YUV).
If the format is changed, there was a chance (or at least a higher
potential for bugs) that the shader generation code could be confused by
the mismatch of formats, and would create incorrect conversions.
Simplify this by requiring the hwdec interop driver to set the format it
will return to us. This affects all fields, not just some (done by
replacing the format with the value of the converted_imgfmt field in
init_format), in particular fields like colorlevels.
Currently, no hwdec interop driver does anything sophisticated, and the
win is mostly from the mp_image_params_guess_csp() function, which will
reset fields like colorlevels to expected value if RGBA is used.
Reduces the size of gl_video.c a bit further.
This also uses a separate vertex array object for OSD elements, so the
video one can be simplified slightly.
OSD shader generation is still in gl_video.c, which leads to the strange
additional parameter to mpgl_osd_init(). The issue is that video
parameters influence the OSD shader (????), and also OSD needs to go
through the screen colormanagement.
Useful if we want to reduce the size of gl_video.c further.
To some degree this emulates traditional glDrawArrays() usage. It also
leaves a loophole for avoiding a reupload every time by leaving
ptr==NULL, although this is unused for now.
default_tex_params() and texture_size() are each called only once, so
move inline/reimplement them at the caller.
image_dw/dh were unused. texture_w/h, image_format, and component_bits
were rarely used, and can be replaced. Regroup some other fields.
Rename surface_num to surface_idx, because the former sounded like a
count, and not an index. Move fbosurface_next() closer to its callers
too.
Move the DebugMessageCallback() code to gl_utils.c (also simplify it
by always setting the callback, instead of only when it changes).
This is somewhat messy, because fbotex_init() itself was depending on
some gl_video parameters unrelated to FBO creation (like what scaler was
in use - what the fuck did this check do in this function?), so this
commit does a bit more than moving code around. In particular, the FBO
for the separate scaling intermediate step now always uses GL_NEAREST
sampling, and all FBOs are destroyed/recreated on renderer
reinitialization.
This also moves the function matrix_ortho2d() - trivial enough not to
put it into a separate commit.
Windows Intel drivers seem to reject some (AFAIK) valid GLSL. Make them
happy.
<rossy> GL_RENDERER='Intel(R) HD Graphics 4400'
<rossy> GL_VERSION='3.0.0 - Build 10.18.14.4080'
<rossy> GL_SHADING_LANGUAGE_VERSION='1.30 - Build 10.18.14.4080'
Handles stupid boilerplate OpenGL requires you to handle. It's the same
code as in gl_video.c, although if no VAOs are available, the fallback
code rebinds them on every draw call instead of just once.
gl_common.c contained the function loader (which is big) and additional
utility functions (not so big, but will grow when moving more out of
gl_video.c). Just split them. There are no changes other than some
modifications to comments.
Commit acb40644 fixed video with unaligned luma/chroma sizes. It
attempted to disable the fix for videos where it effectively does
nothing (just some minor performance paranoia), but this check was
broken - fix it by not duplicating the logic for this.
PNG uses a different component order from GL_RGBA, so we upload the
surface using the "wrong" order, and then fix it in the shader. This
breaks if a sRGB texture (GL_SRGB) is used: the hardware will not touch
the alpha channel, which means that the B component is not adjusted,
leading to incorrect output.
Just remove the use of sRGB textures completely. It might lead to a
slight slow down when playing RGB with color management enabled, but
with this combination of obscure use case with minor performance impact
it's not a meaningful disadvantage.
Unfortunately this also means that alpha is handled incorrectly with our
own color management, but alpha isn't so important and can be fixed
later. (0.0 and 1.0 are unchanged by the transfer function, so it
"mostly" works.)
Fixes#1530.
This was apparently useful for correct interlaced scaling (although I
don't know anyone who used this). It was rarely used (if at all), had an
inconvenient output format (packed YUV), and now has a better solution
in libavfilter (using the libavfilter "scale" filter via vf_lavfi).
There is no reason to keep this filter any longer.
