| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
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 04f0b0abe48d664aaa1400d1dddb02b434999b85.
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'.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
This was significantly refactored upstream. Switch to new APIs and add
new tone mapping curves and options.
cf. https://code.videolan.org/videolan/libplacebo/-/merge_requests/212
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Fixes https://github.com/mpv-player/mpv/issues/9387
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Make it clearer that watch-later-options controls which options are not saved
and not which ones are restored.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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)
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This "bw" should most likely be a "be".
|
| |
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
--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.
|
| |
|
|
|
|
|
|
| |
- 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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
--cover-art-auto affects rescan-external-files, and --autoload-files
affects cover art.
|
| |
|
|
| |
Closes #8666.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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.
|
| |
|
|
|
| |
It serves a purpose and a rework of the cache won't be coming anytime soon.
This partially reverts commit 8427292eb7c4074e1205c3d73c53c9e82569325f.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
The 90° step limitation must be a leftover from old behavior since any
value between 0 and 359 works now.
|
| | |
|
| |
|
|
|
|
|
| |
Part 1 of "look how well it performs, then start cleaning up the
old one."
Closes #8376
|
| | |
|
| |
|
|
|
| |
Not clear what exactly makes it fail with this change, but making
the note paragraph added in d5ab5482a9 a note structure seems to fix it.
|
| |
|
|
|
| |
loop-file counts the number of zero-seeks, not playthroughs,
which makes its counter off by one compared to loop-playlist.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
It is supported at least on Intel, from gen8 to gen11, and still gives a
pretty welcome reduction of CPU usage on my gen9.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
