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

79 Commits

Author SHA1 Message Date
Niklas Haas
93546f0c2f vo_opengl: refactor pass_read_video and texture binding
This is a pretty major rewrite of the internal texture binding
mechanic, which makes it more flexible.

In general, the difference between the old and current approaches is
that now, all texture description is held in a struct img_tex and only
explicitly bound with pass_bind. (Once bound, a texture unit is assumed
to be set in stone and no longer tied to the img_tex)

This approach makes the code inside pass_read_video significantly more
flexible and cuts down on the number of weird special cases and
spaghetti logic.

It also has some improvements, e.g. cutting down greatly on the number
of unnecessary conversion passes inside pass_read_video (which was
previously mostly done to cope with the fact that the alternative would
have resulted in a combinatorial explosion of code complexity).

Some other notable changes (and potential improvements):

- texture expansion is now *always* handled in pass_read_video, and the
  colormatrix never does this anymore. (Which means the code could
  probably be removed from the colormatrix generation logic, modulo some
  other VOs)

- struct fbo_tex now stores both its "physical" and "logical"
  (configured) size, which cuts down on the amount of width/height
  baggage on some function calls

- vo_opengl can now technically support textures with different bit
  depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries
  inside img_format.c doesn't export this (nor does ffmpeg support it,
  really) so the status quo of using the same tex_mul for all planes is
  kept.

- dumb_mode is now only needed because of the indirect_fbo being in the
  main rendering pipeline. If we reintroduce p->use_indirect and thread
  a transform through the entire program this could be skipped where
  unnecessary, allowing for the removal of dumb_mode. But I'm not sure
  how to do this in a clean way. (Which is part of why it got introduced
  to begin with)

- It would be trivial to resurrect source-shader now (it would just be
  one extra 'if' inside pass_read_video).
2016-03-05 13:08:38 +01:00
igv
b638a413c3 vo_opengl: remove redundant code 2016-02-28 17:46:16 +01:00
igv
8bafd68fff vo_opengl: set uniform variable "pixel_size" for internal shaders 2016-02-26 23:21:03 +01:00
Niklas Haas
2f562825e0 vo_opengl: declare vec4 color inside fragment shader stub
Why was this done so stupidly, with so many complicated special cases,
before? Declare it once so the shader bits don't have to figure out where
and when to do so themselves.
2016-02-23 20:58:15 +01:00
igv
f0794d0544 vo_opengl: set uniform variable "pixel_size"
pixel_size is often used variable, also reciprocal is a costly operation
for AMD and older nVidia (prior to Kepler) GPUs.
2016-02-22 22:33:04 +01:00
igv
935c8402bc vo_opengl: set the correct size of the input image 2016-02-22 22:32:49 +01:00
wm4
c01aaabb3e vo_opengl: use correct gl_target variable
p->gl_target and plane->gl_target are always the same value here, but
semantically plane->gl_target is the correct one.
2016-02-18 10:46:03 +01:00
wm4
d6af58c699 vo_opengl: pass the correct target to deband functions
Apple crap (namely hardware decoding interop) forces us to use rectangle
textures for input. But after that we continue with normal textures.
This was not considered for debanding, and the sampler type used for it
can be different depending on the exact render chain. Simply use the
target type of the input texture.
2016-02-18 10:41:13 +01:00
wm4
fd80fcd3f3 vo_opengl: unconfuse Coverity
It thinks that integer_conv_fbo[index] is implied to be accessed with up
to index=5. Although that is theoretical only, it has a point that this
makes no sense. Use the same constant for the array allocation, to make
it more uniform and robust.

Fixes CID 1350060.
2016-02-12 15:56:58 +01:00
wm4
fb3b8e1e25 vo_opengl: do chroma merging in integer conversion stage
This is a huge win when playing yuv420p10 on ANGLE - the 2 conversion
stages for planes 1 and 2 and the chroma merging stage are all merged
into one.
2016-01-27 21:08:30 +01:00
wm4
34bead4859 vo_opengl: replace tscale-interpolates-only with interpolation-threshold
The previous approach was too naive, and can e.g. ruin playback if
scheduling switches e.g. between 1 and 2 vsync per frame.
2016-01-27 21:07:17 +01:00
wm4
7b6e3772ab vo_opengl: support 10 bit support with ANGLE
GLES does not support high bit depth fixed point textures for unknown
reasons, so direct 10 bit input is not possible. But we can still use
integer textures, which are supported by GLES 3.0. These store integer
data just like the standard fixed point textures, except they are not
normalized on sampling. They also don't support bilinear filtering, and
require a special sampler ("usampler2D").

