e.g:
gstglcontext_egl.c:613:7: error: implicit declaration of function 'strcmp'
[-Werror=implicit-function-declaration]
if (strcmp (G_MODULE_SUFFIX, "so") == 0)
Currently float and int are supported by default. vec2, vec3, vec4
and mat4 are supported if graphene is used. Of course if one wants
to set custom uniforms they can also be set using the create-shader
signal.
We know that the gchar arrays contain at least one string. Furthermore,
g_strfreev() checks if the array is NULL and simply returns if it is.
Hence, there is no need to check if the array is empty before using
g_strfreev().
CID 1327412-1327415
In order to ensure the sequence_position will always be consistently updated,
store the current file duration.
This way, when we advance, we can always increment the position based on what
was previously outputted.
https://bugzilla.gnome.org/show_bug.cgi?id=752132
Store and copy input state fields when setting the
output state of the decoder. Avoids problems like
the framerate set by an upstream element being ignored
Related to:
https://bugzilla.gnome.org/show_bug.cgi?id=756563
One may not have an GstGLContext available or current in the thread where one
would need to update the shader. Support this by signalling create-shader
whenever the one-shot 'update-shader' is set to TRUE.
Implemented with videotestsrc ! glshader ! glupload ! gtkglsink
Errors on an invalid shader compilation are ignored however any error
provided by the glsl compiler is printed to stdout.
While technically, i is always 0 and *vertex_sources[i++] is equivalant
to (*vertex_sources)[i++]. Be future-proof in the case of code
moves/changes/etc.
CID 1327406
A GstGLShader is now simply a collection of stages that are
compiled and linked together into a program. The uniform/attribute
interface has remained the same.
Allows playlists that are missing the mediasequence information to
be correctly parsed. If the playlist was updated without reseting
the mediasequence it would constantly increase over subsequent updates,
leading to issues during playback.
For live streams, we want to make sure there's a certain distance
between the sequence to play and the last (earliest) fragment.
The problem is that it assumes there are at least 3 fragments in
the playlist, which might not always be the case (like in the case
of a server restarting and gradually adding fragments).
In order to avoid ending up with negative sequence numbers (which
will just loop forever), limit the new target sequence number to
the highest of:
* either the first sequence number of the playlist (fallback)
* or 3 fragments from the last one (standard behaviour)
