1669c4698d notably flipped the default of
--subs-with-matching-audio from yes to no as part of a series of changes
that gave more control over sub selection behavior. While the increased
amount of options is definitely nice, changing the default to no results
in very unintuitive behavior. For example, setting alang=en and slang=en
in your config will not show any subtitles since the audio stream is
English as well so --subs-with-matching-audio being no causes the subs
to not be be selected. This is very weird for users who reasonably
expect slang being set to actually result in showing subs and this is
what mpv did for the past decade.
The other case is when a subtitle does not have a language tag but is
flagged as default. Because --subs-fallback (a new option), defaults to
no, these subtitles also will not be loaded. This is also strange for
users since mpv previously loaded these and they would need to change
the value of this option. It's also inconsistent because audio tracks
that are tagged as default are also loaded by default.
The new behavior seems to have mostly just confused users, and it also
regresses their configs for unclear reasons. Let's just set the options
to be back in line with the old behavior with is what most users expect.
--subs-with-matching-audio goes back to being yes and the new option
--subs-fallback should be default. Fixes#11854.
Make it clearer that you should be using --hwdec with this VO. Also make
some comments about the things that are required for this to work
correctly (i.e. working drivers/GPU and the right compositor).
To remain consistent with our belief that `auto-safe` should be the
recommended mode when turning on hw decoding, let's remap `yes` from
`auto` to `auto-safe`.
It has been odd that ctrl+h toggles `auto` for hwdecs even though we
always recommend people start with `auto-safe`, and `auto` will attempt
various hwdecs that can fail so badly we can't fall back to software
decoding.
With the change to more exhaustively attempt to use hwdecs, it is now
easier to get into situations where these fragile hwdecs will get
attempted in basic scenarios, like pressing ctrl+h.
So it is high time to default to `auto-safe`.
This adds osd support via shm buffers using a similar approach that the
normal buffers do, but it differs in a few key areas. One thing to note
is that sway and weston actually handle this extremely differently which
required all the abstractions here. In particular, weston does not cope
well with destroying the wl_buffer from shm outside of the release
handler at all (i.e. it segfaults). The workaround here is to simply
attach a NULL to the osd surface and do a surface commit before we
destroy the buffers. This is reasonable enough and seems to work well
although it's pretty weird. Sway is more straightforward although it
actually releases the osd buffer when the window goes out of sight.
Also, I found that it doesn't always release every buffer before you
close it unlike weston seems to do which is part of the reason all this
bookkeeping is required. I don't know if there's any other compositor
out there that can possibly handle vo_dmabuf_wayland right now, but
suffering through these two is good enough for now I think.
Directories were always loaded recursively, which can be slow
(e.g. one of the subdirectories is a mounting point to a slow device)
and can unexpectedly expand into a massive playlist.
Due to the problems described in 503dada42f,
this defaults to recursive loading.
ref. https://github.com/mpv-player/mpv/issues/9652
--no-config should prevent loading user files of any type: configs,
cache, etc. For cache files, this case wasn't properly handled and it
was assumed they would always get something. vo_gpu's shader cache
actually already handles this, so it was left untouched. In theory,
demuxer cache should never have this issue because saving it to disk is
disabled by default (and likely that will never change), but go ahead
and change it for consistency's sake. Fixes some segfaults with
--no-config and various combinations of settings (particularly
--vo=gpu-next).
4502522a7a changed the way mpv handled and
saved cached files. In particular, it made a separate boolean option for
actually enabling cache and left the *-dir options as purely just a path
(i.e. having a dir set didn't mean you save cache). This technically
regressed people's configs, so let's just turn the cache on by default.
Linux users already expect random stuff in ~/.cache and well everyone
else can just live with some files possibly appearing in their config
directory.
Add an option for allowing pointer events to pass through the mpv
window. This could be useful in cases where a user wants to display
transparent images/video with mpv and interact with applications beneath
the window. This commit implements this functionality for x11 and
wayland. Note that whether or not this actually works likely depends on
your window manager and/or compositor. E.g. sway ignores pointer events
but the entire window becomes draggable when you float it (nothing under
the mpv window receives events). Weston behaves as expected however so
that is a compositor bug. Excuse the couple of completely unrelated
style fixes (both were originally done by me).
Notes:
- converts the (image) write() api to filenames, because using avio
with FILE* is a pain.
- adds more debug logs for screenshots.
build: rename av1 dependency to avif_muxer
wscript: unify lavf dependency with meson
Today, the only way to make mpv consider multiple hwdecs and pick the
first one that works is to use one of the `auto` modes. But the list
that is considered in those cases is hard-coded. If the user wants to
provide their own list, they are out of luck.
And I think that there is now a significant reason to support this -
the new Vulkan hwdec is definitely not ready to be in the auto list,
but if you want to use it by default, it will not work with many codecs
that are normally hardware decodable (only h.264, hevc and av1 if you
are very lucky). Everything else will fall back to software decoding.
Instead, what you really want to say is: use Vulkan for whatever it
supports, and fall back to my old hwdec for everything else.
One side-effect of this implementation is that you can freely mix
hwdec names and special values like `auto` and `no`. The behaviour will
be correct, so I didn't try and prohibit any combinations. However,
some combinations will be silly - eg: sticking any further values after
`no` will result in them being ignored. On the other hand, a
combination like `vulkan,auto` could be very useful as that will use
Vulkan if possible, and if not, run the normal auto routine.
Fixes#11797
Some platforms (wayland) apparently have a lot of trouble with drag and
drop. The default behavior is still the same which is basically obeying
what we get from the window manager/compositor, but the --drag-and-drop
option allows forcibly overriding the drag and drop behavior. i.e. you
can force it to always replace the playlist or append at the end. This
only implements this in X11 and Wayland but in theory windows and macos
could find this option useful (both hardcode the shift key for
appending). Patches welcome.
It is worth adding this example because it has been asked multiple times
in the issue tracker and the IRC channel.
string.find() is used because it's 20 times faster than string.match().
Vulkan Video Decoding has finally become a reality, as it's now
showing up in shipping drivers, and the ffmpeg support has been
merged.
With that in mind, this change introduces HW interop support for
ffmpeg Vulkan frames. The implementation is functionally complete - it
can display frames produced by hardware decoding, and it can work with
ffmpeg vulkan filters. There are still various caveats due to gaps and
bugs in drivers, so YMMV, as always.
Primary testing has been done on Intel, AMD, and nvidia hardware on
Linux with basic Windows testing on nvidia.
Notable caveats:
* Due to driver bugs, video decoding on nvidia does not work right now,
unless you use the Vulkan Beta driver. It can be worked around, but
requires ffmpeg changes that are not considered acceptable to merge.
* Even if those work-arounds are applied, Vulkan filters will not work
on video that was decoded by Vulkan, due to additional bugs in the
nvidia drivers. The filters do work correctly on content decoded some
other way, and then uploaded to Vulkan (eg: Decode with nvdec, upload
with --vf=format=vulkan)
* Vulkan filters can only be used with drivers that support
VK_EXT_descriptor_buffer which doesn't include Intel ANV as yet.
There is an MR outstanding for this.
* When dealing with 1080p content, there may be some visual distortion
in the bottom lines of frames due to chroma scaling incorporating the
extra hidden lines at the bottom of the frame (1080p content is
actually stored as 1088 lines), depending on the hardware/driver
combination and the scaling algorithm. This cannot be easily
addressed as the mechanical fix for it violates the Vulkan spec, and
probably requires a spec change to resolve properly.
All of these caveats will be fixed in either drivers or ffmpeg, and so
will not require mpv changes (unless something unexpected happens)
If you want to run on nvidia with the non-beta drivers, you can this
ffmpeg tree with the work-around patches:
* https://github.com/philipl/FFmpeg/tree/vulkan-nvidia-workarounds
This adds cache as a possible path for mpv to internally pick
(~/.cache/mpv for non-darwin unix-like systems, the usual config
directory for everyone else). For gpu shader cache and icc cache,
controlling whether or not to write such files is done with the new
--gpu-shader-cache and --icc-cache options respectively. Additionally,
--cache-on-disk no longer requires explicitly setting the --cache-dir
option. The old options, --cache-dir, --gpu-shader-cache-dir, and
--icc-cache-dir simply set an override for the directory to save cache
files. If unset, then the cache is saved in XDG_CACHE_HOME.
A pain point for some users is the fact that watch_later is stored in
the ~/.config directory when it's really not configuration data. Roughly
2 years ago, XDG_STATE_DIR was added to the XDG Base Directory
Specification[0] and its description, user-specific state data, actually
perfectly matches what watch_later data is for. Let's go ahead and use
this directory as the default for watch_later. This change only affects
non-darwin unix-like systems (i.e. Linux, BSDs, etc.). The directory
doesn't move for anyone else.
Internally, quite a few things change with regards to the path
selection. If the platform in question does not have a statedir concept,
then the path selection will simply return "home" instead (old
behavior). Fixes#9147.
[0]: 4f2884e16d
This finally allows us to put any user defined options into the
CONFIGURATION variable like what waf does. The arbitrary hardcoded
fallback is left in place for old meson versions. Also update the
documentation in regards to the mpv-configuration variable to be
relevant to meson.
Instead of erroring when values returned by profile-cond expressions
aren't booleans, apply the relative profiles as long as the return
values are truthy. This allows shortening conditions like
profile-cond=path:match('foo') ~= nil
to
profile-cond=path:match('foo')
Since meson has its own unit testing system, let's rework mpv's tests so
they integrate nicely with this. To prepare for this, start off by
dropping the unittest option. Of course, this means that tests will no
longer be supported in the waf build at all but it will be dropped
anyway. Note that the tests option is preserved for the meson build. We
will still make use of this in the future commits.
mpv's window resizing logic always automatically resized the window
whenever the video resolution changed (i.e. advancing forward in a
playlist). This simply introduces the option to make this behavior
configurable. Every windowing backend would need to implement this
behavior in their code since a reconfigure event must always be a
resize. The params of the frame changed so you either have to resize the
window to the new size of the params or make the params the same size as
the window. This commit implements it for wayland, win32, and x11.
These options make it possible to specify the directory that will be
passed to ass_set_fonts_dir(), akin to VLC's `--ssa-fontsdir` and
FFmpeg's `fontsdir`.
Fixes#8338
This returns the value of the target OS that mpv was built on as
reported by the build system. It is quite conceivable that script
writers and API users would need to make OS-dependent choices in some
cases. Such people end up writing boilerplate/hacks to guess what OS
they are on. Assuming you trust the build system (if you don't, we're in
really deep trouble), then mpv actually knows exactly what OS it was
built on. Simply take this information at configuration time, make it a
define, and let mp_property_platform return the value.
Note that mpv has two build systems (waf and meson), so the names of the
detected OSes may not be exactly the same. Since meson is the newer
build system, the value of this property follows meson's naming
conventions*. In the waf build, there is a small function to map known
naming deviations to match meson (i.e. changing "win32" to "windows").
waf's documentation is a nightmare to follow, but it seems to simply
take the output of sys.platform in python and strip away any trailing
numbers if they exist (exception being win32 and os2)*.
*: https://mesonbuild.com/Reference-tables.html#operating-system-names
*: https://waf.io/apidocs/Utils.html#waflib.Utils.unversioned_sys_platform
The playlist title only got set when it was specified in the
playlist file.
If there is a title after opening a file, that should also be reflected
in the playlist.
ref. #4780
PipeWire supports a global volume control for streams that works on top
of the per-channel volumes.
As mpv only supports a single volume with ao-volume it can make sense to
use the single global volume from PipeWire for it.
This allows the user to also specify per-channel volumes and not have
mpv trample over them.
This mode is not the default as pulseaudio does not support this
global volume control and all tooling controlling PipeWire via
pipewire-pulse (like pavucontrol) will not be able to see this channel.
This option is a bit obscure, but some people do use it and it can be
useful. The actual code that implements this is very simple, so there's
really no need to have a scary note in the docs about it possibly
changing or being removed.
With significant improvements to the color tagging support in various
screenshot formats, e.g. cICP in FFmpeg, and JPEG XL's generally robust
color support, it's safe to default this to yes.
Previously, this defaulted to yes and configure-bounds from the
compositor would always apply. In the case where the user explicitly set
autofit or geometry, this could be confusing because configure-bounds
would take precedence over it. Instead, let's add an auto choice and
make that the default. If we detect that the option is on auto and that
there is autofit/geometry being set, then ignore the event. This should
be more intuitive since someone who bothers to explicitly set mpv's
geometry would naturally expect that geometry to actually apply.
This reverts:
3fb4140c lua/defaults: add user_data helpers
68a20e7a javascript/defaults: add user_data helpers
00510379 lua/js: fix user_data_del util function
As well as the lua/js parts of:
3ec2a098 docs: document new user-data property
user-data and its sub-properties can be set/get/observed/deleted
via the standard properties interface, so there's no need for
additional helpers specific to user-data, which only added maintenance
burden.
--vd-lavc-dr defaulted to "yes", which caused issues on certain
hardware. Instead of disabling it, add a new "auto" value and
make it the default.
The "auto" choice will enable DR only when we can request host-cached
buffers (as signalled by the new VO_DR_FLAG_HOST_CACHED).
Co-authored-by: Nicolas F. <ovdev@fratti.ch>
Co-authored-by: Niklas Haas <git@haasn.dev>
The situation here is that HWND is always a 32-bit value but the
win32 API also accepts sign-extended values as valid. The trouble
starts when the numeric value is negative, as mpv ignores those.
Apparently this only happens after a while (related to uptime
or number of handles created), which meant this problem was rare.
addresses #10189
The watch-later mechanism has always unconditionally wrote start to
files to save the playback position. When this was later expanded to
watch-later-options, this logic was kept in place. But we don't actually
have to unconditionally write this and can allow users to remove the
option from the list if they want to. The start value still requires
some special handling; it should always be written if possible
regardless of the value changing. However, we can just place it within
the default set of options for watch-later-options so it can be removed
like any other.
So far there was no way to sync video to display and have audio sync to
video without changes in pitch.
With this option the audio does not get resampled (pitch change) and
instead the corrected audio speed is applied to audio filters.
Buffering ahead nonstop into the cache results in nonstop disk or network
activity to read stream data from wherever it may originate. Currently,
there's no way to configure the demuxer to back off once it's buffered
ahead enough data, since the cache limit will be perpetually not-reached as
a stream continues to play, until the entire stream is eventually buffered.
On a laptop with an i9-12900H with decoding performed by the iGPU,
watching a locally-saved 1080p video which hasn't been buffered into the
page cache consumes approximately 15 W even with caching enabled. When
configuring a hysteresis to make the demuxer back off, power consumption
drops to 9 W when watching the same video, resulting in a whopping 6 W of
power savings.
To make it possible to attain significant power savings via caching, add
a --demuxer-hysteresis-secs option to configure a hysteresis to make the
demuxer back off until there's only the configured number of seconds
remaining in the cache from the current playback position.
This feature is disabled by default.
See https://sw.kovidgoyal.net/kitty/graphics-protocol/
This makes no attempt at querying terminal features or handling
terminal errors, as it would require mpv to pass the response codes
from the terminal to the vo instead of interpreting them as
keystrokes made by the user and acting very unpredictably.
Tested with kitty and konsole.
Fixes#9605
currently only supported on x11.
one practical use-case of this is wanting to embed something (such as
dmenu) into the mpv window to use as a menu/selection. there might be
other use-cases as well (e.g doing some shenanigans with `xdotool` or
whatnot).
it's currently possible to:
* listen for 'current-window-scale' change (to check if the
window has been created or not)
* call an external tool like `xdo` or `xdotool` and grab the xid
from mpv's pid.
however it adds unnecessary dependency on external tools when mpv is
fully capable of easily providing this information.
closes: #10918
The legacy DRM API adds some complexity to the DRM code. There
are only 4 drivers that do not support the DRM Atomic API:
1. radeon (early GCN amd cards)
2. gma500 (ancient intel GPUs)
3. ast (ASPEED SoCs)
4. nouveau
Going forward, new DRM drivers will be guaranteed to support the atomic
API so this is a safe removal.
The content-type protocol allows mpv to send compositor a hint about the
type of content being displayed on its surface so it could potentially
make some sort of optimization. Fundamentally, this is pretty simple but
since this requires a very new wayland-protocols version (1.27), we have
to mess with the build to add a new define and add a bunch of if's in
here. The protocol itself exposes 4 different types of content: none,
photo, video, and game.
To do that, let's add a new option (wayland-content-type) that lets
users control what hint to send to the compossitor. Since the previous
commit adds a VOCTRL that notifies us about the content being displayed,
we can also add an auto value to this option. As you'd expect, the
compositor hint would be set to photo if mpv's core detects an image,
video for other things, and it is set to none for the special case of
forcing a window when there is not a video track. For completion's sake,
game is also allowed as a value for this option, but in practice there
shouldn't be a reason to use that.
mpv has an internal optimization on a couple of platforms where it will
not render any frames if the window is minimized or hidden. There's at
least once possible use case for wanting to force a render anyway
(screensharing with pipeware) so let's just add a simple switch for
this that always forces mpv to render. Closes#10846.
This is a very simple but easy way of doing it. Ideally, it would be
nice if we could also add some sort of introspection about shader
parameters at runtime, ideally exposing the entire list of parameters as
a custom property dict. But that is a lot of effort for dubious gain.
It's worth noting that, as currently implemented, re-setting
`glsl-shader-opts` to a new value doesn't reset back previously mutated
values to their defaults.
Deduplicate history like the fish shell. So for example
entering "cmd 1" then "cmd 2" then "cmd 3" then "cmd 1"
would result in a history of
[cmd 2][cmd 3][cmd 1]
instead of
[cmd 1][cmd 2][cmd 3][cmd 1]
Adds a function `history_add` to replace directly adding to history.
Adds an option `history_dedup` to activate the deduplication.
Defaults to on.
vo_dmabuf_wayland has its own ra and context so it can handle all the
different hwdec correctly. Unfortunately, this API was pretty clearly
designed with vo_gpu/vo_gpu_next in mind and has a lot of concepts that
don't make sense for vo_dmabuf_wayland. We still want to bolt on a
ra_ctx, but instead let's rework the ra_ctx logic a little bit. First,
this introduces a hidden bool within the ra_ctx_fns that is used to hide
the wldmabuf context from users as an option (unlike the other usual
contexts). We also want to make sure that hidden contexts wouldn't be
autoprobed in the usual ra_ctx_create, so we be sure to skip those in
that function. Additionally, let's create a new ra_ctx_create_by_name
function which does exactly what says. It specifically selects a context
based on a passed string. This function has no probing or option logic
is simplified just for what vo_dmabuf_wayland needs. The api/context
validations functions are modified just a little bit to make sure hidden
contexts are skipped and the documentation is updated to remove this
entries. Fixes#10793.
Wayland VO that can display images from either vaapi or drm hwdec
The PR adds the following changes:
1. a context_wldmabuf context with no gl dependencies
2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects
no-op because there is no need to map/unmap the drmprime buffer,
and there is no need to manage any textures.
Tested on both x86_64 and rk3399 AArch64
Pushing E (aka Shift+e) cycles through Editions for containers
that support editions, such as Matroska, although this feature was not
documented before this commit.
We've had some annoying names for interops, which we can't simply
rename because that would break config files and command lines. So we
need to put a little more effort in and add a concept of legacy names
that allow us to continue loading them, but with a warning.
The two I'm renaming here are:
* vaapi-egl -> vaapi (vaapi works with Vulkan too)
* drmprime-drm -> drmprime-overlay (actually describes what it does)
* cuda-nvdec -> cuda (cuda interop is not nvdec specific)
This has had no effect since libplacebo v4.192.0, and was deprecated
upstream a year ago. No deprecation period in mpv is justified by this
being a debug / work-around option.
Removed the outdated information about environmental brightness
with respect to --gamma-factor, and mention that the option is
deprecated and subject to future removal. Also deprecated the
--gamma-auto option as it relies on the same outdated way of doing
things.
In wayland-protocols 1.25, xdg-shell got a version bump which added the
configure_bounds event. The compositor can send this to clients to
indicate that they should not resize past a certain size. For mpv, we'll
choose to only listen to this on reconfig events (i.e. when the window
first appears and if the video resolution changes later in the
playlist). However, this behavior is still exposed as a user option
(default on) because it will neccesarily conflict with a user setting a
specific geometry size and/or window scale. Presumably, if someone is
setting a really large size that goes beyond the bounds of their
monitor, they actually want it like that. The wayland-protocols version
is newer-ish, but we can get around having to poke the build system by
just using a define that exists in the generated xdg-shell header.
In the confusing landscape of hardware video decoding APIs, we have had
a long standing support gap for the v4l2 based APIs implemented for the
various SoCs from Rockship, Amlogic, Allwinner, etc. While VAAPI is the
defacto default for desktop GPUs, the developers who work on these SoCs
(who are not the vendors!) have preferred to implement kernel APIs
rather than maintain a userspace driver as VAAPI would require.
While there are two v4l2 APIs (m2m and requests), and multiple forks of
ffmpeg where support for those APIs languishes without reaching
upstream, we can at least say that these APIs export frames as DRMPrime
dmabufs, and that they use the ffmpeg drm hwcontext.
With those two constants, it is possible for us to write a
hwdec-interop without worrying about the mess underneath - for the most
part.
Accordingly, this change implements a hwdec-interop for any decoder
that produces frames as DRMPrime dmabufs. The bulk of the heavy
lifting is done by the dmabuf interop code we already had from
supporting vaapi, and which I refactored for reusability in a previous
set of changes.
When we combine that with the fact that we can't probe for supported
formats, the new code in this change is pretty simple.
This change also includes the hwcontext_fns that are required for us to
be able to configure the hwcontext used by `hwdec=drm-copy`. This is
technically unrelated, but it seemed a good time to fill this gap.
From a testing perspective, I have directly tested on a RockPRO64,
while others have tested with different flavours of Rockchip and on
Amlogic, providing m2m coverage.
I have some other SoCs that I need to spin up to test with, but I don't
expect big surprises, and when we inevitably need to account for new
special cases down the line, we can do so - we won't be able to support
every possible configuration blindly.
Whether or not the GNOME project has a tendency to make life
difficult for anyone outside their ecosystem, the user manual is
no place for childish rants such as this.
Keep it to what is relevant for users.
Generally, the hard-coded sizes used for the OSC elements are
comfortable regardless of the font used, but the timecode fields have
relatively many characters, and so are affected to a greater degree by
fonts with a wider or narrower average character width than expected.
This allow users to adjust the space reserved for the timecode fields to
compensate.
Previously if the raw command_native_async returned an error then the
callback function was run directly. This meant that script writers
potentially had to account for both synchronous and asynchronous logic
in the callback, which can happen even with seemingly 'safe' commands
if the mpv event queue is full.
This was at odds with the Javascript implementation of
the function, which always runs the callback asynchronously.
Now the mp.add_timeout function is used to run the callback
asynchronously on error, replicating the Javascript implementation.
This provides consistency for developers in how the callback is handled
in Lua, and increases consistency between the Lua and Javascript APIs.
With the recent addition of the libxpresent, it should improve frame
timings for most users. However, there were known cases of bad behavior
(Nvidia) which lead to a construction of a whitelist instead of just
enabling this all the time. Since there's no way to predict whatever
combination of hardware/drivers/etc. may work correctly, just give users
an option to switch the usage of xorg's presentation statistics on/off.
The default value, auto, works like before (basically, Mesa drivers and
no Nvidia are allowed), but now one can force it on/off if needed.
The `absolute` value was incorrectly labelled as the default instead of
the value named `default`, which was somewhat confusing. When the newer
default option was added in 679e410 it seems like wm4 forgot to remove
the label in the manual on the previous default.
This is mainly for other user scripts that may conflict with the osc
logo in some way. Although it is possible to listen for
shared-script-properties, this has many edge cases that could easily pop
up. A user could want other OSC things to happen at the same time (say
osc-message). They just don't want the logo. The idlescreen option
disables all idlescreen related things (including the santa hat) if it
is set to "no". A new script message (osc-idlescreen) is also added so
users can easily toggle the value (passing "cycle" or just explictly
setting "yes" or "no"). Some more discussion on this is found in the
below github issues.
https://github.com/mpv-player/mpv/issues/10201https://github.com/CogentRedTester/mpv-file-browser/issues/55
This driver makes use of dmabuffer and viewporter interfaces
to enable efficient display of vaapi surfaces, avoiding
any unnecessary colour space conversion, and avoiding scaling
or colour conversion using GPU shader resources.
Add Jpeg XL as a possible output format for screenshots, which
should make it possible to take fast screenshots with much better
quality than JPEG, or take lossless high-bit-depth screenshots
with lower file sizes than PNG.
- Say built-in which is more common than builtin
- Move "By default" because only the key to open the console is
customizable, and fix the punctuation and case of the sentence
- ` opens the console, not ´
- Remove the sentences that explains which user script console.lua is
based on since it's no longer relevant now that the console has been
part of mpv for over 2 years.
Now that a separate --cover-art-whitelist option exists, files like
cover.jpg are loaded even without setting --cover-art-auto to fuzzy, so
only load files that have exactly the media filename by default, since
fuzzy loading is probably more likely to load unwanted images than to
load cover art that the user intended to display, especially if you play
audio files with a short filename like a.mp3.
This allows more fine grained control over which cover art to load. With
--cover-art-auto=exact and --cover-art-whitelist=yes, you can now load
cover art with the exact media filename and the whitelisted filenames,
but not cover art that contains the media filename
(--cover-art-auto=fuzzy).
This adds a section to the documentation to explain how resuming
playback works, and in particular it explains how it affects which
playlist entry mpv starts playing from, since this feature was only
implied in the --playlist-start documentation.
It also groups the documentation of the watch later options together to
make them easier to find.
Variable Refresh Rate (VRR), aka Freesync or Adaptive Sync can be used
with DRM by setting the VRR_ENABLED property on a crtc if the
connector reports that it is VRR_CAPABLE. This is a useful feature
for us as it is common to play 24/25/50 fps content on displays that
are nominally locked to 60Hz. VRR can allow this content to play at
native framerates.
This is a simple change as we just need to check the capability
and set the enabled property if requested by the user. I've defaulted
it to disabled for now, but it might make sense to default to auto
in the long term.
The documentation's current discussion of hwdec usage is out of date,
and unnecessarily pessemistic when applied to modern hardware. The
reality is that modern APIs on modern hardware produce reasonable
results and there's no need to pretend otherwise. The current language
that tries to drive people away from using hwdecs at all leads to them
making bad choices when they do try to use it.
Let's also make it clearer that users should use vo=gpu with hwdecs
rather than vo=vaapi or vo=vdpau. Even the existing admonitions have
proven insufficient, so let's strengthen that language.
There are two major ways of going about this:
1. Expose the native ra_gl/ra_pl/ra_d3d11 objects to the pre-existing
hwdec mappers, and then add code in vo_gpu_next to rewrap those
ra_tex objects into pl_tex.
2. Wrap the underlying pl_opengl/pl_d3d11 into a ra_pl object and expose
it to the hwdec mappers, then directly use the resulting pl_tex.
I ultimately opted for approach 1 because it enables compatibility with
more hardware decoders, specifically including ones that use native
OpenGL calls currently. The second approach only really works with
cuda_vk and vaapi_pl.
I was initially hesitant to link to an external article from the manpage
but a lot of other places in the man page already do something like
this, and it really makes more sense to have this as a wiki article
rather than trying to keep the manpage up-to-date by hand, since this
evolves quickly and the two are expected to converge over time.
The stop-screensaver option is currently limited to a simple yes/no
option. While the no option does always disable mpv trying to stop the
screensaver, yes does not mean the screensaver is always stopped. The
screensaver will be enabled again depending on certain conditions (like
if the player is paused). Simply introduce a new value for this option,
always, which does exactly what the name implies: the screensaver will
always be disabled.
- Make it clearer that playback_only affects subprocess' behavior when
the playback of the current playlist entry terminates, rather than
when mpv quits.
- Explain when status is positive and when it is negative.
- Replace "exited gracefully" in status' and error_string's
documentation with "terminated normally" so it can't be misinterpreted
as exiting successfully.
- Reword the playback_only warning
We have a few examples with vf=rotate=90, but libavfilter's rotate
accepts radians - not degrees, so a value of 90 is valid but misleading
because it's not 90 degrees.
Change the value of 90 at those examples.
Also replace "vf-add=hflip" with "vf add hflip", since that example
lists commands, not options, to run.
When utils.get_user_path was added, the expand-path command didn't
exist. Now it does, so remove the C code, make it a trivial wrapper.
Keep this function for backward compat to not break scripts, but
technically it's not required anymore.
Currently the profile-restore field is intentionally omitted if it
holds the default value (i.e. no values are stored for the profile,
and trying to restore would only warn).
See m_config_get_profiles at command.c .
Changes:
- rewrite to use new internal MPV API;
- code refactoring;
- fix buffers size calculations;
- buffer set to auto;
- reset() - clean/reinit device only after errors;
Previously, the sub-visibility option changed the visibility of all
subtitles including secondary ones. This meant that it was not possible
to only display secondary subtitles while hiding the primary ones. This
modifies the sub-visibility option so that it only affects primary
subtitles which allows only secondary subtitles to be displayed.
This reverts commit 04f0b0abe4.
It's not a good idea to unify the names only for visibility, while
keeping secondary-* for everything else.
This needs a bit more thought before we allow secondary sub to be
visible on its own.
Adds --sub-visibility choices 'primary-only' for only displaying the
primary subtitle track, and 'secondary-only' for only displaying
secondary subtitle track.
Removes --secondary-sub-visibility and displays a message telling the
user to use --sub-visibility=yes/primary-only instead.
These changes make it so that the default 'sub-visibility' bind 'v'
cycles through all the 'sub-visibility' choices, 'no', 'yes',
'primary-only', and 'secondary-only'.
The AO provides a way for mpv to directly submit audio to the PipeWire
audio server.
Doing this directly instead of going through the various compatibility
layers provided by PipeWire has the following advantages:
* It reduces complexity of going through the compatibility layers
* It allows a richer integration between mpv and PipeWire
(for example for metadata)
* Some users report issues with the compatibility layers that to not
occur with the native AO
For now the AO is ordered after all the other relevant AOs, so it will
most probably not be picked up by default.
This is for the following reasons:
* Currently it is not possible to detect if the PipeWire daemon that mpv
connects to is actually driving the system audio.
(https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1835)
* It gives the AO time to stabilize before it is used by everyone.
Based-on-patch-by: Oschowa <oschowa@web.de>
Based-on-patch-by: Andreas Kempf <aakempf@gmail.com>
Helped-by: Ivan <etircopyhdot@gmail.com>
Useful to strip dolbyvision from the output, in cases where the user
does not want it applied. Doing this as a video filter gives users the
abiilty to easily toggle this stripping at runtime in a way that
properly propagates to any (potentially stateful) VO.
It also thematically fits the rest of the options in vf_format, which
are similarly concerned with modifying the video image parameters.
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.
Not all deprecated symbols were removed. Only three events were removed for now
since these are not used internally.
This bumps the library version to 2.0.
Previously OSD was always displayed on {ch,pl}_{next,prev} left-click,
and seekbar-hover-chapter was always enabled and with fixed format.
Now it can be controlled with:
- chapters_osd, playlist_osd: yes/no (only affects left-click).
- chapter_fmt: lua string.format template, or "no" to disable.
Fixes#4675
The audio rewrite in d27ad96542 originally
broke this ao. However, 0ac724f002 fixed
and the documentation was never updated to reflect that. OpenAL has
worked fine for a while not. Just remove this sentence.
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.
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.
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.
mpv doesn't have other dot files in its config dir, and it also
shouldn't be "invisible".
The new name ~~/init.js now replaces ~~/.init.js
While mpv usually deprecates things before outright removing them,
in this case the old (dot) name is replaced without deprecation:
- It's a bad idea to execute hidden scripts, even if at a config dir,
and we don't want to do that for the next release cycle too.
- We warn if the old (dot) name exists and the new name doesn't,
which should be reasonably visible for affected users.
- It's likely niche enough to not cause too much pain.
If for some reason both names are needed, e.g. when using also an old
mpv versions, then the old name could be symlinked to the new one, or
simply have one line: `require("~~/init")` to load the new name, while
a new mpv version will load (only) the new name without warning.
As the documentation of the toggle says - the implementation can (and
will actually if they follow the GLX/EGL spec) return context version
greater than the one requested.
This happens with all Mesa drivers that I've tested as well as the
Nvidia binary drivers.
This toggle seems like a workaround for buggy drivers, yet it's lacking
context about the vendor and version.
Remove it for now - I'll be happy to reinstate it (partially or in full)
as we get concrete details.
This allows us to simplify ra_gl_ctx_test_version() making the whole
context creation business easier to follow by mere mortals.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
This behavior is more convenient and allows profile conditions like:
[video]
profile-cond=get('current-tracks/video/image') == false
[image]
profile-cond=get('current-tracks/video/image')
Otherwise, these profiles have to be manually applied and restored in a
script.
The note about discouraging the use of current-tracks in scripts is
removed, because it makes people avoid using this convenient property.
It was added in 720bcd79d0 without leaving an explanation of why you
shouldn't use it, and the only reason seems to be that it doesn't work
with lavfi-complex, but this commit changes that.
This exposes whether a video track is detected as an image, which is
useful for profile conditions, property expansion and lavfi-complex.
The lavf demuxer sets image to true when the existing check detects an
image.
When the lavf demuxer fails, the mf one guesses if the file is an image
by its extension, so sh->image is set to true when the mf demuxer
succeds and there's only one file.
The mkv demuxer just sets image to true for any attached picture.
The timeline demuxer just copies the value of image from source to
destination. This sets image to true for attached pictures, standalone
images and images added with !new_stream in EDL playlists, but it is
imperfect since you could concatenate multiple images in an EDL playlist
(which should be done with the mf demuxer anyway). This is good enough
anyway since the comment of the modified function already says it is
"Imperfect and arbitrary".
The custom init script should be considered a configuration file, and
as such it should be ignored when the user wants vanilla mpv - and now
it is ignored with --no-config.
This is similar to [no-]input-default-bindings, but affects only
builtin bindings (while input-default-bindings affects anything which
config files can override, like scripting mp.add_key_binding).
Arguably, this is what input-default-binding should have always done,
however, it does not.
The reason we add a new option rather than repurpose/modify the
existing option is that it behaves differently enough to raise
concerns that it will break some use cases for existing users:
- The new option is only applied once on startup, while
input-default-bindings can be modified effectively at runtime.
- They affects different sets of bindings, and it's possible that
the set of input-default-bindings is useful enough to keep.
Implementation-wise, both options are trivial, so keeping one or the
other or both doesn't affect code complexity.
It could be argued that it would be useful to make the new option
also effective for runtime changes, however, this opens a can of
worms of how the bindings are stored beyond the initial setup.
TL;DR: it's impossible to differentiate correctly at runtime between
builtin bindings, and those added with mp.add_key_bindings.
The gist is that technically mpv needs/uses two binding "classes":
- weak/builtin bindings - lower priority than config files.
- "user" bindings - config files and "forced" runtime bindings.
input-default-bindings affects the first class trivially, but
input-builtin-bindings would not be able split this class further
at runtime without meaningful changes to a lot of delicate code.
So a new option it is. It should be useful to some libmpv clients
(players) which want to disable mpv's builtin bindings without
breaking mp.add_key_bindings for scripts.
Fixes#8809
(again. the previous fix 8edfe70b only improved the docs, while
now we're actually making the requested behavior possible)
Unfortunately, this functionality in large part based on a struct
member that was made private in FFmpeg/FFmpeg@7489f63281
in May. Unfortunately, this was not noticed during review.
This reverts commit 0862664ac9.
This exposes whether a video track is detected as an image. This is
useful for profile conditions, property expansion and lavfi-complex, and
is more accurate than any detection even Lua scripts can perform, since
they can't differentiate between images and videos without container-fps
and audio and with duration 1 (which is the duration set by the mf
demuxer with the default --mf-fps=1).
The lavf demuxer image check is moved to where the number of frames is
available for comparison, and is modified to check the number of frames
and duration instead of the video codec. This doesn't misdetect videos
in a codec commonly used for images (e.g. mjpeg) as images, and can
detect images in a codec commonly used for videos (e.g. 1-frame gifs).
pix files are also now detected as images, while before they weren't
since the condition was checking if the AVInputFormat name ends with
_pipe, and alias_pix doesn't.
Both nb_frames and codec_info_nb_frames are checked because nb_frames is
0 for some video codecs (hevc, av1, vc1, mpeg1video, vp9 if forcing
--demuxer=lavf), and codec_info_nb_frames is 1 for others (mpeg, mpeg4,
wmv3).
The duration is checked as well because for some uncommon codecs and
containers found in FFMpeg's FATE suite, libavformat returns nb_frames =
0 and codec_info_nb_frames = 1. For some of them it even returns
duration = 0, so they are blacklisted in order to never be considered
images.
The extra codecs that would have to be blacklisted without checking the
duration are AV_CODEC_ID_4XM, AV_CODEC_ID_BINKVIDEO,
AV_CODEC_ID_DSICINVIDEO, AV_CODEC_ID_ESCAPE130, AV_CODEC_ID_MMVIDEO,
AV_CODEC_ID_NUV, AV_CODEC_ID_RL2, AV_CODEC_ID_SMACKVIDEO and
AV_CODEC_ID_XAN_WC3, while the containers are film-cpk, ivf and ogg.
The lower limit for duration is 10 because that's the duration of
1-frame gifs.
Streams with codec_info_nb_frames 0 are not considered images because
vp9 and av1 have nb_frames = 0 and codec_info_nb_frames = 0, and we
can't rely on just the duration to detect them because they could be
livestreams without an initial duration, and actually even if we could
for these codecs libavformat returns huge negative durations like
-9223372036854775808.
Some more images in the FATE suite that are really frames cut from a
video in an uncommon codec and container, like cine/bayer_gbrg8.cine,
could be detected by allowing codec_info_nb_frames = 0, but then any
present and future video codec with nb_frames = 0 and
codec_info_nb_frames = 0 would need to be added to the blacklist. Some
even have duration > 10, so to detect these images the duration check
would have to be removed, and all the previously mentioned extra codecs
and containers would have to be added added to the blacklists, which
means that images that use them (if they exist anywhere) will never be
detected. These FATE images aren't detected as such by mediainfo either
anyway, nor can a Lua script reliably detect them as images since they
have container-fps and duration > 0 and != 1, and you probably will
never see files like them anywhere else.
For attached pictures the lavf demuxer always set image to true, which
is necessary because they have duration > 10. There is a minor change in
behavior for which audio with attached pictures now has mf-fps as
container-fps instead of unavailable, but this makes it consistent with
external cover art, which was already being assigned mf-fps.
When the lavf demuxer fails, the mf one guesses if the file is an image
by its extension, so sh->image is set to true when the mf demuxer
succeds and there's only one file.
Even if you add a video's file type to --mf-type and open it with the mf
protocol, only the first frame is used, so setting image to true is
still accurate.
When converting an image to the extensions listed in demux/demux_mf.c,
tga and pam files are currently the only ones detected by the mf demuxer
rather than lavf. Actually they are detected with the image2 format, but
it is blacklisted; see d0fee0ac33.
The mkv demuxer just sets image to true for any attached picture.
The timeline demuxer just copies the value of image from source to
destination. This sets image to true for attached pictures, standalone
images and images added with !new_stream in EDL playlists, but it is
imperfect since you could concatenate multiple images in an EDL playlist
(which should be done with the mf demuxer anyway). This is good enough
anyway since the comment of the modified function already says it is
"Imperfect and arbitrary".
Because youtube-dl is inactive and the yt-dlp fork is becoming more
popular, make mpv use yt-dlp without any extra configuration.
yt-dlp is ordered before youtube-dl because it's more obscure, so users
who have yt-dlp installed are more likely to want to use it rather than
youtube-dl.
Fixes#9208.
The "cycle" command _declaration_ enables repeatability by default,
however, the command handler applies additional logic to augment it,
based on the property which is being cycled - using some guesswork.
Specifically, properties with discrete values are not repeatable
(like sub or osd-level), while continuous properties are repeatable
(like volume).
Previously, the "repeatable" prefix could not override this additional
logic.
This commit changes the behavior so that the logic affects only the
default repeatability (still based on the property like before),
however, the "repeatable" prefix is now allowed to override it.
Previously, a list of commands was always considered repeatable.
This behavior was added at 6710527a (and moved around since then),
in order to fix#807 (impossible to make a repeatable list).
The problem was that a list doesn't have the normal repeatability
flags and so it was never repeatable, so it was hardcoded to be
repeatable instead. Presumably it was deemed good enough.
However, this made it impossible to have a non-repeatable list.
This commit changes the behavior so that a list repeatability is
that of the first command at the list.
This way, any list can be made either repeatable or non-repeatable
using the following idiom (e.g. at input.conf), based on the fact
that the "ignore" command is not repeatable by default:
x ignore; cmd1...; cmd2... # non-repeatable
y repeatable ignore; cmd1...; cmd2... # repeatable
Fixes#7841
Discovered with:
find . -type f \( -name '*.md' -o -name '*.rst' \) -exec grep -n 'http://' {} +
All real, i.e. non-example, links found were moved to https. There are
some dead links and websites with no https available which were not
converted.
Discovered with:
find . -type f \( -name '*.md' -o -name '*.rst' \) -exec grep -n 'http://' {} +
All links to mpv.io or github.com/mpv-player that were http were
converted to https.
- Replace the legacy --osd-status-msg with the newer --osd-msg3.
- Escape \b in show-text "This is ${osd-ass-cc/0}{\b1}bold text".
- Link the Flat command syntax section because it's no longer true that
you always need to escape \, since C escape sequences are not
interpreted with single and custom quotes.
