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.
Add a new function-like macro MP_SATURATE_MUL. It multiplies a * b and
stores it in pointer "result", but sets "result" to its type's maximum
value if it overflows. Evaluates to true if it saturated, otherwise
false.
Add a new MP_CKD_MUL macro which does a multiplication with overflow
checking, backed by either the C23 ckd_mul standard function, or the
GCC/Clang __builtin_mul_overflow otherwise.
Some sites throttle requests, but throttling can be avoided with many
small range requests. yt-dlp implements a "http_chunk_size" key in its
-J output to inform us of the ideal size.
https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21703 has just been merged,
which allows use the http_chunk_size to greatly speed up how fast
YouTube videos get loaded into the cache by mpv.
Should the FFmpeg that mpv is built against lack the request_size
AVOption, then this will silently not do anything new, so no version
checks are needed.
Specifying multiple_requests=1 like suggested in
https://github.com/mpv-player/mpv/issues/8655#issuecomment-3872689494
does not seem necessary.
Fixes#8655.
Supersedes #15612.
Co-authored-by: Nicolas F <ovdev@fratti.ch>
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.
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.
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.
Previously, device_buffer defaulted to 0 on pulse. This meant that
commit baa7b5c would always wait with a timeout of 0, leading to
high CPU usage for PulseAudio users.
By setting device_buffer to the number of samples per channel that
PulseAudio sets as its target, this commit fixes this behaviour.
Previously, EGL as provided by a pkg-config was checked for independently
in several places. The effect this had is that --disable-egl would not
actually disable EGL from the build, as this only affected the "egl" option
relied upon by egl-x11. wayland-gl and egl-drm did their own EGL checks.
By making wayland-gl and drm-egl depend on egl instead, we fix this
behaviour and can simplify egl-helpers a bit, as we can now simply
check whether egl or one of the other features providing some non-pc egl
is enabled, instead of checking every single thing that might be pulling
in egl.
Future work could make the "egl" option just be a catchall for any
EGL implementation, so that brcmegl and angle and Android can piggyback
on the egl option as well.
A minority of users have expressed a dislike of hats, calling them
"cancer [that] don't belong in software" describing the people who add
them as "shitty circlejerks" and "chucklefuck."
While I personally disagree with those opinions, it's probably easier
to let them have it their way. For that reason this adds the option
`greenandgrumpy` to the osc, which allows users to disable the hat.
Apparently there are two different options for controlling which
screen an mpv window goes onto: --fs-screen and --screen. The former
explicitly only controls which screen a fullscreened window goes onto,
but does not appear to actually care about this option at runtime for
X11, so pressing f will always fullscreen to the screen mpv is currently
on. This means the option is of questionable usefulness for starters.
Making it worse, if you use --screen=1 --fs, mpv will actually fullscreen
on screen 0, because --fs-screen isn't set. Instead of doing that, fall
back to whatever --screen is set to.
Some failures by youtube-dl prompt the user to submit a bug report.
If such a failure occurs, we can compare youtube-dl's version to the
current calendar date to see how old it is. We don't make this check
on every youtube-dl failure, as failing to extract an URL is quite
common, and waiting for a second blocking python interpreter startup
for every such case would be a bit unpleasant.
Here the assumption is made that any youtube-dl version older than
3 months is probably severely out of date. Users will be warned about
this.
We also output the trimmed stderr of youtube-dl with msg.error, as this
appeared to have been the behaviour of utils.subprocess without stderr
capturing. Since this uses mp.command_native now, we'll have to do this
ourselves where appropriate.
We default to EGL instead of GLX now, which means vdpau only works
if we explicitly specify that we want a GLX context, as vdpau lacks
interop for EGL.
Update the hwdec documentation to reflect this.
Concerns #6980.
The question came up on how a client would figure out where
screenshot-directory saved its screenshots if it contained
mpv-specific expansions. This command should remedy the situation
by providing a way for the client to ask mpv to do an expansion.
I assume (but cannot confirm) that VA-AP-API is in fact a typo, because
most if not all search engine results related to it are from mpv's manual
page.
By changing this to VA-API and clarifying that this requires VA-API support
on a system to use it, we can hopefully make it clear to unsuspecting
Windows users that this is not the filter they're looking for.
Concerns #6690.
Someone on IRC pointed out that the default stats bindings weren't
documented in the interactive control section of the manual, so
let's add them with a short mention and a reference to the STATS
section of the manual.
dlopen() and dlsym() can fail in various ways, and we can find out
how it failed by calling dlerror(). This is particularly useful if
you typo the filename of a script when explicitly passing it with
--script, and dlopen actually tells you that the file doesn't exist
instead of leading you down a rabbit hole of disassembling your
shared object file to figure out why the thing won't load.
Nicolas F