| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This commit sucks bad, but everything else is worse is other ways.
Basically, the current vblank waiting time in the vo_wayland_wait_frame
function (calculated very carefully using presentation statistics) is
randomly too short. Some compositors are quite variable when they
actually return callback so our timeout expires too quickly and throws
everything off. The fix? Add an arbitrary 5% to the vblank value and
pray that nothing gets off that much. Why did they have to make
swapinterval 1/fifo mode indefinitely block? Fixes #9504.
|
|
|
|
|
|
|
| |
Better to avoid any wonky calculations on startup with garbage values.
The others end up being derived from last_ust/last_msc. refresh_interval
is referenced exactly once and could, in theory, result in some terribly
erroneous vblank time.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A read can be prepared on the wayland display FD that is never actually
read. This occurs when events are triggered on other FDs in the fd set.
This change cancels a prepared read if poll reported no events for it.
This fixes some hangs due to how nvidia's EGL implementation polls on
the wayland fd unlike mesa implementations. It is based on nvidia's
proposed fix for qt's similar message pump in
https://codereview.qt-project.org/c/qt/qtwayland/+/373473
Signed-off-by: Kurt Kartaltepe <kkartaltepe@gmail.com>
|
|
|
|
|
| |
If the EGL extension is present, pass the modifiers for each plane
to the EGL driver.
|
|
|
|
|
| |
Wrapping the context is pretty straightforward. This is only complicated
by needing to account for the upside-down framebuffer in a few places.
|
|
|
|
|
|
| |
This is done to avoid cluttering vo_gpu_next.c with more ifdeffery and context-specific code
when additional backends are added in the near future.
Eventually gpu_ctx is intended to take the place of ra_ctx to further separate gpu and gpu_next.
|
|
|
|
|
|
| |
This case was added in 662c793a557925319493297de8c941a636f18d73
for use in vo_gpu_next as a visibility test before rendering a frame.
The OpenGL context doesn't have this so it just returns true.
|
|
|
|
| |
Fixes 2b2442ee67913221e5c87cbc06010671e1b41c15
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is needed when the color system is not explicitly tagged, but
instead needs to be inferred by the VO.
Note that there exists the function mp_image_params_guess_csp for this
sort of stuff, but it contains a lot of baggage that I don't want to
replicate, in order to move as much of this logic into pl_renderer as
possible, and therefore also give it the best chance of knowing what
shortcuts it can and can't take.
Fixes the other half of https://github.com/mpv-player/mpv/issues/9499
|
|
|
|
|
|
|
|
|
|
| |
Adding vsync_offset to the pts in pl_queue_update actually messes up
frame timings if one isn't using interpolation. The easiest way to see
this is to have the monitor's refresh rate at an integer multiple of a
video during a panning shot (classic case). There will be very visible
judder/stutter in this case that does not happen in vo_gpu. The cause of
this is the addition of the extra vsync_offset. Just match the semantics
of vo_gpu where this is only used when interpolating.
|
|
|
|
|
|
| |
Similar to ff0864d5f07d31c808014dbf1791ed3ec14644a8
Fixes #9484
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This possibility actually existed for years. The wayland protocol is
asynchronous and there's no restriction on when a compositor can send a
surface enter event. In mpv's case, the surface enter event is used to
set some vital things regarded geometry/scaling etc. However, this
implictly assumes that wl->current_output is actually initialized. The
vast majority of the time, vo_wayland_reconfig will happen first which
is where wl->current_output is, and should, be created. There's no
rule/law that the ordering of events will always occur in this order.
Plasma with certain auto-profile conditions can send the surface enter
event before mpv does its initial reconfig. That segfaults of course.
Just add a check to make sure we have wl->current_output here and return
if we don't. This assumes that the compositor will send us another
surface enterance event when mpv actually does the initial surface
commit and roundtrip request later. Wayland logs indicate this does
happen. Fixes #9492.
|
|
|
|
|
|
| |
It was never implemented before but it's trivial. As an aside, touch
events currently don't support modifiers either (is this a thing?). Well
if someone complains that can be done later. Fixes #9490.
|
|
|
|
|
|
|
| |
Even when not display synced. Prevents redraw overhead for refreshes
while paused.
Also make the logic slightly clearer to follow (since it's inverted).
|
|
|
|
|
| |
Fix typo in the warning to avoid ewa_lanczossharp because
it might be removed in the future.
|
|
|
|
| |
Matches what `pl_log_create` does as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This almost perfectly recreates the semantics of --vo=gpu, i.e.:
- still frames are never interpolated
- non-repeated frames bypass single frame cache
The only difference is that libplacebo doesn't do a cache/blit on the
full output image, but rather it re-runs the last rendering step. This
has some advantages and some drawbacks. The most notable advantage is
that it also allows re-using the image contents when the only thing that
changes is the OSD (whereas `--vo=gpu` would force a full re-render for
that). The most notable drawback is that it also implies going through
the dithering and output LUT logic on redraws. All in all, I think this
is a pretty good trade-off in favor of `--vo=gpu-next`.
Fully fixes the last remaining performance difference in #9430.
|
|
|
|
| |
Closes #9454
|
|
|
|
|
|
|
| |
GLX_CONTEXT_PROFILE_MASK_ARB and related constants are provided by
GLX_ARB_create_context_profile but the check was for _create_context.
The former implies the latter (which we also need) so just replace
the checked extension.
|
|
|
|
| |
Again no functional difference, just uses better APIs when they're available.
|
|
|
|
| |
This does what 3a10210c568f9c7d969ca6c4da2377c55fbf30f3 was supposed to, but better.
|
|
|
|
|
|
| |
It abstracts EGL 1.5, extension checks and other inconsistencies away.
This can be used in context code as the (preferred) alternative to
eglCreateWindowSurface().
|
|
|
|
|
|
| |
Using a simple substring match for extension checks is considered bad practice
because it's incorrect when one extension is a prefix of another's name.
This will almost surely not make a difference in practice but do it for correctness anyway.
|
|
|
|
|
|
| |
Although there are no known problems with this, using the helper should
be more portable. It will also prefer EGL 1.5's eglGetPlatformDisplay
over eglGetPlatformDisplayEXT if available.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the basic Vulkan Display context can theoretically drive the
display without the involvement of any non-Vulkan code, that prevents
us from using VAAPI acceleration. When initialising VAAPI without a
window system, we need to provide it with an opened DRM render fd
corresponding to the device to use.
In the context of using VK_KHR_display, that means we need to identify
which DRM device matches the selected Vulkan device, and then open its
render fd and set the necessary state that VAAPI expects to find.
With that done, the normal VAAPI<->Vulkan interop can kick in and we
get working acceleration
|
|
|
|
|
|
|
| |
Ever instance of m_obj_list is a constant and for all of them, the field
is true. Just remove the field all together.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
d2e8bc449986e012f257249a996386bd323febd0 was the the commit that
originally introduced the usage of this bit. As the message states, the
purpose was to force creating GLES 3 contexts on drivers that do not
return a higher version context than what was requested. With the recent
opengl refactors, mpv's gl selection has already moved away from such
complicated queries. Perhaps when that commit was added things were
different, but nowadays it seems like Mesa simply returns the highest
driver version available that is compatibile with the request (i.e.
requesting GLES 2 returns a GLES 3 context on my machine). In that case,
let's just simply drop EGL_OPENGL_ES3_BIT altogether as it does break
GLES 2 only machines. Fixes #9431.
|
|
|
|
|
| |
This is identical to eglCreateWindowSurface but should be
preferred as part of EGL's platform extension.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new GBM supporting nvidia drivers declare support for 10bit
surfaces using BGR ordering, rather than RGB, so add support for them.
We've also seen examples of hardware supporting BGR8888 but not
RGB8888 so let's support those too.
Of course, the nvidia EGL driver doesn't publish support for any 10bit
formats so you can't actually do 10bit display. Perhaps they'll
eventually fix that.
|
|
|
|
|
|
|
|
|
| |
The GBM supporting nvidia driver doesn't support creating surfaces
without modifiers and using modifiers is more and more recommended as
the right way to do this.
Enumerating modifiers is painfully verbose, but necessary if we are to
allow the driver to pick the best possible one.
|
|
|
|
|
|
|
|
| |
This logic, which was working around a libplacebo bug, ended up always
alpha blending - even for sources without an alpha channel. This caused
a minor slowdown to be constantly enabled.
Due to the recent bump to libplacebo v170, this is no longer needed.
|
|
|
|
|
| |
Without initializing, the random data causes the `pl_render_image_mix`
function to abort with a SIGSEGV.
|
|
|
|
|
|
|
|
| |
Completely untested, since Linux still can't into HDR in 2021. Somebody
please make sure it works.
Technically covers #8219, since gpu-context=drm can be combined with
vo=gpu-next.
|
|
|
|
| |
These are no longer needed with the minimum version bump.
|
|
|
|
|
|
|
|
| |
This required an upstream API change to implement in a way that doesn't
unnecessarily re-push or upload frames that won't be used. I consider
this a big enough bug to justify bumping the minimum version for it.
Closes #9401
|
|
|
|
|
|
|
|
|
| |
This was originally added in f2afae55e95b4b1eec1aeb828ba6ff1f0695d993
for unclear reasons (way to go me). This concept is clearly incorrect.
It doesn't matter what state the window is in. As soon as mpv detects a
scale change, it needs to reset the buffer scale of the window. Just
remove all this junk and put wl_surface_set_buffer_scale in
set_surface_scaling like it should be. Related issue: #9426.
|
|
|
|
|
|
|
| |
This one hits a lot of people. Probably because the man page explicitly
recommends it.
Fixes #9408
|
|
|
|
|
|
| |
I somehow completely forgot about this option existing.
Closes #9416
|
|
|
|
|
|
|
|
|
|
|
| |
Looking at this again I'm not sure it does anything useful at all. The
man page entry is also wrong: `bicubic` is not affected, only
`bicubic_fast`, and those filters are not configurable anyways.
So this would only ever be a debugging option, and I don't see a
pressing need for it.
No interface-change.rst update because it only just got added anyways.
|
|
|
|
|
|
|
|
|
| |
In practice, this is for wayland. vo_gpu_next doesn't check the
check_visible parameter since it didn't descend into the
vulkan/context.c file when starting a frame. To make this happen, just
call the start_frame function pointer but pass NULL as the ra_fbo. In
there, we can do the visibility checks and after that bail out of the
start_frame function if ra_fbo is NULL.
|
|
|
|
|
|
|
|
|
|
| |
This vulkan-specific parameter was poorly named and probably causes
confusion. Just rename it to check_visible instead to make clear what is
going on here. Only wayland uses it for now but in theory anyone else
can. As an aside, wayland egl accomplishes this by using an external
swapchain instead (an opengl-only concept in the mpv code). This may or
may not need to be changed in the future when gpu-next gets opengl
support.
|
|
|
|
|
| |
It was pointed out on IRC that the name is misleading, since the actual
semantics of the macro is to assert first.
|
|
|
|
|
|
| |
vo_gpu defaults this to NAN, libplacebo uses 0.0 as the default.
Fixes https://github.com/mpv-player/mpv/issues/9386
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed in #8799, this will eventually replace vo_gpu. However, it
is not yet complete. Currently missing:
- OpenGL contexts
- hardware decoding
- blend-subtitles=video
- VOCTRL_SCREENSHOT
However, it's usable enough to cover most use cases, and as such is
enough to start getting in some crucial testing.
|
|
|
|
|
|
|
|
|
| |
This seems to work on gcc, clang and mingw as-is, but I made it
conditional on __GNUC__ just in case, even though I can't figure out
which compilers we care about that don't export this define.
Also replace all instances of assert(0) in the code by MP_UNREACHABLE(),
which is a strict improvement.
|
|
|
|
|
|
|
|
|
|
|
| |
A lot of people seem to do something like --tscale=box
--tscale-window=<function>. Just let them use --tscale=<function>
directly, by also accepting raw windows.
Kinda hacky but needed for feature parity with vo_gpu_next, which no
longer has `--tscale=box`. Note that because the option struct is still
shared, vo_gpu_next inherits the same option handling code, so we have
to export this feature for vo_gpu as well.
|
|
|
|
| |
So I can reuse it in vo_gpu_next.
|
|
|
|
| |
So I can re-use them for vo_gpu_next.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Back when runtime updating of autofit/geometry was added for wayland and
x11 (commits: 4445ac828dca0298543103094357e64f8828ef56 and
ced92ba607ebd98687b26ef3d8c09d5f6e22cf4b respectively), the naive
assumption was that window-related geometry would always be available.
While this is true 99% of the time, this isn't a guarentee. It is
possible for certain things such as loading shaders to delay starting up
the player. This causes autofit/geometry options to be registered as a
runtime update and triggers VOCTRL_VO_OPTS_CHANGED. This ends up calling
some geometry-related functions but this happens before the actual
values are available. Hence, a nullptr was accessed which segfaults. At
least one user experienced this with a combination of options in wayland
but in theory the same thing could happen under x11.
The fix is simple. Just be sure to check that the required geometry is
available before doing any calculations. In wayland, this would be
wl->current_output. Additionally add an assert to set_geometry (we
should never use this function without wl->current_output) to be extra
sure. In x11, the check is on x11->window. Later when the reconfig for
each backend actually happens, the autofit/geometry set by the user
happens anyway so ignoring it in this case does no harm. Fixes #9381.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upstream libplacebo got refactored to use byte-sized strides rather than
texel-sized strides. This commit makes mpv's ra_pl wrapper take
advantage of that, rather than forcing a stride-fixing memcpy.
Note that, technically, we would still need a stride fixing memcpy in
cases when the true stride is not a multiple of the format's texel
*alignment*, however this is a much rarer case and extremely unlikely to
occur in practice, since all relevant formats use power-of-two texel
alignments.
|
|
|
|
|
|
|
|
|
|
|
| |
In the reconfig event, the keepaspect option was checked before setting
the window_size geometry to the new params obtained from the vo. This is
incorrect. If a user disabled keepaspect on wayland, the video's size
would not change on a reconfigure event (i.e. loading a new video in the
playlist with a different size). No other windowing backend (x11, win32,
etc.) behaves like this or uses keepaspect in its code like wayland did
in this case. Clearly, this is not correct. Such functionality should be
handled by a separate option entirely. Just remove this if statement.
|
|
|
|
| |
Add support for the newly added USB connector type and also SPI and Writeback.
|
|
|
|
|
| |
Avoid 'Segmentation fault' by using the connector type name UNKNOWN if
the connector type is not known to mpv.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on the idea behind emersion's change to drm_info
(https://github.com/ascent12/drm_info/commit/869e789a645b92a99e592a230fe39b0c59a2cd7d).
Lets us by default skip devices which are not capable of doing what
the DRM master output requires (not primary devices), as some devices
have card0 actually not be such.
Negative part is that the number given to drm-connector is no
longer a direct mapping against a file name.
|
|
|
|
|
|
|
|
| |
Upon re-examination I have no idea why this code was ever written or
what problem it was trying to solve. But, getting rid of it fixes #9291.
It might be a remnant from before 2af2fa7a27. Who knows. This code will
be replaced soon(tm) anyways.
|
|
|
|
|
|
|
| |
Regression from e13fe1299d8aefdc264e74159cce07b8bfcf722c. Apparently,
Broadcom's EGL does not support the EGL_CONTEXT_FLAGS_KHR attribute nor
EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR. Just define these as EGL_NONE and 0
respectively if we do not have them.
|
|
|
|
|
|
|
| |
With the recent refactor and quick look against the GLX code path, it's
fairly obvious, and trivial, how to add support for debug contexts.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|