While these texture formats enable us to shuffle the data to the GPU,
they're rather impractical with the requirements mentioned above and our
current architecture. One problem is that most code assumes it can
always use bilinear scaling (even if bilinear is never used when using
appropriate scale/cscale options). Another is that we don't have any
concept of running a function on a texture in an uniform way.

So for now, run a simple conversion step through a FBO. The FBO will use
the rgba16f format normally, which gives enough bits for 10 bit, and
will at least gracefully degrade with higher depth input.

This is bound to be much slower than a more "direct" method, but at
least it works and is simple to implement.

The odd change of function call order in init_video() is to properly
disable "dumb mode" (no FBO use) if these texture formats are in use.
2016-01-26 21:35:23 +01:00
wm4
beb7094301 vo_opengl: actually reset use_normalized_range field
This was never reset - absolutely can't be right. If the renderer
somehow switches back to another codepath, it certainly has to be reset.
Maybe this was hard to hit, as the normalization is going to be
idempotent in simpler cases (like rendering RGBA input).

Also get rid of the "merged" variable.
2016-01-26 21:35:23 +01:00
wm4
fc3ca14ef7 vo_opengl: default to rgba16f FBOs on ANGLE
Although it has only 1 bit more precission than rgba10_a2, it was
reported to improve the visual quality.
2016-01-26 21:35:16 +01:00
wm4
521110054d vo_opengl: add tscale-interpolates-only sub-option 2016-01-25 21:46:40 +01:00
wm4
bd1fb6f9b1 vo_opengl: default scaler-resizes-only sub-option to yes
Often requested. The main argument, that prominent scalers like sharpen
change the image even if no scaling happens, disappeared anyway.
("sharpen", unsharp masking, is neither prominent nor a scaler anymore.
This is an artifact from MPlayer, which fuses unsharp masking with
bilinear scaling in order to make it single-pass, or so.)
2016-01-25 21:46:40 +01:00
wm4
7f300b4204 vo_opengl: rename custom shader entrypoint from sample to sample_pixel
"sample" is a reserved identifier at least in GLES ES. Suggestions for a
better name than "sample_pixel" are still welcome.

Fixes #2733.
2016-01-25 20:24:41 +01:00
wm4
3a015b9ec7 video: remove some useless old RGB formats
Some VOs had support for these - remove them.

Typically, these formats will have only some use in cases where using
RGB software conversion with libswscale is faster than letting the
VO/GPU do it (i.e. almost never). For the sake of testing this case,
keep IMGFMT_RGB565. This is the least messy format, because it has no
padding/alpha bits with unknown semantics.

Note that decoding to these formats still works. We'll let libswscale
repack the data to whatever the VO in use can take.
2016-01-25 10:43:35 +01:00
wm4
e4ec0f42e4 Change GPL/LGPL dual-licensed files to LGPL
Do this to make the license situation less confusing.

This change should be of no consequence, since LGPL is compatible with
GPL anyway, and making it LGPL-only does not restrict the use with GPL
code.

Additionally, the wording implies that this is allowed, and that we can
just remove the GPL part.
2016-01-19 18:36:34 +01:00
wm4
27bc881cd8 vo_opengl: generic semi-planar support
Should take care of the planned FFmpeg AV_PIX_FMT_P010 addition. (This
will eventually be needed when doing HEVC Main 10 decoding with DXVA2
copyback.)
2016-01-07 16:31:52 +01:00
Bin Jin
2f4bd58f4a vo_opengl: reset nnedi3 weights properly
Fixes #2661
2016-01-03 23:33:54 +01:00
wm4
082c23515f vo_opengl: fix operation on GLSL versions earlier than 1.30
GLSL below version 1.30 does not support mix() with a boolean
interpolation value. Use ?: instead. Untested, but probably works.
2015-12-24 14:44:46 +01:00
wm4
eac0665b8d vo_opengl: blend transparent video against tiles by default
Add a "blend-tiles" choice to the "alpha" sub-option. This is pretty
simplistic and uses the GL raster position to derive the tiles. A weird
consequence is that using --vo=opengl and --vo=opengl-hq gives different
scaling behavior (screenspace pixel size vs. source video pixel size
16x16 tiles), but it seems we don't have easy access to the original
texture coordinates. Using the rasterpos is probably simpler.

Make this option the default.
2015-12-22 23:18:46 +01:00
wm4
cd24fdcd5a vo_opengl: disable pbo by defaults for opengl-hq
Too many problems.
2015-12-19 16:26:36 +01:00
wm4
47f2f554a3 vo_opengl: handle alpha with odd bit widths too
Since alpha isn't pulled through the colormatrix (maybe it should?), we
reject alpha formats with odd sizes, such as yuva444p10.

But the awful tex_mul path in vo_opengl does this anyway (at some points
even explicitly), which means there will be a subtle difference in
handling of 16 bit yuv alpha formats. Make it consistent and always
apply the range adjustment to the alpha component. This also means odd
sizes like 10 bit are supported now.

