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.
The previous wording gave the false impression that there was no media
key support for OSes besides Windows and macOS. This is untrue, the
option may only exist on those two platforms but it simply means that
media keys will always be enabled on other OSes as long as they are
supported.
There's currently some touch related code in mpv wayland, but clearly
nobody actually uses because it's a broken mess. Initially an attempt to
distinguish between two finger touches and one finger touch was made,
but there's not a good way to make this work. For whatever reason,
initiating either xdg_toplevel_resize or xdg_toplevel_move blocks any
other touch events from occurring (at least in plasma). Trying to call
these functions anywhere else is not really useful since the serial will
be invalid outside of the touch down events (well it would work in the
touch up event but that's just silly).
Anyways, let's just make this work sanely. Eliminate the touch entries
variable completely because it's pointless. Only one finger event is
ever considered at a time. Touches besides the initial one are all
ignored. If a user touches and drags within the touch edge radius, then
a resize event occurs. If the user touches and drags elsewhere on the
window, a move event occurs. A single tap displays the osc (which is
clickable if you tap again). A double tap toggles fullscreen.
Additionally, the default touch edge radius of 64 pixels is way too big
(at least I think so). Cut this in half to 32 which feels a lot better
(on a pinephone using plasma mobile anyway).
The window-scale property mirrors the respective option (not the
effective scale derived from the current window size), and as such
setting its value to the same value it had before has no effect.
Specifically - the window will not resize.
This is consistent as far as property-option bridge behavior goes,
but we do end up with an issue that we can't set an arbitrary scale
and expect the window to always resize accordingly.
We do also have a current-window-scale property which does reflect
the actual window size, however, it's been read-only till now.
This commit makes current-window-scale RW so that it's now always
possible to set an arbitrary scale and expect the window to resize
accordingly (without affecting window-scale - like manual resize).
Also, mention window-scale no-effect-if-not-changed at the docs.
Based on code by @Dudemanguy from commit 873ae0d, with same effect.
This reverts commit 873ae0de2a.
The next commit will restore this functionality, with the
following differences from the reverted commit:
- Smaller and simpler code change.
- On bad scale: use "Invalid value" (compared to "no such property").
- Doesn't combine the docs for window-scale and current-window-scale.
- Doesn't remove the docs for window-scale behavior prior to 0.31.0.
Somewhat confusingly, mpv has both a window-scale option and a
current-window-scale property. The documentation lists window-scale
under properties (and it is technically is one), but at its core it is
actually an option which means it behaves subtly different. Options in
mpv are runtime-configurable, but they only change anything if the value
of the option itself changes. window-scale is an option and not meant to
keep track of the actual scale of the window (intended behavior
introduced by d07b7f0). This causes window-scale to do nothing in
certain cases (ex: the window is manually resized and window-scale is
set to 1.00 again). This is logical and consistent with the behavior of
the rest of the mpv options, but it also makes it a poor candidate for
setting the mpv window scale dynamically.
As a remedy, we can just make current-window-scale writeable instead.
current-window-scale is intended to always report the actual scale of
the window and keep track of any window size changes made by the user.
By making this property also writeable, it allows the user to have more
intuitive behavior (i.e. setting current-window-scale to 1.00 always
sets the window to a scale of 1). Additionally, the default input.conf
is changed to use current-window-scale instead of window-scale. The
window-scale documentation under property list is removed since it is
already documented under options and users should probably set the
current-window-scale property instead in most cases.
Using --sub-filter-regex-plain (default:no)
The ass-to-plaintext functionality already existed at sd_ass.c, but
it's internal and uses a private buffer type, so a trivial utility
wrapper was added with standard char*/bstr interface.
The plaintext can be multi-line, and the multi-line regexp flag is now
always set, but only affects plaintext (the ASS source is one line).
Pretty much identical to filter-regex but with JS expressions and
requires only JS support. Shares the filter-regex-* control options.
The target audience is Windows users - where filter-regex doesn't
work due to missing APIs, but mujs builds cleanly on Windows, and JS
is usually enabled in 3rd party Windows mpv builds.
Lua could have been used with similar effort, however, the JS regex
syntax is more extensive and also much more similar to POSIX.
Users expect single quotes to work when the value includes literal
backslashes or double-quotes (or as general quoting like in shell).
The updated docs also include some previously-missing notes:
- newline is only supported in double quotes.
- adjacent (quoted) arguments don't join into one.
Supporting mixed quoting (adjacent quoted strings) would make
mpv's parsing more complete, but would require delicate effort of
larger scope, for two reasons:
- We'd need to also support escaping outside of quotes and do our
best about backward compatibility.
- The parsed value can either be a substring of the input or
a newly-allocated string, which would be delicate when joining.
Not critical to add right now.
Custom quotes were added in 4f129a3e and began with !, however, this
required quoting "!reverse" (used for the cycle-values command), which
is inconvenient, and was not taken into account when ! was chosen for
custom quotes. Also, ` is more natural for quoting than !.
This does break backward compatibility with the earlier form of custom
quotes, but at least we didn't make a release yet since custom quotes
were added (the last release - 0.33[.1] doesn't support it).
Let audio-display determine whether embedded images or external cover
art tracks should be selected when both are present.
Attached pictures are given priority by default as requested in #8539.
Also updates references to attached pictures in the log and manpage to
refer to cover art as well.
Closes#8539.
This fix the warnings shown below when compiling the manual for
any of its three common formats:
```
DOCS/man/mpv.rst:46: (ERROR/3) Unknown target name: "--input-test".
DOCS/man/stats.rst:183: (ERROR/3) Unknown target name: "--input-test".
```
In rst, double-backtick starts a code string only if it's followed by
a non-space char, otherwise it's taken literally, hence, `` x2.0``
was taken literally rather than code string.
--watch-later-options-remove doesn't accept multiple options, so split
the example.
Also suggest the more correct -clr to empty the list, and remove the
workaround to not print an error with --watch-later-options=
This allows configuring which options are saved by quit-watch-later.
Fixes#4126, #4641 and #5567.
Toggling a video or audio filter twice would treat the option as changed
because the backup value is NULL, and the current value of vf/af is a
list with one empty item, so obj_settings_list_equal had to be changed.
Unlike the page switching/scrolling keys which are bound at runtime
and therefore we need to know which (configured) keys to bind, the
main keys (i/I by default) are static and can be bound via input.conf.
And indeed, the builtin bindings at etc/input.conf have them already.
- The video filter to turn the video upside-down is vflip. There is no
filter called "flip" so using it just causes an error.
- Reword a sentence.
- Add exact and all to the values accepted by cover-art-auto. They were
implemented in 029ff1049b but not added to the accepted arguments.
While --input-test is useful, and so is page 4 of stats, until now
there was no way to simply print the list in a help-like fashion.
This commit adds such printout, invoked by the script opt
stats-bindlist=yes, which uses the existing page 4 code. This prints
the list on startup and quits immediately - like any help page.
It's awkward to invoke compared to other help pages, and it does
require the stats page to be enabled (it is by default), however
it is a script-generated output, and currently there's no other
method to print a help page generated by a script.
The printout itself is performed using lua's io.write. While reliable,
it's not the standard way for mpv to print to the terminal.
Other possible printout methods are mp.msg.info - which also prints
"[stats]" prefix on each line (ugly), or forcing term-osd and setting
an osd-message which mpv will then print at the terminal - however
that's printed to stderr, and could also be subject to timing concerns
since we quit right afterwards.
In the future we can consider changing/integrating the invocation so
that mpv itself could print a help page generated by a script, thus
solving both the awkward invocation and printout-method issues.
This is a scrollable page which also works nicely with the terminal
OSD. Typically there are more than 100 bound keys.
It groups the binding using fuzzy property/command/script name after
simple analysis of the command string, and then further sorts the
binding in each group according to the "complexity" of the key itself
(plain keys -> keys with modifiers, alphabetically, etc).
The alignment/grouping style is heavily inspired by @medhefgo's #8924
but otherwise it's an independent implementation.
The --secondary-sub-visibility options was previously undocumented in
the pull request that added it. This commit adds documentation for it
and clarifies its behavior.
Modifies the sub-seek and sub-step commands with a second <flags>
argument to specify whether to seek/step on the primary or secondary
subtitles. The flag is used to index into the current_track array in
cmd_sub_step_seek.
Adds secondary-sub-start and secondary-sub-end properties by setting
the current_track index in the m_property's priv variable which later
gets accessed in get_times. Also adds a test of the secondary subtitle
time properties in tests/subtimes.js bound to 'T'.
Not sure what I was on when I wrote this. wayland-app-id is supposed to
default to "mpv". Just set that in the vo_sub_opts and don't do this
weird m_config_cache_write_opt thing. Also make the doc entry nicer.
This fixes a long-standing apparent issue where mpv would display the last
frame with no subtitles at EOF. This is caused by sub rendering switching from
video timestamps to audio timestamps when the video ends, and audio streams
often running past the timestamp of the last video frame. However, authoring
tools (most notably Aegisub) don't tend to provide easy ways to add meaningful
subtitles after the end of the video, so this is rarely actually useful.
This makes cover-art-auto behave more like sub-auto and audio-file-auto:
- load cover art with a language, e.g. if playing foo.mp3, foo.en.jpg
will be loaded with lang=en
- load cover art containing the media filename with fuzzy and all, e.g.
'foo (large).jpg'
- make all/2 load all images in the directory, and make fuzzy/1 the
default
These are all uncommon use cases, but synchronizing the behavior of the
external file options simplifies the code.
Commit 6abb7e3 updates the markers when the chapters change, but it
doesn't update their relative position at the bar when the duration
changes.
This means that adding chapters to a live stream would result in
corresponding chapter markers which were static while the duration
changed and thus their positions became incorrect over time until the
OSC was reinitialized.
This is fixed by observing the duration property if chapters are present
and reinitializing the OSC when the duration changes.
The live_markers user option, which determines whether the duration
property is observed when there are chapters, has been added in order to
allow disabling this behaviour as calling request_init() frequently
might have some impact on low-end systems.
The impact of request_init() on render() was measured to increase from
1-1.5 ms to 2-3 ms on a 2010 MacBook Air, while the impact was neglible
on a 2016 Surface Book (increasing only to an average of 1.4 ms from
1.3 ms for n=1500 render cycles).
The live_markers option is enabled by default.
This is the Vulkan equivalent of the drm context for OpenGL, with
the big difference that it's implemented purely in terms of Vulkan
calls and doesn't actually require drm or kms.
The basic idea is to identify a display, mode, and plane on a device,
and then create a display backed surface for the swapchain. In theory,
past that point, everything is the same, and this is in fact the case
on Intel hardware. I can get a video playing on a vt.
On nvidia, naturally, things don't work that way. Instead, nvidia only
implemented the extension for scenarios where a VR application is
stealing a display from a running window system, and not for
standalone scenarios. With additional code, I've got this scenario to
work but that's a separate incremental change.
Other people have tested on AMD, and report roughly the same behaviour
as on Intel.
Note, that in this change, the VT will not be correctly restored after
qutting. The only way to restore the VT is to introduce some drm
specific code which I will illustrate in a separate change.
And also change the existing WM_KILLFOCUS handler to return 0 instead
of 'break' (which later calls DefWindowProcW), as MSDN says we should
do for WM_{KILL,SET}FOCUS.
It seems that the 'focused' property is now supported by all main VOs:
x11, macOS, wayland, Windows.
TCT/sixel/caca probably don't support it, and unknown with SDL.
Fixes#8868
Not only does this have semantics that make far more sense, it also has
a default that makes far more sense. (Equivalent to the old
`icc-contrast=inf`)
This removes the weird 1000:1 contrast default assumption which
especially broke perceptual profiles and also screws things up for
OLED/CRT/etc.
Should probably close some issues but I honestly can't be bothered to
figure out which of the thousands colorimetry-related issues are
affected.
Add new header which shows up as tags/metadata (associated with
--display-tags). The way this is added means it doesn't always work,
because root->meta (see code) can be NULL for some absurd reason. But it
works for the one case I intended to use it (ytdl_hook, see next
commit), though only in default configurations.
For some reason, this never existed before. Add VOCTRL_GET_DISPLAY_RES
and use it to obtain the current display's resolution from each
vo/windowing backend if applicable. Users can then access the current
display resolution as display-width and display-height as per the client
api. Note that macOS/cocoa was not attempted in this commit since the
author has no clue how to write swift.
This commit describes more accurately what currently gets disabled
by this option - specifically also keys from mp.add_key_binding.
It's not necessarily the best behavior because libmpv clients might
want to disable mpv's own builtin keybindings while still allowing
scripts to define keys which `input.conf' can override.
In the future we might exclude mp.add_key_binding from this option,
but for now at least document this option accurately.
Fixes#8809
The ctime member on Windows uses FILE_BASIC_INFO.ChangeTime, which is
pretty much the same as st_ctime on POSIX.
See https://devblogs.microsoft.com/oldnewthing/20100709-00/?p=13463 :
... The LastWriteTime covers writes to the file’s data stream
(which you accomplish via the WriteFile function). On the other
hand, the ChangeTime also includes changes to the file metadata,
such as changing its file attributes ...
Fixes#8801
Some subproperties in osd-dimensions were returned as doubles despite
actually being integers. Additionally, correct a highly misleading line
in the osd-width/osd-height documentation.
The accurate description of this option was:
- fit-border is enabled by default. When disabled, it adds a bug where
if the window has borders and mpv shrinks it to fit the desktop, then
the calculation ignores the borders and adds incorrect video crop.
The option was added at commits 70f64f3c and 949247d6, in order to
solve an issue (#2935) where if mpv wanted to display a video with
size WxH, then w32_common.c incorrectly set the window to WxH, while
down-scaling the video slightly to fit (even with small sizes).
It was addressed with a new option which is enabled by default, but
does the right thing (sets the client area to WxH) only when disabled,
so that everyone who prefers their video slightly downscaled could
keep their default behavior.
(#2935 also addressed an off-by-one issue, fixed before fit-border)
While disabling the option did avoid unnecessary downscaling, it also
added a bug when disabled: the borders are no longer taken into
account when the size is too big for the desktop. Most users don't
notice and are unaffected as it's enabled by default.
Shortly later (981048e0) the core issue is fixed, and now the client
area is correctly set to WxH instead of the window (and together with
the three following commits which center the video, adds a new bug
where the window title can be outside the display - addressed next).
However, fit-border remained, now without any effect, except that it
still has the same bug when disabled and the window is too big.
Later code changes and refactoring preserved this issue with great
attention to details, and it remained in identical form until now.
Simply rip out fit-border.
When mpv attempts to play a video that is, on average, 60 FPS on a
display that is not exactly 60.00 Hz, two options try to fight each
other: `video-sync-max-video-change` and `interpolation-threshold`.
Normally, container FPS in something such as an .mp4 or a .mkv is
precise enough such that the video can be retimed exactly to the display
Hz and interpolation is not activated.
In the case of something like certain live streaming videos or other scenario
where container FPS is not known, the default option of 0.0001 for
`interpolation-threshold` is extremely low, and while
`video-sync-max-video-change` retimes the video to what it approximately
knows as the "real" FPS, this may or may not be outside of
`interpolation-threshold`'s logic at any given time, which causes
interpolation to be frequently flipped on and off giving an appearance
of stuttering or repeated frames that is oftern quite jarring and makes
a video unwatchable.
This commit changes the default of `interpolation-threshold` to 0.01,
which is the same value as `video-sync-max-video-change`, and guarantees
that if the user accepts a video being retimed to match the display,
they do not additionally have to worry about a much more
precise interpolation threshold randomly flipping on or off. No internal
logic is changed so setting `interpolation-threshold` to -1 will still
disable this logic entirely and always enable interpolation.
The documentation has been updated to reflect this change and give
context to the user for which scenarios they might want to disable
`interpolation-threshold` logic or change it to a smaller value.
Changes:
- code refactored;
- mixer options removed;
- new mpv sound API used;
- add sound devices detect (mpv --audio-device=help will show all available devices);
- only OSSv4 supported now;
Tested on FreeBSD 12.2 amd64.
Apple has decided that Mac OS X is now named macOS for the time
being. For consistency, it makes sense to use the same name for the
operating system in all places where it occurs. This commit renames
OS X to macOS in the documentation in places where it was otherwise
still using the old name.
Where X is any ASCII char chosen by the user. An argument is only
interpreted as custom-quoted if it starts with '!' and the line doesn't
end right after it. Custom quotes don't interpret backslash-escape.
This change only affects command arguments which mpv parses (not array
commands), and not tokens before the arguments (where applicable - key
name, input section, command prefixes, command name).
currently we use the whole screen rectangle to calculate the window
geometry. this doesn't take the menu bar or the Dock into account.
by default use the visible screen rectangle instead. this is also a
change in behaviour, since the window can't be placed outside of this
rectangle anymore. also add an option to change to the old behaviour,
because it can still be useful in certain cases, like placing the window
directly underneath the menu bar when used a desktop background.
Fixes#8272
--alpha=yes doesn't affect only transparent videos and images, but also
the background. I spent time researching how to implement transparent
backgrounds and had no idea that they already worked at least on
Wayland.
Background transparency will work on X11 when
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2376 is
merged. It doesn't work on Windows. No idea about macOS. Either way,
this paragraph already says that it only works on certain environments
twice.
References #6590
With the current wording, I thought that playlist-prefetch doesn't
prefetch the next url within a playlist of m3u8 urls, but it makes a big
difference, and I would have enabled it earlier if it wasn't for this
paragraph.
This makes it clear that you can prefetch any file, but that it won't
prefill the cache with the video data. This is true for any video,
there's nothing unique about HLS streams in the behavior of this option.
Simple groundwork for adding a couple of user options that allow
selecting the screen with a string name. The next two commits implements
these options for xorg and wayland.
While this says that _ is replaced with -, it doesn't say that you HAVE
to use _. This isn't obvious and I didn't understand why my profile
conditions with - weren't working at first. Seeing as the person who
reproted #8324 ran into this as well, this may be worth clarifying.
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.
This reverts commit 3d17e19c2c.
The effect of turning off this setting is that mpv doesn't tell libass what
the video stream's resolution is. This happens to result in some files having
their transforms scaled in ways that give higher performance (as described
in #7435) because libass happened to guess a video resolution that resulted
in transforms yielding smaller bitmaps, but it's just as easy for the opposite
to happen depending on the resolutions and effects involved.
The option's name is also somewhat misleading: setting the storage size affects
blur, but it also affects stroke (which is far more important for the vast
majority of scripts) and 3D transforms (which look very screwy when done wrong).
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.
Having them in the same line made it hard to read them in the man page
since they are formatted in the same way and they look as though they
are only one definition.
Recent versions of mpv have applied security checks to --playlist
that previously only existed if playlist files were played as an
input directly. This commit documents this change and how to work
around it, in the event that playlist files are trusted.
Apparently mpv supports loading config files from the same directory as
the mpv.exe. This is a fallback of some sort. It used the old_home
mechanism.
I want to add a warning if old_home exists, but that would always show
the warning on win32. Obviously we don't want that.
Add a separate exe_dir entry to deal with that.
Untested, but probably works.
Mistakenly reverted as part of the default configuration directory
location switch-back in aa18a8e1cd.
Separation of the mpv executable directory from old_path is a
good change now that we warn about the old_config directory also
existing.
Fixes#8232Fixes#8244Fixes#8262
This can be viewed at page 4 of the internal stats display (i or I).
CPU time report is the same as at lua.c, but untested - doesn't seem
to work on windows - also not for lua.
TL;DR: Set env MPV_LEAK_REPORT=1 to enable js memory reporting stats.
This also almost doubles the memory usage by js scripts.
For memory reporting, we don't have enough info by default, because
even when using a custom allocator, mujs doesn't report the old size
(on free or realloc) because it doesn't track this value, and as
a result we can't track the overall size.
Our option are either to track the size of each allocation on our own,
or use talloc which tracks this value.
However, using talloc for mujs allocations adds a considerable
overhead, and almost doubles(!) the overall memory used, because each
individual allocation includes a considerable talloc header, and mujs
does many small allocations.
So our solution is that by default we behave like previously - not
using a custom allocator with mujs, and stats does not display memory
usage for js scripts.
However, if the env var MPV_LEAK_REPORT is set to 1, then we use
a custom allocator with talloc and track/report memory usage.
We can't switch allocator at runtime, so an mpv instance either tracks
or doesn't track js scripts memory usage, according to the env var.
(we could use a property and apply it whenever a new script starts,
so that it could change for newly launched scripts, but we don't).
- Explain which properties are writeable.
- Mark edition-list/N/id as writable.
- Remove (R) from some read-only properties since none of the others
have it.
- Add osd-dimension/ to its subproperties.
- options/<name> isn't read-only.
- focused works on macOS because of 82eda2e. Though it shouldn't be
possible to observe it without raising VO_EVENT_FOCUS.
The picture type is explained in /usr/include/libavutil/avutil.h
Other subproperties in /usr/include/libavutil/frame.h
And there is a more detailed explanation for repeat_pict in
/usr/include/libavcodec/avcodec.h
When possible, refer to booleans with "Whether..." since it can refer to
both yes (using input.conf and mp.get_property) and true (using the JSON
IPC or mp.get_property_native/bool), else explicitly say yes/true.
Say "true" for subprocess and osd-overlay named arguments since you
can't use them in input.conf and you will typically use them with the
boolean true in the named arguments, like the subprocess example in the
manpage does (though the string "yes" also works).
Subproperties that can't be accessed with the / syntax like
demuxer-cache-state's bof-cached and eof-cached always return true,
never yes.
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.
This allows keybindings such as:
a script-message-to console type "seek :0 absolute" 6
% script-message-to console type "seek absolute-percent" 6
The cursor position 0 isn't allowed because it has the weird effect of
filling the console with the text twice, leaving the cursor in the
middle.
Negative positions would put the cursor n characters before the end, and
positions greater than the text's length at the end. They seem to work
at first, but the console breaks when you move the cursor, so they
aren't allowed.
It seems that float values don't cause issues, but I'm using the
argument's floor anyway to be safe. Using >= 1 instead of > 0 ignores
values like 0.5.
This introduces the delete-watch-later-config command, to complement
write-watch-later-config. This is an alternative to #8141.
The general problem that this change is attempting to help solve has
been described in #336, #3169 and #6574. Though persistent playback
position of a single file is generally a solved problem, this is not
the case for playlists, as described in #8138.
The motivation is facilitating intermittent playback of very large
playlists, consisting of hundreds of entries each many hours
long. Though the current "watch later" mechanism works well - provided
that the files each occur only once in that playlist, and are played
only via that playlist - the biggest issue is that the position is
lost completely should mpv exit uncleanly (e.g. due to a power
failure). Existing workarounds (in the form of Lua scripts which call
write-watch-later-config periodically) fail in the playlist case, due
to the mechanism used by mpv to determine where within a playlist to
resume playback from.
The missing puzzle piece needed to allow scripts to implement a
complete solution to this problem is simply a way to clean up the
watch-later configuration that the script asked mpv to write using
write-watch-later-config. With that in place, scripts can then
register an end-file event listener, check the stop playback reason,
and in the "eof" and "stop" case, invoke delete-watch-later-config to
delete any saved positions written by write-watch-later-config. The
script can then proceed to immediately write a new one when the next
file is loaded, which altogether allows mpv to resume from the correct
playlist and file position upon next startup.
Because events are delivered and executed asynchronously,
delete-watch-later-config takes an optional filename argument, to
allow scripts to clear watch-later configuration for files after mpv
had already moved on from playing them and proceeded to another file.
A Lua script which makes use of this change can be found here:
https://gist.github.com/CyberShadow/2f71a97fb85ed42146f6d9f522bc34ef
(A modification of the one written by @Hakkin, in that this one takes
advantage of the new command, and also saves the state immediately
when a new file is loaded.)
The original documentation here is unclear, so let's describe the
behaviour we actually have. Inspired by wm4's updated docs but
obviously not identical because we're not changing any of the
behaviours.
Thomas Weißschuh
Niklas Haas
sfan5
Ivan
Avi Halachmi (:avih)
Dudemanguy
Mehul Mittal
Niklas Haas
Guido Cella
Jan Ekström
Emil Velikov
Nicolas F
a1346054
LaserEyess
hooke007
garoto
Ripose
rcombs
Sagnac
Philip Langdale
Chris Varenhorst
Zsolt Vadasz
Your Name
un.def
rim
Tom Wilson
Evgeny Zinoviev
Érico Rolim
Mia Herkt
Leo Izen
Emmanuel Gil Peyrot
der richter
Shreesh Adiga
Emanuele Torre
wm4
Guido Cella
soredake
Ricardo Constantino
Vladimir Panteleev