Commit Graph

48640 Commits

Author SHA1 Message Date
wm4 720bcd79d0 command: add a way to access properties of a current track
Requested. Should be good for simple use cases. "sub2" is technically
inconsistent (since the option is called --secondary-sid), but fuck the
consistent name.
2020-08-12 17:23:13 +02:00
wm4 45cc47a68b TOOLS/file2string: change to python3
The same was done to matroska.py before, so at least it's consistent.
Doesn't matter for waf, because it imports this script (rather than
executing it).
2020-08-12 17:21:49 +02:00
James Ross-Gowan bb231889fd win32: request the UTF-8 code page for Windows APIs
This sets the activeCodePage property in the manifest, which forces the
ANSI code page to be UTF-8 in Windows 10 1903 and up. It shouldn't make
a difference for mpv itself, since mpv already uses the wide-char APIs
for most functions, however some of mpv's dependencies, such as Lua,
rely on the ANSI codepage. Hence this change enables support for Unicode
file names in Lua's I/O library.

Thanks @avih for finding this property.

See:
https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page
2020-08-08 15:00:25 +03:00
ekisu cdd8ba7224 ao/lavc: add channels and channel_layout to AVFrame
FFmpeg expects those fields to be set on the AVFrame when
encoding audio, not doing so will cause the avcodec_send_frame
call to return EINVAL (at least in recent builds).
2020-08-07 19:42:42 +02:00
wm4 4c72202eb1 auto_profiles: unapply conditional profiles if declared
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.
2020-08-07 19:41:56 +02:00
wm4 1f132c675a options: add some way to more or less "unapply" profiles
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.
2020-08-07 19:41:56 +02:00
Avi Halachmi (:avih) d5a02dd934 js: hooks: allow deferred continuation (match d0ab562b)
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).
2020-08-07 15:12:20 +03:00
wm4 53ee1ae417 auto_profiles: register hooks for more synchronous profile application
The property observation mechanism is fairly asynchronous to the player
core, and Lua scripts also are (they run in a separate thread). This may
sometimes lead to profiles being applied when it's too load.

For example, you may want to change network options depending on the
input URL - but most of these options would have to be set before the
HTTP access is made. But it could happen that the profile, and thus the
option, was applied at an slightly but arbitrary later time.

This is generally not fixable. But for the most important use-cases,
such as applying changes before media opening or playback
initialization, we can use some of the defined hooks.

Hooks make it synchronous again, by allowing API users (such as scripts)
to block the core because it continues with loading.

For this we simply don't continue a given hook, until we receive an idle
event, and have applied all changes. The idle event is in general used
to wait for property change notifications to settle down. Some of this
relies on the subtle ways guarantees are (maybe) given. See commit
ba70b150fb for the messy details. I'm not quite sure whether it
actually works, because I can't be bothered to read and understand my
bullshit from half a year ago. Should provide at least some improvement,
though.
2020-08-05 23:28:24 +02:00
wm4 d0ab562b1f lua: make hook processing more flexible
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.
2020-08-05 23:19:41 +02:00
wm4 13d354e46d auto_profiles: add this script
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.
2020-08-05 22:37:47 +02:00
Dudemanguy f457f3839a manpage: clarify requirements for boxvideo
The osc must not auto-hide for this option to do anything.
2020-08-04 15:20:24 -05:00
Dudemanguy fb55ee99e3 wayland: don't set mouse pos on state change
Sway 1.5 started sending more pointer motion events to mpv which broke
the autohiding behavior. The cursor would appear again if you
fullscreened. Sway had a good reason to do this because certain
applications had inconsistencies between hardware cursor and software
cursor without rebasing on state changes[1]. So mpv needs to take this
special case into consideration.

Initially, simply checking mouse coordinates for changes was considered,
but this doesn't work. All coordinates are surface-local in wayland so
something can appear to move in the local coordinate space but not
globally. You're not allowed to know global mouse coordinates in
wayland, and we don't care about local coordinate changes in mpv so this
approach isn't viable.

Instead, let's just keep track of a local state change. If the toplevel
surface changes in some way (fullscreen, maximized, etc.), then just set
a bool that lets us ignore the mp_input_set_mouse_pos function. This
keeps the cursor from appearing simply because the state was changed
(i.e. fullscreening). For compositors that don't send pointer motion
events on a state change, this does technically mean that the initial
mp_input_set_mouse_pos is never set. In practice, this isn't a
noticeable difference though because moving a mouse generates a ton of
motion events so you'll immediately see it on the second motion event.

