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.
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.
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.
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_.
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
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
The "screenshot window" command (ctrl+s by default) somehow broke video
colors with --gpu-api=vulkan --profile=gpu-hq when playback was paused.
I don't know the cause, but the rest of the code seems to imply
gl_video_reset_surfaces() needs to be called manually to flush some
caches, and it fixes the issue, so I assume there's no great mystery
here.
Commit 07b0c18 introduced some build breakages. Some breakages
were fixed on c1fc535 and a1adafe. This one is still remaining.
This commit fixes the following build error:
[153/521] Compiling video/out/vulkan/context_wayland.c
../video/out/vulkan/context_wayland.c:26:10: fatal error: video/out/wayland/presentation-time.h: No such file or directory
26 | #include "video/out/wayland/presentation-time.h"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Relevant to: #7802
Commit 6a13954d67 lowered the frequency of wakeups with this
condition. But it seems it sometimes the audio sync mode really should
get the wakeup before the frame is rendered. Normally, vo_thread is
supposed to perform this wakeup. Now the wakeup frequency is twice of
what should be needed - whatever, maybe it can be fixed properly once or
if timing is moved to the VO entirely in the future.
Fixes: #7777 (probably, untested)
When the window is mapped, some ICCCM WM_HINTS are set.
The input field is set to true and state is set to NormalState.
To quote the spec, "The input field is used to communicate to the window
manager the input focus model used by the client" and "[c]lients with
the Passive and Locally Active models should set the input flag to True".
mpv falls under the Passive Input model, since it expects keyboard input,
but only listens for key events on its single, top-level window instead
of subordinate windows (Locally Active) or the root window (Globally
Active).
From the end users prospective, all EWMH/ICCCM compliant WMs (especially
the minimalistic ones) will allow the user to focus mpv, which will allow
mpv to receive key events. If the input field is not set, WMs are
allowed to assume that mpv doesn't require focus.
I'm not sure why it only rendered OSD inside the video. Since OSD
rendering was always done on the X image (after software scaling and
color conversion), there was no technical reason for this. Maybe it was
because the code started out this way, and it was annoying to change it.
Possibly, one reason was that it didn't normally have to clear the black
bars in every frame (if video didn't cover the entire window).
Anyway, simply render OSD to the full window. This gets rid of some
rather weird stuff. It seems to look mostly like vo_wlshm now. The
uncovered regions are cleared every frame, which could probably be
avoided by being clever with the OSD renderer code, but this is where
I'm decidedly losing interest.
There was some mysterious code for aligning the image width to 8 pixels.
Replace that by attempting to align it to SIMD alignment (might matter
for libswscale, or if repack.c gets SIMD). Why are there apparently 4
different ways representing a pixel format (depth, VisualID, Visual,
XVisualInfo), but none of them seem to provide the XImage.bits_per_pixel
value (the actual size of a pixel, including padding)? Even after 33
years, X11 still seems overengineered, confusing, and inconvenient. So
just call X11 a heap of shit, and assume the worst case for alignment.
It may be completely useless, and I can't verify it as no known samples
or other known/accessible software using it, but why not?
Putting this together with he 422 code requires making it slightly more
generic. I'm still staying with a "huge" if tree instead of a table to
select the scanline worker callback, because it's actually small and not
huge (although it not being generic still feels slightly painful).
Now everything is super generic and super undebuggable. Some awkwardness
because the new metadata is basically a transposed version of the
mp_regular_imgfmt metadata, which was used for component info before.
The old code ignored many corner cases, and even wrote "blacker than
black" to YUV images. Use the new pixel format metadata and other
recently added gimmicky crap, which should make this more correct. Even
the almighty fuckup of a format AV_PIX_FMT_UYYVYY411 should work,
although that couldn't be tested for obvious reasons.
This doesn't work for "monow", but this is so extremely fringe while at
the same time painful that I just won't care. In theory, it could be
modeled as some sort of inverted gray colorspace or something.
Make sure to accept only native endian mpv formats. Previously, it
didn't check, and simply matched LE, because these are usually defined
before the BE formats.
red_mask etc. are defined as unsigned long, so use that instead of
hardcoding a 32 bit limit.
A repeat of the previous useless commits.
Pondered whether to use separate fields or just a flags integer for
color and component types; the latter won for now.
Functions like mp_imgfmt_get_component_type() are now discouraged, and
mp_imgfmt_desc.flags is back for defining all information. Some days ago
I felt like the opposite would be the better design. Fortunately, it
doesn't matter.
With this, I think all image format properties that mpv needs are
exhaustively defined all in one place.
Useless, but super generic! Actually may add support for other fringe
formats, however vo_x11 in itself is useless, so nothing won here. Also
I didn't bother with big endian support.
I guess I decided to stuff it all into mp_imgfmt_desc (the "old"
struct). This is probably a mistake. At first I was afraid that this
struct would get too fat (probably justified, and hereby happened), but
on the other hand mp_imgfmt_get_desc() (which builds the struct) calls
the former mp_imgfmt_get_layout(), and the separation doesn't make too
much sense anyway. Just merge them.
Still, try to keep out the extra info for packed YUV bullshit. I think
the result is OK, and there's as much information as there was before.
The test output changes a little. There's no independent bits[] array
anymore, so formats which did not previously have set this now show it.
(These formats are mpv-only and are still missing the metadata. To be
added later). Also, the output for the cursed packed formats changes.
Use the new pixfmt metadata to replace the format tables with weird
generic code.
As you can see, this removes the tables that essentially duplicate
information (which is baaaaaaaaaad), in exchange for code which is
probably more fragile and has less of a chance of being understood by
someone new to the code (which is probably even worse from a maintenance
and robustness point of view, but LALALA I CAN'T HEAR YOU).
There are some more formats which can be handled like this (RGB30 and
packed YUV I guess), maybe later.
Dudemanguy
Niklas Haas
wm4
Philip Langdale
der richter
sfan5
Stephen Salerno
Daniel Bermond
Arthur Williams