This assumes alpha uses the same "shifted" range as the yuv color
channels for depths larger than 8 bit. I'm not sure whether this is
actually the case.
2015-12-19 16:11:34 +01:00
wm4
a0519f1d18 vo_opengl: cocoa: output premultiplied alpha
Which is apparently what is expected here. (I'm pretty sure X11
compositors want stright alpha, so 2 code paths are needed.)
2015-12-19 14:14:12 +01:00
wm4
3394d37b4e vo_opengl: refactor how framebuffer depth is passed from backends
Store the determined framebuffer depth in struct GL instead of
MPGLContext. This means gl_video_set_output_depth() can be removed, and
also justifies adding new fields describing framebuffer/backend
properties to struct GL instead of having to add more functions just to
shovel the information around.

Keep in mind that mpgl_load_functions() will wipe struct GL, so the
new fields must be set before calling it.
2015-12-19 14:14:12 +01:00
wm4
f24ba544cd vo_opengl: enable brightness/contrast controls for RGB
Why not.

Also, instead of disabling hue/saturation for RGB, just don't apply
them. (They don't make sense for conversion matrixes other than YUV, but
I can't be bothered to keep the fine-grained disabling of UI controls
either.)
2015-12-12 14:47:30 +01:00
wm4
47e6ef0bdf vo_opengl: remove one more XYZ special-case
The XYZ colorspace on XYZ pixfmt is enforced in some sanitation routine.
2015-12-09 17:10:38 +01:00
Bin Jin
6d36c432ab vo_opengl: fix precision loss of fruit dithering matrix
With default setting, the matrix for fruit dithering requires 12 bits
precision (values from 0/4096 to 4095/4096). But 16-bit float
provides only 10 bits. In addition, when `dither-size-fruit=8` is
set, 16 bits are required from the texture format.

Fix this by attempting to use 16 bit integer texture first. This is
still not precise, but should be better than using a half float.
2015-12-09 00:36:48 +01:00
wm4
45ae0716be csputils: rename "yuv2rgb" functions
They're not necessarily restricted to YUV aka YCbCr.

vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
2015-12-09 00:23:36 +01:00
wm4
c5c7b239b6 csputils, vo_opengl: remove XYZ special case in color matrix retrieval
This just seems unnecessary. Refactor it a bit. There should be no
functional changes.
2015-12-09 00:16:51 +01:00
wm4
c138505813 vo_opengl: enable colormatrix even for RGB input
Enables brightness/contrast controls, and handles gbrp10 correctly.
2015-12-07 23:48:59 +01:00
wm4
663415b914 vo_opengl: fix issues with some obscure pixel formats
The computation of the tex_mul variable was broken in multiple ways.
This variable is used e.g. by debanding for moving expansion of 10 bit
fixed-point input to normalized range to another stage of processing.

One obvious bug was that the rgb555 pixel format was broken. This format
has component_bits=5, but obviously it's already sampled in normalized
range, and does not need expansion. The tex_mul-free code path avoids
this by not using the colormatrix. (The code was originally designed to
work around dealing with the generally complicated pixel formats by only
using the colormatrix in the YUV case.)

Another possible bug was with 10 bit input. It expanded the input by
bringing the [0,2^10) range to [0,1], and then treating the expanded
input as 16 bit input. I didn't bother to check what this actually
computed, but it's somewhat likely it was wrong anyway. Now it uses
mp_get_csp_mul(), and disables expansion when computing the YUV matrix.
2015-12-07 23:48:59 +01:00
Bin Jin
c569d4f6ed vo_opengl: decrease default lookup texture size to 64
It turns out that with accurate lookup we can decrease the
default size of texture now. Do it to compensate the performance
loss introduced by the LUT_POS macro.
2015-12-07 23:48:40 +01:00
Bin Jin
e6058d3dc3 vo_opengl: make LOOKUP_TEXTURE_SIZE configurable 2015-12-07 23:48:18 +01:00
Bin Jin
c1a96de41c vo_opengl: Fix minor LUT sampling error
Define a macro to correct the coordinate for lookup texture. Cache
the corrected coordinate for 1D filter and use mix() to minimize the
performance impact.
2015-12-07 23:48:15 +01:00
wm4
17507b5935 vo_opengl: require --enable-gpl3 for nnedi
There are claims that nnedi3.c doesn't constitute its own new
implementation, but is derived from existing HLSL or OpenCL shaders
distributed under the LGPLv3 license.

