The helper fragment_shaders.c was responsible to create the whole
fragment shaders. For now on, make it responsible to generate only the
piece of GLSL code necessary to access the input picture (i.e. to
implement vlc_texture()).

Make the renderer create its own fragment shader, using the
vlc_texture() function generated by fragment_shaders.c.

Extract a fragment shader function to provide the pixel color of a
picture from pictures coordinates.

Concretely, it replaces:

    void main(void) {
     vec3 pic_hcoords = vec3(PicCoords, 1.0);
     ...
     gl_FragColor = result * FillColor;
    }

by:

    vec4 vlc_texture(vec2 pic_coords) {
     vec3 pic_hcoords = vec3(pic_coords, 1.0);
     ...
     return result * FillColor;
    }
    void main() {
     gl_FragColor = vlc_texture(PicCoords);
    }

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

The video_format_t parameter of vout_display_opengl_Display() is not
used anymore. Remove it.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

Texture paddings were computed in _Display(), while the picture format
is known in _Prepare().

This will allow to remove the video_format_t parameter of _Display().

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

It will be modified to depend on static functions. Move it below them.

This will make the diff more readable.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

After the previous changes, two successive loops iterating tex_count
times can now be merged into one.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

The multiview mode (stereo) was applied by changing the texture
paddings to crop only the left eye.

The problem is that these texture paddings are specific to the input
picture, while the stereo mode is specific to the renderer, which should
be independent of the input picture.

To separate these concerns, apply the stereo mode using a matrix to
transform the texture coordinates from the renderer.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

Apply all texture coordinates transformation in the fragment shader.

This is necessary to be able to implement a renderer independent of the
input picture (i.e. without even knowing the details) by using a single
GLSL function "vlc_texture(vec2 pic_coords)".

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

Now that the coordinates are independant of paddings (which are
transmitted via a separate transform matrix), there is no need to
recompute them when the paddings change.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

A picture is stored in OpenGL textures (one per plane), possibly with
padding (the texture may be larger than the actual picture).

The conversion from picture coordinates to texture coordinates (which
takes the padding into account) was applied on the input coordinates,
before the vertex shader. As a consequence, the vertex shader received
one vector of input texture coordinates per plane (the padding is not
necessarily the same for all the planes):

    (before this commit)

   picture   texture
   coords    coords        (attributes)      (varyings)
          (1 per plane)

             (x0, y0) --> MultiTexCoord0     TexCoord0     fragment
   (x,y) --> (x1, y1) --> MultiTexCoord1 --> TexCoord1 --> shader
             (x2, y2) --> MultiTexCoord2     TexCoord2

This poses a problem to separate chroma conversion from rendering: the
renderer should be able to retrieve a pixel color in picture
coordinates, regarless of the input format or padding.

To solve this issue, pass the picture coordinates instead of the texture
coordinates as attribute, and initialize uniform matrices to convert
from picture to texture coordinates for each plane directly in the
fragment shader:

    (after this commit)

   picture
   coords    (attribute)     (varying)

   (x,y) --> PicCoordsIn --> PicCoords --> fragment shader
                                             ^^^
                                             |||
                             TexCoordsMap0 --'||
                (uniforms)   TexCoordsMap1 ---'|
                             TexCoordsMap2 ----'

Note that this also changes the multiplication order of
(non-commutative) matrices, from (semantically):

    TexCoords = Orientation * TexCoordsMap * PicCoords

to:

    TexCoords = TexCoordsMap * Orientation * PicCoords

The latter is the correct one: the orientation defines how the input
picture is rotated, so it must apply to picture coordinates, regardless
of the actual coordinates in the texture.

As a side effect, BuildRectangle, BuildSphere and BuildCube are now
independant of both the number of planes and any texture padding.

For now, TexCoordsMap is computed from the renderer, but the goal is to
move it to a separate component (a "sampler").

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

Expose in vlc_gl_api whether it supports non-power of 2 textures.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

The fields is_gles and glexts (extensions) are not specific to interop,
and may be useful without an interop instance.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

Pass the whole structure (which will have new fields soon) to interop
and renderers, instead of the virtual table only.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

Use a separate component for storing OpenGL API-specific utils (for now,
only the vtable).

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

The opengl_vtable_t is used only if USE_OPENGL_ES2 is not defined.
Declare it inside the ifdef-block.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

Expose a single function to create an OpenGL program for a vertex shader
and a fragment shader.

This simplify the code, and handles the errors in the same way
everywhere.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Romain Vimont authored 5 years ago and Jean-Baptiste Kempf committed 5 years ago

OpenGL ES 2 does not necessarily define all these constants, but
supports them as extensions.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

It's expected to be in extras/tools

If the display fails to open and a libvlc application request the media
player to pause, it will assert although you don't need a display to
pause the video output.

priv_control must be NULL if created from a module.

Tested cross compiling for armv7 with this docker image
registry.videolan.org/vlc-debian-raspbian:20200213203125

gcc is stupid and doesn't use the folder relative to the file that loads the
include.

install_subtargets is equivalent to all three calls

The pathes generated are too long for msys

The pkg-config in msys overwrites/loses the PKG_CONFIG_PATH but not the
PKG_CONFIG_LIBDIR, so we set the PKG_CONFIG_LIBDIR (which is empty anyway) to
the value of PKG_CONFIG_PATH.

The driver may lie about its conversion capabilities (like Y410 to X8R8G8B8 on
Intel) when DXVA-HD works correctly. So we use this option by default.

The gnutls version we build requires a minimum nettle version of 3.4.1.

When cross-compiling the PKG_CONFIG is either forced by the environment, to find
what the user wants us to find, or we detect a usable one and set common system
pathes where we might find usable packages.

It's possible to disable the use of PKG_CONFIG like it used to be by setting
PKG_CONFIG=false in the environment, when building contribs.

We make sure PKG_CONFIG_LIBDIR is used when we set its value.

The contrib path is automatically added for contribs and for vlc.

We still need a proper environment to build VLC. We set the same values used in
contribs. They should always match. It could be removed once it's move into
configure.ac.

It uses the same detection for bogus Debian $TRIPLET-pkg-config.

And use it for all contribs detection and building.

on Debian, the x86_64-w64-mingw32-pkg-config may exist and run but give an
error when actually trying to find a package because the package architecture
doesn't exist for that target. So we have to test it thoroughly.

If we revert to pkg-config when cross-compiling we also force the
PKG_CONFIG_LIBDIR, otherwise we leave it untouched as the system/environment may
provide more that we know.

Both /usr/$(HOST)/lib/pkgconfig and /usr/lib/$(HOST)/pkgconfig variants exist,
at least on Debian.

So it's used by make, meson and CMake.
No need to set it in the CMake toolchain file anymore.

At least widl/windres are Windows tools that are not defined in GNU Make on
msys or Linux.

Neither ranlib or strip have implicit values either when I tested with make -p.

In order to match with vlc_input_decoder_t.