When running the console in the terminal, style log lines with the same
escape sequences as msg.c.
mp.input can also specify terminal escape sequences, e.g. a script to
select a playlist entry can invert the color of the selection.
Also add a missing newline to help's error message.
This doesn't actually work on either Windows or Linux with --terminal.
With --no-terminal or --no-input-terminal the SIGTERM handler is never
registered, so it definitely can't work.
Just remove the note about signals because it would be complicated to
explain that they don't terminate abruptly only with --terminal and only
if that signal has a handler, and it wouldn't be of interest to most
users.
fe875083b3 confused things a bit and made
--no-subs-with-matching-audio actually mean what it says: no subtitles
if the languages match. However, the option actually meant no non-forced
subtitles not no subtitles at all. This isn't really intuitive so
instead of changing the behavior back to the old way (we already have a
release since then), add a third option "forced" which is equivalent to
the old meaning of --no-subs-with-matching audio. Fixes#13151.
Currently, libplacebo always tries to reconfigure the d3d11 swapchain
to a 10-bit output format because disable_10bit_sdr isn't set to true,
even when an 8-bit format is explicitly requested via
--d3d11-output-format.
Fix this by passing the requested output format preference to libplacebo.
Document that this option may be ignored.
--ao=pipewire has been preferred on Linux for a long time, and this note
even makes it sound like alsa is preferred on any system. Just say that
the print order is the order in which the drivers are tried so this note
won't have to be updated again in the future, like --gpu-context's
documentation does.
This section has no reason to exist anymore because:
- No "desktop issues" sections exist for other platforms, and all other
Linux-specific issues are represented as notes for options. This section
only addressed one specific issue.
- This section was shortened significantly with commit
2c46ae8ea3, so there is no need for
this to be a separate section anymore.
- This section was shortened again with commit
d5e681e95d, when the original rationale
behind this section became outdated because GNOME has implemented the
idle inhibit protocol.
The historical info is moved to the documentation of --stop-screensaver.
Some places in the manpage uses `.. admonition:: Warning` instead of
the specific directive type `.. warning::` for warning admonitions.
This causes the "Warning" text appearing in black color instead of red.
Correct them here.
- --image-display-duration does not hide the OSC.
- Saying "Setting --image-display-duration" makes no sense because it is
not a boolean and it cannot be unset.
When hovering certain elements over the OSC, using the mouse wheel can
result in special commands (such as seeking, changing audio tracks,
etc.) Not everyone neccessarily wants this feature, so add an option to
make it possible to disable all of it. Maybe more fine-tuned control
would be more ideal, but probably not worth it. Fixes#13096.
f1c4d20e65 added this option, but the
documentation is actually backwards. --replaygain-clip allows clipping.
Having it disabled, the default, prevents it. Keep the behavior the
same, but change the documentation to reflect reality. Closes#13111.
This is useful for completing files and more rarely for profiles. It
will also be useful to third-party scripts interacting with the console
once the API to do it is merged.
I honestly don’t care either way but I also don’t believe this innocent
and cute hat is worth repeatedly having people show up on the issue
tracker to aggressively virtue signal and then shit-talk the project
elsewhere when their “concerns” are ignored and made fun of.
For the record, I approve of neither brand of childish nonsense.
If your workflow depends on December festivities, feel free to use an
alternative OSC implementation.
Fixes#13082 and #9548
This filter is a bit complicated, but one of the essential parts of it
is removing text enclosed by particular set of characters (e.g. text
inbetween []). This was previously hardcoded to only take into account
parenthesis and brackets, but people may want to filter more things so
make this customizable. The option only takes "left hand characters" so
the right pair is mapped internally if applicable. If not, then we just
use the same character. Fixes#8268 since the unicode character in
question can just be passed to this option.
A simplified version of the text width estimation code from uosc.
An osd_overlay is created with compute_bounds=true for measuring the
width of the lower case alphabet at what's estimated to be the largest
font size possible without clipping.
The lower case alphabet was chosen to get decent results for proportional
fonts, even if they aren't officially supported.
Add --secondary-sub-delay option and decouple --sub-delay from secondary
subtitles. This produces desirable behavior in most cases as secondary
and primary subtitles tracks tend to be timed independently of one
another.
This feature is implemented by turning the sub_delay field in
mp_subtitle_opts into an array of 2 floats. From here the track index is
either passed around or derived when sub_delay is needed. There are some
cases in dec_sub.c where it is possible for dec_sub.order (equivalent to
track index) to be -1. In these cases, sub_delay is inferred as 0.
the cocoa backend was removed and all functionality is either available
on all macOS backends or explicitly only with cocoa-cb. the manual
should properly reflect that change.
also remove the last mention of the old cocoa backend.
This property was never encouraged. The manual even stated that "You
should avoid using it, unless you absolutely have to." Since we now have
user-data which is superior in every single way and replaces this,
delete this property. The manual also has threatened people for years
with the line "It's a makeshift solution which could go away any time
(for example, when a better solution becomes available)." We were nice
and deprecated it in 1d00aee8e1 for a
while to give script authors some time to update. Let's remove it for
good now.
Only vaapi-copy variant as nothing can map D3D12 resources currently.
And even if we would add resource sharing to D3D11 it would invoke copy
at some point, so there is no point really. Maybe in the future when
libplacebo get smarter about resource sharing on Windows, but practical
advantages are really small. I've tested it with Vulkan <-> D3D11
sharing and GPU <-> GPU copy is still invoked. Better than CPU memcpy,
something for the future.
The "auto" logic is vastly better than setting a specific size. This
option amounts to "allow users to shoot themselves in the foot" flag,
given that the vast majority of ICC profiles in the wild are fine on
17x17x17 or even smaller 3DLUTs.
Setting stupidly high --3dlut-size is the main source of ICC-related
slow startup issues, and there is absolutely no conceivably benefit to
going above the defaults except for pixel peeping and chasing tiny PSNR
increments.
D3D11 is actually the main platform that suffers from slow shader
compilation, typical Vulkan/GL drivers are either very fast to begin
with, or already internally cache.
Display aspect ratio (aspect) and pixel aspect ratio (par) are already
exported, but storage aspect ratio (sar) isn't. This value is needed to
display the storage aspect ratio for non-square pixel sources in stats.lua.
This exports two new properties: video-params/sar and video-params/sar-name.
Docmentation is updated accordingly.
Stretch a subtitle duration so it ends when the next one starts.
Should help with subtitles which erroneously have zero durations.
I found such a subrip substitles stream in the wild.
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
There's some geometry-related things that mpv has to calculate before
the window is actually mapped onto the screen in wayland. But there's no
way to know which output the window will end up on before it happens, so
it's possible to calculate it using the wrong values. mpv corrects
itself later when the surface event happens, but making the initial
guess work better can help in certain cases.
find_output is the only thing that needs to be changed here. Its main
purpose is to grab the right output based on user settings when we're
trying to full screen and giving a fallback in case we don't have
wl->current_output yet. The x11 code already does something similar, so
we're basically just copying it. Allow user settings like --screen and
--screen-name to influence the initial wl_output guess. Those options
won't actually place the window on that specific screen since we can't
do that in wayland, but if the user knows where the window will end up
beforehand it makes sense to listen to the arguments they pass. If
something goes wrong, then we just fallback to 0 like before.
currently hysteresis-secs only works when the demuxer-max-bytes fills
up. but it's possible for the cache-secs/demuxer-readahead-secs to be
reached first.
in those cases, hysteresis-secs doesn't work and keeps buffering
non-stop. but the goal of this option was to save power by avoiding
non-stop buffering so go ahead and make it respect cache-secs as well.
additionally remove some redundant repetition from the docs.
5f74ed5828 deprecated this many years ago.
The utility is questionable at best given that -remove exists and is
more natural to use. Free up some code and drop it.
The MPV_LEAK_REPORT environment variable was previously read in order to
determine whether or not to enable memory reporting for javascript
scripts. This is kind of weird and deviates from the norm of exposing an
option to the user. So let's just add --js-memory-report and disable it
by default instead.
--play-dir sounds like it has something to do with directories so change
it. The play_dir variable is used a bunch everywhere internally so
whatever just leave it alone instead of renaming that.
This option has exactly the same semantics are other mpv options that
override a particular thing with something from the user. So instead of
the "force-style" name, use "-overrides" which is more consistent.
The plural form is used since it's a list option.
Other similar options are in the form of --foo-override not
--override-foo. The display-fps one was backwards so flip it around the
other way for consistency reasons.
This better reflects what it actually does. As a bonus, script writers
won't be misled into thinking that fps displays the actual video or
display fps.
Peak detection greatly increases HDR experience. Performance hit of
non-delayed detection is not that significant and is in line with
current default settings.
Nobody except a chosen few (I'm not one of them) even knows what it
means. Multiple people thought it was actually some kind of rendering
bug. Just disable it by default. Closes#12671.
I started going through the blame but once I got to mplayer commits from
20 years ago, I stopped bothering. This obscure option has always been
disabled by default, but there's zero reason, as far as I know, to not
just enable it today. Some CDs (particularly very old ones) have the
first sector shifted a bit and not starting exactly at 0. This makes the
logic that tries to get all the chapters completely fail and thus you
can't skip through tracks. However if you just enable this obscure
option, it just works. For anything that starts exactly at 0, the
calculated offset is just 0 anyway so it's a no-op and works exactly the
same. So basically, there's literally no reason to not just always try
to correct for the offset of the first sector by default.
Fixes#8777.
Why a bigger search-interval is required:
scaletempo2 doesn't do a good job when the signal contains frequencies
less then 1/search_interval. With a search interval of 30ms that means
anything below 33.333Hz sounds bad.
Depending on the genre it's very for music to contain frequencies down
to 30Hz, and sometimes even a little bit below that. Therefore a higher
default value is needed to handle such cases.
Based on that an argument can be made for a value of 50, as that should
work down to 20Hz, or something even higher because movies sometimes
have some infrasonic content.
However the downside of big search intervals is increased CPU usage and
intelligibility at higher speeds, as it effectively leads to parts of
the audio being skipped.
A value of 40 can handle frequencies down to 25Hz, enough for all music
except very rare edge cases, while still providing decent
intelligibility.
Why a smaller window-size is required:
Large values reduce intelligibility at high speeds and therefore small
values are preferred.
However when values get too small it starts to sound weird
(similar to librubberband).
In my testing a value of 10 already works well, but adding a small
safety margin seems like a good idea, especially since it made no
noticeable difference to intelligibility, which is why 12 was chosen.
add support for vulkan through metal and a translation layer like
MoltenVK. also add the possibility to use different render timing modes
for testing.
i still consider this experimental atm.
Added to the functions `mp.add_timeout` and `mp.add_periodic_timer`.
If the `disabled` argument is set to `true` or a truthy value, the
timer will wait to be manually started with a call to its `resume()`
method.
Only vpdau-copy works with EGL. 2d1d815cc7 already added this to
manpage, and 1c8d2246bf removed it again, but that seems to be a mistake
because I can only get vdpau to work with GLX, and another user also
reported that only vdpau-copy was working for him with the default EGL.
playlist-prev-playlist goes to the beginning of the previous playlist
because this seems more useful and symmetrical to
playlist-next-playlist. It does not go to the beginning when the current
playlist-path starts with the previous playlist-path, e.g. with mpv
--loop-playlist foo/, which expands to foo/{1..9}.zip, the current
playlist path foo/1.zip beings with the playlist-path foo/ of {2..9}.zip
and thus playlist-prev-playlist goes to 9.zip rather than to 2.zip.
Closes#12495.
Completion suggestions are now nicely formatted into a table.
Maximum width of the table is estimated based on OSD size and
font size.
This requires a new scaling factor option `font_hw_ratio`.
A factor of 2.15 works great for me,
but the default is 2.0 to avoid problems with other fonts.
The space between columns is automatically adjusted to be
between 2 and 8 spaces.
It tries to use as few rows as possible.
There's really no reason not to do this especially since sub-codepage
already defaults to auto. Also change logging in charset_conv since
telling us that the data is UTF-8 if the passed codepage value is "auto"
or "utf-8" is really not useful information (that's the expectation).
What are cue sheets not metadata or something? No reason this needs to
be a separate option so just deprecate it. This does mean that the
default value changes from "auto" to "utf-8" for this obscure fringe
case. I really hope people don't use non-UTF-8 cuesheets, but the next
commit will change the default of --metadata-codepage to "auto" so
there's no actual change in behavior to users.
This reverts commit 576e86bfa1 (functionally).
Right now, the --config-dir option silently causes all watch_later and cache
files to be written in the --config-dir as well. This is pretty uninitutive
and also not desirable in most cases so get rid of this.
libmpv users will have to set the corresponding options or env vars if they
want to keep the old behaviour.
Combine the cover art whitelist with the extensions in
--cover-art-auto-exts instead of hardcoding them. This is shorter,
checks for more extensions, saves us from updating the whitelist
everytime we add a new image extension, and since the whitelist had
gotten so big and the priority is calculated as
MP_ARRAY_SIZE(cover_files) - n, files like cover.jpg were taking
priority over cover art loaded by --cover-art-auto=exact.
There was a discrepancy in what the keybind was advertised to do in the
manual, and what the comment in input.conf described it to be doing. It
makes very little sense to add a keybind that changes the default and
doesn't allow you to get back to the default. This keybind is much more
useful if it toggles between yes/force instead of no/force.
There is zero reason for this to be an MPOpt. Because of how the
OPT_SUBSTRACT works, the option gets renamed to cdda-device instead, but
probably not a big deal since the old alias is still in place.
These were deprecated a long time ago and apparently didn't even work
with lavfi filters. Go ahead and remove them and additionally clean up
some code related to them. m_config_from_obj_desc_and_args becomes much
simpler now and a couple of arguments can be completely removed.
No wonder wm4 wanted to get rid of this. This option requires touching a
bunch of crap in the core player code. --stream-record works perfectly
fine and is a lot nicer so there's no need for this to exist anymore.
A bit different from the OPT_REPLACED/OPT_REMOVED ones in that the
options still possibly do something but they have a deprecation
message. Most of these are old and have no real usage. The only
potentially controversial ones are the removal of --oaffset and
--ovoffset which were deprecated years ago and seemingly have no real
replacement. There's a cryptic message about --audio-delay but who
knows. The less encoding mode code we have, the better so just chuck
it.
e9e93b4dbe added a warning about writing
the same value to the playlist-pos property that in the future it would
stop restarting playback. Instead, you should use the
playlist-play-index command for that. Well go ahead and drop the old
deprecated behavior now and do what wm4 wanted this to do: just ignore
if the same value is written again.
drop-frame-count and vo-drop-frame-count are ancient and have no reason
to exist anymore. The other change is that support for writing to
display-fps has been removed, and the property is strictly read-only
now. 3a2dc8b22e is what deprecated it with
a warning to users, so we can remove it without much trouble.
We've got an ungodly amount of OPT_REPLACED and OPT_REMOVED sitting
around in the code. This is harmless, but the vast majority of these are
ancient. 26f4f18c06 is the last commit
that touched the majority of these and of course that only changed how
options were declared so all of this stuff was deprecated even before
that. No use in keeping these, so just delete them all. As an aside,
there was actually a cocoa_opts but it had only a single option which
was replaced by something else and empty otherwise. So that entire thing
was just simply removed. OPT_REPLACED/OPT_REMOVED declarations that were
added in 0.35 or later were kept as is.
The defaults were awful and horribly regressed many files while also not
fixing banding on files that actually needed it, sometimes even
*increasing* banding due to the low threshold.
Fixes: 12ffce0f22
See-Also: haasn/libplacebo@e1e43376d1
This probably makes `vo_gpu` tone mapping worse, or something, but who
cares. The status quo for a while now has been to use `vo_gpu_next` if
you care about HDR rendering at all.
See-Also: haasn/libplacebo@ec60dd156b
See-Also: haasn/libplacebo@0903cbd05d
This new filter is slightly sharper, and significantly faster, than
mitchell. It also tends to preserve detail better. All in all, there is
no reason not to use it by default, especially from a performance PoV.
(In vo_gpu_next, hermite is implemented efficiently using hardware
accelerated bilinear interpolation)
See-Also: 75b3947b2c
It can hurt people's feelings to refer to scalers as "high quality" and
"low quality", when it is so subjective.
I decided to preserve the lanczos sections at least because it's mostly
talking about the difference between EWA Lanczos and Lanczos, which is
less controversial than the difference between, say, Lanczos and
Catmull.
Very amusingly, the manual previously said "The rpi VO will be removed
in mpv 0.23.0." Obviously, this didn't happen. It looks like wm4 changed
his mind on this with 51fd8f6fe1, but
never updated the docs. What was the problem? Who knows but allegedly
there are people that use --vo=rpi (it's supposed to work at least).
Actually context_rpi is probably broken since wm4 changed fullscreen
handling in 59cdfe50b2 and no one ever
bothered to fix it after that commit. In fact, that's the last commit
that touched that particular file. Someone did actually fix vo_rpi after
that so that one probably works at least. Anyways, I wouldn't mind just
deleting all rpi stuff, but there's probably some people out there that
use it so whatever. Remove the outdated deprecated language in the
documentation and just accept that we support this unfortunately.
Defining MPV_CPLUGIN_DYNAMIC_SYM during plugin compilation will replace mpv_*
functions with function pointers. Those pointer will be initialized when
loading the plugin.
It is recommended to use this symbol table when targeting Windows. The loader
does not have notion of global symbols. Loading cplugin into mpv process will
not allow this plugin to call any of the symbols that may be available in
other modules. Instead cplugin has to link explicitly to specific PE binary,
libmpv-2.dll/mpv.exe or any other binary that may have linked mpv statically.
This limits portability of cplugin as it would need to be compiled separately
for each of target PE binary that includes mpv's symbols. Which in practice
is unrealictis, as we want one cplugin to be loaded without those restrictions.
Instead of linking to any PE binary, we create function pointer for all mpv's
exported symbols. For convinience names of entrypoints are redefined to those
pointer so no changes are required in cplugin source code, except defining
MPV_CPLUGIN_DYNAMIC_SYM. Those function pointer are exported to make them
available for mpv to init with correct values during runtime, before calling
`mpv_open_cplugin`.
Note that those pointer are decorated with `selectany` attribute, so no need
to worry about multiple definitions, linker will keep only single instance.
This fixes cplugin usability on Windows. Without any API changes, only
recompilation with -DMPV_CPLUGIN_DYNAMIC_SYM is needed.
The goal is to provide simple to understand quality/performance level
profiles for the users.
Instead of default and gpu-hq profile. There main profiles were added:
- fast: can run on any hardware
- default: balanced profile between quality and performance
- high-quality: out of the box high quality experience. Intended
mostly for dGPU.
Summary of three profiles, including default one:
[fast]
scale=bilinear
cscale=bilinear (implicit)
dscale=bilinear
dither=no
correct-downscaling=no
linear-downscaling=no
sigmoid-upscaling=no
hdr-compute-peak=no
[default] (implicit mpv defaults)
scale=lanczos
cscale=lanczos
dscale=mitchell
dither-depth=auto
correct-downscaling=yes
linear-downscaling=yes
sigmoid-upscaling=yes
hdr-compute-peak=yes
[high-quality] (inherits default options)
scale=ewa_lanczossharp
cscale=ewa_lanczossharp (implicit)
hdr-peak-percentile=99.995
hdr-contrast-recovery=0.30
allow-delayed-peak-detect=no
deband=yes
scaler-lut-size=8
After fixing the B and C params for bcspline, it ended up being the same
thing as bicubic. There's no reason to have two names for the same
filter, so remove bcspline and keep bicubic to match libplacebo.
No need for this since it's entirely redundant with just changing the
filter radius directly. In fact, that's the whole *point* of the filter
radius - it does not modify the filter, it modifies the scaling of the
window.
Of course, this does not work for non-resizable kernels. But, really,
who cares?
And make it the default. In libplacebo, this uses internal heuristics to
pick a good size based on the actual ICC characteristics. This is
significantly less wasteful than always generating a 64x64x64 3DLUT (the
old status quo).
In vo_gpu, for simplicity, just default to 65x65x65. Note that this
provides slightly better accuracy than the old default of 64x64x64 for
technical reasons, and matches what libplacebo defaults to for typical
display profiles.
Adds catmull_rom as an example for --scale in the user manual, alongside
a brief description of the filter.
catmull_rom was only exposed to users as an available filter through
--scale=help. However, catmull_rom is very often aliased as "Bicubic" in
other applications such as GIMP and VapourSynth, and is a relatively
popular resizing filter. The documentation lacked any description of
catmull_rom, outside of a brief mention of it in the --tscale section.
While this resolves limitations of lavc decoder crop, it also introduces
artifacts with some of the source files or hwdec.
Depending on chroma sampler it is possible to sample outside the decoder
crop area, pulling dirty pixels into the image. Some decoders left them
zeroed, not black. To fix that we would need specifc solution during
mapping of avframes.
As most of the files require the crop only in bottom/right area, the
AVCodecContext::apply_cropping works ok for those.
For all other cases that require more fancy cropping like 1440x1080+240+0
user can manually set `--vd-apply-cropping=no`.
Limitations of the lavc crop are explained here:
https://ffmpeg.org/doxygen/trunk/structAVCodecContext.html#a4745c7455c317272c4e139d6f369936c
Fixes: 826ce82cad
In the never ending quest of trying to satisfy every possible user
request for subtitle autoselection, I ended up redoing how
--subs-fallback-forced works. The old behavior had it as strictly a
fallback-type option when there were no lang matches, but now we can
make it an active part of compare_track and it works along with slang to
select the desired track. Since it's a three state option, the no option
still works to avoid selecting any forced subtitle tracks. The meaning
of always slightly changes to mean "only select forced subtitle tracks"
and yes remains essentially the same (no special priority given besides
the audio matching subtitle language case).
Cropping by decoder has limitations with regards to aligment and hwdec.
It doesn't work to offset top left corner with hwdec and even with
software decoding it don't crop fully when resulting data would not be
aligned.
VO cropping is way more robust.
Setting `--video-crop=0x0+0+0` applies full frame crop, ignoring the
container one. Setting --video-crop=0 disables manual crop and restores
container one if it is available.
This makes it easier to apply crops without need to manually calc the
offset. I wanted for it to be top-left corner based, but maybe it was
not that good idea in retrospect.
Also rename scrw/scrh, since they don't refer to screen. It was copied
form m_geometry apply.
Third try is the charm? I stupidly missed that this option already
existed in my previous commits. Instead, add an auto value to it and
enable it by default for sd_lavc but not sd_ass. On my limited samples,
it seems to fix the gaps issue that can occur but without regressing
some duration timings for sub_lavc subtitles. Well hopefully anyway.
Fixes#12327.
We currently only allow specifying the Vulkan device to use by name. We
did this to avoid confusion around devices being enumerated in an
unpredictable order. However, there is a valid edge case where a system
may contain multiple devices of the same type - which means they will
have the same name, and so you can't control which one is used.
This change implements picking devices by UUID so that if names don't
work, you have some option available. As Vulkan 1.1 is a hard
requirement for libplacebo, we can just use UUIDs without conditional
checks.
Fixes#10898
The old mplayer / zap style format is not fully standardized across
channel scanners, so autodetection may fail if the file name
does not indicate the delivery system.
This is similar to DVB-T, but requires slightly different treatment
as there is no T/T2 differentiation.
Use a new channels.conf.isdbt file as channels config file.
There are way too many preexisting scripts that rely on this behavior
for video panning, like for example scripts that allow you to use mpv as
an image viewer. If this behavior is desired then it may be better to
add a new option for panning relative to the destination instead.
The restriction of video-pan-x/y being clamped to {-3, 3} also results
in the video being impossible to pan if it was zoomed in beyond a
certain degree.
This reverts commit 7d6f9e3739.
the osc currently allows for changing volume via scrolling when on top
of the volume icon. this does the same thing for the seekbar by allowing
seeking via scroll.
`--vo=gpu-next` no longer uses this option, being replaced entirely by a
luminance-based approach internally. And even for `--vo=gpu`, the values
other than 'hybrid' are universally inferior in quality.
In the interest of gradually reducing the amount of option bloat here,
remove this mostly-pointless option.
64959c450d solved the problems with resuming playback, so default to
--directory-mode=lazy because it's faster, especially on slow drives,
and results in smaller playlists.
If --slang was set to some language and it matched the subtitle track,
then --no-subs-with-matching-audio would do nothing. Fix the logic by
doing the --no-subs-with-matching-audio step at the end to ensure that
it always "wins" over whatever --slang or --subs-fallback has set.
Clarify the docs a bit to make it clearer that this is the intended
behavior. Fixes fbe8f99194.
Since we no longer have the auto choice, this is always exactly equal to
the value of the option (sub-forced-events-only). Remove the property
and alias it.
The old name is pretty bad and users mistakenly think it has something
to do with selecting forced subtitles (that would be
--subs-fallback-forced). Instead of giving it such a generic name, make
it clearer that this has to do specifically with forced sub events
which is only relevant for a small minority of subtitles.
First of all, this never worked. Or if it ever did, it was in some
select few scenarios. c9474dc9ed is what
originally added support for the auto choice. However, that commit
worked by propagating a value to a fake option used internally. This
shouldn't have ever worked because the underlying m_config_cache was
never updated so the value shouldn't have been preserved when accessed
in sd_lavc. And indeed with some testing, the value there is always 0
unsurprisingly.
This was later rewritten in ba7cc07106
along with a lot of other sub changes, but with that, it was still
mostly broken. The reason is because one of the key parts of having to
hit this logic (prefer_forced) required `--no-subs-with-matching-audio`
to be set. If the audio language matches the subtitle language (the
requirement also excludes forced subs), the option makes no subtitle
selection in the first place so pick->forced_only_def is not set to true
and nothing even happens. Another way around this would be to attempt to
change your OS language (like with the LANG environment variable) so
that the subtitle track gets selected but then audio_matches mistakenly
becomes false because it compares the OS language to the audio language
which then make preferred_forced 0, so nothing happens. I don't think
there's a scenario where pick->forced_only_def is actually set to true
(thus meaning `auto` is useless), but maybe someone could contrive
something very strange. Regardless, it's definitely not something even
remotely common.
fbe8f99194 changed track selection again
but didn't consider this particular case. The net result is that DVD/PGS
subs become equivalent to --sub-forced-only being yes, so this a change
in behavior and probably not a good one. Note that I wasn't able to
actually observe any difference in a PGS sample. It still displayed
subtitles fine but that sample probably didn't have the right flags to
hit the sub-forced-only logic.
Anyways, the auto feature is extremely questionable at best and in my
view, not actually worth it. It is meant to be used with
`--no-subs-with-matching-audio` to display forced pictures in subtitle
tracks that are not marked as forced, but that contradicts that
particular option's purpose and description in the manual (secretly
selecting a track under certain conditions even though it says not to).
Instead of trying to shove all this logic into select_default_track
which is already insanely complicated as it is, recognize that this is a
trivial lua script. If you absolutely want to turn --sub-forced-only on
under these certain conditions (DVD/PGS subtitles, matching audio and
subtitle languages, etc.), just look at the current-tracks property and
do your thing. The very, very niche behavior that this option tried to
accomplish basically never worked, no user even knows what this option
does, and well it's just not worth supporting in core mpv code. Drop
all this code for sanity's sake and change --sub-forced-only back to a
bool.
In general, forced tracks should only be shown if they match the
language of the audio. However some people do want them no matter what,
so add an always option to this so such tracks are always selected.
This is the replacement for the previous auto option for slang. It
behaves similar however it never overrides slang if that is set and will
instead try to pick the subtitle that matches the user's language if
appropriately flagged by the file.
This proved to be too problematic. Depending on the value of
--subs-with-matching-audio, you could either end up with cases where
--slang wasn't respected and users didn't get subtitles or alternatively
cases where subtitles were given and the user didn't ask for them.
Fundamentally, the OS language functionality doesn't really map well to
slang (and for alang/vlang it makes zero sense; not that anyone actually
used it). Instead of trying to shove it in an option where it doesn't
belong, we should split this off into something else. So for now, just
remove the special handling of "auto" and flip slang back to NULL.
Ideally, users should be using lavfi-complex instead of lavfi-bridge
for such a use case, however currently lavfi-complex doesn't support
hwdec. So we can allow filters with dynamic inputs to work with
lavfi-bridge, at the cost of them only being able to take in
only one input. This should probably be reverted when/if lavfi-complex
has hwdec, but for now this allows us to use libplacebo
as a video filter with hwdec in mpv again.
--audio-file-auto, --cover-art-auto, and --sub-auto all work by using an
internally hardcoded list that determine what file extensions get
recognized. This is fine and people periodically update it, but we can
actually expose this as a stringlist option instead. This way users can
add or remove any file extension for any type. For the most part, this
is pretty pretty easy and involves making sub_exts, etc. the defaults
for the new options (--audio-file-auto-exts, --cover-art-auto-exts, and
--sub-auto-exts). There's actually one slight complication however. The
input code uses mp_might_be_subtitle_file which guesses if the file drag
and dropped file is a subtitle. The input ctx has no access to mpctx so
we have to be clever here.
For this, the trick is to recognize that we can leverage the
m_option_change_callback. We add a new flag, UPDATE_SUB_EXTS, which
fires when the player starts up. Then in the callback, we can set the
value of sub_exts in external_files to opts->sub_auto_exts. Whenever the
option updates, the callback is fired again and sub_exts updates. That
way mp_might_be_subtitle_file can just operate off of this global
variable instead of trying to mess with the core mpv state directly.
Fixes#12000.
1fa6669bc0 misinterpreted the example and
changed the pixel value from 128 to 168 (thinking that it meant pixels
after scaling), but likely the original calculation was correct because
the line specifically says "of the source video". This is just confusing
not really useful information so instead change the example to a more
common resolution (1920x1080) and remove any references to the source
video resolution. Also mention video-pan-y while we're at it.
It makes it more usable to virtually move dst rect instead of scaled
src.
The issue with the latter is that it is affected by video-zoom
paramters. For example if we do `--video-pan-x=-0.5` in normal case it
will move video -50%, but if we apply video-zoom/scale the video will
float towards the middle in unintuitive way. Extreme case is when one do
--video-zoom-x=0.01, now it is impossible to move video unless you
specify huge video-pan-x value, but it is limited to [-3, 3]. So you
cannot do anything.
With this changes regardless of video scale/zoom, video-pan will keep
center of scaled video in one place.
This completely disables all smoothing. Despite what the manual claims,
a decay rate of 1.0 does *not*.
It's worth pointing out that this depends on the following commit to
work properly in --vo=gpu-next, but I don't think working around such a
minor detail is worth the trouble, considering people building nightly
mpv are probably also building nightly libplacebo it should just work
(tm).
See-Also: 1c464baaf4
See-Also: 83af2d4ebd
This deliberately wasn't being done when mpv was embedded
(fbccddb48b). There are some applications
that would benefit from mpv setting a title since they don't do so
themselves (such as tabbed), but at the same time some others would
probably rather not have this behavior (like smplayer). Add an option
that allows an embedded mpv to set the title if the user wishes.
Fixes#11528.
A bit of a long standing pain with scripting is that when opening a file
that gets interpreted as a playlist (like an m3u), the original path of
the file gets thrown away later. Workarounds basically consist of
getting the filename before mpv expands the path, but that's not really
reliable. Instead of throwing it away, save the original playlist path
by copying to the playlist entries when applicable (demuxer playlist and
the playlist option). Then expose these as properties: playlist-path for
the currently playing entry and playlist/N/playlist-path for each
specific entry. Closes#8508, #7605.
mpv has a generic method for getting the display resolution, so we can
save it in vf_vapoursynth without too much trouble. Unfortunately, the
resolution won't actually be available in many cases (like my own)
because the windowing backend doesn't actually know it yet. It looks
like at least windows always returns the default monitor (maybe we
should do something similar for x11 and wayland), so there's at least
some value. Of course, this still has a bunch of pitfalls like not being
able to cope with multi monitor setups at all but so does display_fps.
As an aside, the vapoursynth API this uses apparently requires R26 (an
ancient version anyway), so bump the build to compensate for this.
Fixes#11510
The OSC reports the speed-adjusted remaining time, but the terminal does
not. This is a weird mismatch and the OSC's default behavior makes
sense, so let's just do some division and add an option to disable it.
Also named "remaining-playtime" after the OSC option. Fixes#10445.
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
