Slightly faster than using the dispmanx mess (perhaps to a large amount
due to the rather stupid C-only unoptimized ASS->RGBA blending code).
Do this by reusing vo_opengl's subtitle renderer, and vo_opengl's RPI
backend.
This detected whether an OpenGL context still provided legacy OpenGL if
the OpenGL version is modern (>= 3.0). This was actually only needed for
vo_opengl_old, because it relied on legacy functions. Since it's gone,
this code isn't needed either.
(Also, the removed comment about OpenGL 3.0 was wrong: you could just
query GL_CONTEXT_FLAGS and see if the forward compatible bit was set.)
Outputting the detected OpenGL features was useless and redundant with
the extension loading output.
Also, remove MPGL_CAP_3D_TEX from OpenGL(ES) 3.0. This block didn't
include the glTexImage3D function, so that was pointless and couldn't
have worked. The OpenGL 2.1 block does it correctly.
This is basically a hack for drivers which prevent the mpv DXVA2 decoder
glue from working if OpenGL is in fullscreen mode.
Since it doesn't add any "hard" new API to the client API, some of the
code would be required for a true zero-copy hw decoding pipeline, and
sine it isn't too much code after all, this is probably acceptable.
An attempt to get rid of the weird mix of callbacks that take either
struct vo or MPGLCopntext as parameter. This is not perfect, and the
API will probably change a bit until all other code is ported to it.
the main question is how to separate struct vo completely from the
windowing code, which actually needs vo for very little.
In the end, the legacy callbacks will be dropped.
Instead of having separate backends, make use of GLES a flag. This
reduces the number of backends and the resulting annoyances.
Also, nobody cares about using GLES, so there's no backward
compatibility either.
This requires FFmpeg git master for accelerated hardware decoding.
Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav
will also work.
Most things work. Screenshots don't work with accelerated/opaque
decoding (except using full window screenshot mode). Subtitles are
very slow - even simple but huge overlays can cause frame drops.
This always uses fullscreen mode. It uses dispmanx and mmal directly,
and there are no window managers or anything on this level.
vo_opengl also kind of works, but is pretty useless and slow. It can't
use opaque hardware decoding (copy back can be used by forcing the
option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend
is preferred over the X11 ones in case you're trying on X11; but X11
is even more useless on RPI.
This doesn't correctly reject extended h264 profiles and thus doesn't
fallback to software decoding. The hw supports only up to the high
profile, and will e.g. return garbage for Hi10P video.
This sets a precedent of enabling hw decoding by default, but only
if RPI support is compiled (which most hopefully it will be disabled
on desktop Linux platforms). While it's more or less required to use
hw decoding on the weak RPI, it causes more problems than it solves
on real platforms (Linux has the Intel GPU problem, OSX still has
some cases with broken decoding.) So I can live with this compromise
of having different defaults depending on the platform.
Raspberry Pi 2 is required. This wasn't tested on the original RPI,
though at least decoding itself seems to work (but full playback was
not tested).
With the previous commit, we have no need anymore to check a part of an
extension string (for ignoring a prefix). So check the extension string
properly, instead of just using the broken old strstr() method, which
could accidentally ignore prefixes or suffixes. Do this by extending
the check to whether the extension name is properly delimited by spaces
or string start/end.
Instead of somehow looking for the substring "_swap_control" and trying
to several arbitrary function names, do it cleanly. The old approach has
the problem that it's not very exact, and may even load a pointer to a
function which doesn't exist. (Some GL implementations like Mesa return
function pointers even the functions which don't exist, and calling them
crashes.)
I couldn't find any evidence that glXSwapInterval, wglSwapIntervalSGI,
or wglSwapInterval actually exist, so don't include them. They were
carried over from MPlayer times.
To make diagnostics easier, print a warning in verbose mode if the
function could not be loaded.
Drop support for GL_EXT_framebuffer_object. It has 2 problems: semantics
might be slightly different from the "proper" GL_ARB_framebuffer_object
extension (but is likely completely untested), and also our extension
loader is too dumb to load the same group of function pointers
represented by different extensions only once.
Even the lowest supported GL versions have arrays. This test was for
returning arrays from functions, which didn't work in lower GL versions,
but we don't need it anymore.
Check the scanf() return value, and don't continue if it doesn't find
both numbers (can happen with GLES 1.0). Also, some implementations can
return NULL from glGetString() if something is "broken".
gl_common.c contained the function loader (which is big) and additional
utility functions (not so big, but will grow when moving more out of
gl_video.c). Just split them. There are no changes other than some
modifications to comments.
PNG uses a different component order from GL_RGBA, so we upload the
surface using the "wrong" order, and then fix it in the shader. This
breaks if a sRGB texture (GL_SRGB) is used: the hardware will not touch
the alpha channel, which means that the B component is not adjusted,
leading to incorrect output.
Just remove the use of sRGB textures completely. It might lead to a
slight slow down when playing RGB with color management enabled, but
with this combination of obscure use case with minor performance impact
it's not a meaningful disadvantage.
Unfortunately this also means that alpha is handled incorrectly with our
own color management, but alpha isn't so important and can be fixed
later. (0.0 and 1.0 are unchanged by the transfer function, so it
"mostly" works.)
Fixes#1530.
This fixes compatibility with GLES 2.0 and makes the code a bit neater
in general. It also properly forces indirect scaling for subsampled
video regardless of the lscale setting.
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.
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.
While there's no actual need to get rid of these, I want to make sure
nobody actually needs this stuff, and removing it is the best way to
get to know this. We still can revert this commit if it turns out there
is a significant need for this stuff.
The final goal is removing vo_opengl_old entirely. Add a warning, which
basically announces this intention.
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.
Using them reduces state change, since now at least vo_opengl_cb has to
setup/break the vertex array bindings on every frame if no VAOs are
available.
This reverts the VAO related change in commit f64665e7.
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.
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.
There are probably bugs with GLES support; also, if you somehow get GLES
instead of desktop GL on a desktop computer, something else is probably
wrong. So I see no point in using this automatically. We first need to
find out whether the GLES support works on real hardware, and whether
it is useful at all.
Apparently GLX can do this, so using EGL is not strictly required.
This code tries to create an ES context if creating a desktop GL context
fails. Also, a "x11es" backend for forcing ES (instead of desktop GL) is
added, mostly for testing and debugging.
Before this, missing additional but required functions were ignored.
("Main" functions still made it error out.) But we pretty much expect
that these are present on a given version level, and only an extremely
buggy OpenGL implementation would not do this.
Involve detection of software renderers in the probing properly. Other
VOs could handle probing also more gracefully, and e.g. produce less
noise if an API is unavailable. (Although other than the OpenGL VOs,
only vo_wayland will.)
Now the "sw" suboption for vo_opengl[_old] is strictly speaking not
needed anymore. Doing "--vo=opengl" disables the probing logic, and will
always force it, if possible.
Includes some simplifications as well.
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.
Previously, this was sort of messed together with desktop OpenGL
loading. Add explicit support for ES, and clean up the mess. Also sort
the function arrays alphabetically (at least most of them).
In some cases, add functions to multiple sections. This keeps the number
of sections down.
Don't check for GL_ARB_vertex_array_object. This feature must be used in
OpenGL 3 core, while it may be not available at all in earlier versions,
and not using it if it's available as extension only has no advantages.
This commit also considers GLES 2, because actual support for it will be
added with a later commit.
Also get rid of some MPGL_VER() uses (see some commits ago).
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.
OpenGL 3.0 has the weird situation that it's "hard" to detect whether
legacy GL is really present. Since we pretend that we have OpenGL 3.0 if
we use GLES, it was assuming legacy GL is available.
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.
wm4
Marcin Kurczewski
Niklas Haas