the old check stopped at the first occurrence of a vulkan loader path.
though it's possible different vulkan loaders are installed in different
paths, leading to not found vulkan loaders.
to prevent this, also check if the needed vulkan loader is actually
installed to that path.
specific case is when installing MoltenVK and KosmicKrisp at the same
time. the former is installed in the homebrew prefix under etc/ the
latter under share/. the latter wasn't found previous, since the former
was found first.
The feature test macro is nonstandard and not available on older GCC
version, which causes build failure despite the compiler does support
__builtin_mul_overflow.
Since there are no fallback when __builtin_mul_overflow is not
available, there is no need to check, so simply remove it.
If __builtin_mul_overflow is not supported compilation will still fail
just like currently.
Instead of using zero initialized value. Otherwise an early init failure
calls close(0), a descriptor we don't own, breaking whatever else
happens to hold it.
This is bit defensive, but I want to init those just after allocation,
so we don't have to trace whether they are initalized correctly or not.
Instead of using zero initialized value. Otherwise an early init failure
calls close(0), a descriptor we don't own, breaking whatever else
happens to hold it.
Also add missing check before close() call.
Instead of using zero initialized value. Otherwise an early init failure
calls close(0), a descriptor we don't own, breaking whatever else
happens to hold it.
This is bit defensive, but I want to init those just after allocation,
so we don't have to trace whether they are initalized correctly or not.
The software renderer backend is not capable of using any of the VO
capabilities set globally by vo_libmpv. This can lead to assertion
errors when trying to render a video with 90 degree rotation metadata.
Instead use the ctx->renderer->driver_caps value so the source frame
doesn't have its params rotated when it's not desired.
An `--audio-file` could be sourced from a stream. A stream could be
using timestamps that match unix time in their segments. In that
case, setting `audio-delay` will lead to a big unexpected A/V desync
due to the limited precision of floats.
This commit changes `--audio-delay` (and --sub-delay while at it) to be
stored in `double` instead of `float`.
`audio_delay` was already up-casted to `double` wherever it was
evaluated. Same for `sub-delay`, except its own value was getting
adjusted based on `double` values in one place (bad!):
player/command.c:6297
mpctx->opts->subs_shared->sub_delay[track_ind] -= a[0] - refpts;
A showcase:
mkfifo /tmp/mpv
date=$(date +'%s')
Before:
mpv --input-ipc-server=/tmp/mpv -
echo 'print-text '"${date}" | socat - /tmp/mpv # 1782890841
echo 'set audio-delay '"${date}" | socat - /tmp/mpv
echo 'set sub-delay '"${date}" | socat - /tmp/mpv
echo 'print-text ${=audio-delay}' | socat - /tmp/mpv # 1782890880.000000
echo 'print-text ${=sub-delay}' | socat - /tmp/mpv # 1782890880.000000
After:
mpv --input-ipc-server=/tmp/mpv -
echo 'print-text '"${date}" | socat - /tmp/mpv # 1782890841
echo 'set audio-delay '"${date}" | socat - /tmp/mpv
echo 'set sub-delay '"${date}" | socat - /tmp/mpv
echo 'print-text ${=audio-delay}' | socat - /tmp/mpv # 1782890841.000000
echo 'print-text ${=sub-delay}' | socat - /tmp/mpv # 1782890841.000000
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
Implement `lavfi-tempo` audio filter, which uses `atempo` or `ascale`
form libavfilter for setting the tempo.
Users (myself included) seem to be always looking for alternative tempo
scalers to try, and this provides a faster implementation (or two), and
may prove useful beyond performance/speed.
`atempo` is picked as a default, and as a fall-back if `ascale` is not
available.
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
The XDG Base Directory specification says “All paths set in these
environment variables must be absolute. If an implementation encounters
a relative path in any of these variables it should consider the path
invalid and ignore it.”
In the 2020s, now known as "the twilight years of modern
civilization", Silicon Valley's two most morbidly obese failsons
finally found their niche: a product that lets complete imbeciles
pretend to be software developers. This was, at least for a
while, a smash hit. Hordes of claudecucked vibechuds began
spamming free software projects with bogus "security bugs" and
associated even worse fixes, both of which they did not know how
to reason about, and definitely did not care to learn how to
reason about. The entire exercise, after all, was to get one's
name into the list of contributors, to get ahead in a highly
competitive job market of economies with equally torturous
education systems.
To the disturbingly moist-looking tech oligarchs recording
Goldman Sachs jerk-off instructons on their podcasts, this was a
profound shift in software development. Now, they no longer had
to pay 6 figures to some idiot who doesn't know how to program so
chooses React, and instead they can pay 6 figures to some
application that doesn't know how to program so chooses React.
For everyone else, it just added to the torment that is life in a
modern globalised service economy, where the fruits of their
labour are siphoned off and directed towards building ever
grander and more opulent paedophile island resorts.
But back to the code. Someone submitted a slop issue about how
there's UB if you run an input command with bogus parameters.
This is hardly a bug, since the commands are trusted, so the fix
is "don't do dumb shit". However, contextless vibechuddies saw
this as an opportunity to fire up their deeply subsidized
planet-burners and shit out some code they had no idea about what
it did.
LLMs, failing to have any real reasoning, tried twice, and failed
twice, to find the real """fix""" here. #18144 decided that
another condition needed to be added to the logical OR, whereas
the subsequent #18211 instead wanted to do an explicit cast to
size_t for no fucking reason. Funnily enough, the unsignedness of
size_t doesn't cause any problems here, because of the earlier
check to make sure `w` is positive.
Both of them missed that if `foo < bar * 4` overflows `bar`, you
can just check for `foo / 4 < bar`, which is an efficient
division as 4 is a power of 2, and the integer division here does
not lead to any problems because the check is a range check.
Do that, just to stop these stupid fucking PRs from popping up,
and deny these dumb shitheads the satisfaction of getting their
name into the contributor stats.
Closes#18128.
This joins Dolby Vision EL track with base one. libbluray current (as of
1.4.1) doesn't even expose this info, it will be available in next
version, but it is less code to ask lavf for this info in fact.
Don't try to select dependent track as main and feedback to base track.
To avoid situations where tracks are deselected only to select the same
group again.
This filter only converts SDR to HDR, so disable it if we have already
HDR on input. Note that it also seems to be disabled if HDR is disabled
in Windows, but we don't check that, because filters are not related to
display. Use conditional profile to enable this filter when needed, this
commit is only small convenience change.
Fixes: #17800
select.lua: `properties` is a large table containing 10k+ elements,
currently it's a global variable, which makes its memory cannot be
reclaimed by the GC after menu closing, so let's simply change it
to a local variable.
console.lua: `selectable_items` has the same issue, however, it cannot
be changed to a local variable because it is used by too many functions,
but at least we can reset it to nil when closing console.
This is mostly useful for SDR mode where previously we would output 203
nits, which on Windows is considered HDR, because reference white is
fixed at 80 nits in SDR mode. Which in turn causes additional
tone-mapping when using scRGB output.
Note that for SDR transfers this doesn't change the luminance, but
instead causes more aggressive tone-mapping, might not be fully
expected. But maybe we should follow system setting for better of for
worse.
Fixes: https://github.com/mpv-player/mpv/issues/17850
Not fully, because when ICC profile is embeded in content, libplacebo
will override our luminance, this will be fixed separately.