Rationale is to allow the manifest update task to continue running while
seeks are occurring. Otherwise, if the user reliably performs a seek
before the manifest is updated, then as the manifest task is reset on
seeks (and thus the time to wait between manifest updates), the manifest
would never be updated.
This fix makes the manifest update task free-running and continously
update even during seeks.
Some actions (Qos, reconfigure, ...) might take place before we finish pushing out flush_start.
One problem would be that:
1) The QOS handling in adaptivedemux takes the MANIFEST LOCK
That QOS event comes from basesink with its PREROLL_LOCK taken
2) FLUSH_START is sent from adaptivedemux with the MANIFEST_LOCK taken and the basesink flushing handler needs to take the PREROLL_LOCK
=> deadlock
https://bugzilla.gnome.org/show_bug.cgi?id=781320
meson's configure_file emits only a comment like /* #undef ... */
for values which are unset in the configuration_data. For
gstglconfig.h, this differs from the autotools build where the
preprocessor definitions are always either 0 or 1. So loop over a
list of variables to set to zero as default.
Also sync up the gstglconfig.h.meson file with the additional
macros defined by the autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=781043
Windows aren't always removed in time, and it turns out to be
very, very hard to remove a window in a way that's not racy and
not deadlocky. Since the window itself doesn't leak, freeing
the list on object destruction is enough.
https://bugzilla.gnome.org/show_bug.cgi?id=781018
At the moment that demux is waiting manifest update, the target sequence
of fragment was advanced already. So, checking stream_has_next_fragment()
means looking for the next fragment of target fragment.
This might cause unexpected buffering if each fragment has
large duration and manifest is listing only limited number of fragments.
https://bugzilla.gnome.org/show_bug.cgi?id=780494
The GstGLFramebufferClass struct is typedeffed in
gstgl_fwd.h, and having a duplicate elsewhere is
breaking the cerbero build on my OSX machine,
even though it seems to be working in CI.
When entering this code path, we know that:
We received EOS on this pad.
We consumed all its buffers.
In any case, we want to replace vaggpad->buffer with NULL,
otherwise we will end up mixing the same buffer twice.
https://bugzilla.gnome.org/show_bug.cgi?id=781037
If set, the parent is used to proxy need-context messages from
uridownloader's http source in order to get cookies/headers
from the pipeline.
Based on a patch from Philippe Normand
https://bugzilla.gnome.org/show_bug.cgi?id=726314
When there are new pads pending for a bitrate switch, don't allow
EOS through from the old streams. It will be sent when the new pads are
ready, just before the old streams are removed.
This fixes racy bitrate switching with hlsdemux in urisourcebin
where old pads EOS before new pads appear and the entire pipeline can
EOS if those propagate fast enough
libgstgl has a dependency on libgstallocators starting with:
ed1e4c1 glupload: Add support for Vivante DirectTexture uploads
The dependency wasn't stated in the Makefile, so the build could
occasionally fail if you got unlucky with the ordering of build
steps.
https://bugzilla.gnome.org/show_bug.cgi?id=780330
In commit
> 956c4d0 gl/format: use our own GL format enum's instead of gstvideo's
the name and return type of gst_gl_format_from_video_info changed,
but some returns of the old type were missed. Here they are
updated to the correct type.
https://bugzilla.gnome.org/show_bug.cgi?id=780064
gst_player_set_uri_internal shouldn't free suburi which maybe set
by user to load external subtitle before start play. It just need
reset playbin's subutri property to NULL no matter if there was a
previous one or not.
https://bugzilla.gnome.org/show_bug.cgi?id=779453
All code interacting with Objective-C objects should now use Automated
Reference Counting rather than manual memory management or Garbage
Collection. Because ARC prohibits C-structs from containing
references to Objective-C objects, all such fields are now typed
'gpointer'. Setting and gettings Objective-C fields on such a
struct now uses explicit __bridge_* calls to tell ARC about
object lifetimes.
https://bugzilla.gnome.org/show_bug.cgi?id=777847
For duration queries on live streams, adaptivedemux ignores the query.
The problem then is that the query is answered by the downstream
qtdemux element, with the duration of the currently passing fragment.
This commit changes the behaviour of adaptivedemux to answer the duration
queries for live streams, returning GST_CLOCK_TIME_NONE.
https://bugzilla.gnome.org/show_bug.cgi?id=753879
