Add a property that returns whether the window is focused, currently
only for X11 and Wayland.
My use cause for this is having an equivalent of pause-when-minimize.lua
for tiling window managers: make mpv play only while it's in the current
workspace or is focused (I'm fine with either one but prefer focus).
On X I do this by observing display-names, which is empty when the
rectangles of the display and mpv don't intersect, but on Wayland its
value doesn't change when mpv leaves the current workspace (and the same
check doesn't work since the geometries still intersect).
This could later be made writable as requested in #6252.
Note that on Wayland se shouldn't consider an unactivated window with
keyboard input focused.
The wlroots compositors I tested set activated after changing the
keyboard focus, so if you set wl->focused only in
keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the
"has_keyboard_input" member, focused isn't set to true when first
opening mpv until you focus another window and focus mpv again.
Conversely, if that order can't be assumed for all compositors, we
should toggle wl->focused when necessary in keyboard_handle_enter() and
keyboard_handle_leave() as well as in handle_toplevel_config().
--audio-stream-silence is a shitty feature compensating for awful
consumer garbage, that mutes PCM at first to check whether it's
compressed audio, using formats advocated and owned by malicious patent
troll companies (who spend more money on their lawyers than paying any
technicians), wrapped in a wasteful way to make it constant bitrate
using a standard whose text is not freely available, and only rude users
want it. This feature has been carelessly broken, because it's
complicated and stupid. What would Jesus do? If not getting an aneurysm,
or pushing over tables with expensive A/V receivers on top of them, he'd
probably fix the feature. So let's take inspiration from Jesus Christ
himself, and do something as dumb as wasting some of our limited
lifetime on this incredibly stupid fucking shit.
This is tricky, because state changes like end-of-audio are supposed to
be driven by the AO driver, while playing silence precludes this. But it
seems code paths for "untimed" AOs can be reused.
But there are still problems. For example, underruns will just happen
normally (and stop audio streaming), because we don't have a separate
heuristic to check whether the buffer is "low enough" (as a consequence
of a network stall, but before the audio output itself underruns).
Transparent windows on X11/EGL/native Mesa GL didn't work for various
reasons. From what I remember, the current code did work with nvidia at
least. Mesa has made attempts to fix this, but they never really made it
in.
But it turns out you can make EGL/Mesa list the EGLConfigs that use X11
RGBA visuals, and context_x11egl.c contains code that explicitly selects
them if alpha is requested (see pick_xrgba_config()).
The reason EGL/Mesa did not list them (and thus breaking transparency)
is because we requested a EGL_ALPHA_SIZE != 0 if alpha is requested. But
the transparent EGLConfigs use EGL_ALPHA_SIZE == 0. That's because EGL
doesn't actually support the concept of transparent windows; the alpha
size parameter is something else (memory rendering without FBOs or
something, I don't care enough to look up the real reasons).
This still won't work on Wayland. Every EGL backend needs platform
specific code. (Good job, EGL, such an awesome platform independent
standard.)
Fixes: #6590
Accepting ":" in addition to "," seems confusing and dumb. It only
causing problems when you want to pass a value that contains ":". Remove
support for ":", it is now treated like any other normal character. This
affects all options that are listed as "Key/value list" in the option
list.
It's possible that this breaks for someone who happened to use ":" as
separator. But this was undocumented, and never recommended. Originally,
the option treated many other characters in a special way, but this was
changed in commit a3d561f950. I'm, not sure why ":" was explicitly
included. Maybe because -the absurd -vf/--af syntax uses ":" as list
separator. But "," was always recommended and used in examples for
key/value options.
Fixes: #8021 (if you consider it a bug)
This allows users to control whether full dialogue subtitles are displayed
with an audio track already in their preferred subtitle language.
Additionally, this improves handling for the forced flag, automatically
selecting between forced and unforced subtitle streams based on the user's
settings and the selected audio.
Add support for reading a byte range from a stream via
the `slice://` protocol.
Syntax is `slice://start[-end]@URL` where end is a maximum
(read until end or eof).
Size suffixes support in `m_option` is reused so they can
be used with start/end.
This can be very useful with e.g. large MPEGTS streams with
corruption or time-stamp jumps or other issues in them.
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
Make it possible to feed a string to stdin of a subprocess. Out of
laziness, it can't be an arbitrary byte string. (Would require adding an
option type that takes in a Lua byte string.)
Do not set stdin of a subprocess to fd 0 (i.e. mpv's stdin) anymore,
because it makes things more consistent. Enabling stdin didn't make too
much sense in the first place, so this behavior change seems
justifiable.
win32 support missing.
Fixes: #8003
Seems like this is requested all the time.
It seems libass allows out of range values, but does allows the subtitle
to go out of the screen at the bottom (only when moving it to the top
it's "clamped"). Too bad, don't do that then. The bitmap sub rendering
code on the other hand is under our control, and will not move a
subtitle out of the screen.
Fixes: #7986
Requested. Should be good for simple use cases. "sub2" is technically
inconsistent (since the option is called --secondary-sid), but fuck the
consistent name.
Uses the mechanism introduced in the previous commit. The hope was to
make auto-profiles easier to use, and to get rid of the need for
manually created inverse profiles. Not sure if the end result is useful.
Make it possible to restore from profiles by backing up the option
values before profile application. This is sort of like unapplying a
profile. Since there might be multiple ways to do this, a profile needs
to explicitly provide the "profile-restore" option, which specifies how
exactly this should be done.
This is a big mess. There is not natural way to do this. Profile
application is "destructive" and simply changes the values of the
options. Maybe one could argue that the option system should have
hierarchical "overlays" of profiles instead, where unset options will
use the value of the lower profiles. Options set interactively by the
user would be the top profile. Default values would be in the lowest
profile. You could unapply a profile by simply removing it from this
overlay stack.
But uh, let's not, so here's something stupid. It reuses some code used
for file local options to reduce code size. At least the overlay idea
would still be possible in theory, and could be added as another
profile-restore mode.
This is used by the following commit.
The callback now gets an object argument with defer/cont functions.
Like the lua code, the behavior is that each hook event allows at
most one continue, but nothing enforces the order of continuations
if more hook events arrive before prior ones were continued - which
is possible now with the defer option, but wasn't possible before
(continuation was synchronous from the hook event handler).
This can now opt to not continue a hook after the hook callback returns.
This makes it easier for scripts, and may make it unnecessary to run
reentrant event loops etc. for scripts that want to wait before
continuing while still running the event loop.
This is taken from a somewhat older proof-of-concept script. The basic
idea, and most of the implementation, is still the same. The way the
profiles are actually defined changed.
I still feel bad about this being a Lua script, and running user
expressions as Lua code in a vaguely defined environment, but I guess as
far as balance of effort/maintenance/results goes, this is fine.
It's a bit bloated (the Lua scripting state is at least 150KB or so in
total), so in order to enable this by default, I decided it should
unload itself by default if no auto-profiles are used. (And currently,
it does not actually rescan the profile list if a new config file is
loaded some time later, so the script would do nothing anyway if no auto
profiles were defined.)
This still requires defining inverse profiles for "unapplying" a
profile. Also this is still somewhat racy. Both will probably be
alleviated to some degree in the future.
scaletempo2 is a new audio filter for playing back
audio at modified speed and is based on chromium
commit 51ed77e3f37a9a9b80d6d0a8259e84a8ca635259.
It sounds subjectively better than the existing
implementions scaletempo and rubberband.
Add env and detach arguments. This means the command.c code must use the
"new" mp_subprocess2(). So also take this as an opportunity to clean up.
win32 support gets broken by it, because it never made the switch to the
newer function.
The new detach parameter makes the "run" command fully redundant, but I
guess we'll keep it for simplicity. But change its implementation to use
mp_subprocess2() (couldn't do this earlier, because win32).
Privately, I'm going to use the "env" argument to add a key binding that
starts a shell with a FILE environment variable set to the currently
playing file, so this is very useful to me.
Note: breaks windows, so for example youtube-dl on windows will not work
anymore. mp_subprocess2() has to be implemented. The old functions are
gone, and subprocess-win.c is not built anymore. It will probably work
on Cygwin.
This probably makes it much faster (I wouldn't know, I didn't run any
benchmarks ). Seems to work as well (although I'm not sure, it's not
like I'd perform rigorous tests).
The scale_zimg test seems to mysteriously treat color in fully
transparent alpha differently, which makes no sense, and isn't visible
(but makes the test fail). I can't be bothered with investigating this
more. What do you do with failing tests? Correct, you disable them. Or
rather, you disable whatever appears to cause them to fail, which is the
threading in this case.
This change follows mostly the tile_example.cpp. The slice size uses a
minimum of 64, which was suggested by the zimg author. Some of this
commit is a bit inelegant and weird, such as recomputing the scale
factor for every slice, or the way slice_h is managed. Too lazy to make
this more elegant.
zimg git had a regressio around active_region (which is needed by the
slicing), which was fixed in commit 83071706b2e6bc634. Apparently, the
bug was never released, so just add a warning to the manpage.
Mess this into the --geometry option, because I like to be
irresponsible. I considered adding a separate option, but at least this
allows me to defer the question how the hell this should work as
property (geometry simply and inherently does not).
Tested on IceWM only. Option equality test and string output not tested.
I'm tired of dealing with this frequent spawning of xdg-screensaver when
debugging and what not. xdg-screensaver was never a serious tool anyway,
it's more like some self-deprecating joke by FDO folks.
This will affect X11 on GNOME and other DEs. I'm singling out GNOME
though, because they are the ones actively sabotaging any sane
technical solutions and community cooperation.
I have been accused of taking it out on innocent GNOME users, while none
of this will reach GNOME developers. Of course that is not the
intention.
libplacebo exposes this feature already, because this particular type of
bug is unusually common in practice. Simply make use of it, by exposing
it as an option.
Could probably also bump the libplacebo minimum version to get rid of
the #if, but that would break debian oldoldstable or something.
Fixes#7867.
Apparently mpv supports loading config files from the same directory as
the mpv.exe. This is a fallback of some sort. It used the old_home
mechanism.
I want to add a warning if old_home exists, but that would always show
the warning on win32. Obviously we don't want that.
Add a separate exe_dir entry to deal with that.
Untested, but probably works.
XDG is stupid, so change back to the standard behavior. Unfortunately,
most users will now have the XDG one, so we will still need to load
this. (This is exactly the same problem as when XDG support was
introduced, just the other way around).
This should not affect any normal users. Hopefully I tested this well
enough; my intention is not to torment miserable XDG fans; they can keep
using their config dir if they want it.
This changes behavior in two cases:
- new users (now creates ~/.mpv/ instead of ~/.config/mpv/)
- users which have both directories
The latter case will behave subtly or obviously different, not sure.
Just fix your shit.
Extend the manpage with all the messy details, as far as I could reverse
engineer them from the code.
De-emphasize it, since a user should usually not use it. This _could_ be
used to make the cache seekable with --cache=no, but it's better and
more intuitive to use --cache=yes. As such, the only use of this is for
debugging. I'm not quite sure if this should be removed entirely, but I
still see some value in it (for example if you want the cache lookahead,
but you're using a stream where cache seeking is somehow broken).
Implementation copy/pasted from:
https://code.videolan.org/videolan/libplacebo/-/commit/f793fc0480f
This brings mpv's tone mapping more in line with industry standard
practices, for a hopefully more consistent result across the board.
Note that we ignore the black point adjustment of the tone mapping
entirely. In theory we could revisit this, if we ever make black point
compensation part of the mpv rendering pipeline.
This standard says we should use a value of 203 nits instead of 100 for
mapping between SDR and HDR.
Code copied from https://code.videolan.org/videolan/libplacebo/-/commit/9d9164773
In particular, that commit also includes a test case to make sure the
implementation doesn't break roundtrips.
Relevant to #4248 and #7357.
