If a (master) playlist contains a variant list entry without a
URI then during parsing of the next variant list entry we are
a) leaking the entry we're currently parsing (new_list), and
b) free'ing the pointer to the previous list entry (list) without
updating the pointer.
Hence when then adding the URI for the latest parsed entry, incorrect
information is stored, as the information is used from 'list' which
is not valid memory anymore, also leading to crashes.
Fix this by correctly storing the new variant list entry pointer
as needed.
https://bugzilla.gnome.org/show_bug.cgi?id=756861
Nicer to read, two lines of code less, and also the callback
function should've been a GCompareFunc that returns a gint
and not a boolean (it did work correctly, was just confusing).
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
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.
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)
Change the gstcvdilate.c file extension to cpp and add it into Makefile for
consistency with other elements of opencv and because Opencv not support C
language in new API 2.4.11.
https://bugzilla.gnome.org/show_bug.cgi?id=754148
Change the file extension to cpp and add it into Makefile for consistency
with other elements of opencv and because Opencv not support C language in
new API 2.4.11.
https://bugzilla.gnome.org/show_bug.cgi?id=754148
