1
0
mirror of https://github.com/mpv-player/mpv synced 2025-03-11 08:37:59 +00:00
Commit Graph

226 Commits

Author SHA1 Message Date
igv
2aae5ce0ba vo_opengl: make size of a cropped source image available to user shaders 2017-03-25 13:39:15 +01:00
wm4
8fb9cc2534 vo_opengl: read framebuffer depth from actual FBO used for rendering
In some cases, such as when using the libmpv opengl-cb API, or with
certain vo_opengl backends, the main framebuffer is never accessed.
Instead, rendering is done to a FBO that acts as back buffer. This meant
an incorrect/broken bit depth could be used for dithering.

Change it to read the framebuffer depth lazily on the first render call.

Also move the main FBO field out of the GL struct to MPGLContext,
because the renderer's init function does not need to access it anymore.
2017-03-20 13:31:28 +01:00
wm4
03fe50651b vo_opengl: move some init_gl code to utility functions 2017-03-20 13:20:35 +01:00
wm4
f8861f681f vo_opengl: properly respect dither option if dumb mode is used
When dumb mode is used (the "simple" rendering path), respect the dither
options. Options should never be ignored (except in GLESv2 mode); either
they should be respected in dumb mode, or they should disable dumb mode.
In this case, the former applies.
2017-03-20 04:46:18 +01:00
Philip Sequeira
a2a5fa4545 options: add M_OPT_FILE to some more file options
(Helps shell completion.)
2017-03-06 15:41:06 +01:00
Nicholas J. Kain
e226041355 filter_kernels: Keep f.radius in terms of dest/filter coords.
The existing code modifies f.radius so that it is in terms of the
filter sample radius (in the source coordinate space) and has
some small errors because of this behavior.

This commit changes f.radius so that it is always in terms of
the filter function radius (in the destination coordinate space).

The sample radius can always be derived by multiplying f.radius
by filter_scale, which is the new, more descriptive name for the
previous inv_scale.
2017-03-06 03:31:40 +00:00
wm4
eda69f5333 vo_opengl: move texture mapping of pixel formats to helper function
All supported pixel formats have a specific "mapping" of CPU data to
textures. This function determines the number and the formats of these
textures. Moving it to a helper will be useful for some hardware decode
interop backends, since they all need similar things.
2017-02-17 16:28:31 +01:00
wm4
9c54b224d8 vo_opengl: handle GL_LUMINANCE_ALPHA and integer textures differently
GL_LUMINANCE_ALPHA is the only reason why per-plane swizzles exist.
Remove per-plane swizzles (again), and regrettably handle them as
special cases (again). Carry along the logical texture format (called
gl_format in some parts of the code, including the new one).

We also don't need a use_integer flag, since the new gl_format member
implies whether it's an integer texture. (Yes, the there are separate
logical GL formats for integer textures. This aspect of the OpenGL API
is hysteric at best.)

This should change nothing about actual rendering logic and GL API
usage.
2017-02-17 16:28:31 +01:00
wm4
e0f25010c7 vo_opengl: replace 2 memsets
Cosmetic change.
2017-01-08 11:22:55 +01:00
Niklas Haas
22a22322cb vo_opengl: partially fix rotation for 4:2:2 content
The chroma alignment renormalization code forgot to account for the fact
that the chroma subsampling ratio has to be rotated.

Unfortunately, doing it this way seems to have somewhat broken the
chroma offset rotation logic for odd-sized subsampled image files. While
this is a bug, it's much, much less noticeable, so it's not nearly as
important as the bug this change fixes. Either way, a future patch needs
to still revise this logic, ideally by redesigning the entire rotation
mechanism.
2016-12-28 15:10:48 +01:00
wm4
1a2319f3e4 options: remove deprecated sub-option handling for --vo and --ao
Long planned. Leads to some sanity.

