This backend is a special case where the state of the frame (i.e. is it
still) needs to be taken into account when flipping the page because it
does its own fencing. vo_gpu_next never calls the submit_frame API in
ra_swapchain which meant the drm backend wasn't aware of the state of
the frames and thus couldn't respond. This is a bit weird though because
in vo_gpu we actually want the ra_gl_ctx_submit_frame call after the
custom external drm_egl_submit_frame. But we don't want this in
vo_gpu_next, we only want the state update. Be lazy and just compare the
vo_drivers, but the way this is currently designed feels wrong. Fixes
delayed OSD rendering when you play a still image like an audio
file with cover art.
The comment is true, but just passing an empty ra_gl_ctx_params does
exactly the same thing. There's no reason to specifically use the
external_swapchain API.
These were separate for some reason which makes no sense and is really
annoying if you want to use something that's in the vk version and not
the gl one or vice versa. As a bonus, these now get to live right above
the ra_swapchain definition which is more convenient.
Not all compositors will send another action after the data_device entry
event. We currently assume this which always causes the previously set
action to be overwritten with the default value (-1). The easiest way to
solve this is to simply save the old dnd_offer action value and then
reapply it after we update it to the pending_offer. Fixes#15939.
This ensures a clear separation between public and private headers. It
also makes it clear in Meson and prevents the accidental use of private
headers.
I don't know why I didn't get it before but Lua's LSP now complains with
Compute `"Edition " .. (edition.id + 1)` first. You may need to add
brackets. [ambiguity-1].
Just move the parenthesis to make it happy.
osd_surface is a sync sub-surface of video_surface meaning that a commit
of osd_surface will not take effect until the next commit of
video_surface.
Some compositors (wlroots) do not implement sync sub-surface correctly,
meaning that the difference cannot be observed there. But it can easily
be seen on Jay and GNOME:
1. Open an mpv window.
2. Pause the video.
3. Enter the surface with the mouse.
Expected behavior:
1. The OSD shows up immediately.
Actual behavior:
1. Nothing happens for a few seconds.
2. The OSD shows up and immediately fades out.
This is because the fade-out commits cause the initial osd_surface
commit to become effective.
This reverts part of PR #15899 (commit dd6e3a0ece).
"Why is this even useful?": It's very useful for multi-disc playlists. Compare:
`mpv bd:///DISC{1..4}`
`mpv -\{ bd:// --bluray-device=DISC1 -\} -\{ bd:// --bluray-device=DISC2 -\} -\{ bd:// --bluray-device=DISC3 -\} -\{ bd:// --bluray-device=DISC4 -\}`
Basically just bits of a9d83eac40 that was
removed and ported to here. Not really smart but it seems like flushing
buffers during seek generally leads to better behavior and avoids some
errors. The additional stream_seek call that was being performed is
definitely bogus (will never work and spams errors). So that is skipped
for bd/dvd. SEEK_FORCE is no longer needed. Instead demux_disc calls
drop_buffers on the slave demuxer (i.e. lavf).
Need to shuffle some stuff around but it's pretty simple. Mute the
audio stream before the frame step and then unmute it when we're done.
It's exactly the same as the default play mode otherwise.
You probably wouldn't guess what this does from the name alone, but it
actually selects a range of tracks to play. It's slightly different than
using --start because it confines the range to just that track and you
cannot seek before it. The functionality is useful, but you can
accomplish exactly the same thing with --start and --end. Also the
implementation of the cdda option is weird because starting from a track
after 1 makes it impossible to seek before it. There's no reason to have
this when using the core option is simply better and works fine.
This is allowed but it's pretty weird. You'd end up typing something
like dvd:////dev/sr0 or cdda:///dev/sr0 (notice the differing amount of
/). Why is this even useful? Just use the matching --cdda-device option.
There's no need to have two ways to do the same thing here.
modal dialogs steal the key/mouse input and possibly eat corresponding
key up events when opening via key binding. this leads to key sequence
ends to not reported and key bindings not being triggered if no key up
event was triggered after closing the modal.
This is only needed for spawning main mpv process, there is no need to
spin CRT just to call main() and support basic memcpy.
Additionally adjust compilation flags to reduce the size of mpv.com.
This is the small binary using only kernel32 as dependecy now.
Stripped mpv.com built with clang 19.1.7 (x86_64-w64-windows-gnu)
Before:
text data bss dec hex filename
6982 7281 0 14263 37b7 mpv.com
After:
text data bss dec hex filename
1094 2894 0 3988 f94 mpv.com
Depending on compiler and options the size may vary. For example with
-flto and -Wl,-gc-sections it is:
text data bss dec hex filename
833 750 0 1583 62f mpv.com
but gc-sections were rejected as an default option before.
As a bonus add some error checking to this code.
No need for pointless prefix, print error directly. Don't use CRT
function. This will write only to console, but it's not meant to be
written to file anyway.
This adds --video-aspect-method=ignore to replace --video-aspect-override=0.
--video-aspect-override=0 and --video-aspect-override=-1 will no longer be
handled specially. For compatibility, 0 is mapped to always use ignore
and -1 is always mapped to always use container.
"no" is now the replacement for --video-aspect-override=-1, which is
internally remapped to -2 to avoid using a deprecated value.
This is poorly implemented and will break existing scripts which set
the value directly with double without a string value, like
mp.set_property_native, or if the value is set with add/multiply commands.
Revert this until a better solution is found.
This reverts commit cb91de2a34.
Maybe the xx version was different (probably not), but looking over this
code again it's pretty clear that there is a lot of unneeded
complication. There's no need to keep track of the image description,
creator params, etc. globally. This can all be passed around on the fly.
Also, reset_color_management was redundant because it would execute on
reconfig and also on the first draw after the reconfig. We don't need
both so delete the reconfig path. Collapse the various color functions
into one simple "set_color_management" and let the wayland listeners do
all the object destroying for us.
343a5fd345 killed all mmal hardware
decoding, but there was still some junk lying around. There's
IMGFMT_MMAL still, but that's harmless to keep around.
I started doing this in f594482451 for
protocol objects that were newer than the lowest version, but I can't
remember why (some waf-related reason?). This wasn't even followed for
other PRs merged recently like ext-data-control and color-management.
Anyways, it's not needed and works fine if you're on wayland-protocols
1.31 so stop doing this void weirdness.
Dudemanguy