[1] https://github.com/swaywm/sway/issues/5594
2020-08-02 17:06:51 -05:00
Eva 359261c50c stats: fix crash when aspect ratio is unavailable
When switching between files it's possible that r["aspect"] returns nil, resulting in a crash.
2020-08-03 00:50:57 +03:00
Derek Guenther b238897614 ytdl_hook: fix typo in unexpected error message 2020-08-01 15:02:39 +03:00
Dudemanguy 10e11834e5 wayland: avoid potential deadlocks
wl_display_dispatch is dangerous because it will block forever if the
event queue is empty. Any direct calls to this function should just be
replaced with wl_display_dispatch_pending which accomplishes the same
thing for mpv's purposes without any chance of blocking.

The other potential trap is wl_display_roundtrip. It can internally call
wl_display_dispatch which in certain circumstances could potentially
block. There are cases where we need the server to finish processing
client requests before doing anything else so this can not be cleanly
avoided. The dangerous call is the usage of wl_display_roundtrip in
vo_wayland_wait_frame. In the majority of cases, this shouldn't be a
problem because the previous wl_display_read_events should always queue
up some events on the fd for wl_display_roundtrip to send. However, the
compositor could potentially send us an error in the display queue that
could lead to bad behavior when wl_display_roundtrip is called.

The wl_display_roundtrip can't be removed because we are relying on its
semi-blocking capabilities, but the logic can be slightly adjusted to be
safer. The obvious thing to do is to make sure we check the pollfd for
any errors. If one is returned, then we call wl_display_cancel_read and
try again. The less obvious trick is to call wl_display_dispatch_pending
and move wl_display_roundtrip outside of the blocking + timeout loop.

This change has some subtle but important differences. Previously,
vo_wayland_wait_frame would read an event and wait on the server to
process it one-by-one. With this change, the events are dispatched as
soon as possible to the server and then we wait on all of those
(potentially multiple) events to be processed after we have either
received frame callback or the loop times out.

After that is done, we can then check for if there are any errors on the
display. If it's all clear, we can run wl_display_roundtrip without any
worries. If some error happens, then don't execute the function at all.
2020-07-31 21:23:45 +00:00
der richter bb800352f5 travis: update macOS image from 10.14 to 10.15 2020-07-31 13:22:37 +02:00
der richter 3586ef77f3 travis: make macOS builds faster
the problem here is that with time, and because the macOS VMs don't get
updated, the homebrew update is getting longer since more and more
changes have to be pulled. to prevent that, we cache the homebrew
installation folder after the update. that way we don't have to update
several months worth of updates every build. for the legacy build we
have to check put master again to actually cache the newest homebrew
version.

additionally to that, we also do the same as on the legacy build, with
the addition of not removing all installed formulas but only the ones
we don't need. so we don't need to reinstall those.
2020-07-31 13:22:37 +02:00
der richter 16a08e87c8 travis: fix macOS 10.12 legacy build
just remove all pre installed formulas, since we don't need the majority
of it. after that install what we need. this also fixes the brew update
of those formulas where the source links were broken like popt.

