| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of reading back the image from textures, keep a reference to the
original image, and return that.
The main reason this was done this way was that originally, images
weren't refcounted, and would be deallocated or overwritten as soon as
the VO's draw call returned. But now there isn't really a good reason
for this anymore. One possibly _could_ argue that it was better because
other code could reuse the image sooner (e.g. for the cache), but on the
other hand, the VO runs already on a different thread, and filtering and
decoding each run on other threads too, so this argument probably
wouldn't hold up.
|
|
|
|
|
|
|
|
| |
Instead of converting the hw surface to an image in the VO, provide a
generic way to convet hw surfaces, and use this in the screenshot code.
It's all relatively straightforward, except vdpau is being terrible. It
needs a huge chunk of new code, because copying back is not simple.
|
|
|
|
|
|
|
| |
This also fixes the maximum range to 16.0, which was previously set to
32.0 and incorrectly documented as 8.0. 16 taps should be more than
anybody will ever need, but it's the highest radius that's supported by
all affected filters.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't load all the legacy functions (including ancient extensions).
Slightly simplify function loader and context creation, now that legacy
GL doesn't need to be handled. Remove the code for drawing OSD in legacy
mode.
Remove all the header hacks, which were meant for ancient OpenGL headers
which didn't even support things like OpenGL 1.3. Instead, adjust the
GLX check to make sure we get both OpenGL 3x and 2.1 symbols. For win32
and OSX, we assume that the user has the latest headers anyway. For
wayland, we hope that things somehow go right.
|
|
|
|
|
|
|
|
|
|
| |
Simply clamp off the U/V components in the colormatrix, instead of doing
something special in the shader.
Also, since YA8/YA16 gave a plane_bits value of 16/32, and a colormatrix
calculation overflowed with 32, add a component_bits field to the image
format descriptor, which for YA8/YA16 returns 8/16 (the wrong value had
no bad consequences otherwise).
|
|
|
|
| |
For an explanation see the additions to the manpage.
|
|
|
|
|
|
|
| |
Broke operation with GLSL.
Since 1D texture usage was apparently (and mysteriously) good for speed,
it might be added back, but it's unknown how to do so in a clean way.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After finding out more about how video mastering is done in the real
world it dawned upon me why the "hack" we figured out in #534 looks so
much better.
Since mastering studios have historically been using only CRTs, the
practice adopted for backwards compatibility was to simulate CRT
responses even on modern digital monitors, a practice so ubiquitous that
the ITU-R formalized it in R-Rec BT.1886 to be precisely gamma 2.40.
As such, we finally have enough proof to get rid of the option
altogether and just always do that.
The value 1.961 is a rounded version of my experimentally obtained
approximation of the BT.709 curve, which resulted in a value of around
1.9610336. This is the closest average match to the source brightness
while preserving the nonlinear response of the BT.1886 ideal monitor.
For playback in dark environments, it's expected that the gamma shift
should be reproduced by a user controlled setting, up to a maximum of
1.224 (2.4/1.961) for a pitch black environment.
More information:
https://developer.apple.com/library/mac/technotes/tn2257/_index.html
|
|
|
|
|
| |
This is the polar (elliptic weighted average) version of lanczos.
This introduces a general new form of polar filters.
|
|
|
|
|
|
|
|
|
| |
This avoids issues when upscaling directly in linear light, and is the
recommended way to upscale images according to imagemagick.
The default slope of 6.5 offers a reasonable compromise between
ringing artifacts eliminated and ringing artifacts introduced by
sigmoid-upscaling. Same goes for the default center of 0.75.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the given mp_image_params does not match with that of gl_video,
gl_video_config() always calls uninit_video() but calls init_video()
only if valid format is given.
Since uninit_video() does not change image_params of gl_video,
when the same params as the previous one is given to gl_video_config()
after gl_video is unitialized with invalid format, gl_video_config()
never calls init_video().
To prevent this, invalidate image_params of gl_video in uninit_video().
|
|
|
|
| |
This removes an old code path that was disabled in 016bb14.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes vo_opengl_cb respond to controls like "gamma" and
"brightness". The commit includes an awkward refactor for vo_opengl to
make it easier for vo_opengl_cb.
One problem is a logical race condition. The set of supported controls
depends on the pixelformat, which in turn is set by reconfig(). But the
actual reconfig() call (on the renderer) happens asynchronously on the
renderer thread. At the time it happens, the player most likely already
tried to set some controls for command line options (see init_vo() in
video.c). So setting this command line options will fail most of the
time, though it could randomly succeed. This can't be fixed directly,
because the player can't wait on the renderer thread, because the
renderer thread might already wait on the player.
|
|
|
|
|
| |
Not being able to use the 3x3 part of the matrix was annoying, so split
it into a float[3][3] matrix and a separate float[3] constant vector.
|
|
|
|
|
|
|
|
|
| |
Although the line count increases, this is better for making sure
everything is handled consistently for all users of the mp_csp_params
stuff.
This also makes sure mp_csp_params is always initialized with
MP_CSP_PARAMS_DEFAULTS (for consistency).
|
|
|
|
| |
It used to be central, but now it's just unneeded.
|
|
|
|
|
|
| |
The details of the non-linear transformation from/to BT.2020's constant
luminance system don't really make sense with any other gamma curve,
since changing the gamma curve completely breaks the chroma channels.
|
|
|
|
|
|
|
|
|
|
|
|
| |
vo_opengl was originally written against OpenGL 3 core, and it seems
GPUs/drivers supporting this are mostly sane. Later, it was made to work
with OpenGL 2.1 too. Lately we removed the requirement for RG textures,
and look, someone reported a problem with "lesser" Intel GPUs.
This commit does the same in vo_opengl what was added to vo_opengl_old a
long time ago.
Fixes #1383.
|
|
|
|
|
|
|
|
|
|
|
| |
Originally, this code was written to have full control over the OpenGL
state, rather than having to cooperate with unknown components by being
embeded like vo_opengl_cb is meant to be. As a consequence, it was
thought to be ok to setup a global binding (if the context is below
OpenGL 3.0, which guarantees VAOs).
This could break badly. Fix it by setting up and breaking the bindings
on entry/exit.
|
|
|
|
|
| |
The code was always uploading the 3D LUT (even of unused), as long as
vo_opengl was setting a icc-profile. This could crash with GLES 2.
|
|
|
|
|
|
| |
GL_ARB_debug_output provides a logging callback, which can be used to
diagnose problems etc. in case the driver supports it. It's enabled only
if the vo_opengl "debug" suboption is set.
|
|
|
|
|
|
| |
vo_opengl actually checks this in the context creation code already, but
it still increases robustness in case the requirements are changed
later.
|
|
|
|
| |
Fixes #1373.
|
|
|
|
|
|
|
|
|
| |
Whether we have texture_rg doesn't matter much anymore; the scaler
should be fine with this. But on ES 2.0, 1st class arrays are missing,
so even if filterable float textures should be available, it won't work.
Dithering (at least the "fruit" variant) will not work either, because
it uses floats.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently GLES 2 and 3 do not support this. (The implementations I
tested with were derived from desktop OpenGL and were not overly strict
with this.)
This is no problem; just use GL_RGBA and mangle the channels in the
shader.
Also disable direct support for image formats like IMGFMT_RGB555 with
GLES; at least some of them are not supported in this form, and the
formats aren't important anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 0e8fbdbd removed the rg_texture requirement from vo_opengl;
commit 541f6731 changed to a more convenient method. Both commits broke
vo_opengl_old in some ways. vo_opengl_old always requires GL_ALPHA for
single-channel texture, because it draws the OSD without shaders and by
using certain blend modes.
So we need to explicitly distinguish between vo_opengl and vo_opengl_old
in the OSD renderer, and force fixed texture formats for vo_opengl_old.
The other logic is specific to the internals of vo_opengl. (Although it
might be possible to get the same result by playing with the old GL
fixed-function functions in vo_opengl_old. But seems like a waste of
time.)
Fixes #1370.
|
|
|
|
| |
The parameter to default_tex_params() is always the same.
|
|
|
|
|
|
|
|
| |
Rather basic support. Almost nothing works, and even if it does, it's
bound to be inefficient (due to texture upload). This was tested with
the nVidia desktop binary drivers, which provide GLES 2 support only.
However, nVidia is not known to be very strict about OpenGL, and the
driver is very new too, so the vo_opengl code will have bugs too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is needed for GLES 2 support. GLES 2 doesn't support
GL_UNPACK_ROW_LENGTH, and we shouldn't even use this constant, since a
GLES implementation could raise an error.
So set it only if neccessary, and leave it in the default state
otherwise. This also smuggles in a ES 2 fallback for glUploadTex(),
and querying an extension relevant for ES 2. For the alignment state
(GL_[UN]PACK_ALIGNMENT) do the same for symmetry. All 4 states
(alignment/rows x pack/unpack) are now assumed to be in their initial
states by default.
Also redo the PixelStorei handling in the function table. I could rebase
this, but look at the commit time.
|
|
|
|
| |
There are probably many more which I overlooked.
|
|
|
|
|
|
|
|
|
|
|
| |
This was a nice trick to get the mpv colormatrix directly into OpenGL,
because the memory representation happened to match.
Unfortunately, OpenGL ES 2 doesn't have glUniformMatrix4x3fv().
Even more unfortunately, the memory representation is now incompatible.
It would be nice to change it, but that would mean getting into a big
mess.
|
|
|
|
|
|
|
|
|
|
|
|
| |
If GL_RED was not available, we used GL_ALPHA. But this is an
unnecessary complication, and it's easier to use GL_LUMINANCE instead.
With the latter, a texture will return the .r component set, and as long
as the shader doesn't look at the other components, the shader doesn't
need any changes.
Some of the changes added in 0e8fbdbd are now unneeeded.
Also, realign the entire gl_byte_formats_legacy table.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tested with MESA on software emulation. Seems to work well, although the
default FBO format in opengl-hq disables most interesting features. I
have no idea how well it will work on real hardware (or if it does at
all).
Unfortunately, some features, including playback of 10 bit video, are
not supported. Not sure what to do about this.
GLES 2 or 1 do not work.
|
|
|
|
|
|
|
|
|
| |
Remove the readback stuff; it was a useless mess.
Don't test GL_R16 as FBO. The intention was to measure the effective
bitdepth of the texture, except that it was never actually done.
(There's also a OpenGL function which is supposed to retrieve the
bitdepth, but we don't use that either.)
|
|
|
|
| |
Might be slightly more compatible too, and will make it work on GLES.
|
|
|
|
|
|
|
|
|
|
| |
I'm hoping this is generally more compatible, and it works with GLES.
This probably has not much of an effect on desktop GL. It also switches
only the default format for --vo=opengl, not --vo=opengl-hq.
"-hq" already uses GL_RGBA16, though since it's a sized format, the
story is a bit different, and it won't work on GLES either.
|
|
|
|
|
| |
Features not supported are disabled (although with a misleading error
message).
|
| |
|
|
|
|
|
| |
Possibly explains why some users got mysterious FBO errors on crappy
hardware.
|
|
|
|
|
|
|
|
| |
Obscure feature, and I've never heard of anyone using it.
The anaglyph effects can be reproduced with vf_stereo3d. The only thing
that can't be reproduced with it is "quadbuffer", which requires special
and expensive hardware.
|
|
|
|
| |
It was missing an indentation in some cases.
|
|
|
|
|
|
|
| |
I think that's expected; mpv shouldn't draw anything while no video is
active. This doesn't blend transparently, though.
Also document the vo_opengl_cb thing.
|
|
|
|
|
| |
This mainly affects the black bars that are drawn if the window and
video aspect ratios mismatch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds API to libmpv that lets host applications use the mpv opengl
renderer. This is a more flexible (and possibly more portable) option to
foreign window embedding (via --wid).
This assumes that methods like context sharing and multithreaded OpenGL
rendering are infeasible, and that a way is needed to integrate it with
an application that uses a single thread to render everything.
Add an example that does this with QtQuick/qml. The example is
relatively lazy, but still shows how relatively simple the integration
is. The FBO indirection could probably be avoided, but would require
more work (and would probably lead to worse QtQuick integration, because
it would have to ignore transformations like rotation).
Because this makes mpv directly use the host application's OpenGL
context, there is no platform specific code involved in mpv, except
for hw decoding interop.
main.qml is derived from some Qt example.
The following things are still missing:
- a way to do better video timing
- expose GL renderer options, allow changing them at runtime
- support for color equalizer controls
- support for screenshots
|
|
|
|
|
|
| |
I guess most problems with it have been fixed.
It's still slower than necessary, though.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not all filter sizes the shaders could handle were in the filter_sizes
list. The shader can handle any multiple of 4 (the sizes 2 and 6 are
special-cased to keep it simple).
Add all possible filter sizes, up to 64. 64 is ridiculously high anyway.
Most of the larger filter sizes are completely useless for upscaling,
but help with the fancy-downscaling option. (Although it would still be
more efficient to use cascaded scalers to handle downscaling better.)
I considered doing something less stupid than the hardcoded array, but
it seems this is still the simplest solution.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, the convolution scaler shader functions were pre-
instantiated in the shader file. For every filter size, a corresponding
function (with the filter size as suffix) had to be present.
Change this, and make the C code emit the necessary bits.
This means the shader code is much reduced. (Although hopefully it
doesn't make shader compilation faster - it would require a really dumb
compiler if it spends its time on dead code.)
It also makes it more flexible, which is the main goal.
The DEF_SCALER0 stuff is needed because the C code writes the header of
the shader, at a point where scaler macros are not defined yet.
|
|
|
|
|
|
|
|
|
| |
This was a microoptimization for small filters which need 4 or less
weights per sample point. When I originally wrote this code, using a 1D
texture seemed to give a slight speed gain, but now I couldn't measure
any difference.
Remove this to simplify the code.
|
|
|
|
|
|
| |
For better downscaling.
Maybe the list of filter sizes shouldn't be static...
|
|
|
|
|
| |
Seems it's actually buggy, beyond the problem that large filter sizes
are required.
|
|
|
|
|
|
| |
Also replace the weights calculations for 8/12/16 with the generic
weight function definition macro. (The weights 2/4/6 follow slightly
different rules.)
|
| |
|
|
|
|
|
|
| |
This wasn't done before because there was no advantage in "abstracting"
it. This changed, and putting this into its own files is better than
messing it into gl_common.c/h.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Always set the viewport on entry. The way the viewport is tracked is a
bit complicated in my opinion, and in fact it doesn't even reduce the
number of GL calls. Setting it on entry is actually redundant if video
covers the screen fully, because the handle_pass() unconditionally sets
it anyway, but avoiding it would complicate the cases gl->Clear() is
actually needed.
Add a fbo argument to gl_video_render_frame(). This allows you to render
into a FBO rather than the default framebuffer. It will be useful for
providing an API to render on an external GL context. (If that will
actually be added.)
|
|
|
|
|
|
|
|
| |
Seems like a waste not to print this.
Anyone with enough technical knowledge to have use for the exact error
can map the number back to the GL symbol, so don't bother to convert it
to a symbol.
|
|
|
|
|
|
|
| |
All of these are already the defaults.
One exception is glDepthMa |