This played e.g. a 1264x722 file as 1264x720. There was some code which
dropped the aspect ratio if the video (in original resolution) wasn't
scaled by more than 4 pixels. Commit 5f3c3f8c introduced this (although
I'm not really sure what the code replaced by it did).
Just remove this "feature".
We now update uniforms every time, so we should try to reduce the number
of uniforms to avoid performance penalties. (Originally, some caching
was planned, but it looks like it would be too complicated to implement
compared to the expected gains.)
OPT_REPLACED can't specify option values or multiple options. Change to
OPT_REMOVED. Also, target-prim doesn't have an srgb option. BT.709 uses
sRGB primaries, so use it instead.
The default scaling was a slight bit too low, which could cause buffer
underruns in some cases.
This should improve the result when using tscale filters other than
oversample. The oversample case should be unaffected.
This adds extra debugging output for buffer underruns, to help track
down possible queueing issues. It also inverts the numberic output for
tscale=oversample to make more sense, without changing the logic.
This moves the color management code out of pass_render_main (which is
now dedicated solely to up/downscaling and hence renamed pass_scale_main)
and into a new function, which gets called from pass_draw_to_screen
instead.
This makes more sense from a logical standpoint, and also means that we
interpolate in linear RGB, before color management - rather than after
it, which is significantly better for color accuracy and probably also
interpolation quality.
This replaces the old smoothmotion code by a more flexible tscale
option, which essentially allows any scaler to be used for interpolating
frames. (The actual "smoothmotion" scaler which behaves identical to the
old code does not currently exist, but it will be re-added in a later commit)
The only odd thing is that larger filters require a larger queue size
offset, which is currently set dynamically as it introduces some issues
when pausing or framestepping. Filters with a lower radius are not
affected as much, so this is identical to the old smoothmotion if the
smoothmotion interpolator is used.
Also the size is now a simple #define that can easily be changed later.
This is done for smoothmotion, which might want to blend more than 4
frames at once, depending on the setting.
Since the gl_rework merge, this started to print some OpenGL errors when
using vdpau hardware decoding with vo_opengl smoothmotion. This happens
because some hwdec unmap_image call were not paired with a map_image
call. Unlike the old vo_opengl, the new code does not do this out of
convenience (it would be a pain to track this exactly). It was triggered
by smoothmotion, because not every rendered frame has actually a new
input video frame (i.e. no map_image call, but it called unmap_image
anyway).
Solve this by handling unmapping differently in the vdpau code. The next
commit will remove the unmap_image callback completely.
Fixes#1687.
This caused complaints because the fps was basically rounded on
microsecond boundaries in the vsync interval (it seemed convenient to
store only the vsync interval). So store the fps as float too, and let
the "display-fps" property return it directly.
Even the lowest supported GL versions have arrays. This test was for
returning arrays from functions, which didn't work in lower GL versions,
but we don't need it anymore.
Previously, mpv would hide the cursor when the autohide timer expired,
even if the window menu was open. This made it difficult to use the menu
with the mouse.
When handling VOCTRL_SET_CURSOR_VISIBILITY, instead of determining
whether to call SetCursor by checking if the cursor is in the client
area, call it based on the parameters to the last WM_SETCURSOR message.
When the window enters "menu mode," it gets a WM_SETCURSOR message with
HIWORD(lParam) set to 0 to indicate that the cursor shouldn't be set.
Requested change in behavior.
Note that we set the assumed "infinite" display_fps to 1e6, which
conveniently lets vo_get_vsync_interval() return a dummy value of 1,
which can be easily checked against, and still avoids doing math with
float INFs.
I'm not comfortable with VOCTRL_GET_DISPLAY_FPS being called every
frame.
This requires the VO to set VO_EVENT_WIN_STATE if the FPS could have
changed. At least the X11 backend does this.
This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL,
etc, as well as color management. Also adds a new gamma function (gamma22).
This adds new parameters to configure the CMS settings, in particular
letting us target simple colorspaces without requiring usage of a 3DLUT.
This adds smoothmotion. Mostly working, but it's still sensitive to
timing issues. It's based on an actual queue now, but the queue size
is kept small to avoid larger amounts of latency.
Also makes “upscale before blending” the default strategy.
This is justified because the "render after blending" thing doesn't seme
to work consistently any way (introduces stutter due to the way vsync
timing works, or something), so this behavior is a bit closer to master
and makes pausing/unpausing less weird/jumpy.
This adds the remaining scalers, including bicubic_fast, sharpen3,
sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also
consult scale-param1, which was undocumented in master.
This also implements cropping and chroma transformation, plus
rotation/flipping. These are inherently part of the same logic, although
it's a bit rough around the edges in some case, mainly due to the fallback
code paths (for bilinear scaling without indirection).
The basic idea is to use dynamically generated shaders instead of a
single monolithic file + a ton of ifdefs. Instead of having to setup
every aspect of it separately (like compiling shaders, setting uniforms,
perfoming the actual rendering steps, the GLSL parts), we generate the
GLSL on the fly, and perform the rendering at the same time. The GLSL
is regenerated every frame, but the actual compiled OpenGL-level shaders
are cached, which makes it fast again. Almost all logic can be in a
single place.
The new code is significantly more flexible, which allows us to improve
the code clarity, performance and add more features easily.
This commit is incomplete. It drops almost all previous code, and
readds only the most important things (some of them actually buggy).
The next commit will complete it - it's separate to preserve authorship
information.
If you click on a window that doesn't have a focus, a LeaveNotify
followed by a EnterNotify event can be generated. The former will have
mode set to NotifyGrab, the latter to NotifyUngrab. This will make the
player think the mouse left the window, even though this is not the
case. Ignore these and only react to those with mode set to
NotifyNormal.
Probably fixes#1672, and some other strange issues on some WMs.
mpv_opengl_cb_render() is supposed to clear the screen with the
background color if there's no video... I think.
It didn't do this, because although uninit() requested gl_video_config()
to be called, this didn't happen, because this function checks whether
the VO is set - and it's unsert after uninit() releases the lock.
Also call the user wakeup callback in this situation, so the user
actually redraws immediately.
Do not rely on the pointed-to argument to be initialized; VOCTRLs are
supposed to completely overwrite them on success (or not to touch them
on failure).
The currently only caller of VOCTRL_GET_WIN_STATE initializes the value
before calling this, so this is merely about correctness and didn't lead
to any actual bugs.
Add filter parameters to VAAPI deinterlacing filter to actually process
bottom fields instead of deinterlacing top field twice.
Signed-off-by: wm4 <wm4@nowhere>
Some UI elements in OS X – like Launchpad and Dock folders – are implemented
using borderless windows in background demonized applications.
When we use these elements, mpv doesn't stop to be the active application, but
the mpv window leaves keyWindow state while we use the OS controls.
This commit just keeps track of window state to update the cursor visibility
accordingly.
Fixes#513
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.
