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 <[email protected]>
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 [email protected] 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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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. <[email protected]>
Co-authored-by: Niklas Haas <[email protected]>
--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. <[email protected]>
Co-authored-by: Niklas Haas <[email protected]>
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 <[email protected]>
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 <[email protected]>
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.
Apparently, it is possible for touchbar.m to compile on non-macos
machines. Also, the disable switch didn't actually work either. Fix this
by using the require() function and making sure that Cocoa (should be
apple-only) is found in addition to the compile check passing which is
what waf does. Fixes#10847.
This is a very simple but easy way of doing it. Ideally, it would be
nice if we could also add some sort of introspection about shader
parameters at runtime, ideally exposing the entire list of parameters as
a custom property dict. But that is a lot of effort for dubious gain.
It's worth noting that, as currently implemented, re-setting
`glsl-shader-opts` to a new value doesn't reset back previously mutated
values to their defaults.
In practice this never led to any issues due to implementation
details of bstr_sanitize_utf8_latin1, but there's no guarantee that
a bstr is correctly null-terminated.
This allows the core of mpv to know about issues in the AO.
Otherwise playback will just freeze as no more data callbacks are sent
by PipeWire.
Also it allows mpv to try to reconnect the AO or find another, working
AO.
We want to add more logic to the stream event handler.
This logic should not be triggered during normal stream shutdown, so we
remove the listener beforehand.
Workflow virtual machines have now been updated so that moby package
contains rule for the newly added syscalls, such as 'clone3'.
Effectively reverts 64fa440c69 .
This older image has been deprecated and will be removed in December.
The images have also already had planned outages during which the CI
flow has been affected. Thus it feels like a good idea to clean
this up at this point.
Ref: actions/runner-images#5583
It turns out, even xy-VSFilter and XySubFilter do not
mangle colours if the video is native RGB regardless of
the sub's YCbCr header. libass' docs were also updated
to reflect this.
Deduplicate history like the fish shell. So for example
entering "cmd 1" then "cmd 2" then "cmd 3" then "cmd 1"
would result in a history of
[cmd 2][cmd 3][cmd 1]
instead of
[cmd 1][cmd 2][cmd 3][cmd 1]
Adds a function `history_add` to replace directly adding to history.
Adds an option `history_dedup` to activate the deduplication.
Defaults to on.
This was only needed because the mingw CI used to run on Ubuntu 20.04
which had a version of meson too old for mpv. This hasn't been the case
since we switched to 22.04 in f7164fcfac
and can now just use the package manager version.
Only matters when configuring ytdl_hook with `all_formats=yes`.
So far the tracks were ordered from worst to best quality.
Web players with quality selection always show the highest quality
option at the top. Since tracks are usually listed with the first
track at the top, that should also be the highest quality one.
yt-dlp/youtube-dl sorts it's formats from worst to best.
Iterate in reverse to get best track first.
This patch adds support for two extra WAVEFORMATEXTENSIBLE GUID tags
that can appear inside RIFF headers. It also adds support for extra
codec IDs that may appear as their own unique wSubFormats inside RIFF
headers, such as ATRAC9 inside matroska, as one example.
Fixes#10757.
I was confused in d3a28f12c9 why it
actually even worked, but after not being stupid, it's quite obviously
just a dangling pointer. The reason it only happens with
wp_presentation_feedback is because the object and listener actually
created in frame_callback not the presentation events itself (for vsync
timing reasons). So it is possible to free the object, but not
immediately recreate it again before quitting (unlike with the frame
callback). The actual comment is moved into feedback_presented (which is
first) but as of this commit it doesn't have the NULL setting logic
(that's the next one).
964692ad4c added some code to destroy
presentation_feedback we get in the presentation_discarded event. This
is the correct thing to do since the compositor could send us this
instead of feedback_presented. Without that change, mutter could
potentially leak memory on every frame.
Unfortunately, life is not so simple and wlroots and weston act
differently. These compositors only send one presentation_discarded
event if the mpv window is hidden. Not on every single missed frame like
mutter. Now in theory this shouldn't matter, but it also turns out that
mpv attempts to free the presentation feedback twice if you quit it
while it is hidden away (on weston and wlroots compositors only). The
inital wp_presentation_feedback_destroy in feedback_discarded fires, but
then the function goes off again in vo_wayland_uninit because
wl->feedback is apparently not NULL for some reason. Possibly, this is
some race condition but we can't just get rid of what's in
feedback_discarded since mutter needs this line. Instead, just hack it
by explicitly setting wl->feedback to NULL in feedback_discarded after we
destroy the presentation feedback. Some valgrind testing in mutter,
sway, and weston shows that this works correctly on all of those
compositors with various combinations of mpv being visible or not while
quitting. feedback_presented doesn't appear to exhibit this behavior so
we just leave that as-is.
666cb91cf1 added dmabuf_feedback, but it
was never actually free'd on uninit. Because this function requires
wayland protocols 1.24, we have to wrap it in an #if. Also throw in some
minor cosmetic changes in here.
This mapping isn't actually relevant until we have the Vulkan interop
merged, and it requires a newer version of libavutil than our minimum
requirement. So I'm going to remove it from master and put it in the
interop PR.
Fixes#10813
666cb91cf1 added support for v4 of the
dmabuf protocol. This was meant to be optional and the fallback support
for the old v2 (dates back to 2017[0] well before the 1.15
wayland-protocol version we depend on) was maintained. However, v4 added
several new functions and structs that of course aren't defined in old
protocol versions so naturally this breaks the build on those systems.
Since this is just a niche feature and not really critical to overall
wayland support in mpv, just give in and add another check in the build
system and #if out the newer stuff in wayland_common. v4 of linux-dmabuf
depends on wayland protocols 1-24[1], so go ahead and make that our new
check. Fixes#10807.
[0]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/a840b3634ad637b237f238d2efb9ab8f4712d5f4
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/commit/8a5cd28a0e84911a5339855cb32ed63fb57ea40a
mpv has a CONFIGURATION define which is defined at configure time in
both build systems and printed out when you use verbose flags. In waf,
this is line is exactly what the user passes on cli at configure time.
In meson, there's currently no way to do that (someone did recently open
up a PR that would make this possible), so we just hardcode the prefix
and call it a day. This is a bit of a tangent, but the build also
copies waf and sets an optimize variable (true or false) that is also
printed out on verbose output. For waf, this makes some sense because
the build has a specific --optimize option (internally all it does is
pass -O2). In meson, optimizing is a built-in option and we just set
anything that's not -O0 as "optimize". Furthermore, there is a new
optimization option added in meson 0.64 called "plain" which passes no
flags at all* so this logic would need to be updated to account for
this.
In retrospect, this is all just stupid though. optimization is not a
boolean value and there's no real use for treating it like one just
because that's what waf does. Let's remove it from the features array.
Instead, we can expose this information in the CONFIGURATION variable
along with the prefix option so we know exactly what optimization was
used in the compiled executable. For good measure, let's also throw in
buildtype since it's related.
*: https://github.com/mesonbuild/meson/commit/a590cfde0cf719c637b75e4784be0c0ae60e3b1f
Meson's master branch helpfully prints out a warning here now saying
that "find_library('libdl') starting in "lib" only works by accident
and is not portable". We'll go ahead and trust them and instead change
this to dl which works with no issues.
The old "meson build" build command was actually deprecated a few months
ago*. It turns out that you're supposed to use "meson setup build"
instead which has been around for years. Go ahead and be a good citizen
and update this in the CI. Also replace any mention of "meson build"
with "meson setup build" in the documentation as well and change the one
random hardcoded string we have in meson.build to "meson configure
build" (might as well).
*: https://github.com/mesonbuild/meson/commit/3c7ab542c0c4770241eae149b0d4cd8de329aee0
Console already respected the bottom margin to not overlap with the
bottom bar from the OSC, but it would still overlap with the window
decorations from the OSC.
Now everything is clipped above the top margin and no superfluous lines
are drawn.
vo_dmabuf_wayland has its own ra and context so it can handle all the
different hwdec correctly. Unfortunately, this API was pretty clearly
designed with vo_gpu/vo_gpu_next in mind and has a lot of concepts that
don't make sense for vo_dmabuf_wayland. We still want to bolt on a
ra_ctx, but instead let's rework the ra_ctx logic a little bit. First,
this introduces a hidden bool within the ra_ctx_fns that is used to hide
the wldmabuf context from users as an option (unlike the other usual
contexts). We also want to make sure that hidden contexts wouldn't be
autoprobed in the usual ra_ctx_create, so we be sure to skip those in
that function. Additionally, let's create a new ra_ctx_create_by_name
function which does exactly what says. It specifically selects a context
based on a passed string. This function has no probing or option logic
is simplified just for what vo_dmabuf_wayland needs. The api/context
validations functions are modified just a little bit to make sure hidden
contexts are skipped and the documentation is updated to remove this
entries. Fixes#10793.
vo_gpu and vo_gpu_next typically load hwdec interops on demand and
vo_dmabuf_wayland naively copied this logic. This is actually wrong
however since draw_frame in the VO always inherently relies on hwdec
being fully loaded. This can lead to a race condition during startup
which happens with --force-window=immediate. Avoid this by simply always
loading all the interops. In the case of vo_dmabuf_wayland, this is not
really a big deal since there's only vaapi and drmprime to load. Also
fixes#10791 (the other half).
We really need two roundtrips in the init function. The first one is for
running the registry and then second one is for ensuring the xdg_surface
and other potential wayland objects are configured at least once before
mpv does anything. We've been getting away with only doing the first for
a while via luck, but really we should do at least one more wait on the
compositor. Fixes#10791 (half of it).
Despite being run in a VM, the workflow actually copies the files back
to the host. We can then explictly print the error logs on failure in
their own separate section for visibility instead of it being hidden
within all the vm output.
Building on DRM platform without VAAPI broke because of misuse of
HAVE_VAAPI with #ifdef in place of #if. Also, the hwcontext_drm.h
header is not required for VAAPI builds, only DRM builds.
Originally, I considered warning once to be useful for figuring
out whether the change in logic regarding resetting requested
mode actually fixed the reported issue or not, but alas not everyone
was happy with that decision. Thus the log level will always be
debug. This enables us to lose one level of indent as well as a
variable, which is always positive.
Additionally, make the message more explicit regarding what could
possibly be implied by the mismatch, as it seems like this was
not always clear.
Otherwise mpv and the compositor can end up in an eternal loop where
mpv requests one mode, and compositor tells that the mode is not
that (and will most likely not change).
Additionally, log these mismatches - first time as a warning, and
later as debug logging.
It is verbose, but makes it more explicit that requested_decoration
takes in three values:
* 0: no specific mode requested by mpv
* ZXDG_TOPLEVEL_DECORATION_V1_MODE_CLIENT_SIDE: (!border)
* ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE: (border)
Pulled from https://github.com/mpv-player/mpv/pull/10382
The zwp_linux_dmabuf_v1 protocol version 4 provides a file descriptor
containing both formats and modifiers, which makes it possible for the
compositor to import the buffers onto planes using explicit modifiers.
This is an extremely important efficiency improvement, as the 3D
hardware can be left powered off altogether, the vaapi buffer being sent
directly from the video hardware to the display controller.
It could be possible to support zwp_linux_dmabuf_v1 version 3 as well,
but there is no reason beyond compatibility with old stacks. I would
recommend to ditch version 2 as well, as modifier-less formats aren’t
very useful nowadays.
Wayland VO that can display images from either vaapi or drm hwdec
The PR adds the following changes:
1. a context_wldmabuf context with no gl dependencies
2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects
no-op because there is no need to map/unmap the drmprime buffer,
and there is no need to manage any textures.
Tested on both x86_64 and rk3399 AArch64
dmabuf-wayland vo supports both DRMPRIME and VAAPI formats.
If upload filter is needed, we want to try VAAPI hwdec first
since most users will be using VAAPI, and there is a several second
delay when DRMPRIME hwdec is tried and fails.
Pushing E (aka Shift+e) cycles through Editions for containers
that support editions, such as Matroska, although this feature was not
documented before this commit.
The AO is feature-complete now.
As PipeWire also provides compatibility with PulseAudio, ALSA and Jack
we should put it before those for the autodetection to work.
The pure presence of PipeWire does not mean that it is actually driving
the audio session. For example it could only be meant for video.
Currently there is no proper API to detect this (see [0]), so we check
for the presence of audio sinks.
As soon as a proper API exists, we should use that.
[0] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1835
It turns out that wayland-scanner and wayland-protocols are both exposed
as configure options in waf meaning you can --enable/--disable them at
configure time. This is pretty nonsensical. If you want to control
wayland in the build, you should just use --enable-/--disable-wayland.
wayland-scanner and wayland-protocols should just be typical checks like
in the meson build.
vaapi allows for implicit conversion on upload, which has some
relevance as the set of supported source formats is larger than the
set of displayable formats. In theory, this allows for offloading the
conversion to the GPU - if you have any confidence in the hardware
and/or driver's ability to do the conversion.
Today, we actually track the 'input' and 'output' upload formats
separately all the way up until the point we do a check as to whether
the original source format is an accepted 'output' format and then
reject it if it is not.
This means that we're essentially ignoring all the work we did to track
those 'input' formats in the first place. But it also means that it's a
simple change to compare against the 'input' format instead. The logic
is already in place to do best format selection on both sides.
I imagine that if I read through the history here, wm4 tried to
implement all of this properly and then gave up in disgust after seeing
vaapi mangle various conversions.
This is particularly interesting for vo-dmabuf-wayland where it is only
possible to display the subset of valid vaapi formats that are
supported by the compositor, yet all playback has to go through vaapi.
Users will then be able to take advantage of all possible vaapi formats
to avoid having to do software format conversion.
This has been a long standing problem that I think was the root cause
for wm4's vaapi shitlist. As DRM explicit supports all possible rgba
orderings, but OpenGL only guarantees support for 'rgba8', something
has to happen to support import of dmabufs with non-native ordering.
Although undocumented, it appears that somewhere in the import on the
GL side, the ordering is swizzled to rgba - which makes sense as that's
the only way to be able to support importing all the different formats.
But we didn't know this, and we do our own swizzling based on the
original imgfmt - which matches the drm format. So we get double
swizzling and messed up colours.
As there is no way for us to express that the GL swizzle happened to
the rest of mpv, the easiest thing to do is fudge the format to the
natural ordering so the GL doesn't change anything, then our swizzling
will do the right thing in the end.
Note that this change doesn't handle 0rgb and 0bgr because they seem to
be affected by some additional feature/bug that is mangling the
ordering somewhere that equally affects Vulkan interop. That could be a
vaapi driver bug or something going on in ffmpeg.
A few years ago, wm4 got sufficiently annoyed with how vaapi image
format support was being discovered that he flipped the table and
introduced the shit list (which just included vaapi) to hard-code the
set of supported formats.
While that might have been necessary at the time, I haven't been able
to find a situation where the true list of supported formats was unsafe
to use. We filter down the list based on what the vo reports - and the
vo is already doing a thorough testing of formats, and if a format
makes it through that gauntlet, it does actually work.
Interestingly, as far as I can tell, the hwdec_vaapi probing code was
already good enough at the time (also written by wm4), so perhaps the
key difference here is that the driver side of things has improved.
I dug into this because of the support for the 422/444 high bit depth
vaapi formats I added to ffmpeg. These are obviously not in the hard
coded list today, but they work fine.
Finally, although it's positioned as a vaapi thing, it's really just
Intel specific, as the AMD vaapi driver has never exposed support for
anything except the formats used by the decoder/encoder profiles.
The logic around trying to establish what formats are supported by
vaapi is confusing, and it turns out that we've been doing it wrong.
Up until now, we've been going through the list of decoding profile
endpoints and checking the formats declared in those profiles to build
our list.
However, the set of formats that the vaapi driver can actually support
is potentially a superset of those supported by any given profile
endpoint. This master list is exposed by libavutil via the
av_hwframe_transfer_get_formats() function, and so we should use that
list as our starting point.
Perhaps surprisingly, this change actually removes no code, because we
still want the logic that enumerates endpoints and finds supported
formats for endpoints. We need this because we must have at least one
known sw format to initialise the hwframe_ctx with.
Additionally, while in the general case,
av_hwframe_transfer_get_formats can return different formats depending
on what format you initialise the hwframe_ctx with, I happen to have
read the libavutil code, and it doesn't care, so we just need to call
it once, we know we'll get back all known formats.
In practice, with an Intel vaapi driver, this will result in us
supporting a handful of extra formats for hwuploads - particularly
yuv420p (so no need to convert to nv12 first) and various orderings
of rgb(a).
Commit 740b701 introduced handling for subtitles with unknown duration,
but it came with a minor flaw where a track event that shares identical
start time with following track event will has its Duration value set
to 0, we don't want this to happen since it will prevent simultaneous
rendering of multiple track events.
This commit aims to address this issue.
When the width is exactly a multiple of SLICE_W (currently 256),
heap buffer overflow is reported by Address Sanitizer. So adjust
the maximum index for the line array accordingly.
We've had some annoying names for interops, which we can't simply
rename because that would break config files and command lines. So we
need to put a little more effort in and add a concept of legacy names
that allow us to continue loading them, but with a warning.
The two I'm renaming here are:
* vaapi-egl -> vaapi (vaapi works with Vulkan too)
* drmprime-drm -> drmprime-overlay (actually describes what it does)
* cuda-nvdec -> cuda (cuda interop is not nvdec specific)
mpv set _NET_WM_DESKTOP to 0xFFFFFFFF, which behaves differently with each window manager.
Instead, set the window property to STICKY, and let the window managers deal with it.
The new status quo is simple: all messages coming from libplacebo are
marked "vo/gpu{-next}/libplacebo", regardless of the backend API (vulkan
vs opengl/d3d11).
Messages coming from mpv's internal vulkan code will continue to come
from "vo/gpu{-next}/vulkan", and messages coming from the vo module
itself will be marked "vo/gpu{-next}".
This is significantly better than the old status quo of vulkan messages
coming from "vo/gpu{-next}/vulkan/libplacebo" whereas opengl/d3d11
messages simply came from "vo/gpu{-next}", even when those messages
originated from libplacebo.
(It's worth noting that the the destructor for the log is redundant
because it's attached to the ctx which is freed on uninit anyway)
Managed to go completely unnoticed for months (who was the bad person
that introduced these*). Fairly self-explanatory. After getting
ProviderInfo from randr, we need to free it. The other one is pretty bad
because it leaked every frame (ouch). It turns out that you're supposed
to free any event data after you cast a generic event to an
XGenericEventCookie. Free that as well.
*: It was me.
The wayland presentation time code currently always assumes that only
CLOCK_MONOTONIC can be used. There is a naive attempt to ignore clocks
other than CLOCK_MONOTONIC, but the logic is actually totally wrong and
the timestamps would be used anyway. Fix this by checking a use_present
bool (similar to use_present in xorg) which is set to true if we receive
a valid clock in the clockid event. Additionally, allow
CLOCK_MONOTONIC_RAW as a valid clockid. In practice, it should be the
same as CLOCK_MONOTONIC for us (ntp/adjustime difference wouldn't
matter). Since this is a linux-specific clock, add a define for it if it
is not found.
This has had no effect since libplacebo v4.192.0, and was deprecated
upstream a year ago. No deprecation period in mpv is justified by this
being a debug / work-around option.
Removed the outdated information about environmental brightness
with respect to --gamma-factor, and mention that the option is
deprecated and subject to future removal. Also deprecated the
--gamma-auto option as it relies on the same outdated way of doing
things.
This brings vo_gpu_next's behavior more in line with vo_gpu. Currently,
the status quo was that `vo_gpu_next` generated subtitles with the full
resolution of the dst crop, even though practical limitations of
libplacebo meant that such subtitles inevitably got cut off at the video
boundaries. This was actually a worse status quo than `vo_gpu`, which
simply constrained subtitles to the video dimensions to prevent these
issues.
With this change, the behavior is the same as `vo_gpu`, which has the
exact same problem w.r.t interpolation. Users are back to choosing
between --blend-subtitles=yes and not having subtitles in margins,
and using --blend-subtitles=no and not having subtitle interpolation.
There are different pros and cons to each approach, and I still
ultimately plan on allowing libplacebo to interpolate subtitles even in
the black bars, to solve this issue once and for all. But for now, let's
not let perfect be the enemy of good.
No attempt is made to implement `--blend-subs=video`, which I consider
deprecated.
Fixes: https://github.com/mpv-player/mpv/issues/10272
Specifying the id of the target node during stream connect is
deprecated. Instead the property target.object should be used to link
by target serial or name. Using the name allows us to drop a bunch of
custom code.
I actually don't quite understand why this is needed, since in theory we
should already be doing the rotation as part of applying the crop. But I
guess that code doesn't quite work. This is the only way it works, so
it's probably correct. (And note that `vo_gpu` does the same internally)
This fixes an issue where blend stages with multiple passes got
overwritten by later passes, with only the final pass (typically the
overlayp pass) actually being shown.
Alphabetizing the extensions cleans up the code and makes it less
ambiguous where newer extensions should be added. The video line
also was wrapped to 72 characters for cleanliness.
When af_scaletempo2.c:process() detects a format change, it goes back
through mp_scaletempo2_init() to reinitialize everything. However,
mp_scaletempo2.input_buffer is not necessarily reallocated due to a
check in af_scaletempo2_internals.c:resize_input_buffer(). This is a
problem if the number of audio channels increases, since without
reallocating, the buffer for the new channel(s) will at best point to
NULL, and at worst uninitialized memory.
Since resize_input_buffer() is only called from two places, pull size
check out into mp_scaletempo2_fill_input_buffer(). This allows each
caller to decide whether they want to resize or not. We could be
smarter about when to reallocate, but that would add a lot of machinery
for a case I don't expect to be hit often in practice.
Certain combinations of hardware formats require the use of hwmap to
transfer frames between the formats, rather than hwupload, which will
fail if attempted.
To keep the usage of vf_format for HW -> HW transfers as intuitive as
possible, we should detect these cases and do the map operation instead
of uploading.
For now, the relevant cases are moving between VAAPI and Vulkan, and
VAAPI and DRM Prime, in both directions. I have introduced the IMGFMT
entry for Vulkan here so that I can put in the complete mapping table.
It's actually not useless, as you can map to Vulkan, use a Vulkan
filter and then map back to VAAPI for display output.
Historically, HW -> HW uploads did not exist, so the current code
assumes they will never happen. But as part of introducing Vulkan
support into ffmpeg, we added HW -> HW support to enable transfers
between Vulkan and CUDA.
Today, that means you can use the lavfi hwupload filter with the
correct configuration (and previous changes in this series) but it
would be more convenient to enable HW -> HW in the format filter so
that the transfers can be done more intuitively:
```
--vf=format=fmt=cuda
```
and
```
--vf=format=fmt=vulkan
```
Most of the work here is skipping logic that is specific to SW -> HW
uploads doing format conversion. There is no ability to do inline
conversion when moving between HW formats, so the format must be
mutually understood to begin with.
Additional work needs to be done to enable transfers between VAAPI
and Vulkan which uses mapping, rather than uploads. I'll tackle that
in the next change.
Today, lavfi filters are provided a hw_device from the first
hwdec_interop that was loaded, regardless of whether it's the right one
or not. In most situations where a hardware based filter is used, we
need more control over the device.
In this change, a `hwdec_interop` option is added to the lavfi wrapper
filter configuration and this is used to pick the correct hw_device to
inject into the filter or graph (in the case of a graph, all filters
get the same device).
Note that this requires the use of the explicit lavfi syntax to allow
for the extra configuration.
eg:
```
mpv --vf=hwupload
```
becomes
```
mpv --vf=lavfi=[hwupload]:hwdec_interop=cuda-nvdec
```
or
```
mpv --vf=lavfi-bridge=[hwupload]:hwdec_interop=cuda-nvdec
```
If we want to be able to handle conversion between hw formats in filter
chains, then we need to be able to load hwdec_interops from filters, as
the VO is only ever going to initialise one interop, based on its
configuration. That means that in almost all situations, only one of
the required interops will be loaded at the time the filter is
initialised.
The existing code has some assumptions that new hwdec_interops will not
be loaded after the vo has picked one to use. This change fixes two
instances:
* Refusing to load a new hwdec_interop if there is at least one
loaded already.
* Not recalculating the set of formats known to the autoconvert
filter when a new output format shows up. This leads to autoconvert
not knowing that a new format is supported when the hwdec interop is
lazily loaded.
It turns out that it's generally more useful to look up hwdecs by image
format, rather than device type. In the situations where we need to
find one, we generally know the image format we're dealing with. Doing
this avoids us having to create mappings from image format to device
type.
The most significant part of this change is filling in the image format
for the various hw interops. There is a hw_imgfmt field today today, but
only a couple of the interops fill it in, and that seems to be because
we've never actually used this piece of metadata before. Well, now we
have a good use for it.
ASS must only automatically break at ASCII spaces (\x20), but other
subtitle formats might expect more breaking oppurtinities.
Especially non-ASS subs in scripts, which typically do not use (ASCII)
spaces to seperate words, like e.g. CJK, might overflow the screen
if the conversion didn't insert additional linebreaks (ffmpeg does not).
Thus try to enable Unicode linebreaking for converted subs and the OSD
if libass is new enough. The feature may still be unavailable at runtime
if libass wasn't build with Unicode linebreaking support.
Previously, running a debug build of mpv would crash with this output
when preinit() at vo_libmpv.c:732 calls control(vo, VOCTRL_PREINIT, NULL):
Swift/Optional.swift:247: Fatal error: unsafelyUnwrapped of nil optional
This comes from this line of code:
var data = UnsafeMutableRawPointer.init(bitPattern: 0).unsafelyUnwrapped
Unsafely unwrapping a UnsafeMutableRawPointer.init has always been UB,
but the Swift runtime began asserting on it in debug builds a couple macOS
versions ago.
Previously we would only call list_devs() on available AOs if an AO
*did not* have a hotplug_init() callback or for the first one that *did*
have it.
This is problematic when multiple fully functional hotplug-capable AOs
are available.
The second one would not be able to contribute discovered devices.
This problem prevents ao_pipewire from introducing full hotplug support
with hotplug_init().
When a platform has multiple valid AOs that can provide hotplug events
we should try to use the one that also provides playback.
Concretely this will help when introducing hotplug support for
ao_pipewire.
Currently ao_pulse is probed by ao_hotplug_get_device_list() before
ao_pipewire and on the common setups where both AOs could work pulse
will be selected for hotplug handling.
This means that hotplug_init() of ao_pipewire will never be called and
list_devs() has to do its own initialization.
But if ao_pulse is non-functional or not compiled-in suddenly
ao_pipewire *must* implement hotplug_init() for hotplugging events to
work for all.
Also if the hotplug ao_pulse connects to a PulseAudio instance that is
not emulated by the same PipeWire instance as the playback ao_pipewire
the hotplug events are useless.
30 characters are not a lot.
Also when the name is calculated from the allocation site the line
number will be the at the end of the name, so truncating it is
especially inconvenient.
I'm adding support in ffmpeg for the XV36 format which will be used
by VAAPI for 12bit 4:4:4 content. It's an undefined-alpha channel
variant of Y412 which is itself a 12bit+4bits padding variant of Y416.
We currently have a repacker for full four channel cccc16, and for
three channel ccc16, but nothing for ccc16x16 with the undefined alpha
channel.
It's simple enough to add one using the existing macros.
uau did some investigation and noticed that we do not send a wakeup
event when we encounter end-of-stream in ao_read_data(), in contrast to
the equivalent logic for push AOs in ao_play_data().
Inserting that wakeup fixes the original problem of lack of
reinitialization on a format change without the problems we saw with
the previous attempted fix.
Fixes#10566
We have previously had a problem where pull AOs (such as pipewire)
would not reinitialize on a format change when going between two
audio-only files. In such a situation, playback would stop after the
first file.
We initially attempted to fix this by explicitly draining on EOF, which
solves that problem but introduces a blocking step where we don't
actually want one, breaking gapless audio, and causing dropped frames
at the end of playback for files with video in them too.
So, let's undo these changes and do something better in the next
commit.
The error description in #10545 could indicate that we are overflowing
we are corrupting the buffer metadata ourselves through out-of-bound
writes.
This check is also present in pw-cat so it seems to be expected for
b->requested to exceed the actual available buffer space.
Potential fix for #10545
52aed495cb ("audio: drain ao on EOF") introduced logic to drain an AO
when EOF of the input has been reached.
When no AO however is present this leads to a NULL-dereference.
Fixes#10556
Facing down the multitude of ways to somehow wrangle the get_fn pointer
out of the GL environment and into libplacebo, I decided the easiest is
to just store it inside the GL struct itself.
The lifetime of this get_fn function is a bit murky, since it's not
clear on whether or not it survives the VO init call (especially in the
case of the GL render API, which explicitly states that parameters do
not need to survive the call they're passed to), so just add a
disclaimer.
(It's fine for us to use like this because `gpu_ctx_create` is still
part of VO init)
Closes https://code.videolan.org/videolan/libplacebo/-/issues/216
Every format that was not detected as a video format was added to the
audio tracks. This resulted in e.g. YouTube storyboards from ending up
in the list of audio tracks.
Now formats that are already known to be neither video formats nor audio
formats, will also not end up in any track list.
Formats where it is unknown if they are video or audio get added to
tracks if `force_all_formats` is used, otherwise only
formats that are known to contain video or audio become video or audio
tracks respectively.
https://github.com/yt-dlp/yt-dlp/issues/4373#issuecomment-1186637357
Add xoshiro as a PRNG implementation instead of relying
on srand() and rand() from the C standard library. This,
in particular, lets us avoid platform-defined behavior with
respect to threading.
Since the previous commit introduced the notion of a features dictionary
that conveniently tells us whether or not to use a feature in a simple
yes/no, we can make use of this everywhere in the build. Instead of
doing something like 'if foo.()', change it to 'if feature['foo']
instead. This enforces a consistent standard instead of having a lot of
different possible combinations of booleans that may or may not do
something.
mpv has a ton of defines that are generated during building. Previously,
the meson build just had this as a big giant wall of text that manually
set each one but we can do this smarter. Instead, change the "features"
object to a dictionary and have it hold the name of the feature and its
value (true/false on whether it is enabled). Then at the end, just loop
through it and reformat the name of the feature so it becomes
HAVE_FEATURE. A side effect of this is that a lot of extra defines are
generated that aren't actually used in the code, but the waf build
worked like this for years anyway. A nice result of this is that the use
of foo['use'] internally can be completely eliminated and replaced with
feature['foo'] instead when needed.
The build was a bit overzealous with using dictionaries. These are fine
for when the feature checking is more complicated, but there's no point
in having them for the simplier things. This also eliminates the usage
of the 'name' key completely.
One would expect that e.g.
`--script-opts=ytdl_hook-all_formats=no --ytdl-format=bestaudio` and
`--script-opts=ytdl_hook-all_formats=yes --ytdl-format=bestaudio`
to play the exact same tracks without manual intervention.
This already worked when two formats were requested.
For a single format with `all_formats=yes` it would also play a track
that was not requested when available. This was inconsistant with the
behavior of `all_formats=no` (default), which would not play a second
track when only a single one was requested.
This combined with #10395 now plays the exact same tracks with
`all_formats=yes` as without, even when only one format is requested.
In wayland-protocols 1.25, xdg-shell got a version bump which added the
configure_bounds event. The compositor can send this to clients to
indicate that they should not resize past a certain size. For mpv, we'll
choose to only listen to this on reconfig events (i.e. when the window
first appears and if the video resolution changes later in the
playlist). However, this behavior is still exposed as a user option
(default on) because it will neccesarily conflict with a user setting a
specific geometry size and/or window scale. Presumably, if someone is
setting a really large size that goes beyond the bounds of their
monitor, they actually want it like that. The wayland-protocols version
is newer-ish, but we can get around having to poke the build system by
just using a define that exists in the generated xdg-shell header.
Unexpectedly, x11->screenrc actually doesn't update with randr events.
In a multimonitor configuration it could easily be wrong depending on
the user's layout. While it's tempting to modify the logic so screenrc
changes with randr events, this rectangle is currently used everywhere
and as far as we know, this pretty much works fine. Instead, just loop
over the randr displays that we have and select it if it overlaps with
the winrc. This follows the same logic as the fps selection in the case
of the mpv window overlapping multiple monitors (the last one is
selected).
Tracks are marked as default tracks based on what yt-dlp/youtube-dl
returns in the field `requested_formats`. The problem is that this field
only exists when there is more then one requested format.
So `ytdl-format=bestvideo+bestaudio` would have that field,
but `ytdl-format=bestaudio` would not,
leading to no tracks being marked as default tracks.
The requested formats can also be found under `requested_downloads`,
which exists regardless of the number of requested formats.
However when there is more then one requested format,
`requested_downloads` doesn't contain those formats directly and instead
has a field `requested_formats` that is identical to the other
`requested_formats`. Therefore use `requested_downloads` as a fallback
for when `requested_formats` doesn't exist.
ae768a1e14 forgot to bump the required
libdrm version however Debian 11 just barely misses the requirement,
which is a good reason not to require it unconditionally anyway.
The older overlay based drmprime hwdec should be preferred to the new
texture mapping one. This is for a few reasons:
1. In any situation where both hwdecs work, it's probably right to use
the more mature one by default, for now.
2. It seems like the overlay path primarily works on older SoCs
where the texture path is less performant, and in at least one
tested case is visually buggy, so you definitely want it to be
tried first.
3. In situations where the old hwdec doesn't work, it will fall through
to the new one.
sfan5 found a few things after I pushed the change, so this fixes them.
* Use-after-free on drm_device_Path
* Not comparing render_fd against -1
* Not handling dup() errors
This gives pull-based AOs the chance to play all queued audio.
Also it will make sure that the audio has finished playing so we can
reinitialize the AO if format changes are necessary.
Fixes#10018Fixes#9835Fixes#8904
In the confusing landscape of hardware video decoding APIs, we have had
a long standing support gap for the v4l2 based APIs implemented for the
various SoCs from Rockship, Amlogic, Allwinner, etc. While VAAPI is the
defacto default for desktop GPUs, the developers who work on these SoCs
(who are not the vendors!) have preferred to implement kernel APIs
rather than maintain a userspace driver as VAAPI would require.
While there are two v4l2 APIs (m2m and requests), and multiple forks of
ffmpeg where support for those APIs languishes without reaching
upstream, we can at least say that these APIs export frames as DRMPrime
dmabufs, and that they use the ffmpeg drm hwcontext.
With those two constants, it is possible for us to write a
hwdec-interop without worrying about the mess underneath - for the most
part.
Accordingly, this change implements a hwdec-interop for any decoder
that produces frames as DRMPrime dmabufs. The bulk of the heavy
lifting is done by the dmabuf interop code we already had from
supporting vaapi, and which I refactored for reusability in a previous
set of changes.
When we combine that with the fact that we can't probe for supported
formats, the new code in this change is pretty simple.
This change also includes the hwcontext_fns that are required for us to
be able to configure the hwcontext used by `hwdec=drm-copy`. This is
technically unrelated, but it seemed a good time to fill this gap.
From a testing perspective, I have directly tested on a RockPRO64,
while others have tested with different flavours of Rockchip and on
Amlogic, providing m2m coverage.
I have some other SoCs that I need to spin up to test with, but I don't
expect big surprises, and when we inevitably need to account for new
special cases down the line, we can do so - we won't be able to support
every possible configuration blindly.
Whether or not the GNOME project has a tendency to make life
difficult for anyone outside their ecosystem, the user manual is
no place for childish rants such as this.
Keep it to what is relevant for users.
I already added the equivalent logic for dmabuf_interop_pl previously
but I skipped the GL support because importing dmabufs into GL requires
explicitly providing the DRM format, and if you are taking a
multi-plane format and trying to treat each plane as a separate layer,
you need to come up with a DRM format for each synthetic layer.
But my initial testing has shown that the RockPRO64 board I've got to
work on drmprime hwdec will only produce NV12 in a single layer multi
plane format, and it doesn't have Vulkan support, so I have had to
tackle the GL multi-plane problem.
To that end, this change introduces the infrastructure to provide new
formats for synthetic layers. We only have lookup code for NV12 and
P010 as these were the only ones I could test.
Annoyingly, libva and libdrm use different structs to describe dmabufs
and if we are going to support drmprime, we must pick one format and do
some shuffling in the other case.
I've decided to use AVDRMFrameDescriptor as our internal format as this
removes the libva dependency from dmabuf_interop. That means that the
future drmprime hwdec will be able to populate it directly and the
existing hwdec_vaapi needs to copy the struct members around, but
that's cheap and not a concern.
With the files renamed, we can now disentangle the shared private
struct between the interops and hwdec_vaapi. We need this separation
to allow the future drmprime hwdec to use the interops.
This is the first in a series of changes that will introduce a drmprime
hwdec. As our vaapi hwdec is based around exporting surfaces as
drmprime dmabufs, we've actually got a lot of useful code already in
place in the GL/PL interops. I'm going to reorganise and adjust this
code to make the interops usable with the new hwdec as well.
The first step is to rename the files and functions. There are no
functional or other changes here. They will come next.
Avoids another pitfall on systems where the first card has a primary
node but is not capable of KMS. With this change --drm-context=drm
should work correctly out-of-the-box in all cases.
On S905X (meson) boards drmModeAtomicCommit called from
disable_video_plane in hwdec_drmprime_drm.c might still be running when
another call is made from queue_flip in context_drm_egl.c.
This causes EBUSY error in queue_flip, and causes mpv to hang.
The example given in #3024 would not play the correct video when
combined with `--ytdl-raw-options=yes-playlist=`.
Allowing `youtube:tab` as extractor and correcting the id check fixes
that.
This is somewhat academic for now, as we explicitly ask for separate
layers and the scenarios where multi-plane images are required also use
complex formats that cannot be decomposed after the fact, but
nevertheless it is possible for us to consume simple multi-plane
images where there is one layer with n planes instead of n layers with
one plane each.
In these cases, we just treat the planes the same as we would if they
were each in a separate layer and everything works out.
It ought to be possible to make this work for OpenGL but I couldn't
wrap my head around how to provide the right DRM fourcc when
pretending a plane is a layer by itself. So I've left that
unimplemented.
A VRAM memory leak was present in d3d11 when `idle=yes` and playback
stops for an item. This patch re-enables some of the code which is
only used during diagnostic which fixes the issue.
Generally, the hard-coded sizes used for the OSC elements are
comfortable regardless of the font used, but the timecode fields have
relatively many characters, and so are affected to a greater degree by
fonts with a wider or narrower average character width than expected.
This allow users to adjust the space reserved for the timecode fields to
compensate.
Using cmsFLAGS_HIGHRESPRECALC results in Little-CMS generating an
internal 49x49x49 3DLUT, from which it then samples our own 3DLUT. This
is completely pointless and not only destroys the accuracy of the 3DLUT,
but also results in no additional gain from increasing the 3DLUT
precision further.
The correct flag for us to be using is cmsFLAGS_NOOPTIMIZE, which
suppresses this internal 3DLUT generation and gives us the full
precision. We can also specify cmsFLAGS_NOCACHE, which is negligible but
in theory prevents Little-CMS from unnecessary pixel equality tests.
pw_core_disconnect frees the core, so accessing it afterward to
destroy the context is not allowed.
Instead, just destroy the context, the first thing it does is disconnect
all cores for us.
mpv only remembers volume for two channels.
Always apply the same volume to all channels in case of
non-stereo layout similarly to ao_pulse.
Don't try to do anything smart when averaging volumes,
normally they are equal anyway.
This was introduced in 7fb972fd39 and
later revised in f5a094db04. Transparency
in EGL/X11 has been broken upstream for years in Mesa unfortunately.
However, the first commit claimed to have found a way to preserve
transparency by doing a trick with picking EGLConfigs (the second commit
revises this but keeps the logic in place). However, it doesn't appear
that the first commit actually fixes anything (transparency doesn't work
on my machine) and no one else seems to have reported it working. On the
other hand, if Mesa does ever actually fix this, transparency would
immediately be broken since mpv would always set the EGL_ALPHA_SIZE to
0. Go ahead and remove this since it doesn't seem to have any actual
utility and is technically a bit of a timebomb (not that deleting two
lines is a lot of work but still) if upstream ever does fix this.
The meson build does a lot of checks and if you aren't familiar with the
internals of the meson.build, it may not be clear what is actually
enabled and what isn't. It turns out that meson has a handy function,
summary, exactly for this. This just prints a pretty summary of some
notable features in the build. It's not meant to be a comprehensive
list, but rather just what users are likely to care the most about (i.e.
x11, vulkan, etc.)
This was introduced in 04257417 without a clear explanation of the bug
it was solving, so I have no idea if it's still needed (or why it ever
was). And it definitely creates unexpected behavior, e.g. forced
clipping when converting between float and floatp.
I therefore think we should simply remove this logic and see if it
regresses anything else, then fix those other bugs *properly* (if
they're still around).
Fixes#9979
Commit 7f4841ff sorted the bindings so that if the same key was bound
more than once, then the newest binding takes priority (sorted last).
However, it got the comparison function wrong, which means the result
of the sort depended on the algorithm and not on the actual data, so
the priority for keys with more than one binding was still arbitraty.
Fix the sort function, and finally ensure that later binding acutally
override earlier bindings of the same key.
This commit kind of mixes several related things together. The main
thing is to avoid calling any XPresent functions or internal functions
related to presentation when the feature is not auto-whitelisted or
enabled by the user. Internally rework this so it all works off of a
use_present bool (have_present is eliminated because having a non-zero
present_code covers exactly the same thing) and make sure it updates on
runtime. Finally, put some actual logging in here whenever XPresent is
enabled/disabled. Fixes#10326.
Previously if the raw command_native_async returned an error then the
callback function was run directly. This meant that script writers
potentially had to account for both synchronous and asynchronous logic
in the callback, which can happen even with seemingly 'safe' commands
if the mpv event queue is full.
This was at odds with the Javascript implementation of
the function, which always runs the callback asynchronously.
Now the mp.add_timeout function is used to run the callback
asynchronously on error, replicating the Javascript implementation.
This provides consistency for developers in how the callback is handled
in Lua, and increases consistency between the Lua and Javascript APIs.
With the recent addition of the libxpresent, it should improve frame
timings for most users. However, there were known cases of bad behavior
(Nvidia) which lead to a construction of a whitelist instead of just
enabling this all the time. Since there's no way to predict whatever
combination of hardware/drivers/etc. may work correctly, just give users
an option to switch the usage of xorg's presentation statistics on/off.
The default value, auto, works like before (basically, Mesa drivers and
no Nvidia are allowed), but now one can force it on/off if needed.
The old logic always reset the x11->has_mesa/has_nvidia values on every
loop through the provider. This meant that it would always just match
whatever the last provider happened to be. So in the case of a dual GPU
system, if nvidia was the very first provider and the integrated
intel/amd card was the second (in practice, this is probably mostly the
other way around), then mpv would set has_mesa to true and has_nvidia to
false and thus try to use presentation. This is not the intended
behavior. Just rework this by also checking x11->has_mesa/has_nvidia in
the loop so a true value from the previous iteration is preserved.
This code was taken from the older vo_vaapi driver, which does
use the vaapi format list, but the new driver has no use for
these formats, as it is only interested in va surfaces that
can be mapped to wl buffers. The format doesn't enter into
it at all.
Immediately after this, d3d11 is defined again and the rest of the
meson.build uses that. Probably, this dictionary was from the original
meson PR and removing it was forgotten at some point while stuff was
being rewritten.
This builds off of present_sync which was introduced in a previous
commit to support xorg's present extension in all of the X11 backends
(sans vdpau) in mpv. It turns out there is an Xpresent library that
integrates the xorg present extention with Xlib (which barely anyone
seems to use), so this can be added without too much trouble. The
workflow is to first setup the event by telling Xorg we would like to
receive PresentCompleteNotify (there are others in the extension but
this is the only one we really care about). After that, just call
XPresentNotifyMSC after every buffer swap with a target_msc of 0. Xorg
then returns the last presentation through its usual event loop and we
go ahead and use that information to update mpv's values for vsync
timing purposes. One theoretical weakness of this approach is that the
present event is put on the same queue as the rest of the XEvents. It
would be nicer for it be placed somewhere else so we could just wait
on that queue without having to deal with other possible events in
there. In theory, xcb could do that with special events, but it doesn't
really matter in practice.
Unsurprisingly, this doesn't work on NVIDIA. Well NVIDIA does actually
receive presentation events, but for whatever the calculations used make
timings worse which defeats the purpose. This works perfectly fine on
Mesa however. Utilizing the previous commit that detects Xrandr
providers, we can enable this mechanism for users that have both Mesa
and not NVIDIA (to avoid messing up anyone that has a switchable
graphics system or such). Patches welcome if anyone figures out how to
fix this on NVIDIA.
Unlike the EGL/GLX sync extensions, the present extension works with any
graphics API (good for vulkan since its timing extension has been in
development hell). NVIDIA also happens to have zero support for the
EGL/GLX sync extensions, so we can just remove it with no loss. Only
Xorg ever used it and other backends already have their own present
methods. vo_vdpau VO is a special case that has its own fancying timing
code in its flip_page. This presumably works well, and I have no way of
testing it so just leave it as it is.
Unfortunately there's a certain company that makes graphics drivers that
are harder to deal with. The next commit aims to implement presentation,
but some empirical testing from users show that it's actually broken.
Give up and just tap into Xrandr so we can figure what drivers (or well,
providers by the extension terminology) are driving the screen.
Basically if we find intel, amd, or radeon, assume it's a Mesa driver.
If we find nvidia, then it must be nvidia. This detection requires randr
1.4 (which means using presentation in mpv secretly depends on randr
1.4), but this protocol version is nearly a decade old anyway so
probably 99.9% of users are fine. Do the version query check and all
that anyway just to be on the safe side.
Wayland had some specific code that it used for implementing the
presentation time protocol. It turns out that xorg's present extension
is extremely similar, so it would be silly to duplicate this whole mess
again. Factor this out to separate, independent code and introduce the
mp_present struct which is used for handling the ust/msc values and some
other associated values. Also, add in some helper functions so all the
dirty details live specifically in present_sync. The only
wayland-specific part is actually obtaining ust/msc values. Since only
wayland or xorg are expected to use this, add a conditional to the build
that only adds this file when either one of those are present.
You may observe that sbc is completely omitted. This field existed in
wayland, but was completely unused (presentation time doesn't return
this). Xorg's present extension also doesn't use this so just get rid of
it all together. The actual calculation is slightly altered so it is
correct for our purposes. We want to get the presentation event of the
last frame that was just occured (this function executes right after the
buffer swap). The adjustment is to just remove the vsync_duration
subtraction. Also, The overly-complicated queue approach is removed.
This has no actual use in practice (on wayland or xorg). Presentation
statistics are only ever used after the immediate preceding swap to
update vsync timings or thrown away.
Technically this was wrong. If you passed -Dvdpau=enabled but did not
have x11 (a requirement for this), the build would silently just not
build the vdpau VO. The correct behavior is for it to be a hard error.
Accomplish this by using the require function and making sure that x11
is indeed being used before attempting to find the library.
In win32 build, if libass and libfontconfig appear after libmingwex
during linking, crash happens whenever fontconfig calls to opendir().
Moving them before ffmpeg makes sure they always appear first.
More info on https://github.com/shinchiro/mpv-winbuild-cmake/issues/217.
The first set iterates through all standard FFmpeg layouts and
checks that those which fit MP_NUM_CHANNELS succeed.
The second set iterates through built-in named channel layouts,
and attempts to convert them to AVChannelLayouts.
This is the new FFmpeg channel layout structure, which now
combines channel count and layout into a single location.
Only unspecified (channel count only) and native (channel layout
mask based) layouts are currently supported for the initial move
towards non-deprecated APIs.
This shouldn't have mattered but apparently qtile is unable to get the
app id if you set it after the initial surface commit. Wayland is a mess
anyway so just shuffle this around so that the frame callback and
surface commit are the last things registered in vo_wayland_init. This
works around qtile and, in theory, doesn't appear to break anything
else. Fixes#10280.
Some wayland compositors (i.e. weston) get extremely picky about
committed buffer sizes not matching the configured state. In particular,
weston throws an error on you if you attempt to launch with
--window-maximized and use opengl (vo_vaapi_wayland actually errors as
well in this case, but that's a different issue). The culprit here is
actually wl_egl_window_create. This creates an initial buffer at the
sizes passed in the arguments which is what weston doesn't like.
Instead, move the egl_window creation call to the resize function. This
ensures that mpv is using the size obtained via the toplevel event, and
it should always be the buffer size we want.
The `absolute` value was incorrectly labelled as the default instead of
the value named `default`, which was somewhat confusing. When the newer
default option was added in 679e410 it seems like wm4 forgot to remove
the label in the manual on the previous default.
TL;DR: previously a JavaScript VM was created + destroyed whenever
a sub track was initialized, even if no jsre filter was set.
Now a JS VM is created only if jsre filters were set.
Sub filters are initialized once when a subtitle track is chosen, and
then whenever the sub track changes or when some sub options change.
Sub filters init is synchronous - playback is suspended till it ends.
A filter can abort init early (get disabled) depending on conditions
specific to each filter. The regex and jsre filters aborted early
if the filter is disabled (default is enabled) or if the track is not
ass (relativey rare, e.g. bitmap subs).
The init then iterates over the filter strings, and if the result is
empty (common - no filter was added, but also if all strings failed
regex init) then it's also aborted during init.
While this iteration step is cheap with filter regex, with jsre it
requires instanciating the JS VM (mujs) in advance in order to parse
the filter strings at the list, and the VM is then destroyed if the
list ends up empty.
This VM create+destroy is fast but measurable (0.2 - 0.7 ms, slowest
measured on 2010 MacBook Air), but can be avoided altogether if we
check that the filter list is not empty before we create the VM.
So now we do just that.
This way mingw-w64 becomes the first CI workflow to build gpu-next.
Unfortunately, currently neither wscript or meson has gpu-next or
libplacebo-next as an option that one can require.
This was actually always bugged, but we just got lucky that compositors
ignored it. The egl window was created only using wl->geometry's
coordinates but those do not include the scale factor. So technically,
the initial window creation always had the wrong size (off by whatever
the scaling factor is). The resize call later fixes it because that
correctly uses wl->scaling so in practice nothing bad was seen.
wlroots's master branch has started sending an error in this case
however and this is what trips it. Fix it correctly by using the scale
factor. This is what cd3b4edea0 tried to
fix (but was incorrect).
cd3b4edea0 is not correct and had some
unexpected breakage with geometry/resizing. Rather than completely
revert it, this commit restores the set_surface_scaling call as well as
rearranges some other things in the wayland init/reconfig process to
make it simplier. The next commit properly fixes what
cd3b4edea0 tried to fix.
Just a couple of small changes. First, the obvious one is to remove the
bogus wl->window_size = wl->vdparams; line in the configure conditional.
The reconfig always unconditionally sets the window_size here so there's
no need to duplicate it. The more important change is to remove the
usage of set_surface_scaling. This function is just to handle when
scaling changes and for setting the initial scale, it was called in the
reconfig. This, however, causes some weird issues in the latest
sway/wlroots where it can try to divide a buffer by an inappropriate
scale factor. This is possibly due to some weird ordering of events and
only occured in opengl for some reason.
Luckily, it turns it out it's not neccessary to set the scaling here at
all. The surface enter event is already setup to handle scale changes.
On an HIDPI display, mpv will initially assume a scale of 1 but the
surface actually enters the wl_output, it will automatically readjust
and resize itself to the appropriate scale value. This works on the
initial launch of the mpv window as well, so there's no need to special
case this in the reconfig event. This has the nice bonus of avoiding
that sway/wlroots issue as well since the buffer_scale is set much
later. Fixes#10263.
One downside of this approach is that it bypasses the mixer cache, but
while this is not ideal for performance reasons, the status quo is also
simply broken so I'd rather have a slower implementation that works than
a faster implementation that does not.
And as it turns out, updating the OSD state and invalidating the mixer
cache correctly is sufficiently nontrivial to do in a clean way, so I'd
rather have this code that I can be reasonably certain does the right
thing.
Fixes#9923 as discussed. Also fixes#9928.
This is mainly for other user scripts that may conflict with the osc
logo in some way. Although it is possible to listen for
shared-script-properties, this has many edge cases that could easily pop
up. A user could want other OSC things to happen at the same time (say
osc-message). They just don't want the logo. The idlescreen option
disables all idlescreen related things (including the santa hat) if it
is set to "no". A new script message (osc-idlescreen) is also added so
users can easily toggle the value (passing "cycle" or just explictly
setting "yes" or "no"). Some more discussion on this is found in the
below github issues.
https://github.com/mpv-player/mpv/issues/10201https://github.com/CogentRedTester/mpv-file-browser/issues/55
Apparently _t names are reserved, and in this case it wasn't very
useful anymore (it was useful while developing it, but this code is
almost 10 years old now).
Fixes a compilation error on Solaris.
The wayland stuff is designed to update/rescale itself whenever the
wl_output scale changes. This is great, but vo_vaapi_wayland should not
actually attempt to handle any hidpi stuff. The point of this VO is to
hand off as much to the compositor as possible, so we do want the
compositor to do the scaling here (enjoy your bilinear). This fixes some
incorrect rendering that could occur with scaling values not equal 1 due
to mismatches between buffer coordinates and the surface local
coordinates. It also eliminates the need to specify
--no-hidpi-window-scale on hidpi displays (has the same practical
effect).
A bad person (AKA me) merged this stuff without paying close enough
attention to the code style. Reformat this to be in-line with the rest
of the wayland code and general mpv style (braces for functions on the
next line, horizontally aligning arguments, some cosmetic cleanups for
wayland_common.h, etc.).
So it turns out that mpv already has an mp_tag_str which makes a
readable string out of fourccs (drm formats are these).
drm_format_string, on the other hand, has a ton of baggage with having
to check different libdrm versions for certain headers, adding
compile-time defines (because there are no version defines in the libdrm
headers), etc. It's a lot simpler to just use what mpv already has and
it returns what you actually care about: i.e. is this format supported
or not. Fixes https://github.com/mpv-player/mpv-build/issues/184
This driver makes use of dmabuffer and viewporter interfaces
to enable efficient display of vaapi surfaces, avoiding
any unnecessary colour space conversion, and avoiding scaling
or colour conversion using GPU shader resources.
If the player is started with --idle and the osc-tracklist script-message
is called then the tracks_osc table will be nil,
which caused the OSC to crash due to attempting to index a nil value.
This appears to be because the osc_tracklist variable is both
initialised and updated by (ultimately) the render() function, which
is not run when the player is idling.
Rather than mess with the existing OSC logic it's easier to either
add this single check, or alternatively to initialise the the tracks_osc
table somewhere before this.
Both mpv's main function and the client API use mp_initialize to start
up. In general, these work the same however the client API had one
slight, unnecessary limitation: you can't start it up with idle=no. In
practice, the libmpv profile (used with the client API) sets idle to
yes, so it's rarely encountered, but there's no particular reason why
this policy needs to be enforced. It turns out that mp_initialize does a
quick check to see if there are any entries in the playlist and if idle
mode is set. If not, it prints the help message and exits. Basically,
it's just the part that handles the terminal message when you type "mpv"
with no arguments. Unfortunately with idle=no, the client API also hits
this code path, exits prematurely with 1 and thus returns an API error.
Fortunately, the fix is very simple. If the client API is used instead
of the "normal" mpv executable, then the mp_initialize function gets a
NULL for the options argument. When starting mpv from the terminal (when
you would want to see the before mentioned help text), there will always
be at least an argv[0] (the mpv executable name itself) so we can
reliably distinguish between the two. The other case where there could
be no argv is if the pseudo-gui profile is used, but this always
enforces idle so we don't have to worry about it either. In other words,
with this combination of conditions (options, no idle, and no playlist
entries), we can be sure this is from a user calling mpv in the terminal
with no arguments. Therefore, other cases can be allowed which means
client API users can initialize with idle=no. Fixes#10162.
Normally with the keep-open option, mpv is supposed to set the
eof-reached property to true so clients can possibly do interesting
things at this step. However, there was actually an edge case where this
property notification did not occur. If you use keep-open and then seek
in the file past the end (so mpv stops), property notification is not
actually sent in this case. Internally, mpv does a very exact seek at
this step which also ends playback, but it does not set STATUS_EOF to
the ao and vo before the core idle state is updated. To fix this edge
case, it's simply just a matter of explictly setting STATUS_EOF after
seek_to_last_frame in handle_keep_open. This logic will only ever
trigger if keep-open is being used and the seek goes past the end of the
file, so we know that there will always be an EOF here.
5774ce759a added the new output name event
and used them for the --fs-screen-name option. It turns out that the
display-names property could also make use of these names, so go ahead
and use output->name in this case if we have them. If not, fallback to
output->model like before.
Windows is weird and symbols weren't actually being exported. This is
because __GNUC__ is defined and picked up in the conditional, but
__attribute__((visibility("default"))) doesn't actually export anything
to the dll. Instead, just check if we have win32 defined first and then
always set __declspec(dllexport). Fixes#10171.
ffmpeg 5.1 adds support for IPFS (the ipns:// and ipfs:// protocols).
This patch enables those protocols to be fist-class citizens in mpv.
Thus allowing for playing IPFS resources on mpv like:
"mpv ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T"
Some compiler flags were passed to mpv in order to get it to build as a
gui application on windows. However on the meson build, this always
resulted in mpv being built as a console application. This is because
the function for making executables in meson specifically has a kwarg
called win_subsystem* which defaults to 'console'. That always added
link arguments at the end which compiled mpv.exe as a console
application. The correct thing to do is to remove all of the
subsystem-related flags in the meson build and use the win_subsystem
kwarg as intended by setting it to 'windows,6.0'. For mpv.com, we can
remove the -Wl,--subsystem,console flag since meson will set this by
default in that executable. This makes mpv.exe function correctly and
open with the pseudo-gui while mpv.com acts as a console wrapper.
https://github.com/mesonbuild/meson/commit/1a0603835e3c9f1047d9b7694efc996219a422e4
These values and options were simply never looked at in the drm egl
context. This pretty much is just a copy and paste of what is in vo_drm.
Fixes#10157.
09ea3a424f moved the console above the OSC when it is visible so they
don't overlap, but only changed the first ass:pos() call and forgot to
update the second one, which redraws the cursor on top of the text, so
when both the OSC and the console are visible, a second cursor is drawn
on the OSC. You have to type past where the buttons are to notice it.
This commit synchronizes the position of the 2 ASS events.
Allow screenshot-high-bit-depth=yes to work with JPEG XL
screenshots when screenshot-sw=no is set. They already work
as expected when screenshot-sw=yes is set, but this allows
the hardware screenshots to work this way too.
Since 2018, wl_surface_damage_buffer has been explicitly preferred and
recommended over wl_surface_damage*. mpv was still using the old
function in a couple of spots. The only difference is that we need to
pass buffer coordinates instead of surface coordinates. In vo_wlshm,
this is done by using vo->dwidth/vo->dheight since that is always used
whenever wl_buffers are created. In the case of the cursor surfaace, we
actually already passed buffer coordinates to it (img->width/height)
which was probablly technically wrong with wl_surface_damage, but it
doesn't really matter in practice. This requires bumping wl_compositor
to version 4 which is no problem since this dates back to 2015*.
https://gitlab.freedesktop.org/wayland/wayland/-/commit/921d0548035673a1bf6aeb9396b9bc728133411ehttps://gitlab.freedesktop.org/wayland/wayland/-/commit/3384f69ecf043d62a4e036c0353c2daa01d7c4d0
Add Jpeg XL as a possible output format for screenshots, which
should make it possible to take fast screenshots with much better
quality than JPEG, or take lossless high-bit-depth screenshots
with lower file sizes than PNG.
It is possible for vo_gpu_next to attempt a resize before the windowing
backend is fully initialized. In practice, this can happen on wayland
which means libplacebo attempts a 0x0 resize. Depending on the API, a
0x0 resize may be allowed (vulkan or d3d11), but libplacebo just returns
a 0 in this case which mpv doesn't do anything with anyway. In the case
of opengl, this usage is explictly forbidden and will result in a
warning which may confuse users. Solve this by just not trying a resize
if dwidth and dheight in the vo are not available. Fixes#10083.
Recently, git patched a CVE which makes it much more strict about
different users operating on directories they don't own. For us, this
causes breakage with version.sh and version.py since they both run a git
describe command to fetch the commit hash. Currently, this only affects
the tumbleweed container (likely because it was recently changed) and
thus the git describe command always errors out. Workaround this by just
explictly adding the mpv directory as a safe directory for git.
- Say built-in which is more common than builtin
- Move "By default" because only the key to open the console is
customizable, and fix the punctuation and case of the sentence
- ` opens the console, not ´
- Remove the sentences that explains which user script console.lua is
based on since it's no longer relevant now that the console has been
part of mpv for over 2 years.
Now that a separate --cover-art-whitelist option exists, files like
cover.jpg are loaded even without setting --cover-art-auto to fuzzy, so
only load files that have exactly the media filename by default, since
fuzzy loading is probably more likely to load unwanted images than to
load cover art that the user intended to display, especially if you play
audio files with a short filename like a.mp3.
This allows more fine grained control over which cover art to load. With
--cover-art-auto=exact and --cover-art-whitelist=yes, you can now load
cover art with the exact media filename and the whitelisted filenames,
but not cover art that contains the media filename
(--cover-art-auto=fuzzy).
This adds a section to the documentation to explain how resuming
playback works, and in particular it explains how it affects which
playlist entry mpv starts playing from, since this feature was only
implied in the --playlist-start documentation.
It also groups the documentation of the watch later options together to
make them easier to find.
draw_image is an old API that was deprecated long ago. However when
wlshm was originally added, it used draw_image. There's no particular
reason for this and it can trivially be switched to draw_frame instead.
This has some real advantages (notably --vo=wlshm --idle --force-window
actually works).
This fixes build failures with avcodec 58.113.100 or before,
matching FFmpeg release versions 4.0 to 4.3.
This flag was added in between avcodec 58.113.100 and 58.114.100
during the FFmpeg 4.4 development cycle. It lacks its own version bump,
so instead a check for the define is utilized instead.
Additionally, warn the user if they request GPU film grain with
too old of an FFmpeg.
Fixes#10088
The VO is available during decoder initialization mostly for direct
rendering purposes, so if f.ex. a complex filter chain is utilized,
there is no video renderer information available via
mp_filter_find_stream_info during creation of the decoder filter.
Thus, check for whether the VO is available before attempting to
check the capabilities flag from it.
Additionally - to simplify logic - makes explicitly requesting GPU
film grain to always disable decoder film grain functionality. The
warning is still shown if the VO is available and no support for
film grain application is available.
Fixes#10079
In wayland 1.20.0, a couple of new events, name and description, were
added to the interface. Description is not particularly useful, but name
returns back nice names for the output like "DP-1" and so on. It makes
sense to use these for fs-screen-name and prefer them over the model
name (old way of doing it) if they are available. The only problem is
that 1.20.0 is pretty new so old distros aren't going to have it anytime
soon. Deal with this by adding some defines.
Because wayland is a special snowflake, mpv wound up incorporating a lot
of logic into its render loop where visibilty checks are performed
before rendering anything (in the name of efficiency of course). Only
wayland actually uses this, but there's no reason why other backends
(x11 in this commit) can't be smarter. It's far easier on xorg since we
can just query _NET_WM_STATE_HIDDEN directly and not have to do silly
callback dances.
The function, vo_x11_check_net_wm_state_change, already tracks net wm
changes, including _NET_WM_STATE_HIDDEN. There is an already existing
window_hidden variable but that is actually just for checking if the
window was mapped and has nothing to do with this particular atom. mpv
also currently assumes that a _NET_WM_STATE_HIDDEN is exactly the same
as being minimized but according to the spec, that's not neccesarily
true (in practice, it's likely that these are the same though). Anyways,
just keep track of this state in a new variable (hidden) and use that
for determing if mpv should render or not.
There is one catch though: this cannot work if a display sync mode is
used. This is why the previous commit is needed. The display sync modes
in mpv require a blocking vsync implementation since its render loop is
directly driven by vsync. In xorg, if nothing is actually rendered, then
there's nothing for eglSwapBuffers (or FIFO for vulkan) to block on so
it returns immediately. This, of course, results in completely broken
video. We just need to check to make sure that we aren't in a display
sync mode before trying to be smart about rendering. Display sync is
power inefficient anyways, so no one is really being hurt here. As an
aside, this happens to work in wayland because there's basically a
custom (and ugly) vsync blocking function + timeout but that's off
topic.
The video sync logic for mpv lies completely within its core at
essentially the highest layer of abstraction. The problem with this is
that it is impossible for VOs to know what video sync mode mpv is
currently using since it has no access to the opts. Because different
video sync modes completely changes how mpv's render loop operates, it's
reasonable that a VO may want to change how it renders based on the
current mode (see the next commit for an example).
Let's just move the video sync option to mp_vo_opts. MPContext, of
course, can still access the value of the option so it only requires
minor changes in player/video.c. Additionally, move the VS_IS_DISP
define from to player/core.h to common/common.h. All VOs already have
access to common/common.h, and there's no need for them to gain access
to everything that's in player/core.h.
A bit of a personal pet peeve. vulkan, opengl, and wlshm all had
different methods for doing wayland's "check for visibility before
drawing" thing. The specific backend doesn't matter in this case and the
logic should all be shared. Additionally, the external swapchain that
the opengl code on wayland uses is done away with and it instead copies
vulkan by using a param. This keeps things looking more uniform across
backends and also makes it easier to extend to other platforms (see the
next couple of commits).
This lets us remap various messages which might now be happening at
each frame onto the trace level, thus unaffecting the initial debug
log level.
Additionally - thanks to this ability - the previously globally denied
message queue abandonment messages can now be handled and mapped to
trace log level, as on that log level they may be of use.
Recommended by rossy and based on his libplacebo commit
6d72f6445566eddb0493447d0bda72d98a99d40c .
Instead of always having the reference outside of calling resize,
request a backbuffer at start and relieve the backbuffer at
submission for presentation.
Query the description of the swap chain, which should in all theory
contain the format of the backbuffer. Then utilize a newly added
ra_d3d11 function to map the format to an ra_format. After that,
utilize the depth of the first plane of the format, as previously.
This makes use of the new frame acquire/release callbacks to hold on to
hwdec images only as long as necessary. This should greatly improve the
smoothness/efficiency of hwdec interop, by not holding on to them for
longer than needed.
This also avoids the need to pool hwdec mappers altogether.
Should fix#10067 as well, since frames are now only mapped when we
actually use them.
9a7b2015e1 added the --screen-name option
for x11, but it was unfortunately broken. The commit does correctly
handle vo_x11_update_screeninfo and select the correct screen. However,
vo_x11_sizehint was missed. Specifically, the force_pos bool was always
false because it only took into account --screen being set and not
--screen-name. To fix this, just add an extra condition to the force_pos
bool so it becomes true if there's a string in --screen_name. Fixes
issue #9877.
Previously on wayland, it would result in an egl config with only 2 alpha
bits, which technically matches what was requested, but is not very useful.
Fixes#9862
Variable Refresh Rate (VRR), aka Freesync or Adaptive Sync can be used
with DRM by setting the VRR_ENABLED property on a crtc if the
connector reports that it is VRR_CAPABLE. This is a useful feature
for us as it is common to play 24/25/50 fps content on displays that
are nominally locked to 60Hz. VRR can allow this content to play at
native framerates.
This is a simple change as we just need to check the capability
and set the enabled property if requested by the user. I've defaulted
it to disabled for now, but it might make sense to default to auto
in the long term.
The field has been deprecated, yet the upcoming new default is not yet
the default. Thus, until lavc major hits 60 and the default behavior
finally gets changed, we have to explicitly set the field's value.
The deprecation had already been handled by adding the required
version limitation for this code in bbbf3571ed ,
this change merely just removes the warning which would otherwise
appear until lavc major version gets bumped to 60.
this field is used only in a special vo draining edge case.
switching to an atomic reduces osd->lock contention
between the mpv core (in write_video) and vo threads
which are managing osd rendering manually (such as vo_rpi).
Signed-off-by: Aman Karmani <[email protected]>
Pulling in <libplacebo/utils/libav.h> in particular triggers the
notorious _av_vkfmt_from_pixfmt linking issue when FFmpeg is built
without Vulkan support.
When I introduced the concept of lazy loading of hwdecs by img format,
I did not propagate the probing flag correctly, leading to the new
normal loading path not runnng with probing set, meaning that any
errors would show up, creating unnecessary noise.
This change fixes this regression.
FFmpeg recently split version.h into version.h and
version_major.h, and no longer automatically includes
version.h in avcodec.h (and the other libraries). This
should allow mpv to build against ffmpeg git master. See
FFmpeg/ffmpeg@f2da2e1458
These headers are not new, so their inclusion should not affect
backwards compatibility.
As found out by @philipl, failing to pass this from the VkInstance to
the VkDevice is bad style. We might want to override the get_proc_addr
pointer in the future.
20c4036daa switched to hiding all symbols
by default and exporting the ones we want with MPV_EXPORT.
However, the mpv_stream_cb_add_ro function was missed and it is part of
the client API. Export it too. Fixes#9971.
Our logging here today is very poor. We don't make it clear what
formats we are probing, or even that a certain format failed in most
cases. In the case where we do log the error, we don't make it clear
which format it was that failed.
The end result is that we have no idea what the possible and final
format spaces are, which makes it very hard to debug whether things are
working correctly, or to work on supporting additional formats.
The documentation's current discussion of hwdec usage is out of date,
and unnecessarily pessemistic when applied to modern hardware. The
reality is that modern APIs on modern hardware produce reasonable
results and there's no need to pretend otherwise. The current language
that tries to drive people away from using hwdecs at all leads to them
making bad choices when they do try to use it.
Let's also make it clearer that users should use vo=gpu with hwdecs
rather than vo=vaapi or vo=vdpau. Even the existing admonitions have
proven insufficient, so let's strengthen that language.
This code fails if we have DR buffers, but none of them correspond to
the current frame. Normally only happens if e.g. changing the decoder at
runtime, since DR buffers are not properly reinit in that case.
(Arguably a separate bug)
The current map_frame() code fails to clean up after itself on the
failure paths. But if map_frame returns false, no cleanup code is ever
attempted. Add the relevant calls to clean up state manually,
throughout.
So, turns out the approach in 7f67a553f doesn't work for all codecs. In
particular, sometimes lavc will internally allocate a new AVBuffer that
just points at the old AVBuffer but has a different opaque field for
some reason. In these cases, the DR metadata doesn't survive the
round-trip through libavcodec.
I explored several alternative ways of solving this problem, including
adding new mp_image fields, but in the end none of them survived the
round-trip through AVFrame and back. The `priv` and `opaque` fields
in respectively `mp_image` and `AVFrame` are also too heavily overloaded
to be of much help.
In the end, bite the bullet and use the same approach as done in
`vo_gpu`, which is to just keep track of a list of all allocations. This
is a really ugly way of doing things IMO, but ultimately, completely
safe.
Previously, when mpv was invoked with unsupported hwdec value, such
as --hwdec=foobar, there was no indication that it doesn't exist.
The reason it's not validated during options parsing is that the name
is only evaluated when selecting hwdec for actual decoding, by
matching it against runtime list of names from ffmpeg.
Additionally, when selecting hwdec for decoding, matching the name
came after filtering by codec, hence overall never-matched-name did
not necessarily indicate it's unsupported (doesn't exist at all).
Now we check the name before filtering by codec, and when done,
warn if no hwdec with that name exists at all.
This means that an unsupported name will now generate such warning
whenever we try to choose a hwdec, i.e. possibly more than once.
It's much better than no notification at all, and arguably adequate
for a sort of configuration error (linked ffmpeg has no such hwdec
name) which we don't validate during option parsing.
Some decoders, notably hevcdec, will unconditionally memset() the entire
AVBufferRef based on the AVBufferRef size. This is bad news for us,
since it also overwrites our `struct dr_buf`.
Rewrite this code to make it more robust - keep track of the DR buf
metadata in a separate allocation instead. Has the unfortunate downside
of technically being undefined behavior if `opaque` is not at least 64
bits in size, though, but avoids this issue.
Maybe there's a better way for us to unconditionally keep track of DR
allocation metadata. I could try adding it into the `mp_image` itself.
Maybe on a rainy day. For now, this works.
Fixes#9949
Might fix#9526
Previously only status<0 was considered as error, but status>0 is
also an error (the process exit code). Change to status != 0.
This likely makes little to no difference in practice, because if
stdout is empty or can't be parsed as JSON then it's considered
an error anyway, but still, this is more correct.
Also, on error, add the complete subprocess result to the verbose log.
There are two major ways of going about this:
1. Expose the native ra_gl/ra_pl/ra_d3d11 objects to the pre-existing
hwdec mappers, and then add code in vo_gpu_next to rewrap those
ra_tex objects into pl_tex.
2. Wrap the underlying pl_opengl/pl_d3d11 into a ra_pl object and expose
it to the hwdec mappers, then directly use the resulting pl_tex.
I ultimately opted for approach 1 because it enables compatibility with
more hardware decoders, specifically including ones that use native
OpenGL calls currently. The second approach only really works with
cuda_vk and vaapi_pl.
I was initially hesitant to link to an external article from the manpage
but a lot of other places in the man page already do something like
this, and it really makes more sense to have this as a wiki article
rather than trying to keep the manpage up-to-date by hand, since this
evolves quickly and the two are expected to converge over time.
This avoids decoding/caching more frames in advance than necessary. In
particular, this is very important for hwdec, which generally can't have
too many decoded frames in a pool at the same time.
So I can reuse it in vo_gpu_next without having to reinvent the wheel.
In theory, a lot of the stuff could be made more private inside the
hwdec code itself, but for the time being I don't care about refactoring
this code, merely sharing it.
We don't need to hold on to buffers longer than necessary. Doesn't
matter for vo_gpu but greatly matters for vo_gpu_next, since it persists
hwdec mapped textures for longer periods.
Unfortunately, only provides benefits for hwdecs which do explicit
copies in their decode path, which currently just means cuda and
d3d11va.
There's really nothing vulkan-specific about this hwdec wrapper, and it
actually works perfectly fine with an OpenGL-based ra_pl. This is not
hugely important at the time, but I still think it makes sense in case
we ever decide to make vo_gpu_next wrap OpenGL contexts to ra_pl instead
of exposing the underlying ra_gl.
Easiest way is by just using a designated struct initializer. If we
don't, `p->images` ends up inheriting random data, which leaks into e.g.
eglDestroyImageKHR.
It's a small miracle this never blew up before. Or maybe it did. Who
knows.
A few years ago, in 25e70f4743, we
disabled the vavpp deinterlacing auto-filter on the basis that it
caused crashes on _some_ hardware with _some_ driver version(s). But
since then, the situation has improved. There is still a limitation
where you can't turn deinterlacing on on the fly with AMD, but it
doesn't crash anymore (That is #7388).
So, given that AMD users have to set up the deinterlacing filter
manually either way, let's re-add the auto-filter for Intel users.
Some youtube_dl extractors retrieve URLs which contain other URLs
inside of them, for example Funimation, like this:
https://example.com/video?parameter=https://example.net/something
The url_is_safe function uses a pattern to match the protocol at the
start of the URL. Before this commit, this pattern was not compliant
with the URL spec (see the definition of "A URL-scheme string"):
https://url.spec.whatwg.org/#url-writing
Therefore it would match any characters, including "://", until the
last occurence of "://" in the string. Thus the above URL would match
https://example.com/video?parameter=https
which is not in safe_protos so the video will not play.
Now the protocol can only start with a letter and only contain
alphanumerics, "." "+" or "-" as the spec says, so it will only match
the first protocol in the URL ("https" in the above example.)
Previously the URL also had to contain "//" after the ":". Data URLs
do not contain "//": https://datatracker.ietf.org/doc/html/rfc2397
so now the pattern does not look for "//", only ":".
libplacebo v198 fixed this properly by adding the ability to flip planes
directly, which is done automatically by the swapchain helpers.
As such, we no longer need to concern ourselves with hacky logic to flip
planes using the crop. This also removes the need for the OSD coordinate
hack on OpenGL.
These helpers, for some reason, decided to round the returned values up
to multiples of the nearest plane alignment. This logic makes no sense
to me, and completely breaks any sort of oddly-sized mp_image.
This logic was introduced, presumably in error and without real
justification, as part of a major refactor commit (caee8748), As far as
I can tell, removing it again doesn't regress anything.
Fixes several serious bugs including buffer underflows and GPU crashes
in vo_gpu and vo_gpu_next.
Page 2 displays the frame timing info for each type (currently "Fresh"
and "Redraw"), but since they're unordered keys of a map, their
iteration order and hence their order on screen could (and did) change
depending on $things, which was annoying.
haasn thinks none of them should be considered more important (and
therefore maybe worthy of being displayed on top), so we go with
lexicographic order, which currently means that "Fresh" is first.
Fixes#9901
This fixes two potential divisions by 0 at generate_graph(...):
- If v_avg is (given and) 0.
- if v_max is 0.
The former doesn't seem to happen in practice because v_avg is only
used at one generate_gpah call, where it's apparently not 0.
The latter triggers if all the graph values are 0 (hence v_max is
also 0).
The implication of these divisions by 0 is an invalid y-value which
ends up at the ASS coordinates string for the graph inner content.
On linux the value ends as "nan" (luajit) or "-nan" (lua 5.1/5.2), and
on Windows it's "nan" (luajit) or "-1.#IND00" (lua 5.1/5.2), maybe due
to msvcrt's snprintf.
All these strings are wrong as ASS numbers, but due to luck in how
libass parses the coordinates, "nan" and "-nan" result in empty graph
(which looks OK for "all values are 0"), while "-1.#IND00" is parsed
as -1, which breaks the graph rendering (affects other graphs too).
One example of "all values are 0" is at page 0 (internal performance
graphs) on Windows - because the cpu metrics don't work.
So this fixes at least page 0 on Windows with lua 5.1/5.2.
While at it, move the scale calculations to one place, which now
avoids division by 0, instead of duplicating this calculation.
In the future, we can consider improving the generate_graph API:
- It needs one peak value, but takes 3 (v_max, v_avg, scale) which
are meshed into one final value.
- v_avg is only used in 1 of 6 call sites, but at the middle of the
arguments, so all other call sites need to pass explicit "nil".
- "scale" is arbitrary and used to leave some space at the top of the
graph. 5 places use 0.8, one uses 0.9. Could probably be unified.
Render subs at the output resolution, rather than the video resolution.
Uses the new APIs found in libplacebo 197+, to allow controlling the OSD
resolution even for image-attached overlays.
Also fixes an issue where the overlay state did not get correctly
updated while paused. To avoid regenerating the OSD / flushing the cache
constantly, we keep track of OSD changes and only regenerate the OSD
when the OSD state is expected to change in some way (e.g. resolution
change). This requires introducing a new VOCTRL to inform the VO when
the UPDATE_OSD-tagged options have changed.
Fixes#9744, #9524, #9399 and #9398.
The stop-screensaver option is currently limited to a simple yes/no
option. While the no option does always disable mpv trying to stop the
screensaver, yes does not mean the screensaver is always stopped. The
screensaver will be enabled again depending on certain conditions (like
if the player is paused). Simply introduce a new value for this option,
always, which does exactly what the name implies: the screensaver will
always be disabled.
- Make it clearer that playback_only affects subprocess' behavior when
the playback of the current playlist entry terminates, rather than
when mpv quits.
- Explain when status is positive and when it is negative.
- Replace "exited gracefully" in status' and error_string's
documentation with "terminated normally" so it can't be misinterpreted
as exiting successfully.
- Reword the playback_only warning
Historically, we have treated hwdec interop loading as a completely
separate step from loading the hwdecs themselves. Some hwdecs need an
interop, and some don't, and users generally configure the exact
hwdec they want, so interops that aren't relevant for that hwdec
shouldn't be loaded to save time and avoid warning/error spam.
The basic approach here is to recognise that interops are tied to
hwdecs by imgfmt. The hwdec outputs some format, and an interop is
needed to get that format to the vo without read back.
So, when we try to load an hwdec, instead of just blindly loading all
interops as we do today, let's pass the imgfmt in and only load
interops that work for that format. If more than one interop is
available for the format, the existing logic (whatever it is) will
continue to be used to pick one.
We also have one callsite in filters where we seem to pre-emptively
load all the interops. It's probably possible to trace down a specific
format but for now I'm just letting it keep loading all of them; it's
no worse than before.
You may notice there is no documentation update - and that's because
the current docs say that when the interop mode is `auto`, the interop
is loaded on demand. So reality now reflects the docs. How nice.
Pass channel volumes to `pw_stream_set_control` as array.
This is correct calling conventions and prevents
right channel muting every time ao-volume property is changed.
Terminate `pw_stream_set_control` calls with 0.
This is an annoying special case only really needed because of the
`vflip` filter. mpv handles this by directly adjusting the plane
transform. The libplacebo API, unfortunately, does not allow passing the
required information for this to work smoothly.
Long-term I plan on adding support for plane flipping in libplacebo
directly, but for the meantime, we will have to work-around it by moving
the flipping to the whole-image `crop` instead. Not an ideal solution
but better than crashing.
Fixes#9855
We're getting bug reports that the recent change to add extra usage
flags to swapchain buffers (for gpu-next) breaks mpv on some Windows 7
systems, and it seems like this is only happening with flip-model
swapchains.
Creating swapchains with DXGI_USAGE_UNORDERED_ACCESS should be valid. At
least, it's not specifically disallowed, unlike some other flags[1]. So,
just disable it for flip-model swapchains in Windows 7, rather than
disabling it everywhere.
[1]: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-usage
See the previous commit for the full explanation. Basically, luajit 2.0
has a bad pc file on macos that causes libmpv to fail during build. The
workaround was, if the os was darwin and luajit was found, to save a
full luajit dep and a partial luajit dep with the link args removed. The
partial dep was used for compiling libmpv, and the full dep was used for
the actual mpv executable. This worked and was needed for the CI to pass
but it sucked. Since the previous commit now makes the CI grab lua 5.1,
we don't need all this crap anymore. Just delete it and treat the
dependency normally.
This does effectively mean that building libmpv with luajit 2.0 on macOS
will no longer work with the meson build. However libraries not being
built correctly is not a mpv-specific issue. The waf build will succeed
for some reason, but it has known issues and it would be better if it
just failed honestly. An upstream developer said years ago that that
macOS users should use the 2.1 branch (and there's no release of
course). In any case, no macOS user should be building mpv with luajit
2.0, so we shouldn't be going out of our way to support this.
https://github.com/mpv-player/mpv/issues/7512https://github.com/LuaJIT/LuaJIT/issues/521#issuecomment-562999247
LuaJIT is still actively developed, but upstream is allergic to making
new releases for whatever reason. The last tagged release was in May of
2017, so we probably shouldn't expect a new release anytime soon. Now
for mpv, this doesn't really matter except in the case of macOS where
2.0.5 is actually a bit broken (and of course the CI uses luajit). More
specifically, the 2.0.5 pc is broken and has a "-pagezero_size 10000"
flag which causes libmpv to fail (only executables are allowed to use
this). This magically works on waf. It's possible that it just happens
to ignore the link arguments. However on the meson build, this is broken
and led to a really ugly hack using a partial dependency so both mpv and
libmpv succeed. Fortunately, the 2.1 luajit branch fixes this.
Unfortunately, there's no actual release.
Instead, just use Lua 5.1. Note that lua 5.1 is technically deprecated
in homebrew, but the chances of this going away is pretty slim since
everyone knows that new lua versions are not backwards compatible.
Anyways, using 5.1 works fine and lets us get rid of a terrible hack in
the meson build. People really shouldn't be using 2.0 LuaJIT anyway.
We have a few examples with vf=rotate=90, but libavfilter's rotate
accepts radians - not degrees, so a value of 90 is valid but misleading
because it's not 90 degrees.
Change the value of 90 at those examples.
Also replace "vf-add=hflip" with "vf add hflip", since that example
lists commands, not options, to run.
Drag and drop in wayland is weird and it seems everyone does this
slightly differently (fun). In the past, there was a crash that
occured (fixed by 700f4ef5fa) which
involved using the wl_data_offer_finish in an incorrect way that
triggered a protocol error (always fatal). The fix involved moving the
function call to data_device_handle_drop which seemingly works, but it
has an unfortunate side effect. It appears like GTK applications (or at
least firefox) close the pipe after this function is called which makes
it impossible for mpv to read data from the fd (well you could force it
open again in theory but let's not do that). Who knows if that was the
case when that commit was made (probably not because I'd think I would
have noticed; could just be a dummy though), but obviously having broken
dnd for a major application isn't so fun (this works with QT and
chromium anyway).
Ideally one would just simply check the pipe in data_device_handle_drop,
but this doesn't work because it doesn't seem the compositor actually
sends mpv the data by then. There's not actually a defined event when
you're supposed to be able to read data from this pipe, so we wait for
the usual event checking loop later for this. In that case,
wl_data_offer_finish needs to go back into check_dnd_fd, but we have to
be careful when calling it otherwise we'd just commit protocol errors
like before. We check to make sure we even have a valid wl->dnd_offer
before trying to indicate that it is finished and additionally make sure
there is a valid dnd_action (after checking the fd, it's always set back
to -1).
This doesn't fix everything though. Specifically, sway with
focus_follows_mouse (the default) and GTK as the data source still
doesn't work. The reason is that when you do a drag and drop in sway
with that option on, a new wl_data_device.data_offer event is sent out
instantly after the drop event. This happens before any data is sent
across the fd and before mpv even has a chance to check it. What GTK
does, when getting this new data_offer event, is close the pipe
(POLLHUP). This means mpv can't read it when we reach the event loop and
thus no data is ever read and broken drag and drop. From the client
side, this isn't really fixable since the wayland protocol doesn't have
a clear indication of when clients are supposed to read from the fd and
both the compositor and data source are doing things totally out of our
control. So we'll consider this weird case, "not our bug" at least. The
rest should work.
By receiving the graphics API-specific contexts from the generic
pl_gpu instance, it is not necessary to store them separately.
As the current priv struct stores nothing else, this allows its
removal. This removal cleans up related compiler warnings regarding
unused variables in case of opengl and d3d11 being disabled in
mpv/libplacebo.
Functions to receive the underlying vulkan,gl,d3d11 structure were
added in libplacebo version 4.182. Our current requirement for
gpu-next is 4.190, and thus we can freely utilize these helper
functions.
We only wish to touch actual video frames, which should have an
allocated image attached to them, so just check the frame type
early, and exit by passing through such non-video frames to further
filters in the chain without attempting to process them.
Fixes a crash in case of non-video (EOF/NONE) frames being passed
onto the filter when the dovi option was set to false since
05ccc51d53 .
While testing support for the exotic formats used by Intel vaapi for
4:2:2 and 4:4:4 surfaces, I realised that we were enumerating all
endpoints and checking formats for them. The problem with this is
that decoding (VLD) endpoints are only a subset of what vaapi exposes.
All the encoding endpoints are there too, and there is also the
None profile that we don't care about, but which generates ffmpeg
warnings if you try and examine it.
So, let's only look at VLD endpoints. This will speed things up a
little bit and make the logging less noisy.
This speeds up chapter name access while hovering the seekbar:
- Fetch the chapter-list property using observation rather than on
every render while hovering the bar. Property access, especially
with potentially lots of values (chapters), can be expensive-ish,
and can involve locking, so the less per-render the better.
- Sort the list once (on change) to simplify the iteration logic when
searching the chapter which matches the mouse position. It's still
O(N) (no binary search currently), but with less work.
The cached sorted list is stored at the state. While there are other
places which access this property and could use this cache, for now we
don't touch them, because they're not performance-critical (on init
for the chapter markers, on ch_{prev,next} button click for OSD).
Caching properties using observation instead of using mp.get_property
can indeed speedup other places too, but it should be part of a system
rather than implemented per-property. Maybe some day.
When utils.get_user_path was added, the expand-path command didn't
exist. Now it does, so remove the C code, make it a trivial wrapper.
Keep this function for backward compat to not break scripts, but
technically it's not required anymore.
This has been the latest stable release for about half a year now. This
version in particular lets us get rid of all the deprecation warnings in
the older code. (See the following commits)
The wayland backend contains logic to detect if the window is hidden. If
so, we skip rendering as an optimization. However, if we receive
multiple resize events in rapid succession, we will send the compositor
new buffers faster than the refresh rate of the monitor. Therefore the
compositor will not send us frame events which we incorrectly interpret
as the window being hidden.
Once the last buffer has actually been rendered, the compositor sends us
a frame event. However, if at that point playback is paused, there is no
logic to restart rendering of frames that we skipped due to the above
optimization. Therefore we never send the compositor new buffers
corresponding to the new size of the window and the surface will either
be too small or too large.
The simplest solution is to always render a few frames after we receive
a resize event.
vo_gpu_next and libplacebo expect swapchain images to be able to be
blitted to, which for libplacebo on FL11_0 and up means they have to
have DXGI_USAGE_UNORDERED_ACCESS, since libplacebo uses a compute shader
to emulate certain kinds of blits. For libplacebo's benefit, set all
applicable usage flags on swapchain images.
The docs specify that the +-X+-Y geometry values position the content.
This used to work correctly but got broken at 8fb4fd9a .
Geometry size is unaffected - this only concerns position.
Commit 8fb4fd9a made it center the window rather than the content by
taking the borders into account during positioning, but forgot to make
an exception when a position is specified explicitly.
This commit adds this exception, and now if a specific position is
requested then the borders are ignored, and the content is positioned
correctly.
The code assumed that the value of the profile-restore field is
"default" for such profiles, but the C implementation is such
that the field is intentionally omitted in such case.
This resulted in incorrectly trying to restore such profiles. However,
there are no stored values with profile-restore=default, so it only
resulted in a harmless warning, but otherwise behaved correctly (i.e.
nothing is restored).
Fix the condition by taking into account that missing field means
"default", so that it doesn't try to restore in such case, and
avoid the warning.
Currently the profile-restore field is intentionally omitted if it
holds the default value (i.e. no values are stored for the profile,
and trying to restore would only warn).
See m_config_get_profiles at command.c .
a02901cae7 changed how mpv was handling
wl_surface_set_buffer_scale. It's correct in that constantly setting the
surface scale on every resize (which mpv was previously doing) is
unneccessary and not right. However, it introduced a slight regression
if someone moved a surface to a new monitor with the same resolution but
a different scale. It did not trigger a resize and thus the video would
have incorrect dimensions. A later refactor changed how things looked
inside here, but this regression wasn't fixed. A resize should always be
triggered if the scale changes in this surface event. Fixes#9426.
Mouse button event codes above `BTN_EXTRA` (the ones currently defined
in `input-event-codes.h` are `BTN_FORWARD`, `BTN_BACK`, and `BTN_TASK`)
are mapped to `MP_MBTN9` and up. (Reminder that due to historical
reasons, the names `BTN_FORWARD` and `BTN_BACK` are completely
misleading; the real forward and back buttons are `BTN_SIDE` and
`BTN_EXTRA` and are already mapped correctly by mpv.)
This functionality is analogous to what the X11 backend supports in
`video/out/x11_common.c` and what the Cocoa backend supports in
`video/out/cocoa/events_view.m`.
According to the xdg-shell protocol spec, a 0x0 size from the compositor
means that "the client should decide its own window dimension". We were
not doing this correctly. What should happen is that mpv should simply
reuse the old window size if it is not maximized or fullscreened. This
should work on all (reasonably recent) versions of mutter and an
compositor that follows the spec.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
So actually according to the xdg-shell spec, a 0x0 resize is meant to
indicate that "the client should decide its own window dimension".
Previously, this just accidentally worked. In mutter 41.3, they changed
how 0x0 resizes were sent and what actually happened was that mpv tried
to resize itself to 0x0. This was obviously broken, so the reverted
commit naively just ignored 0x0. It actually seemed to work, but it
ended up breaking older versions of mutter. It's also not exactly the
correct fix so it deserves a revert.
This reverts commit d16defac27.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1050
This define was always just a stopgap for that two month period (August
2021 - October 2021) where the bytes_read field in ffmpeg was completely
missing. Before that time, it was a private member in a struct (which
mpv used). Afterwards, it officially became public. Fortunately, the
lack of this field never actually made it into a release, so it could
have only possibly affected people building from the master branch.
Since ffmpeg 5.0 came out recently, and it's been plenty of months since
that two month window, we can go ahead and drop this check. This
finishes up the work done in 78cfeee2b9.
Sidenote: the cached ffmpeg version in the mingw ci were from that time
period when the bytes_read field was missing. The N in the workflow is
bumped to force a full rebuild and fresh clone of ffmpeg.
Both _NET_WM_NAME and _NET_WM_ICON_NAME (part of Extended Window Manager
Hints) require that the string is UTF-8*. mpv was not doing this and
thus violating the spec. Just sanitize the title for these two atoms.
Note that XA_WM_NAME and XA_WM_ICON_NAME have no such requirement so
those atoms are left the same. Fixes#8812.
*: https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html
Apparently mutter can send us 0x0 resizes* for whatever reason. Probably
there's some interal reason why this occurs, but for us trying to resize
to 0x0 is obviously terrible and results in all kinds of brokenness.
Just ignore any 0 values. Fixes#9748.
*: https://gitlab.gnome.org/GNOME/mutter/-/issues/2091
Changes:
* fixed hangups in the loop function and in some other cases
* refactoring according to @michaelforney's recommendations in #8314
* a few minor and/or cosmetic changes
* ability to build ao_sndio using meson
Changes:
- rewrite to use new internal MPV API;
- code refactoring;
- fix buffers size calculations;
- buffer set to auto;
- reset() - clean/reinit device only after errors;
Previously, the sub-visibility option changed the visibility of all
subtitles including secondary ones. This meant that it was not possible
to only display secondary subtitles while hiding the primary ones. This
modifies the sub-visibility option so that it only affects primary
subtitles which allows only secondary subtitles to be displayed.
This reverts commit 04f0b0abe4.
It's not a good idea to unify the names only for visibility, while
keeping secondary-* for everything else.
This needs a bit more thought before we allow secondary sub to be
visible on its own.
Adds --sub-visibility choices 'primary-only' for only displaying the
primary subtitle track, and 'secondary-only' for only displaying
secondary subtitle track.
Removes --secondary-sub-visibility and displays a message telling the
user to use --sub-visibility=yes/primary-only instead.
These changes make it so that the default 'sub-visibility' bind 'v'
cycles through all the 'sub-visibility' choices, 'no', 'yes',
'primary-only', and 'secondary-only'.
Was tripping -Wparantheses as the && after the || was not explicitly
wrapped. However, due to operator precedence the intended effect was
still correct.
Warning from meson:
WARNING: You should add the boolean check kwarg to the run_command call.
It currently defaults to false,
but it will default to true in future releases of meson.
See also: https://github.com/mesonbuild/meson/issues/9300
All of the run_command() calls currently use need to succeed for the
build to work properly.
The AO provides a way for mpv to directly submit audio to the PipeWire
audio server.
Doing this directly instead of going through the various compatibility
layers provided by PipeWire has the following advantages:
* It reduces complexity of going through the compatibility layers
* It allows a richer integration between mpv and PipeWire
(for example for metadata)
* Some users report issues with the compatibility layers that to not
occur with the native AO
For now the AO is ordered after all the other relevant AOs, so it will
most probably not be picked up by default.
This is for the following reasons:
* Currently it is not possible to detect if the PipeWire daemon that mpv
connects to is actually driving the system audio.
(https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1835)
* It gives the AO time to stabilize before it is used by everyone.
Based-on-patch-by: Oschowa <[email protected]>
Based-on-patch-by: Andreas Kempf <[email protected]>
Helped-by: Ivan <[email protected]>
The only way to fix the channel order here is to create the texture with
bgra format. Incidentally, there used to be a way to set the component
map for overlays directly, but no more. Shouldn't matter since
everything supports bgra8 anyways, though.
Fixes#9699
These got added upstream a while ago. Need to be added to the mapping
helpers.
It might be time to think about bumping the minimum dependency here.
Reported-by: Uoti Urpala <[email protected]>
There was some breakage with regards to the iconv detection in some
older meson versions. This was all settled in 0.60.3 and now it simply
just works. Remove the workarounds and bump the needed meson version to
0.60.3.
When this was originally added, some OS package managers were slow and
behind the required meson version needed for mpv to build. Both opensuse
tumbleweed and freebsd now appear to carry meson 0.60.3 in their repos
so we no longer need to do the two-step process of installing pip3 and
then installing meson via pip. Instead, just use the OS package manager
version.
Useful to strip dolbyvision from the output, in cases where the user
does not want it applied. Doing this as a video filter gives users the
abiilty to easily toggle this stripping at runtime in a way that
properly propagates to any (potentially stateful) VO.
It also thematically fits the rest of the options in vf_format, which
are similarly concerned with modifying the video image parameters.
This needs to be forwarded from the AVStream to the AVPacket itself, so
that it reaches the decoder. There exists an FFmpeg function for this,
we just need to call it. (Also add some logging)
Instead of `xkb_keymap_new_from_string`. The protocol does not require
the keymap to be null terminated and if the size of the keymap is a
multiple of the page size, using `_from_string` could lead to problems.
Some compositors include a null byte and even include the null byte in
`size`. Therefore we have to use `strnlen` to find the real length of
the string. Note that `_from_string` internally uses `strlen` and then
calls `_from_buffer`.
While mpv uses version 1 of the `wl_seat` protocol and `MAP_PRIVATE` is
only required from version 7 on, using `MAP_PRIVATE` allows us to be
compatible with compositors that have only been tested with newer
applications.
Since the keymap is not modified after `mmap`, using `MAP_SHARED` has no
advantage over `MAP_PRIVATE`.
This merges the old desaturation control options into a single
enumeration, with the goal of both simplifying how these options work
and also making this list more extensible (including, notably, new
options only supported by vo_gpu_next).
For the hybrid option, I decided to port the (slightly tweaked) values
from libplacebo's pre-refactor defaults, rather than the old values we
had in mpv, to more visually match the look of the vo_gpu_next hybrid.
Merge --gamut-clipping and --gamut-warning into a single option,
--gamut-mapping-mode, better corresponding to the new vo_gpu_next APIs
and allowing us to easily extend this option as new modes are added in
the future.
image2D is only defined from GLSL ES 3.1 onwards, so those statements
broke GLES 2.0. Move the qualifier to a place that is only reached with
the right version requirements.
fixes commit 584ab29c88
This commit is mainly for correcting the previous commit message.
The previous commit fixed an issue where [un]registering events above
the first event ID "hole" is not requested from libmpv, and that's
indeed true.
However, this had nearly zero impact in practice, because libmpv
enables all events by default anyway (except TICK).
Therefore, above the first ID "hole" [un]register requests are not
sent to libmpv, and the events just keep arriving.
But the callback functions are still added/removed correctly (at
defaults.js), and so the script is not called back even if unregister
did not actually happen with libmpv.
The only event which was affected is TICK - which is not enabled by
default as it's deprecated, and before the previous commit could not
be enabled.
So the fix is more a general correctness fix now that the IDs array
can have "holes", but with effctively no impact in practice.
Commit 63205981 removed some events but left all other event IDs at
their original values, which created "holes" at the events IDs array.
The JS backend for mp.register_event maps a name to an ID by scanning
all IDs and stopping when the name was found or a NULL name was
returned. Lua does the same except that it doesn't stop on NULL name.
Previously it was not possible to have a NULL name before the end of
the array, but now it is possible due to the enumeration holes.
Fix by skipping missing names, like lua does.
Back when the meson build was still in the PR state, this particular
variable was a dictionary. Later, it was refactored to simply be a
feature object instead. All uses of egl_drm['use'] should have been
replaced with egl_drm.allowed() but this particular line was missed
(that's what I get for not just doing find/replace). The conditional in
this line is usually satisified before egl_drm ever needs to be checked
which was why no one noticed until now. Fixes#9631.
Commits 04018c3061cd7a7a1de8 introduced behavior that
updated window geometry during wayland events (specifically surface and
output). This is good but they also are too aggressive with
automatically resizing. For example, if a window is manually resized by
the user and then dragged to a different monitor with different geometry
than the initial monitor, mpv will automatically resize itself to the
window's resolution. The initial thought behind this logic was for
autofit to automatically readjust itself on a new monitor, but doing
that breaks other common use cases. An attempt could be made to
distinguish between autofit and a manual resize but that introduces a
lot of complexity for an edge case. It's better to simply not change the
window geometry here. Internal values are recalculated and scaled of
course, but wl->window_size and wl->geometry should not change.
shaderc is a special case dependency in meson. According to the
documentation*, it first checks for shaderc_shared and will fallback to
shaderc_combined (the order is reversed if the static keyword is true).
However, shaderc also has a third .pc file (shaderc_static) which should
be checked. The meson documentation doesn't indicate this, but it also
actually checks shaderc_static*. shaderc_combined is first checked if
meson looks for static libs and if that is not found it tries
shaderc_static. So this extra fallback check is not needed.
*: https://mesonbuild.com/Dependencies.html#shaderc
*: https://github.com/mesonbuild/meson/blob/a2934ca9d13ede4eb97b320bc768319ecad7b525/mesonbuild/dependencies/misc.py#L539
Shaderc has been shipping .pc files for almost three years and we all
know of the advantages. If this turns out to be problematic the old checks
can be re-added but I'd like to avoid doing this preemptively.
During execve() ignored and blocked signals carry over to the child
process, though apparently for SIGCHLD (which the bug report was about)
this is implementation-defined.
fixes#9613
We've been assuming that maximum number of compute group threads is
never less than the 1024 defined by the desktop GL spec. Given that we
haven't had working compute shaders for GLES and I guess the Vulkan
spec defines at least as high a value, we've gotten away with it so
far.
But we should really look the value up and respect it.
This is only needed on Android and supposed to handle a context
resize without reconfiguring the image parameters. reconfig()
already does exactly this so plug it in there.
Not all deprecated symbols were removed. Only three events were removed for now
since these are not used internally.
This bumps the library version to 2.0.
Simply returning out of this function leaks avpkt, need to always "goto
done".
Rewrite the logic a bit to make it more clear what's going on (IMO).
Fixes#9593
It's supposed to work with GLES >= 3.1 but we had all sorts of bad
assumptions in our version handling, and then our compute shaders
turn out not to be GLSL-ES compliant.
This change contains some necessary, but insufficient, tweaks to the
shaders. Perhaps we'll make it actually work some day.
Some of the extension declarations did not include the ES version where
they became core functionality, and in some of these cases, there was
never actually an ES extension - it first appeared in core. We also had
a number of buggy version checks where ES versions were compared
against required desktop GL versions.
nvidia follow the OpenGL spec very strictly, with two particular
consequences:
* They will give you the exact context version that you ask for,
rather than the highest possible version that meets your request.
* They will hide extensions that the specs say require a higher
version than you request, even if it's technically possible to
provide the extension at lower versions.
In our case, we really want a variety of extensions, particularly
compute shaders that are only available in 4.2 or higher. That means
that we must explicitly include a high enough version in our list of
versions to check for us to be able to get a 'good' enough context.
As for which version? We restore the 4.4 version that we had in the
old version selection logic. This is the highest version we ever asked
for, and we have separate logic that clamps the GLSL version to 4.4,
so anything newer wouldn't make a difference.
Since libavcodec major version 59, the requested "ass" format became
the default as the old timing-included format was disabled starting
with that version. Additionally, this option by itself has since
been deprecated as it no longer serves any purpose.
References:
FFmpeg/FFmpeg@1f63665ca5FFmpeg/FFmpeg@176b8d785bFixes#9413
`plane_data_from_imgfmt` doesn't zero-initialize the struct, so this
contained invalid values for e.g. `row_stride`, causing formats to
*randomly* fail. (Especially any formats with specific alignment
requirements)
Might fix#9424 and #9425.
This is a workaround for nvidia proprietary drivers. The authors of
those drivers interpret the spec such that eglMakeCurrent will not
reconfigure the read and draw buffers. Thus windows wont display
anything drawn by opengl. nvidia authors refer to
https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_no_config_context.txt
specifically Issues 2/3 which reference eglMakeCurrent.
On mesa this is a non-issue and the read/draw targets are assigned with
eglMakeCurrent.
The context must be made current in order to query OpenGL strings. An
earlier proposal to create the wayland window surface similarly to X11
during init was deemed inappropriate so instead we manually set the
targets once we have created a window surface.
Allow --keep-open=always to work with --loop-playlist, where
before this patch it would work only on the last playthrough of the
playlist. This patch allows it to work on all playthroughs.
Fixes#9470.
Somewhat annoying but still relatively straightforward. There are
several ways to approach this, but I settled on reusing the pl_queue as
a cheap way to get access to the currently mapped frame. This saves us
from having to process `vo_frame` at all, and also avoids any overhead
from re-uploading the same frame twice.
(However maybe there's some circumstance in which `vo_frame` needs to be
queried/updated first, to get a screenshot of the correct frame? I'm not
sure.)
I also had the option of going with either pl_render_image() on the
extract pl_frame, or just calling pl_render_image_mix directly on it. I
went for the latter, because in the optimal case, this allows the
rendered frame to be directly retrieved from the cache, actually
entirely avoiding any sort of recompute overhead. This makes e.g. ctrl+s
during playback essentially free. (Except for the download cost,
obviously)
It would be even neater if we could make this VOCTRL asynchronous and
thereby leverage libplacebo's asynchronous download capabilities. But oh
well. That will have to wait for a sufficiently rainy day.
Closes#9388
20c4036daa switched to using symbol
visibility attributes for mpv client api functions (for the meson build
at least). Unfortunately mpv_client_api_version was mistakenly missed.
We need to export this function as well. Fixes#9531.
As noticed in #9526, apparently there's some case in which DR buffers
get corrupted. Add an explicit sentinel check to try and figure out
which cases these are.
The initial iconv dependency worked everywhere but was broken on
freebsd. This was fixed in 0.60.2 but the fix accidentally broke mingw
(ouch; kind of my fault for not double checking). There's another PR to
fix this but that won't land until 0.60.3 so for the meantime just
if/else this (both freebsd and windows work with the system method)
until we want to bump the meson version (probably not for a while since
opensuse tumbleweed is weirdly slow).
Previously OSD was always displayed on {ch,pl}_{next,prev} left-click,
and seekbar-hover-chapter was always enabled and with fixed format.
Now it can be controlled with:
- chapters_osd, playlist_osd: yes/no (only affects left-click).
- chapter_fmt: lua string.format template, or "no" to disable.
Fixes#4675
This commit sucks bad, but everything else is worse is other ways.
Basically, the current vblank waiting time in the vo_wayland_wait_frame
function (calculated very carefully using presentation statistics) is
randomly too short. Some compositors are quite variable when they
actually return callback so our timeout expires too quickly and throws
everything off. The fix? Add an arbitrary 5% to the vblank value and
pray that nothing gets off that much. Why did they have to make
swapinterval 1/fifo mode indefinitely block? Fixes#9504.
Better to avoid any wonky calculations on startup with garbage values.
The others end up being derived from last_ust/last_msc. refresh_interval
is referenced exactly once and could, in theory, result in some terribly
erroneous vblank time.
A read can be prepared on the wayland display FD that is never actually
read. This occurs when events are triggered on other FDs in the fd set.
This change cancels a prepared read if poll reported no events for it.
This fixes some hangs due to how nvidia's EGL implementation polls on
the wayland fd unlike mesa implementations. It is based on nvidia's
proposed fix for qt's similar message pump in
https://codereview.qt-project.org/c/qt/qtwayland/+/373473
Signed-off-by: Kurt Kartaltepe <[email protected]>
This is done to avoid cluttering vo_gpu_next.c with more ifdeffery and context-specific code
when additional backends are added in the near future.
Eventually gpu_ctx is intended to take the place of ra_ctx to further separate gpu and gpu_next.
This case was added in 662c793a55
for use in vo_gpu_next as a visibility test before rendering a frame.
The OpenGL context doesn't have this so it just returns true.
This is needed when the color system is not explicitly tagged, but
instead needs to be inferred by the VO.
Note that there exists the function mp_image_params_guess_csp for this
sort of stuff, but it contains a lot of baggage that I don't want to
replicate, in order to move as much of this logic into pl_renderer as
possible, and therefore also give it the best chance of knowing what
shortcuts it can and can't take.
Fixes the other half of https://github.com/mpv-player/mpv/issues/9499
Adding vsync_offset to the pts in pl_queue_update actually messes up
frame timings if one isn't using interpolation. The easiest way to see
this is to have the monitor's refresh rate at an integer multiple of a
video during a panning shot (classic case). There will be very visible
judder/stutter in this case that does not happen in vo_gpu. The cause of
this is the addition of the extra vsync_offset. Just match the semantics
of vo_gpu where this is only used when interpolating.
This possibility actually existed for years. The wayland protocol is
asynchronous and there's no restriction on when a compositor can send a
surface enter event. In mpv's case, the surface enter event is used to
set some vital things regarded geometry/scaling etc. However, this
implictly assumes that wl->current_output is actually initialized. The
vast majority of the time, vo_wayland_reconfig will happen first which
is where wl->current_output is, and should, be created. There's no
rule/law that the ordering of events will always occur in this order.
Plasma with certain auto-profile conditions can send the surface enter
event before mpv does its initial reconfig. That segfaults of course.
Just add a check to make sure we have wl->current_output here and return
if we don't. This assumes that the compositor will send us another
surface enterance event when mpv actually does the initial surface
commit and roundtrip request later. Wayland logs indicate this does
happen. Fixes#9492.
It was never implemented before but it's trivial. As an aside, touch
events currently don't support modifiers either (is this a thing?). Well
if someone complains that can be done later. Fixes#9490.
The audio rewrite in d27ad96542 originally
broke this ao. However, 0ac724f002 fixed
and the documentation was never updated to reflect that. OpenAL has
worked fine for a while not. Just remove this sentence.
Even when not display synced. Prevents redraw overhead for refreshes
while paused.
Also make the logic slightly clearer to follow (since it's inverted).
Following the previous commit, we can just set gnu_symbol_visibility to
'hidden' to hide everything except for the symbols we explictly want to
export. This should work on gcc, clang, and msvc.
In mpv, the only symbols we want to export are the functions from the
client API. This is accomplised using a specific .def whitelist, but the
main compilers people use (gcc or clang) like these attributes since it
allows for further optimizations. MSVC also allegedly supports this as
well (untested of course), so use __declspec for tht case.
This almost perfectly recreates the semantics of --vo=gpu, i.e.:
- still frames are never interpolated
- non-repeated frames bypass single frame cache
The only difference is that libplacebo doesn't do a cache/blit on the
full output image, but rather it re-runs the last rendering step. This
has some advantages and some drawbacks. The most notable advantage is
that it also allows re-using the image contents when the only thing that
changes is the OSD (whereas `--vo=gpu` would force a full re-render for
that). The most notable drawback is that it also implies going through
the dithering and output LUT logic on redraws. All in all, I think this
is a pretty good trade-off in favor of `--vo=gpu-next`.
Fully fixes the last remaining performance difference in #9430.
GLX_CONTEXT_PROFILE_MASK_ARB and related constants are provided by
GLX_ARB_create_context_profile but the check was for _create_context.
The former implies the latter (which we also need) so just replace
the checked extension.
It abstracts EGL 1.5, extension checks and other inconsistencies away.
This can be used in context code as the (preferred) alternative to
eglCreateWindowSurface().
Using a simple substring match for extension checks is considered bad practice
because it's incorrect when one extension is a prefix of another's name.
This will almost surely not make a difference in practice but do it for correctness anyway.
Although there are no known problems with this, using the helper should
be more portable. It will also prefer EGL 1.5's eglGetPlatformDisplay
over eglGetPlatformDisplayEXT if available.
The original implementation had some errors with regards to android. Add
a couple of missing files, add the android library, fix the aviocontext
bytes_read check, fix egl-android, and rearrange/tidy up the vulkan
handling.
While the basic Vulkan Display context can theoretically drive the
display without the involvement of any non-Vulkan code, that prevents
us from using VAAPI acceleration. When initialising VAAPI without a
window system, we need to provide it with an opened DRM render fd
corresponding to the device to use.
In the context of using VK_KHR_display, that means we need to identify
which DRM device matches the selected Vulkan device, and then open its
render fd and set the necessary state that VAAPI expects to find.
With that done, the normal VAAPI<->Vulkan interop can kick in and we
get working acceleration
A few custom targets had some less than optimal names which created some
misleading "Generating custom-target-name with a custom command"
messages. Change those to be more descriptive/correct. In a few other
places, some checks were being done that could easily be
skipped/ignored in certain cases (like checking for windows-related
headers when gl-win32 isn't true). Also rearrange that to be smarter.
Finally, print some extra libplacebo messages for enabling/disabling
vo_gpu_next.
This test fails because the compiler object does not have -Wformat when
it tries this flag. To fix this this, we have to pass both -Wformat and
-Werror=format-security at the same time during the test. This requires
us to use has_multi_arguments so this flag needs to be pulled out of
this array and tested separately.
youtube-dl and yt-dlp both support --sub-langs and --srt-lang in
addition to --sub-lang for defining languages of subtitles. This hook
only checked for sub-lang in --ytdl-raw-options and inserted --all-subs
in its absence.
Nearly all the code base correctly references the data as constant. But
a couple of instances - fix those.
Signed-off-by: Emil Velikov <[email protected]>
Ever instance of m_obj_list is a constant and for all of them, the field
is true. Just remove the field all together.
Signed-off-by: Emil Velikov <[email protected]>
Update the github workflows to also do meson builds for every OS.
Additionally, make every workflow execute the built mpv executable
(except for windows and FreeBSD's waf executable) to make sure that it
runs. As an aside, FreeBSD unfortunately is a bit less elegant since it
is in a VM.
The extension is completely arbitrary since ebml_defs.c isn't a real c
file that actually is compiled at any point in time. It's just used as
an include. The reason for changing the extension is because meson needs
to add this to its list of sources for dependency/ordering purposes.
Understandably, meson will try to compile any .c file added to a c
project executable object. Obviously, this compilation will never
succeed, and this shouldn't be compiled anyways. Just make it .inc
instead.
Another modification for the upcoming meson build. Meson can capture the
stdout and redirect it to a file. However, this is considered a hack.
It's better to just add a few lines to this script and write a file
directly.
Apple is great and forces us to do a lot of weird checks because they
randomly move the location of the swift libraries around. Make a
specific python script for checking various locations and write the
output to stdout for meson.
Building for macos requires us to check the macos sdk path as well as
the sdk version that is on the system. To do this, let's steal the logic
that's in the compiler_swift.py check from the waf build. This returns a
comma-delinated string. The first entry is the absolute path to the sdk.
The second entry is the detected macos sdk version.
version.h is essential for building, and its generation was done by a
shell script. Strictly speaking, python should in general be more
portable (windows), and would be better for the upcoming meson build to
simply just execute a python script. version.py has some small
differences with version.sh which shouldn't matter but they are noted
below.
- version.sh accepted several arguments that seemed useless (like
--cwd). These were removed from version.py.
- version.py takes either no arguments (prints the version) or it takes
exactly one argument specifying the complete path of where the header
should be generated.
- version.sh attempted to read a file named "snapshot_version". The
comments noted that this was for "daily tarball snapshots". Such a
file does not exist in the source tree, and it's not really clear that
anyone actually uses this. This logic was removed from version.py.
- version.py reads the SOURCE_DATE_EPOCH environment variable. Some
distros use this for reproducible builds. Technically you could also
just disable the build date but this is only a couple of extra lines
and maybe it's prettier than UNKNOWN.
- version.py also doesn't attempt to display timezone information in the
build date. It only shows UTC time.
d2e8bc4499 was the the commit that
originally introduced the usage of this bit. As the message states, the
purpose was to force creating GLES 3 contexts on drivers that do not
return a higher version context than what was requested. With the recent
opengl refactors, mpv's gl selection has already moved away from such
complicated queries. Perhaps when that commit was added things were
different, but nowadays it seems like Mesa simply returns the highest
driver version available that is compatibile with the request (i.e.
requesting GLES 2 returns a GLES 3 context on my machine). In that case,
let's just simply drop EGL_OPENGL_ES3_BIT altogether as it does break
GLES 2 only machines. Fixes#9431.
The new GBM supporting nvidia drivers declare support for 10bit
surfaces using BGR ordering, rather than RGB, so add support for them.
We've also seen examples of hardware supporting BGR8888 but not
RGB8888 so let's support those too.
Of course, the nvidia EGL driver doesn't publish support for any 10bit
formats so you can't actually do 10bit display. Perhaps they'll
eventually fix that.
The GBM supporting nvidia driver doesn't support creating surfaces
without modifiers and using modifiers is more and more recommended as
the right way to do this.
Enumerating modifiers is painfully verbose, but necessary if we are to
allow the driver to pick the best possible one.
This fixes a mismatch between configure working and build time
failing with Linux + OSSv4, enabling compilation on Debian based
Linux systems with the oss4-dev package.
Fixes#9378
This logic, which was working around a libplacebo bug, ended up always
alpha blending - even for sources without an alpha channel. This caused
a minor slowdown to be constantly enabled.
Due to the recent bump to libplacebo v170, this is no longer needed.
Completely untested, since Linux still can't into HDR in 2021. Somebody
please make sure it works.
Technically covers #8219, since gpu-context=drm can be combined with
vo=gpu-next.
This required an upstream API change to implement in a way that doesn't
unnecessarily re-push or upload frames that won't be used. I consider
this a big enough bug to justify bumping the minimum version for it.
Closes#9401
This was originally added in f2afae55e9
for unclear reasons (way to go me). This concept is clearly incorrect.
It doesn't matter what state the window is in. As soon as mpv detects a
scale change, it needs to reset the buffer scale of the window. Just
remove all this junk and put wl_surface_set_buffer_scale in
set_surface_scaling like it should be. Related issue: #9426.
Looking at this again I'm not sure it does anything useful at all. The
man page entry is also wrong: `bicubic` is not affected, only
`bicubic_fast`, and those filters are not configurable anyways.
So this would only ever be a debugging option, and I don't see a
pressing need for it.
No interface-change.rst update because it only just got added anyways.
In practice, this is for wayland. vo_gpu_next doesn't check the
check_visible parameter since it didn't descend into the
vulkan/context.c file when starting a frame. To make this happen, just
call the start_frame function pointer but pass NULL as the ra_fbo. In
there, we can do the visibility checks and after that bail out of the
start_frame function if ra_fbo is NULL.
This vulkan-specific parameter was poorly named and probably causes
confusion. Just rename it to check_visible instead to make clear what is
going on here. Only wayland uses it for now but in theory anyone else
can. As an aside, wayland egl accomplishes this by using an external
swapchain instead (an opengl-only concept in the mpv code). This may or
may not need to be changed in the future when gpu-next gets opengl
support.
As discussed in #8799, this will eventually replace vo_gpu. However, it
is not yet complete. Currently missing:
- OpenGL contexts
- hardware decoding
- blend-subtitles=video
- VOCTRL_SCREENSHOT
However, it's usable enough to cover most use cases, and as such is
enough to start getting in some crucial testing.
This seems to work on gcc, clang and mingw as-is, but I made it
conditional on __GNUC__ just in case, even though I can't figure out
which compilers we care about that don't export this define.
Also replace all instances of assert(0) in the code by MP_UNREACHABLE(),
which is a strict improvement.
A lot of people seem to do something like --tscale=box
--tscale-window=<function>. Just let them use --tscale=<function>
directly, by also accepting raw windows.
Kinda hacky but needed for feature parity with vo_gpu_next, which no
longer has `--tscale=box`. Note that because the option struct is still
shared, vo_gpu_next inherits the same option handling code, so we have
to export this feature for vo_gpu as well.
Back when runtime updating of autofit/geometry was added for wayland and
x11 (commits: 4445ac828dca0298543103094357e64f8828ef56 and
ced92ba607ebd98687b26ef3d8c09d5f6e22cf4b respectively), the naive
assumption was that window-related geometry would always be available.
While this is true 99% of the time, this isn't a guarentee. It is
possible for certain things such as loading shaders to delay starting up
the player. This causes autofit/geometry options to be registered as a
runtime update and triggers VOCTRL_VO_OPTS_CHANGED. This ends up calling
some geometry-related functions but this happens before the actual
values are available. Hence, a nullptr was accessed which segfaults. At
least one user experienced this with a combination of options in wayland
but in theory the same thing could happen under x11.
The fix is simple. Just be sure to check that the required geometry is
available before doing any calculations. In wayland, this would be
wl->current_output. Additionally add an assert to set_geometry (we
should never use this function without wl->current_output) to be extra
sure. In x11, the check is on x11->window. Later when the reconfig for
each backend actually happens, the autofit/geometry set by the user
happens anyway so ignoring it in this case does no harm. Fixes#9381.
The problem with the previous code - which used mp.get_user_path, is
that it returns a path even with --no-config, and even if the file
doesn't exist.
This is why we tested the "config" property, and also used
mp.utils.file_info to check that the file exists.
mp.find_config_file doesn't return a path with no-cofig and doesn't
return a path if the file doesn't exists. It's simpler and better.
Upstream libplacebo got refactored to use byte-sized strides rather than
texel-sized strides. This commit makes mpv's ra_pl wrapper take
advantage of that, rather than forcing a stride-fixing memcpy.
Note that, technically, we would still need a stride fixing memcpy in
cases when the true stride is not a multiple of the format's texel
*alignment*, however this is a much rarer case and extremely unlikely to
occur in practice, since all relevant formats use power-of-two texel
alignments.
In the reconfig event, the keepaspect option was checked before setting
the window_size geometry to the new params obtained from the vo. This is
incorrect. If a user disabled keepaspect on wayland, the video's size
would not change on a reconfigure event (i.e. loading a new video in the
playlist with a different size). No other windowing backend (x11, win32,
etc.) behaves like this or uses keepaspect in its code like wayland did
in this case. Clearly, this is not correct. Such functionality should be
handled by a separate option entirely. Just remove this if statement.
The bytes_read struct member in AVIOContext is now officially public,
so its usage no longer has to be specified as non-compliance with
FFmpeg's ABI/API rules.
That said, unfortunately there was a short period of time between
August 2021 and October 2021 where the struct member did not exist
in FFmpeg's git master, so keep a feature check for it alive for
now to enable building with those versions. Thankfully, no release
version of FFmpeg will be without this field, so it should be
possible to drop this check with time.
Finally, simplify the function in case the struct member is not
found. After all, there is zero reason to iterate through the AVIO
contexts if we cannot get the information we require.
Based on the idea behind emersion's change to drm_info
(https://github.com/ascent12/drm_info/commit/869e789a645b92a99e592a230fe39b0c59a2cd7d).
Lets us by default skip devices which are not capable of doing what
the DRM master output requires (not primary devices), as some devices
have card0 actually not be such.
Negative part is that the number given to drm-connector is no
longer a direct mapping against a file name.
Upon re-examination I have no idea why this code was ever written or
what problem it was trying to solve. But, getting rid of it fixes#9291.
It might be a remnant from before 2af2fa7a27. Who knows. This code will
be replaced soon(tm) anyways.
Regression from e13fe1299d. Apparently,
Broadcom's EGL does not support the EGL_CONTEXT_FLAGS_KHR attribute nor
EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR. Just define these as EGL_NONE and 0
respectively if we do not have them.
editorconfig configuration files hold editor style hints, and
is supported by many popular editors. See https://editorconfig.org/ .
The vast majority of the mpv source/text files are already styled as
4 space indentation, trailing newline at EOF, and UTF-8 encoding.
This commit adds a single .editorconfig root file which applies these
rules to all files using the glob "[*]".
If it turns out to be too inclusive then we can narrow it down later.
Signed-off-by: Emil Velikov <[email protected]>
Normally there was no issue, but when the code converted a deeply
nested table into an mpv node - it didn't ensure the stack has room.
Lua doesn't check stack overflow when invoking lua_push* functions,
and leaves this responsibility to the (c) user via lua_checkstack.
Normally that's not an issue because when a lua (or autofree) function
is called, it's guaranteed at least LUA_MINSTACK (20) pushes.
However, pushnode and makenode are recursive, and each iteration can
add few values at the stack (which are popped when the recursion
unwinds), so checkstack must be used on (recursive) entry.
pushnode already checked the stack, makenode did not.
This commit checks the stack at makenode as well. The value of 6
(stack places to reserve) is with some room to spare, and in pratice
each iteration needs 2-3 at most (pushnode also leaves room).
Example which could previously corrupt the stack:
utils.format_json({d1={d2={<8 more times>}}}
This uses makenode to convert the lua table into an mpv node which
the json writer uses as input, and if the depth is 10 or more then
corruption could occur. mp.command_native is also affected, as well as
any other mp/utils command which takes a lua table as input.
While at it, fix the error string which pushnode used (luaL_checkstack
uses the provided string with "Stack overflow (%s)", so the user
message only needs to be additional info).
The speedup is due to moving big part of the autofree runtime overhead
(new lua c closure) to happen once on init at af_pushcclosure, instead
of on every call. This also allows supporting upvalues trivially, even
if mpv doesn't use it currently, and is more consistent with lua APIs.
While x2 infrastructure speedup is meaningful - and similar between
lua 5.1/5.2/jit, in practice it's a much smaller improvement because
the autofree overhead is typically small compared to the "real" work
(the actual functionality, and talloc+free which is needed anyway).
So with this commit, fast functions improve more in percentage.
E.g. utils.parse_json("0") is relatively fast and is now about 25%
faster, while a slower call like mp.command_native("ignore") is now
about 10% faster than before. If we had mp.noop() which does nothing
(but still "needs" alloc/free) - it would now be about 50% faster.
Overall, it's a mild performance improvements, the API is now more
consistent with lua, and without increasing code size or complexity.
mpv doesn't have other dot files in its config dir, and it also
shouldn't be "invisible".
The new name ~~/init.js now replaces ~~/.init.js
While mpv usually deprecates things before outright removing them,
in this case the old (dot) name is replaced without deprecation:
- It's a bad idea to execute hidden scripts, even if at a config dir,
and we don't want to do that for the next release cycle too.
- We warn if the old (dot) name exists and the new name doesn't,
which should be reasonably visible for affected users.
- It's likely niche enough to not cause too much pain.
If for some reason both names are needed, e.g. when using also an old
mpv versions, then the old name could be symlinked to the new one, or
simply have one line: `require("~~/init")` to load the new name, while
a new mpv version will load (only) the new name without warning.
With the recent refactor and quick look against the GLX code path, it's
fairly obvious, and trivial, how to add support for debug contexts.
Signed-off-by: Emil Velikov <[email protected]>
Drop the gl3 suffix from the function name - it's no longer needed, with
the _old function gone.
Push the mpgl_min_required_gl_versions[] looping within the function,
reducing the identical glXGetProcAddress/glXQueryExtensionsString calls
while making the code neater.
v2:
- tabs -> spaces indentation
- mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions
- 320 -> 300 (in glx code path)
v3:
- legacy code path is gone \o/
Signed-off-by: Emil Velikov <[email protected]>
The old/legacy code-path isn't really needed for mpv use-cases.
In particular:
All Mesa drivers (even GL 2.1 ones like lima/vc4) work fine with the
"non-legacy" path.
From proprietary/binary drivers - the vendor either does not support
desktop GL or the drivers/HW is not actively supported.
Looking at the Nvidia HW - anything GeForce 7 and older is GL 2.1 and
lacks decent video acceleration. The latest official drivers are from
2017.
All newer Nvidia HW is GL 3.3+ thus must have GLX_ARB_create_context as
in the non-legacy path, while also good acceleration albeit via VDPAU
in some cases.
With the old path gone, provide meaningful error message in the very
unlikely case that GLX_ARB_create_context is missing.
Signed-off-by: Emil Velikov <[email protected]>
With earlier commit f8e62d3d82 ("egl_helpers: fix create_context
fallback behavior") we added a fallback for creating OpenGL context
while EGL_KHR_create_context is missing.
While it looked correct at first, it is missing the eglMakeCurrent()
call after creating the EGL context. Thus calling glGetString() fails.
Instead of doing that we can just remove some code - simply pass the
CLIENT_VERSION 2, as attributes which is honoured by EGL regardless of
the client API. This allows us to remove the special case and drop some
code.
v2:
- mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions
Signed-off-by: Emil Velikov <[email protected]>
The ra_gl_ctx_test_version() helper is quite clunky, in that it pushes a
simple check too deep into the call chain. As such it makes it hard to
reason, let alone have the GLX and EGL code paths symmetrical.
Introduce a simple helper ra_gl_ctx_get_glesmode() which returns the
current glesmode, so the platforms can clearly reason about should and
should not be executed.
v2:
- mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions
- 320 -> 300 (in glx code path)
Signed-off-by: Emil Velikov <[email protected]>
As the documentation of the toggle says - the implementation can (and
will actually if they follow the GLX/EGL spec) return context version
greater than the one requested.
This happens with all Mesa drivers that I've tested as well as the
Nvidia binary drivers.
This toggle seems like a workaround for buggy drivers, yet it's lacking
context about the vendor and version.
Remove it for now - I'll be happy to reinstate it (partially or in full)
as we get concrete details.
This allows us to simplify ra_gl_ctx_test_version() making the whole
context creation business easier to follow by mere mortals.
Signed-off-by: Emil Velikov <[email protected]>
Alike the GL commit earlier - the EGL spec essentially mandates that
implementation will return GLES 3.0+ (if supported by the driver), even
though only GLES 2 is requested.
The only thing we should watch out is - we should add both ES2_BIT and
ES3_BIT as EGL_RENDERABLE_TYPE.
This has been verified against the Mesa drivers (i965, iris, swrast) and
Nvidia binary drivers.
v2:
- int es_version -> bool es
- unloop create_context() execution
Signed-off-by: Emil Velikov <[email protected]>
Currently mpv requires a bare minimum of GL 2.1, although it tries to
use 3.2+ core contexts when possible.
The GLX and EGL spec effectively guarantee that the implementation will
give you the highest compatible version possible. In other words:
Requesting 3.2 core profile will always give you core profile and the
version will be in the 3.2 .. 4.6 range - as supported by the drivers.
Similarly for 2.1 - implementation will give you either:
- 2.1 .. 3.1, or
- 3.2 .. 4.6 compat profile
This has been verified against the Mesa drivers (i965, iris, swrast) and
Nvidia binary drivers.
As such, drop the list to 320, 210 and terminating 0.
v2:
- mpgl_preferred_gl_versions -> mpgl_min_required_gl_versions
- update ^^ comment
Signed-off-by: Emil Velikov <[email protected]>
The ioctls were disabled a while back since they error out and allegedly
cause problem with X running in another VT.
Omitting the ioctls is not cool, even as a workaround.
If they fail, the user is supposed to fallback appropriately - use a suid
wrapper, logind-like daemon or otherwise.
As of kernel 5.10, they should just work in nearly all cases, so let's
just reinstate the calls.
Signed-off-by: Emil Velikov <[email protected]>
The ioctls were disabled a while back since they error out and allegedly
cause problem with X running in another VT.
Omitting the ioctls is not cool, even as a workaround.
If they fail, the user is supposed to fallback appropriately - use a suid
wrapper, logind-like daemon or otherwise.
As of kernel 5.10, they should just work in nearly all cases, so let's
just reinstate the calls.
Signed-off-by: Emil Velikov <[email protected]>
This behavior is more convenient and allows profile conditions like:
[video]
profile-cond=get('current-tracks/video/image') == false
[image]
profile-cond=get('current-tracks/video/image')
Otherwise, these profiles have to be manually applied and restored in a
script.
The note about discouraging the use of current-tracks in scripts is
removed, because it makes people avoid using this convenient property.
It was added in 720bcd79d0 without leaving an explanation of why you
shouldn't use it, and the only reason seems to be that it doesn't work
with lavfi-complex, but this commit changes that.
This exposes whether a video track is detected as an image, which is
useful for profile conditions, property expansion and lavfi-complex.
The lavf demuxer sets image to true when the existing check detects an
image.
When the lavf demuxer fails, the mf one guesses if the file is an image
by its extension, so sh->image is set to true when the mf demuxer
succeds and there's only one file.
The mkv demuxer just sets image to true for any attached picture.
The timeline demuxer just copies the value of image from source to
destination. This sets image to true for attached pictures, standalone
images and images added with !new_stream in EDL playlists, but it is
imperfect since you could concatenate multiple images in an EDL playlist
(which should be done with the mf demuxer anyway). This is good enough
anyway since the comment of the modified function already says it is
"Imperfect and arbitrary".
This moves the image check to where the number of frames is available of
comparison, which allows not detecting jpg and png videos as images, and
detecting 1-frame gifs as images. This works with the mjpeg and png
videos in the FATE suite, though unfortunately the bmp video is still
detected as an image since it has nb_frames = 0.
aliaspix streams are also now considered images.
Attached pictures are now treated like standalone images, so audio with
attached pictures now has mf-fps as container-fps instead of
unavailable, which makes it consistent with external cover art, which
was already being assigned mf-fps.
Unfortunately images in a codec commonly used for videos are never
detected, and detection was inaccurate even using the now private
codec_info_nb_frames field in AVStream, and mediainfo gets them wrong
too, so I guess it's just a lost cause.
The custom init script should be considered a configuration file, and
as such it should be ignored when the user wants vanilla mpv - and now
it is ignored with --no-config.
This is similar to [no-]input-default-bindings, but affects only
builtin bindings (while input-default-bindings affects anything which
config files can override, like scripting mp.add_key_binding).
Arguably, this is what input-default-binding should have always done,
however, it does not.
The reason we add a new option rather than repurpose/modify the
existing option is that it behaves differently enough to raise
concerns that it will break some use cases for existing users:
- The new option is only applied once on startup, while
input-default-bindings can be modified effectively at runtime.
- They affects different sets of bindings, and it's possible that
the set of input-default-bindings is useful enough to keep.
Implementation-wise, both options are trivial, so keeping one or the
other or both doesn't affect code complexity.
It could be argued that it would be useful to make the new option
also effective for runtime changes, however, this opens a can of
worms of how the bindings are stored beyond the initial setup.
TL;DR: it's impossible to differentiate correctly at runtime between
builtin bindings, and those added with mp.add_key_bindings.
The gist is that technically mpv needs/uses two binding "classes":
- weak/builtin bindings - lower priority than config files.
- "user" bindings - config files and "forced" runtime bindings.
input-default-bindings affects the first class trivially, but
input-builtin-bindings would not be able split this class further
at runtime without meaningful changes to a lot of delicate code.
So a new option it is. It should be useful to some libmpv clients
(players) which want to disable mpv's builtin bindings without
breaking mp.add_key_bindings for scripts.
Fixes#8809
(again. the previous fix 8edfe70b only improved the docs, while
now we're actually making the requested behavior possible)
Currently using mpv --msg-level=help, shows an instance of --msglevel
(missing dash). Seems like the help message was only partially updated
with the -msglevel -> --msg-level transition.
Signed-off-by: Emil Velikov <[email protected]>
Before this commit, animation-end was handled at render(), however,
it's not called on idle, which resulted in state.anitype ~= nil, with
nothing to reset it during idle, which caused in an infinite tick()
loop (starts on first mouse move).
Now tick resets the animation on idle, and also, as a safety measure,
if we're past 1s after the animation deadline.
The safety measure is because the osc states are complex, and it's
easier to detect a "we really shouldn't be animating now" at tick()
itself rather than detecting the exact states where animation should
be reset. Generally, the safety mmeasure is not needed.
TL;DR: use --lua=XXX for pkg-config name XXX, e.g. --lua=lua-5.1 .
For unversioned 'lua.pc', use the name luadef51/luadef52 .
Autodetection remains the same (5.2 names, luajit, 5.1 names).
The old names are still supported, but not auto-detected.
Before this patch, if one wanted to choose a specific lua version when
more than one is installed, then the names were a mess, e.g. 51obsd is
also the name detected on Arch linux, and other (distro) names are
also not unique to a specific distro/platform.
So to ask mpv to choose the package name (specifically, the pkg-config
file name), one needs to look at the mpv sources and find the
(arbitrary) distro name which has the same lua version naming as they
do on their own system, e.g. --lua=51obsd on Arch. This is a pain.
Now we add generic names:
- luadef51/luadef52 - generic pkg-config lua.pc (version is inside).
- lua* - exactly the pkg-config name, e.g. --lua=lua-51 for lua-51.pc
(the names are curated, e.g. --lua=foo won't detect foo.pc).
- The legacy names (e.g. 51deb) are still supported, but undocumented,
and the new generic names take precedence during auto-detection.
The fact that the generic names all start with "lua" has an additional
benefit that it shows right after "lua" at the output of mpv -v,
while the old names start with numbers, so they're first at the list,
making it hard to understand that e.g. "51obsd" is the lua version.
None of these names are actually used at the mpv code. The C code
checks the version using the lua headers (LUA_VERSION_NUM).
The lua version names which are autodetected/chosen (such as "51deb")
are used for two things:
- as key for storing the pkg-config compile/link flags.
- as ID for config.h and elsewhere - they're sanitized to use "_".
Due to some inconsistensies, if the sanitized ID is different than
the original name, then the compile/link flags are stored with the
original name as key, while the retrieval happens with the sanitized
ID - and therefore fails to find the correct flags.
The solution is to use the original name only for display purpose at
the output of configure, while using the sanitized version for
everything else, so that storage and retrieval use the same key.
Currently there's no issue and the patch has no effect, because the
sanitizer considers all the current names as valid IDs.
However, the next commit will add names which the sanitizer modifies,
such as "lua-5.1", so this commit makes such names work too.
Unfortunately, this functionality in large part based on a struct
member that was made private in FFmpeg/FFmpeg@7489f63281
in May. Unfortunately, this was not noticed during review.
This reverts commit 0862664ac9.
This CI builder bases on openSUSE Tumbleweed, and recently had
its glibc updated. This led to new syscalls such as 'clone3' not
being allowed through the security layer.
Can be reverted after Github Actions updates their security policy.
actions/virtual-environments#3812
This exposes whether a video track is detected as an image. This is
useful for profile conditions, property expansion and lavfi-complex, and
is more accurate than any detection even Lua scripts can perform, since
they can't differentiate between images and videos without container-fps
and audio and with duration 1 (which is the duration set by the mf
demuxer with the default --mf-fps=1).
The lavf demuxer image check is moved to where the number of frames is
available for comparison, and is modified to check the number of frames
and duration instead of the video codec. This doesn't misdetect videos
in a codec commonly used for images (e.g. mjpeg) as images, and can
detect images in a codec commonly used for videos (e.g. 1-frame gifs).
pix files are also now detected as images, while before they weren't
since the condition was checking if the AVInputFormat name ends with
_pipe, and alias_pix doesn't.
Both nb_frames and codec_info_nb_frames are checked because nb_frames is
0 for some video codecs (hevc, av1, vc1, mpeg1video, vp9 if forcing
--demuxer=lavf), and codec_info_nb_frames is 1 for others (mpeg, mpeg4,
wmv3).
The duration is checked as well because for some uncommon codecs and
containers found in FFMpeg's FATE suite, libavformat returns nb_frames =
0 and codec_info_nb_frames = 1. For some of them it even returns
duration = 0, so they are blacklisted in order to never be considered
images.
The extra codecs that would have to be blacklisted without checking the
duration are AV_CODEC_ID_4XM, AV_CODEC_ID_BINKVIDEO,
AV_CODEC_ID_DSICINVIDEO, AV_CODEC_ID_ESCAPE130, AV_CODEC_ID_MMVIDEO,
AV_CODEC_ID_NUV, AV_CODEC_ID_RL2, AV_CODEC_ID_SMACKVIDEO and
AV_CODEC_ID_XAN_WC3, while the containers are film-cpk, ivf and ogg.
The lower limit for duration is 10 because that's the duration of
1-frame gifs.
Streams with codec_info_nb_frames 0 are not considered images because
vp9 and av1 have nb_frames = 0 and codec_info_nb_frames = 0, and we
can't rely on just the duration to detect them because they could be
livestreams without an initial duration, and actually even if we could
for these codecs libavformat returns huge negative durations like
-9223372036854775808.
Some more images in the FATE suite that are really frames cut from a
video in an uncommon codec and container, like cine/bayer_gbrg8.cine,
could be detected by allowing codec_info_nb_frames = 0, but then any
present and future video codec with nb_frames = 0 and
codec_info_nb_frames = 0 would need to be added to the blacklist. Some
even have duration > 10, so to detect these images the duration check
would have to be removed, and all the previously mentioned extra codecs
and containers would have to be added added to the blacklists, which
means that images that use them (if they exist anywhere) will never be
detected. These FATE images aren't detected as such by mediainfo either
anyway, nor can a Lua script reliably detect them as images since they
have container-fps and duration > 0 and != 1, and you probably will
never see files like them anywhere else.
For attached pictures the lavf demuxer always set image to true, which
is necessary because they have duration > 10. There is a minor change in
behavior for which audio with attached pictures now has mf-fps as
container-fps instead of unavailable, but this makes it consistent with
external cover art, which was already being assigned mf-fps.
When the lavf demuxer fails, the mf one guesses if the file is an image
by its extension, so sh->image is set to true when the mf demuxer
succeds and there's only one file.
Even if you add a video's file type to --mf-type and open it with the mf
protocol, only the first frame is used, so setting image to true is
still accurate.
When converting an image to the extensions listed in demux/demux_mf.c,
tga and pam files are currently the only ones detected by the mf demuxer
rather than lavf. Actually they are detected with the image2 format, but
it is blacklisted; see d0fee0ac33.
The mkv demuxer just sets image to true for any attached picture.
The timeline demuxer just copies the value of image from source to
destination. This sets image to true for attached pictures, standalone
images and images added with !new_stream in EDL playlists, but it is
imperfect since you could concatenate multiple images in an EDL playlist
(which should be done with the mf demuxer anyway). This is good enough
anyway since the comment of the modified function already says it is
"Imperfect and arbitrary".
Previously, loading ~~/.init.js was inside a try block, in order to
quietly ignore errors if the file doesn't exist.
However, that also prevented any real errors from showing up even when
the file does exist, and the script continued as if everything is OK,
while in fact the custom init script didn't complete correctly.
Now we first check if the file exists, and then load it without
try/catch, so that any error shows up normally (and abort the script).
The value of the border option should always match what the actual state
of the window is. Previously if a compositor rejected the request by
mpv, it did not correct itself. Also add some code to keep track of
decoration requests. Anytime the state is changed, make the last saved
request again (doesn't hurt and seems like intuitive behavior).
Unfortunately, this isn't foolproof since options only send callback if
the value is changed. (ex. on sway if the floating window has no border,
and then is titled, setting the border value to "yes" does nothing since
tiling the window already set the border value to "yes").
Fixes handle leak that happened whenever tvservice callback was invoked.
Powering on the TV causes HDMI unplug and attached events to be sent to
the tvservice callback.
This meant you could only power on/off your TV a finite number of times
before you were unable to allocate additional resources from VideoCore
(usually resulting in a "Could not get DISPMANX objects." error).
Furthermore because the VideoCore kernel driver does not cleanup handles
when a process dies, the only way to recover from the leak was to reboot
the RPI.
Because youtube-dl is inactive and the yt-dlp fork is becoming more
popular, make mpv use yt-dlp without any extra configuration.
yt-dlp is ordered before youtube-dl because it's more obscure, so users
who have yt-dlp installed are more likely to want to use it rather than
youtube-dl.
Fixes#9208.
In Linux kernel commit 819fbd3d8ef36c09576c2a0ffea503f5c46e9177
these two header files were moved to staging (though they've since
been moved out again by Linus.)
We do not actually use this, and it's in a state of maybe-removal
from the kernel as of Linux 5.14. Get rid of it; mpv still builds
fine without it, so it wasn't needed anyways.
Fixes#9233.
Without this, cases where the parser cannot return data right away
will end up utilizing the following fed packet's timestamps. This
will in turn cause an unnecessary offset in the audio stream
timestamps.
An example of such buffered parser in libavcodec is the EAC3 one.
Before this commit, timeBeginPeriod(1) was set once when mpv starts,
and the timers remained hi-res till mpv exits.
Now we do the same as before on Windows version < 10.
On Windows 10+ we now use timeBeginPeriod if needed, per timeout.
To force a mode regardless of Windows version, set env MPV_HRT:
- "always": the old behavior - hires timers as long as mpv runs.
- "perwait": sets 1ms timer resolution if timeout <= 50ms.
- "never": don't use timeBeginPeriod at all.
It was observed that on Windows 10 we lose about 0.5ms accuracy of
timeouts with "perwait" mode (acceptable), but otherwise it works
well for continuous timeouts (one after the other) and random ones.
On Windows 7 with "perwait": continous timeouts are accurate, but
random timeouts (after some time without timeouts) have bad
accuracy - roughly 16ms resolution instead of the requested 1ms.
Windows 8 was not tested, so to err on the side of caution, we keep
the legacy behavior "always" by default.
This brings enabled features on the same level as disabled and
auto-detected features by having both alternatives available.
Looking at the commit message of 652895abdc
this seems to have been the intent from the start, but this specific
definition was missing from the option creation in Features.
In wayland_common, wl->window_size keeps track of the window's size when
it is not in the fullscreen or maximized state. GET_UNFS_WINDOW_SIZE is
meant to report the size except for when it is fullscreen (hence UNFS).
However, the actual function was merely returning the wl->window_size so
it was wrong for maximized windows. Workaround this by returning
wl->geometry instead when we have the maximized case. Fixes#9207.
Its define (HAVE_FFMPEG_STRICT_ABI) is now utilized in a single
location, where an internal libavformat struct member is utilized.
This struct member is now (after around 10 years) finally removed
from public visibility in FFmpeg's master.
After a review of functionality, the information in bytes_read is
passed onto the demuxer layer, and then utilized for
{cache,hack}_unbuffered_read_bytes. This information is then utilized
for:
1. Calculation of bytes_per_second in demux/demux.c::update_cache,
which fills the information for properties "cache-speed" as well as
"raw-input-rate" (of which stats.lua is the most prominent user).
2. bytes_per_second also affects how often update_cache is called in
addition to the two locations it is called unconditionally in
(read_packet, demux_update).
In other words, the information provided does not appear to control
crucial mpv functionality, but rather its lack would seem to mostly
affect the speed of certain properties updating, or having valid
values. For the former, stream size as well as timed metadata get
updated in update_cache - although the demux layer does throttle
the update of certain things to once per second in that function.
For the latter, "cache-speed" and "raw-input-rate" lose read data
statistics from AVIOContexts opened by the opened FFmpeg AVFormatContext
itself, as opposed to the primary one - which goes through mpv's
stream reading implementation.
By enabling this feature, and disabling this abuse of private API
lets users build mpv by default with the latest master FFmpeg, thus
giving us the breathing room to look into some of the details of
this case, and either decide to:
1. Post a patch to add this information back to FFmpeg proper.
2. Remove or replace this functionality in another manner.
End user impact:
Any IO not handled by mpv itself - but rather by IO contexts newly
opened by the input format - is not visible through the properties
"cache-speed" and "raw-input-rate". Examples of such input formats
are the HLS and DASH readers in FFmpeg.
Historical git references:
- Addition of unbuffered_read_bytes: 4dfaa37384
- Rework to have the reporting function: ebf183eeecFixes#9159
Last time it was extended was de3ecc60 from 8K to 512K two years ago.
The issue currently is that youtube EDL files can get very big.
Size of about 520K (one line), was observed, at the time of writing:
mpv https://youtube.com/watch?v=DBzFQgSMHdQ --ytdl-format=299
ytdl_hook.lua is unaffected by this because EDL lists don't go through
the file reader at demux_playlist.c (where each line was limited to
512K before this commit), however, EDL files on disk which are
loaded with --playlist=file.edl do.
Increase the limit to 2M so that such EDL files can also be loaded
from disk.
Fixes#9186
Previously, the initial positioning and fit ignored the borders, and
centered the content (the video itself) at the working area.
Now, the initial positioning centers the window, by subtracting the
borders (if needed) from the target area for the initial fit/position.
While this does mean that the initial maximum content area is now
smaller than before, ultimately this has no impact on the window size,
because fit_on_screen is called later and, if needed, further shrinks
the window to fit the borders too - but without centering the window.
So the net impact of this commit is only the initial positioning (same
size as before), which now centers the window instead of the content.
Note that on Windows 10 the borders include invisible areas at the
sides and bottom of the window (for mouse edge-drag), so visibly the
window is nearer to the top than to the bottom, but these are the
metrics we have (fit_on_screen uses the same border size values).
On Windows 7 it looks perfectly centered.
The --monitoraspect value is calculated at vo_calc_window_geometry2
(VCWG2) or VCWG3, and applied via vo_apply_window_geometry.
Before this commit, the screen size which the win32 VO used with
VCWG2 was the working area (screen minus taskbar). This allows better
fitting, but breaks the pixelaspect calculation which is derived from
the --monitoraspect value and this rectangle.
VCWG3 allows an independent size for the aspect calculations, and now
we use it independently of the fit size.
vo_calc_window_geometry2 (VCWG2) calculates both the pixelaspect and
the autofit sizes based on one "screen" rectangle.
However, these two calculations might need two different "screen"
rects if the fit should take into account decorations and/or taskbar
etc, while pixelaspect should be based on the full (monitor) rect.
VCWG3 does just that. It's the same as VCWG2, but with an additional
monitor rect which is used exclussively to calculate pixelaspect,
while the "screen" argument is used for fitting (like before).
VCWG2 now uses/calls VCWG3 with the same screen and monitor rects.
Currently yet unused.
If bash_completion wasn't installed, _filedir wouldn't be defined which
led to all filename-based completions to error out. Specifically
autocompletion would fail when a filename was expected and when
bash_completion wasn't installed. Now we fall back to `compgen -f` if
_filedir fails. According to _filedir's comments, compgen doesn't
handle files with spaces well, but it is still better to complete most
files than none.
If an unknown ESC sequence is detected where an ASCII char <X> follows
the ESC, mpv interprets it as ALT+<X>, which is the traditional
terminal encoding of ALT+letter.
However, if <X> is '[' then it's a CSI sequence which continues after
the '[', and has its own termination rules (can be many chars).
Previously, mpv interpreted unknown CSI sequences as (incorrect) ALT+[
followed by (incorrect) "keys" from the rest of the sequence.
In this commit, if a unknown CSI sequence is detected, mpv ignores
exactly the complete sequence.
The "cycle" command _declaration_ enables repeatability by default,
however, the command handler applies additional logic to augment it,
based on the property which is being cycled - using some guesswork.
Specifically, properties with discrete values are not repeatable
(like sub or osd-level), while continuous properties are repeatable
(like volume).
Previously, the "repeatable" prefix could not override this additional
logic.
This commit changes the behavior so that the logic affects only the
default repeatability (still based on the property like before),
however, the "repeatable" prefix is now allowed to override it.
This is an artificial background box with the original colors,
rendered as a plain rectangle instead of libass's opaque-box.
Fixes#9134 (together with the previous commit)
This breaks the rendering in various ways, so first workaround is to
simply disable the opaque box for the bar.
Next commit will add an artificial background box.
This read-only property reflects the VO's dpi-scale value, and wasn't
supported on win32 until now (it is supported on wayland/x11/osx).
Currently in mpv it's only used by the builtin script console.lua,
and assumed 1 if unavailable.
When --window-scale=NUM is set from CLI, the dpi_scale value was/is
taken into account when the win32 VO calls vo_calc_window_geometry2.
However, when [current]-window-scale is read or set at runtime, it uses
the VOCTRL_{GET,SET}_UNFS_WINDOW_SIZE interface, where other VOs apply
the dpi_scale value internally (wayland, x11, osx), but the win32 VO
didn't before this commit.
Fixes two issues when --hidpi-window-scale=yes and dpi_scale != 1 :
- Incorrect window-size when setting [current-]window-scale at runtime.
- Incorrect current-window-scale value when reading it.
vo_calc_window_geometry2(...) is called to initialize the window
size with the dpi_scale value as one of the arguments.
dpi_scale is 0 initially, and set to a valid value at update_dpi(),
which is called from [force_]update_display_info().
However, no measures were taken to ensure that dpi_scale is set
correctly before vo_calc_window_geometry2() is called, which could
result in incorrect window size if it's not initialized.
It did happen to get initialized on time, by luck, because
VOCTRL_GET_DISPLAY_FPS is used early, which happens to call
update_display_info to read the fps value (other update_display_info()
calls are after the first vo_calc_window_geometry2() call).
This commit ensures that dpi_scale is initialized on time if needed.
Also, update_dpi() now ensures that dpi_scale is never 0.
Previously, a list of commands was always considered repeatable.
This behavior was added at 6710527a (and moved around since then),
in order to fix#807 (impossible to make a repeatable list).
The problem was that a list doesn't have the normal repeatability
flags and so it was never repeatable, so it was hardcoded to be
repeatable instead. Presumably it was deemed good enough.
However, this made it impossible to have a non-repeatable list.
This commit changes the behavior so that a list repeatability is
that of the first command at the list.
This way, any list can be made either repeatable or non-repeatable
using the following idiom (e.g. at input.conf), based on the fact
that the "ignore" command is not repeatable by default:
x ignore; cmd1...; cmd2... # non-repeatable
y repeatable ignore; cmd1...; cmd2... # repeatable
Fixes#7841
Discovered with:
find . -type f \( -name '*.md' -o -name '*.rst' \) -exec grep -n 'http://' {} +
All real, i.e. non-example, links found were moved to https. There are
some dead links and websites with no https available which were not
converted.
Discovered with:
find . -type f \( -name '*.md' -o -name '*.rst' \) -exec grep -n 'http://' {} +
All links to mpv.io or github.com/mpv-player that were http were
converted to https.
This is a regression from cbbd81bb (the previous commit):
print_seq1 (which prints a sequence with 1 parametric byte value) is
used with 256 colors output, and apparently was never tested.
Two issues were introduced at the offending commit:
1. The ";5" part was incorrectly removed from the strings
ESC_COLOR256_{BG,FG} (affects both *nix and Windows).
2. On windows only - a semicolon was not used after the prefix.
Both issues resulted in an invalid 256 colors sequences and output.
- Replace the legacy --osd-status-msg with the newer --osd-msg3.
- Escape \b in show-text "This is ${osd-ass-cc/0}{\b1}bold text".
- Link the Flat command syntax section because it's no longer true that
you always need to escape \, since C escape sequences are not
interpreted with single and custom quotes.
On windows the UTF-8 strings are translated to wchar_t when printed to
the console, and some escape sequences are also translated, however,
this only works when printf is mapped to mp_printf, and for that to
happen we need to include osdep/io.h .
Normally in wayland, you receive a keymap event from the compositor
which is what allows the client to setup what is needed for xkb.
However, it turns out that this doesn't occur in the case of virtual
keyboards, such as from wtype, that come from the custom
virtual-keyboard protocol. What happens in this case is that mpv only
receives a keyboard entrance event. According to the wayland protocol
documentation [1], "the compositor must send wl_keyboard.modifiers event
after [the wl_keyboard.enter] event". It is possible for this to occur
before the physical keyboard is properly mapped (i.e: using a virtual
keyboard to start mpv). What this results in is a segfault once
xkb_state_update_mask is called in the modifiers event. The fix is to
simply not always assume we have created the xkb state if we get this
event and check for its existence first. Closes#9119.
https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_keyboard
When changing video track with subtitles with unknown duration, they
aren't shown until you seek, cycle sub back and forth, or apply a video
filter. This is caused by reinit_video_chain_src() calling
reset_subtitle_state() -> sub/sd_ass.c:reset() -> ass_flush_events()
when ctx->duration_unknown is true.
The ass_flush_events() call was added in a714f8e so subs with unknown
duration wouldn't multiply on seek, i.e. when reset_subtitle_state() is
called from reset_playback_state(). So keep calling it from there, and
in reinit_video_chain_src() use just term_osd_set_subs(mpctx, NULL)
instead to clear any subtitles printed to the terminal. The
reset_subtitle_state() call was added in c1ac97b to "reset the state
correctly when switching between video/no-video", but with it removed I
no longer notice any issue doing that.
Previous fullscreen handling code was removed in 59cdfe50b2 during
deprecation of VOCTRL_FULLSCREEN. Lack of this code caused the OSD layer
to be to be not resized along with the video layer when fullscreen is
toggled.
If a user attempted to change the window scale of a maximized window on
x11, nothing would happen since the window manager holds the size of the
window constant. Just do an unmaximize first before performing the
resize.
When the VT switch out is triggered, the decode thread (VD) falls back
to sw decoding. However, on the VO thread, which is responsible for
handling display preemption and presentation, vo_vdpau.c:reconfig() is
called. The reconfig() function returned -1 when the check_preemption()
returned 0. The vo_reconfig2() (which calls reconfig()) returned -1 in
turn which entered into an error handling path. This led to a series of
functions calls that ultimately set the in_terminate flag to TRUE.
This led the vo_thread to exit which ultimately led to the
MPV application exit.
The fix is to return 0 instead of -1 after the check_preemption() in
the vo_vpdau.c:reconfig(). Returning 0 instead of -1 is not fatal and
does not have any side effects. This is confirmed by testing the VT
switching behaviour. And as far as the frames that are going to the
display are concerned, they are now dropped. Since the display is
preempted, it is okay to drop the frames and continue.
Without this entry, when starting mpv as a flatpak application on
elementaryOS, the Dock icon would get duplicated, as if the application
was detached from its launcher. This entry fixes that by allowing the
dock to associate the app's window with the desktop entry.
Fixes#9109
29e15e6248 prefixed youtube-dl's subs url with an edl prefix to not
download them until they're selected, which is useful when there are
many sub languages. But this prefix broke the alignment of secondary
subs, which would overlap the primary subs instead of always being
placed at the top. This can be tested with
--sub-file='edl://!no_clip;!delay_open,media_type=sub;secondary_sub.srt'
When a sub is added, sub.c:reinit_sub() is called. This calls in
init_subdec() -> dec_sub.c:sub_create() -> init_decoder() ->
sd_ass:init(). Then reinit_sub() calls
sub_control(track->d_sub, SD_CTRL_SET_TOP, &(bool){!!order}) which sets
sd_ass_priv.on_top = true for secondary subs.
But for EDL subs the real sub is initialized again when in
dec_sub.c:sub_read_packets() is_new_segment() returns true and
update_segment() is called, or when sub_get_bitmaps() calls
update_segment(). update_segment() then calls init_decoder(), which
calls sd_ass:init(), so sd_ass_priv is reinitialized, and its on_top
property is left false. This commit sets it to true again.
For URLs that need to be downloaded it seems that the update_segment()
call that reinitializes sd_ass_priv is always the one in
sub_read_packets(), but with local subs sub_get_bitmaps() is usually
called earlier (though there shouldn't be a reason to use the EDL URL
for local subs), so I added the order parameter to sub_create(), rather
than adding it to all of update_segment(), sub_read_packets() and
sub_get_bitmaps().
Also removes the cast to bool in the other sub_control call, since
sub/sd_ass.c:control already casts arg to bool when cmd is
SD_CTRL_SET_TOP.
Right after the listener is constructed, request a mode based on the
value of the border option. If border, then request SSD. If no border,
request CSD. The decoration listener handles it from there.
The previous wording gave the false impression that there was no media
key support for OSes besides Windows and macOS. This is untrue, the
option may only exist on those two platforms but it simply means that
media keys will always be enabled on other OSes as long as they are
supported.
The current usage of the xdg-decoration protocol is quite a bit crude.
There's a specific listener struct for this like with most wayland
things, but mpv wasn't even using it. It also made no attempt to detect
if the compositor was telling mpv to use client side decorations. To
implement this correctly, first of all we need to create the decoration
listener object and add it like how most wayland things work. Secondly,
set_border_decorations needs to be changed to accept the uint32_t mode
given by the compositor. When we get the decoration event, pass the mode
obtained from the compositor to set_border_decorations. Update the mpv
border option, based on whether or not we have server side decorations
(yes if we have them; no if we don't). mpv can actually request either
client side or server side decorations with this protocol. This function
doesn't belong in set_border_decorations but rather it should be called
when the border option changes. Whether or not this request actually
works depends on the compositor (Plasma appears to allow it; sway does
not). If the compositor allows this request, then it gets handled by
configure_decorations. Note that the enum strangely starts at 1 hence
why there is an extra +1.
When performing the scaling calculations, the window scale properties do
not bother checking for potential monitor par. The vo keeps track of
this via vo->monitor_par. Simply multiply/divide the video's width or
height depending on the value of monitor_par. We also clamp the values
to avoid the values running away to infinity in extreme cases.
The vo currently handles rotations in 90 degree steps and some VOs set
this via VO_CAP_ROTATE90. When the rotation exactly hits either 90 or
270 degrees, this causes the values of dwidth and dheight to perfectly
swap like one would expect. However, the mp_image_params_get_dsize
function call in both of the window scale functions do not take this
special case into account. So the width/height values returned will be
incorrectly flipped in the 90 and 270 degree cases if the vo driver does
implement VO_CAP_ROTATE90 (like vo=gpu). Fortunately, the
mp_image_params struct keeps track of the rotation for us. So all we
need to do is check if the image is rotated at 90 or 270 degrees and
check that the current vo driver supports VO_CAP_ROTATE90. If so, then
swap vid_w and vid_h to their true, correct values.
Based on a small patch originally written by @avih. Instead of
duplicating the window-scale logic in update_window_scale, just call the
mp_property_current_window_scale function with the M_PROPERTY_SET action
and a NULL property.
So the resizing mechanism is actually supposed to match the video size
to the window size while preserving the aspect ratio. In wayland, the
current logic behaves as if --no-keepaspect-window was set. Fix this by
simply multiplying the height by the same scale factor the width is
multiplied by. Also get rid of the pointless (width > height) test (it
makes no difference in any case) as well as some unneccesary checks for
the keepaspect-window option. The use of ceil here is to make sure the
window coordinates can never possibly have be 0 due to truncation
(weston can still give you a 1x1 window which is fun). Fixes#9098.
There's currently some touch related code in mpv wayland, but clearly
nobody actually uses because it's a broken mess. Initially an attempt to
distinguish between two finger touches and one finger touch was made,
but there's not a good way to make this work. For whatever reason,
initiating either xdg_toplevel_resize or xdg_toplevel_move blocks any
other touch events from occurring (at least in plasma). Trying to call
these functions anywhere else is not really useful since the serial will
be invalid outside of the touch down events (well it would work in the
touch up event but that's just silly).
Anyways, let's just make this work sanely. Eliminate the touch entries
variable completely because it's pointless. Only one finger event is
ever considered at a time. Touches besides the initial one are all
ignored. If a user touches and drags within the touch edge radius, then
a resize event occurs. If the user touches and drags elsewhere on the
window, a move event occurs. A single tap displays the osc (which is
clickable if you tap again). A double tap toggles fullscreen.
Additionally, the default touch edge radius of 64 pixels is way too big
(at least I think so). Cut this in half to 32 which feels a lot better
(on a pinephone using plasma mobile anyway).
The way the window-scale option is supposed to behave wasn't really ever
documented until 25cfc81. It turns out that different OS/WMs may do
slightly different things. For wayland, we need to fix two things.
First, only return the wl->window_size in GET_UNFS (aka don't return the
fullscreen size). For SET_UNFS, we need to change the behavior for the
maximized window case. If the window is maximized, first attempt to
unmaximize it and send the wayland event. If the compositor allows this
to happen, then go ahead and set the new dimensions and resize it. In
the case that the attempt to unmaximize is not successful, then don't
attempt the resize and just save the window size dimensions for later to
be used when the user unmaximizes the window.
The window-scale property mirrors the respective option (not the
effective scale derived from the current window size), and as such
setting its value to the same value it had before has no effect.
Specifically - the window will not resize.
This is consistent as far as property-option bridge behavior goes,
but we do end up with an issue that we can't set an arbitrary scale
and expect the window to always resize accordingly.
We do also have a current-window-scale property which does reflect
the actual window size, however, it's been read-only till now.
This commit makes current-window-scale RW so that it's now always
possible to set an arbitrary scale and expect the window to resize
accordingly (without affecting window-scale - like manual resize).
Also, mention window-scale no-effect-if-not-changed at the docs.
Based on code by @Dudemanguy from commit 873ae0d, with same effect.
This reverts commit 873ae0de2a.
The next commit will restore this functionality, with the
following differences from the reverted commit:
- Smaller and simpler code change.
- On bad scale: use "Invalid value" (compared to "no such property").
- Doesn't combine the docs for window-scale and current-window-scale.
- Doesn't remove the docs for window-scale behavior prior to 0.31.0.
Regression from 24357cb. It's ugly but unfortunately keeping tracking of
the last toplevel width and height really is the best way to solve this
problem and removing it was a mistake. Compositors don't always send
width/height coordinates of the actual window. The easiest way to
trigger this is by changing window-scale/current-window-scale and then
unfocusing the window. The compositor will send another toplevel
configure event with coordinates of the window before the resize. Maybe
compositors could be smarter but multiple ones do this (sway, gnome,
plasma), so just keep the old workaround. The only difference this time
is that the toplevel width/height is saved at the very beginning which
also covers the case where it equals 0 (i.e. weston).
Somewhat confusingly, mpv has both a window-scale option and a
current-window-scale property. The documentation lists window-scale
under properties (and it is technically is one), but at its core it is
actually an option which means it behaves subtly different. Options in
mpv are runtime-configurable, but they only change anything if the value
of the option itself changes. window-scale is an option and not meant to
keep track of the actual scale of the window (intended behavior
introduced by d07b7f0). This causes window-scale to do nothing in
certain cases (ex: the window is manually resized and window-scale is
set to 1.00 again). This is logical and consistent with the behavior of
the rest of the mpv options, but it also makes it a poor candidate for
setting the mpv window scale dynamically.
As a remedy, we can just make current-window-scale writeable instead.
current-window-scale is intended to always report the actual scale of
the window and keep track of any window size changes made by the user.
By making this property also writeable, it allows the user to have more
intuitive behavior (i.e. setting current-window-scale to 1.00 always
sets the window to a scale of 1). Additionally, the default input.conf
is changed to use current-window-scale instead of window-scale. The
window-scale documentation under property list is removed since it is
already documented under options and users should probably set the
current-window-scale property instead in most cases.
Using --sub-filter-regex-plain (default:no)
The ass-to-plaintext functionality already existed at sd_ass.c, but
it's internal and uses a private buffer type, so a trivial utility
wrapper was added with standard char*/bstr interface.
The plaintext can be multi-line, and the multi-line regexp flag is now
always set, but only affects plaintext (the ASS source is one line).
Pretty much identical to filter-regex but with JS expressions and
requires only JS support. Shares the filter-regex-* control options.
The target audience is Windows users - where filter-regex doesn't
work due to missing APIs, but mujs builds cleanly on Windows, and JS
is usually enabled in 3rd party Windows mpv builds.
Lua could have been used with similar effort, however, the JS regex
syntax is more extensive and also much more similar to POSIX.
1. On a pathological case where event_format is NULL, previously the
filter was trying to use it with each new sub - and re-failed. Now
the filter gets disabled on init (event_format doesn't change).
2. Previously, if the filter didn't modify the text or if the text
could not be extracted - it still allocated a new packet with same
content. Now it returns the original, saving a whole lot of no-ops
(there are still few allocations in this case though).
1 above is preparation for the next commit, and 2 was trivial, but
there's more to do if anyone cares (NIH string functions instead of
bstr, unused arguments, messages could be improved, and more).
Add two stand-alone function to help with the text-extraction task
which ass filters need. Makes it easier to add new filters without
cargo-culting this functionality.
Currently, on malformed event (which shouldn't happen), a warning is
printed when a filter tries to extract the text, so if few filters
are enabled, we'll get multiple warnings (like before) - not critical.
The regex filter now uses these utils, the SDH filter not yet.
The source of many geometry woes. There's some loosely related toplevel
things that should be cleaned up/fixed. First of all,
VO_EVENT_LIVE_RESIZING is actually completely useless. It might have
been useful sometime in the past, but there's no point. It doesn't
"speed up" resizing in any way and appears to be originally for cocoa.
Just remove it.
Way back in the day, toplevel_width/height was added as a workaround for
when we got uncoorperative (i.e. wrong) width/height coordinates from
the compositor in this event. Basically it could happen due to numerous
reasons but a lack of atomic commits was part of the reason and also
mpv's geometry handling then was a lot rougher. We *shouldn't* need this
workaround anymore. The width/height values are only used exactly when
we need them. If mpv sets geometry on its own, it should still be the
right dimensions.
Related to the above, mpv never actually propertly handled the case
where width or height was equal to 0. According to the xdg-shell spec,
"If the width or height arguments are zero, it means the client should
decided its own window dimension." An example of a compositor doing this
is weston. It's, unsurprisingly, broken. Getting out of fullscreen or a
maximized state does not restore the old window size like it should. The
right way to handle this is to just return near the end of the function
if we have a 0 for either argument and before any geometry is set
(wl->geometry's width or height can never be zero). Luckily, state
changes are already being detected so they just trigger the goto when
needed.
Finally, e2c24ad mistakenly removed the VO_EVENT_EXPOSE. There are edge
cases where this is needed and it's safer to just force a redraw here
when the window gets activated again. Just force wl->hidden to false
first and then trigger the expose.
Since 1d1d1fbff9 option-info/<name>/set-locally was being set to true
for every option. This broke setting start from ytdl-hook, which doesn't
overwrite start if it was set-locally. Fix this so that only adding an
option to reset-on-next-file or setting file-local-options/<name> make
set-locally true like before.
However, it's arguable that just adding an option to
reset-on-next-file without ever changing it should not make set-locally
true, so that e.g.
--reset-on-next-file=start 'https://youtube.com/watch?v=...&t=30'
will start at 30, though it currently doesn't.
Fixes#9081.
Previously we assumed the key-name string occupies strlen(name) cells,
now we count codepoints instead.
This improves alignment of non-english key names. Still not perfect
because we don't know if the key name is single or double width, but
wcwidth not available to scripts, notoriously unreliable (depends on
locale, correct and updated tables, etc), and also not always
available (Windows).
Still, better than nothing, and we err by at most one cell - vs up to
three before this commit (4 bytes keyname codepoint).
In the future we could do the alignment using libass tags, however,
this both complicates the ass-output generation, and also not available
when we output for the terminal, so for now only count codepoints.
Also, if the key name was in a right-to-left language, then previously
the name/command were swapped visually. Now we inject a left-to-right
marker before the name to ensure direction. This works also when
harfbuzz is disabled for libass (--sub-ass-shaper=simple).
Users expect single quotes to work when the value includes literal
backslashes or double-quotes (or as general quoting like in shell).
The updated docs also include some previously-missing notes:
- newline is only supported in double quotes.
- adjacent (quoted) arguments don't join into one.
Supporting mixed quoting (adjacent quoted strings) would make
mpv's parsing more complete, but would require delicate effort of
larger scope, for two reasons:
- We'd need to also support escaping outside of quotes and do our
best about backward compatibility.
- The parsed value can either be a substring of the input or
a newly-allocated string, which would be delicate when joining.
Not critical to add right now.
Custom quotes were added in 4f129a3e and began with !, however, this
required quoting "!reverse" (used for the cycle-values command), which
is inconvenient, and was not taken into account when ! was chosen for
custom quotes. Also, ` is more natural for quoting than !.
This does break backward compatibility with the earlier form of custom
quotes, but at least we didn't make a release yet since custom quotes
were added (the last release - 0.33[.1] doesn't support it).
Let audio-display determine whether embedded images or external cover
art tracks should be selected when both are present.
Attached pictures are given priority by default as requested in #8539.
Also updates references to attached pictures in the log and manpage to
refer to cover art as well.
Closes#8539.
This fix the warnings shown below when compiling the manual for
any of its three common formats:
```
DOCS/man/mpv.rst:46: (ERROR/3) Unknown target name: "--input-test".
DOCS/man/stats.rst:183: (ERROR/3) Unknown target name: "--input-test".
```
In rst, double-backtick starts a code string only if it's followed by
a non-space char, otherwise it's taken literally, hence, `` x2.0``
was taken literally rather than code string.
Because having these on every video is annoying, and when you resume
from watch later files, the filters are applied immediately so they hide
your osd-playing-msg or equivalent show-text commands.
More wayland weirdness. So previously, flipping a hidden state from true
to false was done in vo_wayland_wait_frame. In theory, this would be
after you get the frame callback and all those events so there's no
problem. However since the function also does a bunch of
flushing/dispatching/etc. to the default display queue so a lot of
unknown things can happen before we actually set the hidden variable
back to false. For example if a single image was paused and left on
another virtual desktop long enough (~5 minutes) while also not having
focus, switching back to that desktop could render it a black frame.
This edge case was supposed to be handled by the surface being activated
again in the toplevel event but apparently that doesn't always work. The
fix is to just delete all of that junk and set wl->hidden = false in the
frame callback. What's actually happening is kind of a mystery honestly.
Probably the compositor drops the buffers after a while as an
optimization (sensible) and forces a repaint if you switch back to the
virtual desktop. Somehow wl->hidden not being set to false would not
properly trigger a repaint (likely because it also sends a toplevel
event which does stuff) thus you just get a black window. If you just
make sure to set hidden in the frame callback, it appears like all of
these problems and edge cases are solved. Since this event must happen
first, that makes sense. That simplifies a lot of stuff and fixes some
subtle bugs at the same time so just go with this approach.
The EGL stuff is really complicated because of historical reasons
(tl;dr: blame EGL). There was one edge case with EGL context creation
that lead to incorrect behavior. EGL_KHR_create_context was created with
EGL 1.4 (which mpv does support) but it is still possible for an EGL 1.4
device to not implement this extension. That means that none of the EGL
attrs that pass a specific opengl version work. So for this obscure
case, there is a fallback context creation at the very end which simply
creates an EGLContext without passing any special attrs.
This has another problem however. mpv has a hard requirement on at least
desktop opengl 2.1 or opengl ES 2.0 to function (we're not asking for
much here). Since the fallback EGL context creation has no version
checking, it is entirely possible to create an EGL context with a
desktop opengl version under 2.1. As you get further along in the code,
the user will encounter the hard opengl version check and then error
out. However, we're supposed to also actually check if GLES works
(that's what the opengl-es=auto option is for) so this is a bug.
The fix is to do a bit of code duplication and make a mpgl_check_version
specifically for if we hit the edge case of needing to create an EGL
context without the EGL_KHR_create_context extension. Grab the version
with the function pointer, check if it's under 210, if so destroy the
EGL context and set it to NULL. After that, if the user has set
opengl-es to auto, mpv will try GLES next. If it is set to no, then mpv
will simply fail as desired. Fixes#5915.
Sidenote: the ra_gl_ctx_test_version originally testing 140 doesn't make
any sense. Passing the version number in that function only does
something if the user has set opengl-restrict. What we need to do is to
pass the version of the created context to that function. If the version
is higher than the opengl-restrict option, then make this a failure.
When changing image-display-duration at runtime, make the new value take
effect immediately, rather than from the next playlist-position change.
This allows toggling the slideshow mode while viewing images (without
hacks like executing playlist-play-index current afterwards).
All the conditions are just to be safe since even if you set time_frame
while playing a video, it's immediately overwritten by the next value.
mpv has two methods to display output from text input:
- show-text (scripting: mp.osd_message) has ass disabled by default
(escaped), and the property osd-ass-cc can control escaping.
- osd-overlay (scripting: mp.set_osd_ass or mp.create_osd_overlay)
has ass enabled (unescaped), and osd-ass-cc is NOT supported.
By default, stats.lua uses mp.osd_message which does support escaping.
That's persistent_overlay=no.
When using persistent_overlay=yes then mp.set_osd_ass is used.
Due to this, the no_ASS(..) function - which is supposed to escape
ass, simply returned its input unmodified when persistent_overlay
is enabled.
This is not a new issue, and the filters on page 1 use no_ASS() to no
avail in persistent mode, however, this content (filter name and value
strings) rarely actually needs escaping, and users didn't notice.
However, the new page 4 (keys) does break visibly when no_ASS doesn't
work, because it tries to escape arbitrary key-names and command
strings, and at the very least the key '{' is bound by default, which
is displayed incorrectly if escaping doesn't work.
Fix this by rolling our own escaping when using mp.set_osd_ass,
similar to how the mpv code does it for mp.osd_message (substrings
replacements).
However, this means that the set_ASS(..) function can no longer
behave correctly because escaping requires going through the whole
content string rather than only inserting a marker.
Luckily, other than at no_ASS, set_ASS was only used at one place
(text_style), which is only called from two places:
- generate_graph() only needs to restore styles - not to enable ass.
- add_header() is only used at the begining of page output, and
uses set_ASS to enable ass initially when using mp.osd_message.
So remove the set_ASS function, and instead enable ass directly at
print_page using osd-ass-cc when mp.osd_message is used.
Fixes#9022
This was explictly coded to avoid the autoprobe way back when in
2015[1] with no real explanation. In theory, there shouldn't be any
issues allowing this. If a user runs mpv in tty, this is probably what
they actually want in most cases. Perhaps something strange happens on
nvidia, but it should just fail anyway during the autoprobe.
[1]: https://github.com/mpv-player/mpv/commit/f757163058c2e5c7136213b0f79923fcea34b71a
As it turns out, js_try can throw if it runs out of try-stack
(without/before entering either the try part or the catch part).
If it happens, then C code which does allocation -> try will leak.
In mpv there were two places which do alloc and then try, one of
them as part of the autofree system. On both cases the leak is the
smallest possible (zero allocation) - talloc_new(NULL);
It's very unlikely to trigger - an autofree mpv API should be called
when the try-stack is exactly full, and our next try will throw
(and guaranteed to get caught at an outer level, but with a leak).
Fix that by doing the allocation inside the try block, so that if
try throws before it's entered then nothing got allocated/leaked.
Mujs internal code also has/had similar leaks, which are getting
fixed around this time (July 2021, post mujs 1.1.3).
[1] exhaust the try-stack or call-stack, whichever comes first:
function kaboom() { try { kaboom() } catch(e) {} }
--watch-later-options-remove doesn't accept multiple options, so split
the example.
Also suggest the more correct -clr to empty the list, and remove the
workaround to not print an error with --watch-later-options=
Previously, if a script bound the same key more than once to different
functions (without removing the older bindings first), then pressing
the key triggered any of the bound functions arbitrarily[1].
Now the newest binding for the same key is always the active one.
If the newest binding is then removed - the second-newest will become
active, etc. (same mechanism as before, except that the active key
was not always the newest).
[1] The order was implementation-defined, however `for (name in obj)'
happens to iterate. With mujs that's currently alhabetic order,
and name is from mp.add_[forced_]key_binding(key, name...)
or generated internally if name is not provided. So a binding with
higher alphabetic `name' value had priority over lower name value.
This allows configuring which options are saved by quit-watch-later.
Fixes#4126, #4641 and #5567.
Toggling a video or audio filter twice would treat the option as changed
because the backup value is NULL, and the current value of vf/af is a
list with one empty item, so obj_settings_list_equal had to be changed.
Unlike the page switching/scrolling keys which are bound at runtime
and therefore we need to know which (configured) keys to bind, the
main keys (i/I by default) are static and can be bound via input.conf.
And indeed, the builtin bindings at etc/input.conf have them already.
- The video filter to turn the video upside-down is vflip. There is no
filter called "flip" so using it just causes an error.
- Reword a sentence.
- Add exact and all to the values accepted by cover-art-auto. They were
implemented in 029ff1049b but not added to the accepted arguments.
Page 4 bindings listing wants to exclude the interactive keys of the
stats script itself - so that they don't hide the normal keys which
are bound when stats is not interactive.
It did so by testing that the bound command includes stats/__key
which is how it usually looks when a script binds keys.
However, if a script uses a name for the binding - like stats.lua does
for the interative keys (because it later removes them by name when
interactive mode ends), then the command has stats/name rather than
stats/__key...
To fix this, we change the names of the forced interactive bindings
to start with __forced_, and that's now also what the page-4 listing
excludes.
This reverts commit 0f1654811bda0dfdd337734ec33c59b67522234a.
It was an incorrect fix, because the key names do get used - to remove
the forced bindings once stats exits the interactive mode.
And without names - the interactive keys remained active even after
stats exited interactive mode.
The page 4 keybinding list tries to skip the interactive bindings of
stats itself (because they would hide the normal bindings of these
keys when stats is not visible), and to do that it excludes commands
containing "script-binding stats/__key" - which is how script-added
bindings usually look like.
However, keys which are added with a "name" bind stats/name rather
than stats/__key... - and that's what stats.lua did till now with its
interactive force-bindings.
Now the interactive forced bindings are added without a name, and so
they do end up using the automatic stats/__key... and get excluded.
While --input-test is useful, and so is page 4 of stats, until now
there was no way to simply print the list in a help-like fashion.
This commit adds such printout, invoked by the script opt
stats-bindlist=yes, which uses the existing page 4 code. This prints
the list on startup and quits immediately - like any help page.
It's awkward to invoke compared to other help pages, and it does
require the stats page to be enabled (it is by default), however
it is a script-generated output, and currently there's no other
method to print a help page generated by a script.
The printout itself is performed using lua's io.write. While reliable,
it's not the standard way for mpv to print to the terminal.
Other possible printout methods are mp.msg.info - which also prints
"[stats]" prefix on each line (ugly), or forcing term-osd and setting
an osd-message which mpv will then print at the terminal - however
that's printed to stderr, and could also be subject to timing concerns
since we quit right afterwards.
In the future we can consider changing/integrating the invocation so
that mpv itself could print a help page generated by a script, thus
solving both the awkward invocation and printout-method issues.
This is a scrollable page which also works nicely with the terminal
OSD. Typically there are more than 100 bound keys.
It groups the binding using fuzzy property/command/script name after
simple analysis of the command string, and then further sorts the
binding in each group according to the "complexity" of the key itself
(plain keys -> keys with modifiers, alphabetically, etc).
The alignment/grouping style is heavily inspired by @medhefgo's #8924
but otherwise it's an independent implementation.
Typically the current page is rebuilt and rendered once per second,
howeve, scrolling can invoke the rebuild function very frequently,
even at a rate which is too fast for the rebuild function to keep
up. This can result in high CPU usage and input lag.
This commit adds an argument to the page-rebuild function, letting it
know whether or not it's called following a scroll keypress, thus
allowing it to cache intermediate data so that it doesn't have to
re-calculate the whole page from scratch.
This additional argument is unused currently, but it could be useful
for the internal performance page - which can be relatively heavy.
When playing a new file, if paused_for_cache was true before being reset
the AO would never be unpaused because that state was thrown away, leaving it stuck.
Fix this by updating the pause state before resetting that variable. Note that this
does not make the second update_internal_pause_state() call redundant.
This fixes the same bug fb5d976cb0 was supposed to.
The previous code tried to disable autocrop for cover-art by testing
that track-list/$vid/albumart is false, however, $vid is completely
unrelated to the track-list index.
It only sometimes succeeded to disable for albumart, by accident,
e.g. with one audio track and one video track where $vid==1 and
track-list/1 happens to be the video (cover art) track.
The new code detects the currently-used video track by finding a track
with type=="video" and selected==true. Unlike the previous code, it
also works in scenarios with many audio/video/sub tracks.
Additionally, autocrop is now enabled also with lavfi-complex, which
should be considered an improvement. The previous code implicitly
disabled it with lavfi-complex because $vid is nil on such case.
in->byte_level_seeks field is written and modified inside
update_bytes_read at the same time when demux_get_reader_state
is executing, which locks the demux thread mutex. This results
in a data race, reported by Thread Sanitizer when playing mp3 file
of sufficient long length.
reinit_audio_filters_and_output function will free mpctx->ao_chain
when there is a failure during audio initialization. So modify it
to return -1 in case of init failure. The return value is checked
to avoid use after free. Reported by Address Sanitizer when manually
specifying --ao which triggers "Failed to initialize audio driver" error.
When using "stty susp ''" to disable sending the TSTP signal with ^Z,
mpv didn't recognize ^Z correctly in the terminal:
[input] No key binding found for key 'Ctrl+2'.
Because ASCII 26 (^Z) and above were incorrectly considered ^<NUMBER>.
This commit moves the cutoff between letters/numbers from 25 to 26 so
that ^Z is now detected correctly as ^<LETTER>.
Additionally, it rephrases the ^<NUMBER> formula for clarity.
The --secondary-sub-visibility options was previously undocumented in
the pull request that added it. This commit adds documentation for it
and clarifies its behavior.
Modifies the sub-seek and sub-step commands with a second <flags>
argument to specify whether to seek/step on the primary or secondary
subtitles. The flag is used to index into the current_track array in
cmd_sub_step_seek.
Adds secondary-sub-start and secondary-sub-end properties by setting
the current_track index in the m_property's priv variable which later
gets accessed in get_times. Also adds a test of the secondary subtitle
time properties in tests/subtimes.js bound to 'T'.
Though, only when the output format is matroska, to avoid muxing errors.
This is quite useful when the input has ASS subtitles, as they tend to
rely on embedded fonts.
I've looked and studied the flow in the recorder, and to my
understanding, the packet queue is moot after the initial sync, maybe
even then - but that's beyond me right now.
With the previous choice to mux trailing packets whatever the case, this
doesn't result in any new ill effects (and some missing packets at the
end is no big deal).
Notably, since we don't have to hold onto the packets after we get
muxing, we'll never run into any issues with veeery long GOPs filling up
our queue (resulting in dropped packets and much user chagrin).
For muxing, FFmpeg expects the FLAC extradata to be just the bare STREAMINFO,
and passing the full FLAC extradata (fLaC header and block size, with any
additional channel layout metadata) will result in malformed output, as
ffmpeg will simply prefix another fLaC header in front.
This can be considered to be a bug.
FFmpeg's own demuxers only store the STREAMINFO, hence the naivety, while
our common source of FLAC streams, the matroska demuxer, holds onto the
full extradata. It has been deemed preferable to adjust the extradata upon
muxing, instead of in the demuxer (ffmpeg's FLAC decoder knows to read
the full fLaC extradata).
This fixes muxing FLAC streams, meaning recorder.c or dump-cache.
dump_cache() calls qsort() to order an array of pointers, while the
comparator forgets it's receiving pointers to pointers.
Since cache-dumping over multiple cache ranges is fairly rare, this
seems to have gone unnoticed.
In commit f7678575a5, wm4 chooses to mux
all remaining packets when mp_recorder_mark_discontinuity() is called and
adds a call to mux_packets(). However, it is called only after flush_packets(),
which clears the packets before they can be muxed out. This has no ill
effects per se - recordings end on keyframes, as before - but judging from
his commit message, the intention explicitly was to output the inter
frames, since long GOPs can mean several seconds of missing content from
the output. So, clear the stream packet queues only after the final mux.
Also, flushing can mean both discarding and committing. What a country!
osc-visibility can already be changed at runtime via script-message
or other means, but until now there was no way to tell what the
current state is.
Now shared-script-properties/osc-visibility reflects this state.
It's output-only by the osc - changing it does not affect the osc.
Useful if a script wants to change osc-visibility temporarily, and
later restore to its original state.
There's no way to coordinate if more than one script wants to change
it, but that would be a hard problem to solve anyway, even if the
osc itself tried to coordinate such requests from different sources.
Another day, another wayland refactor. Way back when, dcc3c2e added
support for the hidpi-window-scale option (something you probably should
never set to no but whatever) to wayland. Well technically, it never had
any runtime toggling support (don't remember if detecting when vo_opts
changed was possible or not then; maybe not). Anyways in the process of
fixing that, I went ahead and refactored how this is all handled. The
key difference is that when hidpi-window-scale is disabled, wl->scaling
is directly set to 1 instead of forcibly setting
wl->current_output->scale to 1. Note that scaling operations don't
always require a geometry reset/resize so set_surface_scaling needs to
be separate from set_geometry. The logic here is kind of complicated but
it (should) be correct.
The wl_surface lives for the entire lifetime of the vo. It's only
neccesary to set the scale initially and when the output scaling changes
(the surface moves to a different output with a different scale or the
output itself changes it scale). All of the calls that were being made
in the egl/vulkan resize functions are not needed. vo_wlshm wasn't
correctly rescaling itself before this commit since it had no logic to
handle scale changes. This should all be shared, common code in the
surface/output listeners.
A subtle regression from c26d833. On sway if mpv was set to be a
floating window in the config, set_buffer_scale would actually get
applied twice according to the wayland log. That meant a 1920x1080
window would appear as a 960x540 window if the scale of the wl_output
was set to 2. This only affected egl on sway (didn't occur on weston and
was too lazy to try anything else; probably they were fine). Since
wl->render is initially false, that meant that the very first run
through the render loop returns false. This probably caused something
weird to happen with the set_buffer_scale calls (the egl window gets
created and everything but mpv doesn't write to it just yet) which makes
the set_buffer_scale call happen an extra time. Since it was always
intended for mpv to initally render, this is worth fixing. Just chnage
wl->render to wl->hidden (again) and flip the bools around. That way,
the initial false value results in render == true and mpv tries to draw
on the first pass. This fixes the weird scaling behavior because
reasons.
Not sure what I was on when I wrote this. wayland-app-id is supposed to
default to "mpv". Just set that in the vo_sub_opts and don't do this
weird m_config_cache_write_opt thing. Also make the doc entry nicer.
Mostly a cosmetic change that (hopefully) makes things look better. Some
functions and structs that were previously being exported in the wayland
header were made static to the wayland_common.c file (these shouldn't be
accessed by anyone else).
When the current file is hidden and `ignore_hidden` is true,
autoload will skip loading other files in the current directory. Make
sure that the current file is always counted for autoloading even if it
is hidden.
In 8a7614a0fb files that start with a '.'
were blacklisted from autoload.lua. Since then
35e8710b86 was introduced and explicitly
whitelisted file extensions. With this change, there is no longer a
reason to blacklist all files starting with '.', because it is valid to
have a file called '.hidden.mkv', and there is no chance of hidden files
such as '.bashrc', '.DS_STORE', '.gitignore', etc. being autoloaded by
mpv.
This commit tries to keep the same behavior as before, which is to by
default not load hidden files, but allows the user to optionally allow
hidden files to be autoloaded.
Commits 4d1ffec and 6e481d0 renamed sub-ass-style-override to
sub-ass-override. But in commit bd603c2, when renaming it in
quit-watch-later's backup_properties, which determines which properties
are saved by quit-watch-later/write-watch-later-config, it was
incorrectly renamed to sub-style-override instead, and thus never got
saved even if modified at runtime. Instead mpv attempted to save the
non-existing property "sub-style-override", but since no error is raised
when saving non-existing properties with quit-watch-later, no one
noticed it. This commit renames the saved property to the correct new
name "sub-ass-override" so that it does get saved.
This fixes two issues, both of which resulted from the timers-wait
period not being re-calculated after idle-observers were executed:
- If timers were added from an idle observer then they could fire long
after they were due (only when/if the next mpv event arrives).
- Idle observers don't execute in zero time, and the wait period for
the next timer was implicitly extended by the idle observers
execution time (because it was calculated before the idle observers).
This commit ensures that if idle-observers were executed, then the
timers wait period is re-calculated, which solves both issues.
Previously, process_timers() kept going as long as there were due
timers, which could be for extended periods of time or even forever
if there were slow timer callbacks with either periodic timers or if
timers were added repeatedly.
This prevented dequeuing mpv events, and subsequently, among others,
prevented mpv from quitting until process_timers() completed.
For instance, this caused process_timers() to never return:
function render() <longer than 1/60 s on a slow system> end
mp.add_periodic_timer(1/60, render)
Similarly, it never returned if a timer callback always added a new
one-shot which was already due by the time the callback completed.
This commit ensures that process_timers() only executes callbacks which
were due when it started, so that timers which are added (or repeated)
during process_timers() will wait for the next iteration - after mpv
events are dequeued.
This has no performance impact under normal conditions (when callbacks
complete before the next timer is due).
Additionally, previously idle-observers were executed unconditionally
after the timers because indeed there was nothing due when (if...)
process_timers() completed. However, now process_timers() can return
even if there are due timers, so skip idle-observers on such case.
This fixes a long-standing apparent issue where mpv would display the last
frame with no subtitles at EOF. This is caused by sub rendering switching from
video timestamps to audio timestamps when the video ends, and audio streams
often running past the timestamp of the last video frame. However, authoring
tools (most notably Aegisub) don't tend to provide easy ways to add meaningful
subtitles after the end of the video, so this is rarely actually useful.
This makes cover-art-auto behave more like sub-auto and audio-file-auto:
- load cover art with a language, e.g. if playing foo.mp3, foo.en.jpg
will be loaded with lang=en
- load cover art containing the media filename with fuzzy and all, e.g.
'foo (large).jpg'
- make all/2 load all images in the directory, and make fuzzy/1 the
default
These are all uncommon use cases, but synchronizing the behavior of the
external file options simplifies the code.
The idle-observers block has at least 3 function calls, and it was
entered every time the script went into idle, however, we can save these
calls by checking first that there are indeed such observers.
Remove the check that the external filename is not the same as the
currently playing one, which prevents mpv from loading images again as
external cover art, but this isn't necessary because cover art is only
added when playing standalone audio. I had only added this check because
I would otherwise get a segfault only when compiling with gcc 10.2 with
optimize and changing position within a playlist of multiple images (and
this couldn't even be reproduced by Dudemanguy on the same gcc version),
but this was caused by the uninitialized lang variable which is now
fixed.
Commit 029ff10 added a goto statement which skipped initializing the
`lang' variable. This could crash depending on compiler optimizations
and other factors: if the lang bstr pointer happened to end up NULL
(which is apparently the case with most compilers) then it's validly
empty, but if it pointed to a random and incorrect memory address then
it crashed.
The crash was observed when mpv was compiled using gcc 10.2 with
optimizations enabled, and affected some third party Windows builds.
This commit ensures the goto doesn't skip the initialization.
Thanks to votemp for figuring this out.
Fixes#8922.
Previously tick() was ensured unconditionally only after mouse-move,
but there are other mouse-events which need re-rendering (tick), like
mouse-down (icons may get grayed-out) or mouse-up (icons may change).
For instance: mpv --pause --myclip.mkv
then move the mouse over the volume/mute OSC button, then - without
moving the mouse - press and release the left mouse button.
The osc was not re-rendered because it's paused and the mouse didn't
move, so the volume icon didn't get grayed-out when held down, and the
icon doesn't change on mouse-up (to reflect the new mute state).
Now both these changes are rendered correctly.
This is not a new issue, however, until the last commit - 96b246d
init probably didn't happen much (or at all) between mouse-down and
mouse-up, but after this commit, if there are chapters in a live-stream
then osc_init() is used to re-render the markers at the adjusted
position - which breaks the OSC buttons functionality if init happened
between mouse-down and mouse-up.
Commit 6abb7e3 updates the markers when the chapters change, but it
doesn't update their relative position at the bar when the duration
changes.
This means that adding chapters to a live stream would result in
corresponding chapter markers which were static while the duration
changed and thus their positions became incorrect over time until the
OSC was reinitialized.
This is fixed by observing the duration property if chapters are present
and reinitializing the OSC when the duration changes.
The live_markers user option, which determines whether the duration
property is observed when there are chapters, has been added in order to
allow disabling this behaviour as calling request_init() frequently
might have some impact on low-end systems.
The impact of request_init() on render() was measured to increase from
1-1.5 ms to 2-3 ms on a 2010 MacBook Air, while the impact was neglible
on a 2016 Surface Book (increasing only to an average of 1.4 ms from
1.3 ms for n=1500 render cycles).
The live_markers option is enabled by default.
If a plane is not connected to any displays, we won't set an entry in
the mapping of planes to displays. So ensure these unset entries are
null and skip them.
Fixes#8913
This is the Vulkan equivalent of the drm context for OpenGL, with
the big difference that it's implemented purely in terms of Vulkan
calls and doesn't actually require drm or kms.
The basic idea is to identify a display, mode, and plane on a device,
and then create a display backed surface for the swapchain. In theory,
past that point, everything is the same, and this is in fact the case
on Intel hardware. I can get a video playing on a vt.
On nvidia, naturally, things don't work that way. Instead, nvidia only
implemented the extension for scenarios where a VR application is
stealing a display from a running window system, and not for
standalone scenarios. With additional code, I've got this scenario to
work but that's a separate incremental change.
Other people have tested on AMD, and report roughly the same behaviour
as on Intel.
Note, that in this change, the VT will not be correctly restored after
qutting. The only way to restore the VT is to introduce some drm
specific code which I will illustrate in a separate change.
The VkDisplayKHR context type requires making calls against the
physical device before the libplacebo context is initialised.
That means we can't simply use the physical device object that
libplacebo would create - instead we have to create a separate one,
but make sure it's referring to the same physical device.
To that end, we need the device name that the user may have requested
so we can pass it on.
This moves the JSON parsing above the main youtube-dl error-handling
block and integrates parsing errors into that block. Now, if a parsing
error occurs, youtube-dl's stderr will be logged as it is with other
errors. This also catches errors that cause youtube-dl to output
"null", which would previously be mishandled as a parsing error and
crash ytdl_hook when it attempted to concatenate the error string from
parse_json.
This was originally just a bugfix for a race condition, but the scope
expanded a bit. Currently, the wayland code does a prepare_read ->
dispatch_pending -> display_flush -> read_events -> dispatch_pending
routine that's basically straight from the wayland client API
documentation. This essentially just queues up all the wayland events
mpv has and dispatches them to the compositor. We do this for blocking
purposes on every frame we render. A very similar thing is done for
wait_events from the VO.
This code can pretty easily be unified and split off into a separate
function, vo_wayland_dispatch_events. vo_wayland_wait_frame will call
this function in a while loop (which will break either on timeout or if
we receive frame callback from the compositor). wait_events needs to
just check this in case we get some state change on the wakeup_pipe
(i.e. waking up from the paused state).
As for the actual bugfix part of this, it's a slight regression from
c26d833. The toplevel config event always forced a redraw when a surface
became activated again. This is for something like displaying cover art
on a music file. If the window was originally out of view and then later
brought back into focus, no picture would be rendered (i.e. the window
is just black). That's because something like cover art is just 1 frame
and the VO stops doing any other additional rendering. If you miss that
1 frame, nothing would show up ever again. The fix in this case is to
always just force a redraw when the mpv window comes back into view.
Well with the aforementioned commit, we stopped doing
wl_display_roundtrip calls on every frame. That means we no longer do
roundtrip blocking calls. We just be sure to queue up all of the events
we have and then dispatch them. Because wayland is fundamentally an
asynchronous protocol, there's no guarantee what order these events
would be processed in. This meant that on occasion, a
vo_wayland_wait_frame call (this could occur multiple times depending on
the exact situation) would occur before the compositor would send back
frame callback. That would result in the aforementioned bug of having
just a black window. The fix, in this case, is to just do a
vo_wayland_wait_frame call directly before we force the VO to do a
redraw. Note that merely dispatching events isn't enough because we
specifically need to wait for the compositor to give us frame callback
before doing a new render.
P.S. fix a typo too.
And also change the existing WM_KILLFOCUS handler to return 0 instead
of 'break' (which later calls DefWindowProcW), as MSDN says we should
do for WM_{KILL,SET}FOCUS.
It seems that the 'focused' property is now supported by all main VOs:
x11, macOS, wayland, Windows.
TCT/sixel/caca probably don't support it, and unknown with SDL.
Fixes#8868
When the OSC initializes, it checks whether the current video has
chapters, and if it does not, it disables its chapter functionality
(chapter buttons are grayed out and unusable, chapter indicators don't
show on the seek bar). If another script changed the chapter list
after the video has loaded, those changes would be ignored by the OSC
until some other event causes it to re-initialize, because it did not
observe the chapter list property. This is fixed by adding
observation of chapter-list alongside the other properties that
trigger re-initialization.
Avoiding blindly copying the codec_tag between different formats allows
us to mux packets from, say, mpegts streams to matroska, making the
recorder (dump-cache) much more usable as unsupported codec_tags can
make the muxer reject the streams.
This brings my scaletempo2 benchmark down from ~22s to ~7s on my machine
(-march=native), and down to ~11s with a generic compile.
Guarded behind an appropriate #ifdef to avoid being ableist against
people who have the clinical need to run obscure platforms.
Closes#8848
Not only does this have semantics that make far more sense, it also has
a default that makes far more sense. (Equivalent to the old
`icc-contrast=inf`)
This removes the weird 1000:1 contrast default assumption which
especially broke perceptual profiles and also screws things up for
OLED/CRT/etc.
Should probably close some issues but I honestly can't be bothered to
figure out which of the thousands colorimetry-related issues are
affected.
Take two. f4e89dd went wrong by moving vo_wayland_wait_frame before
start_frame was called. Whether or not this matters depends on the
compositor, but some weird things can happen. Basically, it's a
scheduling issue. vo_wayland_wait_frame queues all events and sends them
to the server to process (with no blocking if presentation time is
available). If mpv changes state while rendering (and this function is
called before every frame is drawn), then that event also gets
dispatched and sent to the compositor. This, in some cases, can cause
some funny behavior because the next frame gets attached to the surface
while the old buffer is getting released. It's safer to call this
function after the swap already happens and well before mpv calls its
next draw. There's no weird scheduling of events, and the compositor log
is more normal.
The second part of this is to fix some stuttering issues. This is mostly
just conjecture, but probably what was happening was this thing called
"composition". The easiest way to see this is to play a video on the
default audio sync mode (probably easiest to see on a typical 23.976
video). Have that in a window and float it over firefox (floating
windows are bloat on a tiling wm anyway). Then in firefox, do some short
bursts of smooth scrolling (likely uses egl). Some stutter in video
rendering could be observed, particularly in panning shots.
Compositors are supposed to prevent tearing so what likely was happening
was that the compositor was simply holding the buffer a wee bit longer
to make sure it happened in sync with the smooth scrolling. Because the
mpv code waits precisely on presentation time, the loop would timeout on
occasion instead of receiving the frame callback. This would then lead
to a skipped frame when rendering and thus causing stuttering.
The fix is simple: just only count consecutive timeouts as not receiving
frame callback. If a compositor holds the mpv buffer slightly longer to
avoid tearing, then we will definitely receive frame callback on the
next round of the render loop. This logic also appears to be sound for
plasma (funfact: Plasma always returns frame callback even when the
window is hidden. Not sure what's up with that, but luckily it doesn't
matter to us.), so get rid of the goofy 1/vblank_time thing and just
keep it a simple > 1 check.
Checking against 1.0 is wrong for this code, because it's in an absolute
luminance scale relative to reference white. We should be normalizing
this by `dst.sig_peak`.
This is actually a very nice simplification that should have been
thought of years ago (sue me). In a nutshell, the story with the
wayland code is that the frame callback and swap buffer behavior doesn't
fit very well with mpv's rendering loop. It's been refactored/changed
quite a few times over the years and works well enough but things could
be better. The current iteration works with an external swapchain to
check if we have frame callback before deciding whether or not to
render. This logic was implemented in both egl and vulkan.
This does have its warts however. There's some hidden state detection
logic which works but is kind of ugly. Since wayland doesn't allow
clients to know if they are actually visible (questionable but
whatever), you can just reasonably assume that if a bunch of callbacks
are missed in a row, you're probably not visible. That's fine, but it is
indeed less than ideal since the threshold is basically entirely
arbitrary and mpv does do a few wasteful renders before it decides that
the window is actually hidden.
The biggest urk in the vo_wayland_wait_frame is the use of
wl_display_roundtrip. Wayland developers would probably be offended by
the way mpv abuses that function, but essentially it was a way to have
semi-blocking behavior needed for display-resample to work. Since the
swap interval must be 0 on wayland (otherwise it will block the entire
player's rendering loop), we need some other way to wait on vsync. The
idea here was to dispatch and poll a bunch of wayland events, wait (with
a timeout) until we get frame callback, and then wait for the compositor
to process it. That pretty much perfectly waits on vsync and lets us
keep all the good timings and all that jazz that we want for mpv. The
problem is that wl_display_roundtrip is conceptually a bad function. It
can internally call wl_display_dispatch which in certain instances,
empty event queue, will block forever. Now strictly speaking, this
probably will never, ever happen (once I was able to to trigger it by
hardcoding an error into a compositor), but ideally
vo_wayland_wait_frame should never infinitely block and stall the
player. Unfortunately, removing that function always lead to problems
with timings and unsteady vsync intervals so it survived many refactors.
Until now, of course. In wayland, the ideal is to never do wasteful
rendering (i.e. don't render if the window isn't visible). Instead of
wrestling around with hidden states and possible missed vblanks, let's
rearrange the wayland rendering logic so we only ever draw a frame when
the frame callback is returned to use (within a reasonable timeout to
avoid blocking forever).
This slight rearrangement of the wait allows for several simplifications
to be made. Namely, wl_display_roundtrip stops being needed. Instead, we
can rely entirely on totally nonblocking calls (dispatch_pending, flush,
and so on). We still need to poll the fd here to actually get the frame
callback event from the compositor, but there's no longer any reason to
do extra waiting. As soon as we get the callback, we immediately draw.
This works quite well and has stable vsync (display-resample and audio).
Additionally, all of the logic about hidden states is no longer needed.
If vo_wayland_wait_frame times out, it's okay to assume immediately that
the window is not visible and skip rendering.
Unfortunately, there's one limitation on this new approach. It will only
work correctly if the compositor implements presentation time. That
means a reduced version of the old way still has to be carried around in
vo_wayland_wait_frame. So if the compositor has no presentation time,
then we are forced to use wl_display_roundtrip and juggle some funny
assumptions about whether or not the window is hidden or not. Plasma is
the only real notable compositor without presentation time at this stage
so perhaps this "legacy" mechanism could be removed in the future.
when using the bundle with activated big enough cache, very slow and
wasteful memory allocations lead to jittery playback and lot of dropped
frames. the cache had to have a certain size so it would constantly
allocate new memory to reproduce this. this never happens when started
from the terminal.
the source of the problem is a different malloc allocation policy,
MALLOC_NANO, that allocated a huge amount of virtual memory without
actually using it. the usage was between 0% to 25% of that virtual
memory. the binaries allocation policy on the other hand used >80% of
that allocated virtual memory and was a lot more efficient, it would use
MALLOC_TINY instead.
this is fixed by setting the MallocNanoZone environment variable to 0
to use the V1 of the allocation policy. when started from the bundle via
launchd this is forced to 1 and V2 policy which causes this problem.
some more info can be found in following file and its comments on the
Apple open source site:
https://opensource.apple.com/source/libmalloc/libmalloc-317.40.8/src/nano_malloc_common.c.auto.htmlFixes#7405
Shows uploader, channel, description fields. This works only if the
media media is constructed as EDL (for youtube it usually does this),
and if the all_formats option is not set to true (does anyone even use
it?). The former usually happens because youtube serves audio and video
separately, though it will not for live HLS/DASH. The latter uses
delayed media opening, which breaks the global_tags mechanism (see
previous commit).
Add new header which shows up as tags/metadata (associated with
--display-tags). The way this is added means it doesn't always work,
because root->meta (see code) can be NULL for some absurd reason. But it
works for the one case I intended to use it (ytdl_hook, see next
commit), though only in default configurations.
When trying to use completion for mpv binaries specified with some shell
glob, e.g. ~/dev/mpv/build/mpv, the current code doesn't substitute the
homedir prefix into the path name, resulting in runtime errors about
the file '~/dev/mpv/build/mpv' not being found.
The simple fixed is to use $~var instead of $var whenever expanding the
filename, which performs the same globbing that would otherwise be
performed when executing the command.
This reverts commit b8156a9a86.
Apparently there are two problems here. One on Linux (fixed by the
original change and this revert) and one on alternative-medicine-Job's
OS. Since the latter has deprecated OpenGL and OpenGL is a second-class
citizen, I think it's better to prefer the fix for a platform that is
still alive.
When inserting vf_sub, the VO OSD is directed not to draw itself. But
this flag was never unset, even when removing vf_sub.
The fix is pretty shit, but appears to work.
Switching to a new file while keeping the AO didn't update the volume.
While there's an explicit audio_update_volume() call in
reinit_audio_chain_src(), it doesn't work, because at that point
ao_chain->ao is still NULL, and it does nothing. That's pretty weird and
might cause other problems (what happens if you try to mute while the AO
is "floating"?). Regarding gapless, trying to use the AO gain for
replaygain is also gross nonsense, because the new replaygain computed
gain would affect audio from the previous file. It looks like replaygain
should be in an af_volume filter maybe. On the other hand, I enjoy
setting ridiculous replaygain-preamp values and compensating with a low
volume setting, which would not work well if both gains were applied to
the audio independently.
For now, just add the missing call. This is orthogonal to fixing
replaygain "properly".
This reverts commit 3239e41277.
I'm fairly sure this is wrong, and my next commit should fix it
properly. I'm not really sure, though. Normally, the AO is set again
by reinit_audio_filters_and_output() after the new audio chain has
decoded a frame and knows the new format. The reason replaygain (and
apparently the thing the reverted commit tried to fix) didn't work is
because they work asynchronously to the audio played by the AO (i.e.
buggy and hard to fix).
For some reason, this never existed before. Add VOCTRL_GET_DISPLAY_RES
and use it to obtain the current display's resolution from each
vo/windowing backend if applicable. Users can then access the current
display resolution as display-width and display-height as per the client
api. Note that macOS/cocoa was not attempted in this commit since the
author has no clue how to write swift.
This commit describes more accurately what currently gets disabled
by this option - specifically also keys from mp.add_key_binding.
It's not necessarily the best behavior because libmpv clients might
want to disable mpv's own builtin keybindings while still allowing
scripts to define keys which `input.conf' can override.
In the future we might exclude mp.add_key_binding from this option,
but for now at least document this option accurately.
Fixes#8809
3909e4cdfc seems to have replaced this 0.5 constant by 0.75, using its
presence in glumpy as justification.
0.75 is clearly a bug in glumpy, as its own source code doesn't even
match the comment immediately above it. Every other implementation of
this window I could find uses 0.5, including e.g. ImageMagick.
The ctime member on Windows uses FILE_BASIC_INFO.ChangeTime, which is
pretty much the same as st_ctime on POSIX.
See https://devblogs.microsoft.com/oldnewthing/20100709-00/?p=13463 :
... The LastWriteTime covers writes to the file’s data stream
(which you accomplish via the WriteFile function). On the other
hand, the ChangeTime also includes changes to the file metadata,
such as changing its file attributes ...
Fixes#8801
We now have at least 3 scripting APIs which are trivial wrappers
around properties: mp.get_mouse_pos, utils.getcwd, utils.getpid.
After some discussion on IRC it was decided that it's easier for us to
maintain them as trivial wrappers than to deprecate them and inflict
pain on users and script authors, so currently no plan to deprecate.
Some subproperties in osd-dimensions were returned as doubles despite
actually being integers. Additionally, correct a highly misleading line
in the osd-width/osd-height documentation.
This fixes a bug where using boxvideo with showfullscreen=no or
showwindowed=no resulted in the margins not resetting when the OSC
wasn't visible.
For example, using:
script-opts=osc-visibility=always,osc-boxvideo=yes,osc-showfullscreen=no
and then going fullscreen would make the OSC disappear but the video
margins would remain. This is because boxvideo was missing a dependence
on the showfullscreen and showwindowed user options.
This is fixed by adding the corresponding conditions to update_margins()
and setting state.marginsREQ on fullscreen changes. update_margins() is
called on tick() if there's a margins update pending, which guarantees
the boxvideo margins are reset appropriately.
It turns out that if a user specifies fullscreen=yes and a width/height
in an autoprofile, the compositor can execute its toplevel listener
event. This can happen before we have any mpv window rendered at all so
we end up performing a bunch of geometry operations and state checks
when we shouldn't. It subtly messes up a lot of things like state
detection. Just return from this function if the geometry has no width
or height yet.
Clearing state.osd.data with an empty string at render_wipe() fixes an
issue where changing the OSC visibility from "never" directly to
"always" didn't immediately update the display when the player was
paused. This could be verified by starting the player with
`--script-opts=osc-visibility=always --pause` and then running
`script-message osc-visibility never` followed by
`script-message osc-visibility always`.
Removing the overlay without changing the contents meant the overlay
wouldn't update and display when enabled again until the fields changed
in some way (e.g. seeking, mousing over the OSC area, etc.). Clearing
state.osd.data before removal of the OSC makes sure set_osd doesn't
return on re-enable and instead displays the OSC immediately as the data
is now different.
render_wipe() is now also used when the OSC needs to be cleared at
tick() as using set_osd to clear it with an empty string did not call
state.osd:remove() which can allow cleanups related to bitmap memory
allocations etc.
this is a regression of af26402, where we changed the geometry
calculation to use the visible frame and consider its origin. though the
origin is not screen relative but relative to the main screen. the rest
of the code expects a screen relative rectangle. because of that windows
would be placed out of the screen bounds when not on the main screen.
recalculate to origin to be screen relative and use those values for the
rest of the calculations. to make the code a bit more comprehensible
be a bit more explicit about what is done where with temporary variables
and comments. also move the mp_rect calculation that moves the origin
and flips the y position to a separate function, so we can reuse it
later.
The fit_on_screen logic was a bit twisted. Simplify it a bit
and update few comments to explain better what it's used for.
Note that the new logic is not identical to before, but its intent
should now be clearer. This means there might be regressions or
improvements at edge cases. If followup fixes are needed, then we
should keep the intent clear. Most likely though that it's fine.
fit_on_screen is called only from reinit_window_state.
Move the yes/no logic unmodified from fit_on_screen to
reinit_window_state, and remove the w32->parent condition because it's
already checked earlier at reinit_window_state.
Previously, because the video (client area) was centered but the top
and bottom borders are uneven (title is taller), then if the window
is shrunk vertically to just-fit the desktop - the top edge of the
title bar ended above the top edge of the display.
This is a state which Windows prevents during manual move, but
apparently it's not rejected at the Windows API.
Now we ensure it doesn't happen, and nudge the window down to align
the top edges if necessary.
This is a commulative regression of commits 981048e0 and 364af7c6.
To clarify functionality, this includes a no-op change: fit_rect was
renamed to fit_rect_size and it now takes explicit width and height,
because it only used the width/height of rc2 anyway.
Fixes#6695
The accurate description of this option was:
- fit-border is enabled by default. When disabled, it adds a bug where
if the window has borders and mpv shrinks it to fit the desktop, then
the calculation ignores the borders and adds incorrect video crop.
The option was added at commits 70f64f3c and 949247d6, in order to
solve an issue (#2935) where if mpv wanted to display a video with
size WxH, then w32_common.c incorrectly set the window to WxH, while
down-scaling the video slightly to fit (even with small sizes).
It was addressed with a new option which is enabled by default, but
does the right thing (sets the client area to WxH) only when disabled,
so that everyone who prefers their video slightly downscaled could
keep their default behavior.
(#2935 also addressed an off-by-one issue, fixed before fit-border)
While disabling the option did avoid unnecessary downscaling, it also
added a bug when disabled: the borders are no longer taken into
account when the size is too big for the desktop. Most users don't
notice and are unaffected as it's enabled by default.
Shortly later (981048e0) the core issue is fixed, and now the client
area is correctly set to WxH instead of the window (and together with
the three following commits which center the video, adds a new bug
where the window title can be outside the display - addressed next).
However, fit-border remained, now without any effect, except that it
still has the same bug when disabled and the window is too big.
Later code changes and refactoring preserved this issue with great
attention to details, and it remained in identical form until now.
Simply rip out fit-border.
See #8137 for justification.
This is not ideal, because a large cache results in a lot of `strcmp`
invocations for every single shader invocation. But it's way better than
resulting in a lot of shader recompilations for every single shader
invocation.
The only reason I don't want to uncap it altogether is because there are
conceivable edge cases in which users load dynamically generated shaders
with updated parameters (indeed, I've seen IRC discussions to this
effect), and in this case, we don't want to grow the cache infinitely as
a result of something like a floating point parameter being continuously
updated. (Never mind that this *would* actually trigger worst case
behavior for the `strcmp`, since the updated float constant is likely to
be near the bottom of the shader body)
Whatever. vo_placebo will liberate us all in the end.
The wayland code uses a heuristic to determine whether or not the mpv
window is hidden since the xdg-shell protocol does not provide a way for
a client to directly know this. We don't render with the frame callback
function for various, complicated reasons but the tl;dr is that it
doesn't work well with mpv's core (maybe an essay should be written on
this one day).
Currently, the aforementioned heuristic considers a window hidden if we
miss more frames in a row than the display's current refresh rate
(completely arbitrary number). However, the wayland protocol does allow
for the display's refresh rate to be 0 in certain cases (like a virtual
output). This completely wrecks the heuristic and basically causes only
every other frame to be rendered (real world example: nested sway
sessions).
Instead let's slightly redesign this mechanism to be a little smarter.
For coming up with the vblank time (to predict when to timeout on the
wait function), instead use the vsync interval calculated using
presentation time. That is the most accurate measure available. If that
number is not available/invalid, then we try to use the vsync interval
predicted by the presentation event.
If we still don't have that (i.e. no presentation time supported by the
compositor), we can instead use the old way of using the expected vsync
interval from the display's reported refresh rate. If somehow we still
do not have a usable number, then just give up and makeup shit. Note
that at this point we could technically ask the vo for the estimated
vsync jitter, but that would involve locking/unlocking vo which sounds
horrifying. Ideally, you never reach here.
See https://github.com/swaywm/wlroots/issues/2566 for the actual target
of this fix. wlroots uses presentation time so in practice we are mostly
just using that calculated vsync interval number.
Seems to be a slight corner case with the audio API rewrite. When
switching from one file to another one, the volume of the ao would never
be set because the audio chain's ao wasn't set. This caused a bug with
the reset-set-on-file option. The volume/property would be correctly set
internally, but the gain was not actually set when the file switched.
Fixes#8287.
The wayland output listener can update whenever something about the
output changes (resolution, scale). Currently, the mpv VO updates
correctly when the refresh rate changes, but changes of both scale and
resolution were not considered. This causes a bug in certain cases like
the mouse surface not being shown at certain scale factors due to the
cursor scale not being updated correctly. Also autofit type options
would not update if the resolution changes.
To fix this, we must always reset the window geometry and wl scaling
whenever the output event occurs on wl->current_output. There is no way
to know precisely what changed from the previous state, so all of the
parameters must be reset and then resized.
As an aside, this apparently doesn't fix all cursor problem as there's
apparently a bug in libwayland-cursor(*). It's still something we should
be doing regardless.
*: https://gitlab.freedesktop.org/wayland/wayland/-/issues/194
So apparently this property had existed since 2019. Internally, it's
used as a part of the console.lua script for scaling. Yours truly
somehow didn't bat an eye at the fact that the text in the console was
super small (made worse by the fact that xwayland does scale) and just
ignored it for all this time. Oh well.
To report dpi changes to mpv's core, we need to use VO_EVENT_DPI in a
couple of places. One place is, of course, the surface listener if the
scale value reported by the wayland server changes. The other place is
in the very first reconfig since mpv's core will not find the correct
scale value until we actually get a wl_output from the wayland server.
This fixes audio encoding crashing under ASan.
When extended_data != data, FFmpeg copies more pointers from
extended_data (= the number of channels) than there really
are for non-planar formats (= exactly 1), but that's not our fault.
Regardless, this commit makes it work in all common cases.
The args struct is reused to attempt opening an URL with
different stream layers, overwriting args->url not only
breaks this but also causes the freed buffer to be used again.
Before this commit, the user could specify a printf format string
which wasn't verified, and could result in:
- Undefined behavior due to missing or non-matching arguments.
- Buffer overflow due to untested result length.
The offending code was added at commit 103a9609 (2002, mplayer svn):
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@4566 b3059339-0415-0410-9bf9-f77b7e298cf2
It moved around but was not modified meaningfully until now.
Now we reject all conversion specifiers at the format except %%
and a simple subset of the valid specifiers. Also, we now use
snprintf to avoid buffer overflow.
The format string is provided by the user as part of mf:// URI.
Report and initial patch by Stefan Schiller.
Patch reviewed by @jeeb, @sfan5, Stefan Schiller.
When mpv attempts to play a video that is, on average, 60 FPS on a
display that is not exactly 60.00 Hz, two options try to fight each
other: `video-sync-max-video-change` and `interpolation-threshold`.
Normally, container FPS in something such as an .mp4 or a .mkv is
precise enough such that the video can be retimed exactly to the display
Hz and interpolation is not activated.
In the case of something like certain live streaming videos or other scenario
where container FPS is not known, the default option of 0.0001 for
`interpolation-threshold` is extremely low, and while
`video-sync-max-video-change` retimes the video to what it approximately
knows as the "real" FPS, this may or may not be outside of
`interpolation-threshold`'s logic at any given time, which causes
interpolation to be frequently flipped on and off giving an appearance
of stuttering or repeated frames that is oftern quite jarring and makes
a video unwatchable.
This commit changes the default of `interpolation-threshold` to 0.01,
which is the same value as `video-sync-max-video-change`, and guarantees
that if the user accepts a video being retimed to match the display,
they do not additionally have to worry about a much more
precise interpolation threshold randomly flipping on or off. No internal
logic is changed so setting `interpolation-threshold` to -1 will still
disable this logic entirely and always enable interpolation.
The documentation has been updated to reflect this change and give
context to the user for which scenarios they might want to disable
`interpolation-threshold` logic or change it to a smaller value.
Today, validation is only possible for string type options. But there's
no particular reason why it needs to be restricted in this way, and
there are potential uses, to allow other options to be validated
without forcing the option to have to reimplement parsing from
scratch.
The first part, simply making the validation function an explicit
field instead of overloading priv is simple enough. But if we only do
that, then the validation function still needs to deal with the raw
pre-parsed string. Instead, we want to allow the value to be parsed
before it is validated. That in turn leads to us having validator
functions that should be type aware. Unfortunately, that means we need
to keep the explicit macro like OPT_STRING_VALIDATE() as a way to
enforce the correct typing of the function. Otherwise, we'd have to
have the validator take a void * and hope the implementation can cast
it correctly.
For help, we don't have this problem, as help doesn't look at the
value.
Then, we turn validators that are really help generators into explicit
help functions and where a validator is help + validation, we split
them into two parts.
I have, however, left functions that need to query information for both
help and validation as single functions to avoid code duplication.
In this change, I have not added an other OPT_FOO_VALIDATE() macros as
they are not needed, but I will add some in a separate change to
illustrate the pattern.
This fixes an issue where dithering was effectively broken on libplacebo
versions >= 103 because the dither texture was being sampled with
edge-clamped rather than repeating semantics.
Changes:
- code refactored;
- mixer options removed;
- new mpv sound API used;
- add sound devices detect (mpv --audio-device=help will show all available devices);
- only OSSv4 supported now;
Tested on FreeBSD 12.2 amd64.
There was a simple oversight that meant audio outputs were
uninitialized during an encoding, which is not allowed, the encoding
would stop with numerous errors.
I added a single line to prevent the call of uninit_audio_out in
reinit_audio_chain if the encoder was active and this appears to have
fixed the problem without breaking anything else.
Fixes#8568
Gopher over TLS (gophers) is a community-adopted protocol and has recently
been merged in:
- curl (a1f06f32b8603427535fc21183a84ce92a9b96f7)
- ffmpeg (51367267c8a9f1a840f5e810f8c788e6e03712a5)
Now loading cover art through mp_add_external_file requires an
additional argument to be set to true. This way not all video-add
commands end up being marked as cover art when they move through
mp_add_external_file, as originally changed in 55d7f9ded1 .
Additionally, this lets us clean up some logic that would otherwise be
duplicated between open_external_files and autoload_external_files, if
the logic had been kept split from mp_add_external_file.
Fixes#8358
This makes the behavior of all control messages consistent,
fixing an inconsistency that has been with us since
4d8266c739 - which is the initial
rework of the polyaudio AO into the pulseaudio AO.
Muting the stream also directly triggers an update to the OSD.
When not waiting for the command completion this read of the mute
property may read the old state. A stale read.
Note that this somehow was not triggered on native Pulseaudio, but it is
an issue on Pipewire.
See https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/868
Some tracks happen to lack bitrate information (ie. no tbr value).
In that case, just ignore the track while computing the max bitrate.
For an example, this is a stream in which all audio tracks
have no bitrate: https://www.raiplay.it/dirette/rai1
The wayland code takes mouse dragging into account in order to trigger a
client-side request for a window move or window resize. According to the
xdg-shell spec*, "[t]he server may ignore move[/resize] requests
depending on the state of the surface (e.g. fullscreen or maximized)".
Since it is not actually a hard requirement, that means the compositor
could actually respond to a clientside move/resize request even if the
mpv window was fullscreen. For example, it was pointed out that in sway,
if mpv is a floating window, you could drag it around off screen even
though the window is fullscreen.
This kind of behavior does not really have any practical use. A user can
should pan a video if he/she wishes to move its orientation while
fullscreen (or maximized for that manner). Naturally, a maximized or
fullscreened window should never be manually resized (every compositor
likely ignores this anyway). The fix is to simply just not trigger the
smecial mouse dragging case if the wayland surface is fullscreened or
maximized.
*:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/stable/xdg-shell/xdg-shell.xml
the fullscreen style mask is not supported on macOS 11 anymore outside
of the native fullscreen animation. this can lead to a none working fs
or in the worst case a crash.
to fix this we will simulate a fullscreen window with a borderless
window with the size of the whole screen, though only on macOS 11.
Fixes#8490
It's about a year old, and packaged pretty much everywhere that bothers
to package libplacebo at all. Older versions are only a thing on LTS,
which will probably also use older mpv so it works out.
Starting with v2.72.0, libplacebo validates all of its parameters
internally and turns them into function failures. Doing it twice is
awfully redundant, so we can drop the parameter validation.
Also allows us to drop some preprocessor macros.
if log-file and really-quiet options were used together it could lead to
a completely empty log-file. this is unexpected because we need the
log-file option to work in all cases and produces at least a log of
verbosity -v -v. this is a regression of commit
a600d152d2
move the really quiet check back up, so it's set before the evaluation
of the actual log level, where check for log file, terminal, etc take
place.
the slider on the touch bar was always updated when any of the related
properties changed their value. this is partially dependent on the
refresh rate of the video, in the case of time-pos. too many updates to
touch bar impact the render performance.
to prevent this we only update the slider when necessary, when the touch
bar or the touch bar item is visible. the touch bar items only need a
granularity of seconds without any decimals, but the time-pos property
provides a granularity with decimals. we floor those values and only
update the touch bar items when we have at least a 1 second difference.
we also check for the visibility of the touch bar and its items.
Fixes#8477
the NSSliderTouchBarItem seem to be broken in a way it can't be fixed.
it has constraints set by default that can't be removed and lead to
warnings and render performance regressions.
instead of using the preconfigured NSSliderTouchBarItem we use a custom
touch bar item (NSCustomTouchBarItem) with a slider, which essential are
the same. this way we can configure our constraints ourselves, which
aren't needed in the first place.
Fixes: #7047
initialising UnsafeMutableRawPointer the way we did won't free those
pointers and we get dangling pointers. explicitly define a scope those
pointers are alive and auto freed.
this drops support for swift <4.1 and with this support for xcode <=9.2.
this was the last setup that is officially working on macOS 10.12.
our old legacy build macOS 10.12 + xcode 9.2 is replaced by macOS 10.13
+ xcode 9.4.1 with swift 4.1. the macOS 10.13 + xcode 10.1 VM is
replaced by the latest macOS 10.14 + xcode 11.3.1 VM. this is the oldest
version officially supported by Apple.
this is in preparations for the following commit.
the pointer used to initialise the respective structs is only guaranteed
to be alive within this constructor. the struct itself is used later and
the data it points to, is not guaranteed to be the same.
to fix this we define a scope that pointer is definitely valid and use
it within this scope. a helper function was added to get the pointers
for several data at once. otherwise we would need to nest
withUnsafeMutableBytes several times, which would make it hard to read.
Apple has decided that Mac OS X is now named macOS for the time
being. For consistency, it makes sense to use the same name for the
operating system in all places where it occurs. This commit renames
OS X to macOS in the documentation in places where it was otherwise
still using the old name.
Where X is any ASCII char chosen by the user. An argument is only
interpreted as custom-quoted if it starts with '!' and the line doesn't
end right after it. Custom quotes don't interpret backslash-escape.
This change only affects command arguments which mpv parses (not array
commands), and not tokens before the arguments (where applicable - key
name, input section, command prefixes, command name).
This enables us to get more of a message than just "Download failed.",
possibly helping people help themselves to get the download going.
References #8417
Should result in: "You manually enabled the feature 'lua', but the
autodetection check failed."
The moved bit of code was probably intended to do that all along, but it
was running too late, so the code that actually checked for Lua didn't
know it was explicitly asked for and quietly disabled it if not found.
Oversight when the modifier checking was split out to a separate
function. Instead of immediately returning on a match, be sure to loop
through all modifiers and catch every single one that is pressed before
we return them.
currently we use the whole screen rectangle to calculate the window
geometry. this doesn't take the menu bar or the Dock into account.
by default use the visible screen rectangle instead. this is also a
change in behaviour, since the window can't be placed outside of this
rectangle anymore. also add an option to change to the old behaviour,
because it can still be useful in certain cases, like placing the window
directly underneath the menu bar when used a desktop background.
Fixes#8272
when exiting fullscreen we set the window frame to a aspect fit frame of
the fullscreen frame to prevent aspect ration problems when animating.
though that intermediate frame was set too early and before the system
knew we already exited the fullscreen. because of that the frame we set
could not be properly set and its origin was defaulted to the bottom
left corner for exactly one display refresh and only after that the
wanted frame was set. this led to a (dark) grey area on the right or
top depending on the aspect ratio difference of the screen and video.
to prevent this set the intermediate frame in the animation group to
make it sync with the system's fullscreen behaviour.
Fixes#8371
Originally when presentation time was implemented, the frame callback
and presentation feedback functions were called in each rendering api's
separate backend (egl and vulkan). This meant that their respective
structs were basically copy and pasted across both files. Plus later
vo_wlshm started using frame callbacks too. Things got refactored a few
times and it turns out there's actually no need to have these things
separate anymore. The frame callback can just be initialized in
vo_wayland_init and then everything else will follow from there. Just
move all of this code to wayland_common and get rid of the duplication.
Sidenote: This means that vo_wlshm can actually receive presentation
feedback now. It's really simple to do so might as well. See the next
commit.
If the window is maximized, we can't change the size immediately. In
that case, we set a bool and wait for the state to change before
triggering the resize.
Additionally, do some cleanups in the resize/autofitting code to make
sure we don't do any wasteful VO_EVENT_RESIZE calls. Note that if
set_geometry is called, we must always perform a resize.
--alpha=yes doesn't affect only transparent videos and images, but also
the background. I spent time researching how to implement transparent
backgrounds and had no idea that they already worked at least on
Wayland.
Background transparency will work on X11 when
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2376 is
merged. It doesn't work on Windows. No idea about macOS. Either way,
this paragraph already says that it only works on certain environments
twice.
References #6590
With the current wording, I thought that playlist-prefetch doesn't
prefetch the next url within a playlist of m3u8 urls, but it makes a big
difference, and I would have enabled it earlier if it wasn't for this
paragraph.
This makes it clear that you can prefetch any file, but that it won't
prefill the cache with the video data. This is true for any video,
there's nothing unique about HLS streams in the behavior of this option.
There's a bit of a catch-22 in the wayland backend. mpv needs to know
several things about the wl_output the surface is on (geometry, scale,
etc.) for lots of its options. You still have to render something
somewhere before you can know what wl_output the surface is actually on.
So this means that when initializing the player, it is entirely possible
to calculate initial parameters using the wrong wl_output. The surface
listener is what will eventually correct this and pick the correct
output. However not everything was technically working correctly in a
multi-output setup.
The first rule here is to rework find_output so that it returns a
vo_wayland_output instead of internally setting wl->current_output. The
reason is simply because the output found here is not guaranteed to be
the output the surface is actually on. Note that for initialization of
the player, we must set the output returned from this function as the
wl->current_output even if it is not technically correct. The surface
listener will fix it later.
vo_wayland_reconfig has to confusingly serve two roles. It must ensure
some wayland-related things are configured as well as setup things for
mpv's vo. The various functions are shuffled around and some things are
removed here which has subtle implications. For instance, there's no
reason to always set the buffer scale. It only needs to be done once
(when the wl->current_output is being created). A roundtrip needs to be
done once after a wl_surface_commit to ensure there are no configuration
errors.
surface_handle_enter is now handles two different things: scaling as
well as mpv's autofit/geometry options. When a surface enters a new
output, the new scaling value is applied to all of the geometry-related
structs (previously, this wasn't done). This ensures, in a multi-monitor
case with mixed scale values, the surface is rescaled correctly to the
actual output it is on if the initial selection of wl->current_output is
incorrect.
Additionally, autofit/geometry values are recalculated if they exist.
This means that dragging a surface across different outputs will autofit
correctly to the new output and not always be "stuck" on the old one.
A very astute observer may notice that set_buffer_scale isn't set when
the surface enters a new output. The API doesn't really indicate this,
but a WAYLAND_DEBUG log reveals that the compositor (well at least
sway/wlroots anyway) magically sets this for you. That's quite fortunate
because setting in the surface handler caused all sorts of problems.
in the original commit, that removed the conditional clearing, an
incorrect assumption was made that clearing "should be practically free"
and can be done always. though, at least on macOS + intel this can have
a performance impact of up to 50% increased usage. it might have an
impact on other platforms and setups as well, but this is unconfirmed.
the reason for removing the conditional clearing was to partially work
around a driver bug on very specific setups, X11 with amdgpu and OpenGL,
to clear garbled frames on start. though it still has issues with
garbled frames in other situation like fullscreening. there is also an
open bug report on the mesa bug tracker about this. setting the
radeonsi_zerovram flag works around all of those issues.
since the flag works around all these issues and the original fix
doesn't work completely we revert it and keep our optimisation.
Fixes#8273
the screen-name and fs-screen-name option allow for specifying screens
based on their name. this is the name of the NSScreen and also reported
by the VOCTRL_GET_DISPLAY_NAMES event. the old screen and fs-screen
options by id, respectively, are preferred over these new ones.
In wayland, setting the surface on a specific monitor only works in
fullscreen so only --fs-screen-name can be implemented. Like with x11,
we prefer --fs-screen over --fs-screen-name if it is set. This may be
more useful than setting by ids because there's no guaranteed order in
which screens are added in wayland. In wayland, the name used here is
the model name detected by the output_listener.
The --screen-name and --fs-screen-name options allow for specifying
screens based on their name. For x11, this is the display name reported
by xrandr. --screen-name and --fs-screen-name mimic the --screen and
--fs-screen options respectively. If --screen is set, then --screen-name
will always do nothing. Likewise, --fs-screen-name does nothing if
--fs-screen is set.
Simple groundwork for adding a couple of user options that allow
selecting the screen with a string name. The next two commits implements
these options for xorg and wayland.
While this says that _ is replaced with -, it doesn't say that you HAVE
to use _. This isn't obvious and I didn't understand why my profile
conditions with - weren't working at first. Seeing as the person who
reproted #8324 ran into this as well, this may be worth clarifying.
Zlib has had a .pc file since 2010, and the default search paths we use
here can break the build on some distros (notably openSUSE Tumbleweed,
which our Travis builds use). Just check pkg-config instead.
Our canvas size calculation is affected by few factors, and rounded
down more than once - which can result in 0 width or (more typically)
height - e.g. when terminal height is one row.
If the width or height are 0 then all bets are off, so simply skip
the setups and rendering on this case. We can still recover
automatically if the terminal is resized to become bigger.
The obvious approach would be SIGWINCH, however, integrating it would
be tricky, so instead we simply poll the size on draw_frame.
This means the image won't resize automatically when still - e.g.
cover art or when paused, though it would re-fit on OSD changes.
This is commonly used by UHD/HDR sources, and mpv hilariously ignores it
up until now, just blindly mapping it to MP_CHROMA_AUTO without even so
much as a warning message.
It would be justified to add all the other chroma locations as well, but
I'm lazy and just wanted to quickly fix this bug.
homebrew is removing 10.13 support and some of the dependencies start
building rom source now. we will just pin the last working homebrew
version, similar to the 10.12 build
The reference is allocated at reconfig and happens at least once (and
leaked at least once), but can also be called more, e.g. on zoom or
pan-and-scan changes.
The reference is allocated at reconfig (and leaked at least once), but
could theoretically be called more than once by mpv, or in the future
when the tct code is enhanced to hande e.g. pan-and-scan changes.
testdither was being created irrespective of whether
opt_fixedpal is set or not. In case of opt_fixedpal=1,
testdither is not used in the `prepare_static_palette`
code. Hence only initialize it when opt_fixedpal is 0.
In sixel_dither_initialize, replace 3 with the libsixel
SIXEL_PIXELFORMAT_RGB888. Also in sixel_encode, the 4th
parameter is supposed to be depth, which also happens
to be the value of PIXELFORMAT_RGB888, so replacing that
constant with the depth value.
Since 0.33.0 mpv does not support python2. This commit removes
python2 support from the file completely with the following
changes:
- __future__ import of print_function is python2 only
- unicode literals are legacy in python3
- 'sys.version_info.major < 3' check is redundant
In 0.33.0 python2 support has been removed from mpv's build system. This
commit removes python2 compatibility code from bootstrap.py with the
following changes:
- __future__ import for print_function is not needed
- urllib2 is python2 only
For two reasons:
1. It was counter intuitive that there's an "auto" value (which is
actually a libsixel value and not an mpv one), but it's not the
default value - our default was Atkinson.
2. "auto" provides better dithering than Atkinson with libsixel, which
is especially noticeable with smooth gradients - where Atkinson has
visible banding.
In libsixel 1.8.2 the "auto" value maps to Atkinson if the output
palette has up to 16 colors, or to Floyd-Steinberg otherwise (e.g.
using fixed palette with 256 colors chooses Floyd-Steinberg).
The issue was that we only uploaded the palette to the terminal when it
changed (once on init with fixed palette, every frame with dynamic
palette with trheshold=-1, only on scene change with threshold >= 0).
Now we upload it on every frame, and it seems to fix the mlterm image
corruption both with fixed palette and also with dynamic palette with
threshold (i.e. at frames which did not upload a palette).
It's not entirely clear why it's required with mlterm.
It would seem that the palette which libsixel uses with fixed palette
matches the built in default palette in xterm, but not in mlterm.
With dynamic palette we can guess that mlterm resets the palette after a
sixel image, but that's not confirmed.
Uploading the palette on every frame doesn't seem to slow down xterm
when using fixed palette - not clear yet why uploading a different
palette (when using fixedpalette=no) slows it down while same palette
on every frame doesn't.
In mlterm there's no slowdown either way - and now also no corruption.
By default we still clear the screen, but now it's possible to leave the
last sixel image on screen.
Allows mpv to be used as img2sixel of sorts, but with our auto-fit and
various mpv scaling/filters etc.
When mpv is in the background because it was started with
`mpv foo.mp3 &`, or the user did ctrl+z bg, and is then brought to the
foreground with fg, it buffers input until you press enter. This makes
it accept input almost immediately. Having a short interval isn't
important, since input is buffered until the next loop iteration.
Closes#8120.
Loaded 100 of 609 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