Newer Windows issue this warning if we send metadata with each picture:
DXGI WARNING: IDXGISwapChain4::SetHDRMetaData: Redundant invocation on unchanged
metadata could result in presentation performance inefficiency. [ MISCELLANEOUS WARNING #295: ]
OS/2 socket APIs use int not unsigned int in place of socklen_t. As
a result, compilation is stopped at function call requiring socklen_t *
because of type mismatch between int * and unsigned int *.
Signed-off-by: Steve Lhomme <robux4@ycbcr.xyz>
Mismatching pointers are usually a result of using the incorrect pointer and
might trigger crashes.
Missing initializers are useful for structures of callbacks, to make sure a new
callback is not missing by accident. It's always possible to put NULL, on
purpose, knowingly.
Both flags produce no error on win32/win64 with clang or gcc. But they cannot
be set globally outside of the build script as many contribs will likely fail
these tests and we shouldn't refuse/patch a contrib just for that.
I have been compiling with these flags for weeks without issues. It helped find
some issue (48442d3536) that were pushed
unnoticed without these checks.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Steve Lhomme
Francois Cartegnie
Marvin Scholz
KO Myung-Hun
Hugo Beauzée-Luyssen
Quentin Chateau
Romain Vimont