Sharing a process sure is hard in POSIX.
The rationale is that you'd have to handle EINTR on every single
blocking syscall. stream_file.c does not seem to handle it on read()
calls.
It appears that on most modern systems, this can happen only if you call
sigaction(), and incompetently forget to add SA_RESTART. signal()
usually adds it.
Add env and detach arguments. This means the command.c code must use the
"new" mp_subprocess2(). So also take this as an opportunity to clean up.
win32 support gets broken by it, because it never made the switch to the
newer function.
The new detach parameter makes the "run" command fully redundant, but I
guess we'll keep it for simplicity. But change its implementation to use
mp_subprocess2() (couldn't do this earlier, because win32).
Privately, I'm going to use the "env" argument to add a key binding that
starts a shell with a FILE environment variable set to the currently
playing file, so this is very useful to me.
Note: breaks windows, so for example youtube-dl on windows will not work
anymore. mp_subprocess2() has to be implemented. The old functions are
gone, and subprocess-win.c is not built anymore. It will probably work
on Cygwin.
Rather than after tone-mapping. This prevents overflow when the
pre-tonemapped signal contains inputs exceeding sig_peak. I also
realized that with this clipping in place, post-clipping no longer needs
to be done, so this isn't even particularly slower.
The only two exceptions to the rule are "clip" and "linear", which
relied on the post-clipping to do their tone mapping properly.
Fixes#7929
This normally gets printed by libplacebo itself when initializing the
context, but due to the way our code is structured (for convenience) we
don't have the log hook enabled by the time this function call is
relevant. So instead just print it manually as an easier work-around
than restructuring the code.
This probably makes it much faster (I wouldn't know, I didn't run any
benchmarks ). Seems to work as well (although I'm not sure, it's not
like I'd perform rigorous tests).
The scale_zimg test seems to mysteriously treat color in fully
transparent alpha differently, which makes no sense, and isn't visible
(but makes the test fail). I can't be bothered with investigating this
more. What do you do with failing tests? Correct, you disable them. Or
rather, you disable whatever appears to cause them to fail, which is the
threading in this case.
This change follows mostly the tile_example.cpp. The slice size uses a
minimum of 64, which was suggested by the zimg author. Some of this
commit is a bit inelegant and weird, such as recomputing the scale
factor for every slice, or the way slice_h is managed. Too lazy to make
this more elegant.
zimg git had a regressio around active_region (which is needed by the
slicing), which was fixed in commit 83071706b2e6bc634. Apparently, the
bug was never released, so just add a warning to the manpage.
The intention is to add slice-threading to the wrapper. For that
purpose, move all zimg related state to a new struct mp_zimg_state.
There is now an array of instances of this struct. The intention is to
have one instance for each thread. As of this commit, this is hardcoded
to 1 thread; the following commit extends this.
libass recently switched the default from 1 to 0 for compatibility
with ASS scripts that rely on the historical/VSFilter default of 0.
libass does attempt to detect and avoid breaking scripts that rely
on the historic libass-only default of 1, but it doesn't cover tracks
created directly through the API, so set the header explicitly.
Fixes https://github.com/mpv-player/mpv/issues/7900.
It turns out that the AMD driver doesn't bother to set the size
field in the descriptor for an exported VA surface. I guess they
assume the caller can always use lseek() and don't bother. So, we
need to use lseek() in these situations.
Modified-by: Niklas Haas <git@haasn.xyz>
Guarded this behind PL_API_VER >= 88 to prevent it from exploding on
older libplacebo versions, where vaapi support does not yet work
properly on AMD due to lack of DRM modifiers.
When get_state() corks the stream after an underrun happens
priv->playing is incorrectly reset to true, which can cause the
player to miss the underrun entirely. Stop resetting priv->playing
during corking (but not uncorking) to fix this.
The underflow callback introduced in d27ad96 can be called
when the buffer is still full, causing playback to never
resume afterwards since get_state() reports free_samples == 0.
Fix this by fully resetting on underrun, which flushes
the stream and ensures free buffer space.
fixes#7874
we properly set the unfs window size on live resize end. due to a race
condition in the fullscreen events, which is also a live resize, the
unfs window size is incorrectly set to a fullscreen size. this happens
when the end fs screen event triggers before the end of live resize one.
this just adds a second condition to not be un fullscreen when updating
the unfs window size.
Mess this into the --geometry option, because I like to be
irresponsible. I considered adding a separate option, but at least this
allows me to defer the question how the hell this should work as
property (geometry simply and inherently does not).
Tested on IceWM only. Option equality test and string output not tested.
Probably did not cause any practical problems, but it sure seems
unclean. sws_utils users might also rely on these fields being exactly
the same as the actual input/output. It's better to avoid this.
I'm tired of dealing with this frequent spawning of xdg-screensaver when
debugging and what not. xdg-screensaver was never a serious tool anyway,
it's more like some self-deprecating joke by FDO folks.
This will affect X11 on GNOME and other DEs. I'm singling out GNOME
though, because they are the ones actively sabotaging any sane
technical solutions and community cooperation.
I have been accused of taking it out on innocent GNOME users, while none
of this will reach GNOME developers. Of course that is not the
intention.
This can be used to make vo_libmpv render video to a memory buffer. It
only adds a new backend API that takes memory surfaces. All the render
API (such as frame rendering control and so on) is reused.
I'm not quite convinced of the usefulness of this, and until now I
always resisted providing something like this. It only seems to
facilitate inefficient implementation. But whatever.
Unfortunately, this duplicates the software rendering glue code yet
again (like it exists in vo_x11, vo_wlshm, vo_drm, and probably more).
But in theory, these could reuse this backend in the future, just like
vo_gpu could reuse the render_gl API.
Fixes: #7852
libplacebo exposes this feature already, because this particular type of
bug is unusually common in practice. Simply make use of it, by exposing
it as an option.
Could probably also bump the libplacebo minimum version to get rid of
the #if, but that would break debian oldoldstable or something.
Fixes#7867.
Apparently mpv supports loading config files from the same directory as
the mpv.exe. This is a fallback of some sort. It used the old_home
mechanism.
I want to add a warning if old_home exists, but that would always show
the warning on win32. Obviously we don't want that.
Add a separate exe_dir entry to deal with that.
Untested, but probably works.
XDG is stupid, so change back to the standard behavior. Unfortunately,
most users will now have the XDG one, so we will still need to load
this. (This is exactly the same problem as when XDG support was
introduced, just the other way around).
This should not affect any normal users. Hopefully I tested this well
enough; my intention is not to torment miserable XDG fans; they can keep
using their config dir if they want it.
This changes behavior in two cases:
- new users (now creates ~/.mpv/ instead of ~/.config/mpv/)
- users which have both directories
The latter case will behave subtly or obviously different, not sure.
Just fix your shit.
Extend the manpage with all the messy details, as far as I could reverse
engineer them from the code.
De-emphasize it, since a user should usually not use it. This _could_ be
used to make the cache seekable with --cache=no, but it's better and
more intuitive to use --cache=yes. As such, the only use of this is for
debugging. I'm not quite sure if this should be removed entirely, but I
still see some value in it (for example if you want the cache lookahead,
but you're using a stream where cache seeking is somehow broken).
Using mediump float on GLES causes problems with kernel resampling,
PQ HDR, and possibly others. The issues are fixed by using highp,
which is available when GL_FRAGMENT_PRECISION_HIGH is defined.
--dscale= and --*scale-window= (i.e. an empty string) are respectively
valid settings for their options (and, in fact, the defaults).
This fixes the bug that it was impossible to reset e.g. tscale-window
back to the default "unset" setting after setting it once.
Credit goes to @CounterPillow for locating the cause of this bug.
For testing in VMs I guess?
This features a very broken hack that probably works. Though I didn't
test the packed format case. Again, the mismatch is essentially due to
big endian byte addresses decreasing as bit addresses increase, so you
can't represent a bit position in a byte stream with a single address,
which the mpv metadata does.
OSD is broken because repack.c doesn't support big endian. You'll have
to live with it.
The recent changes to the image format metadata broke big endian, and
that was intentional. Some things are inherent to little endian (like
the idea to coalesce bit and byte offsets into a single bit offset), and
they don't be fixed. But some obvious things can be fixed, such as
marking LE vs. BE formats the right way around on BE hosts.
The metadata is formally still in LE, except that if the LE/BE flag
matches the host endian, the host endian can be used when accessing
packed formats with bit shifts, or when computing byte aligned component
byte offsets. The former may work because formats with LE/BE variants
use the same bit offsets after byte swapping, the latter may work
because little endian is the natural concept for addressing memory. But
it will "subtly" fail to do the right thing in some cases, and code
using this can't know, so have fun.
Many things are broken, but this makes e.g. vo_gpu mostly work.
My general opinion about BE computers is that you should get a better
computer, you can get one for free from any garbage dump.
IMGFMT_RGB30 was added first; FFmpeg added AV_PIX_FMT_X2RGB10 later.
This is exactly the same, so treat them as such. For some reason,
libswscale still seems to output incompatible data - not sure what this
is about, but I'm not going to debug it.
Instead of applying this only to "regular" formats, do it with all
formats.
For some reason, some repackers still have their own endian code. These
could probably be removed, but whatever.
This change attempts to fix detection of how endian swapping is to be
performed. Details can be found in the code comments.
It should not change anything, other than fixing handling of the
X2RGB10BE ffmpeg pixel format. This format was detected incorrectly, and
the component location metadata was discarded due to an internal
consistency check. With this commit, it is handled correctly. At first I
thought the X2RGB10BE ffmpeg pixdesc metadata was wrong, but it appears
to be correct. The problem with this format is that it's the first
packed RGB format that requires bit shift to access, and where the
endian word size is larger than the (rounded up) component size, all
while pixdesc would "require" you to perform 3 memory accesses (instead
of 1), and the code tries to reverse this.
It appears that trying to use the pixdesc metadata is much, much more
work than just duplicating it in a saner form. To be fair, most problems
are with big endian, and the mpv internal format does not care much
about endian _hosts_.
The pull mode APIs were previously required to have thread-safe
ao_controls. However, locks were added in b83bdd1 for parity with push
mode. This introduced deadlocks in ao_wasapi.
Instead, only lock ao_control for the push mode APIs.
fixes#7787
See also #7832, #7811. We'll wait for feedback to see if those should
also be closed.
For cases in which the requirements of the GPU API prevent directly
uploading a texture with a given stride, we need to fix the stride
manually in host memory. This incurs an extra memcpy, but there's not
much we can do about it. (Even in `ra_gl` land, the driver will just
hide this memcpy from the user)
Note: This code could be done better. It could only copy as many texels
as needed, and it could pick a stride that's a multiple of
`gpu->limits.align_tex_xfer_stride` for better performance. Patches
welcome (tm)
Fixes#7759
Implementation copy/pasted from:
https://code.videolan.org/videolan/libplacebo/-/commit/f793fc0480f
This brings mpv's tone mapping more in line with industry standard
practices, for a hopefully more consistent result across the board.
Note that we ignore the black point adjustment of the tone mapping
entirely. In theory we could revisit this, if we ever make black point
compensation part of the mpv rendering pipeline.
This standard says we should use a value of 203 nits instead of 100 for
mapping between SDR and HDR.
Code copied from https://code.videolan.org/videolan/libplacebo/-/commit/9d9164773
In particular, that commit also includes a test case to make sure the
implementation doesn't break roundtrips.
Relevant to #4248 and #7357.
glslang accepted this, perhaps erronneously, but mesa does not. It seems
to be incorrect. A caveat is that this means *all* SSBOs are now
coherent, but since we only use SSBOs for peak detection, that's a
non-issue. (And besides, marking something as coherent when we don't
perform any synchronization commands on it should be a no-op anyway)
Fixes#7823
Commit fcf0b80dc9 fixed this the first time. Commit 85576f31a9
"accidentally" removed this code again. The commit message justifying
the removal is correct, except it doesn't take other side-effects of the
state machine into account. I obviously didn't remember what exactly
this was about. So add a comment explaining it this time.
Just apply it again; the thing the latter commit fixed still works.
Fixes: #7819
AOs which use the "push" API must set this field now. Actually, this was
sort of always required, but happened to work anyway. The future
intention is to use device_buffer as the pre-buffer amount, which has to
be available right before audio playback is started. "Pull" AOs really
need this too conceptually, just that the API is underspecified.
From what I can see, only ao_null did not do this yet.
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.
since the title bar catches the mouse up and down events, the underlying
events view doesn't reset the isMoving state and no mouse movements are
signalled to the core. now we also reset the state in mouse up events
on the title bar.
Fixes#7807