There still are some rather gross things. Especially g_groups is ugly,
and a hack that can hopefully be removed. (There is a plan for it, but
whether it's implemented depends on how much energy is left.)
2016-11-25 21:17:25 +01:00
Philip Sequeira
cf85191cb7 vo_opengl: blend against background color for --alpha=blend
Do it after color management, etc. so that it matches the color drawn in
the margins.
2016-11-13 18:21:27 +01:00
wm4
6a06e6002b vo_opengl: fix --blend-subtitles handling
The intention was that if --blend-subtitles is enabled, the frame should
always be re-rendered instead of using e.g. a cached scaled frame. The
reason is that subtitles can change anyway, e.g. if you pause and change
subtitle size and such.

On the other hand, if the frame is marked as repeated, it should always
use the cached copy. Actually "simplify" this and drop the cache only if
playback is paused (which frame->still indicates indirectly).

Also see PR #3773.
2016-11-07 22:49:24 +01:00
wm4
de72cb2c33 vo_opengl: fix redrawing with hardware decoding
unmap_current_image() is called after rendering. This essentially
invalidates the textures, so we can't assume that the image is still
present.

Also see PR #3773.
2016-11-07 22:49:16 +01:00
Niklas Haas
654721c27b filter_kernels: add ability to taper kernels/windows
This allows us to define the tukey window (and other tapered windows).

Also add a missing option definition for `wblur` while we're at it, to
make testing out window-related stuff easier.
2016-11-01 16:25:40 +01:00
wm4
17733bd5b8 vo_opengl: make frame reupload logic more robust
It's not that easy to decide whether a frame needs to be
reuploaded/rerendered. Using unique frame IDs for input makes it
slightly easier and more robust. This also removes the use of video PTS
in the interpolation path.

This should also avoid reuploading the video frame if it's just redrawn
in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 16:25:40 +01:00
wm4
202f695398 vo_opengl: partially re-enable glFlush() calls
It turns out the glFlush() call really helps in some cases, though only
in audio timing mode (where we render, then wait for a while, then
display the frame). Add a --opengl-early-flush=auto mode, which does
exactly that.

It's unclear whether this is fine on OSX (strange things going on
there), but it should be.

See #3670.
2016-10-21 17:23:26 +02:00
wm4
53798b6465 vo_opengl: apply --opengl-early-flush in dumb mode too
In "dumb mode" (where most features are disabled and which only performs
some basic rendering) we explicitly copy a set of whitelisted options,
and leave all the other options at their default values. Add the new
--opengl-early-flush option to this whitelist. Also remove an option
field accidentally added in the commit adding --opengl-early-flush.
2016-10-05 20:35:00 +02:00
wm4
6789f9b094 vo_opengl: disable glFlush() by default, and add an option to enable it
It seems this can cause issues with certain platforms, so better to
disable it by default. The original reason for this isn't overly
justified, and display-sync mode should get rid of the need for it
anyway.

The new option is meant for testing, and will probably be removed if
nobody comes up and reports that enabling the option actually improves
anything.
2016-10-05 12:21:34 +02:00
wm4
486b3ce6f8 vo_opengl: minor simplification
The extra gl_transform_trans() has no apparent use.
2016-10-01 16:12:03 +02:00
wm4
82231fd74d vo_opengl: attempt to fix chroma offset under rotation and flipping
Other than being overly convoluted, this seems to make sense to me.
Except that to get the "rot" transform I have to set flip=true, which
makes no sense at all to me.
2016-10-01 16:07:51 +02:00
wm4
052584c9e2 vo_opengl: add debugging options for testing with padded textures 2016-10-01 12:09:18 +02:00
wm4
52fea2f909 vo_opengl: partially fix dumb-mode cropping with rotation
Combining rotation and cropping didn't work. It was just completely
broken.

I'm still not sure if this is correct. Chroma positioning seems to be
broken on rotation. There might also be a problem with non-mod-2 frame
sizes. Still, strictly an improvement for both rotated and non-rotated
rendering modes.

Also, this could probably be written in a more elegant way.
2016-09-30 22:19:01 +02:00
wm4
2aba6972cf vo_opengl: allow hwdec interops to support multiple image formats 2016-09-30 13:46:27 +02:00
wm4
c296b6204f vo_opengl: apply 90° rotation to chroma texture size
When we rotate the inmage by 90° or 270°, chroma width and height need
to be swapped.

Fixes #3568.

But is the chroma sub location correct? Who the hell knows...
2016-09-22 15:16:53 +02:00
wm4
fe7db61035 options: slightly better option update mechanism
Extend the flag-based notification mechanism that was used via
M_OPT_TERM. Make the vo_opengl update mechanism use this (which, btw.,
also fixes compilation with OpenGL renderers forcibly disabled).

