Similar to the previous commit. There's no reason for --bluray-device to
be in MPOpts. Make a specific subopt for stream_bluray and use that
instead so we can remove the mp_read_option_raw call.
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.
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.
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.
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.
--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.
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.
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.
mpv makes this option an integer, but the underlying ass API actually
accepts doubles. From some testing, there is no meaningful precision
difference between float or double (it seems to go in roughly 0.05
steps), so just make it a float. sd_lavc also can handle non-integer
values here. Closes#11583.
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.
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
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).
the reason for these casts are unknown but they were presumably to
silence warnings 9 years ago. but it doesn't seem to be necessary
nowadays, so just drop the casts and also drop the `const` from the
compound literal type.
some small technical notes:
1. while string literals aren't `const` in C, writing to them is
undefined (do not ask me why). and so compilers will typically put
string literals into read only section anyways, regardless of
weather `const` was used in the source or not. so this shouldn't make
any difference codegen wise.
2. making the array of pointers `const` on the other hand might affect
codegen, eg: `(char *const []){...}`. however, that'd trigger a lot
of discarded qualifier warnings.
shorter and more robust this way instead of inserting at an index by
manually counting.
the surrounding code also uses `[STREAM_*] = ..` so it's more consistent
as well.
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.
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.
c784820454 introduced a bool option type
as a replacement for the flag type, but didn't actually transition and
remove the flag type because it would have been too much mundane work.
A longstanding pain point of the drm VOs is the relative lack of state
sharing. While drm_common does provide some sharing, it's far less than
other platforms like x11 or wayland. What we do here is essentially copy
them by creating a new vo_drm_state struct and using it in vo_drm and
context_drm_egl. Much of the functionality that was essentially
duplicated in both VOs/contexts is now reduced simple functions in
drm_common. The usage of the term 'kms' was also mostly eliminated since
this is libdrm nowadays from a userspace perspective.
The watch-later mechanism has always unconditionally wrote start to
files to save the playback position. When this was later expanded to
watch-later-options, this logic was kept in place. But we don't actually
have to unconditionally write this and can allow users to remove the
option from the list if they want to. The start value still requires
some special handling; it should always be written if possible
regardless of the value changing. However, we can just place it within
the default set of options for watch-later-options so it can be removed
like any other.
So far there was no way to sync video to display and have audio sync to
video without changes in pitch.
With this option the audio does not get resampled (pitch change) and
instead the corrected audio speed is applied to audio filters.
The content-type protocol allows mpv to send compositor a hint about the
type of content being displayed on its surface so it could potentially
make some sort of optimization. Fundamentally, this is pretty simple but
since this requires a very new wayland-protocols version (1.27), we have
to mess with the build to add a new define and add a bunch of if's in
here. The protocol itself exposes 4 different types of content: none,
photo, video, and game.
To do that, let's add a new option (wayland-content-type) that lets
users control what hint to send to the compossitor. Since the previous
commit adds a VOCTRL that notifies us about the content being displayed,
we can also add an auto value to this option. As you'd expect, the
compositor hint would be set to photo if mpv's core detects an image,
video for other things, and it is set to none for the special case of
forcing a window when there is not a video track. For completion's sake,
game is also allowed as a value for this option, but in practice there
shouldn't be a reason to use that.
mpv has an internal optimization on a couple of platforms where it will
not render any frames if the window is minimized or hidden. There's at
least once possible use case for wanting to force a render anyway
(screensharing with pipeware) so let's just add a simple switch for
this that always forces mpv to render. Closes#10846.
With the recent addition of the libxpresent, it should improve frame
timings for most users. However, there were known cases of bad behavior
(Nvidia) which lead to a construction of a whitelist instead of just
enabling this all the time. Since there's no way to predict whatever
combination of hardware/drivers/etc. may work correctly, just give users
an option to switch the usage of xorg's presentation statistics on/off.
The default value, auto, works like before (basically, Mesa drivers and
no Nvidia are allowed), but now one can force it on/off if needed.
Now that a separate --cover-art-whitelist option exists, files like
cover.jpg are loaded even without setting --cover-art-auto to fuzzy, so
only load files that have exactly the media filename by default, since
fuzzy loading is probably more likely to load unwanted images than to
load cover art that the user intended to display, especially if you play
audio files with a short filename like a.mp3.
This allows more fine grained control over which cover art to load. With
--cover-art-auto=exact and --cover-art-whitelist=yes, you can now load
cover art with the exact media filename and the whitelisted filenames,
but not cover art that contains the media filename
(--cover-art-auto=fuzzy).
