in the original commit, that removed the conditional clearing, an
incorrect assumption was made that clearing "should be practically free"
and can be done always. though, at least on macOS + intel this can have
a performance impact of up to 50% increased usage. it might have an
impact on other platforms and setups as well, but this is unconfirmed.
the reason for removing the conditional clearing was to partially work
around a driver bug on very specific setups, X11 with amdgpu and OpenGL,
to clear garbled frames on start. though it still has issues with
garbled frames in other situation like fullscreening. there is also an
open bug report on the mesa bug tracker about this. setting the
radeonsi_zerovram flag works around all of those issues.
since the flag works around all these issues and the original fix
doesn't work completely we revert it and keep our optimisation.
Fixes#8273
the screen-name and fs-screen-name option allow for specifying screens
based on their name. this is the name of the NSScreen and also reported
by the VOCTRL_GET_DISPLAY_NAMES event. the old screen and fs-screen
options by id, respectively, are preferred over these new ones.
In wayland, setting the surface on a specific monitor only works in
fullscreen so only --fs-screen-name can be implemented. Like with x11,
we prefer --fs-screen over --fs-screen-name if it is set. This may be
more useful than setting by ids because there's no guaranteed order in
which screens are added in wayland. In wayland, the name used here is
the model name detected by the output_listener.
The --screen-name and --fs-screen-name options allow for specifying
screens based on their name. For x11, this is the display name reported
by xrandr. --screen-name and --fs-screen-name mimic the --screen and
--fs-screen options respectively. If --screen is set, then --screen-name
will always do nothing. Likewise, --fs-screen-name does nothing if
--fs-screen is set.
Our canvas size calculation is affected by few factors, and rounded
down more than once - which can result in 0 width or (more typically)
height - e.g. when terminal height is one row.
If the width or height are 0 then all bets are off, so simply skip
the setups and rendering on this case. We can still recover
automatically if the terminal is resized to become bigger.
The obvious approach would be SIGWINCH, however, integrating it would
be tricky, so instead we simply poll the size on draw_frame.
This means the image won't resize automatically when still - e.g.
cover art or when paused, though it would re-fit on OSD changes.
This is commonly used by UHD/HDR sources, and mpv hilariously ignores it
up until now, just blindly mapping it to MP_CHROMA_AUTO without even so
much as a warning message.
It would be justified to add all the other chroma locations as well, but
I'm lazy and just wanted to quickly fix this bug.
The reference is allocated at reconfig and happens at least once (and
leaked at least once), but can also be called more, e.g. on zoom or
pan-and-scan changes.
The reference is allocated at reconfig (and leaked at least once), but
could theoretically be called more than once by mpv, or in the future
when the tct code is enhanced to hande e.g. pan-and-scan changes.
testdither was being created irrespective of whether
opt_fixedpal is set or not. In case of opt_fixedpal=1,
testdither is not used in the `prepare_static_palette`
code. Hence only initialize it when opt_fixedpal is 0.
In sixel_dither_initialize, replace 3 with the libsixel
SIXEL_PIXELFORMAT_RGB888. Also in sixel_encode, the 4th
parameter is supposed to be depth, which also happens
to be the value of PIXELFORMAT_RGB888, so replacing that
constant with the depth value.
For two reasons:
1. It was counter intuitive that there's an "auto" value (which is
actually a libsixel value and not an mpv one), but it's not the
default value - our default was Atkinson.
2. "auto" provides better dithering than Atkinson with libsixel, which
is especially noticeable with smooth gradients - where Atkinson has
visible banding.
In libsixel 1.8.2 the "auto" value maps to Atkinson if the output
palette has up to 16 colors, or to Floyd-Steinberg otherwise (e.g.
using fixed palette with 256 colors chooses Floyd-Steinberg).
The issue was that we only uploaded the palette to the terminal when it
changed (once on init with fixed palette, every frame with dynamic
palette with trheshold=-1, only on scene change with threshold >= 0).
Now we upload it on every frame, and it seems to fix the mlterm image
corruption both with fixed palette and also with dynamic palette with
threshold (i.e. at frames which did not upload a palette).
It's not entirely clear why it's required with mlterm.
It would seem that the palette which libsixel uses with fixed palette
matches the built in default palette in xterm, but not in mlterm.
With dynamic palette we can guess that mlterm resets the palette after a
sixel image, but that's not confirmed.
Uploading the palette on every frame doesn't seem to slow down xterm
when using fixed palette - not clear yet why uploading a different
palette (when using fixedpalette=no) slows it down while same palette
on every frame doesn't.
In mlterm there's no slowdown either way - and now also no corruption.
By default we still clear the screen, but now it's possible to leave the
last sixel image on screen.
Allows mpv to be used as img2sixel of sorts, but with our auto-fit and
various mpv scaling/filters etc.
Currently in mpv functions sixel failures return the
value status which is of type SIXELSTATUS. So changing
it to -1 which is explicit and compatible with mpv.
Also log the errors using MP_ERR/MP_LOG with the
error string returned by libsixel to have more info.
fixedpalette seems to be slightly faster than dynamic
palette, and also in mlterm it avoids corruption of
too bright values overflowing to black. Hence setting
it to be default choice instead of dynamic palette.
Resize the image based on the dimensions reported by
vo_get_src_dst_rects to correctly handle aspect ratio
that might be set/ignored.
Added pad-x and pad-y options for padding.
These options will be used to remove the extra padding.
Some terminals report the padding of 2px in the ioctl
dimensions which can't be used for displaying sixel
output. These options can be used for fine tuning
the output video resolution.
Now all the terminal size detection and calculation logic
is done in a single function at resize. Also top and left
values are computed from the dst_rect parameters to simplify
the logic for the aspect ratio based centering.
Additionally vo-sixel-rows and vo-sixel-cols options
have been added to enable the user to override the values
in case of failures with get_terminal_size2.
This commit also adds ability to handle video zoom correctly.
Whenever video-zoom is triggered, the src and dst rects
will be updated. Scaling seems to work well now.
This has no changes to mpv sixel playback behaviour.
This is required because currently the offset values
and the resolutions are being overwritten and not
remembered.
The pointer button event had no code to handle any modifier keys. So
this meant input combinations like Shift+MTBN_LEFT did not work. Fix
this by ripping out the modifier-checking code in keyboard key event to
a separate function and using it for both the keyboard and mouse events.
In the case of the mouse, it is possible that the keyboard may not exist
so be sure to check before trying to get any modifiers. Fixes#8239.
30dcfbc is a workaround for incorrect border sizes that could occur on
sway/wlroots in certain edge cases. This seemed harmless enough, but it
turns out that on mutter the extra wl_surface_commit somehow causes the
window always go to the top left of the screen after you leave
fullscreen. No idea why this occurs, but the original commit is a
workaround a sway bug and causing regressions for other users isn't
right despite the author being biased towards sway/wlroots.
This reverts commit 30dcfbc9cb.
Based on the implementation of ffmpeg's sixel backend output written
by Hayaki Saito
https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c
Sixel is a protocol to display graphics in a terminal. This commit
adds support to play videos on a sixel enabled terminal using libsixel.
With --vo=sixel, the output will be in sixel format.
The input frame will be scaled to the user specified resolution
(--vo-sixel-width and --vo-sixel-height) using swscaler and then
encoded using libsixel and output to the terminal. This method
requires high cpu and there are high frame drops for 720p and
higher resolution videos and might require using lesser colors and
have drop in quality. Docs have all the supported options listed
to fine tune the output quality.
TODO: A few parameters of libsixel such as the sixel_encode_policy
and the SIXEL_XTERM16 variables are hardcoded, might want to
expose them as command line options. Also the initialization
resolution is not automatic and if the user doesn't specify the
dimensions, it picks 320x240 as the default resolution which is not
optimal. So need to automatically pick the best fit resolution for
the current open terminal window size.
Wayland’s wl_pointer interface describes the button event’s argument as
being taken from linux/input-event-codes.h, so there is no need to
include the more generic linux/input.h.
Testing kwinft out (kwin fork), it was discovered that sometimes it
would return a ust value of 0 which subsequently resulted in incorrect
presentation statistics (i.e. large negative numbers which are obviously
impossible). Arguably, it shouldn't return 0s, but a workaround for mpv
in this case is harmless.
VOCTRL_UPDATE_RENDER_OPTS is supposed to be optional so check if it
actually exists before executing the function. Fixes a segfault when
changing the alpha value at runtime on non-wayland platforms.
7fb972f fixed transparency on x11/EGL/Mesa but happened to also break it
for wayland and nvidia. Ideally on wayland, you should just be able to
pick the right EGLConfig that has alpha but this doesn't seem to work
because reasons. So just go back to setting the EGL_ALPHA_SIZE bit if
the user asks for alpha. Apparently this worked before for nvidia as
well. The hack is to just run an eglQueryString in the x11egl context.
If it picks up Mesa as the EGL_VENDOR, then force ctx->opts.want_alpha
to 0 and let pick_xrgba_config take care of the rest.
Made possible with 00b9c81. 34b8adc let the wayland surface set an
opaque region depending on if alpha was set by the user or not. However,
there was no attempted detection for runtime changes and it is possible
(at least in wayland vulkan) to toggle the alpha on and off. So this
meant, we could be incorrectly signalling an opaque region if the user
happened to change the alpha. Additionally, add a helper function for
this and use it everywhere we want to set the opaque region.
vo_gpu has a small set of options for ra_ctx that can be set. In
practice, runtime toggling doesn't matter for most of these as they have
no effect while a video is playing. However, changing the alpha option
during runtime can actually work depending on the backend used. mpv
already detected when one of these options changed, but it made no
attempt to update the options in the ra_ctx accordingly (likely because
nothing made any use of this information). Another related change is to
add an update_render_opts to the fns and allow invidiual backends to
(optionally) use it.
efb0c5c changed the rendering logic of mpv on wayland and made it skip
rendering when it did not receive frame callback in time. The idea was
to skip rendering when the surface was hidden and be less wasteful. This
unfortunately had issues in certain instances where a frame callback
could be missed (but the window was still in view) due to imprecise
rendering (like the default audio video-sync mode). This would lead to
the video appearing to stutter since mpv would skip rendering in those
cases.
To account for this case, simply re-add an old heuristic for detecting
if a window is hidden or not since the goal is to simply not render when
a window is hidden. If the wait on the frame callback times out enough
times in a row, then we consider the window hidden and thus begin to
skip rendering then. The actual threshold to consider a surface as
hidden is completely arbitrary (greater than your monitor's refresh
rate), but it's safe enough since realistically you're not going to miss
60+ frame callbacks in a row unless the surface actually is hidden.
Fixes#8169.
Pointless feature that can be done with environment variables. It was
also implemented incorrectly and broke autoprobing.
This reverts commit 015b676875.
As per the client API, a client can connect to any arbitrary wayland
socket. mpv has always just passed NULL which connected to the
compositor currently in use, but one could just as easily pass the name
of a different socket (i.e. the value of WAYLAND_DISPLAY). Here, we just
expose this argument as a user configurable option. If the user passes a
socket name that does not exist, then print a warning and fall back to
NULL.
Apparently a part of the wayland spec. A compositor may use a surface
that has set part of itself as opaque for various optimizations. For
mpv, we simply set the entire surface as opaque as long as the user has
not set alpha=yes (note: alpha is technically broken in the wayland EGL
backend at the time of this commit but oh well). wlshm is always opaque.
Fixes#8125.
on macOS 10.15 setting the activation policy behaves quite weirdly. the
call changes the current active App to a nameless process, which
probably also the reason that prevents the not focusing to work.
a workaround for that, is to refocus the previous active app.
Fixes#7725
Back in the olden days, mpv's wayland backend was driven by the frame
callback. This had several issues and was removed in favor of the
current approach which allowed some advanced features (like
display-resample and presentation time) to actually work properly.
However as a consequence, it meant that mpv always rendered, even if the
surface was hidden. Wayland people consider this "wasteful" (and well
they aren't wrong). This commit aims to avoid wasteful rendering by
doing some additional checks in the swapchain. There's three main parts
to this.
1. Wayland EGL now uses an external swapchain (like the drm context).
Before we start a new frame, we check to see if we are waiting on a
callback from the compositor. If there is no wait, then go ahead and
proceed to render the frame, swap buffers, and then initiate
vo_wayland_wait_frame to poll (with a timeout) for the next potential
callback. If we are still waiting on callback from the compositor when
starting a new frame, then we simple skip rendering it entirely until
the surface comes back into view.
2. Wayland on vulkan has essentially the same approach although the
details are a little different. The ra_vk_ctx does not have support for
an external swapchain and although such a mechanism could theoretically
be added, it doesn't make much sense with libplacebo. Instead,
start_frame was added as a param and used to check for callback.
3. For wlshm, it's simply a matter of adding frame callback to it,
leveraging vo_wayland_wait_frame, and using the frame callback value to
whether or not to draw the image.