While this adds a 3rd mechanism and just seems to further the chaos, I'd
rather have a very simple mechanism now, than actually furthering the
mess by mixing old and new update mechanisms. In particular, we'll be
able to remove quite some property implementations, and replace them
with much simpler update handling. The new update mechanism can also
more easily refactored once we have a final mechanism that handles
everything in an uniform way.
2016-09-19 19:51:26 +02:00
wm4
dc48893630 options: simplify M_OPT_EXIT
There were multiple values under M_OPT_EXIT (M_OPT_EXIT-n for n>=0).
Somehow M_OPT_EXIT-n either meant error code n (with n==0 no error?), or
the number of option valus consumed (0 or 1). The latter is MPlayer
legacy, which left it to the option type parsers to determine whether an
option took a value or not. All of this was changed in mpv, by requiring
the user to use explicit syntax ("--opt=val" instead of "-opt val").

In any case, the n value wasn't even used (anymore), so rip this all
out. Now M_OPT_EXIT-1 doesn't mean anything, and could be used by a new
error code.
2016-09-17 18:07:40 +02:00
wm4
c47ae06ed8 vo_opengl: don't pass negative height to overlay_adjust()
Negative height is used to signal a flipped framebuffer. There's
absolutely no reason to pass this down to overlay_adjust(), and only
requires implementers to deal with an additional special-case.
2016-09-16 14:50:05 +02:00
wm4
88a07c5f53 vo_opengl: dynamically manage texture units
A minor cleanup that makes the code simpler, and guarantees that we
cleanup the GL state properly at any point.

We do this by reusing the uniform caching, and assigning each sampler
uniform its own texture unit by incrementing a counter. This has various
subtle consequences for the GL driver, which hopefully don't matter. For
example, it will bind fewer textures at a time, but also rebind them
more often.

For some reason we keep TEXUNIT_VIDEO_NUM, because it limits the number
of hook passes that can be bound at the same time.

OSD rendering is an exception: we do many passes with the same shader,
and rebinding the texture each pass. For now, this is handled in an
unclean way, and we make the shader cache reserve texture unit 0 for the
OSD texture. At a later point, we should allocate that one dynamically
too, and just pass the texture unit to the OSD rendering code. Right now
I feel like vo_rpi.c (may it rot in hell) is in the way.
2016-09-14 20:46:45 +02:00
wm4
e24ba8fa7f vo_opengl: require explicit reset on shader cache after rendering
The caller now has to call gl_sc_reset(), and _after_ rendering. This
way we can unset OpenGL state that was setup for rendering. This affects
the shader program, for example. The next commit uses this to
automatically manage texture units via the shader cache.

vo_rpi.c changes untested.
2016-09-14 20:24:06 +02:00
wm4
ffbc85cde9 vo_opengl: remove a redundant glActiveTexture() call
This bound video textures to individual texture units - this is how it
used to work long ago, but now is pointless, and maybe even dangerous.
2016-09-14 18:51:32 +02:00
Niklas Haas
f7471b7ff4 vo_opengl: fix typo in bt.601 auto-guessing logic
The wrong enum got copied here, so it was essentially using the transfer
characteristics as the primaries (instead of the primaries), which
accidentally worked fine most of the time (since the two usually
coincided), but broke on weird/mistagged files.
2016-09-13 09:23:47 +02:00
wm4
274e71ee8b vo_opengl: add hw overlay support and use it for RPI
This overlay support specifically skips the OpenGL rendering chain, and
uses GL rendering only for OSD/subtitles. This is for devices which
don't have performant GL support.

