--stop-playback-on-init-failure=no is documented to continue playback in
audio-only mode if video init fails. However, this does not function
properly after a080432992: because video
is initialized first, if video init fails, ao_chain is still null.
As a result, !(mpctx->vo_chain || mpctx->ao_chain) is true, a playback
error is raised, so the playback ends and audio does not play.
Fix this by reverting that change, so it checks the tracks instead.
Fixes: a080432992
Turns out that adding more medatata like HDR10+ and Dolby Vision would
produce a lot of duplication and it is better to centralize it around
the track-list property.
Fixes: e720159f72
If the player is paused, switching subtitle track requires us to read
subs packets for an indefinite amount of time in order to actually
display the subtitles. The problem with this is that it puts a blocking
loop in the play thread which can be slow in cases where it takes a long
time to fetch the subtitle (e.g. over a network).
9e27b1f523 alleviates this when a pause
happens because of buffering, but it's not complete. One could encounter
this if the user pauses the video first manually and then switches the
subtitle track.
To solve this better, make it so the loop has a time out (totally
arbitrary number) so the player isn't blocked forever. If subtitles are
not fetched within that time, we flag the track and try again later in
the playloop.
Section 12 of Matroska Media Container Format Specifications says:
If a BCP 47 Language Element and an ISO 639-2 Language Element are used
within the same Parent Element, then the ISO 639-2 Language Element MUST
be ignored and precedence given to the BCP 47 Language Element.
Fixes: #8144
Adds support for extracting codec profile. Old properties are redirected
to new one and removed from docs. Likely will stay like that forever as
there is no reason to remove them.
As a effect of unification of properties between audio and video,
video-codec will now print codec (format) descriptive name, not decoder
long name as it were before. In practice this change fixes what docs
says. If you really need decoder name, use the `track-list/N/decoder-desc`.
The protocol strongly implies that this only happens when the value
changes, and it's also what you would naturally expect. But maybe it's
worth guarding this in cause for some reason the same value twice in a
row happens.
The mpv window overlapping multiple outputs with different scale values
can result in some weird behavior when dragging it from one monitor to
another one. This is due to the way some compositors implement
preferred_scale or preferred_buffer_scale (integer scale equivalent).
Depending on the scale values, mpv window has to be resized to match the
new scaling value (due to fractional scaling requiring a viewport). This
can cause the window to become smaller and no longer overlap the monitor
you were just trying to drag it to. Repeat this and the window will
become smaller and smaller. Depending on the layout, the reverse can
also happen (the window becomes larger). This can cause additional
events to fire as the preferred_scale value may change again which does
more weird things.
It seems kwin is not affected by this because their implementation of
preferred_scale sends the event only if the window is fully on the new
monitor. Honestly, this is probably more logical anyway but we should at
least deal with the other implementations better. Try to deal with it by
reworking scaling changes so they only occur when the mpv window is
fully on one monitor. If we get a preferred_scale event and there is an
overlap, save it as a pending change to be performed on the next
surface_enter or surface_leave event (whichever results in there being
only one monitor. Some weird rendering glitches can still happen during
overlap but this makes it usable again.
Turns out libplacebo uses unrotated target crop in relation to source.
Use dst rect from VO, instead of extracting it from pl_frame, to avoid
another unrotating operation.
Fixes: a9354b36ca
Previously if mpv's size was constrained by the compositor's configure
bounds event, there was no attempt to preserve the aspect ratio of the
given coordinates if --keepaspect (the default) was used. Be sure to
apply keepaspect to the bounded widths and heights if we are using this
event.
The reconfigure event handles setting fullscreen, maximize, etc. We were
implictly relying on the compositor to just ignore mpv if we set a
redundant state (e.g. setting fullscreen when we're already fullscreen),
but kwin actually doesn't and operates again. This causes some subtle
issues when handling geometry on state changes. Rework the state change
calls so they are only executed if wl->geometry_configured isn't set yet
(i.e. the window just opened up for the first time). It's the only time
this is actually needed.
If mpv is coming out of some locked size state (fullscreen, maximized,
tiled), the window size given by the reconfigure event should be used
assuming the --auto-window-size option is set.
Fixes 8a9749b8a5
the mp_log is freed when the corresponding mpv_handle (ta_parent) is
freed in the EventHelper, though it could still be used from different
threads. instead don't use a ta_parent and manually free on manual
dereferencing. on app shutdown (memory cleanup) this is not called but
instead is freed by the usual cleanup and freeing.
the LogHelper is only able to be manually dereferenced in the AppHub,
so no race conditions are possible in all other cases (vo).in the AppHub
it's impossible to hit a race condition atm, because of how the init
process works and how/where the log is used. only manually forcing
logging in the exit process itself could theoretically trigger a use
after free.
Fixes#13823
Playback with many audio channels could be distorted when using
scaletempo2. This was most noticeable when there were a lot of quiet
channels and few louder channels.
Fix this by increasing the weight of louder channels in relation to
quieter channels. Each channel's target block energy is factored into
the usual similarity measure.
This should have little effect on very correlated channels (such as most
stereo media), where the factors are very similar for all channels.
See-Also: #8705
See-Also: #13737
When converting a list to string for show-text, since
05c398fb6c the OSD_ASS_0 escape hatch
is used. This usage is problematic because the same format string is
used for print-text, which results in these ASS escape sequences
being printed in the terminal.
Also since d6610a5b2f, the print-text
output to console.lua is no longer escaped if OSD_ASS_0 is present.
This results in abnormally formated text in the console output.
Fix this by not using ASS escape sequences for this. Instead, use the
circle symbols used by the OSC, which also results in the same width
for active and inactive items.
this will prevent jumping of the window size in the case the window size
was 'externally' modified and not via the window-scale property, when
using the pinch gesture.
Fixes#11594Fixes#13799
Lots of filters have generic internal function names like "process".
On a stack trace, all of the different filters use this name,
which causes confusion of the actual filter being processed.
This renames these internal function names to carry the filter names.
This matches what had already been done for some filters.
"playthread" is a confusing name which doesn't describe what it really
is. Rename it to ao_thread, and ao_wakeup_playthread to ao_wakeup,
in the same style as VO threads. This makes call stack function names
less confusing.
This commit was originally sparked by a change in sway. When looking at
the wording of the spec, it was believed that the rotation should be
counter-clockwise. But that was interpreted incorrectly. The rotation
direction in the spec is meant for compositors not clients. Clients
should be rotating clockwise and compositors rotate it the opposite
direction. Also see the discussion in upstream wayland*.
*: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/369
This reverts commit 27ef1725e7.
Allows to avoid non-portable strlen usage. Also avoid "initializer
element is not constant" warnings on older GCC that doesn't like
explicit type specification in aggregate initialization.
Co-authored-by: NRK <nrk@disroot.org>
Co-authored-by: nanahi <130121847+na-na-hi@users.noreply.github.com>
Removes mp_puts/mp_fputs and adds mp_fwrite.
In fact I wanted fwrite instead of puts, no need to make it more awkward
with the implicit new lines.
Fixes: fc55f355fc
This is multiple times faster than just writing every pixel sequence
separately. Especially on slower terminal emulators. In general no need
to stress I/O, while we can just prepare the frame to print and do it
once.
This change is mostly motivated by missing
VK_KHR_portability_enumeration instance extension when enumerating the
devices. Which causes issues with MoltenVK which does not advertise full
Vulkan conformance.
To avoid duplicating code use pl_vk_inst_create() which correctly query
availability and enables the mentioned extension.
While at it fix the VkInstance leaking in vk_validate_dev().
Probing for hwdec can be very slow: on my setup (Nvidia GPU without
VP9 hwdec capability), this causes 2x hot cache startup time compared
to explicitly disabling VP9 in this list (500 ms -> 1 000 ms).
Also remove --vo=vdpau reference.
In many places, flags options have duplicate descriptions like
--break-player and --no-break-player. This is redundant since the
equivalence of this syntax to --break-player=<yes|no> is already
documented, and the =<yes|no> syntax is more in line with the syntax
of other option types.
This replaces all usage of --no-foobar with --foobar=no, and use
--foobar=<yes|no> when possible.
A figure from pipewire documentation:
```
stream time domain graph time domain
/-----------------------\/-----------------------------\
queue +-+ +-+ +-----------+ +--------+
----> | | | |->| converter | -> graph -> | kernel | -> speaker
<---- +-+ +-+ +-----------+ +--------+
dequeue buffers \-------------------/\--------/
graph internal
latency latency
\--------/\-------------/\-----------------------------/
queued buffered delay
```
We calculate `end_time` in the following steps:
1. get current timestamp in mpv
```
int64_t end_time = mp_time_ns();
```
2. add duration of samples to enqueue
```
end_time += MP_TIME_S_TO_NS(nframes) / ao->samplerate;
```
3. add delay of the pipewire graph
```
end_time += MP_TIME_S_TO_NS(time.delay) * time.rate.num / time.rate.denom;
```
4. add duration of queued and buffered samples.
```
end_time += MP_TIME_S_TO_NS(time.queued) / ao->samplerate;
end_time += MP_TIME_S_TO_NS(time.buffered) / ao->samplerate;
```
New in this commit. `time.queued` is usually zero as `SPA_PARAM_BUFFERS_buffers`
is default to 1; however it is not always.
`time.buffered` is non-zero if there is a resampler involved.
5. add elapsed duration from when `time` is captured
```
end_time -= pw_stream_get_nsec(p->stream) - time.now;
```
New in this commit. `time` is captured at `time.now`.
From then, time has passed so we need to exclude the elapsed time,
by calculating the diff of `pw_stream_get_nsec()` and `time.now`.
instead of using the MP_KEY events (Int32) and using a logical OR to
generate a key event for the mpv core, use the cocoa event type for key
states and pass those to the the function. in the function we properly
map those events to the right MP_KEY events.
when dropping more than one file on the App icon or opening via Finder
the open(urls:) event might not pass all files at once in the array, but
may consecutivly call open(urls:) for each of the files or batched in
several arrays.
to fix this append any file passed to the open(urls:) event within 0.1
seconds of each other to the current playlist. the first event uses the
default behaviour.
the unfsContentFrame wasn't updated when externally resized leading to
a wrong unfs window size afterwards. update it on windowDidResize event
when not in fs, not animating and not live resizing.
No idea how things previously worked without having these set, but
apparently they did...
If this was a normal encoder to muxer case, we would utilize
`avcodec_parameters_to_context`, but alas this is not.
Fixes: #13794
`hotplug_cb` was registered only in `hotplug_init()`.
This commit make it registered in `init()` as well,
so that the ao can listen for latency change
in playback.
When a video-reconfig occurs with an image, the cache is not used
because find_cache_seek_range() checks if the start time was
initialized, but for images it stays at MP_NOPTS_VALUE. This makes
rotating large network images slow because they are re-downloaded on
every rotation.
Fix this by setting the timestamps of image cache ranges by altering a
condition.
This field is used by compare_track when determining if the next track
should be preferred. The only problem is that we were only setting this
in compare_track which isn't used for the very first subtitle track
selection. So if the first subtitle track was a forced track that was
selected, this wasn't marked and the next subtitle track could
mistakenly be detected as preferred. Fix this by setting the field after
we set pick equal to the track in select_default track. Fixes#13804.
when in libmpv mode there is no need to for logging and reading options.
this also prevents possible race conditions with the usage and deinit of
the mpv_handler.
NSApp.terminate() is not a requirement to properly shut down a cocoa
App since it only calls exit() internally. though when not used the
cocoa termination events won't trigger, which we don't need. this
prevented us to exit with a proper exit code.
rework the whole termination logic to end up at one point where we can
return the exit code from the mpv_main function.
Fixes#7456
this event has several advantages, it unifies the mpv:// url handling,
the dropping of files on the App icon and opening via finder into one
event, and it also lets us remove the file open workaround.
we had to keep track of opened files via the command line because the
event was also triggered by passed files on the command line, leading
to redundant load events.
the new event doesn't trigger from files passed via the command line
anymore.
since cocoa is initialising mpv and does several things before the mpv
core does anything and the mpv_handle was passed to the App, this can be
used to log such things before the mpv logging is available. helpful for
debugging especially bundle related things.
the logger mapping looks a bit unintuitive but error is basically yellow
what our warning is and fatal is red what our error is.
At least on some compositors, when the pointer enters a surface,
only a wl_pointer_enter event is generated, but not wl_pointer_motion.
This results in the initial mouse position being lost, which is
especially problematic when input simulation is used.
Fix this by setting the mouse position on pointer enter event.
`buf` contains a `struct spa_data` for each channel.
Therefore the number of channels does not matter to calculate the frame capacity of one `struct spa_data`.
In practice this shouldn't make a difference as `b->requested` would reduce nframes even more.
During AO init, snd_pcm_open() is called, which calls snd_config_update()
to allocate a global config node and stores it in the snd_config global
variable. This is never freed on uninit.
Fix this by freeing the global config node on uninit.
this broke with the recent refactor of the input handling. one of the
edge cases was not considered, where not every mouse down event has a
corresponding mouse up event, eg all double clicks or more only have one
up event after the first down event.
this was handled correctly previously.
Fixes#13777
win32 does not respect --native-keyrepeat option, and native key
repeat has been broken since 0ab3482f73.
This lets mpv respect the --native-keyrepeat option on win32.
The device latency may change during hotplugging.
This commit updates p->hw_latency_ns each time
hotplug_cb is called so that it can reflect
updated device latency.
With certain speed settings, the following can happen at the start of
the playback:
- can_perform_wsola returns false, so no frames are written
- mp_scaletempo2_frames_available returns true when
p->input_buffer_final_frames is 0 and target_block_index < 0
This results in infinite loop and completely stalls audio filter
processing and playback. Fix this by only checking this condition
after the final frame is set.
Fixes: 8080d00d7f
Would be better to search the other way around, because options list is
bigger than property list, but with minimal changes this is good enough.
Both are relatively small tho and the only reason for this micro
optimization is to increase the fuzzing throughput.
add new app_bridge objc file for bridging between mpv core and app
functionality. replace old EventsResponder singleton with AppHub.
another step to clean up all App functionality and have one central
place for it.
As far as I can tell PulseAudio introduced a bug in 16.0
where if a stream is (un)paused too often the reported latency
will momentarily spike by 3000% or more. Apparently in certain cases
just pausing once and waiting can also cause this.
Save the remaining users of PA the trouble of debugging the various
obscure issues that can arise from this (desync is a harmless example)
by enabling the latency hack code again.
ref: <https://github.com/mpv-player/mpv/issues/12057>
<https://github.com/mpv-player/mpv/issues/10333>
Both possible paths had bugs:
For OpenGL it passed EGL_CONTEXT_CLIENT_VERSION, which - in older versions
of the standard - was not permitted.
For GLES it always assumed EGL_CONTEXT_FLAGS_KHR to work, which belongs to the
aforementioned extension.
Ironically this was never a problem (probably saved by implementations
not being overly strict) except in 2024 on an emulated Android 14 device
that trips over this edge case. It is a mystery.
Basically a simple way to perform any command/property action from the
command line. This takes the exact same syntax as input.conf but not
including the key naturally. Potentially useful for weird properties
that don't map well to options (like ao-volume). Fixes#12353.
This enhancement makes it easier to create constant width property
expansions, useful for the `--term-status-msg`. Additionally, it changes
to `%f` printing with manual zero trimming, which is easier to control
than `%g`. With this method, we can directly specify precision, not just
significant numbers. This approach also avoids overly high precision for
values less than 1, which is not necessary for a generic floating-point
print function.
A new print helper function is added, which can be used with adjusted
precision for specific cases where a different default is needed. This
also unifies the code slightly.
Escape all messages in osc.lua, because other than the title they
weren't being escaped at all. If for example you did mpv foo.mp4
'{\fs50}bar.mp4' and script-message osc-playlist, it would just render
the second entry as bar.mp4 in big text.
The title was escaped partially, now the escaping is complete because:
- It escapes \. Backslashes at the end of the title are escaped instead
of being stripped, and \n, \N and \h are now printed verbatim. In
particular, "\\n" is no longer converted to space and is printed
verbatim instead which is more correct.
- Newlines ("\n", not the "\\n" escape sequence) are converted to spaces
instead of rendering them and messing up the text positioning within
the OSC.
- Spaces at the start are preserved.
Fixes#11209, fixes#11275.
This adds a command to escape ASS tags to remove code duplication
between sub/osd_libass.c, console.lua, osc.lua, stats.lua and any user
script that calls mp.create_osd_overlay().
A command is used instead of scripting functions so that all clients can
use this and not just use Lua and JS ones.
osd_mangle_ass() also interprets osd-sym-cc and osd-ass-cc/{0,1}, but
since they use invalid UTF-8 characters there is no risk of escape-ass
users using them by accident, like with any OSD message.
Always replacing \n with \\N in mangle_ass() even when it is not called
by escape-ass doesn't seem to cause any issue, but I made it conditional
anyway to avoid changing how all OSD messages are treated unnecessarily.
585d8c6856 increased max active
section limit from 5 to 50 but this obviously doesn't properly fix
the problem. Input still breaks if more than 25 scripts are loaded,
or if some scripts define lots of input sections.
Remove the limit completely by using a dynamic array for active sections.
Fixes: https://github.com/mpv-player/mpv/issues/13707
The terminal output was static in size with no way of automatically
adjusting it to the current terminal size.
The new term-size property makes truly automatic adjustment possible.
There was no way for scripts to know the current size of the terminal,
which is essintial if they want to provide a good user experience even
without a window.
The scroll hint on page 4 had baked in ass tags, which shouldn't be
there in the terminal. Also the scroll hint on page 0 was missing.
Refactor scroll hint generation into a function and use that for
pages 2, 4 and 0.
The terminal is assumed to be 80x24 in size, the new options
`term_width_limit` and `term_height_limit` can be used to overwrite
that.
Lines longer then the terminal width cause problems with scrolling
pages and need to be shortened.
The algorithm used for shortening can deal with tabs and escape
sequences, has rudimentary support for UTF-8 and runs in O(n).
avih helped in the creation of the term_ellipsis() function and split()
is also from him.
Pages 2 and 0 had their own scroll implementations, which worked fine
for ass, but didn't work well in the terminal.
Now they both use the same scroll function as page 4.
That scroll function requires each output line to be one entry
in the table. Page 0 did not adhere to that new requirement, instead
it generated two table entries for a single output line when a graph
is shown. To fulfill that requirement the generated graph now gets
directly appended to the same table entry that's used for the rest
of the line.
This scrolling implementation will be used for other pages in future
commits.
The comment said it takes up 20 lines of the terminal, but in reality
it was 22 lines.
Make it more straightforward by always calculating top offset first
instead of having two branches, that tries to calc it directly.
This also fixes missing negative check before `\033[%dA` which was in
practice only problem on macOS which was handling negative values, while
in fact it shouldn't.
Fixes: #13484
Manually editing interface-changes.rst is a giant maintenance pain that
causes merge conflicts all the time. Stop doing that nonsense and
instead have changes be written to files in DOCS/interface-changes. Also
remove that one sentence in changes.rst because it's just not true.
timeBeginPeriod() only allows setting minimum timer resolution
to 1 ms. However, modern x86 platforms support a minimum timer
resolution of 0.5 ms. Use NtSetTimerResolution() instead for
the increased resolution, which can be set with MPV_HRT_RES.
Additionally, change the units of mp_start_hires_timers(),
mp_end_hires_timer(), MPV_HRT_RES, and MPV_HRT_MAX to nanoseconds,
in accordance with other functions used in timer.h.
GetConsoleMode() can be quite slow and in mpv the mode never changes, so
we can just check it once.
Fixes performance when writing lots of logs to terminal.
%s is evaluated as wchar_t only in "Windows classic" semantic. It is not
C standard compliant.
%ls is compatible with both and means the same wchar_t format.
This commit fixes error output from mpv.com.
See: https://devblogs.microsoft.com/oldnewthing/?p=102823
This is default behavior to attach to existing console, passing custom
handles is useful if we want to replace them, but in case they are
already attached to console we want to attach to console directly.
In theory, it should work out of the box because "console-like" handles
should be managed by Windows internally, which works for INPUT and
OUTPUT, but in certain cases, not for ERROR. This allows using VT
features in those cases for stderr too.
When 3cb9119984b88b31a5b958b1b83efe8d1cf0b818 introduced AVIF screenshot
support, FILE * in write functions were replaced by filenames. This
resulted in unnecessary duplication of FILE * handling code and the usage
of avio_open API made it hard to use exclusive open with it.
To unify file handling, use avio_open_dyn_buf instead which writes to
memory instead. This way FILE * can be used for the write functions
and file handling code can be deduplicated. Since we now control
the file opening, exclusive open can now be used for AVIF screenshots.
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.
This flag is a GNU extension in C99, but was standardrized in C11,
so mpv should be able to use it. fopen is wrapped on win32 so
non-compliant MSVCRT.dll isn't a concern.
Since the upcoming commit uses this feature it can be brought back.
This reverts commit c36e051470.
This commit allows image_writer to attach HDR metadata to AVFrames via
the corresponding AVFrameSideData attachments, if present. It does this
by calling pl_avframe_set_color, already used by mp_image_to_avframe.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Debanding is an inherently destructive process. It is not needed for
most high-quality sources and only produces an adverse smoothing effect
when applied to fine-detailed content, removing detail. It should only
be applied when necessary, either manually with the `b` keybind or with
an automatic profile.
Additionally, it is quite computationally heavy with no real benefit for
high-quality content.
By default, and especially in the high-quality profile, mpv should
preserve source detail and quality as much as possible. Additional
processing should be opt-in.
Fixes the issue described in https://github.com/mpv-player/mpv/issues/11862
for SDR files for non-d3d11 gpu-api. We currently don't have a smarter
way to get the real on-the-wire bpc for other APIs, so this is the best
that can be done.
Windows 10 top bar height cannot be adjusted individually when
WS_CAPTION is enabled due to buggy DWM NC drawing behavior. The issue is
fixed in Windows 11.
To keep consistent window look remove the border on each side, but only
on Windows 10.
Windows 11 draws border regardless, so we are 1px off on window size,
blending border with one line of video. Fix that by adding the border to
our internal windows size calculation.
Windows 10 on the other hand has a bug where specifying left and top NC
area will trigger title bar drawn in full height always. Keep old
behaviour in this case. Also while there is similar "visible" border
there, it seems to be transparent on Windows 10.
For high contrast themes, don't adjust title bar height and instead
remove WS_CAPTION to have the same border all around the window, as DWM
doesn't make borders invisible in this case.
With runtime geometry change, currently it only results in a
SetWindowPos call to resize the window. However, SetWindowPos doesn't
change the window maximized state, so Windows still thinks that the
window is maximized even though it no longer covers the whole workspace.
This results in visual glitches, and if the window is dragged afterwards
it's "restored" again.
Fix this by correctly setting the window maximized state in this case.
Currently mpv always uses the previous window size when unmaximizing
or exiting fullscreen. This disregards compositor's preferenced size in
the configure event, resulting in wrong window size if changing window
state and size are delivered in the same configure event.
It's better to always respect the preferenced size instead, unless
the state change is due to runtime geometry change, where we want
to use our preference.
Clarify that --autofit-larger sets the maximum size of the window.
The original wording was not written with runtime change in mind,
so the implication of "not changing size" is ambiguous.
In the xdg_toplevel_configure handler, in some cases the geometry is
not equal to the width and height in the event. This can happen
when runtime geometry change is requested (a new size is set),
or in the case of wl->state_change || width == 0 || height == 0
(the old size is used).
However, prepare_resize always uses the width and height in the event
and not the corrected geometry here. This causes
xdg_surface_set_window_geometry using the wrong value resulting in
wrong size of window decoration. Amusingly, the debug message right
above it uses the correct size.
Fix this by using the updated geometry size instead. Since now all
prepare_resize have parameters of 0, the width and height parameters
are no longer needed.
Fixes: 828dd65ef8
8e793bde78 made that changing geometry
while maximized has no effect until the window is unmaximazed. However,
this behavior is inconsistent with setting window-scale on all of win32,
wayland, and x11, which always unmaximizes the window and sets the
window size.
Since setting geometry is conceptually similar to setting window-scale
(both change the window size), they should have the same behavior.
If not fullscreen, unmaximize window on runtime geometry change to
keep the behavior consistent with window-scale.
Currently, setting geometry on runtime only changes the window size
but not the position. This is because reset_size is only set if
the window size is changed, and vo_x11_highlevel_resize doesn't set
the window position without force_window_position enabled. Fix this
by setting the related flags and perform a window move when
geometry is updated.
Fixes 8e793bde78.
Commit 39f7f83 changed ao_driver.reset to use AudioUnitReset instead of
AudioOutputUnitStop. The problem with calling AudioOutputUnitStop was
that AudioOutputUnitStart takes a significant amount of time after a
stop when a wireless audio device is being used. This resulted in
lagging that was noticeable to users during seeking and short
pause/resume cycles. Switching to AudioUnitReset eliminated this
lagging.
However with the switch to AudioUnitReset the macOS daemon coreaudiod
continued to consume CPU time and did not release a powerd assertion
that it created on behalf of mpv, preventing macOS from sleeping.
This commit will change ao_coreaudio.reset to call AudioOutputUnitStop
after a delay if playback has not resumed. This preserves the faster
restart of playback for seeking and short pause/resume cycles and avoids
preventing sleep and needless CPU consumption.
Fixes#11617
The code changes were authored by @orion1vi and @lhc70000.
Co-authored-by: Collider LI <lhc199652@gmail.com>
This is useful e.g. when the caller dup2's a socket into stdin, or
passes a socket/pipe as /dev/fd/{fd}, because it is impossible to seek
on sockets and pipes.
As the first aligned format this required a fix to reconfig().
Adding the other component-swapped formats in this group would be trivial
but I checked the DRM database [1] and no driver exists that supports
one of those but not YUYV and this is quite fringe as-is, so I opted not to.
[1] <https://drmdb.emersion.fr/formats>
The VO generic code tries to be helpful and resets this after
each reconfig. However for the simpler VOs the target params
are constant after a reconfig or even for the entire lifetime.
So it's clearly better to let the VO decide.
This also allows the VO to use a static buffer instead.
Segfaults otherwise on uninit because some objects are created while
others are not. Move it to the very top since the purpose of this is to
skip wayland initialization entirely while autoprobing.
Fixes f6f1721101.
Currently, Wayland is above X11 and DRM in probe order. The success
of automatic probing depends on the fact that unsuitable backends
would fail to initialize. For example, X11 backend (which uses Xlib)
fails to initialize if DISPLAY environment variable is not set, so
starting mpv in VT console will pick the DRM backend as expected,
even when an X server is running in another VT.
However, libwayland-client used by the Wayland backend has the
"helpful" behavior of falling back to "wayland-0" if WAYLAND_DISPLAY
is not set. This breaks autoprobing if mpv is started from X server
or VT console while a running Wayland compositor running in another
VT (or even running as an X client) is using "wayland-0" for protocol
socket name: mpv will start playing in the Wayland compsitor instead
of using the X11 or DRM backends.
Similar to DISPLAY for X server, We should consider exporting
WAYLAND_DISPLAY to child processes the responsibility of Wayland
compositors, and any compositor not doing this should be considered
broken. Thus we now require WAYLAND_DISPLAY to be set for the
backend initialization to succeed to make sure that autoprobing
works as intended.
It seems that GLX requires us to explicitly set opts.want alpha before
ra_ctx_create is called. b7fd232524
rearranged the function calls in a way made this not work. Fix this by
rearranging it again so the value is set before ra_ctx is created.
For image formats with 2 or more chroma planes such as YU12, there is
a plane merging pass for these planes calling finish_pass_tex which
does a format conversion. After this conversion, the cscale shader
afterwards works properly.
However, for image formats with only 1 chroma plane (semi-planar formats),
including NV12 and P010, this merging pass is never called, which breaks
the cscale shader afterwards if the video is rotated with subsampled
chroma.
Fix this by adding an explicit conversion pass if this situation is
detected after the pre-scale hooks, so if there are shaders hooking on
CHROMA (like the deband filter) and the conversion is done by pass_hook
already, this conversion won't be called.
`--no-config` should prevent loading any user files, whether it be
config, cache, watch_later state etc. This functionality was changed by
df758880e2 because internally `--no-config` is equivalent to passing
`--config-dir=""` which resulted in cache and state being auto-detected
even if `--no-config` was passed.
Fixes: df758880e2 ("path: don't override "cache" and "state" paths with configdir")
76276c9210 introduced a generic filtering
framework which replaced the separate video and audio filter chains.
Additionally, 6d36fad83c and
76e7e78ce9 made the decoder wrappers
a filter.
Add a new section to document this, and corrrect the outdated
audio/video decoder and filter info.
replaces the old focus-on-open option with a more generic focus-on
options that can be extended.
adjust the only platform that uses that option.
Fixes#8337
This should only be a problem during initialization. If in a
multi-monitor setup, mpv guesses the wrong scale value and the user
passes --fs, the scaled size will be wrong and you have to unfullscreen
and fullscreen again to fix it. This is because rescale geometry won't
do anything if the value of hidpi-window-scale is false (the default) so
the geometry is never rescaled to the correct value thus the wrong size.
Normally, mpv will just correct itself after subsequent events occur but
because it is considered a locked size (as it should be), we avoid doing
any other resizing events thus it never gets corrected. Fix this by just
always rescaling the geometry in the locked size case. It shouldn't
matter elsewhere because mpv will always have the correct scale value
and the possibility of having the wrong one is only possible on startup.
Fixes ded181f642
These options were deprecated with the addition of the channel layout
API about a couple of years ago*. Unfortunately, we never saw the
deprecation messages so it went unnoticed until they were completely
removed with the recent major version bump. Fix this by setting
in_chlayout and out_chlayout instead if we have AV_CHANNEL_LAYOUT.
Fixes#13662.
*: https://github.com/FFmpeg/FFmpeg/commit/8a5896ec1f635ccf0d726f7ba7a06649ebeebf25
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.
mpv isn't really a game and categorising our App bundle as game seems
counterintuitive. though as a video player it does have some
similarities, possibly needing considerably CPU and GPU resources and
low presentation latencies.
the macOS Game Mode promises exactly that, it gives App the highest
priority access to CPU and GPU resources and lowers usage for background
tasks.
sadly the Game Mode can only be activated by categorising the App as a
game and that is only possible with an App bundle and not as a command
line tool.
only add the "Show log File…" menu item config when invoked from the
bundle, instead of testing on menu item creation. this is similar to the
touch bar menu items now.
keeping track of the dynamic menu items lets us directly access them by
key. we don't need to search in the config array for the right config
and menu item.
the check broke when the runtime check was removed, eg the menu item was
never added to the menu. since we only add the menu item to the config
when touch bar support is available the check is completely unnecessary.
Not sure if this is particularly useful, but we might as well generate
these as well. Also use the docutils wrapper since that's what the meson
build does.
Some incorrect syntax is used in DOCS/man/input.rst with https://github.com/mpv-player/mpv/commit/c678033c1d60b48ae02fbbe4815869b9504a17f6
causing failure of PDF manual generation with rst2pdf. There are single
rather than double back-ticks for insert-at and insert-at-play so this
is fixed and a couple of typos are also corrected with this commit.
the render size cached in ctx->vo->dwidth/dheight can be outdated in
some circumstances at the time the context needs resizing. instead use
the current render size.
MoltenVK itself tries to work around a supposedly Metal problem that
itself causes flicker, black screens or broken rendering. it sets the
drawableSize to 1x1 to forcefully complete the presentation. though if
1x1 resolution frame is presented it causes a visual flicker or rather
a solid coloured frame. it causes even more problems since sometimes it
does not reset the drawableSize to the proper resolution and keeps
rendering everything in 1x1.
work around this workaround by discarding drawableSize that are <=1 in
any direction.
Fixes#13505
c2129c18f8 saves the button down serial to
pointer_serial of the seat so that it can be used for window dragging
later. However, this overwrites the serial saved at the enter event.
Since the serial in wl_pointer_set_cursor must be the latest
wl_pointer_enter serial number sent to the client, if a button down
serial overwrites that, setting cursor no longer works until the cursor
enters the window next time.
Fix this by using separate serials for these two types of events.
refqueue gets the field of the frame from mp_image which almost always(if not
always) assumes bottom field order first. By default this behavior should not
change but specifying the field order should bypass this.
Previously there was no way to specify the field order of interlaced videos
when deinterlacing with inbuilt filters. Lavfi deinterlacers seemed to prefer
top field order while inbuilt ones (vdpaupp, vavpp, d3d11vpp) seemed to prefer
bottom field order. The default "auto" option should work exactly as before
while specifying either "tff" or "bff" should force the specified field order
It's been a longstanding issue in wayland* that the first frame on a
hidpi screen will have wrong scaling. A well behaved client immediately
corrects this, but it's noticeable and also can affect window placement
due to the way resizng works. Preferred scale from the fractional
protocol and preferred buffer scale can actually solve this problem. It
depends on compositors mostly, but one could simply send the event
before the client maps its surface so it knows what the correct scale is
in the first place. I'm not sure if any compositors currently behave
like this (sway seems to still require the client to render before
sending any scaling information at least), but it makes to sense to
account for this possibility.
*: https://gitlab.freedesktop.org/wayland/wayland/-/issues/133
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.
avif files will commonly be probed as "mov,mp4,m4a,3gp,3g2,mj2" by
ffmpeg, but demux_lavf currently has some logic to skip
avformat_find_stream_info for these kinds of files. It was introduced in
6f8c953042. Presumably, the optimization
of mentioned in that commit is still valid however for avif we
specifically need to do the avformat_find_stream_info call. Without it,
several codec proprieties like width, height, etc. are unavailable. So
just check the extension type and disable the skipinfo optimization.
Explicitly send an UP event after the client finishes a resize for
touch event, don't resize if locked_size is set for touch event,
and use the correct type for resize edges.
VOCTRLs are processed in the GUI thread through the mp_dispatch mechanism.
Window dragging requests are asynchronous on x11 and wayland, so the item
is processed quickly without problem. However, currently win32 uses the
SendMessage call for this, which is synchronous. This causes the playback
to stop while the dragging request is being processed because the
dispatch queue is blocked.
Work around this by setting a flag instead if the window dragging is
requested, and immediately starts dragging after processing the dispatch
queue. This doesn't block the dispatch queue while also avoiding any
extra latency added by the Windows message queue.
5736737750 removed the check because it was
not needed to prevent fullscreen window from being dragged. However, this
causes an undesirable behavior: when using a touch screen to drag a window
on Windows 11, DWM shrinks the window content a bit with an acrylic
backdrop to indicate that the window is being dragged. This also happens
when trying to drag the window in fullscreen. Add the check to prevent
this from happening.
Currently, VO dragging logic is hardcoded into each VO, where a left mouse
button down event unconditionally begins dragging if the VO dragging test
passes. This method is extremely unflexible as the VO has no knowledge of
what is happening in the input system: while begin dragging with the second
click of a doubleclick is undesired, it cannot determine whether a click
is a double click or not because it's determined by the input system.
The better way to do it is to handle it somewhere in the downstream
consumers of the events instead, as they have more information to make
this decision. The input system is the perfect place for this as the logic
for checking doubleclick already exists. So just issue a begin-vo-dragging
command if it detects a left mouse button down which isn't also a
doubleclick in this case, and delete all hardcoded VO dragging logic
in win32, x11, and wayland.
Note that this solution hardcodes left mouse button down for now, but
because the VO dragging is now centralized, it's possible to make more
improvements, such as a deadzone mechanism to fix the conflict with
MBTN_LEFT mouse bind.
This allows begin-vo-dragging command to initialize a vo dragging request
for wayland. The last mouse button press seat and serial is used for the
request if it is not consumed by interactive resizing.
This allows begin-vo-dragging command to initialize a vo dragging request
for win32. Also set dragging to release all keys like for other platforms.
The hard-coded left mouse button down trigger is scheduled to be removed
in a later commit.
This allows begin-vo-dragging command to initialize a vo dragging request
for x11. The last mouse button press event is used for _NET_WM_MOVERESIZE.
The hard-coded left mouse button down trigger is scheduled to be removed
in a later commit.
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.
0b35b4c917 originally introduced sd_filter
to make a more general subtitle filter infrastructure. But when doing
so, it directly sets ft->event_format to ass_track->event_format in the
struct. The lifetime of ass_track and the sd_filter are not equivalent
which makes it easy to trigger undefined behavior. Notably, commit
cda8f1613f introduced assobjects_destroy
which can destroy ass_track anytime during runtime which means that the
string in ft->event_format is actually freed and should never be used.
Remedy this by simply doing a proper strdup when the filter inits with
ft as the parent so we avoid this scenario altogether. Fixex #13525.
initially we drew on a dedicated render queue to circumvent certain
bottlenecks on the main queue, like concurrent events that could lead
to late drawing.
though due to the way cocoa works we need to draw an the main queue
otherwise we get undefined behaviour that could lead to crashes.
Fixes#10276
The opt validator functions are casted to generic validator, which has
erased type for value. Calling function by pointer of different
definition is an UB.
Avoid that by generating wrapper function that does proper argument type
conversion and calls validator function. Type erased functions have
mangled type in the name.
Fixes UBSAN failures on Clang 17, which enabled fsanitize=function by
default.
Not sure why all of these single line if's were being braced. Probably
some cargo cult from years ago but might as well fix it now since it's
bothering me.
Could have been done in e32554cd57, but I
skipped it there. However, using viewporter is actually a win here.
There's been a longstanding issue in upstream wayland* exactly related
to this. I even forgot about cd7a7a1de8
which was made for this exactly problem and explains the random
spawn_cursor calls. Anyways, just not using buffer scale and instead
scaling the cursor surface via viewporter works just fine and completely
sidesteps this problem. This means we can drop the random looking
spawn_cursor calls and some additional checks.
*: https://gitlab.freedesktop.org/wayland/wayland/-/issues/194
We don't want to use this if we have fractional scaling or version 6 of
the wl_surface interface which has a preferred buffer scale event which
is superior to this. We were checking in the important place (surface
entrance events) but not technically in the output. So just move the
conditional to set_surface_scaling itself. Also through the VO_EVENT_DPI
in there for convenience.
An ass event like `{\p1\pos{1,1}}m 0 0 l -3 -7 l 11 -7 l 11 -2` ends
the drawing mode started with `\p1` due to `\pos` gets confused with
`\p`, and thus that line is wrongly considered to be visible text.
the swift obj-c bridging header is only included when cocoa-cb is
enabled. cocoa-cb is not the only swift feature anymore and disabling
cocoa-cb leads to a runtime error that specific swift classes could not
be found.
include the swift obj-c bridging header in the case swift features are
enabled.
this logic was copied from the cocoa-cb opengl backend, since it was
assumed both layers work similar. apparently they don't and a nil value
on the metal layer means use the display colour profile, while on the
opengl layer it means undefined behaviour.
this also fixes a problem with the target-colorspace-hint option, since
moltenvk needs to set this colour space itself for a proper hint. both
mechanism would compete to set the colour space.
usually the content scale updates automatically, though on init it is
possible the wrong scale is used for the initial rendering leading to a
wrongly sized surface.
properly set the initial content scale of the layer.
cocoa-cb was always pre-allocated in the Application itself because
libmpv needs to be set up before usage, an opengl context has to be set
and because it was decided mac specific code should be kept out of
libmpv.
this means that a completely working libmpv and opengl renderer was set
up even if it wasn't used. leading to unnecessary log message, resources
being used or reserved on the system that might not be used, triggering
of dedicated GPU unnecessarily and many other things.
even if not optimal, this wasn't the biggest problem since we only had
that one working vo on macOS. though now that we have a vulkan
gpu(-next) backend on macOS that was made the default, we always have
that dangling cocoa-cb instance, which is completely unnecessary.
move the cocoa-cb initialisation into libmpv preinit function and only
init cocoa-cb when we are a standalone App and cocoa-cb support is build
into.
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.
The --alpha option currently covers two related but different concepts:
whether or not to ignore the alpha component and possibly blending it
with a background. Because of the way the option currently works, it is
impossible to have a transparent window (which requires setting
--alpha=yes) while blending it with the background at the same time. To
solve this, let's rework it so it it superseded by the background
option.
--background controls what kind of background to set for the image if
possible. It can be blended with the set background color, with tiles,
or not blended at all (the last one is still broken on X11/mesa except
for GLX, *sigh*). In this new paradigm, --alpha=no has no real purpose
because you can simply set the background to color and whatever color
you want for exactly the same effect. So the option is removed. Instead,
the hint set by windowing backends (i.e. setting
ra_ctx->opts.want_alpha) can by done with the --background option.
As an aside, the colors in vo_gpu are currently bugged due to not
pre-multiplying the alpha and it seems no one ever noticed. The next
commit fixes that. vo_gpu_next support happens latter since it requires
new things from libplacebo.
Fixes#9615.
Currently this was being duplicated on init and on runtime updates
between both VOs. Since the conditions for setting this will get more
complicated in the future commits, it's better to just handle it in one
place. We could combine the vo_gpu and vo_gpu_next handling into one
single function but vo_gpu_next has an additional condition for
determining alpha that vo_gpu_does not, so we'll leave these separate
for simplicity. Also this technically fixes a memory leak where gl_opts
weren't being freed.
As it turns out OES_EGL_image is only defined for OpenGL ES.
OpenGL drivers implement this extension anyway because it used to be
the only way of importing EGLImages into GL.
An equivalent extension for OpenGL was defined with EXT_EGL_image_storage.
The only difference is the interaction with immutability, which requires
textures to be recreated since they can be bound only once.
Note: this commit can in theory cause certain systems to lose vaapi / drmprime
support. Since EXT_EGL_image_storage is 7 years old this hopefully doesn't happen.
If it does, the init checks can be relaxed to still permit OES_EGL_image.
We generally try to avoid that due to the #ifdef mess.
The equivalent format is defined in ffmpeg 4.4 while our interop code
requires a higher version, but that doesn't cause any problems.
Beef up the barebones description for the Mitchell filter and make it
consistent with the other --scale examples. In addition to this, make
some wording changes to make the language in the documentation a bit
more unified.
Before this change it was pretty obvious that multiple authors
contributed to this part of the manual (at completely different
timeframes), so the language was somewhat disjointed. The Mitchell
description was also not very helpful.
It's actually been like this for years, but wlroots doesn't keep track
of resizes a client does independent of the compositor. When using sway,
this leads to weird behavior with floating clients resizing themselves
back to the old size if you unfocus it. mpv has been working around this
for a long time, but it's really annoying to selectively ignore events
based on a weird heuristic. Since Sway finally fixed this bug, let's go
ahead and drop this crap. Note that other wlroots compositors may
possibly experience a regression if they didn't correct for this like
sway does, but it's for their own good.
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.
This uses an alpine 3.15 container, which should be one of the oldest
distros that mpv master can compile on and that uses ffmpeg 4.4. Some
functionality is missing due to library versions being too old on
alpine, e.g. wayland, mujs, and pipewire.
The alpine build is also explicitly minimal, to test builds in
conditions where many common mpv features may not be available.
All other ao options are documented there so make ALSA the same.
Also remove the (Linux only) wording since some systems (e.g. FreeBSD)
provide compatibility layer for it.
While making this larger do make audio filters react slower, it doesn't
always make softvol react slower. This is because the softvol reaction
speed is related to the ao buffer size which on many systems have an
upper limit, typically much lower than 200 ms. In this case the softvol
won't react slower. Change the wording to clarify this.
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.
This commit adds a DND_INSERT_NEXT action option for drag-and-drop,
allows for selecting it through the --drag-and-drop=insert-next option,
and adds the necessary plumbing to make that happen when something is
dragged onto the player.
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.
Currently, the softvol gain control attempts to clip floating point ao
formats within -1 and +1. However, this is "optimized out" at unity gain,
where no clipping is applied. This results in inconsistent behavior when
the source audio is already out of -1 and +1 range, where a gain of 0.99
results in clipping, but not at exactly 1.
Since a big advantage of floating point audio data is that they do not
lose information through out-of-range data because the ao sink can apply
suitable negative gain to prevent clipping before converting them to
integer formats, clipping should not be performed on these data.
Fix this by removing the existing clipping behavior. It now results in
a simple multiplication, which faciliates compiler auto-vectorization
of this operation over audio data.
unlink() was never wrapped in win32, so all usages of it were referring
the ANSI version of the function. This doesn't work properly for Windows
versions before 1903 (where the UTF-8 codepage is requested).
Fix this by adding mp_unlink() which wraps over _wunlink().
LRC subtitles can have lines with multiple timestamps, e.g.
[00:00.00][00:02.00]foo
[00:01.00]bar
Currently mpv shows only the "foo" that was decoded first, because it
compares the packet file position to check if a packet was already seen,
and it is the same for both occurrences of "foo". Fix this by also
comparing the pts.
This keeps comparing the packet position on top of the pts to not break
subtitle lines with the same timestamp, like:
1
00:00:00,000 --> 00:00:01,000
foo
2
00:00:00,000 --> 00:00:01,000
bar
where mpv shows both lines on top of each other. They are common in ASS
subtitles.
Fixes https://github.com/mpv-player/mpv/issues/13497.
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.
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.
Several related things but in a nutshell makes it more like wayland.
1. Remove unneeded --hidpi-window-scale checks. The backend should
always report the actual dpi value regardless of what this option
says.
2. Remove dpi_scale factors from UNFS_WINDOW_SIZE VOCTRLs. It makes
things more complicated and unintuitive for no reason. A window scale
of 1 should mean 1. It annoyed a few years ago in #9437, and I agree
with them (wayland was never implemented like this).
3. Change the dpi log messages to be more brief and remove the unneeded
comments about prescaling.
Previous fix only worked when the video output doesn't have vertical
black bars. This fixes the cases like fullscreen, video-zoom etc.
Fixes: https://github.com/mpv-player/mpv/pull/13528
before errors and outputs where ignored from the subscript and the main
script didn't fail nor did it output anything.
with this change the script properly outputs everything to stdout and
stderr. in the case the dylib script fails the whole script fails now.
the main function in dylib_unhell was kept since it can still be used
individually without the oscbundle script. the script had to be renamed
with an underscore to make it importable.
Currently, running AO control wakes up the WASAPI renderer thread in the
`WASAPI_THREAD_FEED` state, where `thread_feed` will be called. However,
it seems that in recent Windows versions (tested on Windows 10 build
19044.3930 and Windows 11 build 22631.3007) we can't know if it is safe
to feed more audio data in event-driven exclusive mode:
- `IAudioClient_GetCurrentPadding` always returns `bufferFrameCount`,
even if *NO* data has ever been written. This means we don't know how
much free space we have that is available for writing. This is not the
case in shared mode, where the return value correctly reflects the
size of data waiting to be processed. As a sidenote, MS did not
document the precise definition of the return value for an
event-driven, exclusive stream [1].
- `IAudioRenderClient_GetBuffer` never fails. We can call it for 10
times in a roll, each time requesting an entire buffer (the unit at
which data is exchanged in exclusive mode using event-driven
buffering; there are 2 such buffers) and get a successful return code
everytime. In shared mode, we get `AUDCLNT_E_BUFFER_TOO_LARGE` if we
request a buffer larger than that currently available.
As a result, `thread_feed` will always write `bufferFrameCount` frames
of audio in exclusive mode. There will therefore be glitches each time
`thread_control` is called due to the subsequent `thread_feed`
overwriting frames yet to be processed. Also, an irreversible error is
accumulated to `sample_count` as long as there is no AO reset, leading
to eventual, unbounded A/V desync.
As a fix to the issue, add a dedicated state for dispatch queue
processing so that `thread_feed` is only called when signaled by the OS.
The buffer checks in `thread_feed` that use `GetCurrentPadding` in
exclusive mode are kept in case there are older versions where the two
APIs behave differently.
Closes#12615.
[1] https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudioclient-getcurrentpadding
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.
The purpose of osdep/io is to provide a wrapper for POSIX I/O functions
on Windows. The last 2 functions are utility functions which don't serve
this purpose.
Move them to a separate file.
fopen() with 'x' mode is a non-portable glibc extension, is currently
unused, and should not be used in order to maintain POSIX compatibility.
Thus there is no need for the Windows wrapper mp_fopen() to support it.
When doing the dithering pass, the fragment coordinate is queried, but
doesn't take the fbo texture flipped property into account. This results
in different dithering patterns when toggling between fbo flipped and
non-flipped state. This can be reproduced with --vo=gpu --gpu-api=opengl
and easily seen with --dither-depth=1 when toggling between playing and
pausing.
Fix this by flipping the fragment y coordinate if the fbo is flipped
when calculating dithering coordinate.
When redrawing cached frames while the fbo texture is flipped,
the texture after drawing to screen pass will be flipped when blitting.
However, when rendering the checkerboard, the fragment coordinate
doesn't take this into account, so the coordinate before flipping is used,
resulting in different checkerboard location when toggling between
flipped and non-flipped state. This can be reproduced with --vo=gpu
and --gpu-api=opengl: the checkerboard patterns when playing and
pausing are different (vertically flipped).
Fix this by flipping the fragment y coordinate if the fbo is flipped
when calculating checkerboard coordinate.
Begin the _NET_WM_MOVERESIZE window dragging in ButtonPress event
to match the behavior of win32 and wayland, simplify logic by dropping
the win_drag_button1_down hack required by the old method, and fix a race
condition described in commit 19f101db68,
which happens when moving the mouse and releasing the button at the same time.
The race condition can be easily triggered when using a touch screen
(tested with libinput driver), where a tap is translated to MotionNotify,
ButtonPress, MotionNotify, and ButtonRelease in sequence, with the last 2
events having the same timestamp. This has caused some window managers to
not stop dragging after the ButtonRelease, resulting in window being stuck
in dragging state after a single tap.
There are good reasons to bind Ctrl+WHEEL_UP/WHEEL_DOWN to video-zoom:
- They are ubiquitous and familiar key bindings to represent zooming
operations, which are used in all popular web browsers, document viewers,
and document editors.
- Because WHEEL_UP/WHEEL_DOWN are scaled with high-resolution scrolling
input devices like touchpads, this allows smooth zooming.
- This makes "pinch to zoom" with touchpads and touchscreens work out of
box on Windows, since by default applications receive these key inputs
for pinch gesture.
- It had been considered to bind these keys to window-scale instead.
However, this results in horrible UX as the keybinds work only when the
mouse pointer is over the mpv window, and if the window shrinks during
this operation, the window below mpv now receives these keybinds,
resulting in unwanted zooming for that window, which violates the principle
of least surprise.
this partially reverts commit 7b5a258. back then the only properly
working vo on macOS was cocoa-cb (libmpv). it would always use the
deprecated opengl cocoa backend or no vo at all. because of that libmpv
was moved to the top of the auto-probing order, so the preferred vo
was used on macOS only.
we now have a working vulkan gpu/gpu-next backend on macOS which should
be the new default vo. though disabling the auto-probing again for
libmpv would probably cause the undesired behaviour on macOS that
cocoa-cb would never be auto selected again. especially if not build
with vulkan support or without vulkan driver on macOS, this would lead
to no video output at all. so instead of completely reverting the
mentioned commit, we instead move libmpv to the bottom of the
auto-probing order but only auto select it when mpv was built with
cocoa-cb support. this restores the previous behaviour on all other
platforms besides macOS, but also lets us auto select cocoa-cb if
supported.
this fixes a crash on quit, when a CATransaction from a system owned
thread/event is happening at the same time. locking the context
synchronises these access and prevents the race condition.
the draw operation induced by any display call from the CAOpenGLLayer
doesn't need that lock, since the display function already does lock
that current context.
Fixes#11681
Homebrew finally pulled the plug on lua 5.1*, and it is no more. So we
have to change to a different lua package and the only other choice is
luajit (no 5.2 in homebrew). We used to use luajit for the ci, but
649556b2b6 switched it to lua 5.1. As
explained there, luajit 2.0 was horribly bugged and not usuable for mpv
and the build had to do dumb hacks to work around it. I expected 5.1 to
last a bit longer than a couple of years, but luckily it seems like
luajit in homebrew now pulls a luajit 2.1 version (some rolling release
thing or however upstream works). The details don't really matter for
us since 2.1 does not have all the awful issues that 2.0 used to have.
So just switch to luajit again.
*: https://github.com/Homebrew/homebrew-core/commit/57d73df3ba924c870f4b6d36080e7cb37275367e
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.
It's only necessary to check the existance of cursor_shape_manager.
Also drop the pointer check to handle multi-seat since a removed seat
sets the cursor_seat to NULL.
For VOCTRL_SET_CURSOR_VISIBILITY, set cursors visibility for all seats.
The return is VO_NOTAVAIL is none of the seats have cursor, and
VO_FALSE if setting visibility failed for at least one seat.
The cursor_shape_device is per pointer, which is per seat. Handle it
together with other seat objects. This in turn also handles cursor
visibility per seat.
On a multi-seat setup, wl_registry_global advertises wl_seat multiple times,
one for each seat. if wl->seat is already set, the previous value will be
overwritten, preventing it from being freed.
Additionally, if the latter seat doesn't have the capabilities of the
former seat, the keyboard/pointer/touch input devices will be destroyed
because the current wl_seat_capabilities doesn't distinguish between
different seats. This casues keyboard/pointer/touch not working if the
latter seat has no such capabilities.
Fix this by implementing multi-seat support.
This allows receiving inputs from all devices on all seats.
All seat-specific objects (wl_keyboard/pointer/touch, wl_data_device)
are grouped with their respective seats so they can be managed together.
Note that currently inputs from all seats are interleaved with each other
and modify the same global input states.
If libplacebo manages to create a vulkan swapchain that allows
alpha composition mode to be controlled by the DWM API,
this makes it runtime changeable.
Specify cAlphaBits in PIXELFORMATDESCRIPTOR makes the pixel format
transparent, as is already the case for d3d11. Also makes the
window transparent when --alpha=yes is used.
Works on --vo=gpu and --vo=gpu-next.
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.
On wayland, depending on the wl_output protocol version used,
the display-names property can have different values. Mention
this in the documentation, like for other platforms.
Previously, libplacebo would fail to render the image since mpv was
feeding it bogus bitmaps with 0 width/height. An easy way to encounter
this would be to set sub-scale to 0 with bitmap/image subs.
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.
This adds --input-preprocess-wheel option, which can be used to control
whether to preprocess received wheel events.
Commit 937128697f added preprocessing of
wheel events to prevent the accidental scrolling of another direction
when one direction is being scrolled for touchpads, which is problematic
with the default wheel bindings where unrelated functions (seeking and
volume) are used for the 2 directions.
However, this behavior is undesirable in the following situations:
- When custom wheel bindings are used so that the 2 directions are used
for closely related actions, such as panning. With preprocessing,
diagonal movement is impossible.
- Since the wheel deadzone was introduced to prevent accidental scrolling
for touchpads, this filtering provides no benefit for high resolution
unidirectional mouse wheels, while causing a regression where scrolling at
least 0.125 units is required to trigger the event, causing input delay.
By adding this option, these two use cases are addressed.
The current documentation lacks clarity regarding the interaction
between the `repeatable` and `complex` options. Through an analysis
of the source code (`player/lua/defaults.lua` and
`player/js/defaults.js`), it was observed that the `repeatable` option
is only meaningful when the `complex` option is not enabled.
Additionally, the `complex` option in the existing documentation is
confusing, actually `fn` can be called on key repeat when `complex` is
`true` and `repeatable` is not `true`.
To address these issues, the documentation for the `repeatable` option
was updated to specify that it only applies when the `complex` option is
not set to `true`. Furthermore, the description of the `complex` and
`event` were revised to acknowledge the occurrence of key repeat events.
It is possible to have data with empty block that contains additions. In
which case the block would not be added and the additions would leak.
Found by fuzzing.
This is technically due to the previous commits that made subtitle
rendering more efficient by eliminating redraws, but working around this
particular edge case is useless. The sub-clear-on-seek option was
originally introduced in d5940fabcd and
specifically is a workaround for completely broken mkv files. There is
no reason to use it otherwise. Because that option disables all
duplicate checking and the previous commits rework subtitle rendering in
the still image case to be dependent on keeping track of packets, the
end result is that you will get the same line rendered multiple times.
However the important case of broken mkv files with duplicate ReadOrder
fields still work just fine with --no-video. So instead of bothering
trying to make this option "work", just clarify that stuff can break
since, again, there's no reason to use it other than as a workaround for
broken files.
The previous commits optimized sub redrawing on still images/terminal so
mpv wouldn't redraw so much. There is a gap though. It only assumes
static subtitles. Since ASS can be animated, those types of subtitles
will always need redraws so we need to build in specific detection for
this. We need to build a whitelist of events in ASS that are considered
animations and then flag the packet. Additionally, there's a bunch of
annoying bookkeeping that has to be done since packets can be dropped on
seeks and so on.
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.
Previously, mpv only saved a strict limit of two packets while decoding
subtitles, but it is a bit incomplete. Firstly, it's certainly possible
for there to be more than two subtitles visible at once. And also, it
did not take into account preloading. Rework this mechanism so that it
is a growable array that can store as many packets as we want. Note that
in this commit, the packets are only ever discarded on reset or destroy,
so in theory it could grow forever. Some discarding logic will be added
in the next commit since it is inherently tied to other things.
This avoids clearing the queued frame and the currently displayed one on
VO reconfiguration requests that happen when new frames arrive. Instead,
let those frames be fully displayed.
Fixes mf:// playback issues introduced after commit ef11d31.
Instead of removing the frame timing check embrace and fix it to wake up
the playloop as needed. The frame display duration is problematic to
handle as both VO and playloop thread would already be sleeping, but in
certain use cases it is needed to display frames in full, so in this
case, let the VO sleep to the end of frame, wake up the core as
requested and go back sleeping.
Note that this patch series reintroduces 0c9ac5835, which is esenitally
fixed in this commit. It is still not perfect, but it is better than
just busy waiting on playloop, even if those events when this would be
needed are quite rare.
the observer is registered on every call of the start function. this
could lead to several registered observers for the same event and
several calls to the make current function, even though we only need it
once per event.
properly remove the observer on stop, so we only ever have one observer
registered.
* 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>
With 1.3.277 the AV1 decode headers have been upstreamed.
These get preferred over ffmpeg's internal non-standard header
for this extension (same name). FFmpeg currently only builds
using its own header and a patch to work with upstream ones
is in review.
For now pin vulkan at the version before that to unbreak our CI.
This will prevent building demos and link statically with libplacebo by
default if system libplacebo is not found or isn't new enough and a
sufficiently new enough libplacebo exists in `subprojects/libplacebo`.
Since 1f8013ff3f, if you release a modifier before a regular key on
Wayland, that key gets immediately pressed again because
keyboard_handle_modifiers() calls mp_input_put_key() regardless of
whether a modifier is pressed or released, e.g. if you press Ctrl+s it
easy to take an another screenshot with s by accident. Fix this by
releasing keys when releasing modifiers.
Ideally, releasing the modifier should input the key alone after
--input-ar-delay, while this patch disables it forever, e.g. on X11 if
you type something in the console, hold Ctrl+h, and release Ctrl, it
starts typing h instead of deleting characters. This doesn't work
because keyboard_handle_key() is only called when you first press a key,
while on X11 KeyPress keeps getting sent as you hold down the key. But
this difference in behavior between X11 and Wayland can also be
reproduced with GTK and Qt applications, so I guess this is acceptable.
When the mpv surface leaves the output, we no longer mark it as the
current output. However, this implicitly depends on there being a
preceding surface entrance event to a different output. This is not
necessarily the case. Consider moving the window from monitor 1, to
monitor 1-2, and then back to 1 again. mpv gets the entrance event to
monitor 2 and sets that as the current output to work off of. Then when
you move back to only monitor 1, it removes monitor 2 from the current
output. However, monitor 1 is not updated again as the current output
because there is not a new surface entrance event in this case (the
window never left). So the numbers that mpv's core is using are
incorrect and for the wrong monitor. Luckily, we already keep track of
what outputs the mpv surface is currently on no matter how many there
are so it is simply a matter of setting current output again in the
leave event if we have a different output that has the mpv surface.
Ref: https://github.com/swaywm/sway/issues/7932
Before 3250f6e447, secondary subtitles
didn't work properly with sd_lavc at all. They would render but be in
the same position as the primary subtitles. sd_ass used SD_CTRL_SET_TOP
to specifically place secondary subtitles in a different spot, but it
was unused by sd_lavc. With that above mentioned commit, it became
possible to distinguish between the position of primary and secondary
subtitles via mpv's option system. sd_lavc was missed however because at
the time we simply didn't realize this could work and was actually
simple. With some subsequent refactoring that happened later, the fix is
to just use the correct sd->order when accessing the shared subtitle
options instead of hard coding 0. Fixes#13440.
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 mp_output_chain_update_filters() fails, talloc_free() is called on
each mp_user_filter. But because the structure doesn't have a talloc
destructor, the args aren't freed, resulting in stale references.
Fix this by calling the destructor of the wrapped filter instead.
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.
This reverts commit be0a979a0b.
The list of images codecs is no longer used by demux_mkv.c because
26a51464b6 made it check the number of blocks instead to not misdetect
animations in image codecs, so move it back to demux_mf.c since it is
its only user, so it is easier to understand how it is used, keeping the
jxl addition from e9d0a31dfe.
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.
As mentioned in [0] the suffix "_locked" would have been the appropriate
naming in line with similar uses inside mpv.
See `mp_abort_recheck_locked()`, `mp_abort_trigger_locked()`,
`retrigger_locked()`, `wakeup_locked()`...
[0] https://github.com/mpv-player/mpv/pull/12811#discussion_r1477518525
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.
df764bc0c3 and
c82c55b4b9 blindly converted the units for
this VO since neither of us actually have the hardware/setup to test the
VO. Well it was not actually correct (maybe just one was wrong or both
who knows) since vo_vdpau using timing very differently than all the
other VOs and no one reported on it until just now. Anyways, just apply
this random patch from @DanOscarsson which apparently works for him and
call it a day. Fixes#13397.
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.
Since the scroll event handler is moved to wl_pointer_frame, version 5 of
wl_seat is required. Warn that scrolling is broken if the compositor
doesn't support that verison.
Commit f54ad8eb05 broke high resolution
scrolling because one logical mouse click is generated for every scroll
event, no matter the magnitude. This makes scrolling on trackpad way
too fast.
Revert the axis scaling change in that commit and clamp the resulting
value between -1 and 1 to make sure mouse wheel scrolling works as
intended on compositors which send a value larger than 10 for these events.
Some X11 window managers support controlling the title bar independently
from other window decorations with _MOTIF_WM_HINTS. This allows hiding
the title bar while keeping other decorations like the resizing borders.
Let mpv respect the --title-bar option on X11 so --no-title-bar can hide
the title bar only like on win32.
4709a94aec along with some related commits
added a way to detect image codecs embedded into mkv streams that
weren't tagged with attached picture (arguably a broken file anyways,
but maybe not the worst thing to workaround). Unfortunately, this has
some false positives particularly with mjpeg playback. So, as usual,
revert and rewrite. Instead, we can probe the file and count blocks in
the stream. If the video stream has only 1 block and 1 timecode, then
assume it's a still image.
Save the cache to separate files to avoid loading/saving a huge combined
libplacebo.cache. This approach allows the saving of only new cache
objects and avoids resaving the entire cache, especially even if only a
tiny change was made.
This commit improves the cold start time of mpv and avoids saving data
when it's not necessary.
Number of changes were made:
- each cached object is saved in its own file
- cache files are prefixed with the name of cached object
- cache directory is cleaned on each uninit
- the least recently used cache files are removed if cumulative cache
size is above limit
- files used in the recent 24 hours are not removed to allow changes
to mpv.conf without worrying about the cache being removed during
experimentation
- shader cache size limit is set to 128 MiB
- icc cache size limit is set to 1.5 GiB
- cache objects are loaded/saved as needed
This commit eliminates the runtime performance penalty associated with
the size cache. While we continue to maintain the cache limit to prevent
retaining stale objects, mpv now only loads a small subset of files that
are currently required for playback, instead of loading all files.
Using the 'terminal-default' log level a client can request
to get all messages that would normally appear on the terminal.
8c2d73f112 changed the size of the
relevant buffer to 100 lines, which was prone to quickly overflowing
once you enable verbose or debug output.
This size is kept for the early terminal buffer but now enlarged
once a client actually requests this log level. This fixes the overflow
risk while not consuming more resources if this feature is unused.
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.
Previously, all scaling was forced to 1 with this vo and all coordinates
were calculated as if the scale was 1. This works since viewport relies
on the compositor completely for scaling so it doesn't really matter if
we don't draw directly to the correct size since the compositor will
just scale the rest for us. This does have some downsides however since
the OSD text might not be drawn at the actual resolution of the final
size of the video.
We can instead handle this by getting rid of the dmabuf_wayland specific
scaling logic and using the same values as everything else. In the
resize in vo_dmabuf_wayland, we just need to adjust the viewport
destination calls so they go to the wayland local coordinates and not
the physical ones. This should ensure that vo_dmabuf_wayland directly
goes to the desired size and the compositor doesn't need to operate on
it after the fact.
If the scaling value changed for some reason, the window geometry would
be recalculated with the new scaling even if this option was disabled.
Properly ignore it.
The core wayland protocol way of handling scaling is to use the
buffer_scale mechanism. But this sucks in several ways for reasons I
won't list here and fractional scaling rightly avoids this altogether
and uses a buffer_scale of 1 (i.e. not setting it) along with
viewporter. When originally implemented, this was only specifically used
when the fractional scale protocol was available, but we actually can
use it as a full replacement instead. This means that mpv now hard
requires viewporter, but this protocol is supported by everyone and is
one of the few that is actually stable.
How it works is the same regardless of fractional scaling or not. When
the compositor has a scale value not equal to 1, it will always scale
the client by that factor (unless you set buffer_scale). What we do here
is pass a viewporter size that exactly undos the compositor-side scale
(sans a possible rounding error). So what we are left with is just the
exactly physical pixels we want to display. Fixes#13316.
7b8a30fc81 made it possible for a VO to
have direct ownership of frame objects since the it may be beneficial
for the frame to follow the lifecycle of that particular VO instead
(i.e. the wayland compositor for dmabuf-wayland). But when frames are
dropped, this always has to be unconditionally freed since the VO isn't
aware of it. Fixes#13364.
It is expected. Last argument of validate functions is always a pointer,
but not always void* which triggers UBSAN warning.
meson since 1.3.1 halts on UBSAN errors in tests, which is good thing.
Fix DTS passthrough playback of 44.1 khz content. Also, take into account that there are some DTS variants with a samplerate of 96khz (e.g. DTS 24/96), somehow they are recognized wrongly as 48khz by the code. Don´t rely on this "bug", do it correctly. Now every samplerate above 44.1Khz is correctly treated as 48khz, and 44.1khz files are treated as 44.1khz for bitstreaming.
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
This reverts commit cb2b579f61.
This breaks files where the audio starts much later after the video
since mpv reads the first audio packet even if it isn't supposed to
start yet, resulting in the audio_status being STATUS_READY for the
entire time mpv is "waiting" for the first audio packet to be played.
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 prevents mp_msg_flush_status_line() from printing an unnecessary
newline when changing file after setting --really-quiet at runtime. If
mpv is backgrounded, this newline garbles the output of TUI programs.
With this change the cursor is not re-enabled after setting
--really-quiet at runtime and quitting with mpv in the foreground, so
enable it on uninit.
If a track's language was guessed from its filename, the commands that
reload the track, like sub-reload, remove it. Fix this by calling
guess_lang_from_filename() again.
Note that backing up t->lang and restoring it if nt->lang is NULL would
work incorrectly when lang is in the stream and it is removed before
reloading.
This displays the current GPU context when --vo=gpu or --vo=gpu-next
is used, which shows the platform and backend information of the vo
which are previously not available.
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.
The lingering cache needs to be cleared so the packets don't stay
forever on the screen past their welcome. Do this by simply refreshing
the stream. Fixes#13148.
mp.observe_property('foo', nil, ...) calls the handler at least 2 times
on each playlist change even when the property doesn't change. This is
dangerous because if you haven't read observe_property's documentation
in a long time this is easy to forget, and you can end up using it for
handlers that are computationally expensive or that cause unintended
side effects.
Therefore, this commit discourages its use more explicitly in the
documentation, and replaces its usages in scripts.
For console.lua, observing focused with type nil leads to calling
mp.osd_message('') when changing file while playing in the terminal with
the console disabled. I don't notice issues from this, but it's safer to
avoid it.
For playlist and track-list this doesn't really matter since they
trigger multiple changes on each new file anyway, but changing it can
avoid encouraging people to imitate the code.
One usage of none in stats.lua is kept because according to b9084dfd47
it is a hack to replicate the deprecated tick event.
When the mouse cursor is hovering over the (CSD) windowcontrols title,
the osc keeps displaying, but the cursor autohide isn't disabled like
other visible regions.
Fix this by disabling the cursor autohide in this region.
All other existing behaviors of the mouse cursor in this region
are unchanged, including triggering main window area input
and allowing VO dragging.
Quickly going through a directory with too many loadable files causes the
autoload tasks to pile up and exiting the player will take forever. Avoid
this by skipping loading when playback is aborted.
This adds volume-gain, volume-gain-max, volume-gain-min options, which
can be used to control audio volume and target dynamic range in decibels.
The gain is applied on top of the existing volume setting.
f9cefbfec4 made it so mp_ass_flush_old_events() is continously called on
subtitles with unknown duration, without explaining why, breaking
sub-seek/step -1 with a VO (the issue does not occur when showing
subtitles in the terminal because get_bitmaps() is not called). I don't
experience any issue after removing the call, so delete it to fix these
commands.
After removing that, you can sub-seek -1 once after regular playback,
but not after seeking and thus not multiple times in a row. This is
caused by a714f8e928 which fixed subtitles with unknown duration being
duplicated when seeking with a VO (it does not happen in the terminal)
by clearing old lines on seeks, which broke sub-seek -1 and sub-step -1
in a second way after any seek. The proper fix is to remove the line
ctx->num_seen_packets = 0 for subtitles with unknown duration instead,
which lets decode() return early when a line has already been shown.
Having removed these 2 lines, I also removed sd->preload_ok = false, and
thus the whole conditional, since according to sub/sd.h preload_ok only
needs to be set to false when old subtitles are discarded, and they are
no longer discarded,
The bug can be reproduced with
mpv --sub-file=<(curl 'https://music.xianqiao.wang/neteaseapiv2/lyric?id=1399616170' | jq -r .lrc.lyric) 'https://www.youtube.com/watch?v=dQw4w9WgXcQ'
Negative values are nonsense to mpv, and can cause protocol error afterwards,
like xdg_surface::set_window_geometry which doesn't accept negative values.
Treat any negative values as zero (client determines size) for now.
Needed in case the timer solution fails. Note that this will leave the
mode indicator in the language bar showing the original mode until
a key is pressed.
The IME is useful for text input. Additionally, Alt+Shift input language
switching doesn't work when IME is disabled even when the languages don't
require IME.
Re-add the VK_PROCESSKEY logic to ensure that IME is handled properly.
Reverts bf6b981367.
strlen is only relevant if the length is less than [1, 4], so this can
be replaced with strnlen instead which will only traverse characters
upto the maxlen insted of the entire string length. It also makes MPMIN
unneeded. Also fix a comment.
commit fa9e1f06f tried to move signal unsafe operations out of
signal handlers but mistakenly introduced a race. before,
sigtstop would process the following in order:
0. do_deactivate_getch2();
1. raise(SIGTSTP)
that commit moved 0 out of the signal handler (due to it being
unsafe) but kept 1 in there. this may mess up the ordering of
these operations. this commit moves everything out of the
handler so that things happen in proper order.
since things are now moved out of the handler, SA_RESETHAND is
no longer being applied to SIGTSTP. since that can result in
races if multiple signals are delivered faster than we can
respond to them.
When running the console in the terminal, style log lines with the same
escape sequences as msg.c.
mp.input can also specify terminal escape sequences, e.g. a script to
select a playlist entry can invert the color of the selection.
Also add a missing newline to help's error message.
This can cause mpv to abruptly quit without following the proper uninit
process when a second `SIGTERM` or `SIGQUIT` is sent and mpv
didn't quit on the first one already. This is because the default action
for these signals is to terminate the program immediately, similar to
`SIGKILL`, and `SA_RESETHAND` resets the `quit_request_sighandler` to
`SIG_DFL` for the default action.
Also keep the `SA_RESETHAND` flag for SIGINT because the current
behavior is to quit after receiving two Ctrl+C no matter what, this is
probably convenient and worth keeping.
This change is because some tools (e.g. GNU timeout) send SIGTERM twice
after the timeout period.
An easy way to reproduce is with `timeout 1 mpv [...]` where mpv would
quit abruptly anywhere from half the time to once every 50 attempts
depending on your luck.
According to the xkbcommon docs, `xkb_state_mod_index_is_consumed` is
true when a modifier *may affect* key translation. A key modifier may
be consumed but not be active. See xkb documentation for this function
for further details. This breaks key modifiers in cases where
L_Shift+R_Shift for example is used to change keyboard layout with
`xkb_options grp:shifts_toggle`. Instead, replace it with a simple
check for a valid modifier.
This doesn't actually work on either Windows or Linux with --terminal.
With --no-terminal or --no-input-terminal the SIGTERM handler is never
registered, so it definitely can't work.
Just remove the note about signals because it would be complicated to
explain that they don't terminate abruptly only with --terminal and only
if that signal has a handler, and it wouldn't be of interest to most
users.
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.
The +1 here is not correct. For a 4-byte unicode character, this would
throw a runtime error because the +1 would try to assign the null
terminator past the actual bound of our array. Just remove it since it
should be exactly equal to whatever we have for bytes.
There's a simple check in filter_sdh that gets the bytes of the first
character in a string in order to do pointer arthimetic to filter the
string. The problem is that it is possible for the amount of bytes to be
greater than the actual length of the string for certain unicode
characters. This can't be worked with so enforce the strlen as the
absolute minimum here to avoid overflow situations.
Fixes#13237.
Stopping output implies that it can't be paused anymore.
This is consistent with the documented API in internal.h as well
as the behavior of other AOs.
resolves#13267
Remove this "hack" from 2017 which disabled `advanced_editlist` while
demuxing mov/mp4. See: b7b12c36af as well
as b86a2316df
At present, advanced edit list support seems to be mature enough that it
doesn't need to be disabled by us and disabling it seems to break more
files based on testing with `elist` files in FFmpeg's FATE suite.
Xft.dpi is much more widely used nowadays by GUI programs compared to
the X11 screen DPI.
This is the best we can get for a vendor-neutral scaling preference
value under X11 in terms of adoption.
If Xft.dpi isn't available, the X11 screen DPI is used as a fallback.
~144 DPI displays are pretty common and neither 1x nor 2x scales are
the right size for it. Allow DPI scale in unit of 0.5 to fix this.
Additionally, add a note about the current behavior of the API used
to get the scale factor.
In theory bstr_split_utf8 should skip invalid sequence and move further,
but it doesn't do that currently, so just the string if unsuported code if
found.
Fixes infinite loop on code.len == 0 condition.
Fixes: 5864b72d1a
Currently, libplacebo always tries to reconfigure the d3d11 swapchain
to a 10-bit output format because disable_10bit_sdr isn't set to true,
even when an 8-bit format is explicitly requested via
--d3d11-output-format.
Fix this by passing the requested output format preference to libplacebo.
Document that this option may be ignored.
0.37.0 uses more computationally expensive shaders by default,
which can cause high GPU usage and frame drops even for modern
integrated GPUs, especially with 4K and high fps contents.
Recommend --profile=fast for them.
--ao=pipewire has been preferred on Linux for a long time, and this note
even makes it sound like alsa is preferred on any system. Just say that
the print order is the order in which the drivers are tried so this note
won't have to be updated again in the future, like --gpu-context's
documentation does.
This is commonly done to understand whether a window is focused. This
explicitly checks if focused is false instead of unavailable to not
break the cursor where focused is unimplemented like on --vo=drm.
The cursor is taller than the input text so it is made transparent
instead of completely removing it so that the log doesn't move up and
down while toggling focus. Alternatively, cheight = opts.font_size * 8
can be changed to 7.
43ed0a83d0 avoided reinserting the string that is appended after certain
completions when it is already after the cursor when inserting the
longest common prefix of the suggestions. Do the same when cycling
through them.
This section has no reason to exist anymore because:
- No "desktop issues" sections exist for other platforms, and all other
Linux-specific issues are represented as notes for options. This section
only addressed one specific issue.
- This section was shortened significantly with commit
2c46ae8ea3, so there is no need for
this to be a separate section anymore.
- This section was shortened again with commit
d5e681e95df759a4df8608cc773931e3f97c9460, when the original rationale
behind this section became outdated because GNOME has implemented the
idle inhibit protocol.
The historical info is moved to the documentation of --stop-screensaver.
Some places in the manpage uses `.. admonition:: Warning` instead of
the specific directive type `.. warning::` for warning admonitions.
This causes the "Warning" text appearing in black color instead of red.
Correct them here.
This allows taking more than 99999 screenshots in a single session,
and also for the case when a sequence of 99999 screenshots
already exists on the filesystem.
In commit c09245cdf2
long-path support was enabled for mpv without actually
making sure that there was no code left that used the
old limit (260 Unicode chars) for buffer sizes.
This commit fixes all but one case.
Reuse common_prefix_length() to make find_common_prefix() shorter and
faster by not creating many temporary strings.
The decrease in the average time to run find_common_prefix() over 1000
calls I measured is:
set \<Tab>: 1e-4s -> 1e-5s
set s\Tab>: 1e-5s -> 5e-6s
- --image-display-duration does not hide the OSC.
- Saying "Setting --image-display-duration" makes no sense because it is
not a boolean and it cannot be unset.
When hovering certain elements over the OSC, using the mouse wheel can
result in special commands (such as seeking, changing audio tracks,
etc.) Not everyone neccessarily wants this feature, so add an option to
make it possible to disable all of it. Maybe more fine-tuned control
would be more ideal, but probably not worth it. Fixes#13096.
24270b8587 disabled the cursor while mpv is running, but if you send mpv
to the background, it is not re-enabled until you run bg, and not even
after that if mpv is paused. Fix this by enabling the cursor from the
SIGTSTP handler.
Even for successful calls, utils.format_json returns nil as the second
return value. This doesn't have any purpose and is not documented, and
it is inconvenient for passing JSON to script-message, because
mp.commandv('script-message', 'foo', utils.format_json(...))
errors because mp.commandv receives nil as the fourth argument.
This commit makes format_json return only one value in case of success
to fix this.
Missed in 3250f6e447. Note that the
hardcoded ass alignment value is not used anymore as of that commit, but
we should ideally be moving towards secondary subs actually being
customizable via ASS anyways.
Over the years, we've accumulated several secondary subtitle related
options and properties, but the implementation was not really consistent
and it wasn't clear what the right process for adding more should be. So
to make things nicer, let's refactor all of the subtitle options with
secondary variants (sub-delay, sub-pos, and sub-visibility) and split
them off to a new, separate struct. All of the underlying values are
stored in an array instead for simplicity. Additionally, the
implementation of some secondary-sub-* properties were slightly changed
so there would be less redundancy.
f1c4d20e65 added this option, but the
documentation is actually backwards. --replaygain-clip allows clipping.
Having it disabled, the default, prevents it. Keep the behavior the
same, but change the documentation to reflect reality. Closes#13111.
Fixes crashes in case of unknown subtitle track being found, as
the original ARIB caption logic added in 0da0acdae8
did not attempt to take into mention tracks with unknown type.
Fixes#13106
As a result of the work I did the explicitly check for formats
supported by the vo in the f_autoconvert logic, I introduced a
regression in the handling of the rpi4_8 and rpi4_10 formats. These
require special handling because they only exist in the rpi forks and
not upstream ffmpeg, which means they don't have stable pix fmt values
that we can use directly.
Previously, we simply didn't declare them as supported, which was ok,
as nothing was really enforcing the list of supported formats, but that
has changed.
As we still can't simply use the pix fmts, I had to do a slightly
ridiculous dance to look them up by name, and if they exist, then
register them as supported.
Good times.
It's conceptually broken for an hw format to be identified as a
supported sw format for an hwdec, but in the case of the drm hwdec,
we have no choice but to do so for the weird rpi formats, as these
are declared, incorrectly, as hw formats in their forked ffmpegs.
This means we can't reject such formats as a matter of principle,
as we do today. Instead let's just assume that such formats can always
be accepted as-is, and will never require conversion. In practice, this
is either true or it will fail in the VO, which is the old behaviour
from before I introduced the conversion filter capability.
Clear completion suggestions from functions that move the cursor, so
that you can't insert suggestions at the wrong spot by pressing Tab
again after moving the cursor,
Also clear suggestions from some editing functions that were never
updated. It is not actually necessary to clear suggestions from
functions that remove text in front of the cursor, but since
handle_del() already clears them, let's just clear them everywhere.
This is useful for completing files and more rarely for profiles. It
will also be useful to third-party scripts interacting with the console
once the API to do it is merged.
Add .jxl as a file extension that maps to an image codec. Note that
this will include animated JXL files, but .gif is also on that list so
they are not different in that regard.
I honestly don’t care either way but I also don’t believe this innocent
and cute hat is worth repeatedly having people show up on the issue
tracker to aggressively virtue signal and then shit-talk the project
elsewhere when their “concerns” are ignored and made fun of.
For the record, I approve of neither brand of childish nonsense.
If your workflow depends on December festivities, feel free to use an
alternative OSC implementation.
Fixes#13082 and #9548
When using the --playlist option on the commandline, it would mark all
entries on the command as having the playlist-path of the value of that
passed option, not just the ones that were expanded from it. Fix this by
moving the playlist_populate_playlist_path to the same place where the
playlist file gets expanded.
Ref https://github.com/mpv-player/mpv/issues/13075#issuecomment-1852179164
https://0x0.st/ has a maximum retention period of 1 year, and much less
for larger files. Uploading them directly to github issue avoids this,
which most people are already doing anyway because of greater convenience.
log file: don't request 0x0.st.
sample files: recommend github first.
Add more and unify requested information:
windows, linux, others: request GPU model to provide more info about
known hardware limitations and hardware/driver combo bugs.
windows, others: request general GPU info.
build: request meson version.
windows, linux, others: request backtrace in case of crash.
all: clarify the language of not attaching a log file.
When updating subtitles while paused, mpv waits until a packet is
available. However in the case of a network stream, it is possible that
mpv will pause itself when buffering for cache reasons. This makes that
particular loop do a busy loop and can take a long time depending on
network streams. Simply just don't do the loop here if we are paused for
cache reasons. Fixes#13077.
The dragging hack can cause unwanted aero shake activation.
Prevent this by saving the window arrangement state before dragging,
temporarily disable it while dragging hack is active, and restore to
the original state after dragging ends.
The mouse down handler checks w32->current_fs to determine whether
to begin the dragging hack. Unfortunately, the w32->current_fs value
is stale, because the input is handled asynchronously, and we cannot
wait for an up-to-date value if dragging needs to be kept resonsive.
As a result, when the fullscreen state changes after the dragging
model loop is entered, the opposite value is used, so the window stays
draggable after entering fullscreen, and becomes undraggable after
exiting fullscreen.
With the resonsiveness and model loop constraints, the up-to-date
state must be queried inside WM_MOVING messages which are sent while
dragging. The message handler now checks if the dragging hack is active
while the window is in fullscreen, and overrides the new window position
with the current one, in effect prevents the window from being moved.
The old check is also removed, so the window is now draggable after
exiting fullscreen while dragging hack is active.
Compose key doesn't function in X11 because XFilterEvent() isn't called,
and XNInputStyle is set to a wrong value. This results in KeyPress events
for the separate keyboard inputs in the compose key input sequence
instead of the composed character, making it impossible to input certain
characters which require compose key.
Fix this by calling the required XFilterEvent() and set XNInputStyle
to the correct value.
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.
These two functions are almost exactly the same. The parenthesis variant
is essentially just a special case with more conditions to not remove
text. These can easily be combined together into one generic
skip_enclosed function to handle both cases. We also use char * instead
of char for the character comparison here since not everything is
neccesarily 1 byte and can fit into a char. This will be useful for the
following commits where we extend this logic further.
A simplified version of the text width estimation code from uosc.
An osd_overlay is created with compute_bounds=true for measuring the
width of the lower case alphabet at what's estimated to be the largest
font size possible without clipping.
The lower case alphabet was chosen to get decent results for proportional
fonts, even if they aren't officially supported.
According to MS documentation, an application should return TRUE from
WM_XBUTTONUP and WM_XBUTTONDOWN if it processes these messages.
DefWindowProc generates the WM_APPCOMMAND message when it processes the
WM_XBUTTONUP message, so if an application properly handles WM_XBUTTONUP
messages, extra WM_APPCOMMAND messages won't be generated.
Because mpv doesn't properly handle these messages,
WM_XBUTTONUP causes APPCOMMAND_BROWSER_BACKWARD to be generated, resulting
in duplicated keys and improper fix 438ead7a, which prevents the processing
of the appcommand from sources other than mouse clicks.
Fix this by following the documentation, and the back and forward
appcommands can be added.
XF86Back and XF86Forward are mostly used to navigate file and web browsers
to go back/forward in history. XF86Forward isn't recognized right now,
so add it.
Because XF86AudioForward already takes the "FORWARD" name, rename the
browse keys to GO_BACK and GO_FORWARD instead.
On practically all platforms and GUI toolkits, a triggered double click
event clears the mouse input buffer so that the next click won't
trigger another double click event. mpv doesn't do this, so a third click
results in another double click event.
Fix this by resetting the double click timer after a double click event
is triggered which achieves the same effect.
in the case the window was already set to a maximized size via geometry
or related options (100%x100%) the maximize function would try to
maximize the window again. this reset the position and slightly
increased the size further.
to prevent this only maximize on init if we really want to maximize. in
the reverse case make a noop call by passing the current zoom state.
Fixes#11193
ca2b05c0fb changed the window size with --force-window and no video
tracks to be closer to 16:9, but I don't see why we shouldn't have an
actual 16:9 ratio. The advantage is that subtitles with fullscreen and
no video tracks will have the same size and position (depending on the
values of --sub-scale-with-window and --sub-use-margins) as with 16:9
videos, because there will be no (invisible) black bars.
As it is now, the FreeBSD CI is failing because meson can't find the
dvb headers.
FreeBSD puts the relevant headers into /usr/local which is bothersome
and in fact required a workaround to be added to the Wayland detection
already (3bdf702b1d) but this should be
addressed by us adding the path to CFLAGS already.
With a more minimal example the detection works fine in my FreeBSD VM.
I'm at my wits end debugging this so just disable it for now.
This was disabled by default in 99cef59fc9 (from 2017)
due to build issues with old kernel headers.
Whatever was considered old at that time will be ancient now
and with the last commit there should be no isses auto-detecting it.
See 1b035402a6. This is only relevant if
you are using d3d11 on --vo=gpu which is windows-only. For all other
platforms, vulkan uses libplacebo which uses shaderc. mpv itself doesn't
need it in those cases.
281b1d8999 introduced a stack use after
scope because dest_fbo can be reassigned a new pointer and then be used
by pass_draw_to_screen outside of that scope where the pointer is no
longer valid. Fix this by rearranging the variables so the assignment is
done in the same scope as the pass_draw_to_screen call instead.
It's not actually related to libplacebo wrap stuff and the swift compile
command needs this to get the right libplacebo include path.
This reverts commit b9d392ecd9.
Meson was pretty strict about target ids and generating the mpv.com in
the same directory as mpv.exe wasn't possible. So as a workaround we
tucked it away in a subdirectory, but that's not really intuitive at
all. Well as of meson 1.3.0, this is now possible so leverage it since
it makes way more sense. We still keep the old workaround for anyone
using older meson versions.
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.
The info provided for libva might be useful. Specifically on Windows it
seems to not use the error callback for what should be logged as error.
[ 0.080][v][vaapi] libva: VA-API version 1.20.0
[ 0.080][v][vaapi] libva: Trying to open <path>/vaon12_drv_video.dll
[ 0.080][v][vaapi] libva: va_openDriver() returns -1
[ 0.080][e][vaapi] Failed to initialize VAAPI: unknown libva error
As we can see only the "unknown" error is printed to the error callback
and important information is printed on the info callback. Print it to
verbose log to make it easier to find.
the cocoa backend was removed and all functionality is either available
on all macOS backends or explicitly only with cocoa-cb. the manual
should properly reflect that change.
also remove the last mention of the old cocoa backend.
the title is updated on the main thread (mandatory with cocoa)
asynchronously, because otherwise it would either deadlock when done
synchronously, lead to undefined behaviour or just crashes. the problem
here is that the c string was only copied to an NSString within that
asynchronous call, which potentially would access the pointer when it
is accessed, modified or freed by another thread. it is only safe to
access this pointer as long as the control callback wasn't returned yet.
to fix this we move the copying and creation of the String from the
c string pointer outside of the asynchronous call where the conversion
of an untyped pointer to a typed pointer is done too. since the
resulting String is a copy it's safe to be used in the asynchronous
call.
also reverting ee6ad40, since the problem was most likely an SDK problem
or the very same problem as mentioned here. i retested the crash case
again und can't reproduce it anymore. using a swift String again instead
of an NSSstring.
Fixes#12935
NSApp is only an Application when initialised from mpv itself. when used
via libmpv an Application is never initialised and mpv would always
immediately exit.
make the retrieval of the vo and mac options static so they can be
retrieved in all cases.
Fixes#12518
- Don't define _GNU_SOURCE on Windows, no need
- Define WIN32_LEAN_AND_MEAN to strip some unneded headers from
windows.h
- Define NOMINMAX and _USE_MATH_DEFINES as they are common for Windows
headers
We prefer to fail fast rather than degrade in unpredictable ways.
The example in sub/ is particularly egregious because the code just
skips the work it's meant to do when an allocation fails.
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.
This mostly is added to resolve player command synchronization with VO
thread discussed in 477a0f83.
The current uses does not necessarily need this as they are all managed
by playloop. But for future use with other params that will be handy.
Those params are mostly to observe current state of VO and does not
necessarly need to be locked along with frame drawing, that changes the
params once at the end.
Only vaapi-copy variant as nothing can map D3D12 resources currently.
And even if we would add resource sharing to D3D11 it would invoke copy
at some point, so there is no point really. Maybe in the future when
libplacebo get smarter about resource sharing on Windows, but practical
advantages are really small. I've tested it with Vulkan <-> D3D11
sharing and GPU <-> GPU copy is still invoked. Better than CPU memcpy,
something for the future.
Up to 2x playback rate is the most we can offer currently. Should work
fine for most kernels with radius <= 2.
This avoids limitation of hwdecs number of frames in-flight.
Fixes: #12927
there is 1px border at the top of the window that is not covered by our
title bar and the video below is visible. this broke in some newer macOS
version even so the calculation of size and position of the title bar is
still correct. add 1px the the height of the title bar to cover up the
unwanted border.
Unclear if there are other situations but at least using --force-media-title
this can be called without a playing file, causing a segfault.
fixes: 34a04d0567
The "auto" logic is vastly better than setting a specific size. This
option amounts to "allow users to shoot themselves in the foot" flag,
given that the vast majority of ICC profiles in the wild are fine on
17x17x17 or even smaller 3DLUTs.
Setting stupidly high --3dlut-size is the main source of ICC-related
slow startup issues, and there is absolutely no conceivably benefit to
going above the defaults except for pixel peeping and chasing tiny PSNR
increments.
These are less likely to be modified from run to run, and with the
avoidance of redundant re-saving we can get away with a larger size.
This is enough to save 10 3DLUTs at typical sizes.
D3D11 is actually the main platform that suffers from slow shader
compilation, typical Vulkan/GL drivers are either very fast to begin
with, or already internally cache.
I have no idea why this code is such a convoluted mess of options and
possibilities. First of all, why is dumping both caches to a single file
even a supported use case? Why is the cache path generated multiple
times, once for saving and once for loading, instead of just generated
once and stored? Why even create a pl_cache if you're not going to
save/load it? Why so much code duplication?
I don't know. But I rewrote it in a way that makes far more sense to me.
This change prevents unwanted adjustments. Generally, screenshots
shouldn't invoke pl_queue_update, as this action could cull the already
mapped frames in the queue.
If !display_synced, some values may not be correct or zeroed. Therefore,
it makes no sense to interpolate in this case.
For a non-moving frame, we always want to show an uninterpolated frame.
libplacebo requires additional frames when VPS is lower than FPS and
anti-aliasing is enabled. Supports up to a 1/4 ratio. VO has a limit of
10 frames, so in practice, not many more can fit.
Note that the internal libplacebo mixing limit is 16 frames.
The `current_frame` can be redrawn even if the remaining `num_vsync` is
equal to 0. In this scenario, the vsync offset would be incremented
beyond the target point.
It turns out that mpv will rewrite the entire cache file on every single
quit. It's not so great since after viewing a ton of files, your cache
can grow to massive sizes and slow down quitting the player to a
noticeable amount. Turn down the max size of both caches to 10 MiB for
now as a workaround until this gets improved later.
without a developer license and the corresponding certificate we can't
sign our app bundle properly. instead use the ad-hoc pseudo identity.
there. i am not sure what restrictions we have because of that, but it's
the only way we can pseudo sign the app bundle.
Fixes#12116
Apps on Apple silicon have to be codesigned to run, but you can't
codesign bundles that have a symlink for the main executable.
The "mpv-bundle" symlink was used as the bundle's main executable
because it makes the execution name of the binary different.
Launch Services runs the CFBundleExecutable key from Info.plist when
launching a bundle, so by comparing the execution name to the name of
the symlink, you can check if that's how the binary was launched.
This replaces that detection method by moving the MPVBUNDLE
environmental variable into Info.plist. Launch Services will set
anything in LSEnvironment as environmental variables before launching
the bundle, so we're able to check for it instead of needing to
differentiate the execution name of the binary.
Fixes#12116
not all dependencies are linked with an absolute path but rather are
relatively linked via @rpath or @loader_path. in those cases we have to
resolve the paths to those dependencies ourselves and change the linking
with install_name_tool to be relative to the @executable_path of the
binary within bundle.
Fixes#11897
This filters out vastly inaccurate values from presentation feedback
that can happen shortly after restarting playback or seeking.
Makes estimated vsync converge almost instantly instead of waiting
until those outliers are dropped from the past samples.
The "Resolution" property shows the storage resolution for videos with
non-square pixels.
Currently, display aspect ratio is shown for both "Resolution" and
"Output Resolution" properties which results in a duplicate,
and is incorrect for the "Resolution" property.
The correct aspect ratio is now shown using the sar and sar-name properties.
Display aspect ratio (aspect) and pixel aspect ratio (par) are already
exported, but storage aspect ratio (sar) isn't. This value is needed to
display the storage aspect ratio for non-square pixel sources in stats.lua.
This exports two new properties: video-params/sar and video-params/sar-name.
Docmentation is updated accordingly.
In acac614032, I sort of cargoculted what
I had to do for m3u, but it's actually not needed. bstr_split_tok
unexpectedly doesn't modify the original string. So the line_dup
business in the ini parsing is not needed. Remove it. The part in
parse_ref_init isn't wrong but naming the variable "line_dup" instead of
"value" is stupid so adjust that. And finally, you can actually force a
codepage in mpv (add "+" before the codepage) which will cause every
line to be allocated memory including the header lines even though those
are obviously valid utf8 that should never need conversion. This wasn't
taken into account so add an extra pl_free_line in a couple of places to
make sure they are freed.
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.
In commit de6d57f0 libplacebo enabled drift compensation by default.
mpv already tracks error and adjust the speed by itself.
This commit fixes judder visible when slowing video a lot, ex. playing
back at 10% speed.
Set ideal vsync duration also when dropping frames, libplacebo estimate
currently own values anyway, will be useful later...
See: https://code.videolan.org/videolan/libplacebo/-/commit/de6d57f021e2336851f51b1a8538aa1484c56607
During move of this code from vo_gpu_next.c to video.c someone(TM) tried
to be smart and simplify the expression. The num_vsync includes error
compensation which can cause it to display +-1 vsync at the same rate.
We explicitly don't want to include this in "ideal" parameters.
Also num_vsyncs was already rounded so we produced off timings in
general.
Revert back to proper way of translating the time.
Fixes: 5e5a325
b56e63e2a9 removed -del for list options but it is still listed in the
list structs, which means that it is still tab completed on the CLI like
the other actions, and seems to behave like -set. Remove it so it is no
longer tab completed.
Also remove the description of -del from the help output of object
settings lists --(ao|vo|af|vf)-help, and update a comment.
The commit subject sounds reasonable except that frame redraws get
spammed in certain cases (still image with subtitles) all the time
regardless if the subtitle actually has changed or not. So this is
stupid and wasteful, but you'll always see subtitles. vo_gpu currently
has this behavior as well, so we're just matching it but later mpv's
core should be fixed so this works reasonably. Fixes#11335.
cd59ea8afab6381951a3ae19a43e422906d02164 removed an arbitrary start
offset added to the timer. However, it turns out that demux secretly
depends on this. When updating cache to actually read bytes from the
stream, there's a diff >= MP_TIME_S_TO_NS(1) check to make it only
update once every second. With the old MP_START_TIME macro, the initial
time value would always be at least 1e10, so this would also be true.
Since we don't have that offset anymore, now the initial time is less
than that so it is not updated and properties like file-size are 0. Just
be sure to always update if the last_speed_query is 0 (i.e. we just
started the player). Fixes#12869.
Fixes gpu-next completely ignoring any speed adjustment, either DS or
playback.
Frames in pl_queue have raw PTS values, so when querying them we have to
use the same time base. There was misunderstanding between mpv and
libplacebo, where the former was querying the frames based on display
vblank timeline, but this cannot work if the playback speed is adjusted
and display timeline is not aligned with video timelien. In which case
we have to schedule "video vsync" points that we want to display.
Previous code was working only when playback speed was 1.0x, but since
DS almost always changes the speed the interpolation was mostly not
timied correctly.
Relative to frame PTS timeline as oposed to display vblank.
Those values are relative to unadjusted video timeline. They will be
used by gpu-next where it expect virtual frame vsync, not display vblank
time.
Originally suggested by @haasn. Instead of awkwardly using a pts from
the previous render loop, we can just peek into pl_queue and use the pts
of the first frame instead. This eliminates a lot of weird artifacts
that can happen on discontinuities like seeking. Fixes#12355.
Several related things in regards to interpolation. Essentially this
adds more general sanity checking to bring it more in line with what
vo_gpu does.
- Add a can_interpolate bool which determines whether or not this frame
is allowed to interpolate.
- p->is_interpolated was sometimes lying and because you can have a mix
frames greater than 1 depending on the video and settings. Make sure
that vsync_offset is not 0 so we know if it's actually interpolated or
not. This prevents a redundant redraw for those edge cases when
pausing.
- When the vo wants a reset, i.e. some sort of discontinuity, don't try
to interpolate the frame. Interpolation is only valid for
monotonically increasing times.
This fixes#11519 because of the additional check to make sure that we
have more than 1 frame. The PTS clamping part is still not great. That
is for the next commit.
String formatting of Lua crashes with widths greater then 99, so limit
the value to that.
A nicer solution would be to create our own string padding function that
can handle bigger widths, but such long suggestions aren't common enough
to be worth the effort.
In the past, this worked by accident because the initial startup was
racy and sometimes the initial firing of handle_toplevel_config would
happen after reconfig. Since we now properly wait on all compositor
events we can save the initial size hint that is given to us and try to
use that as the window-size/geometry provided the --autofit/geometry
options aren't explictly set. Fixes#11134.
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
this is apparently something that was added with swift 5.5, though it is
hard to find anything officially.
don't capture self in closure but explicitly access all variables by
prepending self.
Fixes#12653
older macOS dev tools were inconsistent with the way how SDK versions
were returned, some truncated the minor versions. in those cases the
SDK version had to be retrieved through the SDK build version.
recently the scheme for the SDK build version changed that our heuristic
for converting it to an SDK version produced wrong version strings.
the stride of the minor version changed from 1 to 2, so SDK versions
ended up higher than they actually were. furthermore macOS 11 was
hardcoded.
since Xcode 12 Apple fixed the SDK version retrieval and it is no longer
truncated when using Xcode as dev tools. Xcode 12 is also the latest
supported version on macOS 10.15, which is also our oldest supported
version. we can remove the old SDK build version conversation and use
the Xcode only tool to retrieve the SDK version in the case Xcode is
used as dev tools. furthermore this als keeps support for Xcode 11 where
the problem wasn't fixed yet, but is still a supported version on macOS
10.15.
Fixes#9907
Having the show-progress command obey no-osd is nonsensical and
unintuitive. The show-text command already ignores no-osd, so there's
precedence for this. Fixes#5662.
Fixes a899e14b which changed clamp from 0 to 1 ms which effectivelly
introduced 1ms sleep always, even if requested until_time_ns is in the
past and should request 0 timeout.
While at it also fix mp_poll wrapper to respect negative timeout which
should mean infinite wait.
Also keep the 37d6604 behaviour for very short timeouts, but round only
the ones > 100us, anything else is 0.
Fixes: a899e14b
Most importantly, the wait_until addition was missed while doing the
unit conversions to nanoseconds which meant mpv woke up roughly every
second since not nearly enough time was added. It was meant to be 1000
seconds (1e9 in microseconds). Use a macro so it's more readable. Also
put some other wild 1e9 calculations inside of a macro as well.
Fixes a899e14bcc.
These have been build options since the waf build, but that doesn't
really make sense. The build can detect whatever macOS sdk version is
available and then use that information to determine whether to enable
the features or not. Potentially disabling multiple sdk versions doesn't
really make any sense. Because f5ca11e12b
effectively made macOS 10.15 the minimum supported version, we can drop
all of these checks and bump the required sdk version to 10.15. The rest
of the build simplifies from there.
No longer needed, wrapped status line is supported now. Also this didn't
work correctly if status were decorated with module name or time.
This reverts commit ab6fac43b4.
- prepare string before printing
- reduce amount of fflush(), especially for multiline messages
- clear status line and keep it always at the bottom
- indent module name to the longest value
- disable cursor for status line
- properly support wrapped status line
Overall makes status line less flickering and remove stray status
instead of scrolling them up.
Currently VOCTRL are completely unusable for frequent data query. Since
the HDR parameter addition to video-params, the parameters can change
each frame. In which case observe on those parameter would be triggered
constantly. The problem is that quering those parameters involves VOCTRL
which in turn involves whole render cycle of delay.
Instead update VO params on each draw_frame. This requires changes to VO
reconfiguration condition, but in practice it should only be triggered
when image size or data layout changes. In other cases it will be
handled internal by VO driver.
I'm not quite happy with this solution, but don't see better one without
changing observe/notify logic significantly. There is no good way
currently to handle VOCTRL that are constantly queried.
This adds unfortunate synchronization of player command with VO thread,
but there is not way around that and if too frequent queries of this
param becomes a problem we can thing of other solutions.
Changes the way to get data from VO driver added by a98c5328dc
Fixes: 84de84bFixes: #12825
Stretch a subtitle duration so it ends when the next one starts.
Should help with subtitles which erroneously have zero durations.
I found such a subrip substitles stream in the wild.
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
windowrc in vo_w32_state is actually client size, for hit test we need
proper window size. When border is disabled those sizes are the same,
but when only title bar is disabled it is not.
Reduce the hit area to more sane values when the border is not
drawn to minimize amount of covered client area in borderless mode.
The previous commit was already a big improvement, but it was still
somewhat slow on the lua interpreter. By wrapping the table at the top
we loose the consistent placement of items while resizing (at least as
long as the column count didn't change), but we avoid taking all the
off screen items into account.
The fewer items fit on screen the faster this becomes.
Showing all properties was terribly slow.
Instead of starting at one row and increasing the row count until it
fits, the column count can be increased until it doesn't fit anymore.
That alone already reduces the required iterations, but from the column
count an upper and lower bound for the row count can be calculated.
For large tables this dramatically reduces the amount of iterations.
So far completing something like `${some-pro}` with the cursor between
`o}` would result in `${some-property}}`. Adding that superfluous `}` can
be avoided by checking if it's already in the string after the cursor.
This was specifically special logic for drm. Before present_sync, it
would also clear out all of its vsync values like this. The old drm code
would save a bunch of samples which would confuse vo.c when unpausing
since it got old, bogus values. Since we make sure to match successive
vsync samples with the swapchain depth and that present sync samples
also match the swapchain depth, this is unneeded.
There's some geometry-related things that mpv has to calculate before
the window is actually mapped onto the screen in wayland. But there's no
way to know which output the window will end up on before it happens, so
it's possible to calculate it using the wrong values. mpv corrects
itself later when the surface event happens, but making the initial
guess work better can help in certain cases.
find_output is the only thing that needs to be changed here. Its main
purpose is to grab the right output based on user settings when we're
trying to full screen and giving a fallback in case we don't have
wl->current_output yet. The x11 code already does something similar, so
we're basically just copying it. Allow user settings like --screen and
--screen-name to influence the initial wl_output guess. Those options
won't actually place the window on that specific screen since we can't
do that in wayland, but if the user knows where the window will end up
beforehand it makes sense to listen to the arguments they pass. If
something goes wrong, then we just fallback to 0 like before.
In the sub seek code path, there was an arbitrary small offset added to
the pts before the seek. However when seeking backwards, the offset was
an additional subtraction. de6eace6e9
added this logic 10 years ago and perhaps it made sense then, but the
additional subtraction when seeking backwards causes the subtitle seek
to go too far to the previous subtitle if the durations overlap. This
should always be an addition to work correctly. Additionally, the sub
stepping code path also could use this offset for the same reason
(duration overlaps). However, it is only applicable to sd_ass not
sd_lavc. sd_lavc has step_sub support but on a sample it didn't even
work anyway. Perhaps it only works for certain kinds of subtitles
(patches welcome).
Anyways instead of keeping this offset as a magic number, we can define
it in sd.h which is handy for this. For sd_ass, we add the offset when
sub stepping, and the offset is always added for sub seeking like it was
before. Update the comment to be a little more relevant to what actually
happens today. Fixes#11445.
Since 062104d16e, we started saving cached
packets for subtitles. However, these can point to the same address as
what is stored in sub->new_segment. When a segment is updated, the
packet is potentially freed. Later during decoding, this can lead to a
double free since the cached packets will naturally try to free itself
and update. Fix this by simply always making sub->new_segment a full
copy of the packet so its lifetime doesn't have to be tied to the cached
packet stuff.
A ton of code and drm-specific abstractions can be dropped with this.
One important thing to note is that the usage of sbc is completely
dropped here. The utility of that is not particularly clear since the
sbc value was manually incremented before the flip and it's not as if
the drm page flip event gives it to us like it does with the msec and
ust. It can be reintroduced later if there is a need. For drm, we also
add a present_sync_clear_values helper since all presentation feedback
needs to be cleared on pause/resume for it.
When this was originally written, the queuing/list approach was
deliberately removed since it adds more complication and xorg/wayland
don't really use it anyway. In practice, you only really have one frame
in flight with presentation timestamps. However, one slight annoyance is
that the drm code has its own thing which is almost exactly the same and
does its own calculations. Ideally, we'd port drm to this instead, but
the implementation there takes into account N-frames in flight which
probably does actually work. So we need to make present_sync smarter and
be able to handle this.
mpv does actually have its own linked list implementation already which
is a good fit for this. mp_present becomes the list and each
mp_present_entry has its own set of timestamps. During initialization,
we create all the entries we need and then simply treat it like a queue
during the lifecycle of the VO. When an entry is fully used
(present_sync_get_info), then we remove it from the list, zero it out,
and append it to the end for future use. This avoids needing to allocate
memory on every frame (which is what drm currently does) and allows for
a reasonable number of in flight frames at the same time as this should
never grow to some obscene number. The nice thing is that current users
of present_sync don't need to change anything besides the initialization
step.
This would cause mpv to, in some very specific scenarios, have a
negative vsync_offset after seeking which would result in mpv requesting
a pts before the first frame to libplacebo.
Fix it by setting it to 0 when we reset state, such as after seeking.
Fixes: https://github.com/mpv-player/mpv/issues/12813
This commit replaces all uses of sig_peak and maps all HDR metadata.
Form notable changes mixed usage of maxCLL and max_luma is resolved and
not always max_luma is used which makes vo_gpu and vo_gpu_next behave
the same way.
This change essentially removes mp_thread_self() and instead add
mp_thread_id to track threads and have ability to query current thread
id during runtime.
This will be useful for upcoming win32 implementation, where accessing
thread handle is different than on pthreads. Greatly reduces complexity.
Otherweis locked map of tid <-> handle is required which is completely
unnecessary for all mpv use-cases.
Note that this is the mp_thread_id, not to confuse with system tid. For
example on threads-posix implementation it is simply pthread_t.
UPDATE_SUB_HARD causes all of the ass objects to reset in order to apply
the new style. UPDATE_SUB_FILT doesn't actually reset the sd, but it
should in order to update the actual filters so that was added here.
Doing this causes the current subtitle to be dropped. In the paused
cause, this concidentally works because command.c forces a video refresh
which then reloads the subtitle essentially. But while playing, the
subtitle will be dropped and you won't get anything until the next one
appears.
Instead of using video refreshes, what we can do is just always save the
last two subtitle packets in a cache and redecode them if needed. This
is much easier and also allows us to get rid of all the video refresh
logic in command.c. Fixes#12386.
The other options that have to do with ass styles also uses this flag.
It's needed since we have to destroy the ass objects and reinit them.
It's a bit incomplete since it will technically only properly work when
paused (while playing, the current subtitle gets discarded). That fix is
in the next commit.
The old one would actually crash if the libplacebo.cache file was
invalid. Additionally, set a max size of 1 GiB for icc cache and 50 MiB
for gpu shader cache. The per object size limit is removed which puts
mpv in line with plplay. Finally, a few memory leaks are also fixed
since several objects previously were not freed on uninit.
For whatever reason, some of the lua code (particularly the osc and
ytdl_hook) is full of a bunch of stuff like if (foo), if not (foo ==
nil), etc. The parenthesis aren't needed in lua and actually just look
weird since nobody actually writes lua like this. You can see most of
the other conditionals are written normally. So cleanup the style to
match when the parenthesis clearly aren't doing anything. Not directly
related, but also add some spaces on a few math operations while we're
at it.
This avoids a "Redefined local `options`" LSP warning in
list_option_list() after the previous commit. It still works, but
reusing names for local variables is error-prone.
Probably should have actually tested the filter changes but I didn't.
This was the wrong spot anyway since labels are unique. Something like
this should have been done further down when finding it by content. On
second thought, having multiple filters with the same content does have
a usecase (e.g. stacking multiple rotations) so removing all of them at
once probably isn't great. There's no practical usecase for having
duplicates in a string list, so we'll leave that change alone.
Fixes#12791.
Vapoursynth does not provide crop metadata and input one is likely to be
invalidated during filtering. Set crop to full frame if image dimensions
were changed during filtering.
Fixes: #12780
Previously, the av sync change calculation was only done if the
audio_status was STATUS_PLAYING, but there is at least one or two more
states where this should be done. player/audio is capable of adding
delay if the state is anything besides STATUS_EOF. This means that while
calling adjust_sync, the delay value could have changed from the audio
side of the equation from the previous playloop, and it doesn't
necessarily mean that the current audio_status is STATUS_PLAYING either.
So the old code would technically skip this case. In practice, this is
just one frame so it hardly matters, but it should be taken into
account. For example, STATUS_READY is definitely possible here in
adjust_sync. I'm not sure if it's actually possible for STATUS_SYNCING
to happen but the audio code can change add delay with that status, so
it doesn't hurt. STATUS_DRAINING is probably not relevant, but again
include it to mirror the audio code logic. Of course, STATUS_EOF is
obviously a no-no since that means no audio at all, so we return from
there. I didn't take hard measurements or anything, but this does seem
to result in slightly smaller av sync fluctuations on discontinuities
(like seeking) which makes sense because we're now making an additional
correction that wasn't previously done.
Another change is to always try adjust_sync as long as the frame_time is
nonzero. The old logic only did this if the video_status was playing or
greater, but it is possible to get new frames with a different PTS that
do not have that status. The audio is still playing so logically it
should be adjusted as well. Again, this happens for just one frame, so
it doesn't really matter in practice but it should make more sense. A
zero frame_time is skipped since that would mean the pts did not advance
and the previous playloop should have done the adjustment for that time
already.
3038e578af recently changed the logic here
so it wouldn't trigger on still images, but after thinking about the
code here some more, I don't believe it's needed at all. Doing an ao
reset when you flip the video track is very disruptive and not really
desirable at all. Since the ao no longer adds bogus delay values while
the video is off, there should be no need to do a full reset for syncing
reasons. The delay value will be zero, so we can let the audio just play
normally and let the video code do its thing. There is one slight trick
here however. When using a display sync mode, part of the syncing code
will try to update the audio and video playback speed. This can cause an
audio underrun if we're just turning the video back one. An easy way to
avoid most of these is to not update the speed if we are in the
STATUS_SYNCING state for video. This isn't quite perfect and underruns
are still possible, but it actually seems to depend on the AO. e.g. I
couldn't trigger an underrun with alsa but I could with pipewire. In any
case, the audio artifact here is much less noticeable than doing a full
ao reset, so it's still an improvement.
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.
When using -remove with list options, it previously only removed the
first match. Technically, it is possible for there to be more than entry
with the same name. They should all be removed. key/value lists
specifically only allow unique keys so we don't need to do anything
there.
ytdl lists thumbnails in ascending order according to height/preference.
all_formats=yes adds formats from best to worst, so the same should also
be done for thumbnails.
yt-dlp has a preference field for it's thumbnails, and not all of it's
listed thumbnails have fields with their dimensions.
Therefore prefere the preference field when available and fall back to
height if it's not.
Since we can no longer rely on distuils for a version comparison, let's
modify the macos-sdk-version script so it returns multiple potential
versions to meson. Then use meson's built-in version comparison to pick
the right one instead. This avoids the complication of needing certain
python packages installed since everything simply uses stdlib functions.
Since distutils was dropped from python 3.12, we can't rely on a
standard library implementation for version comparison anymore hence
the switch to packaging instead which is essentially supposed to be the
replacement. This is problematic though because macOS can have several
ways of managing python can result in the build calling the wrong python
binary that doesn't have the actual packaging library installed. This
commit was a workaround for that since it would fetch the python used to
run the build (which is probably the one the user wants), but apparently
upstream doesn't like this and it's subject to change*. So instead,
let's solve try, and solve this a different way.
This reverts commit a57bd8e2b8.
*: https://github.com/mesonbuild/meson/pull/12116#pullrequestreview-1575846647
- Use import to find Python installation.
- Run macos-sdk-version.py with Python provided by meson.
This fixes an error when meson and python-packaging are installed from
Homebrew. Currently, the Python executable from python@3.12 is installed as
python3.12 so python3 is referring to system installation, which may not
have packaging module. meson can provide the correct executable via import.
This was originally for the waf build, and then later writing the output
to a file was added for meson. Since the waf build is no longer around
anymore, remove the dead code.
CLOCK_MONOTONIC_RAW is linux-specific (macOS later supported it but it
has its own timer code) and not neccessarily available everywhere like
on BSDs. It makes sense to prefer it because mpv does a lot of
measurements at small intervals (e.g. every frame) so theoretically it
should be more accurate. However if the OS doesn't have it, fallback to
CLOCK_MONOTONIC instead which is almost exactly the same and very widely
supported across unix-like systems. This clock is technically optional
according to POSIX, but any half-decent OS supports it anyway (sorry
Solaris users). As a benefit, we now know that the clock from mp_time is
always monotonic.
I'd like some names to be more descriptive, but to work with 15 chars
limit we have to make some sacrifice.
Also because of the limit, remove the `mpv/` prefix and prioritize
actuall thread name.
Python 3.10 deprecated disutils and then removed it in 3.12. The macos
sdk check uses the version compare from there, so it needs to be
replaced with something else. So instead use the API from the packaging
module which is also widely available and a fit replacement.
Fixes#12762.
dac977193c changed adding delay to only
when the video is playing but this isn't correct. The video frames
adjust themselves based on the audio, so if we still have audio
processing while the video itself happens to be in some non-playing
state (such as STATUS_READY), the delay still needs to be taken into
account. The correct thing to check is to make sure that it is not
STATUS_EOF. STATUS_EOF covers the case where we have still image, and of
course no video at all is STATUS_EOF. So having a massive bogus delay
value is still avoided.
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.
The point of the mpctx->delay field is for calculating a/v sync and
adjusting the frame timings appropriately. However, the frame_time was
always subtracted from mpctx->delay regardless of the audio status. This
meant that for a video with no audio, every single frame had a
subtraction with nothing ever added to it meaning that you get massive
negative delay times. For weird videos where the audio starts way later,
the massive delay leads to the VO sleeping for basically about as long
as the video was previously playing without audio. This results in
nothing being rendered during that brief period of time and just overall
badness. When using display-sync, it happens to work since the video
doesn't adjust itself based on audio and it renders anyway.
The fix is to simply not touch mpctx->delay in player/video.c unless
there's actually audio playing. This is what the rest of the code
already does aside from setting it to 0 on resets or EOFs. Move the
calculation into adjust_sync after the audio status check. It works
exactly the same as before except that we don't constantly subtract
bogus values when there's no audio playing. The reverse situation in
player/audio.c also has the same issue. For something that is only
audio, mpctx->delay is always added to but nothing will ever subtract
from it. It's not really clear if this particular version could ever
cause a real bug, but logically it needs to be guarded in the same way.
The field here should only be updated if the video is actually playing.
Fixes#12025.
The end position of the word to be completed is never used because all
patterns end with $. Remove it or it would complicate implementing
completers with more patterns.
This will allow providing more nested completions without pre-generating
an enormous amount of completions, and it is more efficient since it
only generates the completions needed for each completion attempt.
In the pursuit of stability.
It is slower and QEMU-based, but if this isn't stable, I don't know what
will be.
Bump the timeout to 30 minutes, just in case. It seems to take 12-15
minutes to finish.
Peak detection greatly increases HDR experience. Performance hit of
non-delayed detection is not that significant and is in line with
current default settings.
This fixes warnings generated for `-Wunused-result` when mpv is built
with `-O1 -D_FORTIFY_SOURCE=1` or higher on clang since read/write
functions are declared with the `warn_unused_result` attribute.
Cast to void to avoid these warnings.
It was found that this causes issues with at least ao_coreaudio,
essentially revealing a way bigger issue:
Some AOs don't check for 0 and/or have no way to deal with short writes.
Someone will have to figure out a fix later but get rid of the direct
cause for now.
This reverts commit ae908a70ce.
Any track that has attached picture is also always considered an image.
Not every image is neccesarily an attached picture though. So change the
check here to capture more possible cases where we should be updating
the subtitle. With the previous commits, this fixes#12387.
Add a simple helper to codec_tags to check if the codec name matches one
of the images. If so, then we set still_image and image in the stream as
true (slightly different semanatics).
demux_mf has a big const struct which is essentially a nice list handy
list of codecs that are considered images. This is generally useful for
all demuxers (demux_mkv could use this), so instead of making yet
another list, lift it out and put it in a common place. Some things
slightly changed so it matches the very similiar mimetype mapping struct
below it. demux_mf calls a helper mapping function instead.
This actually started having a linking error a few days ago, but the ci
never actually actually exited 1 for some reason so it was never caught.
The actual commits where this started happening are unrelated (reverted
all of the them to be sure) and there's no other obvious things like a
meson update that would cause this. All I can assume is some other
package within BSD itself, but I can't be bothered to debug it. Anyways,
just disable iconv in the build for now so the CI stops failing.
Presumably there's something wrong in the environment with GNU's
libiconv and the built-in one clashing somehow. Also, sdl unbelievably
defines HAVE_ICONV in their public header so we have to disable that
too.
Since vmactions is basically a bootlooping disaster* with no signs of
life from upstream, let's try a different action instead and hope it
works better. We don't need to force the latest release channel, so
delete that part. Also make the pkg install just one command for
simplicity.
*: https://github.com/vmactions/freebsd-vm/issues/74
I won't even comment how terrible this option is and why in 2023 default
is not at least `autocrlf=input`.
Disable the conversion to CRLF. We build everything in MSYS2 sysroot,
which supports/expects LF. While the checkout itself is done with
actions/checkout@v3 and this causes problems.
C standard says that `= {0}` activates and initializes first member of
union. We expect whole union to be zeroed, it is used as default value.
Initialize union with one zeroed default instance to ensure proper init.
Fixes: #12711
Make it not possible to build mpv without the latest libplacebo anymore.
This will allow for less code duplication between mpv and libplacebo,
and in the future also let us delete legacy ifdefs and track libplacebo
better.
Some hwdecs (eg: dxva) have no frames constraints and no static
supported_formats, which ends up segfaulting. This change fixes the
segfault, but also includes additional changes to avoid concluding that
direct output of hardware decoded video is impossible.
In the case where there are no frame constraints and no
supported_formats, we basically have no idea what the hardware actually
supports. Previously, we just tried to display the frame, but all the
work I did to detect incompatible formats causes this scenario to now
conclude that no formats can be displayed, and forces a HW download to
system memory.
I have made a couple of small changes to assume that direct display is
possible. If it's not, the VO will error out down the line, which is
what happened previously.
I'm guilty of violating this, but surely I can't be the only one. 85 is
pretty small and there's plenty of lines in the codebase that go well
over that. Surely nobody programs on tiny screens anymore and the kernel
raised the limit to 100 a few years ago so let's just copy that.
Nobody except a chosen few (I'm not one of them) even knows what it
means. Multiple people thought it was actually some kind of rendering
bug. Just disable it by default. Closes#12671.
currently for a filename such as ".file" mpv incorrectly thinks of the
entire filename as being an extension. skip leading dots to avoid
treating "hidden/dot" files as extension.
Matroska spec says that DisplayWidth and DisplayHeight should be applied
after cropping, but this doesn't adhere to the real files which does not
follow this rule. Revert the change and we can re-evaluate if someone
complains with spec compliant files.
See: https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/
This reverts commit f8db02b59d.
Unfortunately there are files out there with broken tags where the
width/height doesn't match the actual width/height of the file. That
means the cropping logic which normally should be a no-op resulting in
(0, 0, w, h) ends up being a crop which is probably not wanted by the
user. Workaround this by simply keeping the entire crop rect as 0 when
there is no container cropping. All zeros is internally treated the same
as (0, 0, w, h) and avoids bad container data messing up the width or
height of the window. Also simplify the logic a bit and get rid of some
superflorous bools that had no real use. Fixes#12680.
macOS didn't support clock_gettime until 10.12 which was released
roughly 7 years ago. Since we're breaking support for ancient OSes
anyway, we might as well break some old macOS versions for fun. This
makes 10.12 the minimum supported macOS version.
ao_read_data() is used by pull AOs potentially from threads managed by
external libraries. These threads can be sensitive to blocking.
For example the pipewire ao is using a realtime thread for the
callbacks.
since i was going to fix the include order of stdatomic, might as well
sort the surrouding includes in accordance with the project's coding
style.
some headers can sometime require specific include order. standard
library headers usually don't. but mpv might "hack into" the standard
headers (e.g pthreads) so that complicates things a bit more.
hopefully nothing breaks. if it does, the style guide is to blame.
replace it with <stdatomic.h> and replace the mp_atomic_* typedefs with
explicit _Atomic qualified types.
also add missing config.h includes on some files.
Also apply some fixes to pthread_cond_timedwait while we're at it.
Note that by using GetSystemTimePreciseAsFileTime here we lose support
for Windows 7. This is considered acceptable.
This reverts commit 318b5471a1.
While it may work, changing these two functions in violation of their documented
behaviour for the sake of a shortcut is a hack that will spell disaster sooner or later.
This is a partial revert since the commit in question also contained a hidden
bugfix where it swapped the calculation order for time_rel.
Otherwise acronyms and such would fail the lint, and it doesn't make any
sense to enforce it here. Also make sure that the length of the word is
greater than 1 to avoid something like "foo: A blah blah" from passing.
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.
It was completely wrong. mpv will buffer data ahead of where the CD
currently is playing. When enough data was buffered into the next track,
the track info is printed regardless of where the stream position
actually is. Depending on the user settings, you can get mpv to buffer
minutes ahead. Printing a message when the track changes might be nice,
but this isn't the right place to do it. Some other mechanism would need
to be leveraged, but I'm not going to bother figuring it out.
CDIO_API_VERSION 6 has been around since libcdio 0.90. That was release
over a decade ago. There's literally no reason to keep the ugly mess of
the old api around so remove it.
Some users report visible black frames during window resize, this should
not happen in most cases. Let's just keep stale content as it is less
distracting. While still clearing on first window paint to avoid white
background.
Fixes: #12642
This is more stable in practice. Avoids switching between possibly
different hwdecs and avoids unnecessary init. Software decoding should be
more stable and possibly faster overall for decoding this small portion
of video needed for cropdetect.
Use mp_tags_move_from_av_dictionary() in place of
mp_tags_copy_from_av_dictionary().
This ensures that when lavf appends metadata
that occurs later in the stream,
it starts from empty each time.
Fixes: <https://github.com/mpv-player/mpv/issues/12559>
Abstracts a common pattern,
in which the av dictionary is cleared
immediately after copying to mp tags,
so that additional tags later in the stream
get appended to empty tags,
instead of being appended to existing tags
that were already copied.
To avoid switching to scientific notation. Apparently it is "jarring"
for some users.
This preserves status quo from before 9dddfc4f where pretty printer were
truncated to 3 decimal places.
Some ffmpeg hwcontexts do not implement frame constraints. That means
they cannot report which formats are support for given configurations.
My previous changes to make hwupload more capable relies on the
constraints to be provided to accurately describe what combinations are
supported, so we will currently see a bunch of errors failing to
configure the hwupload filter on platforms such as v4l2 SoCs with
drmprime. This doesn't break playback, but it's confusing.
To bridge the gap, this change uses the static format metadata that we
include for hwdecs to build a fake constraints struct to keep all the
other code working.
Homebrew has finally given up supporting macOS 11, and all updated
dependencies are being built locally. Additionally, python3.12 - being
a dependency of libass in Homebrew - seems to completely fail under
cairo's meson usage on macOS 11, even if we let it build.
Thus, finally remove macOS 11 from our macOS build matrix, leaving
12 and 13.
ref: Homebrew/brew#16019
With the previous series of commits, all internal usage has been
replaced by the nanosecond functions. There's not really any point in
keeping these around anymore plus there are macros for unit conversions
now so we can just axe them. It's worth noting that mpv_get_time_us()
obviously still needs to work for API reasons, but we can just divide
mp_time_ns() by 1000 to get the same thing.
Pull AOs work off of a callback that relies on mpv's internal timer. So
like with the related video changes, convert all of these to nanoseconds
instead. In many cases, the underlying audio API does actually provide
nanosecond resolution as well.
There's a lot of wild 1e6, 1000, etc. lying around in the code. A macro
is much easier to read and understand at a glance. Add some helpers for
this. We don't need to convert everything now but there's some simple
things that can be done so they are included in this commit.
The whole mess with setting the option value explictly and saving the
old stop_play value only needs to happen if we're at the end of file.
Doing it in general is unneccessary and breaks other things.
Fixes#12424.
These are ancient and have existed since before stats.lua lived in the
mpv repository. We don't need to worry about ancient mpv versions
anymore, so remove these.
Why a bigger search-interval is required:
scaletempo2 doesn't do a good job when the signal contains frequencies
less then 1/search_interval. With a search interval of 30ms that means
anything below 33.333Hz sounds bad.
Depending on the genre it's very for music to contain frequencies down
to 30Hz, and sometimes even a little bit below that. Therefore a higher
default value is needed to handle such cases.
Based on that an argument can be made for a value of 50, as that should
work down to 20Hz, or something even higher because movies sometimes
have some infrasonic content.
However the downside of big search intervals is increased CPU usage and
intelligibility at higher speeds, as it effectively leads to parts of
the audio being skipped.
A value of 40 can handle frequencies down to 25Hz, enough for all music
except very rare edge cases, while still providing decent
intelligibility.
Why a smaller window-size is required:
Large values reduce intelligibility at high speeds and therefore small
values are preferred.
However when values get too small it starts to sound weird
(similar to librubberband).
In my testing a value of 10 already works well, but adding a small
safety margin seems like a good idea, especially since it made no
noticeable difference to intelligibility, which is why 12 was chosen.
The text didn't line up with with the percentages above it because it
didn't use a monospace font.
Instead insert the text at the same position in the template as the
percentages and convert one o.prefix_sep from the percentages into hard
coded \h\h to ensure alignment even when the user changes o.prefix_sep.
add support for vulkan through metal and a translation layer like
MoltenVK. also add the possibility to use different render timing modes
for testing.
i still consider this experimental atm.
add an animation lock to the window to prevent the window from closing
while animating. if this is done while the fs animation is running the
dock will stay hidden. this is not used yet, because it's unnecessary
for cocoa-cb but will be for new vo backends.
Use "%.7g" to show 7 significant digits. Removes the trailing zeros, and
in general makes it more readable, than fixed 3 decimal digits.
For avsync use "%+.2g" to add plus sign, similar to display-sync
values.
- rename prefix to `Framerate:`
- if both estimated and specified values are the same display fps once
- skip the suffix if both the estimated and specified values agrees
Source video parameters are interesting, but we mix them with video
output/target parameters. Which will differ. Add "Display" showing
true output params from VO, including HDR passthrough info and
everything. This makes much more consistent output and alows to quickly
diagnose how is source video translated to target display.
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.
This was wrongly assuming that playlist_path is always set for the
current playlist entry, but it's only set when a file was added by
expanding a playlist.
The crash in playlist_get_first_in_next_playlist can be reproduced with
mpv foo.mkv foo.zip, playlist-next, playlist-prev,
playlist-next-playlist. You need to run playlist-next, playlist-prev
first because foo.zip's playlist_path is NULL until you do that, which
makes playlist_get_first_in_next_playlist return immediately.
The crash in cmd_playlist_next_prev_playlist can be replicated with mpv
--loop-playlist foo.zip foo.mkv, running playlist-next until foo.mkv,
and playlist-play-next. Again, you need to open foo.zip first or its
playlist_path is NULL which skips running strcmp(entry->playlist_path,
mpctx->playlist->current->playlist_path).
Fixes https://github.com/mpv-player/mpv/issues/12495#issuecomment-1760968608
there are currently some silly data-races in the stop/cont sighandler
due to the fact that the signal handler might get invoked in a different
thread.
this changes those sighandlers to a pipe-based approach similar to the
existing "quit" sighandler.
tio_orig and tio_orig_set are being touched inside of signal handler
which might be invoked from another thread - which makes this a data
race.
there's no real reason to set tio_orig inside of do_activate_getch2()
which is registered as a signal handler. just set it once, in
terminal_init(), before any signal handlers come in play.
this also allows removing the tio_orig_set variable completely.
do_deactivate_getch2() touches some global variables which *might have*
been fine if the terminal thread was the one that received the signal
but AFAIK which thread will handle the signal is not well defined.
in my case, when quitting mpv with CTRL+C the main thread receives the
signal rather than the terminal thread and touches those globals without
synchronization. caught by ThreadSanitizer.
the solution is to move the do_deactivate_getch2() call outside of the
signal handler.
Use EDL for single tracks with metadata to set the uploader, channel url
and description metadata with --ytdl-format=best. Currently, these are
only set with the other ytdl formats with video and audio in different
streams.
The uploader tag is commonly available in sites other than Youtube too,
so it may be simpler to always use EDL with single tracks.
Added to the functions `mp.add_timeout` and `mp.add_periodic_timer`.
If the `disabled` argument is set to `true` or a truthy value, the
timer will wait to be manually started with a call to its `resume()`
method.
Only vpdau-copy works with EGL. 2d1d815cc7 already added this to
manpage, and 1c8d2246bf removed it again, but that seems to be a mistake
because I can only get vdpau to work with GLX, and another user also
reported that only vdpau-copy was working for him with the default EGL.
Several window resizing operations (i.e., --auto-window-resize,
border dragging with --keep-aspect-window, Alt+0/1/2) cause the
window to detach from the snapped borders. This patch resolves
this by recording to which borders the window is snapped, and
using this info to determine how the window should be placed after
resizing.
Closes https://github.com/mpv-player/mpv/issues/6588
Allows higher resolution sleeps than Sleep which has milliseconds
resolution. In practice Windows kernel does not really go below 0.5ms,
but we don't have to limit ourselves on API side of things and do the
best we can.
Linux and macOS already use nanosecond resolution for their sleep
functions. It was just being converted from microseconds before. Since
we have mp_time_ns now, go ahead and bump the precision here. The timer
for windows uses some timeBeginPeriod thing which I'm not sure what it
does really but whatever just convert the units to ms like they were
doing before. There's really no reason to keep the mp_sleep_us helper
around. A multiplication by 1000 is trivial and underlying OS clocks
have nanosecond precision.
9606c3fca9 added mp_time_ns(). Since we
apparently expose the mp_time_us() to clients already, there's no reason
to not also expose the new nanosecond one.
On linux, several platforms poll for events over a fd. This has ms
accuracy, but mpv's timer is in ns now so lots of precision is lost. We
can use an mp_poll wrapper to use ppoll instead which takes a timespec
directly with nanosecond precision. On systems without ppoll this falls
back to old poll behavior. On wayland, we don't actually use this
because ppoll completely messes up the event loop for some unknown
reason.
Originally, this was added as purely a shim for macOS. However since we
want to do high resolution polling which is not neccesarily available on
all platforms, making this a generic wrapper for poll functions is
useful so rename it.
In many cases, this is purely cosmetic because poll still only accepts
microseconds. There's still a gain here however since
pthread_cond_timedwait can take a realtime ts now.
Additionally, 37d6604d70 changed the value
added to timeout_ms in X11 and Wayland to ensure that it would never be
0 and rounded up. This was both incomplete, several other parts of the
player have this same problem like drm, and not really needed. Instead
the MPCLAMP is just adjusted to have a min of 1.
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.
Lines that would be outside of the visible area are now culled.
The log messages were already culled, however with the introduction
of suggestions, they also needed a small update.
Completion suggestions are now nicely formatted into a table.
Maximum width of the table is estimated based on OSD size and
font size.
This requires a new scaling factor option `font_hw_ratio`.
A factor of 2.15 works great for me,
but the default is 2.0 to avoid problems with other fonts.
The space between columns is automatically adjusted to be
between 2 and 8 spaces.
It tries to use as few rows as possible.
Tab completion now shows a list of all potential completions
between the log messages and prompt.
The text is colored to differentiate it from regular text.
The color matches the theme and is similar to the mpv logo.
The text styles are now in a table.
The color definitions of the theme where the colors were taken from
are now included in a comment for future reference.
The colors have been converted to BGR as is required by ASS.
vo_still_displaying() is racey with vo_request_wakeup_on_done() and above
that it doesn't work as expected. VO can run out of work and go to sleep
for 1000s, while the play thread still returns on vo_still_displaying()
check, because of a check `now < frame_end` so it never advances and go
to sleep itself.
This fixes dead lock that we have when image parameters changes during
playback.
This reverts commit 0c9ac5835b.
Fixes: #12575
It's 2023 and people don't use UTF-8 for their m3u, ini, etc. files.
Well mpv already has the tools in place to try and guess other
codepages, so we might as well use it I guess. This change is pretty
awkward since we have to read line-by-line but mp_iconv_to_utf8 may
sometimes allocate memory. So sometimes the bstr needs to be freed and
sometimes not for every line. Also we need to make another copy of the
line on the stack since splitting by tokens and such will mess up the
original line which may possibly be allocated memory. The ugliness is
mostly hidden in pl_free_line, but it's still weird. Fixes#10911.
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.
a343666ab5 made demux options public, so
we can take advantage of that here as well. This lets users guess the
codepage if the stream doesn't use UTF-8 characters. Fixes#8844.
The function called to get sub-start and sub-end returns early when the
subtitle's duration is unknown, but by just removing this check the
properties work fine. The final sub line has a very large sub-end, but
that is much better than not having the properties work at all.
fbe154831a added a new VOCTRL to signal
when the OSD changed for gpu-next's handling of subtitles, but this is
both not necessary and actually incomplete. The VOCTRL would signal OSD
changes, but not all subtitle changes (like selecting another
non-external sub track for example). VOCTRL_OSD_CHANGED was used to
increment p->osd_sync which would then redraw the blended subtitles if
the player was paused.
But there's already a VOCTRL_PAUSE and VOCTRL_RESUME. Plus, the
sub_bitmap_list object will have items in it if it changed in any way,
so we don't need the VOCTRL_OSD_CHANGED method at all. That can be
removed.
The check that fp->osd_sync < p->osd_sync stays in place since that's an
optimization while the video is playing, but we also check the pause
state as well since the VO can know this. If we're paused, then always
do update_overlays since core must be signalling a redraw to us if we
get a draw_frame call here. Additionally in update_overlays itself, the
p->osd_sync counter is incremented if we have any items since the frame
signature will need that. As for the actual bug that is fixed, changing
subtitle tracks while paused with blended subtitles now correctly works.
Previously, it was never updated so the old subtitle stayed there
forever until you deselected it (since VOCTRL_OSD_CHANGED triggered
there).
Also include some cosmetic code fixes that were noticed.
The current calculation makes the implicit assumption that the margins
on both sides are always equal (the 2 times multiplication). This isn't
true though. For example, a 720p video fullscreened on a 1680x1050
display will have a top margin of 52 but a bottom margin of 53. The
current calculation just multiplies 52 by 2, so it's off by one. Fix
this by adding together all the margins together (left + right or top +
bottom) then adding that to the dst window size (width or height). This
way, we get the full size of the window for the viewport. Fixes#12554.
This fixes white background appearing for short period of time before
first frame is drawn. Clear to black as this is way less distracting
than bright white flash.
Borderless window and fullscreen seems to be initially not
drawn/transparent, so no need to clear it to black. Only when
decorations are enabled (--border) the issue happens.
Fixes: #12549
e277fadd60 originally added this but it
never actually did anything in the function... wm4 probably changed his
mind but forget to delete it so just remove it here.
2c6a3cb1f2 originally added this struct
member and then 1be863afdb later added
some more logic to loadfile that uses this. There's been more changes
since then of course, but bits using playback_short and playback_start
have mostly stayed the same. It's a bit strange it's worked this way for
so long since it makes an assumption on how long files should be and
leads to weird, broken behavior on playlists with shorter videos. The
main reason for playlist_short, as far as I can tell, is to deal with
some fringe cases with short videos and trying to go back in the
playlist. More specifically, if you use --loop=inf on a very short video
(say less than 1 second) and try to go back in the playlist, you won't
be able to without any of this special logic that deals with it. But the
current approach has several side effects like going back multiple items
in the playlist instead of just one if the video is less than one
second. This is just bad so delete everything related to playlist_short
and playlist_start.
Instead, let's handle this by keeping track of playlist-prev attempts.
Going forward in the playlist doesn't require any special handling since
a bad/broken file will just advance to the next one. So it's only going
backwards that requires some special consideration. If we're going
backwards and the user isn't using force, then mark the playlist entry
with a special flag. If the file loads successfully in
play_current_file, we can just clear the flag and not worry about it.
However if there's a failure, then we set a bool telling
play_current_file that it should go back one more item in the playlist
if possible and try again. This way, we avoid the previously mentioned
--loop=inf edgecase and the user can still attempt to retry previously
failed items in the playlist (like a url or such).
Fixes#6576, fixes#12548.
Forgotten in 7b8a30fc81. Every other case
either is either a dummy frame (no allocated memory) or we manage it as
part of the usual wayland buffer release.
When implementing vo_dmabuf_wayland, it always did a copy of the image
from the current frame and worked with that. The reason was because
mpv's core held onto the frame and caused some timing issues and
rendering glitches depending on when it freed the image. This is pretty
easy to fix: just make vo_dmabuf_wayland manage the the frames. In vo.h,
we add a boolean that a VO can set to make them manage freeing frames
directly. After doing this, change the buffers in vo_dmabuf_wayland to
store the whole vo_frame instead of just the image. Then, just modify
some things a bit so frame is freed instead of the image. Now, we should
truly have zero-copy playback. Well as long as you don't use libass to
render anything (that's still a copy from system memory).
msg.info for when you're potentially adding hundreds of files is way
too spammy and not really useful (autoload loads files, what?). Bump it
up to msg.verbose. Also bump up the previously existing msg.verbose logs
up to msg.debug to keep the difference in log levels. Fixes#12551.
This allows libmpv users to build it as a subproject easily, i.e. meson
setup build --force-fallback-for=mpv -Dmpv:libmpv=true, if the mpv
source is in the subprojects directory. Mainly useful for development.
e125da2096 changed the z order of the
surfaces a bit, but it turns out this has a side effect. If the aspect
ratio of the actual video doesn't match your display, the osd surface
doesn't scale properly and gets clipped. Put the z ordering back where
it used to be. Instead when we have the force window case, simply attach
the already existing solid buffer to the video surface. This allows the
osd surface to actually draw over it instead of always being obscured so
it satisfies the case of not having any real video frames but still
wanting to draw the osd. Also don't mess with any of the viewport source
setting stuff with force window. Weston complains about it, and it's
nonsensical anyway. Fixes#12547.
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.
Previously if the demuxer didn't exist, then it could jump down and try
to free sinfo.filename before it was ever set thus segfaulting. Just
always set the struct unconditionally so we're always sure to free it.
Some demuxers actually close the stream right after they are finished
opening like cue. Since the stream->url is no longer copied with this
commit, that means it gets thrown away after the stream closes. This
leads to a use after free. We still need to allocate stream->url so fix
this another way.
This reverts commit 3e85df3b2d.
Combine the cover art whitelist with the extensions in
--cover-art-auto-exts instead of hardcoding them. This is shorter,
checks for more extensions, saves us from updating the whitelist
everytime we add a new image extension, and since the whitelist had
gotten so big and the priority is calculated as
MP_ARRAY_SIZE(cover_files) - n, files like cover.jpg were taking
priority over cover art loaded by --cover-art-auto=exact.
0739cfc209 added the draw_frame API
deprecated draw_image internally. VOs that still used draw_image were
around, but really there's no reason to not just "upgrade" them anyway.
draw_frame is what the "real" VOs that people care about (gpu/gpu-next)
use. So we can just simplfy the code a bit now. VOCTRL_REDRAW_FRAME is
also no longer needed so that can be completely deleted as well. Note
that several of these VOs are legacy crap anyway (e.g. vaapi) and maybe
should just be deleted but whatever. vo_direct3d was also completely
untested (not that anyone should ever use it).
Remove keybindings for properties that have been removed because they
can no longer be used even if you restore them.
Replace dvb-channel-name with dvbin-channel-switch-offset.
Fix the L keybinding: it was bound to cycle-values loop when loop was an
alias for loop-playlist, but now it's an alias for loop-file.
"osd" was a command that cycles osd-level from 0 to 3.
Keep only the newest I show-text "${filename}" from mpv 0.26, the mpv
0.5 line for it is a mistake because it was bound to that in input.conf
from a749c61437 (2012) until 2e84934be7 (2017), while mpv 0.5 is from
2014.
Yeah another try at this. So when inspecting lazy_stream_needs_wait, I
realized it had a curious !ds->reader_head condition. Actually, this is
what is messing everything up. This was originally added in
cf2b7a4997 for showing large negative sub
delay values correctly. It worked because the packet will eventually be
discarded during playback causing ds->reader_head not exist and thus the
next one will correctly be read ahead as needed.
But for the "switching subtitle tracks while paused" case, this is
actually bad. As the stream is read, eventually you'll find a packet and
set the reader_head. But it's not going to be the correct packet (unless
you're looking for the very first one), so you need to read more. This
won't happen because of the !ds->reader_head check and unlike the sub
delay case, nothing will eventually discard that packet since playback
isn't occuring. So read_packet exits earlier than it should and isn't
tried again, so the subtitle that you want won't show since the
returned packet has the wrong pts. All that needs to be done here is to
delete this one condition. There's already checks in place to make sure
that it's not read past the desired timestamp and for the sub delay case
(the only other time this logic is used), it makes no difference since
you won't read past the specified pts in the first place.
The stream selection state wasn't improved. I didn't realize this messed
with caches. All in all, just not a good idea. Back to drawing board I
guess.
This reverts commit f40bbfec4f.
The timestamps when making a log file is actually dependent on
MP_START_TIME. This is a 10 microsecond offset that was added to the
timer as an offset. With the nanosecond change, this unit needs to be
converted as well so the offset is the same as before. After doing that,
we need to change the various mp_time_us calls in msg to mp_time_ns and
do the right conversion. This fixes the logs timestamps (i.e. so they
aren't negative anymore).
This causes only problems, because we convert mp_time to realtime, which
is not atomic, so we introduce error. And even though on sane platforms
it should work fine, after all the sleep time is in the past.
winpthreads like to sleep for like over 10ms when the time is less than
current time, but not more than 1s.
When seeking chapters, `last_chapter_seek` acts as a projection of
what the current chapter will be once mpv has a chance to seek to it.
This allows for more accurate results from the `chapter` property.
It works by comparing the projection to the actual current chapter
and returning the larger of the two indexes, but this only works when
seeking forward.
If we want it to work for both forward and backward chapter seeking,
we can instead use a boolean called `last_chapter_flag`, which gets
switched on when a chapter seek request is made, and then
switched off when the seek has been performed.
We should also check to ensure that we don't allow the chapter index
to be set to -1 unless there is a span of time between the very
beginning of the track and the start of the first chapter.
Since the new approach to resetting `last_chapter_seek` no longer
depends on `last_chapter_pts`, that member variable can be removed.
In practice, most compositors implement the rotation clockwise which
matches mpv's option, but amusingly this is actually incorrect.
According to the spec*, wayland buffer rotations are counter-clockwise.
So with this assumption in mind, in order for the rotation to match
mpv's usual semantics, the 90 degree and 270 degree positions need to be
flipped. Of course, this will make the VO rotate the wrong way on most
compositors, but this is what the spec says (sway master is known to
currently be correct). Fixes#12508 (sort of but will break the rotation
direction on other compositors. Oh well).
*: https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_output-enum-transform
NV16 is the half subsampled version of NV12 format. Decoders which
support High 4:2:2 of h264 provide the frame in NV16 format to establish
richer colorspace. Similar profiles are also available in HEVC and other
popular codecs. This commit allows NV16 frames to be displayed over
drmprime layers.
Signed-off-by: hbiyik <boogiepop@gmx.com>
This is the most supported in standard layout, if we request more it
tends to fallback to stereo instead. Also channels mask is 32-bit and it
can get truncated.
External subtitles are always read as eager, so they do not need to be
changed on pause/unpause. Don't do the refresh seek since it will just
buffer forever. Fixes f40bbfec4f.
This replaces the previous commit and makes more sense. The internal
demux marked tracks as eager depending on their type and for subtitles
it would always lazily read them unless there happened to be no
available av stream. However, we want the sub stream to be eager if the
player is paused. The existing subtitle is still preserved on the
screen, but if the user changes tracks that's when the problem occurs.
So to handle this case, propagate the mpctx->paused down to the stream
selection logic. This modifies both demuxer_refresh_track and
demuxer_select_track to take that boolean value. A few other parts of
the player use this, but we can just assume false there (no change in
behavior from before) since they should never be related to subtitles.
The core player code is aware of its own state naturally, and can always
pass the appropriate value so go ahead and do so. When we change the
pause state, a refresh seek is done on all existing subtitle tracks to
make sure their eager state is the appropriate value (i.e. so it's not
still set to eager after a pause and a track switch). Slightly invasive
change, but it works with the existing logic instead of going around it
so ultimately it should be a better approach. We can additionally remove
the old force boolean from sub_read_packets since it is no longer
needed.
Actually, I thought of a better way of handling this shortly after
merging this. Revert it and redo it in the next commit.
This reverts commit c2c157ebec.
a323dfae42 almost fixed subtitle tracks
disappearing when paused but it actually missed one part: the behavior
of demux_read_packet_async_until. It's a bit unintuitive, but for
subtitle streams, that function would only return the very first packet
regardless of whatever pts you pass to it. So the previous commit worked
on the very first subtitle, but not actually any of the others (oops).
This is because subtitle streams never marked as eager and thus never
actually read farther ahead. While the video is playing, this is OK, but
if we're paused and switching subtitle tracks then the stream should be
eagerly read. Luckily, the logic is already there in the function for
this. All we have to do add an extra argument to
demux_read_packet_async_until to force the stream to be read eagerly and
then it just works. Be sure to unset the eager flag when we're done.
Actually fixes the bug for real this time.
The default `z` of an overlay is 0, which is used by e.g. console.lua.
Having the idle logo at a `z` of 1000 means that it ends up above the
console (and anything that don't set a value higher then 1000).
It doesn't make sense for the idle logo to overshadow other things, so
put it at -1000 instead to prevent that.
It turns out that iOS doesn't actually need swift so this sdk check was
too strict and the build failed. Instead, only check this if we have
darwin and then make sure that the osdep subdir is only executed if
there are swift sources in the list. Fixes#12161.
Evidently I was wrong and mpv only actually warns once on deprecation
(playlist-pos nor display-fps did not and warned every time, but those
were outliers apparently). Someone complained so just hack it into
command_ctx for now.
Calling wl_display_disconnect closes the file descriptor, no need to
manually do it ourselves beforehand which causes a double close on the
fd.
Signed-off-by: Jack Mitchell <jack.mitchell@tuxable.co.uk>
0b4860248b added user-data which is
completely superior and makes this property obsolete. We've already had
one mpv release with the osc using user-data so drop this.
I removed the previous WHEEL_UP and WHEEL_DOWN bindings because they are
duplicate, and it appears that they were already bound to seek 10 before
7897f79217.
There was a discrepancy in what the keybind was advertised to do in the
manual, and what the comment in input.conf described it to be doing. It
makes very little sense to add a keybind that changes the default and
doesn't allow you to get back to the default. This keybind is much more
useful if it toggles between yes/force instead of no/force.
Copy and pasted from commit msg lint obviously, but I forgot to rename
it. Oops. Capitalize the name field while I'm at it (seems like all the
other workflows do it too).
When someone purely changes some documentation or something similar,
there's no point in having the whole CI build go off. This also leads to
the bot spamming a comment linking to artifacts. This is only useful if
actual source code changes (i.e. so users can test if need). So just add
a path filter to blacklist directories we don't want to consider. If all
changed files match those directories then the CI won't run.
Purely cosmetic, but this weird inconsistency bothered me. There's
techincally vd_lacv_params and ad_lavc_params too, but encode is special
and maybe shouldn't exist so we'll just leave that alone.
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.
With the previous commit, we can just access option values directly now
and avoid a lot of complication. Note that the mp_read_option_raw call
for edition requires calling mp_get_config_group since that option needs
to live in MPOpts.
Several parts of the code need to access options here. There's no point
in hiding it demux.c so just expose it in the demux.h header. This means
pulling it out of demux_internal and putting it in the demuxer struct
instead.
`demux->duration` is set to -1 on initialization, and some checks rely
on it being -1 when unknown. Before this commit, we set
`demux->duration` to 0 when unknown. This is incorrect and breaks rtsp
logic for disabling seeking outside of cached regions.
To fix these issues, initialize `total_duration` and `av_duration` at
-1. They're only changed if a real duration is detected, so in cases
where the duration is unknown, demux->duration is set to -1 correctly.
Fixes: e6afc53e7c ("demux_lavf: get total duration from track durations")
Apparently removing WS_CAPTION disables some window animations. Instead
adjust non-client area to not draw title bar.
Note that we do not account for difference in real border size and
invisible one, but seems to work correctly.
I don't think in fullscreen mode it makes sense to enable rounded corners.
We can add another option if someone needs it, but for now `window_corners`
affects only the window as one would expect.
With the addition of fractional scaling support, wl->scaling was
converted to a double. Some compositors (Plasma) can report values under
1 for fractional scaling, so this meant wl->scaling could be some
small fractional value. This is fine except that when using the legacy
code for drawing the mouse cursor (i.e. not the cursor-shape protocol),
it still uses the old integer scaling method in core wayland. The reason
for this is simply because fractionally scaling the mouse cursor surface
is nonsense and nobody even has cursor images for anything besides a
select few sizes anyways (32x32, 48x48, etc.). The existing integer
scaling sort of works but it's pretty bad too and you can get some weird
sizes anyway. This is why cursor-shape is preferred since it fixes this.
Anyways, since buffer scaling for the cursor only takes integers, there
could be truncation to 0 in the previously mentioned fractional scale
this. This naturally causes the compositor to send us an error and mpv
quits. The fix is to always make sure that the scale value used for the
cursor is at least 1. Anything less makes no sense. Fixes#12309.
There was assumption in the code that default settings are compatible
with dumb mode and are only one that should be used in this case.
Force bilinear if dumb mode is enabled.
ac725764ec originally added these to
prevent those profiles from having auto as a value. However the auto
value was removed in 53d032374d later. So
having these lines here no longer serves any purpose since the default
value for slang is NULL once again (vlang/alang were never needed here).
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.
e9e93b4dbe added a warning about writing
the same value to the playlist-pos property that in the future it would
stop restarting playback. Instead, you should use the
playlist-play-index command for that. Well go ahead and drop the old
deprecated behavior now and do what wm4 wanted this to do: just ignore
if the same value is written again.
drop-frame-count and vo-drop-frame-count are ancient and have no reason
to exist anymore. The other change is that support for writing to
display-fps has been removed, and the property is strictly read-only
now. 3a2dc8b22e is what deprecated it with
a warning to users, so we can remove it without much trouble.
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.
The osd support was originally written with the requirement that we have
actual frames getting delivered to the VO. This isn't always the case
though. If you force a window on a blank audio file for example, then
there will be no frame thus draw_frame did nothing. Since the previous
commit allows us to reliably detect this, we can rearrange the code
around a little bit to make this possible. A key change is to make the
osd_subsurface have wl->surface as the parent. This is seemingly
required otherwise the osd_surface buffers are never visible above the
empty video_surface when we have a black window. Also nuke the desync
call since it's completely pointless. Fixes#12429.
I didn't set file-local-options/hwdec because you have to store the
hwdec value to restore it after cropdetect anyway, and if the user
manually changes hwdec after cropdetect, the new value isn't reset when
changing file.
If you change file while cropdetect is active and you try to crop the
next video, it fails with "Already cropdetecting!". This is because
timers.detect_crop wasn't cleared correctly, only the timer variable
local to the loop was being set to nil.
The defaults were awful and horribly regressed many files while also not
fixing banding on files that actually needed it, sometimes even
*increasing* banding due to the low threshold.
Fixes: 12ffce0f22
See-Also: haasn/libplacebo@e1e43376d1
This probably makes `vo_gpu` tone mapping worse, or something, but who
cares. The status quo for a while now has been to use `vo_gpu_next` if
you care about HDR rendering at all.
See-Also: haasn/libplacebo@ec60dd156b
See-Also: haasn/libplacebo@0903cbd05d
This new filter is slightly sharper, and significantly faster, than
mitchell. It also tends to preserve detail better. All in all, there is
no reason not to use it by default, especially from a performance PoV.
(In vo_gpu_next, hermite is implemented efficiently using hardware
accelerated bilinear interpolation)
See-Also: https://code.videolan.org/videolan/libplacebo/-/commit/75b3947b2c07803456483ec6976c037bad91b5dd
It can hurt people's feelings to refer to scalers as "high quality" and
"low quality", when it is so subjective.
I decided to preserve the lanczos sections at least because it's mostly
talking about the difference between EWA Lanczos and Lanczos, which is
less controversial than the difference between, say, Lanczos and
Catmull.
Avoid generating too much audio after EOF.
Note: This often has no effect, because less audio is produced than
required.
Usually this comes to effect with the userspeed filter at high speed
(4x) and going back to 1x speed to remove the filter.
After the final input packet, the filter padded with silence to allow
one more iteration. That was not enough to process the final frames.
Continue padding the end of `input_buffer` with silence until the final
frames have been processed.
Implementation: Instead of padding when adding final samples, pad before
running WSOLA iteration. Count number of added silent frames and
remaining input frames for time keeping.
This changes the emitted pts values from the start of the search block
to the center of the search block. Change initial `output_time`
accordingly. Initial `search_block_index` is irrelevant, because it's
overwritten before the first iteration.
Using the `output_time` removes the rounding of `search_block_index`,
which also fixes the <20 microsecond gaps in timestamps between output
packets.
Rationale:
The variance in audio position was in the range `0..search-interval`.
With this change, the range is
(- search-interval / 2)..(search-interval / 2)`
which ensures lower maximum offset.
Target block can be anywhere in the previous search-block, varying by
`search-interval` while the filter is active. This resulted in constant
audio offset when returning to 1x playback speed.
- Move the search block to the target block to sync up exactly.
- Drop old frames to minimize input_buffer usage.
The internal time update function involved multiple problems:
- Time was updated after WSOLA iteration. The means speed was updated
one iteration later than it could be.
- The update functions caused spikes of too many or too few samples
advanced, leading to audio glitches on speed changes.
- The inconsistent updates made it very difficult to produce gapless
audio packets.
- The `output_time` update function involved complicated feedback:
`search_block_index` influenced how many frames from `input_buffer`
are retained, which influenced how much `output_time` is changed,
which influenced `search_block_index`.
With these changes:
- Time is updated before WSOLA iterations. Speed changes are effective
instantly.
- There are no spikes in playback speed during speed changes.
- No significant gaps are introduced in output packets.
- The time update function becomes (function calls omitted for brevity)
output_time += ola_hop_size * playback_rate
Functions received a `playback_rate` parameter to check how many samples
are needed before iteration. Internal state is only updated when the
iteration is actually run, so the speed is allowed to change until
enough data is received.
The first WSOLA iteration overlapped audio with whatever was in the
`wsola_output` buffer. This was either silence (if not run before), or
old frames (if switching to 1x and back to a different speed).
Track the state of the output buffer and memcpy the whole window for the
first iteration instead.
`output_time` is used to set the center of the search block. Init of
both `search_block_index` and `output_time` with 0 caused inconsistent
search block movement for the first iterations.
Initialize with `search_block_center_offset` for consistency with initial
`search_block_index`.
Fixes#12028
There was an additional issue that audio was always delayed by half the
configured search-interval. This was caused by the `out` buffer length
not being included in the delay calculation.
Notes:
- Every WSOLA iteration advances the input buffer by _some amount_, and
produces data in the output buffer always of size `ola_hop_size`.
- `mp_scaletempo2_fill_buffer` is always called with `ola_hop_size`
- Thus, the rendered frames are always cleared immediately after
processing, and `num_complete_frames` is 0 in the delay calculation.
- The factors contributing to delay are:
- the pending samples in the input buffer according to the search
block position, and
- the pending rendered samples in the output buffer (always empty in
practice).
The frame_delay code looked like that of the rubberband filter, which
might not work for scaletempo2. Sometimes a different amount of input
audio was consumed by scaletempo2 than expected. It may have been caused
by speed changes being a more dynamic process in scaletempo2. This can
be seen by where `playback_rate` is used in `run_one_wsola_iteration`:
`playback_rate` is only referenced after the iteration, when updating
the time and removing old data from buffers.
In scaletempo2, the playback speed is applied by changing the amount the
search block is moved. That apparently averages out correctly at
constant playback speed, but when the speed changes, the error in this
assumption probably spikes. This error accumulated across all speed
changes because of the persistent `frame_delay` value.
With the removal of the persistent `frame_delay`, there should be no way
for the audio to drift off. By deriving the delay from filter buffer
positions, and the buffers are filled only as much as needed, the delay
always stays within buffer bounds.
Very amusingly, the manual previously said "The rpi VO will be removed
in mpv 0.23.0." Obviously, this didn't happen. It looks like wm4 changed
his mind on this with 51fd8f6fe1, but
never updated the docs. What was the problem? Who knows but allegedly
there are people that use --vo=rpi (it's supposed to work at least).
Actually context_rpi is probably broken since wm4 changed fullscreen
handling in 59cdfe50b2 and no one ever
bothered to fix it after that commit. In fact, that's the last commit
that touched that particular file. Someone did actually fix vo_rpi after
that so that one probably works at least. Anyways, I wouldn't mind just
deleting all rpi stuff, but there's probably some people out there that
use it so whatever. Remove the outdated deprecated language in the
documentation and just accept that we support this unfortunately.
Defining MPV_CPLUGIN_DYNAMIC_SYM during plugin compilation will replace mpv_*
functions with function pointers. Those pointer will be initialized when
loading the plugin.
It is recommended to use this symbol table when targeting Windows. The loader
does not have notion of global symbols. Loading cplugin into mpv process will
not allow this plugin to call any of the symbols that may be available in
other modules. Instead cplugin has to link explicitly to specific PE binary,
libmpv-2.dll/mpv.exe or any other binary that may have linked mpv statically.
This limits portability of cplugin as it would need to be compiled separately
for each of target PE binary that includes mpv's symbols. Which in practice
is unrealictis, as we want one cplugin to be loaded without those restrictions.
Instead of linking to any PE binary, we create function pointer for all mpv's
exported symbols. For convinience names of entrypoints are redefined to those
pointer so no changes are required in cplugin source code, except defining
MPV_CPLUGIN_DYNAMIC_SYM. Those function pointer are exported to make them
available for mpv to init with correct values during runtime, before calling
`mpv_open_cplugin`.
Note that those pointer are decorated with `selectany` attribute, so no need
to worry about multiple definitions, linker will keep only single instance.
This fixes cplugin usability on Windows. Without any API changes, only
recompilation with -DMPV_CPLUGIN_DYNAMIC_SYM is needed.
The goal is to provide simple to understand quality/performance level
profiles for the users.
Instead of default and gpu-hq profile. There main profiles were added:
- fast: can run on any hardware
- default: balanced profile between quality and performance
- high-quality: out of the box high quality experience. Intended
mostly for dGPU.
Summary of three profiles, including default one:
[fast]
scale=bilinear
cscale=bilinear (implicit)
dscale=bilinear
dither=no
correct-downscaling=no
linear-downscaling=no
sigmoid-upscaling=no
hdr-compute-peak=no
[default] (implicit mpv defaults)
scale=lanczos
cscale=lanczos
dscale=mitchell
dither-depth=auto
correct-downscaling=yes
linear-downscaling=yes
sigmoid-upscaling=yes
hdr-compute-peak=yes
[high-quality] (inherits default options)
scale=ewa_lanczossharp
cscale=ewa_lanczossharp (implicit)
hdr-peak-percentile=99.995
hdr-contrast-recovery=0.30
allow-delayed-peak-detect=no
deband=yes
scaler-lut-size=8
296d40dc6f changed how the vo handled
redraw requests in order to fix a race condition that can occur with
pausing. However, there was a slight oversight because a redraw request
that occurred while the core was unlocked and the video was still
playing would still be kept true (previously, this was always cleared).
That redraw is essential if mpv is paused otherwise the old issue comes
back, but if the video is playing it's unnecessary since the next loop
around will simply draw whatever we needed. The extra redraw could cause
a frame drop for some people in certain instances, so the solution is to
simply always clear redraw requests if !in->paused. This eliminates the
extra redraw but still keeps it when pausing.
Fixes#12426 and fixes#11579.
After fixing the B and C params for bcspline, it ended up being the same
thing as bicubic. There's no reason to have two names for the same
filter, so remove bcspline and keep bicubic to match libplacebo.
All we have to do is set VO_CAP_ROTATE90 and then use buffer transform.
Maybe ideally we would rotate with vavpp instead if possible, but this
would be a convoluted mess that I'm not really interested in dealing
with right now.
No need for this since it's entirely redundant with just changing the
filter radius directly. In fact, that's the whole *point* of the filter
radius - it does not modify the filter, it modifies the scaling of the
window.
Of course, this does not work for non-resizable kernels. But, really,
who cares?
Replaced by mathematically and numerically precise constants, the result
of exact computation. Also updates the description to provide more
explanation and motivation.
We currently always scaled the window to the size of the configured
radius. However, this is wrong - we should instead be scaling it to the
size of the sharpened/blurred kernel. Since the window is always
stretched to the configured size of the filter, we can accomplish this
easily by just multiplying the blur value into the filter radius
directly, and then using that adjusted radius in place of `f.radius`
everywhere.
On a side note, this gives a very minor performance boost to
ewa_lanczossharp for no downside.
Upstream finally caved in to peer pressure and added this filter. Of
course, this also removes the fallback for people on older versions of
libplacebo, but people using mpv git master are probably using
libplacebo git master anyway. It's time to debloat this code.
And make it the default. In libplacebo, this uses internal heuristics to
pick a good size based on the actual ICC characteristics. This is
significantly less wasteful than always generating a 64x64x64 3DLUT (the
old status quo).
In vo_gpu, for simplicity, just default to 65x65x65. Note that this
provides slightly better accuracy than the old default of 64x64x64 for
technical reasons, and matches what libplacebo defaults to for typical
display profiles.
Upstream has moved from passing struct pl_icc_profile to directly
attaching a managed pl_icc_object, plus providing a new function
pl_icc_update to update the ICC profile object parameters (if needed).
To facilitate this move, pull our ICC params back out of pl_options and
update the target ICC object directly.
The original OML sync implementation (which is where this calculation
originally comes from) made now_monotonic and ust_mp_time unsigned. This
is fine except it has the assumption that now_monotonic is always
greater than ust. This actually isn't always the case. In wayland, I
observed instances where the reported timestamp is in the future. Of
course, it's a valid question to wonder if this even makes sense but
these UST values are essentially opaque black boxes to us anyways. It's
entirely plausible that the gpu is expecting the actual presentation of
the last swap to be a bit in the future, the compositor gets this and
reports this to us. So we'll consider such stats as valid. Note that
xorg doesn't have this problem because it's roughly one swap buffer call
behind because of how the event loop works (honestly something that
should be fixed).
Of course, the problem with the unsigned type here is that it overflows
on the subtraction so make it signed and allow the appropriate negative
value to happen if it does. Note that this will simply result in a small
addition to mp_time_us() which is exactly what we want here (timestamp
slightly in the future). Some small style changes included just because.
This option behaves the same as the builtin one, and if it's value
is anything other then recursive|lazy|ignore it will fall back on the
builtin one as a sort of "auto" mode. It defaults to that auto mode.
Adds support for adding directories to the playlist in addition to
files. The propertiy `directory-mode` controls if directories get added.
Recursive directory loading will get added in a later commit.
Directories get sorted after files to behave the same way mpv
behaves when it loads directories directly.
The GNOME Nautilus file manager supports browsing of dav:// and davs:// links only. Additionally, dav:// and davs:// are also types of webdav links. Therefore, adding an "or" operation to include support for dav:// and davs:// links.
Adds catmull_rom as an example for --scale in the user manual, alongside
a brief description of the filter.
catmull_rom was only exposed to users as an available filter through
--scale=help. However, catmull_rom is very often aliased as "Bicubic" in
other applications such as GIMP and VapourSynth, and is a relatively
popular resizing filter. The documentation lacked any description of
catmull_rom, outside of a brief mention of it in the --tscale section.
Packet duration is not necessarily related to the display time of the
subtitle. Use start/end_display_time fields as source of the timing.
Fixes subtitles with infinite duration that should be on screen until
next sub is displayed.
While this resolves limitations of lavc decoder crop, it also introduces
artifacts with some of the source files or hwdec.
Depending on chroma sampler it is possible to sample outside the decoder
crop area, pulling dirty pixels into the image. Some decoders left them
zeroed, not black. To fix that we would need specifc solution during
mapping of avframes.
As most of the files require the crop only in bottom/right area, the
AVCodecContext::apply_cropping works ok for those.
For all other cases that require more fancy cropping like 1440x1080+240+0
user can manually set `--vd-apply-cropping=no`.
Limitations of the lavc crop are explained here:
https://ffmpeg.org/doxygen/trunk/structAVCodecContext.html#a4745c7455c317272c4e139d6f369936c
Fixes: 826ce82cad
In the never ending quest of trying to satisfy every possible user
request for subtitle autoselection, I ended up redoing how
--subs-fallback-forced works. The old behavior had it as strictly a
fallback-type option when there were no lang matches, but now we can
make it an active part of compare_track and it works along with slang to
select the desired track. Since it's a three state option, the no option
still works to avoid selecting any forced subtitle tracks. The meaning
of always slightly changes to mean "only select forced subtitle tracks"
and yes remains essentially the same (no special priority given besides
the audio matching subtitle language case).
So strangely enough, estimated_vsync_interval is stored as a double but
nominal_vsync_interval is not and neither is the vsync_interval. Those
are stored as int64_t. This loss of precision can matter even in common
cases. For instance, take a typical 60 Hz monitor. Instead of 16666.6666
(repeating) being calculated as the vsync interval, you would get 16666
since the decimals are truncated. This is not really good at all and
affects the calculated speed values you get when using display sync. For
consistency and better precision, these should all be doubles just like
estimated_vsync_interval. Technically this means that we won't be able
to store as high of an integer value but such values would be absurdly
huge and never actually needed. Also estimated_vsync_interval already
can't handle such a case anyway.
Timestamps are converted from microsecond resolution timestamp, we don't
have more precision, so we have to account for that when comparing the
floating point values as them will slightly be off.
Fixes: #12327
Interrim solution, forwards compatible with new and backwards compatible
with old API. Eventually, we will want to discontinue the use of
deprecated pl_icc_params.save/load and pl_renderer_save/load, but that
requires minimum version bump.
Cropping by decoder has limitations with regards to aligment and hwdec.
It doesn't work to offset top left corner with hwdec and even with
software decoding it don't crop fully when resulting data would not be
aligned.
VO cropping is way more robust.
Setting `--video-crop=0x0+0+0` applies full frame crop, ignoring the
container one. Setting --video-crop=0 disables manual crop and restores
container one if it is available.
This makes it easier to apply crops without need to manually calc the
offset. I wanted for it to be top-left corner based, but maybe it was
not that good idea in retrospect.
Also rename scrw/scrh, since they don't refer to screen. It was copied
form m_geometry apply.
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.
Yet another bad idea. It turns out that there's already a sub-fix-timing
option which logic for this exact thing (overlaps/gaps) fixing. Also it
works better than this since it doesn't appear to artifically increase
sub duration either. Fixes#12327.
This reverts commit 725b631ec3.
mpv saves cache by default nowadays, but vo_gpu is pretty spammy and
saves a bunch of files per shader. If someone is using the non-XDG
config directory, this all gets dumped directly into ~/.mpv which isn't
so nice. Save it to a sub directory called "cache" instead (or
alternatively submit to your XDG overlords). For unfortunate reasons,
macOS uses XDG_CONFIG_HOME and has the same legacy fallback mechanism,
so this applies to it too.
We currently only allow specifying the Vulkan device to use by name. We
did this to avoid confusion around devices being enumerated in an
unpredictable order. However, there is a valid edge case where a system
may contain multiple devices of the same type - which means they will
have the same name, and so you can't control which one is used.
This change implements picking devices by UUID so that if names don't
work, you have some option available. As Vulkan 1.1 is a hard
requirement for libplacebo, we can just use UUIDs without conditional
checks.
Fixes#10898
In the previous change, I added the uuid files. In this change, we
check the libavutil version and if it's too old, we compile in our
local copy.
We have to change the include paths of the uuid code to find some other
libavutil headers, but nothing beyond that.
To avoid taking a dependency on ffmpeg 5.1 before we're ready (we need
a newer Ubuntu LTS release to drop ffmpeg 4.x support), ut not force us
to wait to add support for picking Vulkan devices by UUID, I'm copying
the uuid code from ffmpeg into mpv. It's one file with no private
dependencies, so it's easier to copy than to reimplement in any other
way.
Licence is LGPL so matches us.
We were over-enthusiastic when introducing --no-config into the
autocompletions. When autocompleting profiles, you actually need the
config, because that's where the profiles come from.
zsh is untested - I don't use it.
The old mplayer / zap style format is not fully standardized across
channel scanners, so autodetection may fail if the file name
does not indicate the delivery system.
While ZAP config files should contain strings in most fields,
their field number in the DVB-T / ISDBT case matches the number of fields
for VDR config files, and some channel list writers (namely, dvbv5-scan)
may insert "0" in unused string fields.
To disentangle such config files from real VDR config files,
add a check for the "INVERSION_" field which should always be filled.
dvb_get_channels is expected to append to an existing channel list.
For adapters supporting many delivery systems, a subsequent channel list
may turn up with a non-existent channel config, and the pointer
to the previously parsed channel list may be lost
(i.e. the list will be leaked and no channels detected).
Fix this by passing through the existing list (which may be NULL)
in case no new channels are found.
This is similar to DVB-T, but requires slightly different treatment
as there is no T/T2 differentiation.
Use a new channels.conf.isdbt file as channels config file.
Causes bad performance with interpolation because the changing hue angle
invalidates the mixing cache, as a result of libplacebo implementations
(specifically, the fact that this graph is drawn during the color
management process, instead of as a separate overlay).
Fix it by just hard-coding a particular, relatively interesting plane
(pi/4 approximately maps onto the red-blue axis).
Before this change, mpv used to get the total duration from
`avformat_find_stream_info` and used the per-track duration as a
fallback. This change reverses this order of preference.
The timestamps returned by `avformat_find_stream_info` are truncated or
rounded or floored (depending on the decoder) at the 6th decimal place.
For e.g. `avformat_find_stream_info` may return us a duration like
44.138667, whereas the duration we get from the per-track struct has a
higher degree of precision like 44.13866666666... and so on.
This caused various problems such as the playback_pts being a bigger
value than the duration, which would cause time-remaining to be a
negative value in some cases. Or cause you to reach a negative starting
timestamp when looping on an audio file with `gapless-audio`.
Moreover, we already skipped calling `avformat_find_stream_info` for
mp4, so we had already been utilizing this per-track fallback method for
finding the duration for mp4 files. It should be noted that while this
change is only required for audio-only formats, there is no harm in
doing this for videos as well.
There are way too many preexisting scripts that rely on this behavior
for video panning, like for example scripts that allow you to use mpv as
an image viewer. If this behavior is desired then it may be better to
add a new option for panning relative to the destination instead.
The restriction of video-pan-x/y being clamped to {-3, 3} also results
in the video being impossible to pan if it was zoomed in beyond a
certain degree.
This reverts commit 7d6f9e3739.
the osc currently allows for changing volume via scrolling when on top
of the volume icon. this does the same thing for the seekbar by allowing
seeking via scroll.
The default revert will always add 9 extra characters which means it
could go over the 72 character soft limit if the commit being reverted
has a long subject. We won't fuss about this so just shut up the lint in
this case.
`--vo=gpu-next` no longer uses this option, being replaced entirely by a
luminance-based approach internally. And even for `--vo=gpu`, the values
other than 'hybrid' are universally inferior in quality.
In the interest of gradually reducing the amount of option bloat here,
remove this mostly-pointless option.
fbe8f99194 made it possible for mpv to
autoselect forced subtitles again (it was bugged and would ignore
without slang being specified). Unfortunately, I forgot to take slang
into account here, so it would always autoselect the subtitles if they
are available. Fix this by checking both that it matches the lang and
that the previous track pick wasn't already matched (os_langs being true
is essentially equivalent to there not being any specified slang). This
way, it still respects the order of languages in your slang list.
Probably someone out there will be upset that forced subtitles aren't
always preferred regardless of the order, but that can be another option
for later I guess.
Prevents transient brightness spikes on scene transitions at the cost of
sometimes forcing an extra indirect pass (in particular, when
downscaling). But on GPUs powerful enough to run gpu-hq, the extra
indirect pass shouldn't matter too much. This option mostly exists for
weak iGPUs.
DVD/PGS are definitely not common, and ones that make use of the forced
subpictures flag even less so. For this button to be useful, the
subtitle track would need to be DVD or PGS, the track would need to make
use of the forced flag, the user would have to know what forced
subpictures are, and the user would need to have the preference of only
viewing forced subpictures on a subtitle. The function of this button is
too niche to be on the osc, if this behavior is desired the user can
simply bind a key in their input.conf. Moreover, this button only adds
confusion because there's no intuitive way to show what it does, and
there's no explanation for it anywhere in the manuals. osc real-estate
is quite limited as it is, so let's not waste any space on buttons with
highly questionable utility at best and confusing or bad UX at worst.
Gated behind option for backward compatibility.
Note that this will not magically start working with hwdec, as we do not
have crop detection for hwdec.
64959c450d solved the problems with resuming playback, so default to
--directory-mode=lazy because it's faster, especially on slow drives,
and results in smaller playlists.
Pick a smarter rect, limit it to right half of screen (to allow more
easily using it simultaneously with stats), and also auto-rotate through
the hue plane by default (wrapping once every 10 seconds of playback).
I briefly considered making it based on wallclock time instead of pts,
but this has the rather unfortunate downside of only being updated
sporadically as the user moves the mouse over OSC elements. (Of course,
we could also forcibly redraw the screen continously to avoid it, but
I'd rather not make such an invasive change for no real reason)
This design also allows you to pause and focus on (via framestepping)
individual parts of the hue graph that you're interested in.
Wheel being seek by default is very unintuitive and surprising to a lot
of users. It seems to be one of the things most consistently complained
about in the default UI. I change this on all of my devices, and so do
many others.
It's trivial for users who like the old behavior to change it back.
If --slang was set to some language and it matched the subtitle track,
then --no-subs-with-matching-audio would do nothing. Fix the logic by
doing the --no-subs-with-matching-audio step at the end to ensure that
it always "wins" over whatever --slang or --subs-fallback has set.
Clarify the docs a bit to make it clearer that this is the intended
behavior. Fixes fbe8f99194.
Since we no longer have the auto choice, this is always exactly equal to
the value of the option (sub-forced-events-only). Remove the property
and alias it.
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.
The README says Windows 7 and up, but the reality is that Windows
development is not done with 7 in mind and there are several known
issues that nobody is going to fix. Change this to 10 to reflect
reality. Also add a small paragraph explaining that we don't
intentionally break old systems, but don't expect them to always work.
Also change OSX to macOS.
- Move window scale to scaled resolution line
- add deinterlacing display
- rename "Gamma" to "Transfer"
- reorder to colormatrix/primaries/transfer as commonly used by
ffmpeg/ffprobe
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.
What was previously there is extremely complicated and really confusing.
Poorly named variables like "prefer_forced" that don't neccesarily have
anything to do with prefering forced tracks didn't help either. Try to
rewrite a few things to be saner. The idea is that after you loop
through the tracks, the special sub-specific options (like subs-fallback
and so on) should be handled and the track should be deselected if
appropriate. Another change is to remove the "prefered_forced" argument
in compare_track. This actually was both not neccessary and caused bad
behavior by always depriortizing forced tracks even when it didn't apply
(e.g. forced video tracks were never selected even though the flag
should simply be ignored for anything that's not a subtitle track).
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.
It turns out that the code to track redirects (playlists and
directories) never worked correctly, only the last redirect is
remembered and num_redirects is never greater than 1.
You can see this by doing quit-watch-later with the old watch later
system, before dbf244fd2f, on a m3u playlist of files and a m3u playlist
of directories. Only in the first case a redirect entry for the m3u file
is created, because in the second case the m3u redirect is replaced by
the directory one.
If you did mpv --directory-mode=lazy /foo it did create redirect entries
for all subdirectories e.g. /foo/bar, /foo/bar/baz, /foo/bar/baz/qux,
this made it seem like it worked correctly, but actually
/foo/bar/bar/qux was the only redirect entry and thus it was considered
as the first redirect, and mpv created redirect entries for each segment
of the first redirect only.
In the previous commit dbf244fd2f, rather than figuring out how to fix
the code to track redirects, and since creating redirect entries for
multiple redirects is overkill, I just used the new playlist-path
property which does the same thing but only for the last redirect.
By replacing the only other use of the old redirect code with
playlist-path, we can remove it.
35f43dfacb added a system to write resume files for redirects, i.e.
directories and playlists that mpv expands.
It creates a resume file for each redirect, and for the first redirect
only, it writes a resume file for each segment of its path, without even
converting it to an absolute path if it's relative. This is incomplete:
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
This doesn't save any redirect entry.
mpv --directory-mode=recursive 'Iron Maiden', then quit-watch-later on
Hallowed Be Thy Name
This saves a redirect entry for "Iron Maiden", but not for "1982 The
Number of the Beast". It doesn't save redirect entries for the
directories above "Iron Maiden" either because "Iron Maiden" isn't
converted to an absolute path.
In both of these cases mpv --directory-mode=lazy 'Iron Maiden' won't
resume from "Hallowed Be Thy Name" because "1982 The Number of the
Beast" isn't the first subdirectory and there is no redirect entry for
it.
503dada42f made mpv recursively expand subdirectories precisely to fix
this, and f266eadf1e added back an option not to expand them. But if we
fix how redirect entries are stored, we can make the superior
--directory-mode=lazy (because it's faster and doesn't result in massive
playlists) the default, and also ensure that mpv will resume playback
even when you quit-watch-later a file without redirects and then play
the directories above it.
Fix this by always creating redirect entries for all segments of the absolute
path of the file, so that both
mpv 'Iron Maiden/1982 The Number of the Beast/8 Hallowed Be Thy Name.mp3'
and
mpv --directory-mode=lazy 'Iron Maiden'
will create redirect entries for
/$USER
/$USER/music
/$USER/music/Iron Maiden
/$USER/music/Iron Maiden/1982 The Number of the Beast
making mpv --directory-mode=lazy "Iron Maiden" resume from
"Hallowed Be Thy Name".
This commit also makes mpv delete the redirect entries of parent
directories when resuming playback, because if for example you have a
playlist with all the songs in a discography:
1980 Iron Maiden/1 Prowler.mp3
1980 Iron Maiden/2 Remember Tomorrow.mp3
...
1981 Killers/1 The Ides of March.mp3
1981 Killers/2 Wrathchild.mp3
...
Now mpv will eventually create redirect entries for every album. If you
later decide to play the directories instead and there are 20 albums,
you would have to do mpv * 20 times to clear all the redirect entries.
200992f90c stopped linking mpv to
libXinerama so this library isn't needed anymore. However, we do use
xpresent so mention that instead since all the other needed xorg
libraries are listed as well.
Ideally, users should be using lavfi-complex instead of lavfi-bridge
for such a use case, however currently lavfi-complex doesn't support
hwdec. So we can allow filters with dynamic inputs to work with
lavfi-bridge, at the cost of them only being able to take in
only one input. This should probably be reverted when/if lavfi-complex
has hwdec, but for now this allows us to use libplacebo
as a video filter with hwdec in mpv again.
This ensures the spacing between forced-only sub toggle button and the
volume button matches the spacing between the volume and the fullscreen
button on bottombar/topbar layouts
Fixes: 945d7c1eda
Previously, we would have a button with empty string added to the layout
for non DVD/PGS subtitles. This would cause there to be an invisible
button present that would take up space and could still be clicked
despite being invisible when the current subtitle track was not DVD/PGS.
The idea was that the button would be invisible for regular subtitle
tracks, and be visible as "[ ]"/"[F]" for DVD/PGS subtitle tracks.
This commit modifies the bar and box layouts to only add this button if
the current subtitle track is DVD/PGS. This results in there no longer
being an invisible button, and also prevents it from taking up space.
The button is added to layout as before when the current subtitle track
is DVD/PGS, matching the same logic as before.
x11 and wayland had a lot of multimedia keys mapped that were missing
on windows.
Now the only ones they map that windows doesn't are `MP_KEY_WWW`,
`MP_KEY_ZOOMIN` and `MP_KEY_ZOOMOUT`, which apparently don't have any
equivalent ones on windows.
This actually fixes a bug that was present in this code even before the
new pl_options system, which is that `video_screenshot` would
permanently leave `peak_detect_params.allow_delayed` as false, until
something else forced options re-application due to options cache
change.
This may seem obvious in retrospect, but we need to explicitly account
for the case where the source format is supported by the VO, but not
a valid target format for the conversion filter. In that situation, we
would conclude that conversion was necessary, because we relied solely
on the conversion filter to identify acceptable target formats.
To avoid that, we should go through the VO's reported set of supported
formats and if the source format is on the list, ensure that format is
also on the target list.
This is mostly a no-op as most VOs do not report supported formats
(instead assuming that all formats decoders can produce are supported)
and in the case where it matters (vaapi), there is only one format that
the VO supports which the conversion filter does not (yuv444p).
The last piece in the puzzle for doing hardware conversions
automatically is ensuring we only consider valid target formats for the
conversion. Although it is unintuitive, some vaapi drivers can expose a
different set of formats for uploads vs for conversions, and that is
the case on the Intel hardware I have here.
Before this change, we would use the upload target list, and our
selection algorithm would pick a format that doesn't work for
conversions, causing everything to fail. Whoops.
Successfully obtaining the conversion target format list is a bit of a
convoluted process, with only parts of it encapsulated by ffmpeg.
Specifically, ffmpeg understands the concept of hardware configurations
that can affect the constraints of a device, but does not define what
configurations are - that is left up to the specific hwdevice type.
In the case of vaapi, we need to create a config for the video
processing endpoint, and use that when querying for constraints.
I decided to encapsulate creation of the config as part of the hwdec
init process, so that the constraint query can be down in the
hwtransfer code in an opaque way. I don't know if any other hardware
will need this capability, but if so, we'll be able to account for it.
Then, when we look at probing, instead of checking for what formats
are supported for transfers, we use the results of the constraint query
with the conversion config. And as that config doesn't depend on the
source format, we only need to do it once.
I'm currently not convinced that the way the output_chain is handled as
part of reconfiguration is correct. If there is an event requiring
reconfiguration, such as toggling the use of hwdec, we currently do not
ensure that the filter chain is fully drained first. This creates a
situation where the filter chain is invalidated while the autoconvert's
sub filter (that does the real work) still has a frame to process and
pass on.
As the autoconvert code calls mp_subfilter_drain_destroy(), it returns
early to allow for draining before destroying the subfilter, but that
means the subfilter is still present in its original configuration, and
no actually draining is done before the existing filters reinitialise
themselves.
This leads to a situation where, if a hardware scaling filter is being
used by autoconvert, that filter is still present and responds when
told to reinitialise. But it cannot successfully reinitialise if the
triggering event is disabling hw decoding, as the input frame to the
filter will now be a software frame, so reinit fails, leading to total
failure of the filter chain, which is a fatal error, and we exit.
I think this was never noticed before, because I think it's not
possible for the hwtransfer filter to be active in a situation where
you can dynamically change the state such that the input or output
formats of the output chain are invalidated.
eg: If the autoconverter is activated because of `--vf=format=vaapi`,
it is actually not possible to toggle hwdec off, as the explicit user
filter ensure the hwdec is always present and active.
So, my solution here is to destroy the sub filter, regardless of
whether it needs draining or not. We simply have no opportunity to
drain and reconfigure in the correct order, and we must consider the
remaining frame in the filter as a casualty of the toggling process.
I'm sure there is a more substantial rework of the output_chain
reconfiguration process that could ensure draining before
reconfiguration begins, but my ambitions do not currently extend that
far.
This has been a standing behaviour for a long time, but I noticed it
while implementing the hw->hw autoconvert functionality. Today, the
output_chain will reset the autoconvert state when any output_chain
filter sees the input format change. This is wasteful as it leads to
the image converter having to be reinitialised each time it happens,
so we should only do it when the actual "convert" filter sees the
input format change. It doesn't matter if one of the other filters in
the chain sees a change (although in practice, a format change will
basically always propagate down the chain, so they all see a change
at the same time).
The practical effect of the old behaviour was that a format change
would always lead to the image converter being rebuilt twice - once
after the "convert" filter sees the format change, and then again
after the "out" filter (the end of the chain) sees the change.
In this commit, we check which filter is seeing the change, and only
reset the autoconvert state for the "convert" filter itself.
Historically, we have not attempted to support hw->hw format conversion
in the autoconvert logic. If a user needed to do these kinds of
conversions, they needed to manually insert the hw format's conversion
filter manually (eg: scale_vaapi).
This was usually fine because the general rule is that any format
supported by the hardware can be used as well as any other. ie: You
would only need to do conversion if you have a specific goal in mind.
However, we now have two situations where we can find ourselves with a
hardware format being produced by a decoder that cannot be accepted by
a VO via hwdec-interop:
* dmabuf-wayland can only accept formats that the Wayland compositor
accepts. In the case of GNOME, it can only accept a handful of RGB
formats.
* When decoding via VAAPI on Intel hardware, some of the more unusual
video encodings (4:2:2, 10bit 4:4:4) lead to packed frame formats
which gpu-next cannot handle, causing rendering to fail.
In both these cases (at least when using VAAPI with dmabuf-wayland), if
we could detect the failure case and insert a `scale_vaapi` filter, we
could get successful output automatically. For `hwdec=drm`, there is
currently no conversion filter, so dmabuf-wayland is still out of luck
there.
The basic approach to implementing this is to detect the case where we
are evaluating a hardware format where the VO can accept the hardware
format itself, but may not accept the underlying sw format. In the
current code, we bypass autoconvert as soon as we see the hardware
format is compatible.
My first observation was that we actually have logic in autoconvert to
detect when the input sw format is not in the list of allowed sw
formats passed into the autoconverter. Unfortunately, we never populate
this list, and the way you would expect to do that is vo-query-format
returning sw format information, which it does not. We could define an
extended vo-query-format-2, but we'd still need to implement the
probing logic to fill it in.
On the other hand, we already have the probing logic in the hwupload
filter - and most recently I used that logic to implement conversion
on upload. So if we could leverage that, we could both detect when
hw->hw conversion is required, and pick the best target format.
This exercise is then primarily one of detecting when we are in this
case and letting that code run in a useful way. The hwupload filter is
a bit awkward to work with today, and so I refactored a bunch of the
set up code to actually make it more encapsulated. Now, instead of the
caller instantiating it and then triggering the probe, we probe on
creation and instantiate the correct underlying filter (hwupload vs
conversion) automatically.
--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.
We should account for ao queue when setting playback position on EOF,
previously we were using the pts value corresponding to the start of
the ao queue, rather than the currently playing audio.
This fixes time-remaining being a negative number when mpv seeks to EOF
while playback is paused.
So far all the keypad keys except for `0` and `,` mapped to the same
MP_KEY_* independent of numlock state, even though different key codes
are received.
Now all the alternative functions map to appropriate MP_KEY_* defines,
with missing ones added.
There's some cdecl / stdcall linking nonsense breaking the build
which I'm not inclined to debug this Sunday at all.
32-bit is not important anyway, so just disable it there.
On the plus side the new functional structure makes this very painless.
If someone wants to use the CI artifacts for day-to-day usage
or even for certain tests it can be useful to take screenshots
and use e.g. DShow (--disable-devices option), so enable those.
1fa6669bc0 misinterpreted the example and
changed the pixel value from 128 to 168 (thinking that it meant pixels
after scaling), but likely the original calculation was correct because
the line specifically says "of the source video". This is just confusing
not really useful information so instead change the example to a more
common resolution (1920x1080) and remove any references to the source
video resolution. Also mention video-pan-y while we're at it.
It makes it more usable to virtually move dst rect instead of scaled
src.
The issue with the latter is that it is affected by video-zoom
paramters. For example if we do `--video-pan-x=-0.5` in normal case it
will move video -50%, but if we apply video-zoom/scale the video will
float towards the middle in unintuitive way. Extreme case is when one do
--video-zoom-x=0.01, now it is impossible to move video unless you
specify huge video-pan-x value, but it is limited to [-3, 3]. So you
cannot do anything.
With this changes regardless of video scale/zoom, video-pan will keep
center of scaled video in one place.
It doesn't make sense to have zero here and it breaks, logic below.
Width was still campled to 1, but with broken offset.
This fixes things like video-scale-x=0
- uninit gl before the VO
- destroy EGL surface before context: reverse of the creation order.
I also checked other code which doesn't even call this and leaves
it up to eglTerminate, which frees everything anyway. But this
seems more correct since we're destroying the gbm surface afterwards.
- check against at EGL_NO_DISPLAY instead of 0: there is probably no
EGL implementation where this makes a difference, it is more correct
regardless
- remove pointless eglDestroyContext call
- check render_fd before close
The idea behind period_size is that it's the minimum amount of data
that your audio subsystem wants to fetch.
For PulseAudio, this is given by the minreq buffer attribute, which
is in bytes for all channels. Hence the divisions.
This change sets the device_buffer member of the ao struct for
the JACK ao to whatever value we read during init.
While JACK allows changing the audio buffer size on-the-fly
(you can do this for example through DBus), having it somehow
reconfigure the entire audio buffer logic of mpv that depends
on device_buffer in some way when that happens only leads to
audio dropout and weird code. device_buffer's role is mostly for
prebuffer from what I understand, which means that simply setting
it to its current value in the init function is fine.
mpv was taking focus when being started with "--window-minimized=yes". This change stops mpv from taking focus when this option is used.
Resolves: #9641
In addition to the patch, appropriate additions to the mpv.conf file
will of course be needed for this to work. For example on my system:
audio-device=oss//dev/dsp4
audio-spdif=ac3,dts,dts-hd,eac3,truehd
This has been tested using recent FreeBSD-13.1-stable, using external
surround processors (both a Trinnov Altitude 16 and an LG OLED that
supports Dolby Atmos, and connected with HDMI to an NVidia RTX 2070).
Author and tester: David G Lawrence <dg1007@dglawrence.com>
It's possible for systems to have multiple cards, and the first capable
card to not have a connected output. Skip such cards and continue
iterating until we find one with a connected output.
Without doing this, --fs --fs-screen=1 wouldn't actually end up on the
desired screen since the sizehint was never sent. Also check the
screen-name variants for an empty string as well so the option can
properly "undo" itself (not sure if this has any practical effect).
mpv mixes xinerama and randr usage together which gets kind of
confusing and is also pretty stupid. Xinerama is completely unneccesary
today since randr can do everything it can do and much more. Remove it.
This reworks a lot of the window/geometry handling stuff to be centered
completely around xrandr_display plus some other tweaks to the geometry
handling. An important concept is that current_icc_screen is changed
into current_screen and used more generously since it is useful for
things besides just icc profiles.
There really is no reason to not just hard require randr 1.4. xorg added
1.4 support in 2012 and someone somehow using an xorg server older than
that today surely has several other problems.
If we failed to create a gbm surface, we would call drm_egl_uninit
to free up any state we had allocated. However, we would segfault if we
tried to cleanup properties there were never initialized. Null checks
have been added to guard against this.
Before d208284, this was implicitly reset back to 0 at the start of
every update_options(). But we no longer explicitly reset par->params,
so we need to do it manually here for the hooks.
Fixes: https://github.com/mpv-player/mpv/issues/12203
It turns out this already exists for sd_ass and is being used there. We
can make use of this arbitrary threshold instead for overlapping
subtitle durations to avoid the weird flashing behavior with some
pgs subtitles.
With a backwards compatibility shim for older versions of libplacebo in
which we simply define the relevant subset of this struct ourselves and
initialize it to known-good values, to be able to continue using our
options assigning code.
It's worth pointing out that our use of scalers deviates from how
pl_options was intended to be used, as a consequence of backwards
compatibility with pre-308 versions of libplacebo. But this should work
fine in practice, since we don't care about serializing these custom
scalers correctly. Users can still override them using the built-in
pl_options scalers when loading custom scalers via --libplacebo-options.
(To be added in the next commit)
Under the current file loading logic, a video file and an external
audio track next to it will both be added to the playlist, which
most users don't wish to happen. Having an option that tells the
script to load only one type of files (video, audio, or image)
can avoid this problem. It may also come in handy for people who
have different types of files mixed in a folder but wish to consume
only one type of media at a time.
This was already correctly freed when acquiring a new profile, but never
freed on uninit. Fix by reparenting the profile onto `p`, which is what
vo_gpu also does.
There are a number of ways one can craft a playlist file that refers to
itself or cleverly goes around in a loop to other playlist files. There
is obviously no use for this, but mpv spins around forever trying to
load the files so you have to just SIGTERM/SIGKILL it. We can be smarter
about this and attempt to detect it. The condition for detecting this is
surprisingly simple: the filename of the first entry in the playlist
must match a previous playlist path we stored. If we get this, we can
then log an error and stop playback. If there is a "real" file loaded at
any point in time, then we know it's not an infinite loop and clear out
the saved playlist paths. Fixes#3967.
At least NetBSD ossaudio(3) right now has SNDCTL_DSP_SETPLAYVOL support
but does not support SNDCTL_DSP_HALT chocking at build time.
NFCI on platforms where oss audio output is supported.
libplacebo doesn't like it when the queue_params PTS is less than the
actual PTS of the frame for the first frame and skips mixing it during
interpolation. This can happen if you seek while paused because mpv will
always keep the vsync_offset value as if it was still playing. So in
some cases, this can be a negative value and thus the PTS will end up
decreasing and libplacebo interprets this frame as a first frame. This
skips mixing the frame and thus you get a black screen. To fix this
this, just realize that vsync timings are completely meaninglessly in
while paused. If you are not actively pushing frames, there's no reason
to care about vsync_offset. So just clear it and make it zero when the
VO's internal state is paused and we're trying to render a frame. Makes
libplacebo happy and fixes#11958.
It was actually always wrong, and no one ever noticed. This currently
returns the size of the entire display area and not one actual monitor.
Fix this by calling get_monitor_info and then doing the appropriate
subtractions. Checked by @CrendKing and fixes#12172.
Discovered by @christoph-heinrich in IRC.
09c701b797 added a fallback for headerless
m3u files. However, it requires that the bstr len be greater than 10.
This means that a m3u playlist with a single entry with a very short
filename (such as "test.flac") will not be recognized as a playlist
since the amount of data is too small. The reason for this restriction
is unexplained and really shouldn't matter given that the important
thing mpv should be doing is checking if the data is text. Instead,
loosen the check so that it only needs to be 2 or greater. This covers a
single byte filename and a line terminator.
Introduced by 1f8013ff3f. We try to save
the mpkey so it can be used in the modifier event that comes next if
appropriate and also clear it when needed. The problem is that the
condition for clearing is too strict and things like mismatched cases
and so on can make mpkey on the corresponding key release event not
match the saved mpkey even though in reality they were the same key.
Loosen the check by simply always clearing the saved mpkey as long as
there was some key found and the state is up. We don't handle multiple
keys at the same time anyways (they're interpreted in a sequence), so it
should be hopefully OK.
During initialization, the mpv window was not available and wayland
simply just reported nothing. But this can be a nuisance and there are
cases where having a values is better than nothing (vapoursynth). So if
current->output isn't available yet, fallback to find_output instead.
This is influenced by what is set by options like --screen and
--screen-name, but we'll consider that a feature not a bug.
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.
A bit of a long standing pain with scripting is that when opening a file
that gets interpreted as a playlist (like an m3u), the original path of
the file gets thrown away later. Workarounds basically consist of
getting the filename before mpv expands the path, but that's not really
reliable. Instead of throwing it away, save the original playlist path
by copying to the playlist entries when applicable (demuxer playlist and
the playlist option). Then expose these as properties: playlist-path for
the currently playing entry and playlist/N/playlist-path for each
specific entry. Closes#8508, #7605.
mpv has a generic method for getting the display resolution, so we can
save it in vf_vapoursynth without too much trouble. Unfortunately, the
resolution won't actually be available in many cases (like my own)
because the windowing backend doesn't actually know it yet. It looks
like at least windows always returns the default monitor (maybe we
should do something similar for x11 and wayland), so there's at least
some value. Of course, this still has a bunch of pitfalls like not being
able to cope with multi monitor setups at all but so does display_fps.
As an aside, the vapoursynth API this uses apparently requires R26 (an
ancient version anyway), so bump the build to compensate for this.
Fixes#11510
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.
XDestroyWindow() is called immediately after, which also unmaps window
if needed. according to the manpage:
> If the window specified by the w argument is mapped, it is unmapped
> automatically.
When printing the name of the video track on the OSC, mpv almost always
prefixes it with "unknown". This is referring to the language tag which
essentially nobody ever does for the video track since it doesn't make
any sense. Instead of putting unknown when there's no language, just
make it an empty string instead. "Unknown" confuses can confuse users
here and practically nobody would guess that it's referring to language.
We still will print the language for a video track in case someone out
there really does tag it, but that should be rare.
When playing a sparse video stream, the debug log gets hit with the
video EOF constantly since the audio is still playing. There's no
practical use for this so just do add some logic to only signal it once
if it is sparse.
There's an edge cause with gapless audio and pausing. Since, gapless
audio works by sending an EOF immediately, it's possible to pause on the
next file before audio actually finishes playing and thus the sound gets
cut off. The fix is to simply just always do an ao_drain if the ao is
about to set a pause on EOF and we still have audio playing.
Fixes#8898.
This is pretty obscure but if you screw around with the play-dir option
to essentially create a ping-pong loop; mpv will get hit by an assertion
error. What's happening here is that changing the play-dir always
requires a seek. This is handled in player/command along with the other
runtime option changes. However, queue_seek can actually clear the value
of mpctx->stop_play if the file is ending. So while loadfile is
terminating playback and the play-dir gets changed, the value of
mpctx->stop_play gets cleared because of seek. This then hits that
assertion later when mpv tries to finish the file.
The fix is to just add some weird logic to play-dir in player/command.
We have to be sure that mpctx->play_dir matches the new direction
immediately when we get the change so explictly set it here and don't
wait for it later. Secondly, keep the old value of mpctx->stop_play
before the seek and restore it afterwards. This ensures that termination
still happens cleanly and allows the ping-pong loop to work. Fixes#10782
When getting subtitles, sd_lavc checks if the current pts plus a small
offset (1e-6) is greater than the sub->pts as well as checking if the
pts is less than the sub->endpts. The problem with the endpts check is
that there are subtitles out there (pgs ones) that have overlapping
durations and thus you'll get a case where pts is greater than endpts
because a new subtitle shows up. However, the old subtitle is still
meant to be on the screen. This results in a flickering effect where the
subtitle flashes and then appears the next frame. The easy enough fix is
to just loosen the condition and remove the endpts check altogether.
That ensures that the subtitle remains selected for the entire duration.
Unsure if this possibly could regress some other kind of subtitle out
that that uses sd_lavc, but this does appear to fix a real issue with
pgs subtitles. Fixes#8202 and #10051.
Internal subtitles were not shown when switching between tracks while
mpv was paused. The reason for this is simply because the demuxer data
isn't available yet when the track switch happens. Fixing it is
basically just retrying until the packet is actually available when the
player is paused. Fixes#8311.
1df0a42a8c changed aspect-ratio from
floats to doubles, but forgot to change this function for
pretty-printing them as fractions for the video-aspect-override property
This specific option type is only used for the video aspect. The
underlying type was a float to represent the inputted value, but it's
actually not precise enough. When using something like 4:3, the values
of the incorrect digits are actually significant enough to make av_d2q
return a very funky numerator and denominator which is close to 4/3 but
not quite. This leads to some "off by one pixel" errors. Weirdly, mpv's
actual calculations for this were already being done as double, but then
converted to floats for this specific type. Just drop the conversion
step and leave it all as double which has the precision we need (i.e.
AVRational is now 4/3 for the this case). Fixes#8190.
983e8f0100 resulted in the correct
dimensions, but it was not actually right because vo_gpu_next still had
the src and dst rects the same. This just needs to work like how vo_gpu
does where the src is the image params and the dst is desired output. So
basically, just copy that code over here. Fixes#12108 and as a bonus,
overriding the aspect ratio now results in correct screenshots
(previously didn't work at now and then with the above commit it had
correct dimensions but still incorrect output).
The difference this makes is that the OS API will notice
when we underrun (as opposed to being fed silence).
Other AOs mostly seem to not do this because they've committed
to filling a buffer of a certain size no matter what, but I have
not observed any ill effects for AudioTrack in my testing.
This looks like a pretty bad bug but only became a problem
with the last commit that allows rates like 22.5kHz to pass through
directly instead of being resampled.
Using the width and height params directly doesn't actually work if PAR
is something other than 1. Instead, use mp_image_params_get_dsize and
calculate the correct dimensions which matches the vo_gpu behavior.
1 is not enough to prevent PL_QUEUE_MORE, because the pl_queue is
designed to always know the next frame (in addition to the current).
Before haasn/libplacebo@112bb886, this was was (wrongly) silently
omitted by the pl_queue code, but that fix exposed this.
While it's technically API misuse on mpv side, due to the mpv vo code
having its own internal queueing and timing control, it shouldn't
actually make any difference in practice (and likely, the error message
showing up is the only meaningful bug here - the issue is entirely
cosmetic).
Fixes: https://github.com/mpv-player/mpv/issues/12101
Configuration of filter parameters was moved from pl_filter_function (of
which the user had to make a copy) to pl_filter_config, with the
pl_filter_function remaining immutable.
Implement this new logic in a way that can reasonably exist side-by-side
with the old configuration API. Once we drop support for PL_API_VER
below 303, we can drastically simplify this code.
The win32 code already updates itself on dpi changes. However, it never
signalled mpv's core when this happened which meant that the
display-hidpi-scale property never changed. Simply send the
VO_EVENT_DPI event when appropriate. Fixes#12081.
Currently relative time parsing is buggy when any of the non-leading
units are non zero. For example, "-1:30" should result in -90 but
currently it results in -30 (as a result of `-60 + 30`).
Also reject timestamps where non-leading units are out of range. E.g.
"1:100" would be rejected, but "100" will still be accepted as 100
seconds.
In the same way that fallback in receive_frame() needs to be repeated
until we get a working decoder, we have to do the same thing in
reinit(). Calling force_fallback() only once can still yield a non
functional decoder.
The reason why we have these multiple paths which each require their
own fallback logic is that we can fail at different stages:
* hwdec init
* decoder init <- repeated fallback was missing here
* frame decoding
Fixes#12084
The manual currently says that if dscale is unset, --scale will be
applied. However, this only works at init time. If you change the dscale
filter to be empty later, vo_gpu will segfault and vo_gpu_next will
throw an error and refuse the changes. That's because when the option is
unset at runtime, the value becomes "" not NULL and the vo's never
accounted for this. Fixes#12031.
This is higher quality but comes with a slight performance hit,
especially for weaker iGPUs, so I don't want to enable it out of the box
even when --hdr-compute-peak=auto.
After second thought version.py does not do anything useful. Meson has
built-in function vcs_tag that mostly replicate what version.py did. For
the build time we can just use __DATE__ and __TIME__. Of course this
changes time string format a little, but in my opinion it looks nicer in
fact.
Also it will use local time, instead UTC. But I would argue that date
string is only informative for users to check how old the specific mpv
build is. It doesn't have to be precise, it weren't for years anyway
before recent change.
Get rid of the time during the while loop and just let this run forever
in case of a failure and also bump the timeout in meson to 60 seconds
since we know it is possible for msys to take a very long time on
occasion. That should be plenty of time for it to finish.
This only existed as essentially a workaround for meson's behavior and
to maintain compatibility with the waf build. Since waf put everything
in a generated subdirectory, we had to put make a subdirectory called
"generated" in the source for meson so stuff could go to the right
place. Well now we don't need to do that anymore. Move the meson.build
files around so they go in the appropriate place in the subdirectory of
the source tree and change the paths of the headers accordingly. A
couple of important things to note.
1. mpv.com now gets made in build/player/mpv.com (necessary because of
a meson limitation)
2. The macos icon generation path is shortened to
TOOLS/osxbundle/icon.icns.inc.
wireplumber uses the media role when the node is first created.
To have the property available at this point reliably we need to set it
directly when creating the stream/node.
This is yet another unfortunate side effect of the width % SLICE_W == 0
special case. While looping through these rectangles, the rc->x1 value
on the final loop can be greater than the actual total width. This will
cause a buffer overflow if using the mp_draw_sub_overlay API. 2 of the
current VOs that use that work around it by adjusting the values
returned, but the better fix is to correct what's actually given in the
rectangles so you can safely use the values. As for the fix, it's simply
ensuring that rc->x1 doesn't extend beyond p->w with a MPCLAMP.
Previously, the code would always naively add SLICE_W (256) to rc->x0
which would easily extend past the actual width in many cases. The
adjustments in vo_vaapi and vo_dmabuf_wayland are dropped and in theory
vo_direct3d should work now since we can just trust the values given to
us in the rectangles. How nice.
As the role property is interpreted by wireplumber it can only be
evaluated when creating the stream. The current, dynamic mechanism is
racy so revert it.
See: #11253Fixes: #12041
This reverts commit 535cd6f313.
On DragonFly and FreeBSD native evdev headers are not not be used
outside of base system. Linux-compatible headers are provided by
evdev-proto package but require extra flags. As evdev-proto lacks
pkg-config support use libwayland prefix as approximation.
meson.build:974:0: ERROR: C header 'linux/input-event-codes.h' not usable
- Use ctime() instead manual format string. Fixes 12-hour format (%I)
without AM/PM (%p) specified. It is 24-hours now, as it should be.
- Avoid naive datetime object.
- Fix timestamp type, it is float in Python.
- Remove dummy fallback branch.
- Use f-strings for readability.
- Always rebuild version.h if repository is dirty.
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.
Python 3.11 will be released soon as default Python package, and
actually python3.11 package already disappeared from the repository.
This reverts commit c637beb522.
The avpkt was created once on decoder init but destroyed each time the
filter was destroyed, this obviously can't work. Move the packet alloc
to the filter init function instead.
fixes: 4574dd5dc6
We already have a libmpv test, but it's really basic and barely does
anything. In an effort to hopefully prevent future breakage, lets expand
this to do more stuff. First of all, it simply tests setting a bunch of
properties/options. Secondly, it tries to load a file (the mpv icon that
we already have in the source tree). And then finally it tries the
lavfi-complex filter since this is a known special case where weird
things can happen.
The track during lavfi-complex can actually be NULL which meant that
ca4192e2df regressed lavfi-complex by
causing mpv to crash during runtime changes of the filter. Additionally,
it's possible for the decoder wrapper to also be NULL. check_framedrop
within write_video checks this, but check_for_hwdec_fallback does not.
Perhaps, it's impossible for this to happen, but we might as well add
the check here to be on the safe side since mp_decoder_wrapper_control
is not designed to handle a NULL.
reproduction steps: take any lossy WebP screenshot and check the colors
(or JPEG without libjpeg support, or AVIF with tag-colorspace=no)
fixes: 6d9e72cd89
We make the assumption that there is more buffer available
than indicated, this needs to be considered in this specific
location too as mp_image_crop understandably checks whether
we're about to do something unsafe.
minimal reproducer: mpv av://lavfi:testsrc -vf crop=320:239,format=yuv420p -o test.png
fixes#10469
Curiously, vaapi requiring libdl has always existed ever since support
was added to mpv (2827295703). After some
investigation in IRC from uau and JEEB, it was concluded that the libdl
requirement was blindly copied from the vdpau check above it. At the
time, the vdpau code actually used dlsym so it was needed. The check was
later dropped when waf support was added
(7e2edad8ef). However, the requirement in
vaapi lived on, and actually it was never needed. libva does use dl when
building its libraries unsurprisingly, but this isn't relevant to mpv in
any way. Just drop it.
Can significantly reduce build time, most of dependencies have fixed
versions, so they can be cached fully. Others will be incrementally
build.
Cache is saved on every run and restored from the newest one. Size is
limited to 500M (compressed) to keep cache save/restore fast. Clean
cached build is little over 100M, so we have a headroom as things will
grow. ccache will automatically evict least recently used entries.
It is unlikely that clean build will exceed the limit anytime soon, but
it is something to keep in mind, as we do not want to evict cache
entries from current build, so the cache size need to be set correctly.
If we see "C" in one of the language vars we check, don't treat it as a language tag.
Once we've checked everything, if we don't have any languages, but saw "C" anywhere, fall back on "en".
mpv has a convention of printing everything to stdout. The reasons for
this are pretty unclear and in certain situations rather unintuitive. It
leads to some bad behavior in fringe cases with encoding mode and isn't
the norm for programs so just adjust it so warnings and up are printed
to stderr. Fixes#8608.
2.1.0-beta3 is ancient. Disable unwinding in luajit, as it requires SEH
to be enabled in the image, but it is not on i686 target and it
crashes when luajit tries to use SEH.
In 1f8013ff3f, I mistakenly thought this
was only used for modifier presses way back in the commit it was
introduced in, but it actually also handles non-english keys/letters.
Instead of returning early, we should try xkb_keysym_to_utf8 first and
then return if that doesn't do anything so the modifier can then be
handled in the appropriate event. Fixes#12009.
This has always been a pet peeve of mine and in fact I named the option
in meson "egl-wayland" with the intention of finally doing this. We call
everything that's egl "egl-foo" internally except for wayland.
Remove waf entirely in favor of meson as the only supported build
system. Waf was officially deprecated in 0.36.0, and has not been
preferred over meson since 0.35.0.
We wanted to preserve the libplacebo v5.264.0 requirement for gpu_next
for this release, since this is the what most Linux distributions are shipping.
The VLC 3 <-> libplacebo v6 situation is an additional reason distros are not
likely to ship the newest libplacebo release soon.
This reverts commit b73d96776c.
Doing a pw_thread_loop_wait() without checking conditions is invalid.
The thread loop could be signalled for other reasons and in this case
the wait needs to continue.
PipeWire added such additional signaling in
commit 33be898130f0 ("thread-loop: signal when started").
This meant that for_each_sink would return before the callbacks have
fired and session_has_sink() would incorrectly return "false", failing
the initialization of ao_pipewire.
Fixes#11995
Make it clearer that you should be using --hwdec with this VO. Also make
some comments about the things that are required for this to work
correctly (i.e. working drivers/GPU and the right compositor).
Since this works by mpctx giving us a dummy image, we can be reasonably
be confident that when we receive a matching imgfmt with no underlying
hw_subfmt that this is simply force window from the player. Just allow
this to go through the usual wayland logic and skip the hwdec checking.
When we get the real image later, it will still error out on the
compositors that don't have proper support.
It's a bit of an edge case, but since we now allow the disabling of the
software fallback it's possible to have a situation where hwdec
completely fails and the mpv window is still lingering from the previous
item in the playlist. What needs to happen is simply that the vo_chain
should uninit itself and handle force_window if needed. In order to do
that, a new VDCTRL is added that checks vd_lavc if force_eof was set.
player/video will then start the uninit process if needed after getting
this.
There's an option that's supposed to stop mpv from falling back to
software decoding if hardware decoding fails. Except that it doesn't
work and can fallback to software decoding anyway. Correct this by
checking if all possible hwdec failed after the loop in
select_and_set_hwdec and that we have this option. If so, flag a bool to
force eof. In decode_frame afterwards, we then simply immediately return
an EOF.
When video width is not a multiple of slice size, the last slice will overflow. Fix this by adjusting the width of the last slice to fit within the video.
Fixes issue #10436
Currently, the osc will add a margin of (osc_height / 2) to the
deadzonesize for the window controls, the topbar and the bottombar,
i.e. when osc-deadzonesize=1, the osc will show up even if the cursor
is only hovering (osc_height / 2) pixels above or below it. This is not
what this option is supposed to do according to the manual, instead
osc-deadzonesize=1 should result in the osc only appearing when it is
directly hovered. The user can simply set osc-deadzonesize=0.9 or so if
such a margin is desired, instead make the option work as advertised by
removing this margin.
It should be noted that osc-layout=box does not share this behavior,
and it already works as advertised in the manual.
mpv already has a bunch of software scaling utils. Instead of forcing
every VO to implement this, we can just grab the frame and scale it in
software in one central place. Fixes#11968.
We should always be trying hardware screenshots (VOCTRL_SCREENSHOT and
VOCTRL_SCREENSHOT_WIN) before software ones. Rearrange all the logic
here to hopefully make this clearer. The mode is passed to add_osd
(renamed since it will also be used to add the osd) which will be used
more in the next commit.
Reading the config when we're just interested in the option list
(not sure why mpv does that anyway) only has the potential to mess
this process up when it prints errors or the user has funny options
like msg-level or log-file set, so avoid doing so.
In sum there were three issues:
1. nominal_peak_luminance is an output parameter, not input
2. mpv internally uses MP_REF_WHITE which we need to scale by
3. the value should be left at its default for SDR
Together with the last change this means mpv can sucessfully
take HDR screenshots with --screenshot-sw without resulting
in a brightly colored mess. Though note that zimg does not
perform proper tonemapping.
As a consequence:
- write_avif now respects tag-colorspace=no
- write_lavc additionally sets colorspace and chroma_location
(of no consequence for png or jpeg)
mpv has historically always treated the various tiled states in
xdg-shell as maximized (probably because it was easier). Well it turns
out that there are some tiling compositors (hyprland) that allow tiled
windows to maximize themselves. This can lead to some scenarios where
mpv ends up doing a maximize on hyprland which actually works since it's
not a no-op like on sway. Fix this by separating out the tiled state
from maximize. It works mostly the same, but the main difference is that
there's no request to tile yourself like there is with maximize. Should
fix#11954.
There's a lot of checks that are along the lines of !maximized &&
!minimized or vice versa. Make a locked_size boolean and store the
value of this in here to avoid writing long lines since the next commit
will add yet another condition to this.
There is an additional failure path I didn't account for in my previous
work. While I ensured that a late hwdec failure in receive_frame can be
recovered from by trying the next hwdec, there is a specific
combination where if an hwdec fails in receive_frame, and the next
hwdec is a full decoder (eg: v4l2m2m), and that also fails, we are left
with no decoder and so the entire decoding process ends and playback is
stopped.
Basically, we must keep re-attempting the fallback in receive_frame
until we get a valid decoder (software or hardware). This edge case
will rarely be encountered as there are only a couple of decoder based
hwdecs.
Fixes#11947
I don't know why we've been doing this wrong for so long or how I didn't
notice until now. Wayland specifically has an event for handling
modifiers. We even named it "keyboard_handle_modifiers" in the code.
What we should do is just get the modifier and save it after the xkb
state is updated. Then later if the user does something else (press
another key or clicks the mouse button), the saved modifier key is
applied. If you let go of the modifier at any point, the xkb will just
update its state again and we save a 0 again here (i.e. no modifier).
There is one bit of an edge case however. If a key is pressed BEFORE the
modifier, then we have to handle the mp_input_put_key in the modifier
event instead since the ordering is not guarenteed. What we do here is
keep track of the mpkey as well as the mpmod. However if we are unable
to find a matching mpkey and the key state is pressed down, assume it's
a modifery key that was pressed and don't update mpkey. That way
whenever the modifier event does happen, it can correctly handle this
and we know that the keys must be pressed down if we end up there in the
code path.
As another fun historical note, the xkb_keysym_to_utf8 line was actually
written by wm4 himself in 460ef9c7a4
nearly 10 years ago. As the commit shows, it was clearly intended to
handle modifiers (if lookupkey finds nothing, then try to find a mod
instead). Of course, this is extremely dated and wayland hasn't worked
like that in ages. This branch never actually did anything, and thus
we'll remove it here along with modifier lookup changes.
This solves bizarre issues with modifiers not working with random keys
while working fine with others (don't ask me why). Fixes#10286 and
fixes#11945.
When using lavfi-complex, no single track populates current_track for audio.
We work around this by iterating over the list of tracks and using the first
non-null language from a selected track. If multiple tracks are selected
(i.e. used by the filter) and have conflicting language tags, we'll ignore
them all and maintain the previous behavior (null).
828dd65ef8 started this and put it in the
most common place, but any resize mpv is doing should be accompanied by
that function call to correctly inform the compositor of the window
bounds. Since we also have to set VO_EVENT_RESIZE at the same time, it
makes sense to just put these in the same function. A slight thing to
note is that xdg_surface_set_window_geometry uses surface local
coordinates which means they are divided by the wl->scaling factor. If
possible, we should use surface local coordinates directly if available
(like in the toplevel config) to avoid potential rounding errors.
Otherwise, just calculate it out. The linked commit actually broke
some weston resizes in weird ways (window disappearing or completely
freezing). Don't ask me why and I didn't attempt to find out why either,
but with this it all appears to work normally again (the other
compositors don't appear to be any different, and they shouldn't be), so
we'll go with this since it fixes soemthing and it also is more
conceptually correct.
Libass commit f08f8ea5 (between 0.16 and 0.17) changed how PlayResX
affects some aspects of rendering.
The libass change fixes a VSFilter compatibility issue which existed
for about two decades, and there are no libass plans to support the
previous behavior, so ultimately we have to adjust the mpv code, and
we can't guarantee to restore the old behavior in all cases.
Starting at this commit, vector drawing coords, font spacing, border
and shadow widths are all affected by PlayResX (specifically, by
the aspect), while previously they were unaffected by PlayResX.
This changed converted sub border and shadow widths in mpv, because
ffmpeg generates the ass with fixed PlayResX of 384 (aspect of 4:3),
and with libass 0.17, if this doesn't match the display aspect, then
borders and shadow were too wide - because most clips aspect is more
than 4:3.
The fact that ffmpeg uses fixed PlayResX of 384 could be considered
an issue, but for now we have no control over it, and ffmpeg doesn't
have the video resolution when it converts an srt source to ass.
So here we adjust PlayResX accordingly so that border/shadows are
now rendered with correct width.
However, regardless of that commit, changing PlayResX also affects
the margin value, so to compensate, we adjust sub-margins-x too.
According to libass devs, this should cover basic srt-to-ass
conversion by ffmpeg to work correctly with libass 0.17.
However, there could be srt extensions which use more complex ass,
and/or ffmpeg conversion of other sub formats (such as aribb24,
aribcaption and movtext), where more things need adjustments.
As of now we don't know what these are, and so we don't really know
what else might remain broken or get broken.
dbc5d7b7db seems to have originally
introduced this behavior. At the time, wm4 simply reconfigured ass on
every frame in order to accommodate runtime changes in sub options. This
certainly works, but these libass API calls are not free and there is at
least one known performance regression due to a change in libass*.
Regardless of whether or not the libass change is good/bad, there is no
need for mpv to constantly reconfigure this. When wm4 made that commit,
there was no notification mechanism for options changing that could
easily be used so he didn't really have any other choice. But it's
nearly 10 years later now and internally we have all the necessary
pieces to only configure ass again when we need to: on option changes or
resizes. So go ahead and implement that in this commit which simply uses
the already existing SD_CTRL_UPDATE_OPTS and compares osd_res sizes to
determine whether or not an ass configure is needed.
*: https://github.com/libass/libass/issues/698
4502522a7a implemented cache directories
but only on linux which meant other OSes continued to save this stuff in
their config directory. Since we turned on cache by default, people are
getting cache files in there which is understandably causing some
confusion. Let's go ahead and implement a separate cache directory for
windows since there seems to be some established conventions for this
already. For people using the portable_path, the cache is saved in a
subdirectory within the portable_path since the idea is for that to be
completely self contained.
To remain consistent with our belief that `auto-safe` should be the
recommended mode when turning on hw decoding, let's remap `yes` from
`auto` to `auto-safe`.
We have supported `hwdec=drm` for some time now, and on devices where
this method is present, it is the preferred, and only, method
available. Combine that with the fact that software decoding on
embedded devices will not turn out well, and it's clear that we should
put `drm` and `drm-copy` on the `auto-safe` list to maximise usability
in simple configurations.
It has been odd that ctrl+h toggles `auto` for hwdecs even though we
always recommend people start with `auto-safe`, and `auto` will attempt
various hwdecs that can fail so badly we can't fall back to software
decoding.
With the change to more exhaustively attempt to use hwdecs, it is now
easier to get into situations where these fragile hwdecs will get
attempted in basic scenarios, like pressing ctrl+h.
So it is high time to default to `auto-safe`.
Today, if hwdec initialisation succeeds, we move on to attempting
decoding, and if decoding fails, we enter a fallback path that will
only do software decoding.
This is suboptimal because some hwdecs and codec combinations can
pass hwdec init, but then fail at hwaccel init, or even frame decoding.
In these situations, we will never attempt other hwdecs in the `auto`
or manually specified lists which might work.
One good example is someone tries to use `vulkan,auto` and tries to
play av1 content. The vulkan decoding will fail at hwaccel init time,
and then fallback to software instead of going through the auto list
which would allow vaapi, nvdec, etc to play the file.
Instead, let's not give up immediately, and try the next hwdec after
a failure, just like we do if hwdec init fails.
The key part of this change is to keep track of the hwdecs we have
tried, so that each time we run through hwdec selection, we don't try
the same one over and over again. If we really get through the whole
list with no success, we will then fall back to software decoding.
Fixes#11865
This was never implemented so in cases where the compositor didn't have
support for the underlying format, the window would just be black and
quite unhelpful. Well it turns out that fixing this is actually really
easy because mpv has reconfig2 which returns the entire mp_image on
every reconfig. We can just use that mp_image to try and obtain the
format and modifier pair and then use that to check against what we know
the compositor supports. If there are any problems, error out
gracefully. Some code duplication with the vaapi/drmprime importers, but
it's probably better to keep these separate. Fixes#11198 and fixes#11664
It makes more sense as an option at this point. Also libdrm is not
optional at all. You have to get a drm format and modifier for this to
even work (the VO will just fail without DRM). Just hard require it and
remove the guards. vaapi can remain optional.
6a365b258a broke deleting redirect entries for resuming playback. If you
do mpv dir1 dir2, quit-watch-later on a file in dir1, then later
quit-watch-later on a file in dir2, mpv dir1 dir2 would not resume from
dir2 because the redirect entry for dir1 is never deleted.
Fix this by deleting watch later config files for directory/playlist
entries.
mpv has never used this because we never really seemed to need it, but
it actually has a purpose. This informs the compositor of the actual
dimensions of the mpv window and avoids errors with sizes not matching
(particularly with weston). It's a better way to fix the "maximizing
causing an error on weston" issue since it also works for dmabuf-wayland
(which always had this problem).
The original reason for this commit was to prevent a compositor error on
weston when going into the maximized state. The configured dimensions of
mpv didn't match its actual size and Weston is super strict about this
so it threw a compositor error which is fatal. It only happened in
opengl and this seemed like an OK workaround, so I went with this.
However, there's actually a far easier way to solve this problem and we
don't need this anymore. This has the benefit of avoiding a harmless
warning message that appears with gpu-next on opengl. The next commit is
the proper solution. Closes#10324.
This reverts commit 661b5542de.
The implementation was copied from vo_gpu/vo_gpu_next but fundamentally
it doesn't make sense for this VO. Hardware decoding is not optional in
vo_dmabuf_wayland. We should be sure to request and load all supported
formats in the preinit and fail if there are any problems. There should
be no functional change from before, but it's more conceptually correct
this way.
Essentially the same as d1d2370d07 except
for clear_rgba_overlay. From some empirical testing, the s->x1 value is
either 0 or SLICE_W (256). In the case where it is 256 and s->x0 is 0,
then it writes memory. For most slices, this is fine. However for the
very last slice in the loop, it is possible for the width here to exceed
the total width of the line (p->w). If that occurs, the memset triggers
a buffer overflow. This last case needs to be guarded in the same way as
the previously mentioned commit (total width - SLICE_W * x) and with
MPMIN in case s->x1 is 0 here to preserve the old behavior. It's unknown
if anything other than dmabuf-wayland can possibly hit this, but it's
definitely a problem within mp_draw_sub_overlay itself.
This adds osd support via shm buffers using a similar approach that the
normal buffers do, but it differs in a few key areas. One thing to note
is that sway and weston actually handle this extremely differently which
required all the abstractions here. In particular, weston does not cope
well with destroying the wl_buffer from shm outside of the release
handler at all (i.e. it segfaults). The workaround here is to simply
attach a NULL to the osd surface and do a surface commit before we
destroy the buffers. This is reasonable enough and seems to work well
although it's pretty weird. Sway is more straightforward although it
actually releases the osd buffer when the window goes out of sight.
Also, I found that it doesn't always release every buffer before you
close it unlike weston seems to do which is part of the reason all this
bookkeeping is required. I don't know if there's any other compositor
out there that can possibly handle vo_dmabuf_wayland right now, but
suffering through these two is good enough for now I think.
Otherwise, we could fail and skip to uninit without initalizing this
which then will segfault because the list is null and accessed while
trying to destroy buffers.
It's entirely pointless. Not having viewport is already a fatal error
for this VO as it cannot possibly work without that protocol. Just drop
all these redundant if's.
make sure that fwrite is error checked. and if any data was still
remaining on the buffer, it will be flushed - and errors checked - via
the fclose() call below.
mpv already guesses when the window is hidden so plugging in a proper
event that actually tells us this is really trivial. Note that there's
some redundancy with setting wl->hidden in a few spots, but nothing can
really be done about that as long as the crappy hack is still in place.
This protocol no longer requires us to draw a separate cursor surface
and all of that horrible stuff. We can just ask the compositor for the
default cursor instead since that's literally all mpv cares about.
In case there are no packets from demuxer we cannot send EAGAIN, because
we will not proceed and get stuck with one frame in queue and never
output it. Just respect avcodec_receive_frame ret code and act
accordingly. The only case to care about is EOF when we have to drain
already queued frames.
Fixes playback of 1-2 frame videos.
It can happen during initialization and of course nothing good will
happen if we let this go through (i.e. segfault). Return and wait for
geometry to finish setting up in the wayland stuff before doing the
initial resize.
Very dumb. I can't remember if it was always like this or if I broke it
at some point, but clearly each wl_output should just be freed in
remove_output. Freeing it if it happens to be wl->current_output only
works for that one monitor, so remove that whole line. This has to
happen before we close the wayland connection so reorder the uninit a
little bit.
Currently, mpv immediately deletes the watch_later file after an attempt
at playing the file is made. This is not really ideal because the file
may fail to load for a variety of reasons (including not even existing),
but the state is cleared anyway unconditionally. Instead, just wait
until after playback is successfully initialized before deleting it.
This way silly mistakes like forgetting to mount the drive doesn't
result in deleting your watch_later data. Fixes#3427.
the reason for checking `EBADF|EINVAL` specifically is unknown. but it's
clearly not working as intended since it can cause issues like #11795.
instead of checking for "bad errors" check for known "good errors" where
we might not want to break out. this includes:
* EINTR: which can happen if read() is interrupted by some signal.
* EAGAIN: which happens if a non-blocking fd would block. `tty_in` is
_not_ non-blocking, so EAGAIN should never occur here. but it's added
just in case that changes in the future.
Fixes: https://github.com/mpv-player/mpv/issues/11795
Closes: https://github.com/mpv-player/mpv/pull/11805
d3cef97ad3 changed the way the command
line was parsed and syntax like "--foo value" stopped being considered
valid. This old script still was using the old syntax and thus was
broken. Update it to "--msg-level=ffmpeg=v" which is the recommended
syntax. Fixes#11892.
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
--no-config should prevent loading user files of any type: configs,
cache, etc. For cache files, this case wasn't properly handled and it
was assumed they would always get something. vo_gpu's shader cache
actually already handles this, so it was left untouched. In theory,
demuxer cache should never have this issue because saving it to disk is
disabled by default (and likely that will never change), but go ahead
and change it for consistency's sake. Fixes some segfaults with
--no-config and various combinations of settings (particularly
--vo=gpu-next).
4502522a7a changed the way mpv handled and
saved cached files. In particular, it made a separate boolean option for
actually enabling cache and left the *-dir options as purely just a path
(i.e. having a dir set didn't mean you save cache). This technically
regressed people's configs, so let's just turn the cache on by default.
Linux users already expect random stuff in ~/.cache and well everyone
else can just live with some files possibly appearing in their config
directory.
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).
We used to sort the playlist with playlist-move after every loadfile.
Instead, append all files in order and call playlist-move once to move
the only entry we don't control the position of.
Don't fetch every playlist item separately, reuse native property.
We used to pick up on new files added to the directory, but only when
playing an entry at the edge of the playlist due to an early return.
New files are now added to the playlist on every file change.
This still works as expected and doesn't load duplicate files on
shuffled playlists or playlists with files manually added after autoload
33% faster on average for my test directory with 1371 files.
Notes:
- converts the (image) write() api to filenames, because using avio
with FILE* is a pain.
- adds more debug logs for screenshots.
build: rename av1 dependency to avif_muxer
wscript: unify lavf dependency with meson
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.
Today, the only way to make mpv consider multiple hwdecs and pick the
first one that works is to use one of the `auto` modes. But the list
that is considered in those cases is hard-coded. If the user wants to
provide their own list, they are out of luck.
And I think that there is now a significant reason to support this -
the new Vulkan hwdec is definitely not ready to be in the auto list,
but if you want to use it by default, it will not work with many codecs
that are normally hardware decodable (only h.264, hevc and av1 if you
are very lucky). Everything else will fall back to software decoding.
Instead, what you really want to say is: use Vulkan for whatever it
supports, and fall back to my old hwdec for everything else.
One side-effect of this implementation is that you can freely mix
hwdec names and special values like `auto` and `no`. The behaviour will
be correct, so I didn't try and prohibit any combinations. However,
some combinations will be silly - eg: sticking any further values after
`no` will result in them being ignored. On the other hand, a
combination like `vulkan,auto` could be very useful as that will use
Vulkan if possible, and if not, run the normal auto routine.
Fixes#11797
first of all, POLLERR is supposed to be ignored in `.events` and only
returned in `.revents`.
secondly select()'s exceptfds does not have a 1:1 correspondence with
POLLERR. thankfully, the only caller of this function (in terminal-unix)
never set the POLLERR flag so the errorfds were unused anyways.
so go ahead and remove it entirely instead of pretending we can emulate
something that's not possible.
this changes mp_image_new_ref() to handle allocation failure itself
instead of doing it at its many call-sites (some of which never checked
for failure at all).
also remove MP_HANDLE_OOM() from the call sites since this is not
necessary anymore.
not all the call-sites have been touched, since some of the caller might
be relying on `mp_image_new_ref(NULL)` returning NULL.
Fixes: https://github.com/mpv-player/mpv/issues/11840
in the first iteration, *out will be null and thus the steal and the
strdup both sets the parent to NULL - leaking the allocation later on
(caught via LeakSanitizer).
let append_lang() take care of setting the parent instead.
when vo_drm_init() fails inside of preinit(), uninit() will be called as
part of cleanup with vo->drm being NULL and thus `drm->fd` would lead to
null dereference.
and since vo_drm_uninit() closes drm->fd, destroy_framebuffer() ends up
using a closed fd.
according to the drm-gem manpage [0]:
> If you close the DRM file-descriptor, all open dumb-buffers are
> automatically destroyed.
so remove the destroy_framebuffer() loop entirely, which fixes both the
issues.
[0]: https://www.systutorials.com/docs/linux/man/7-drm-gem/
I originally left `drmprime_overlay` as higher priority because
`drmprime` was new, and because I didn't have any hardware where both
worked (only one or the other) so I couldn't compare relative
performance, and if only one worked, the priority didn't matter.
But with time and more usage, we've reached a point where we can say we
would recommend using `drmprime` in situations where both work, and
we've also been able to identify hardware where both do indeed work and
it seems that `drmprime` is more reliable.
So, let's flip them.
Now that Debian 12 is release bump the minium required version to what
is provided in Ubuntu Jammy (22.04).
The same as has been done for the wayland dependencies.
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Instead of brute forcing the name until it is set, without any error
checking and expecting it would start to work, fallback to client name
if initial request fails.
Fixes player going into infinite loop with very long title names. The
API rejects unreasonably long names, which make sense.
As for alleged "weird race condition in the IAudioSessionControl itself"
I cannot comment. It works on my end and even if it fails, it is not a
critical error or even something that we should care about... and
obviously not hang the whole player for that.
Fixes: #11803
If demux_open_lavf fails between calling avformat_alloc_context() and
assigning the context to priv->avfc, it will never be properly freed.
Fixes#11793.
It was done once before but later reverted for testing reasons. This
time it's permanent though since I can test this VO on ARM and with an
up to date system.
When using a display-* video-sync mode, it is possible for buffers with
a matching id to already have an image associated with them (i.e. the
compositor hasn't released it yet). Previously, it was thought that we
could just unref, return null, and make a new buffer but this eventually
leads to a fatal error that originates from libwayland itself which
stops playback. Admittedly, the reason for the error is a bit nebulous
but likely it seems to be some kind of mismatch between dmabuf params
and the associated image with the buffer.
However, we can simplify this process greatly. Instead when the
previously mentioned edge case happens, the old image can simply be
freed and we give the buffer the new image. This saves creating a new
buffer and also avoids that nasty libwayland error. A nice win-win all
around. Fixes#11773.
vo_dmabuf_wayland has a pool of wl_buffers that it cycles through when
drawing frame. There needs to be at least some minimum number otherwise
a flickering artifact occurs where old frames are mistakenly repeated.
When using display-resample and other similar modes, it seems more
buffers are required (more drawing happens so it makes sense) and the
current minimum of 8 isn't good enough. Let's just bump this to 15. It's
also a random ad hoc number, but as far as I know there's not really a
way to predict how many buffers a random video may need. From testing,
it works fine and overall 15 is still a tiny amount of objects to create
considering the lifetime of a video, so we'll just go with this.
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.
In data_offer_actions, it's possible to get the
WL_DATA_DEVICE_MANAGER_DND_ACTION_NONE action which would set
wl->dnd_action to DND_APPEND (did nothing in practice) but also log a
message which is confusing and misleading. Instead, just ignore and
don't do anything when we get this case.
To avoid building against stale version of dependencies. In particular
libplacebo is moving target and as we can see the build has been broken
few times recently, so let the CI validate it for us.
The time to build everything is under 30 minutes, which is acceptable in
my opinion, not much longer than macos build.
It is worth adding this example because it has been asked multiple times
in the issue tracker and the IRC channel.
string.find() is used because it's 20 times faster than string.match().
519e56f caused an attempt to get the language even if the file name
didn't start with the movie title. However, detecting a language when
fuzz >= 1 or the language is known, caused prio to be non-zero which
caused the file to be included regardless of its name. This shouldn't be
the behavior when sub-auto != all.
Now all the prio updates that depend on lang will only happen if the
file in question starts with the movie name. Since language was never
detected before if this wasn't true, the behavior should be the same as
before 519e56f when sub-auto != all.
Closes: #11749
We're moving to using timeline semaphores for synchronisation between
cuda and vulkan. It's only required with libplacebo-next right now,
but eventually our baseline libplacebo requirement will increase, so we
will need new enough nvidia headers that include the necessary
declarations.
This is not technically necessary, because we never touch the fd again
after passing to cuda, but having it there could lead to future code
accidentally using it.
All hwdecs should respect the probing flag and demote their lgoging to
verbose level, so that initialisation failures during probing do not
spam the user. I forgot to do this for the Vulkan hwdec.
The dmabuf-wayland vo has a stub ra implementation that doesn't
have a swapchain. That means that it's currently not safe to call
ra_vk_ctx_get on that ra_ctx, but it must be safe to call on all ra
implementations as this is how we discover if it is a vulkan ra.
This hasn't been an issue before because no Vulkan code paths would be
triggered when using dmabuf-wayland, but with the new vulkan hwdec, it
becomes possible to trigger when hwdecs are probed.
The libplacebo sync abstraction is deprecated and we should be using
the more explicit Vulkan semaphore helpers instead. This means that
more of the book keeping moves to our side, but it's not too bad.
There are two main things going on here:
1. After a lot of back and forth, I decided to write the new code with
timeline semaphores to streamline things, and that also means all
the variables are separate - which makes the #ifdefs easier to read.
Which is important because:
2. While pl_sync owned the exported fd/handle, pl_vulkan_sem does not,
so we are responsible for managing them. That means reversing the
previous logic - we now can pass an original fd to CUDA and never
think about it again, while we have to clean up a Win32 Handle
because CUDA will not take ownership.
Finding the prefix in the key is not enough, the key has to actually
start with the prefix. Otherwise a key like `uosc-font_scale` will not
only match the `uosc-` prefix, but also the `osc-` prefix, resulting
in a logged warning about `-font_scale` being an unknown key.
AV1 support in Vulkan is extremely bleeding edge - to the point that
the extension is not present in official Khronos releases, but it has
a reserved identifier and we can look it up with a string literal for
now.
This will be skipped and ignored if the driver doesn't support it, so
it's safe if/when the name changes later (it'll just never be activated
in that case).
I originally wrote this trying to avoid doing an explicit version check
on the headers, but it just makes things more confusing, and the
requirements harder to understand.
So, Vulkan interop now takes a dependency on the header release where
they finalised the video decode headers. VK_EXT_descriptor_buffer was
added in 1.3.235, so that's covered as well.
Along the way I fixed a bug in the waf build where it was depending
on libplacebo-next instead of libplacebo-decode.
ffmpeg was previously allocating images for frames as the code size,
rather than the presentation one (1088 vs 1080 in the most common
example). Using the coded size when wrapping images for libplacebo
resulted in incorrect scaling from 1088 -> 1080, but even using the
presentation size wasn't perfect, as discussed in the original
commit.
However, ffmpeg has now been updated to use the presentation size for
the frame images, after discussions that concluded this must be done
because there is no way for a frame consumer to fix the dimensions
without copying the frame.
With that ffmpeg change, we can just use the normal layout information
like all the other hwdecs.
Although we can support vulkan multiplane images, cuda lacks any such
support, and so cannot natively import such images for interop. It's
possible that we can do separate exports for each plane in the image
and have it work, but for now, we can selectively disable multiplane
when we know that we'll be consuming cuda frames.
As a reminder, even though cuda is the frame source, interop is one way
so the vulkan images have to be imported to cuda before we copy the
frame contents over.
This logic here is slightly more complex than I'd like but you can't
just set the flag blindly, as it will cause hwframes ctx creation to
fail if the format is packed or if it's planar rgb. Oh well.
Vulkan hwdec interop with the ffmpeg 6.1 vulkan code will require
additional features beyond those activated by libplacebo by default.
Enabling these features requires both requesting the features'
extensions and then explicitly turning on the features. libplacebo
handles detecting unsupported features and dropping them, to avoid
failing to create the vulkan device.
We then leave it to ffmpeg to decide if any missing features are
required for functionality, and error out if necessary.
As ffmpeg requires at least one bleeding edge extension (descriptor
buffers), all of this logic is gated on the presence of sufficiently
new Vulkan headers.
Vulkan Video Decoding has finally become a reality, as it's now
showing up in shipping drivers, and the ffmpeg support has been
merged.
With that in mind, this change introduces HW interop support for
ffmpeg Vulkan frames. The implementation is functionally complete - it
can display frames produced by hardware decoding, and it can work with
ffmpeg vulkan filters. There are still various caveats due to gaps and
bugs in drivers, so YMMV, as always.
Primary testing has been done on Intel, AMD, and nvidia hardware on
Linux with basic Windows testing on nvidia.
Notable caveats:
* Due to driver bugs, video decoding on nvidia does not work right now,
unless you use the Vulkan Beta driver. It can be worked around, but
requires ffmpeg changes that are not considered acceptable to merge.
* Even if those work-arounds are applied, Vulkan filters will not work
on video that was decoded by Vulkan, due to additional bugs in the
nvidia drivers. The filters do work correctly on content decoded some
other way, and then uploaded to Vulkan (eg: Decode with nvdec, upload
with --vf=format=vulkan)
* Vulkan filters can only be used with drivers that support
VK_EXT_descriptor_buffer which doesn't include Intel ANV as yet.
There is an MR outstanding for this.
* When dealing with 1080p content, there may be some visual distortion
in the bottom lines of frames due to chroma scaling incorporating the
extra hidden lines at the bottom of the frame (1080p content is
actually stored as 1088 lines), depending on the hardware/driver
combination and the scaling algorithm. This cannot be easily
addressed as the mechanical fix for it violates the Vulkan spec, and
probably requires a spec change to resolve properly.
All of these caveats will be fixed in either drivers or ffmpeg, and so
will not require mpv changes (unless something unexpected happens)
If you want to run on nvidia with the non-beta drivers, you can this
ffmpeg tree with the work-around patches:
* https://github.com/philipl/FFmpeg/tree/vulkan-nvidia-workarounds
We will need the full ra_ctx to be able to look up all the state
required to initialise an ffmpeg vulkan hwcontext, so pass let's
pass the ra_ctx instead of just the ra.
This is motivated by a need to access it from vo_gpu_next's opengl
wrapping code, and justified by it being an inherent property of the GL
context itself,
It was unsafe to return pointer to memory that was freed on another
thread, just copy the string to caller owned sturcture.
Fixes crashes when displaying passes stats with gpu-next.
vo_dmabuf_wayland worked by allocating entries to a pool and then having
a lot of complex logic dealing with releasing buffers, pending entries,
etc. along with some other not so nice things. Instead, we can rewrite
this logic so that the wl_buffers created by the imported dmabuf is
instead stored in a linked list, wl_list. We can simply append our
buffers to the list when needed and destroy everything at the end. On
every frame, we can check the ids of our surfaces and reuse existing
buffers, so in practice there will only ever be a handful at a time.
Some other small changes were made in an attempt to organize the
vaapi/drmprime code a little better as well.
An important change is to always enforce at least a minimum number of
buffers. Certain formats would not make enough unique buffers, and this
results in flickering/artifacts occuring. The old way to attempt to deal
with this was to clear out all the existing buffers and remake them, but
this gets complicated and also didn't always work. An easy solution to
this is just create more buffers which appears to solve this problem.
The actual number needed is not really based on anything solid, but 8
is a reasonable number to create for the lifetime of a file and it seems
to do the trick.
Additionally, seeking/loading new files can result in flicker artificts
due to buffers being reused when they shouldn't. When that happens, we
flip a bool so all the buffers get destroyed in draw_frame to avoid any
visual glitches.
This just replaces the API calls to get rid of deprecation warnings, it
doesn't yet expand the enum, nor replace them by the proper options.
The translation from tone map modes to hybrid mix parameters is taken
from the libplacebo source code.
Previously, if vo_drm_init failed at the start of drm_egl_init it
caused a use-after-free in drm_egl_uninit when it tried to access the
non-existant drm context. At that point vo_drm_uninit had already been
called resulting in two different null pointer dereference. In this
situation the DRM private context had also not been allocated.
This matches the behaviour that libmpv API clients expect better and
prevents silent regressons with watch_later suddenly appearing in
an entirely different path (or none at all in case of weird platforms*).
Also added some comments for easier understanding.
* Android
Previously, we'd only attempt to call guess_lang_from_filename if the
external file name matched the video name ignoring the extensions. So if
they didn't match, we'd just report the language as "unknown". And since
the name will never match for urls, the language would always be treated
as unknown.
Now we'll always try to guess the language from the filename regardless
of its similarity to the video file name.
Closes#10348
Filtering globally D3D11_MESSAGE_ID_CREATETEXTURE2D_INVALIDDIMENSIONS is
suboptimal, because can also hide other invalid usages. In the same time
it is not enough, because not only this message is emitted, but also one
about E_INVALIDARG. Just flush queue before and clear messages after to
ignore this part of code.
As a side note, I don't believe this texture size lookup is in fact
useful, but since it is there and is relatively harmless, let's leave
it as is.
The current implementation is order dependent and assumes that getting
keyboard input happens before the toplevel is activated. This isn't
necessarily the case and indeed mutter activates the toplevel first.
Improve this by simply spinning off the check to a function and calling
it in the three places where it would be needed: the toplevel
configuration event, keyboard entering, and keyboard leaving. This
fixes#11694.
Pass "dummy.m3u8" filename to work around FFmpeg commit
6b1f68ccb04d791f0250e05687c346a99ff47ea1 which broke their HLS demuxer
and its ability to probe.
Since the above commit, libavformat will check the filename of the file
to be probed and reject it if it doesn't end with a valid HLS extension
i.e. m3u8,hls,m3u (never mind that .hls is not a valid HLS extension).
In addition to a bug with query strings, this also breaks mpv
functionality as mpv explicitly doesn't tell libavformat the filename
when probing, in order to properly detect the file based only on their
contents.
The [HLS specification](https://www.rfc-editor.org/rfc/rfc8216.txt) aka
RFC 8216, specifies in section 4 that "Each Playlist file MUST be
identifiable either by the path component of its URI or by HTTP
Content-Type." Notably, it does not require both, so this FFmpeg commit
is noncompliant. We work around this noncompliance by checking the MIME
type ourselves. If the mimetype matches one of the valid HLS mimetypes
(and also application/x-mpegurl, a legacy pre-standardization type),
then we pass "dummy.m3u8" to libavformat in order to work around its
overly strict checking of filenames.
Without this patch, we are unable to play many HLS streams, including a
few from the ytdl hook. This patch restores those ability to play those
streams when built against FFmpeg master. Do note that if the server
sends an invalid content-type header then we cannot implement this
workaround so those streams will still fail to play.
This adds cache as a possible path for mpv to internally pick
(~/.cache/mpv for non-darwin unix-like systems, the usual config
directory for everyone else). For gpu shader cache and icc cache,
controlling whether or not to write such files is done with the new
--gpu-shader-cache and --icc-cache options respectively. Additionally,
--cache-on-disk no longer requires explicitly setting the --cache-dir
option. The old options, --cache-dir, --gpu-shader-cache-dir, and
--icc-cache-dir simply set an override for the directory to save cache
files. If unset, then the cache is saved in XDG_CACHE_HOME.
A pain point for some users is the fact that watch_later is stored in
the ~/.config directory when it's really not configuration data. Roughly
2 years ago, XDG_STATE_DIR was added to the XDG Base Directory
Specification[0] and its description, user-specific state data, actually
perfectly matches what watch_later data is for. Let's go ahead and use
this directory as the default for watch_later. This change only affects
non-darwin unix-like systems (i.e. Linux, BSDs, etc.). The directory
doesn't move for anyone else.
Internally, quite a few things change with regards to the path
selection. If the platform in question does not have a statedir concept,
then the path selection will simply return "home" instead (old
behavior). Fixes#9147.
[0]: https://gitlab.freedesktop.org/xdg/xdg-specs/-/commit/4f2884e16db35f2962d9b64312917c81be5cb54b
Currently, nothing new is actually implemented but the idea is simply to
just pass a type string all the way up from mp_find_user_file down to
actually getting the platform path. This allows for selecting different
directories besides the user's native config directory. See the next
commit for an implementation.
macOS really has completely different path conventions that mpv doesn't
take into account and it treats it just like any other old unix-like
system. This means mpv enforces certain conventions on it (like all the
XDG stuff) that doesn't really apply. Since we'd like to use more of
this but at the same time not distrupt mac users even more, let's just
copy and paste the current code to a new file, update the build and call
it a day. This way, the paths of these two platforms can more freely
diverge.
If mp_iconv_to_utf8 was given an empty string to convert in the buf
parameter it would corrupt memory when writing a null into outbuf
before returning it to the caller. This happened when streaming from a
URL that ends in a slash. For such a URL the method mp_basename returns
an empty string. The method append_dir_subtitles passes the result
returned from mp_basename to mp_iconv_to_utf8 which then corrupts
memory. This was detected using Guard Malloc. The fix changes
mp_iconv_to_utf8 check up front if buf is empty and if it is return
buf as the result in compliance with the documented behavior of the
method when no conversion is needed.
Fixes#11626
Upon an option update with an UPDATE_SUB_HARD flag,
the ass_track that stores all the decoded
subtitle packets/events is destroyed and recreated, which means
the packets need to be read and decoded again to refill
the ass_track. This caused issues (no subs displayed) in 2 cases:
1. external sub files
Previously, external sub files were read and decoded only
once when loaded. Since this meant all decoded events were lost
forever when recreating the ass_track, we need to change this
and trigger a new preload during sub reinits.
2. converted subs (non-ASS text subs like srt)
For converted subs, we maintain a list of previously
seen packets to avoid decoding and adding duplicate events
to the ass_track. Previously this list wasn’t synchronized with
the corresponding ass_track, so the sub decoder would reject
any previously seen sub packets, usually meaning only subs sometime
after the current pts would be displayed after sub reinits.
Fix this by resetting the list upon ass_track recreation.
HEVC hardware decode with drm wasn't working on the RPi 4. Mpv would
report the image format (rpi4_8 for 8-bit and rpi4_10 for 10-bit) wasn't
supported. The change to hwdec_drmprime.c identifies these two formats
as NV12 because it functions exactly the same. The change to
dmabuf_interop_gl.c adds support for P030 which rpi4_10 uses. These
changes were tested on a Pi 4 with this fork of ffmpeg:
https://github.com/jc-kynesim/rpi-ffmpeg.
Signed-off-by: EmperorPenguin18 <60635017+EmperorPenguin18@users.noreply.github.com>
This finally allows us to put any user defined options into the
CONFIGURATION variable like what waf does. The arbitrary hardcoded
fallback is left in place for old meson versions. Also update the
documentation in regards to the mpv-configuration variable to be
relevant to meson.
If --screenshot-tag-csp=no, then there won't be any color tags in the
output space, so PNG and JXL screenshots should be written as sRGB
rather than the native space of the input video.
As the Dolby Vision metadata is only supported for vo_gpu_next, the check
whether to use the metadata is now handled by `mp_map_dovi_metadata_to_pl`.
It doesn't hurt to keep the metadata in `mp_image`, and might be useful to
library users.
6e4a76db08 attemped to reject invalid
properties and print an error for users so they actually know that
something is going wrong. This worked by simply checking if the property
not found error is returned, but it is actually perfectly possible for a
property to not be found (different than being unavailable just to be
clear here) at first and then show up later. An example would be
user-data which can be created at any time. It's also possible with
subproperties of things like track-list where a new track could be added
later.
In light of this, let's soften the error checking logic here with a
simple trick. mpv already keeps track of all toplevel properties and it
can be easily retrieved with the "property-list" property, so just cache
that. When we get a property not found error, instead of rejecting it,
try to match it something in the property-list first. If we have a
match, then consider the property valid and allow the script to behavior
normally. If not, we reject it. This approach means property names that
are obviously wrong like "fake-property-here" will reliably get rejected
and something like "user-data/test" works as usual. The downside is that
errors in the subproperty level are not caught, so something like
"track-list/0/fake-property" would still be considered valid and the
user gets no warning that this won't work. We'll just accept the
compromise and hope this isn't too common.
Fixes#11550.
Instead of erroring when values returned by profile-cond expressions
aren't booleans, apply the relative profiles as long as the return
values are truthy. This allows shortening conditions like
profile-cond=path:match('foo') ~= nil
to
profile-cond=path:match('foo')
The idle logo could appear on the left side of the window for a split
second after starting.
That is because when osd dimensions can be reported as 0 at the very beginning.
Since the width gets calculated based on a fixed height and the aspect ratio,
which is 0, that results in a width of 0 until the next update.
Microsoft documented how to enable dark mode for title bar:
https://learn.microsoft.com/windows/apps/desktop/modernize/apply-windows-themeshttps://learn.microsoft.com/windows/win32/api/dwmapi/ne-dwmapi-dwmwindowattribute
Documentation says to set the DWMWA_USE_IMMERSIVE_DARK_MODE attribute to
TRUE to honor dark mode for the window, FALSE to always use light mode.
While in fact setting it to TRUE causes dark mode to be always enabled,
regardless of the settings. Since it is quite unlikely that it will be
fixed, just use UxTheme API to check if dark mode should be applied and
while at it enable it fully. Ideally this function should only call the
DwmSetWindowAttribute(), but it just doesn't work as documented.
Fixes: #6901
This better follows the actual required bits, and makes sure that
a file not part of standard EGL headers is available, as the
handle type is part of standard EGL extensions header.
Previously, it just silently didn't do anything which is not very
intuitive. Since the lua api returns an error string, check to see if
it matches the "property not found" case and print an error message.
Additionally, don't add the fake property to the internal
cached_properties list or try to observe it. This avoids redundant
evaluate calls which will never actually succeed. We do still mark it
under watched_properties however. This avoids having to call
mp.get_property_native multiple times.
`io_close2` was introduced as a superior replacement for `io_close` in
ffmpeg 5.0, and then deprecated in 6.0. The difference is that
`io_close2` can return errors. In our case, we're just calling through
to the original function anyway, so we don't need to do more than pass
the return value back.
This is the latest stable release, and what we should use for
libplacebo-next per haasn's recommendation.
The previous 202 version wasn't even a release.
The playlist title only got set when it was specified in the playlist
file.
If there is a title after opening a file, that should also be reflected
in the playlist.
As it turns out that approach was suboptimal.
The playlist title would only ever get set when media-title actually
gets read, which depending on the configuration and usage might never
happen.
The next commit reimplements that feature in a different way.
This reverts commit 048d4d8b75 except for
the input.rst change.
It turns out that you actually have to add failure() to each condition
otherwise a default status check of success() is applied (thanks
github). Looks redundant but whatever. Thanks to @kasper93 for actually
reading the documentation.
This way we receive such minor details as the profile (necessary for
ARIB captions, among others) during init. This enables decoders
to switch between ARIB caption profile A and profile C streams.
They should not be modifying the argument, so clearly marking it
as const makes sure we don't do it in the future as well as allows
for read-only optimizations.
libplacebo v6.265.0 removed v4 deprecations. We already require
PL_API_VER >= 202, so we don't need to wrap
pl_tex_transfer_params.row_pitch around a conditional, which exists
since PL_API_VER >= 168. However, pl_source_frame.duration does not exist until
PL_API_VER >= 219, so we should use a conditional directive.
While adding fractional scale support, the coordinates for wayland
changed to always include the scaling parameter. The pointer stuff
actually did too. However, the check_for_resize function used the
unscaled, local surface coordinates. Likely, it was neccesary at the
time since wl->geometry used to report unscaled coordinates. In light of
that, we can just simply use mouse_x/y instead for this function to make
it work correctly with the right/bottom edges. mouse_unscaled becomes
completely unneccesary, so just drop it.
Some minor style changes included just because.
`xdg_toplevel_decoration` exists on SSD compositors independent of if
there is a border or not, so resizing didn't work on those.
Checking the border option makes more sense and also works on such
compositors.
Screenshots using the hardware renderer should now include color tags
that map directly from the libplacebo tags, so the if/else logic only
needs to be included once.
mp_trc_to_pl, mp_prim_to_pl, and mp_levels_to_pl have forward but not
inverse mappings. This commit adds mp_trc_from_pl, mp_prim_from_pl, and
mp_levels_from_pl inverse mapping functions, which just map the enums
in the other direction.
By making the data thread realtime it is able to serve requests faster
and more reliable reducing crackling in certain situations.
As the mpv callbacks that are running on the data thread are all
non-blocking and very short this should be safe.
The same mechanism is also used by pw-cat and the alsa plugin shipped by
pipewire.
In raw OTA MPEGTS, different programs can be entirely different virtual channels.
In web streams, different programs can be different variant bitrates,
so using streams from different programs can waste large amounts of bandwidth.
An error indicates that something doesn't work, but as long as a
safe url is available, playback is still expected to work.
Thus reduce logging level of MP4 DASH without fragments message and
add a new error message for when there is no safe url available either.
Also adds a missing space.
With dash the first fragment was always considered an init fragment if
there wasn't a duration. However that only makes sense when there are
also other fragments, so check if there are other fragments in addition
to the lack of a duration.
There is a very subtle race in vo that can manifest itself on pause
events. In the renderloop, render_frame, unsurprisingly, does the heavy
lifting of actually queuing up and flipping the frames. This is called
during normal playback. Sometimes various parts of the player can make a
redraw request which will latter trigger another render of the frame
later down in the loop (do_redraw). Because these requests can happen at
essentially anytime, sometimes the redraw request will happen *before*
do_redraw and it'll be caught in render_frame. When this happens,
the existing render_frame run works perfectly fine as a redraw so it
clears out the request which is sensible. Normally this is all locked of
course, but there's one catch. render_frame has to unlock itself when
propagating down into specific VOs/backends. That's what causes this
bug.
While render_frame is unlocked, other parts of the player can send
redraw requests which will cause in->request_redraw to become true. The
logic in the code always clears out this parameter after a successful
render, but this isn't correct. When in->request_become becomes true in
the middle of render_frame, there needs to be one more draw afterwards
to reflect whatever actually changed (usually the OSD). Instead, this
gets simply discarded. If you rapidly spam pause while rendering things
to the OSD at the same time, it's possible to for the last render to
be behind a frame and appear as if your osd event was ignored.
Once you realize what is happening, the fix is quite simple. Just store
the initial value of in->request_redraw before the unlock step. After we
do the render step and unlock again, only set in->request_redraw to
false if there was an initial redraw request. We just finished doing a
redraw, so it is safe to clear. Otherwise, leave in->request_redraw
alone. If it is initially false, then it will still be false and nothing
changes. However if it updated to true in the middle of the rendering,
this value is now preserved so we can go and call do_redraw later and
show what that last frame was meant to be when you pause. One
unfortunate thing about this design is that it is technically possible
for other internal things in vo to update during that unlocked period.
Hopefully, that doesn't actually happen and only redraw requests work
like this.
Fixes#8172 and #8350.
Instead of running the test directly in the build script, we can make a
separate step in the workflow so it looks a little prettier. For running
the actual tests, we skip mingw since they will never be run (cross
compiled). Additionally, improve the github workflow logic a bit so that
way logs on failure are only shown when that specific step fails. The
freebsd job still has to be less elegant since it's in a weird vm
thingy.
Not really related but the location of various build directories
(particularly waf) are corrected as well (might as well).
This reworks all of mpv's unit tests so they are compiled as separate
executables (optional) and run via meson test. Because most of the tests
are dependant on mpv's internals, existing compiled objects are
leveraged to create static libs and used when necessary. As an aside, a
function was moved into video/out/gpu/utils for sanity's sake (otherwise
most of vo would have been needed). As a plus, meson multithreads
running tests automatically and also the output no longer pollutes the
source directory. There are tests that can break due to ffmpeg changes,
so they require a specific minimum libavutil version to be built.
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.
A few formats were added recently, some were removed, and some flags
were changed. Maybe this should be better, but just update for now so
the tests stop failing.
There is no good reason to do so, both zimg and swscale supports full
range output. If downstream something expects limited range yuv always,
it needs to be comunicated in different way.
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.
This came up in #9828. According to the header comments, creating a 1D
ra_tex requires height and depth to be set to 1. For a 2D texture, it
requires depth be set to 1. There were a couple of spots in mpv's code
where this wasn't being followed. Although there was no known bug from
this, the rest of the code works like this so it was a good idea to go
ahead and sync it up. As a followup, let's just add some simple asserts
to ra.c to enforce this so it doesn't go unnoticed in the future.
These options make it possible to specify the directory that will be
passed to ass_set_fonts_dir(), akin to VLC's `--ssa-fontsdir` and
FFmpeg's `fontsdir`.
Fixes#8338
Which is wl->video_surface for vo_dmabuf_wayland.
Listening on wl->surface results in freezes if it is occluded and
culled by the compositor. Which mutter does, and the wl_surface::frame
spec warns about:
> A server should avoid signaling the frame callbacks if the
> surface is not visible in any way, e.g. the surface is off-screen,
> or completely obscured by other opaque surfaces.
ra_ctx_opts.want_alpha and vo_wayland_set_opaque_region's alpha
argument are only used as bool but both are ints. Particularly for the
function argument, passing a 0 or 1 is confusing - at first glance it
looks like you're specifying an alpha value of 0 or 1.
Since they're only used as bools, make them bools.
The console.lua check is still kind of dumb since we check an
environment variable to distinguish between wayland and x11, but
otherwise it should be better in theory.
This returns the value of the target OS that mpv was built on as
reported by the build system. It is quite conceivable that script
writers and API users would need to make OS-dependent choices in some
cases. Such people end up writing boilerplate/hacks to guess what OS
they are on. Assuming you trust the build system (if you don't, we're in
really deep trouble), then mpv actually knows exactly what OS it was
built on. Simply take this information at configuration time, make it a
define, and let mp_property_platform return the value.
Note that mpv has two build systems (waf and meson), so the names of the
detected OSes may not be exactly the same. Since meson is the newer
build system, the value of this property follows meson's naming
conventions*. In the waf build, there is a small function to map known
naming deviations to match meson (i.e. changing "win32" to "windows").
waf's documentation is a nightmare to follow, but it seems to simply
take the output of sys.platform in python and strip away any trailing
numbers if they exist (exception being win32 and os2)*.
*: https://mesonbuild.com/Reference-tables.html#operating-system-names
*: https://waf.io/apidocs/Utils.html#waflib.Utils.unversioned_sys_platform
ytdl_hook always set force-media-title, making users unable to force
a media-title via options.
To prevent that, check if force-media-title is already set to avoid
overwriting it.
A better solution would be to use tags like is already done for some
metadata, however that doesn't work when `all_formats=yes` is used.
See cbb8f534b0
A comment was added to hint at why it isn't done via tags.
ref.
https://github.com/mpv-player/mpv/pull/10453#issuecomment-1445277496
This refactors exec to only return the result of the subprocess command,
and makes the rest of run_ytdl_hook use the fields of this result,
because specifying all those return values multiple times is unwieldy
now that exec is called several times, and this is easier to read
anyway.
I removed the line
err = string.format("%s returned '%d'", err, es)
altogether instead of updating the es variable, because there was no
chance of it being executed since it would only happen when
result.killed_by_us is true, but run_ytdl_hook returns early when it is.
This reorders some code and checks the image track-list sub-property
instead of the albumart one, so that when playing audio without enough
playtime-remaining and images, the "autocrop only works for videos."
warning is logged instead of the "Not enough time to detect crop." one.
It also avoids repeating this warning twice in the code.
As of e16d0dd15d current-tracks returns a video track even when
lavfi-complex is used, so the track-list loop in is_cropable can be
replaced with just checking current-tracks/video while still cropping
videos with lavfi-complex.
Changing the CONF_TYPE_FLAG was a bad idea because mpv_node.u.flag
continues to be an int, leading to a mismatch in type sizes which can
lead to problems with memcpy().
ref. #11373
This partially reverts commit 17d91b9d4d.
The m_option_type_flag is still needed for the CONF_TYPE_FLAG
(next commit).
Add a comment that m_option_type_flag shouldn't be used.
ref. #11373
This partially reverts commit 07545657bf.
The playlist title only got set when it was specified in the
playlist file.
If there is a title after opening a file, that should also be reflected
in the playlist.
ref. #4780
For hwdecs without devices we can't get instant feedback during probing
whether the hwdec can possibly work or not, so we definitely want to try them last.
Independently this would also have solved the issue addressed by the previous commit.
This fixes an issue where mpv would try mediacodec (which may not
be available depending on Android version) and pick v4l2m2m next
which ends up failing even though mediacodec-copy would have been available.
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.
This was originally dropped because it was thought to be unneeded at the
time, but at least some devices (rockchip) apparently are still on old
compositors that use linux-dmabuf v2. It's not much code, and for
testing purposes it's good to have around since it's hard to test
drmprime otherwise. Some minor additions are here to support the newly
added vaapi-format mapping in v2 of the protocol.
This reverts commit a5b9d529ee.
effort=4 has a significant increase in quality/bpp compared to effort=3
with a very minor increase in encoding time. It's worth the trade-off
as a default setting for lossy encoding.
Older versions of pipewire segfault when calling spa_hook_remove() on
hooks that are zeroed.
Add a backfill for the logic added by pipewire 0.3.57.
Being able to remove zeroed hooks makes errorhandling much easier.
See #11309
This allows the logic in `convert_image` to fast-path if the image
params are equal. Without this check, the image params are basically
never equal, because that path goes through `mp_image_params_guess_csp`
while the `mp_image` itself does not.
Force it here for consistency across VOs.
After commit c98e7353, we blindly pass the screenshot colorspace to the
image writer. But since we want to introduces the ability to save images
in HDR and other exotic formats, we should strip this for unsupported
formats.
See-Also: #10988
When taking window screenshots with a colorspace override, tag them
appropriately, based on the best-known colorspace info. Note that this
is imperfect, we should ideally also attach the output ICC profile if
one exists. But this is better than nothing.
Also force 1:1 PAR in this case. In all other cases, default to sRGB.
When taking an unscaled screenshot, always render to an unspecified
SDR-like space. (Subject to change) Apply output-specific options (ICC
profile, color space overrides, custom LUT) only in window screenshot
mode.
I decided to split this off from subsequent refactors because it is IMO
a bug fix deserving of its own commit.
Screenshots are currently always RGB. Subject to change, but needs to be
communicated clearly if changed. This commit is not a functional change,
it's merely for code clarity.
Based on the new upstream helper function `pl_map_hdr_metadata` and the
existing AV_FRAME_DATA_DYNAMIC_HDR_PLUS. This allows us to use SMPTE
2094-40 dynamic HDR tonemapping in mpv, albeit with the limitation of
requiring `--tone-mapping=auto` in order to pick this curve upstream.
PipeWire supports a global volume control for streams that works on top
of the per-channel volumes.
As mpv only supports a single volume with ao-volume it can make sense to
use the single global volume from PipeWire for it.
This allows the user to also specify per-channel volumes and not have
mpv trample over them.
This mode is not the default as pulseaudio does not support this
global volume control and all tooling controlling PipeWire via
pipewire-pulse (like pavucontrol) will not be able to see this channel.
The `osd-overlay` command didn't trigger a redraw when the overlay was
set to hidden.
This is fine when the overlay was already hidden before that, but
transitioning from not hidden to hidden requires a redraw.
This option is a bit obscure, but some people do use it and it can be
useful. The actual code that implements this is very simple, so there's
really no need to have a scary note in the docs about it possibly
changing or being removed.
3a9e661e92 officially made this video
filter deprecated roughly 6 years ago. Every other video filter in that
commit has actually been removed since then except for vf_sub. ffmpeg
does have its own subtitles filter, but it doesn't have the same control
over scale like vf_sub does. That's probably why wm4 never actually
removed it. Let's stop scaring users with a warning since this filter
probably won't ever get removed. Closes#9254.
With significant improvements to the color tagging support in various
screenshot formats, e.g. cICP in FFmpeg, and JPEG XL's generally robust
color support, it's safe to default this to yes.
As ao_pipewire is probed first if a user does not have PipeWire running
they will see a scary warning message even if another AO afterwards is
probed fine.
Tone down the error message so as not to confuse users.
The value of `sig-peak` is relative to the SDR peak. This is not
a problem when used inside the player, but the `HDR peak` in stats
should display human-readable information.
So change to return the actual nits value of HDR.
Closed https://github.com/mpv-player/mpv/issues/10127
Writing an image either with vo_image or with a screenshot will strip
the colorspace info because it allocates a new mp_image that contains
the same data as the old image after calling mp_image_params_guess_csp.
However, mp_image_params_guess_csp cannot always guess the appropriate
colorspace, so it picks a "sane default." Since this function also
changes parameters so the space always makes sense, this extra info
isn't harmful and allows screenshots and vo_image outs to be properly
tagged with the correct colorspace.
Fixes#10988.
Treat them as http:// and https:// respectively. This allows to play files
on webdav archives directly on KDE, avoiding the (extremely slow) local
copying performed by kio.
It turns out that there's a has_header check, and we should actually be
using that instead. We only care here if the header actually exists so
the pre-processor check is all that is needed. check_header depends on
what arguments the user passes among other things. That makes it more
complicated than necessary for our purposes.
Previously, this defaulted to yes and configure-bounds from the
compositor would always apply. In the case where the user explicitly set
autofit or geometry, this could be confusing because configure-bounds
would take precedence over it. Instead, let's add an auto choice and
make that the default. If we detect that the option is on auto and that
there is autofit/geometry being set, then ignore the event. This should
be more intuitive since someone who bothers to explicitly set mpv's
geometry would naturally expect that geometry to actually apply.
Semi-regression although this option never really did what the manual
said until recently. In the past, this option also controlled whether or
not mpv set the wayland buffer_scale to the value of the wl_output or
force it 1. This had varying effects depending on the exact compositor
configuration. That logic has now all been removed and this option now
only controls whether or not to scale the window with the hidpi scale
factor we get from the compositor. i.e. it actually does what the
manual says now.
Regressed from 879824a47f. The geometry
needs to be explictly recalculated now. Change up this function a little
bit also give it the ability to directly perform a resize after the
fact. This is a common workflow and we'll be using it in the next
commit.
This reverts:
3fb4140c lua/defaults: add user_data helpers
68a20e7a javascript/defaults: add user_data helpers
00510379 lua/js: fix user_data_del util function
As well as the lua/js parts of:
3ec2a098 docs: document new user-data property
user-data and its sub-properties can be set/get/observed/deleted
via the standard properties interface, so there's no need for
additional helpers specific to user-data, which only added maintenance
burden.
This will replace shared-script-properties in new usage. It can be used for all the same things, but is much more versatile.
Clients can create arbitrary sub-objects, and text expansion can access them.
For instance, if a script sets `user-data/my-script/property1` to "test", that value will be available by expanding ${user-data/my-script/property1}.
When building both cplayer and libmpv in the same build previously all
sources were built twice.
By reusing the objects from libmpv in cplayer we can thus save 50%
percent of the build steps.
ao-volume is represented in the code with a `struct ao_control_vol_t`
which contains volumes for two channels, left and right.
However the code implementing this property in command.c never treats
these values individually. They are always averaged together.
On the other hand the code in the AOs handling these values also has to
handle the case where *not* exactly two channels are handled.
So let's remove the `struct ao_control_vol_t` and replace it with a
simple float.
This makes the semantics clear to AO authors and allows us to drop some code from the AOs and command.c.
PresentNotifyMSC turns out to be not only redundant, but also harmful with
mesa-backed egl/glx/vulkan VOs because for all of them, mesa uses
PresentPixmap behind the scenes when DRI3 is available, which already
spawns a PresentCompleteNotify event when the buffer swap actually
finishes. This is important because without using the timing information
from these PresentCompleteKindPixmap events, there's no way for mpv to know
exactly when a frame becomes visible on the display.
By using PresentNotifyMSC in conjunction with DRI3-enabled mesa, two
problems are created:
1. mpv assumes that a vblank won't elapse (i.e., it assumes the current MSC
won't change) between the time when mesa enqueues the buffer swap and
the time when mpv calls PresentNotifyMSC to ask xorg for a notification
at the next MSC, relative to the current MSC at the time that xorg reads
it for the PresentNotifyMSC call. This means that mpv could get a
notification one or more vblanks later than it expects, since the
intention here is for mpv to get a notification at the MSC that the
buffer swap completes.
2. mpv assumes that a buffer swap always takes one vblank to complete,
which isn't always true. A buffer swap (i.e., a page flip) could take
longer than that depending on hardware conditions (if the GPU is running
slowly or needs to exit a low-power state), scheduling delays (under
heavy system or GPU load), or unfortunate timing (if the raster scan
line happens to be at one of the last few rows of pixels and a vblank
elapses just before the buffer swap is enqueued).
This causes mpv to have a faulty assumption of when frames become visible.
Since mpv already receives the PresentCompleteNotify events generated by
mesa's buffer swaps under the hood, the PresentNotifyMSC usage is unneeded
and just throws a wrench in mpv's vsync timing when xpresent is enabled.
Simply removing the PresentNotifyMSC usage from the egl, glx, and vulkan
VOs fixes the xpresent vsync timing.
This protocol is pretty important since it finally lets us solve the
longstanding issue of fractional scaling in wayland (no more mpv doing
rendering over the target resolution and then being scaled down). This
protocol also can completely replace the buffer_scale usage that we are
currently using for integer scaling so hopefully this can be removed
sometime in the future. Note that vo_dmabuf_wayland is omitted from the
fractional scale handling because we want the compositor to handle all
the scaling for that VO.
Fixes#9443.
This is in preparation for fractional scaling support. Basically, redo
all the coordinates in wayland so that wl->geometry is equal exactly to
what is being put out to the screen (no extra wl->scaling multiplication
required). The wl->vdparams variable is also eliminated for simplicity.
This changes mpv's behavior on wayland with hidpi scaling but that will
be addressed in more detail with the next commit.
For OpenGL, this is based on simply comparing GL_VENDOR strings against
a list of allowed vendors.
Co-authored-by: Nicolas F. <ovdev@fratti.ch>
Co-authored-by: Niklas Haas <git@haasn.dev>
--vd-lavc-dr defaulted to "yes", which caused issues on certain
hardware. Instead of disabling it, add a new "auto" value and
make it the default.
The "auto" choice will enable DR only when we can request host-cached
buffers (as signalled by the new VO_DR_FLAG_HOST_CACHED).
Co-authored-by: Nicolas F. <ovdev@fratti.ch>
Co-authored-by: Niklas Haas <git@haasn.dev>
Previously, if log-file was set not via a CLI option (e.g. set via
mpv.conf or other config file, or set from a script init phase),
then meaningful early log messages were thrown away because the log
file name was unknown initially.
Such early log messages include the command line arguments, any
options set from mpv.conf, and possibly more.
Now we store up to 5000 early messages before the log file name is
known, and flush them once/if it becomes known, or destroy this
buffer once mpv init is complete.
The implementation is similar and adjacent, but not identical, to an
existing early log system for mpv clients which request a log buffer.
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.
Core code should not use these features as it would mean that a libmpv
build could change an mpv executable and vice-versa.
Also changing one of them should not force a full recompile of the other
one through a change to config.h.
The libmpv feature should not have any impact on the built core code.
Otherwise a mpv executable compiled in a build together with libmpv has
different features than one from a build without.
The gl feature doesn't hurt, so always enable it.
This handle type was only needed for backwards compatibility with
windows 7. Dropping it allows us to simplify the code: there is no
longer a need for runtime checks, as the handle type can now be
statically assigned based on the platform.
The motivating usecase here, apart from code simplification, is a
desired switch to timeline semaphores, which (in the CUDA API) only
supports the non-KMT win32 handles.
It's worth pointing out that we need no runtime check for
IsWindows8OrGreater(), because the `export_caps.sync` check will already
fail on versions of windows not supporting PL_HANDLE_WIN32.
While the waf build has served us well for many years, it's time to
officially consider it deprecated. The meson build was added fully with
the intention to eventually replace waf and its current state is more
than good enough to do that. Let's start the deprecation period now to
give users a heads up to switch before we remove waf for good.
Currently filenames like `EP.1.v0.1080p.mp4` do not get sorted correctly
(e.g. episode 11 right after episode 1). That is caused by the `.` in
front of the episode number, making it get sorted as if it were
decimals.
The solution is to match the whole real number or integer instead of
matching the integer part and the fractional part separately.
This will regress sorting of numbers with multiple commas where the
length of the individual segments differs between filenames.
Since those are rather uncommon, that is unlikely to be a problem (for
anyone ever).
Officially, the most cursed part of the wayland code in mpv (third or
fourth try now?) This time, let's allocate a pool during init
(arbitrarily set to the maximum swapchain length mpv allows, 8; don't
even know if this actually works in wayland). Then we add/remove
feedbacks from the pool during the lifecycle of the VO, and clean it up
all at the end. Hopefully, this does the trick for good this time.
This ended up being a bad idea. The problem is that it introduces
ordering when destroying events (something we weren't worried about
before) and Lynne pointed out a problem with the callback not also being
destroyed before the surface in IRC. Just undo this and go with a
different approach (next commit). P.S. the wayland_dispatch_events name
change is kept though because I like that better.
This reverts commit aa8ddfcdf3.
I should have caught this during review but the feature was too cool and
I didn't really pay attention (sorry). For consistency with the rest of
the scripts here.
In debug mode the macro causes an assertion failure.
In release mode it works differently and tells the compiler that it can
assume the codepath will never execute. For this reason I was conversative
in replacing it, e.g. in mpv-internal code that exhausts all valid values
of an enum or when a condition is clear from directly preceding code.
The situation here is that HWND is always a 32-bit value but the
win32 API also accepts sign-extended values as valid. The trouble
starts when the numeric value is negative, as mpv ignores those.
Apparently this only happens after a while (related to uptime
or number of handles created), which meant this problem was rare.
addresses #10189
The only real reason this was ever supported is because it was
dramatically simpler than v4, so it was put in as an initial
implementation. Later, v4 support was added and we left v2 for
compatibility, but let's just drop it. Compositors all use v4 nowadays,
and v2 is significantly limited (no modifier support for example). It's
better to just remove this dead code for simplicity.
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.
Instead of choosing based on smallest deviation from set speed,
use the speed change from the smallest factor that does not
exceed `video-sync-max-video-change`.
Formatting the string on each comparison is wasteful.
Formatting strings beforehand and then comparing the already formatted
ones leads to a huge performance gain.
This was already returning true/false but the type was int. Also
simplify a few places in the wayland contexts where we can just return
the value of this function instead of doing redundant checks.
Instead of just returning true/false, it's better to have this function
cleanup itself. We can eliminate some redundant uninit calls elsewhere
in the code as well.
There's several functions that are used for initializing mpv on a
certain platform (x11, wayland, etc.). These currently are all int, but
they actually return 1 and 0 like a boolean. This gets a bit confusing
because actual vo preinit functions return 0 and -1 instead. Just make
these all bool instead and return true/false to make it clearer.
vk->surface is a handle and not a pointer, so assign VK_NULL_HANDLE.
This fixes the following build error on 32bit Windows when using clang for example,
which errors out when assigning a 32bit pointer to a 64bit integer:
../mpv-0.35.0/video/out/vulkan/utils.c:37:21:
error: incompatible pointer to integer conversion assigning to 'VkSurfaceKHR' (aka 'unsigned long long') from 'void *' [-Wint-conversion]
vk->surface = NULL;
^ ~~~~
This allows us to rebuild the manpages and html documentation only when
necessary. It is not necessary to manually keep the list of dependencies
up to date.
Unfortunately rst2pdf does not yet support this feature, see
https://github.com/rst2pdf/rst2pdf/issues/1108
In `new_demux_packet_from`, we initialise a new packet and allocate a
buffer which we copy the source data into. But I was then assigning
the original source pointer as the packet's buffer, rather than keeping
the newly allocated one. Whoops.
Without this change the same track encoded as Opus - which requires R128
tagging - and e.g. Vorbis with ReplayGain tagging have different volumes.
This is caused by ReplayGain 2 having a higher reference level of -18 dB
LUFS, while EBU R128 has a lower reference level of -23 dB LUFS.
For the results of gain application to match, the read EBU R128
values need to be boosted according to the difference in reference
levels.
Patch inspired by mpd's source code.
Similar to some other issues we've had with unprocessed compositor
events. When quitting mpv, there's two things we should be doing:
dispatching any last minute wayland events and then waiting for a
compositor reply. Luckily, there's already an internal helper for this
(renamed to wayland_dispatch_events for consistency) that we can use.
All of the special casing of wl->feedback becomes unneccesary and we can
remove this from vo_wayland_state with this method. Fixes#110022.
In the event of a failed wayland initalization, the display_fd is
actually 0 instead of -1 which would correctly indicate it doesn't
exist. Also move the fd check inside vo_wayland_dispatch_events since
that function shouldn't ever do anything if we don't actually have a
display fd.
We have a use_present bool that keeps track of whether or not to use
presentation time. However, the creation of the feedback listener
actually wasn't checking this and was instead checking for the existence
of wl->presentation. There's no point in always creating the
listener and feedback if mpv isn't actually going to use it. Just change
it to use_present instead.
e97819f88e corrected a special case
condition that lead to an out of bounds access if the total width
happened to be an integer multiple of SLICE_W (256) which could cause a
crash in software VOs. However, it turns out that the functions in this
file evaluate quite differently when using encoding mode (and presumably
libmpv as well according to reports although I could not independently
verify it).
The logic here gets complicated but what ends up happening is that, in
blend_overlay_with_video, the value of x + w can be greater than p->w in
certain cases in encoding mode. The x is the positional value of the
slice which remained unchanged from before, but w can take the full
value of SLICE_W (256) which is not necessarily correct. The width of
the final slice here should be the total remaining width. We can handle
this in mark_rect by simply always adjusting x1 of the last slice to be
equal to total width - SLICE_W * x so it can never extend beyond where
it should be. In practice, this value should be the maximum allowed
here. I'm not sure if the existing x1 value can possibly already be
lower than SLICE_W, but just MPMIN it to be on the safe side.
Fixes#10908.
[motivation]
Seeking on MacOS appears to be lagged when users connect
to wireless audio output (airpods for example).
This commit attempts to fixmpv-player/mpv#10270
[observation]
1. When using other media player (VLC to be exact) simultaneously,
the lagging on seek disappear. We could guess that the AudioDevice
is on some sort of "warm-up" state.
See mpv-player/mpv#9243 for detailed description.
2. `AudioOutputUnitStart` takes significant longer time after each seek
or pause/play when using wireless output devices compares to wired devices.
[rationale]
After investigate codes in ao_coreaudio.c, it appears that the the `stop`
function was used as `ao_driver.reset` function. Therefore every seek
and pause would call `AudioOutputUnitStop`.
It turns out that `ao_driver.reset` function is used in `ao_reset`.
And `ao_reset` function is used to clean up the state of current `ao`
so I think `AudioUnitReset` is more proper than `AudioOutputUnitStop`
under this semantics.
Since ao_coreaudio use pull base mechanism, audio playback behaviors
upon pause/seek could be handled by callback function
(streaming silence when paused) so there is no need to stop AudioUnit when resetting.
Therefore using `AudioUnitReset` as `ao_driver.reset` looks proper.
Additionally, after using proper reset, the AudioUnit that represents
hardware I/O devices doesn't need to be restart everytime seek/pause actions happen.
Restarting wireless devices simply takes longer in MacOS which is
the root cause of lagging observed by users when they seek or pause/play media.
[method]
Use `AudioUnitReset` for ao_driver.reset.
This change enables mpv to work in the WSL2 (WSLg) environment where
OpenGL is implemented on top of D3D12.
This reverts commit 149d98d244.
Mentioned OpenGL implementation (GDI Generic) in the original change
will be rejected by version check, so there is no need to handle it
manually.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Buffering ahead nonstop into the cache results in nonstop disk or network
activity to read stream data from wherever it may originate. Currently,
there's no way to configure the demuxer to back off once it's buffered
ahead enough data, since the cache limit will be perpetually not-reached as
a stream continues to play, until the entire stream is eventually buffered.
On a laptop with an i9-12900H with decoding performed by the iGPU,
watching a locally-saved 1080p video which hasn't been buffered into the
page cache consumes approximately 15 W even with caching enabled. When
configuring a hysteresis to make the demuxer back off, power consumption
drops to 9 W when watching the same video, resulting in a whopping 6 W of
power savings.
To make it possible to attain significant power savings via caching, add
a --demuxer-hysteresis-secs option to configure a hysteresis to make the
demuxer back off until there's only the configured number of seconds
remaining in the cache from the current playback position.
This feature is disabled by default.
mpv currently only recognizes jpg and png files named "AlbumArt",
"Album", "cover", etc. which are in the same folder as the audio files
as album/cover art and displays it when playing such audios.
This feature adds support for webp files following the same naming
scheme to be displayed as cover art for albums who have them.
Webp variations are lower in priority compared to jpg or png files.
Resolves: #11006
Since the modesetting driver now has TearFree support with integration into
xpresent, it's important that xpresent is used with the modesetting driver
to get the correct vsync timing when a frame is delayed by one vblank
interval due to a pending page-flip enqueued by a different entity. The
modesetting driver ensures that the xpresent extension reports the correct
presentation timing when TearFree is used; mpv just needs to listen to it.
Add the modesetting driver to the xpresent whitelist so mpv can get the
correct presentation completion timing when modesetting TearFree is used.
This is also helpful for when xpresent performs page flips directly in the
modesetting driver and a natural delay in the display pipeline causes a
page flip to be delayed by one vblank interval or more.
In the previous change, I replaced the callsites that used
`av_init_packet`, but there are a handful of places that use stack
allocated packets with no initialisation.
In one case, I just switched to heap allocation as it's only done once
per stream at most.
In the other case, I removed our usage of the AVPackets as a
convenience mechanism to transfer data into a heap allocated packet.
Instead, I inlined the data copying.
When a pull AO reaches reaches EOF then ao_read_data() will set
p->playing = false.
Because the ao is marked as not playing ao_set_pause(true) will not
reset the AO.
This keeps the output stream unintentionally open.
Fixes#9835
See https://sw.kovidgoyal.net/kitty/graphics-protocol/
This makes no attempt at querying terminal features or handling
terminal errors, as it would require mpv to pass the response codes
from the terminal to the vo instead of interpreting them as
keystrokes made by the user and acting very unpredictably.
Tested with kitty and konsole.
Fixes#9605
We ask users to freely share log files with us, which is usually
okay, unless a user has some unrelated and potentially embarrassing
files in their working directory. These would show up in the debug
level message output that --log-file enables.
Change the listing of potential external files to trace log level,
to save the users and the developers the embarrassment.
This new hwaccel flag was added to allow us to request that an hwaccel
decode not implicitly copy output frames before passing them out. The
only hwaccel that would implicitly copy frames is nvdec due to how it
has a small output pool that cannot be grown very much. However, we
already copy frames as soon as we get our hands on them (in our hwdec)
so we're already safe from pool exhaustion, and the extra copy doesn't
help us.
H264 hardware decode with v4l2m2m wasn't working on the RPi 4. Mpv would
report the image format (yuv420p) wasn't supported. The change to
hwdec_drmprime.c is to explicitly say that the format now is supported.
The change to dmabuf_interop_gl.c is to specify the colour format of the
planes before generating egl images. These changes were tested on a Pi 4
with this fork of ffmpeg: https://github.com/jc-kynesim/rpi-ffmpeg.
Signed-off-by: EmperorPenguin18 <60635017+EmperorPenguin18@users.noreply.github.com>
currently only supported on x11.
one practical use-case of this is wanting to embed something (such as
dmenu) into the mpv window to use as a menu/selection. there might be
other use-cases as well (e.g doing some shenanigans with `xdotool` or
whatnot).
it's currently possible to:
* listen for 'current-window-scale' change (to check if the
window has been created or not)
* call an external tool like `xdo` or `xdotool` and grab the xid
from mpv's pid.
however it adds unnecessary dependency on external tools when mpv is
fully capable of easily providing this information.
closes: #10918
This has been a long standing annoyance - ffmpeg is removing
sizeof(AVPacket) from the API which means you cannot stack-allocate
AVPacket anymore. However, that is something we take advantage of
because we use short-lived AVPackets to bridge from native mpv packets
in our main decoding paths.
We don't think that switching these to `av_packet_alloc` is desirable,
given the cost of heap allocation, so this change takes a different
approach - allocating a single packet in the relevant context and
reusing it over and over.
That's fairly straight-forward, with the main caveat being that
re-initialising the packet is unintuitive. There is no function that
does exactly what we need (what `av_init_packet` did). The closest is
`av_packet_unref`, which additionally frees buffers and side-data.
However, we don't copy those things - we just assign them in from our
own packet, so we have to explicitly clear the pointers before calling
`av_packet_unref`. But at least we can make a wrapper function for
that.
The weirdest part of the change is the handling of the vtt subtitle
conversion. This requires two packets, so I had to pre-allocate two in
the context struct. That sounds excessive, but if allocating the
primary packet is too expensive, then allocating the secondary one for
vtt subtitles must also be too expensive.
This change is not conditional as heap allocated AVPackets were
available for years and years before the deprecation.
Now that 0.35 has been released, we can consider increasing our minimum
required ffmpeg version. Currently, we think 4.4 is the most recent
version we can move to (from the current requirement of 4.0).
This allows us to remove a few conditionals. There are more that we
won't be able to remove unless we move further up to 5.1.
8300830951 rearranged/simplified some of
the wayland touch code mainly because what was there before was
completely broken on my machine in those days (dragging was unreliable,
resizing was really buggy, etc.). However, one user said that touch
input no longer worked for him after that change. I could not ever
reproduce it, but it seems the issue was putting down the key before
testing for resize/move in the code. Now who knows why this actually
matters, but apparently it works for the user in question and I don't
observe any unexpected behavior on my end when swapping the order. Like
the mouse/pointer code, we also now do a test for dragging before
actually trying a resize/move which is a little more consistent than
before. Fixes#9771.
Not sure when this actually started happening, but it's probably been
like this for years. Currently, the logic for the window-controls works
by simply checking if the osc is visible and then either enabling or
disabling the associated keybindings. The problem is that this can just
constantly spam mp.enable_keybindings/disable_key_bindings on every
single render call if the user disables the border at any point in time.
This does a lot of pointless work and also results in the logs being
spammed with lines like "disable-section". Clearly, this should just
work like the code for checking the input keybindings just above it.
Keep track of an internal state variable and check when it doesn't match
the osc visibility. In that case, we can then either enable or disable
the key bindings and just update the variable.
This allows us to more easily see the datapath from mpv to pipewire.
We know how often the callbacks are triggered, how big the buffers are
and how much data mpv provides to pipewire.
Flushing the cache is a hammer-for-a-screw operation, because it nukes
*all* renderer state, including the HDR peak detection state. When
enabling e.g. --hdr-compute-peak, or any other future methods of dynamic
tone mapping, this would lead to bad results (e.g. brightness
fluctuations) whenever the OSD state is updated.
Instead of flushing the cache to force an OSD re-render, instead just
update the frame signature directly whenever its osd_sync value changes.
This accomplishes effectively the same thing but without touching the
HDR state.
This is slightly violating the libplacebo abstraction in a way that
isn't publicly documented. To be on the safe side we could make a carbon
copy of the array before modifying it, but given that this is unlikely
to change upstream I'll probably just end up explicitly documenting it
instead of forcing the copy in mpv.
BSDs use compiler-rt instead of libatomic for atomic types. In this
case, we can handle it similar to how dl is detected. Check for the
library (allowing for it to fail), and then check for a header symbol
while linking latomic. Fixes#10906.
Currently, the lcms-related options are only defined when lcms2 is
enabled at build time. However, this causes issues (e.g. segfault) for
vo_gpu_next, which relies on the presence of these options (to forward
them to libplacebo).
(That libplacebo internally depends on lcms2 as well is an
implementation detail - compiling mpv *without* lcms against libplacebo
*with* lcms should be possible in principle)
Fixes: #10891Closes: #10856
The new single-pixel-buffer protocol is designed to optimize the case
for using a solid color as an underlay wl_surface. It works the same as
the wl_shm 1x1 pixel trick currently used, but it allows the compositor
to make optimizations with more certainty than the wl_shm trick.
This was previously implicitly included by the order of headers in
vo_dmabuf_wayland.c, but it is better to make it an explicit and reorder
the headers properly.
Meson uses the sysconfdir option for setting the global config
directory. This conveniently defaults to /etc if the prefix is set to
/usr which is nice for linux distros. BSDs tend to use /usr/local which
causes this value to become 'etc' by default which is not an absolute
path so you would need to set something like -Dsysconfdir=/usr/local/etc
as well in the configuration step. It turns out we can have our cake and
eat it too by just joining the paths of prefix and sysconfdir together.
In the case where -Dprefix=/usr, this still results in /etc/mpv as the
path since the path joining logic just drops the leading '/usr/'. For
the /usr/local case, it ends up as /usr/local/etc/mpv as expected. This
fixes#10882.
When the alpha channel is the first component, this code block gets
skipped by the continue, meaning the check for c==0 never passes.
Fix it by explicitly keeping track of whether bits have been set.
The legacy DRM API adds some complexity to the DRM code. There
are only 4 drivers that do not support the DRM Atomic API:
1. radeon (early GCN amd cards)
2. gma500 (ancient intel GPUs)
3. ast (ASPEED SoCs)
4. nouveau
Going forward, new DRM drivers will be guaranteed to support the atomic
API so this is a safe removal.
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's core already keeps track of whether or not it thinks a track is an
image. Some VOs (i.e. wayland) would benefit from knowing if what is
currently being displayed is an image or not so add a new VOCTRL that
signals this anytime we load a new file with a VO. Additionally, let's
add a helper enum for signaling the kind of content that is being
displayed. There is now MP_CONTENT_NONE (strictly for force window being
used on a track with no image/video), MP_CONTENT_IMAGE, and
MP_CONTENT_VIDEO. See the next commit for the actual usage of this (with
wayland).
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.
Related issue: #10868. While most protocols are in theory optional, a
small amount of them are absolutely essential and nothing will work
without them. We should make sure to error out in those cases and not
try to actually do anything. For wayland support in general,
wl_compositor support is obviously required. If there is no wl_surface,
you can't do anything. Additionally, vo_wlshm quite obviously requires
wl_shm so mark that one as well. vo_dmabuf_wayland needs linux_dmabuf,
viewporter, wl_shm, and wl_subcompositor. In practice, these are all
very standard protocols and shouldn't be missing but the linked issue
above is at least one example where a compositor was stuck on an ancient
version of a wayland interface.
Loaded 100 of 654 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
sfan5