| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Make MpvEventsView -signalMousePosition a public method so it can be
called without a compiler warning. Previously, the mouse position would
be reported as (0,0) until the cursor was moved.
(cherry picked from commit bce753060eb9fb99ebc64fb6027d130a37b918a6)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mpv would attempt to load ICC profiles several times during VO init
even if no window is displayed. This potentially causes it to load
a profile for a different screen than it is going to be displayed
on, thereby invalidating the profile cache and rebuilding the LUT
every single time.
It would not unload a previously loaded profile when the video
window is moved to a display without an installed profile.
Fix these issues and tweak the log messages a little.
(cherry picked from commit 1bab7f69aeb1ee80fdd2f75d7658cd5fef7ee2e3)
|
|
|
|
| |
(cherry picked from commit 5cddd4ccca79405ea57fcd423a554ddf12da0126)
|
|
|
|
|
|
|
|
|
| |
Always keep around our private state and destroy it when we are really done in
the async uninit callback.
Fixes #1657
(cherry picked from commit c66b51dab02d9eb0629dc87612459436cd1a882e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The vaapi equalizer have a custom range, and can have a smaller range
than mpv's normalized video equalizer values. The result is that a vaapi
equalizer value can map to multiple mpv values, so changing a mpv value
by 1 can get "stuck". Fix by remember the mpv value, and returning it if
it still corresponds to the vaapi value.
Really fixes #1647.
(Why am I even bothering with this irredeemable crap?)
(cherry picked from commit fc571e0adb2498cc9278ee51f9aa6b00ee165644)
|
|
|
|
|
|
|
| |
Probably fixes #1647 (if it's correct at all). I couldn't reproduce with
the vdpau libva driver, but a driver can use different ranges.
(cherry picked from commit 4e3f8ccb9d24f2f0940e93d1a8582e562265dede)
|
|
|
|
|
|
|
|
|
| |
Stupid compiler.
For decode_surrogate_pair(), I changed the order of evaluation; it
shouldn't matter, but this order is more readable in my opinion.
(cherry picked from commit 85bf102f54cfae9945d26f1edc0e642975881dfa)
|
|
|
|
|
|
|
|
| |
Just use makeFirstResponder on the mpv events view from client code
if you need the built in keyboard events (this is easier for dealing with view
nesting).
(cherry picked from commit 03a69bac95ce4e15016138104cd198a6a60c38cd)
|
|
|
|
|
|
|
| |
Essentially a leak, but not that bad since it's small and allocated only
once.
(cherry picked from commit 73c5c3df5336348367902ec76a5f702909549696)
|
|
|
|
| |
(cherry picked from commit e7b7a5a476a9082320173a7c09b22d3b679fe557)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change test_fbo() so that it checks the FBO lazily, and restructure
check_gl_features() to invoke it only if we know that a FBO will be
needed for a certain enabled feature.
This can avoid strange error messages when using --vo=opengl and the
FBO format does not work. It's also less confusing when reading the
verbose log (users might think that the FBO is actually used, etc.).
(cherry picked from commit 280c826379dfdebb9e949d22583c01d532a504c7)
|
|
|
|
|
|
|
|
|
|
| |
This can happen with the "no-colorkey" suboption. Then the code in
xv_draw_colorkey() can be run before vo_x11_config_vo_window(), when
vo_gc is not allocated yet.
Fixes #1629.
(cherry picked from commit a2e0cd7f251f0c1750bbe7adaff6d408ae7dcd37)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of rendering and upscaling each video frame on every vsync, this
version of the algorithm only draws them once and caches the result,
so the only operation that has to run on every vsync is a cheap linear
interpolation, plus CMS/dithering.
On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz
monitor), up to 120% faster. (The speedup is not quite 250% because of
the overhead that the larger FBOs and CMS provides)
In terms of the implementation, this commit basically swaps
interpolation and upscaling - upscaling is moved to inter_program, and
interpolation is moved to the final_program.
Furthermore, the main bulk of the frame rendering logic (upscaling etc.)
was moved to a separete function, which is called from
gl_video_interpolate_frame only if it's actually necessarily, and
skipped otherwise.
(cherry picked from commit 010cf183fe3133fe6f581f9b25137827c6b26a39)
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLES2 randomly does not support the transpose parameter in matrix
uniform calls. So we have to do this manually. Sure it was worth to
mutilate the standard just so all these shitty SoC vendors can safe 3
lines of code.
(Obviously trying to handle all of GLES2 to GL 4.x in a single codebase
was a mistake.)
(cherry picked from commit cc011415ffb10521260e486a41b56d0080bf2cd9)
|
|
|
|
|
|
|
|
|
| |
GLES2 shaders do not have line continuation characters. Abuse the
HAVE_ARRAYS define to exclude code which uses arrays, and which also
happens to cover all code that defines multi-line macros. (So yes, this
is a hack.)
(cherry picked from commit 2c8d16d89f6f64a587222dd53a3d27b2a218ee01)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original filter window was design for a radius based on the true
zero, but we always cut it off at our selection of radius either way (by
necessity, due to the square matrix we sample from).
This window is tweaked from the original (true radius) to our actual
cut-off radius, and hence improves the result in a few edge cases. The
main win is the reduction of code complexity, since we no longer need to
know what the true radius actually is.
(cherry picked from commit 1ecd9727f0e3df68c6be9955b759547a34a0b79f)
|
|
|
|
|
|
|
|
| |
Check the scanf() return value, and don't continue if it doesn't find
both numbers (can happen with GLES 1.0). Also, some implementations can
return NULL from glGetString() if something is "broken".
(cherry picked from commit 9861abf8ffa4c9e7c4ad9a4f3f667e6f833624a3)
|
|
|
|
|
|
|
|
| |
I've reworked pretty much all the logic to correspond to what the theory
actually describes. With this commit, playback is wonderfully smooth on
my machine.
(cherry picked from commit 4356e893a138e24f2d54dee2b96d2720e69d4c18)
|
|
|
|
|
|
|
| |
This should be no problem... but it _might_ help with #1536, so it's
worth a try.
(cherry picked from commit 0063d94927a0dfd1ba8f4af1bc59467ba793ef82)
|
|
|
|
|
|
| |
This line of code ended up in the wrong block in commit cd6dfcbe.
(cherry picked from commit f247294d7346306ef9f42a986d693df4743f9152)
|
|
|
|
|
|
|
| |
Some IR receivers emit this key by default for remote control
buttons. Make it mappable.
(cherry picked from commit 9aaec7cffb2fb1543d4c3cabb55165f606c0b87d)
|
|
|
|
|
|
|
| |
Falls back to the first display in the list returned by xrandr. Not
entirely correct, but makes some people happy (see #1575).
(cherry picked from commit cd6dfcbef4ef15fd7ccd387e2f3438d7e702c567)
|
|
|
|
|
|
|
|
|
|
| |
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.
(cherry picked from commit 417869f845d34596d8651fd9c38e6c74d56fecee)
|
|
|
|
|
|
|
| |
Using prev_pts as the start of the scale was plain wrong. Change it to
prev_vsync.
(cherry picked from commit 3931544ef33196e1966c416cc0d60d4160cf27fb)
|
|
|
|
| |
Whatever.
|
|
|
|
| |
No change in behavior.
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit a33b46194c3525cb585cc78b449ec275dbfd7f83.
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.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This was left over from 61f5a80.
|
|
|
|
| |
This is already done in the common vo.c code.
|
|
|
|
|
| |
If smoothmotion is enabled, and the screen shows an interpolated frame
the moment you pause, redraw a non-interpolated frame.
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
| |
Makes it unnecessarily slow. It's still needed if the sigmoid crap is
actually used.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This allows a spread of 1.0 in either direction, which is already close
to absurd. Anything higher than that is pretty pointless.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
We still do redundant calls to it, but obviously we can avoid calling it
if we don't want to set a callback at all. May or may not help with
default.
|
|
|
|
| |
Basically, the OpenGL API is crap (it takes an offset as pointer).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
These were intended for some plans that were never realized.
Also move some comments around and fix them.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This opportunity for refactoring was enabled by f3c84a3.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|