hwdec_rpi.c contains code ported from vo_rpi.c. vo_rpi.c is going to be
deprecated. I left in the code for uploading sw surfaces (as it might
be slightly more efficient for rendering sw decoded video), although
it's dead code for now.
2016-09-12 19:58:58 +02:00
wm4
c3097422f2 vo_opengl: use dedicated image unref function in config case
Just another corner-caseish potential issue. Unlike unreffing the image
manually, unref_current_image() also takes care of properly unmapping
hwdec frames. (The corner-case part of this is that it's probably never
mapped at this point, but it's apparently not entirely guaranteed.)
2016-09-08 16:06:12 +02:00
wm4
8bb9632e27 vo_opengl: simplify a condition
The " || vimg->mpi" part virtually never seems to trigger, but on the
other hand could possibly create unintended corner cases (for example by
trying to upload a NULL image, which would then be marked as an error
and render a blue screen).

I guess it's a leftover from over times, where a NULL image meant
"redraw the current frame". This is now handled by actually passing
along the current frame.
2016-09-08 16:06:12 +02:00
wm4
622f9cf1aa vo_opengl: fix incorrect video rendering after vdpau preemption recovery
This could also trigger in certain other cases, whenever it falls back
to dumb mode.
2016-09-07 18:48:24 +02:00
wm4
9ab0f60d44 vo_opengl: simplify option handling
Instead of copying the options around... just don't. video.c now has
full control over when options are updated. (It still gets notified from
outside, but it decides when the updated options are copied: when
m_config_cache_update() is called.) So there's no need for tricky
stuff, and it can be simplified a bit.

Also change lcms.c. We could do it like video.c, and get the options
from the global config store. But it seems simpler to just provide a
pointer to an option struct, which is arbitrarily mutated from the
outside (from the perspective of lcms.c).
2016-09-06 11:11:36 +02:00
wm4
e5cefa346d vo_opengl: fix --icc-profile initial behavior
Setting --icc-profile had no effect, until a vo_opengl option was
changed at runtime. We must initialize the renderer for the initial
option state too.

For some reason, the ICC profile gets loaded twice. The next commit
happens to fix this.
2016-09-06 11:11:23 +02:00
wm4
849480d0c9 vo_opengl: deprecate sub-options, add them as global options
vo_opengl sub-option were always rather annoying to handle. It seems
better to make them global options instead. This is simpler and easier
to use. The only disadvantage we are aware of is that it's not clear
that many/all of these new global options work with vo_opengl only.

--vo=opengl-hq is also deprecated.

There is extensive compatibility with the old behavior. One exception is
that --vo-defaults will not apply to opengl-hq (though with opengl it
still works). vo-cmdline is also dysfunctional and will be removed in a
following commit.

These changes also affect opengl-cb.

The update mechanism is still rather inefficient: it requires syncing
with the VO after each option change, rather than batching updates.
There's also no granularity (video.c just updates "everything", and if
auto-ICC profiles are enabled, vo_opengl.c will fetch them on each
update).

Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
2016-09-02 21:21:47 +02:00
wm4
b2657814c9 vo_opengl: minor renderer option access refactor
Reduce accesses to the renderer opts in vo_opengl.c, and instead add
accessors for them to video.c.

I suppose gamma and maybe icc-auto could be moved to vo_opengl.c
options. Also, the output colorspace could probably be adjusted to what
is really used, not just the options (although it's possible that this
commit changes this, due to video.c mutating its own copy of the options
according to actual renderer capapbilities).

But don't deal with this now.
2016-09-02 14:50:03 +02:00
Niklas Haas
ce05413a87 vo_opengl: remove pre/post/scale-shaders
Deprecated in favor of user-shaders, which are functionally equivalent
but superior. (Except in the case of scaler-shader, which has no direct
replacement, but it turned out to be a very unpopular feature either way
- most custom scalers don't fit into the mpv kernel infrastructure and
are therefore implemented as user shaders either way)

Signed-off-by: wm4 <wm4@nowhere>
2016-09-02 09:29:16 +02:00
wm4
3e0d4de988 vo_opengl: explicitly check for GL errors around framebuffer depth check
It seems like many GL implementations (including Mesa) choke on this,
while others are fine. We still think that this use of the GL API is
allowed by the standard (at least in the Mesa case), so to reduce
confusion, explicitly check the "controversial" calls, and use an
appropriate error message.
2016-08-29 14:02:24 +02:00
Niklas Haas
46b60a3e72 vo_opengl: remove the 3dlut-size npot2 restriction
This requires changing the pixel upload alignment because the odd sizes
might not be aligned to multiples of 4.

Anyway, the restriction has no real benefit and the sizes in between 32
and 64 might be worth using, so just drop it.
2016-07-25 12:50:11 +02:00
Niklas Haas
ebe798a333 vo_opengl: increase 3DLUT accuracy at lower LUT sizes
This code had the exact same texture indexing bug that the original
scaler code had before the introduction of the LUT_POS macro to fix it.