this also helps when the build times out due to building some formulas
from source that are not dependencies we need.
2020-07-31 13:22:37 +02:00
Dudemanguy 700f4ef5fa wayland: correctly signal the end of drag-and-drop
Previously, the compositor was signaled that a drag-and-drop ended with
wl_data_offer_finish in check_dnd_fd. This is, however, erroneous
because it is outside of the data_device_listener and in some cases
caused errors with certain compositors. check_dnd_fd itself does not
need to know or care about anything that happens in wayland. It just
needs to read data from an fd. The simple fix is to just always signal
the end of a drag-and-drop in data_device_handle_drop. check_dnd_fd can
free memory and close the fd later, but it should not talk to the
compositor. Fixes #7954.
2020-07-29 18:36:54 -05:00
Dudemanguy 36951ab6a7 wayland: fix a potential race in wait_events
The read of the wayland display fd in vo_wayland_wait_events was
incorrect and technically vulnerable to race conditions. The correct
usage as per the client api is to use wl_display_prepare_read as well as
wl_display_read_events.
2020-07-29 17:45:42 +00:00
Dorian Rudolph 6e3d4aa94b af_scaletempo2: fix bug where speed was not set
the --speed parameter did not work with
mpv --no-config whatever.mp3 --video=no --speed=2 --af=scaletempo2
(https://github.com/mpv-player/mpv/pull/7865#issuecomment-664243401)
2020-07-27 18:12:05 +02:00
wm4 1fe6def066 af_scaletempo2: M_PI is always defined
I forgot why/how (C99?), but other code also uses it.
2020-07-27 00:59:37 +02:00
Dorian Rudolph 785a2b1261 audio: add scaletempo2 filter based on chromium
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.
2020-07-27 00:57:22 +02:00
Avi Halachmi (:avih) b5368980a8 js: add mp.utils.get_env_list() (match 0e7f53a5, 9301cb78) 2020-07-26 02:26:37 +03:00
Avi Halachmi (:avih) 9301cb78a8 lua: change mp.get_env_list() to utils.get_env_list()
It's documented (twice) at utils, and logically it's the correct place
for it.
2020-07-26 02:25:59 +03:00
sfan5 b67c7a23b8 stats: fix single invocation keybindings 2020-07-21 19:34:41 +02:00
Jan Beich f89c7404d1 manpage: drop --sdl-bufcnt after 346c687d5a 2020-07-21 15:08:47 +02:00
Eva 1732fb0555 external_files: add .pgs subtitle extension 2020-07-21 15:07:17 +02:00
James Ross-Gowan 83fec9bafb subprocess-win: update to mp_subprocess2
This fixes the "run" and "subprocess" commands on Windows, including
youtube-dl support.

Unix-like FD inheritance is emulated on Windows by using an undocumented
data structure[1] that gets passed to the newly created process in
STARTUPINFO.lpReserved2. It consists of two sparse arrays listing the
HANDLE and internal CRT flags corresponding to each FD. This structure
is used and understood primarily by MSVCRT, but there are other runtimes
and frameworks that can write it, like libuv.

The code for creating asynchronous "anonymous" pipes in Windows has been
enhanced and moved into windows_utils.c. This is mainly an artifact of
an unfinished future change to support anonymous IPC clients in Windows.
Right now, it's still only used in subprocess-win.c

[1]: https://www.catch22.net/tuts/undocumented-createprocess
2020-07-20 21:02:17 +02:00
wm4 4476911d45 manpage: add named arguments "subprocess" example
At the same time, this is an example for a command with named arguments.
2020-07-20 21:02:17 +02:00
wm4 d5959df2be client API: comment about signal handlers
Sharing a process sure is hard in POSIX.

The rationale is that you'd have to handle EINTR on every single
blocking syscall. stream_file.c does not seem to handle it on read()
calls.

It appears that on most modern systems, this can happen only if you call
sigaction(), and incompetently forget to add SA_RESTART. signal()
usually adds it.
2020-07-20 21:02:17 +02:00
wm4 0a796e9840 command: add another variant of revert-seek
Requested. See manpage additions. Not sure if it actually deserves to be
a first class feature, rather than an external script or so.

Fixes: #7913
2020-07-20 21:02:17 +02:00
wm4 0e7f53a5bc lua: add mp.get_env_list() function
Because Lua is too stupid to provide this directly, and I sort of need
it.
2020-07-20 21:02:17 +02:00
wm4 0279a44d93 command: extend subprocess command
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.
2020-07-20 21:02:17 +02:00
Dudemanguy c9742413ac wayland: remove unused declaration
Should have been removed in 055a490 but was forgetten.
2020-07-19 15:21:05 -05:00
Dudemanguy 63ae6037df build: actually install the 128x128 icons
mpv has generated this icon size for a while now, so go ahead and
install it in the usual place like the other icon sizes.
2020-07-19 12:15:48 -05:00
Niklas Haas c53a47eda3 vo_gpu: clip highlights before tone-mapping
Rather than after tone-mapping. This prevents overflow when the
pre-tonemapped signal contains inputs exceeding sig_peak. I also
realized that with this clipping in place, post-clipping no longer needs
to be done, so this isn't even particularly slower.

The only two exceptions to the rule are "clip" and "linear", which
relied on the post-clipping to do their tone mapping properly.

Fixes #7929
2020-07-19 08:07:48 +02:00
Niklas Haas 96cdf5315e vo_gpu: vulkan: print libplacebo API ver
This normally gets printed by libplacebo itself when initializing the
context, but due to the way our code is structured (for convenience) we
don't have the log hook enabled by the time this function call is
relevant. So instead just print it manually as an easier work-around
than restructuring the code.
2020-07-16 09:41:09 +02:00
wm4 2a89da0c85 zimg: add slice threading and use it by default
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.
2020-07-15 22:59:17 +02:00
wm4 f1290f7095 zimg: refactor (move around fields)
The intention is to add slice-threading to the wrapper. For that
purpose, move all zimg related state to a new struct mp_zimg_state.
There is now an array of instances of this struct. The intention is to
have one instance for each thread. As of this commit, this is hardcoded
to 1 thread; the following commit extends this.
2020-07-15 22:59:17 +02:00
Oleg Oshmyan d086421ca4 osd_libass: set ScaledBorderAndShadow
libass recently switched the default from 1 to 0 for compatibility
with ASS scripts that rely on the historical/VSFilter default of 0.

libass does attempt to detect and avoid breaking scripts that rely
on the historic libass-only default of 1, but it doesn't cover tracks
created directly through the API, so set the header explicitly.

Fixes https://github.com/mpv-player/mpv/issues/7900.
2020-07-15 15:49:03 +03:00
Philip Langdale fba1c681b8 vo_gpu: hwdec_vaapi: handle lack of object size with AMD drivers
It turns out that the AMD driver doesn't bother to set the size
field in the descriptor for an exported VA surface. I guess they
assume the caller can always use lseek() and don't bother. So, we
need to use lseek() in these situations.

Modified-by: Niklas Haas <git@haasn.xyz>

Guarded this behind PL_API_VER >= 88 to prevent it from exploding on
older libplacebo versions, where vaapi support does not yet work
properly on AMD due to lack of DRM modifiers.
2020-07-14 07:32:04 +02:00
Niklas Haas 22e7c700dd vo_gpu: hwdec_vaapi: add support for DRM format modifiers
This is required to get non-corrupted textures when importing vaapi
planes on AMD drivers.
2020-07-14 07:32:04 +02:00
sfan5 7a7a0a78b5 ao/pulse: fix reporting of playing state
When get_state() corks the stream after an underrun happens
priv->playing is incorrectly reset to true, which can cause the
player to miss the underrun entirely. Stop resetting priv->playing
during corking (but not uncorking) to fix this.
2020-07-12 23:44:41 +02:00
sfan5 f3b29a680c ao/pulse: flush stream on underrun
The underflow callback introduced in d27ad96 can be called
when the buffer is still full, causing playback to never
resume afterwards since get_state() reports free_samples == 0.
Fix this by fully resetting on underrun, which flushes
the stream and ensures free buffer space.

fixes #7874
2020-07-12 23:34:08 +02:00
der richter c82abb3a65 cocoa-cb: fix unfs window size when toggling out of fullscreen
we properly set the unfs window size on live resize end. due to a race
condition in the fullscreen events, which is also a live resize, the
unfs window size is incorrectly set to a fullscreen size. this happens
when the end fs screen event triggers before the end of live resize one.

this just adds a second condition to not be un fullscreen when updating
the unfs window size.
2020-07-12 12:06:56 +02:00
wm4 4a93b046e9 x11: add option to make window appear on a specific workspace
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.
2020-07-12 00:12:55 +02:00
wm4 06033df715 demux_lavf: workaround reading gif from unseekable streams
FFmpeg, being the pile of trash as usual, recently broke this. Add our
own trash hack to trashily workaround this shit.

Fixes: #7893
2020-07-09 12:29:22 +02:00
wm4 adbd28b1db player: fix outdated comment 2020-07-09 12:26:54 +02:00
wm4 b961efb0af sws_utils: do not mutate src/dst parameters
Probably did not cause any practical problems, but it sure seems
unclean. sws_utils users might also rely on these fields being exactly
the same as the actual input/output. It's better to avoid this.
2020-07-08 22:45:12 +02:00