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.
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.
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.
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).
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.)
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.
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.
The logic disabled framedropping if the frame was interpolated (i.e. the
render call is only done to interpolate between the previous frame, and
the frame before that).
It seems doing this wasn't even necessary, and broke framedrop in
smoothmotion mode. In fact, this code did nothing for display with video
fps below display fps. It did prevent the framedrop counter from going
up, though. So change it so that dropped interpolated frames are never
reported. (Doing so can give confusing results, such as dropping 1000s
of frames on slow operations like video start or changing filters.)
SmoothMotion is a way to time and blend frames made popular by MadVR. It's
intended behaviour is to remove stuttering caused by mismatches between the
display refresh rate and the video fps, while preserving the video's original
artistic qualities (no soap opera effect). It's supposed to make 24fps video
playback on 60hz monitors as close as possible to a 24hz monitor.
Instead of drawing a frame once once it's pts has passed the vsync time, we
redraw at the display refresh rate, and if we detect the vsync is between two
frames we interpolated them (depending on their position relative to the vsync).
We actually interpolate as few frames as possible to avoid a blur effect as
much as possible. For example, if we were to play back a 1fps video on a 60hz
monitor, we would blend at most on 1 vsync for each frame (while the other 59
vsyncs would be rendered as is).
Frame interpolation is always done before scaling and in linear light when
possible (an ICC profile is used, or :srgb is used).
These are now auto-detected sanely; and enabled whenever it would be a
performance or quality gain (which is pretty much everything except
bilinear/bilinear scaling).
Perhaps notably, with the absence of scale_sep, there's no more way to
use convolution filters on hardware without FBOs, but I don't think
there's hardware in existence that doesn't have FBOs but is still fast
enough to run the fallback (slow) 2D convolution filters, so I don't
think it's a net loss.
This is significantly faster for FBOs on most modern GPUs, although it
did not result in a huge difference for the video source texture on the
sizes I tested. It might be more significant for 1080p or 4K content, so
it's worth revisiting this in the future.
It also renames SAMPLE_BILINEAR to SAMPLE_TRIVIAL to match the
semantics.
This is better even for non-separable. The only exception is when using
bilinear for both lscale and cscale. I've fixed the
documentation/comments to make more sense.
This is not quite the same thing as madVR's antiringing algorithm, but
it essentially does something similar.
Porting madVR's approach to elliptic coordinates will take some amount
of thought.
This fixes compatibility with GLES 2.0 and makes the code a bit neater
in general. It also properly forces indirect scaling for subsampled
video regardless of the lscale setting.
At least the scale_sep_fbo could have been uninitialized or initialized
incorrectly when switching between scalers (e.g. from bilinear to
lanczos). Calling check_resize() should take care of this.
Instead of reading back the image from textures, keep a reference to the
original image, and return that.
The main reason this was done this way was that originally, images
weren't refcounted, and would be deallocated or overwritten as soon as
the VO's draw call returned. But now there isn't really a good reason
for this anymore. One possibly _could_ argue that it was better because
other code could reuse the image sooner (e.g. for the cache), but on the
other hand, the VO runs already on a different thread, and filtering and
decoding each run on other threads too, so this argument probably
wouldn't hold up.
There was a case when we could have rendered to an output surface while
it's still used for display. Not sure why the API doesn't do this
automatically.
Instead of converting the hw surface to an image in the VO, provide a
generic way to convet hw surfaces, and use this in the screenshot code.
It's all relatively straightforward, except vdpau is being terrible. It
needs a huge chunk of new code, because copying back is not simple.
Before this commit, each hw backend had their own specific struct types
for context, and some, like VDA, had none at all. Add a context struct
(mp_hwdec_ctx) that provides a somewhat generic way to pass the hwdec
context around. Some things get slightly better, some slightly more
verbose.
mp_hwdec_info is still around; it's still needed, but is reduced to its
role of handling delayed loading of the hwdec backend.