We can re-use this same macro here, and the performance drop is
virtually entirely negligible. The benefit is greatly improved LUT
accuracy as the 3DLUT size decreases - in particular, the old LUT
started introducing more and more black crush the lower your LUT size is
(because the error was essentially an over-contrast bias, with a
magnitude linearly related to the lut size).

The new code improves black stability as the LUT size decreases, and
only at very low values (16 and below) do black levels start noticeably
getting affected (due to crude linearization of the nonlinear response
curve).

The default value of 3dlut-size is definitely generous enough for this
to make no difference out of the box, but it also causes no performance
drop at all on my machine so I see no harm in improving the logic.
Furthermore, this means we could easily decrease the default 3dlut size
in a future commit, perhaps even down to 64x64x64 as a default. (But
more testing is warranted here)
2016-07-25 10:26:45 +02:00
Niklas Haas
7d01a16f64 vo_opengl: add a tscale=linear direct implementation
This uses GLSL mix() instead of going through an indirect texture
access. Easy to implement and might require less resources on some
devices, since the oversample code was already essentially just a
special case of this.

Could be made the new default (as per issue #2685), but that should be
done in a separate commit.
2016-07-21 11:26:19 +02:00
wm4
f98e1b0b96 vo_opengl: error out gracefully when trying to use FBOs without FBO API
This can for example happen with vo_opengl_cb, if it is used with a GL
implementation that does not supports FBOs. (mpv itself should never
attempt to use FBOs if they're not available.)

Without this check it would trigger an assert() in our dummy
glBindFramebuffer wrapper.

Suspected cause of #3308, although it's still unlikely.
2016-07-04 13:34:31 +02:00
Niklas Haas
be230d16e5 vo_opengl: move eval_szexpr to user_shaders.c
This moves some of the bulky user-shader specific logic into the file
dedicated to it. Rather than expose video.c state, variable lookup is
now done via a simulated closure.
2016-07-03 19:42:52 +02:00
Niklas Haas
923e3c7b20 vo_opengl: generalize HDR tone mapping mechanism
This involves multiple changes:

1. Brightness metadata is split into nominal peak and signal peak.

For a quick and dirty explanation: nominal peak is the brightest value
that your color space can represent (i.e. the brightness of an encoded
1.0), and signal peak is the brightest value that actually occurs in
the video (i.e. the brightest thing that's displayed).

2. vo_opengl uses a new decision logic to figure out the right nom_peak
and sig_peak for all situations. It also does a better job of picking
the right target gamut/colorspace to use for the OSD. (Which still is
and still should be treated as sRGB). This change in logic also
fixes #3293 en passant.

3. Since it was growing rapidly, the logic for auto-guessing / inferring
the right colorimetry configuration (in pass_colormanage) was split from
the logic for actually performing the adaptation (now pass_color_map).

Right now, the new logic doesn't do a whole lot since HDR metadata is
still ignored (but not for long).
2016-07-03 19:42:52 +02:00
Niklas Haas
d81fb97f45 mp_image: split colorimetry metadata into its own struct
This has two reasons:

1. I tend to add new fields to this metadata, and every time I've done
so I've consistently forgotten to update all of the dozens of places in
which this colorimetry metadata might end up getting used. While most
usages don't really care about most of the metadata, sometimes the
intend was simply to “copy” the colorimetry metadata from one struct to
another. With this being inside a substruct, those lines of code can now
simply read a.color = b.color without having to care about added or
removed fields.

2. It makes the type definitions nicer for upcoming refactors.

In going through all of the usages, I also expanded a few where I felt
that omitting the “young” fields was a bug.
2016-07-03 19:42:52 +02:00
Niklas Haas
3abf9c9204 vo_opengl: don't constantly resize the output FBO
Commit 883d3114 seems to have (accidentally?) dropped the FBOTEX_FUZZY
from the output_fbo resize, which means that current master will keep
resizing and resizing the FBO as you change the window size, introducing
severe memory leaking after a while. (Not sure why that would cause
memory leaks, but I blame nvidia)

Either way, it's bad for performance too, so it's worth fixing.
2016-07-03 19:42:52 +02:00