This has defaulted to yes for a very long time, but evidentally it
annoys a lot of people (including myself). My argument is that this
makes no sense. mpv is for videos; not text. A 1920x1080 video should
open as 1920x1080 regardless of whatever the DPI settings of the OS is.
This can get very silly when you consider watching a 4k video which will
get this additional scale factor which is virtually never desirable.
Whether or not the OS and/or WM prevents it from getting larger than the
screen depends on a lot of things.
Previously some windowing backends required that this option be set to
yes in order to report a dpi scale value other than 1, but this should
be fixed with the previous commits. The only difference is whether or
not to scale the window by the additional factor.
Fixes#13465.
Document the use cases for enabling or disabling the wheel preprocessing.
Also note that this option has no effect on any filtering already done
by the OS/driver.
* Range of accepted values for teletext_page now include 0 and -1.
* 0 means "subtitle" and -1 means "*".
* Make 0 the default.
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
Deinterlacing required that the user set it on/off themselves, but we
actually have handy flags for detecting if a frame is interlaced. So
it's pretty simple to make an auto option using that. Unfortunately,
life is not quite that simple and there are known cases of false
positives from the ffmpeg flags so we can't make auto the default value.
However, it still may have some utility for some people, and the
detection could potentially be improved upon later. Closes#10358.
vo_rpi and its related code has pretty much historically been a
disaster in mpv. The build regularly gets broken and since nobody uses
it, it takes months for anyone to notice. There was also that time where
fullscreen was broken for about a year and a half. Also building in waf
was entirely broken for about a couple of years or so due to mysterious
reasons no one ever figured out (meson magically fixed it).
Anyways, once again the build is broken due to rpi being forgotten about
again, but instead of pretending to support this crap. Just drop it all.
Nowadays, mmal hwdec is a relic since these devices are better off using
the v4l2m2m ffmpeg fork instead which actually uses KMS properly. RPI 1
and 2 probably can't do this and will remain broken but oh well blame
Broadcom for being special snowflakes and not using standard APIs (my
rockpro worked out of the box; just saying). RPI 2 is nearly 10 years
old anyways, so I think you can afford a new SBC by now. If we were
nicer, there would be a deprecation period, but this is broken in the
last major release anyway so too late.
Closes#13402.
This can be used to auto reload the input configuration file, e.g. in
vim:
autocmd BufWritePost ~/.config/mpv/input.conf silent !echo load-input-conf %:p | socat - /tmp/mpvsocket
Partially fixes#6362.
Additionally this can be used as a replacement for deprecated input
sections if they are ever actually removed. For example, if you want to
define different bindings for images, you can load-input-conf an
input.conf for images, and load the original again when switching to a
video. Though currently you would have to redefine builtin bindings that
were overwritten with image ones in the default input.conf.
Unlike set include mpv.conf, this works after playback has started. It
can be used to auto reload the configuration, e.g. in vim:
autocmd BufWritePost ~/.config/mpv/mpv.conf silent !echo load-config-file %:p | socat - /tmp/mpvsocket
Partially fixes#6362.
I don't actually deinterlace ever but allegedly this is better than
yadif, and there's no real reason to not have this be the fallback
deinterlace when we're not using hw frames. Also change various mentions
of yadif to bwdif. Ref #12835.
This exports `current-gpu-context` property, which is the string
description of the current active GPU context. This allows scripts to
uniquely identify the platform and backend used for --vo=gpu
and --vo=gpu-next.
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.
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.
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.
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.
Adds:
--secondary-sub-visibility
--video-aspect-method
--video-unscaled
--video-pan-x
--video-pan-y
--video-rotate
--video-crop
--video-zoom
--video-scale-x
--video-scale-y
--video-align-x
--video-align-y
Those properties are related to playback state and are likely expected
to be restored when resuming playback.
Removes:
--border
--fullscreen
--ontop
--osd-level
--pause
Those options are not really content related. I don't see much gain to
save them per each watch later entry.
the OpenGL cocoa backend was deprecated in 0.29, it has lot of bugs, is
completely unmaintained and can't properly playback anything anymore on
the newest macOS. it is time to remove it.
the old displayName property via the IODisplay API is not working
anymore on ARM based macs and was broken in at least one other case.
instead we use the new localizedName property introduced in 10.15 of the
NSScreen. we don't need any backwards compatibility since 10.15 is the
oldest version we support now.
configs and scripts that use the options and properties fs-screen-name,
screen-name or display-names need to be adjusted since the names could
differ from the previous implementation via the IODisplay API.
Fixes#9697
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.
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.
Not both of them. Formating it as `<name> (<desc>)` produced arguably
silly string like `hevc (HEVC (High Efficiency Video Coding))`. Unpack
this to show only description if available or name otherwise. Produces
way nicer results in stats.lua and similar places where this name is
printed.
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.
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.
