And provide home-made fallback for older GLib versions,
so that we can later find these and remove them when
we bump the GLib requirement (which is certainly going
to happen before 2.0).
https://bugzilla.gnome.org/show_bug.cgi?id=748495
It's better to just select some random variant playlist instead of stopping,
chances are that it's still continuing to work and we might just have to
select a different variant again later.
We should only refresh the currently selected variant playlist (if any,
otherwise the main playlist), not the main playlist. And only try to
refresh the main playlist if updating the variant playlist fails.
Some servers (Wowza) use the request of the main playlist to create a
"session", which is then part of the URI of the variant playlist and
also the fragments. Refreshing the main playlist would generate a new
session, and the server rate limits that usually. And after a few retries
the server just kicks us out.
Also as a side effect we now use the same downloader for all playlists, so
that we only have 2 instead of 3 connections to the server. And also
previously we just ignored the downloaded data from the main playlist that
the base class gave to us.
When the segment is very short it might be the case that the
typefinding fails and when finishing the segment hlsdemux would
consider the remaining data (pending_buffer) as an encryption
leftover.
This patch fixes it and makes sure an error is properly posted
if typefind failed by refactoring buffer handling to a function
and using it from the data_received and finish_fragment functions.
We also have to update the current_file GList pointer in the M3U playlist
client, otherwise we are just continuing playback from the current position
instead of seeking.
Variable hands is already checked to contain a value previously at the beginning
of the current block. There is no need to check again. This is logically dead code.
CID 1197693
Caps refcounting was all wrong in this function. Rewrote it and add some
comments to make it clearer.
Fix caps leaks with the
validate.file.glvideomixer.simple.play_15s.synchronized scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=747915
Signed-off-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
If old opencv1-style legacy include directory is available,
this change becomes purely cosmetic (maybe will compile a bit faster).
It becomes an FTBFS fix when opencv1-style include directory is missing
(possibly because opencv package maintainer decided not to pack it).
https://bugzilla.gnome.org/show_bug.cgi?id=747705
Fix a caps leak with the
validate.file.glvideomixer.simple.play_15s.synchronized scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=747915
Signed-off-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
'array_buffers' contain borrowed GstBuffer and so shouldn't have a free
function. 'frames' is the one containing GstGLMixerFrameData and so should use
_free_glmixer_frame_data as free function.
Fix GstGLMixerFrameData leaks with the
validate.file.glvideomixer.simple.play_15s.synchronized scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=747913
Signed-off-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
Fix a simple buffer overflow - 16 bytes isn't enough to hold
the string representation of a gulong on x86_64. I guess the
intent was to generate a 32 bit random key, so let's do that.
Only matters if anyone ever ports the sink to 1.x
https://bugzilla.gnome.org/show_bug.cgi?id=676524
