| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
On optional hook points, we store to a temp FBO and then read from it
again to complete any operations that may still be left (e.g.
sigmoidization after MAIN/LINEAR).
In theory this mechanism should be reworked to avoid the temporary FBO
until the next time we actually need one - and also skip redundant
passes if we the next thing we need *is* a FBO - but both are those are
tricky. Anyway, in the meantime, at least we can label the
(semi-)redundant passes that get generated when using user shaders.
|
|
|
|
|
|
|
| |
This just indicates a fixed linear coefficient to multiply into the
signal, similar to the old option --target-brightness (but the inverse
thereof). Good for testing purposes, which is why I added it. (This also
corresponds somewhat to what zimg does)
|
|
|
|
|
|
|
| |
It's now possible to request non-dumb mode as a user, even when not
using any non-dumb features. This change is mostly intended for testing,
so I can easily switch between dumb and non-dumb mode on default
settings. The default behavior is unaffected.
|
|
|
|
| |
This caused a single pixel shift to the top-left, introduced in e3e03d0f3.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This backend is selected if vaapi is available, but vaapi-over-EGL is
not. This causes various issues around the forced RGB conversion, which
is done with fixed, usually incorrect parameters.
It seems the existing auto probing check is too weak, and doesn't really
prevent it from getting loaded. Fix this by adding a flag to not ever
load this during auto probing.
I'm still not deleting it, because it's useful for testing on nvidia
machines.
See #4555.
|
|
|
|
|
|
|
| |
The current algorithm blew up when the color was negative, such as the
case when downscaling with dscale=mitchell or other algorithms that
introduce negative ringing. The simplest solution is to just slightly
change the calculation to force both parameters to be in-range.
|
|
|
|
|
| |
Instead of various ad-hoc ways to achieve the same thing. (The API was
added only later.)
|
|
|
|
|
|
|
|
|
| |
This is exposed so that bjin/mpv-prescalers can use textureGatherOffset
for performance.
Since there are now quite a lot of parameters where it isn't quite clear
why they're all defined, add a paragraph to the man page that explains
them a bit.
|
|
|
|
|
| |
In theory the max() should clamp it away anyway but I believe division
by zero is UB so just avoid it altogether.
|
|
|
|
|
|
|
| |
This helps prevent unnaturally, weirdly colorized blown out highlights
for direct images of the sunlit sky and other way-too-bright HDR
content. I was debating whether to set the default at 1.0 or 2.0, but
went with the more conservative option that preserves more detail/color.
|
|
|
|
|
|
|
|
| |
This logic doesn't really make sense. copy_img_tex already binds the
texture, so why would we bind it a second time? Furthermore, nothing
actually uses this return value. Must have been some left-over artifact
of a previous iteration of this function. Anyway, it's harmless, just
nonsensical. So remove it.
|
|
|
|
| |
The pass_read_fbo immediately below replaces it
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is more efficient on my machine (nvidia), but only when applied to
groups of exactly 4 texels. So we switch to the more efficient
textureGather for groups of 4. Some notes:
- textureGatherOffset seems to be faster than textureGather by a
non-negligible amount, but for some reason, textureOffset is still
slower than a straight-up texture
- textureGather* requires GLSL 400; and at least on nvidia, this
requires actually allocating a GL 4.0 context.
- the code in opengl/common.c that clamped the GLSL version to 330 is
deprecated, because the old user shader style has been removed
completely in the meantime
- To combat the growing complexity of the polar sampling code, we drop
the antiringing functionality from EWA shaders completely, since it
never really worked well for EWA to begin with. (Horrific artifacting)
|
|
|
|
|
| |
Seems like AV_HWACCEL_FLAG_IGNORE_LEVEL was introduced much earlier than
AVCodecContext.hwaccel_flags.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of PostMessage, use SendNotifyMessage from the SendMessage
family of functions to wake up the Win32 thread from the VO thread. When
a message is sent rather than posted between threads, it ends up in a
different queue which is processed before posted messages and can be
processed in more places. This prevents a playback glitch when clicking
on the titlebar, but not moving the window. With PostMessage-based
wakeups, VOCTRLs could be delayed for up to 500ms after the user clicks
on the titlebar, but with SendNotifyMessage, they still complete in
under a millisecond.
Also, instead of handling WM_USER, process the dispatch queue before
every message. This ensures the dispatch queue is processed as soon as
possible. WM_NULL is used to wake up the window procedure in case there
are no other messages being processed.
|
|
|
|
| |
Was used by old hwaccel implementations.
|
|
|
|
|
|
|
| |
This sets AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH, which some hwaccels
using the new generic API respect. These do profile selection in
libavcodec, so it can be controlled only with an external flag, instead
of in mpv code like it used to be done.
|
|
|
|
|
|
|
|
| |
They have been deprecated for a decade, yet you're forced to explicitly
deal with them at every step, or they will break your shit.
FFmpeg insists on keeping them, because libavfilter is too stupid to
deal with color ranges properly. Ridiculous.
|
|
|
|
|
|
|
|
|
|
| |
- change asserts to silent exits
- check all pointers before use
- move the p->pass initialization code to the right place
This should hopefully cut down on the amount of crashing by making the
code fundamentally more robust, while also fixing a concrete issue where
opengl-cb failed to initialize p->pass.
|
|
|
|
|
|
| |
This seems to reduce glitches when resizing a --wid program (or it could
be a placebo.) Since we don't need the WM_WINDOWPOSCHANGING handler in
--wid mode, it should be fine.
|
|
|
|
|
|
|
|
| |
This allows filter functions to be prematurely cut off once their
contributions start becoming insignificant. This effectively prevents
wasted GPU time sampling from parts of the function that are essentially
reduced to zero by the window function, providing anywhere from a 10% to
20% speedup. (5700μs -> 4700μs for me)
|
|
|
|
| |
Fucking bullshit.
|
| |
|
|
|
|
|
|
|
|
| |
Now it's sourced from the etc/ PNG files directly, instead of
preprocessing them with imagemagick.
Add some ad-hoc code to decode PNG files with libavcodec. At least we
can drop the zlib code in exchange.
|
|
|
|
|
|
| |
Actually contains some code fragments by Michael Niedermayer (command
line stuff, video equalizer), thus it can be LGPL only once the formal
requirement of mpv's core being LGPL is fulfilled.
|
|
|
|
| |
This shows up as (unknown pass) otherwise.
|
|
|
|
|
|
|
|
|
|
|
|
| |
2f41c4e8 exposed some other edge cases as well. Globally resetting the
pass info was not the right way to go about it, because we don't know in
advance what the frame type is going to be - at least not with the
current code structure. (In principle, we could separately indicate the
frame type and the pass type and then only reset it on the first
actual pass_describe call, but that's annoying as well)
Also fixes a latent issue where p->pass was never initialized, which
broke the MP_DBG debugging code in some cases.
|
|
|
|
|
| |
Omitting this call resulted in a crash when has_frame was false. But we
can just call it way earlier, because there's really no reason not to.
|
|
|
|
|
|
| |
Since all existing code does gl_video_upload immediately followed by
pass_render_frame, we can just move the upload into pass_render_frame
itself, which arguably makes more sense anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces `vo-performance` by `vo-passes`, bringing with it a number
of changes and improvements:
1. mpv users can now introspect the vo_opengl passes, which is something
that has been requested multiple times.
2. performance data is now measured per-pass, which helps both
development and debugging.
3. since adding more passes is cheap, we can now report information for
more passes (e.g. the blit pass, and the osd pass). Note: we also
switch to nanosecond scale, to be able to measure these passes
better.
4. `--user-shaders` authors can now describe their own passes, helping
users both identify which user shaders are active at any given time
as well as helping shader authors identify performance issues.
5. the timing data per pass is now exported as a full list of samples,
so projects like Argon-/mpv-stats can immediately read out all of the
samples and render a graph without having to manually poll this
option constantly.
Due to gl_timer's design being complicated (directly reading performance
data would block, so we delay the actual read-back until the next _start
command), it's vital not to conflate different passes that might be
doing different things from one frame to another. To accomplish this,
the actual timers are stored as part of the gl_shader_cache's sc_entry,
which makes them unique for that exact shader.
Starting and stopping the time measurement is easy to unify with the
gl_sc architecture, because the existing API already relies on a
"generate, render, reset" flow, so we can just put timer_start and
timer_stop in sc_generate and sc_reset, respectively.
The ugliest thing about this code is that due to the need to keep pass
information relatively stable in between frames, we need to distinguish
between "new" and "redrawn" frames, which bloats the code somewhat and
also feels hacky and vo_opengl-specific. (But then again, this entire
thing is vo_opengl-specific)
|
|
|
|
|
|
|
| |
For some braindead reason, Microsoft decided to prevent you from
dynamically loading system libraries. This makes portability harder.
And we're talking about portability between Microsoft OSes!
|
|
|
|
|
|
|
|
|
|
|
|
| |
This partially reverts the change from a longer time ago to always build
DXVA2 and D3D11VA together.
To make it simpler, we change the following:
- building with ANGLE headers is now required to build D3D hwaccels
- if DXVA2 is enabled, D3D11VA is still forcibly built
- the CLI vo_opengl ANGLE backend is now under --egl-angle-win32
This is done to reduce the dependency mess slightly.
|
| |
|
|
|
|
|
|
| |
Slightly cleaner, possibly slightly more correct. (The last case should
be dead code now. In general, we can't know the implied colorspace from
a AV_PIX_FMT, at least not if FFmpeg adds a new one.)
|
|
|
|
|
|
|
|
|
| |
It never worked. It relied on some obscure texture format to provide the
equivalent of GL_RG or GL_LUMINANCE_ALPHA, but no hardware seemed to
report support for it ever. No idea what's the correct way to do this.
On D3D11 it exists, of course.
(Actually I'd like to remove the whole VO.)
|
|
|
|
|
|
| |
Another legacy annoyance. The only place where packed YUV is still
important is slightly older Apple hardware or drivers, which require
it for efficient hardware decoding.
|
|
|
|
|
| |
These were weird due to their past, and often undefined or ill-defined.
Time to get rid of them.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of setting up a weird swizzle (which is linked to how the
internal renderer code works, rather than the generic format code), add
per-component mapping to gl_imgfmt_desc.
The renderer still computes the weird swizzle, but at least it's
confined to itself. Also, it appears the hwdec backends don't need this
anymore.
It's really nice that the messy init_format() goes away too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The changes to path list options is basically getting rid of the need to
pass multiple paths to a single option. Instead, you can use the option
multiple times. The old behavior can be used by using the -set suffix
with the option.
Change some options to path lists. For example --script is now append by
default, and if you use --script-set, you need to use ":"/";" as
separator instead of ",".
--sub-paths/--audio-file-paths is a deprecated alias now, and will break
if the user tries to pass multiple paths to it. I'm assuming that if
these are used, most users will pass only 1 path anyway.
--opengl-shaders has more compatibility handling, since it's probably
rather common that users pass multiple options to it.
Also document all that in the manpage.
I'll probably regret this later, as it somewhat increases the complexity
of the option parser, rather than increasing it.
|
|
|
|
| |
That format is worthless anyway.
|
|
|
|
|
|
|
|
|
|
|
| |
For vo_opengl and vo_direct3d, these are supported in a generic way.
For vf_vapoursynth, we could probably map its VSFormat struct in a
generic way, but for now do some bullshit.
vf_eq.c actually loses support for these formats. We could add generic
support too (anything that has 8 bit planes will work), but why bother.
The filter is deprecated anyway.
|
|
|
|
|
|
| |
These formats are supported in a generic way.
To get rid of IMGFMT_NV21, remove support from vo_direct3d.c completely.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add something that allows is to extract the component order from various
RGBA formats. In fact, also handle YUV, GBRP, and XYZ formats with this.
It introduces a new struct mp_regular_imgfmt, that hopefully will
eventually replace struct mp_imgfmt_desc. The latter is still needed by
a lot of code though, especially generic code. Also vo_opengl still uses
the old one, so this commit is sort of incomplete.
Due to its genericness, it's also possible that this commit introduces
rendering bugs, or accepts formats it shouldn't accept.
|
|
|
|
|
|
|
|
|
|
| |
While this is perfectly OK on Unix, it causes annoying valgrind
warnings, and might be otherwise confusing to others.
On Windows, the runtime can actually abort the process if this is
called.
push.c part taken from a patch by Pedro Pombeiro.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 3fb6380 was supposed to increase MAX_TEXTURE_HOOKS but instead
increased SHADER_MAX_HOOKS, since I forgot that they were separate (for
whatever reason).
To prevent this mistake from happening again, and to unify the location
in which user_shader-specific #defines are placed, get rid of the two
constants in opengl/video.c and move/reuse them from user_shaders.h
instead.
Also bump up MAX_SAVED_TEXTURES (now SHADER_MAX_SAVED) slightly as a
precaution against adding more passes to vo_opengl. I think we're
already flirting with the limit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is even better at preventing discoloration than tone mapping on the
XYZ image. Partly inspired by the HLG OOTF. Also simplifies the way we
tone map, and moves this logic to the pass_tone_map function where it
belongs.
This also fixes what could arguably be considered a bug in the HLG
implementation when using HLG for non-BT.2020 colorspaces, which is not
permitted by spec but thinkable in theory. Although in this case, I
guess it will be arbitrary whether people use the BT.2020-normalized
luma coefficients or change it to fit the colorspace, so I guess either
way could be considered "right", depending on what people end up doing.
Either way, in lieue of standard practice, we do what makes the most
sense (to me), and hopefully others will follow.
The downside is that we upload an extra vec3 uniform even if we don't
use it, but eliminating that would be ugly.
|
|
|
|
|
|
|
| |
For HLG, due to the usage of a reference OOTF configured for 1000 cd/m²,
the default sig_peak of =nom_peak was suboptimal. We can go down to
1000/100 (=10.0), since that's the true dynamic range of the output
signal after it passes through the OOTF.
|
|
|
|
|
|
|
|
|
| |
These can never be uninitialized because the enum cases are exhaustive and
the fallback is in the correct order, but GCC is too dumb to understand
this.
Also explicitly initialize tex_type, because while GCC doesn't warn
about it (for some reason), maybe it will in the future.
|
|
|
|
| |
Changing the headers was actually forgotten in the previous commit.
|
|
|
|
| |
All authors of the current code have agreed.
|
|
|
|
| |
All authors agreed.
|
|
|
|
|
| |
Apparently people are running into the current limit. 64 ought to be
enough for everybody.
|
|
|
|
|
|
|
|
| |
Moves the DXLockObjectsNV call to after PresentEx. This fixes an issue
where the presented image is a single frame late. This may be due to
DXLockObjectsNV locking the render target before StretchRect is done.
The spec indicates that the lock call should provide synchronization
for the resource, so this may be due to a driver bug.
|
|
|
|
|
|
|
|
|
| |
The printout of available modes that you can get with --drm-mode=-1
(with -vo drm or --opengl-backend=drm) does not include the refresh
rate in the printout, which is quite useful to know, if one is to
choose for instance 23.98, or 24 Hz for film material.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
| |
Apparently this is virtually identical to Panasonic's V-Log, but using
the constants from S-Log1 and an extra scaling coefficient to make the
S-Log1 curve less limited. Whatever floats their NIH boat, I guess.
Source: https://pro.sony.com/bbsccms/assets/files/micro/dmpc/training/S-Log2_Technical_PaperV1_0.pdf
|
|
|
|
|
|
|
|
| |
Source: https://pro.sony.com/bbsccms/assets/files/mkt/cinema/solutions/slog_manual.pdf
Not 100% confident in the implementation since the values from the spec
seem to be very subtly off (~1%), but it should be close enough for
practical purposes.
|