| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Failing to do this results in the shader cache not actually ever being
written, ergo no shader caching being done. Oops.
|
| |
|
|
|
|
|
|
|
| |
The only way to fix the channel order here is to create the texture with
bgra format. Incidentally, there used to be a way to set the component
map for overlays directly, but no more. Shouldn't matter since
everything supports bgra8 anyways, though.
Fixes #9699
|
| |
|
|
|
| |
This was a misnomer, the actual channel order is IMGFMT_BGRA (as the
comment explicitly point out). Rename the enum for consistency.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This merges the old desaturation control options into a single
enumeration, with the goal of both simplifying how these options work
and also making this list more extensible (including, notably, new
options only supported by vo_gpu_next).
For the hybrid option, I decided to port the (slightly tweaked) values
from libplacebo's pre-refactor defaults, rather than the old values we
had in mpv, to more visually match the look of the vo_gpu_next hybrid.
|
| |
|
|
|
|
|
| |
Merge --gamut-clipping and --gamut-warning into a single option,
--gamut-mapping-mode, better corresponding to the new vo_gpu_next APIs
and allowing us to easily extend this option as new modes are added in
the future.
|
| |
|
|
|
| |
Properly forward the HDR metadata from the mpi to the equivalent (new)
fields in pl_color_space. Used by the new tone mapping code.
|
| |
|
|
|
|
|
| |
This was significantly refactored upstream. Switch to new APIs and add
new tone mapping curves and options.
cf. https://code.videolan.org/videolan/libplacebo/-/merge_requests/212
|
| |
|
|
| |
This is in nits, so it needs to be converted.
|
| |
|
|
|
|
| |
This is only needed on Android and supposed to handle a context
resize without reconfiguring the image parameters. reconfig()
already does exactly this so plug it in there.
|
| |
|
|
|
|
|
|
|
| |
`plane_data_from_imgfmt` doesn't zero-initialize the struct, so this
contained invalid values for e.g. `row_stride`, causing formats to
*randomly* fail. (Especially any formats with specific alignment
requirements)
Might fix #9424 and #9425.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Somewhat annoying but still relatively straightforward. There are
several ways to approach this, but I settled on reusing the pl_queue as
a cheap way to get access to the currently mapped frame. This saves us
from having to process `vo_frame` at all, and also avoids any overhead
from re-uploading the same frame twice.
(However maybe there's some circumstance in which `vo_frame` needs to be
queried/updated first, to get a screenshot of the correct frame? I'm not
sure.)
I also had the option of going with either pl_render_image() on the
extract pl_frame, or just calling pl_render_image_mix directly on it. I
went for the latter, because in the optimal case, this allows the
rendered frame to be directly retrieved from the cache, actually
entirely avoiding any sort of recompute overhead. This makes e.g. ctrl+s
during playback essentially free. (Except for the download cost,
obviously)
It would be even neater if we could make this VOCTRL asynchronous and
thereby leverage libplacebo's asynchronous download capabilities. But oh
well. That will have to wait for a sufficiently rainy day.
Closes #9388
|
| |
|
|
| |
In preparation of VOCTRL_SCREENSHOT support
|
| |
|
|
|
|
| |
As noticed in #9526, apparently there's some case in which DR buffers
get corrupted. Add an explicit sentinel check to try and figure out
which cases these are.
|
| |
|
|
|
| |
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.
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
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 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.
|
| |
|
|
|
|
| |
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.
|
