The OSC changed to use select.lua for various tasks, resulting in a
significant change in user interaction. This adds a config file
which records OSC behavior changes so that the old behavior can be
restored.
Currently --script-opt=stats-font_size=n is much bigger than
--osd-font-size=n, which can confuse users, so calculate sizes the same
way.
The \fs value to replicate --osd-font-size is
${osd-font-size} * 288 / 720 with --osd-scale-by-window, and
\fs${osd-font-size} * 288 / ${osd-height}
with --osd-scale-by-window=no. This is because
sub/osd_libass.c:update_playres() sets
track->PlayResY = ass->res_y ? ass->res_y : MP_ASS_FONT_PLAYRESY,
where MP_ASS_FONT_PLAYRESY is 288.
This also works with persistent_overlay=yes.
{\fscx100}{\fscy100} would also replicate --osd-font-size with show-text
and with osd-verlay + --osd-scale-by-window, but not with osd-overlay +
--osd-scale-by-window=no.
The default sizes are multiplied by 720/288 = 2.5 to keep them the same
as before.
In the select menu there are no completions to align in a grid, so the
better looking proportional font of --osd-font can be used by default.
It is also easier to read for the visually impaired.
The text width calculation is no longer performed if the console is only
opened through select, it is only performed the first time something is
completed. This avoids having to pass an argument to get_font() to make
it use the monospace font regardless of selectable_items.
Fixes#15176.
1a558bf5c2 made osc-*list script messages aliases to show-texting the
relative properties, so use show-text directly in the menu. Also
increase the duration to be the same as the OSC buttons because the
default of 1 second is too short.
This adds --osd-bar-marker-style option which can be used to
customize OSD bar marker style. In addition to the existing triangle
style, a new style option is added to draw markers as lines.
Add support for tracking playlist_title and playlist_id metadata
corresponding to a given playlist url and the entries associated
with it.
This allows the inclusion of ytdl_playlist_title and ytdl_playlist_id
in the metadata property for single videos which have a corresponding
playlist-path property.
This commit also resolvesyt-dlp/yt-dlp#11234
Even with -Dgpl=false, some files including the documentation,
mpv.desktop, and some key binding files are still being built.
This means that mpv as a whole might not be LGPL even when the
program itself is LGPL.
Also the description that mpv is licensed under LGPLv2.1+
"if built with the -Dgpl=false configure switch" is incorrect
as it appears to give a license grant as long as the switch is
used, regardless if there is a bug in the build system that
results in a GPL file being compiled in.
Change the description to clarify this.
Remove some of the features that no longer exist or aren't directly
supported in the mpv code: Linux analog TV (DVB still supported),
SMB, bootstrap.py.
Also fix the path for mpv.desktop.
When the file is in the current working directory, stream->path points
the path user passed as arg, so it may or may not include './'.
Strip it from both to make the comparison work
Fixes: c201c4874d
For most actual desktop users, vulkan should be the a superior
experience over opengl as this point and our autoprobe should pick that.
For linux users, vulkan on wayland is rapidly seeing improvements and is
far ahead of egl. There is no sign of that changing anytime soon and
working fifo is on the horizon, so really wayland users should just all
be using vulkan from now on. For x11, there is not a big difference
between using egl vs vulkan as far as I know and both work well. macOS
already prefers the vulkan backend over the libmpv one anyways, and
finally windows still defaults to d3d11. Probably virtually no one uses
opengl on windows, but vulkan is reasonably common among windows users
and it doesn't make any sense to prefer opengl over it.
The two outliers here are Android and VK_KHR_display. On Android, vulkan
drivers are probably just a total disaster and let's not put ourselves
in that mess if there's no reason to. For VK_KHR_display, it actually
works fine except for one really big problem: VT switching doesn't work.
If you try it, enjoy losing all input and being forced to do a hard
reboot. It might be fixable if you use logind or something, but the
method of using signals like the drm context does won't work because
VK_KHR_display uses render nodes not primary nodes. Also, the opengl drm
context could support hdr in theory (some attempts were made but none
succesful) so it is probably "better". Maybe. Anyways, for these two
platforms, we still prefer opengl.
this effectively disables the workaround that picks the color/dither
depth based on the source and instead picks it based on the output
surface/pixel format.
macOS apparently always operates at 10bit internally regardless of the
display's bit depth. this changed at some point in the more recent macOS
versions, where previously macOS operated at a frame buffer depth
corresponding to the display. either 30-Bit Color (ARGB2101010) for
10bit or 24-Bit Color (ARGB8888) for 8bit.
Fixes#13767
It is redundant if you're already using the OSC, so only show the
chapter text. Also fix the documented default commands of these buttons
which were outdated.
nanahi
Guido Cella
Wertzui123
Kacper Michajłow
rkscv
Earnestly
der richter
llyyr
Dudemanguy
Rasmus Porsager