Until these are resolved, do the "correct" thing and require
--enable-gpl3 to build nnedi.
2015-12-03 09:32:40 +01:00
Bin Jin
42a0f4d87b vo_opengl: enable NNEDI3 prescaler on OpenGL ES 3.0
It turns out that both UBO and intBitsToFloat() are supported in
OpenGL ES 3.0[1][2], enable them so that NNEDI3 prescaler can be used
in a wider range of backends.

Also fixes some implicit int-to-float conversions so that the shader
actually compiles on GLES.

Tested on Linux desktop (nvidia 358.16) with "es" sub-option.

[1]: https://www.khronos.org/opengles/sdk/docs/man3/html/glGetUniformBlockIndex.xhtml
[2]: https://www.khronos.org/opengles/sdk/docs/manglsl/docbook4/xhtml/intBitsToFloat.xml
2015-12-02 12:32:02 +01:00
wm4
6ff1cd5502 vo_opengl: make tscale=mitchell:tscale-clamp the default
Looks better than "oversample". tscale-clamp suggested by haasn.
2015-11-29 17:55:01 +01:00
wm4
9fc74d5acd vo_opengl: warn if interpolation is enabled, but not display-sync
Try to avoid user confusion.

Reading the global options in this place is a pretty disgusting hack,
but it's still the most robust way.
2015-11-28 20:10:01 +01:00
wm4
318e9801f2 vo_opengl: fix interpolation with display-sync
At least I hope so.

Deriving the duration from the pts was not really correct. It doesn't
include speed adjustments, and becomes completely wrong of the user e.g.
changes the playback speed by a huge amount. Pass through the accurate
duration value by adding a new vo_frame field.

The value for vsync_offset was not correct either. We don't need the
error for the next frame, but the error for the current one. This wasn't
noticed because it makes no difference in symmetric cases, like 24 fps
on 60 Hz.

I'm still not entirely confident in the correctness of this, but it sure
is an improvement.

Also, remove the MP_STATS() calls - they're not really useful to debug
anything anymore.
2015-11-28 15:45:49 +01:00
wm4
7023c383b2 vo: change vo_frame field units
This was just converting back and forth between int64_t/microseconds and
double/seconds. Remove this stupidity. The pts/duration fields are still
in microseconds, but they have no meaning in the display-sync case (also
drop printing the pts field from opengl/video.c - it's always 0).
2015-11-27 22:04:44 +01:00
wm4
1fe64c61be vo_opengl: disable interpolation without display-sync
Without display-sync mode, our guesses wrt. vsync phase etc. are much
worse, and I see no reason to keep the complicated "vsync_timed" code.
2015-11-25 22:10:55 +01:00
wm4
59eb489425 vo_opengl: enable dumb-mode automatically if possible
I decided that I actually can't stand how vo_opengl unnecessarily puts
the video through 3 shader stages (instead of 1). Thus, what was meant
to be a fallback for weak OpenGL implementations, the dumb-mode, now
becomes default if the user settings allow it.

The code required to check for the settings isn't so wild, so I guess
it's manageable. I still hope that one day, our rendering logic can
generate ideal shader stages for this case too.

Note that in theory, dumb-mode could be reenabled at runtime due to a
color management 3D LUT being set, so a separate dumb_mode field is
required. The dumb-mode option can't just be overwritten.
2015-11-19 21:22:24 +01:00
wm4
4fd0cd4a73 vo_opengl: support 3D textures on ANGLE
Unfortunately, color management can still not work, because no GLES
version specified so far support fixed-point 16 bit textures. Maybe
we could use integer textures, but these don't support filtering.
Using float textures would be another possibility.
2015-11-19 21:21:04 +01:00
wm4
6df3fa2ec1 vo_opengl: switch FBO format on GLES
GL_RGB10_A2 is the best fixed-point format we can get on GLES/ANGLE for
now. (Unless we somehow switch to non-normalized integer textures.)
2015-11-19 21:20:50 +01:00
wm4
1a8b06f67e vo_opengl: make 1D textures completely optional
Polar scalers use 1D textures, because they're slightly faster on some
GPUs than 2D textures. But 2D textures work too, so add support for
them.

Allows using these scalers with ANGLE.
2015-11-19 21:20:40 +01:00
wm4
a6fb80baa4 vo_opengl: add RGBA8 framebuffer format, enable non-dumb mode for ES 3.0
This makes advanced scaling sort-of work for GLES 3.0 (on ANGLE). It's
still not very advisable, as 8 bits might not be enough to avoid
debanding. (Ironically, the debanding filter can be enabled, and does
not raise any GL errors - but probably doesn't do anything useful.)
2015-11-19 14:45:06 +01:00
wm4
f9a2fc592f vo_opengl: don't mix floats and integers in dither shader
Some GLSL dialects (GLSL ES 3.00) do not have such implicit conversions.
They have to be made floats for the sake of the shader compiler.
2015-11-19 14:41:49 +01:00