| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
mp_gen_gamma_map() and mp_gen_yuv2rgb_map() were used by vo_opengl_old
only. The other functions removed from csputils.h are used by csputils.c
only.
|
|
|
|
|
| |
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).
|
|
|
|
| |
If you can call this a "stdlib".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Better solutions are available in vf_vapoursynth and vf_lavfi. The only
user I know who used this is now using vf_vapoursynth.
|
|
|
|
| |
If you really want it, it's in libavfilter and can be used via vf_lavfi.
|
|
|
|
|
|
| |
It's entirely useless. I left it in for a while, because the analog TV
code had a transitional bug that could switch chroma planes, but it was
fixed long ago. It's also available in libavfilter.
|
|
|
|
|
|
|
|
| |
Apparently it was completely broken and essentially did nothing. This
was broken sometime in early mpv or mplayer2 times.
Get rid of it. If you _really_ need it, wait until FFmpeg ports it from
MPlayer, which will happen very soon.
|
|
|
|
|
| |
Now it requires libavfilter. The wrapper is left in place, so FFmpeg
users will not notice any change. On Libav, the filter stops working.
|
|
|
|
|
| |
The macro actually returns the *available* space in the array, not how
much is actually filled in.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This deals with subsampled YUV video that has odd sizes, for example a
5x5 image with 4:2:0 subsampling.
It would be easy to handle if we actually passed separate texture
coordinates for each plane to the shader, but as of now the luma
coordinates are implicitly rescaled to chroma one. If luma and chroma
sizes don't match up, and this is not handled, you'd get a chroma shift
by 1 pixel.
The existing hack worked, but broke separable scaling. This was exposed
by a recent commit which switched to GL_NEAREST sampling for FBOs. The
rendering was accidentally scaled by 1 pixel, because the FBO size used
the original video size, while textures_sizes[0] was set to the padded
texture size (i.e. one pixel larger).
It could be fixed by setting the padded texture size only on the first
shader. But somehow that is annoying, so do something else. Don't pad
textures anymore, and rescale the chroma coordinates in the shader
instead.
Seems like this somehow doesn't work with rectangle textures (and
introduces a chroma shift), but since it's only used when doing VDA
hardware decoding, and the bug occurs only with unaligned video sizes, I
don't care much.
Fixes #1523.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With mf://, rather long frame durations are common. By default, one
frame takes 1 second. This causes the if branch changed with this commit
to always being taken, which in turn leads to the player not being woken
up correctly. (As a consequence, it "freezes" by waiting for events that
never come, and moving the mouse cursor over the window will wake it up
again and advance video.)
Obviously, the code should account for how long the video frame takes.
The code is probably still not fully correct, but for now this fixes the
issue at hand.
Fixes #1521.
|
|
|
|
|
| |
We've stopped using them some time ago (we're doing things manually
instead).
|
|
|
|
|
| |
Remove the "PATH" bit, because VOCTRL_GET_ICC_PROFILE returns an in-
memory profile, and not a path. (This was changed a while ago.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This queries the _ICC_PROFILE property on the root window. It also tries
to reload the ICC when it changes, or if the mpv window changes the
monitor. (If multiple monitors are covered, mpv will randomly select one
of them.)
The official spec is a dead link on freedesktop.org, so don't blame me
for any bugs.
Note that this assumes that Xinerama screen numbers match the way mpv
enumerates the xrandr monitors. Although there is some chance that this
matches, it most likely doesn't, and we actually have to do complicated
things to map the screen numbers. If it turns out that this is required,
I will fix it as soon as someone with a suitable setup for testing the
fix reports it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Merge update_icc_profile() into get_and_update_icc_profile() - there's
no reason anymore to keep them separate. The former is only called by
the latter, and the separation of responsibilities between them is
blurry a best.
Query the ICC profile only if the corresponding feature is actually
enabled. Additionally, change the error behavior of this code. Make
loading failure non-fatal, and distinguish between runtime error and
unimplemented functionality.
Fix a memory leak in gl_lcms.c (although the changes in vo_opengl.c
already take care of this, it's just logical and cleaner).
|
|
|
|
| |
We don't use the hwdec-provided video texture for screenshots anymore.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Seems like several people agree that it's a good filter for downscaling.
Setting this option by default may also prevent people from accidentally
using an unsuitable filter for downscaling by setting "scale" and
without being aware of the impliciations (maybe). On the other hand,
this change is not strictly backwards compatible for the same reasons.
Also, allow disabling this option with scale-down="" (before this, not
setting it was the only way to do this - not possible anymore if it's
set by default). This is what the change in handle_scaler_opt() does.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Somehow, the default radius for filters with variable radius was set in
mp_init_filter(). gl_video.c used NAN as default value for the radius,
which would make the filter use the default radius. Simplify this, and
set the default radius directly in the gl_video options. It also makes
the options easier to understand, because the default value listed in
--vo=opengl:help actually shows the default value.
Remove the function can_use_filter_kernel(), because it doesn't set a
radius if none is set. The function is worthless anyway (something about
making filter_kernels.c reusable to other VOs, and trying to deal with
the possibility that it could provide filters not supported by
vo_opengl.)
|
| |
|
|
|
|
|
|
|
|
| |
It actually can and does happen that you want to redraw, even if no
image was queued yet.
Broken by commit 28582322.
Fixes #1510.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Usually, a VO must react to VOCTRL_REDRAW_FRAME in order to redraw the
current screen correctly if video is paused (this is done to update
OSD). But if it's not supported, we can just draw the current image
again in the generic vo.c code.
Unfortunately, this turned out pretty useless, because the VOs which
would benefit from this need to redraw even if there is no image, in
order to draw a black screen in --idle --force-window mode. The way
redrawing is handled in the X11 common code and in vo_x11 and vo_xv is
in the way, and I'm not sure what exactly vo_wayland requires. Other VOs
have a non-trivial implementation of VOCTRL_REDRAW_FRAME, which
(probably) makes redrawing slightly more efficient, e.g. by skipping
texture upload. So for now, no VO uses this new functionality, but since
it's trivial, commit it anyway.
The vo_driver->untimed case is for forcibly disabling redraw for vo_lavc
and vo_image always.
|
|
|
|
|
|
|
|
|
|
|
| |
At the time screenshot support was added, images weren't refcounted yet,
so screenshots required specialized implementations in the VOs. But now
we can handle these things much simpler. Also see commit 5bb24980.
If there are VOs in the future which can't do this (e.g. they need to
write to the image passed to vo_driver->draw_image), this still could be
disabled on a per-VO basis etc., so we lose no potential performance
advantages.
|
|
|
|
| |
Looks like it fails on context creation, not pixfmt creation.
|
|
|
|
|
|
| |
This was previously done in common code but now it's left to backends. Also
remove the GL4 stuff since requesting a 3_2_Core context creates a 4.1 context
here (wtf).
|
|
|
|
|
|
|
|
|
| |
Use different VOCTRLs for "window" and normal screenshot modes. The
normal one will probably be removed, and replaced by generic code in
vo.c, and this commit is preparation for this. (Doing it the other way
around would be slightly simpler, but I haven't decided yet about the
second one, and touching every VO is needed anyway in order to remove
the unneeded crap. E.g. has_osd has been unused for a long time.)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vo.c queried the VO at initialization whether it wants to be updated on
every display frame, or every video frame. If the smoothmotion option
was changed at runtime, the rendering mode in vo.c wasn't updated.
Just let vo_opengl set the mode directly. Abuse the existing
vo_set_flip_queue_offset() function for this.
Also add a comment suggesting the use of --display-fps to the manpage,
which doesn't have anything to do with the rest of this commit, but is
important to make smoothmotion run well.
|
|
|
|
|
|
| |
These are untested due to lack of hardware. From what I've heard, the
drivers are pretty buggy, so it's not clear how well this works, if at
all.
|
|