The screenshot command is documented to not overwrite existing files.
However, there is a race window between the filename is generated with
gen_fname and when the file is open to write. Specifically, the
convert_image function in this window can be very time consuming
depending on video and screenshot image format and size. This results
in existing file being overwritten because the file writing functions
don't check for the existance of file.
Fix this be opening the file in exclusive mode. Add overwrite parameter to
write_image for other operations that are documented to overwrite existing
files, like screenshot-to-file. Note that for write_avif, checking
existance is used instead because avio_open does not support exclusive
open mode.
Convenience to override name if imgfmt is not set.
Allows to create mp_image_params without setting imgfmt. Will be useful
for the next change where mp_imgfmt is not available. This is workaround
that will be remved once all codebase switches to pl_fmt.
Ended up being too flawed and caused trouble in other areas. There's
other approaches to trying to solve the issue this meant to address in
the works that should be better, so let's wait on that. Fixes#13613 and
fixes#13622.
This reverts commit e3af545421.
This seems more robust than relying on the audio status to actually be
playing. For files where there is no audio or the audio start is
delayed, this guards against that but it allows the subtraction to
always occur otherwise on normal files with audio.
This command initializes a vo dragging request for VOs that implement
the new VOCTRL_BEGIN_DRAGGING voctrl. This allows scripts to begin vo
dragging for any button press event.
Ended up being a bad idea. As a property, this inherently has more
functionality and the tradeoff of being able to do --ao-volume wasn't
worth it.
This reverts commit 58ed620c06.
When --osd-blur is set to a nonzero value, the graphs also become
blurry. This is because they are rendered by the osd-overlay command
with the "OSD" style which has OSD blur applied, and are treated no
differently from texts. Fix this by using the "Default" style for
these graphs which uses the default OSD options.
This came up in #13571. playing_audio_pts does not include mpctx->delay
contray to what that implies. The function is meant to only offset the
written audio pts by whatever the internal AO buffer may be.
mpctx->delay is a combination from both the audio and video code, so it
should not be used here. What is wanted is purely the audio pts.
b74c09efbf, a very controversial commit to
say the least, was what introduced this comment, so removing is probably
OK.
Playback speed changes should be treated as a discontinuity just like
seeking. Previously, this was being treated internally as just plain
normal playback, but that can't really work. The frame timings from
before the speed change and after the speed change are completely
different and shouldn't be compared to each other. This lead to frames
being adjusted to weird places and possibly even being skipped (as if
mpv was seeking) on speed changes. What we should do is clear out and
reset all av related fields like what happens when you seek, but it is
not quite as aggressive. No need to do a full video state reset or such.
We also wait an arbitrary amount of frames before adjusting for av sync
again. compute_audio_drift already used a magic number of 10 which
sounds reasonable enough so define that and use it here. Fixes#13513.
When calculating the audio pts, mpv multiplies the ao delay by the
current audio speed and subtracts it from the written audio pts. This
doesn't really make sense though. mpctx->video_pts is never affected by
the playback speed, and this leads to weird behavior like the audio-pts
property changing values while paused merely because the playback speed
changes. Remove the multiplication and simply subtract the delay by a
factor of 1 instead. When updating the av_diff in player/video, this
does actually need to take in account the audio speed so we do the
calculation there.
98a27b3cd1 changed this to mpv but that's
kind of pointless since the binary is already named mpv so that will be
the default thread name. Evidently, people rename/symlink the binary to
something else so might as well make them happier. Fixes#13469.
Change the `playlist_insert_next` function to `playlist_insert_at` (ie,
insert at the location of an entry, rather than after it, and rename to
be clearer that it doesn't have anything to do with the
currently-playing entry).
Also, replace calls to `playlist_add` with calls to
`playlist_insert_at`, since the former has become redundant.
Analogous changes to the previous commit ("add loadfile insert-next commands"),
but for the `loadlist` command.
This allows us to insert a new playlist next in the current playlist,
rather than just appending it to the end.
This commit adds two new commands (`insert-next` and `insert-next-play`)
which mirror the existing commands, `append` and `append-play` in
functionality, with the difference that they insert directly after the
current playlist entry, rather than at the end of the playlist.
This change gives MPV a piece of functionality already found in (for
example) Spotify's media player: "play next". Additionally, using the
new `insert-next` command, users can trivially write a script to play a
new piece of media immediately without otherwise clearing or altering
the remainder of the playlist.
Wayland was the only backend that attempted this, but it can be done in
a centralized place for anything that supports this. hidpi-window-scale
is just the same as a normal window scale but with the OS DPI as the
factor.
With --ignore-path-in-watch-later-config,
--write-filename-in-watch-later-config still writes the absolute path of
files in the comment, even though the hash is calculated from the
basename. Make it write the basename to avoid confusion.
Also stop writing redirect entries for parent directories with
--ignore-path-in-watch-later-config, both because it's redundant, and
because with this patch it would write the basename of directories in
the comment, which would be wrong because their hashes are calculated
from the absolute paths.
There's too many dumb options related to subtitles which have annoying
edge cases. Try to rewrite this completely so it hopefully behaves
normally in every expected scenario. A key goal here is be smarter while
looping through the tracks and avoid selecting the subtitle if it
doesn't meet user's passed options as opposed to clearing the pick after
the fact. Fixes#13280 and fixes#13263.
When using sub-seek without a video track while paused, adding the 0.01
SUB_SEEK_OFFSET to the new timestamp is not enough to show the new
subtitle line. Add 0.1 instead to fix it. 0.01 is already enough for
sub-step.
Since 03cf150ff3, the only purpose of this
VOCTRL was to signal a redraw to the vo. It actualy could have been
removed in 531868fe0d, but this was
missed. The UPDATE_VIDEO flag is better anyway because it allows us to
handle a wide variety of options scattered around that require the VO to
update itself and redraw. We can remove both of the custom callbacks in
vo.c and only leave the VOCTRL_VO_OPTS_CHANGED one. Additionally, that
commit also introduced vo_set_want_redraw, but this is redundant and not
needed. The VOs that use VOCTRL_UPDATE_RENDER_OPTS already set
vo->want_redraw, and those are the only VOs where these options are
relevant in the first place. So we can remove this as well and just let
the big callback in player/command do everything.
25b66256d7 originally added this
property, but it did not add it to the property notification. This is
possibly because the window id doesn't appear to change on x11 even when
toggling VOs at runtime. However, windows uses this property and
apparently the id changes there so we should signal updates when
appropriate. Fixes#13495.
This only affects two special cases: printing subtitles to the terminal
and printing subtitles on a still picture. Previously, mpv was very dumb
here and spammed this logic on every single loop. For terminal
subtitles, this isn't as big of a deal, but for the image case this is
pretty bad. The entire VO constantly redrew even when there was no need
to which can be very expensive depending on user settings.
Instead, let's rework sub_read_packets so that it also tells us whether
or not the subtitle packets update in some way in addition to telling us
whether or not to read more. Since we cache all packets thanks to the
previous commit, we can leverage this information to make a guess
whether or not the current subtitle packet is supposed to be visible on
the screen. Because the redraw now only happens when it is needed, the
mp_set_timeout_hack can be removed.
Move common_prefix_length() and related functions before the first call
to common_prefix_length(). It works now because it's global but if we
ever make all functions local for consistency it will stop working.
When adding things like brightness or gamma, the video obviously needs a
redraw if paused. This happened to work in the normal case because the
OSD notification triggered a redraw, but if you use no-osd the picture
won't change. Fix this by adding another option flag, UPDATE_VIDEO, and
simply signalling we want a redraw. This gets handled along with the
normal osd redrawing check in the playloop so something like "no-osd add
gamma 1" actually works.
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.
32-bit signed integer can hold ~2.1s stored as nanoseconds. While frame
duration doesn't make sense to be this long, the existing clamp is to
10s. Change type to double, which is consistent with other fields in
vo_frame.
This workarounds the issue with vo_gpu that would freeze in certain
condition. I haven't go deep inside to understand why, so this should be
considered as a workaround.
Fixes: #13256
