| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
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 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'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
We still need these to track or notify of modifications to certain properties,
but they're now gone from the libmpv ABI.
|
| |
|
|
|
|
| |
These functions were deprecated in v0.21.0 and no-ops
since v0.23.0. The matching client API functions were
removed in the previous commit.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Prevent audio distortions caused by OpenAL's 3D effects.
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
Wrapping the context is pretty straightforward. This is only complicated
by needing to account for the upside-down framebuffer in a few places.
|
| |
|
|
|
|
|
| |
The audio rewrite in d27ad9654218463694093697e3d09f8983b4ccf3 originally
broke this ao. However, 0ac724f0025d48e1372ac82c62d504aaadf19735 fixed
and the documentation was never updated to reflect that. OpenAL has
worked fine for a while not. Just remove this sentence.
|
| | |
|
| |
|
|
|
|
| |
Adds support for the meson build system as well as a bit of
documentation. Compatibility with the existing waf build is
maintained.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
As it turns out the manual was very wrong about this.
|
| | |
|
| | |
|
| |
|
|
|
| |
Make it clearer that watch-later-options controls which options are not saved
and not which ones are restored.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 720bcd79d03 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@7489f632815c98ad58c3db71d1a5239b5dae266c
in May. Unfortunately, this was not noticed during review.
This reverts commit 0862664ac952d21fef531a8923a58ae575268fc5.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 d0fee0ac33a.
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.
|
| |
|
|
| |
This "bw" should most likely be a "be".
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 |
