When returning GST_ADAPTIVE_DEMUX_FLOW_RESTART_FRAGMENT
for the first segment data, we might need to requeue the
header.
This was leading to occasional prerolling stalls on
HLS live streams with renditions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2849>
Make sure gst_adaptive_demux_loop_cancel_call()
never tries to operate on an invalidated main context. Make
sure to clear the main context pointer while holding the lock,
and to check it in gst_adaptive_demux_loop_cancel_call()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2847>
Media playlist updates and fragment downloads happen in an interleaved
fashion. When a media playlist update fails *while* a segment is being
downloaded, this means we lost synchronization.
Properly propagate and handle this
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2839>
There is now only a single case where we setup the initial playlist to 0, which
is for the very first variant stream.
Rendition streams will have the initial playlist "synchronized" against the
variant stream media playlist.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2839>
Loss of synchronization happens when the updated media playlist has no
relationship to the previous ones. This could happen because of network issues,
server issues, etc...
When this happens, we take no chance and "reset" ourselves so that we can "seek
back to live" against the new updated playlists.
Since this happens at the "media playlist update" level, make sure the custom
flow return is propagated up.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2839>
We are already in the main scheduler thread, therefore we can do the "seek back
to live" directly. This also avoids other pending actions to take place.
Also handle the loss of sync when doing manifest updates.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2839>
Close some race conditions in switching to the next period,
by ensuring the tracks are completely drained first and by
not outputting EOS events to the output source pad
if there is another period pending.
Fixes Manifest_MultiPeriod_1080p.mpd some more.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2838>
Before sending EOS, update the period's has_next_period
flag and/or create the next period. This closes a race
where the output loop might receive the EOS event
and either push it downstream (causing premature EOS),
or receive it and try and switch to the next period
before that period is completely set up.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2838>
When combining stream flows, ignore streams that
are not selected, instead of checking whether
the stream state has changed yet.
Fixes another issue with dashdemux2 where it fails to
change to the next period when playing content with
several video, audio and text streams, as with
Manifest_MultiPeriod_1080p.mpd when seeking to 730
just before the end of the first period.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2838>
With the 2.72 release, glib-networking developers have decided that
TLS certificate validation cannot be implemented correctly by them, so
they've deprecated it.
In a nutshell: a cert can have several validation errors, but there
are no guarantees that the TLS backend will return all those errors,
and things are made even more complicated by the fact that the list of
errors might refer to certs that are added for backwards-compat and
won't actually be used by the TLS library.
Our best option is to ignore the deprecation and pass the warning onto
users so they can make an appropriate security decision regarding
this.
We can't deprecate the tls-validation-flags property because it is
very useful when connecting to RTSP cameras that will never get
updates to fix certificate errors.
Relevant upstream merge requests / issues:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2214https://gitlab.gnome.org/GNOME/glib-networking/-/issues/179https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/193
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2494>
The caps negotiation should respect the selected method to the test pipeline below works properly.
gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=600 ! videoflip method=clockwise ! video/x-raw,width=600,height=320 ! fakesink
Signed-off-by: Adrian Fiergolski <adrian.fiergolski@fastree3d.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2803>
In the trick mode, driver may queue a valid buffer follow by an
empty buffer which has no valid data to indicate EOS.For the empty
buffer whose memory is multi-plane, need to resize it before
unreference it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2731>
In file included from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/gstreamer-1.0/gst/gl/gstglfuncs.h:87,
from ../gst-plugins-good-1.20.3/ext/qt/qtglrenderer.cc:14:
../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/gstreamer-1.0/gst/gl/glprototypes/gstgl_compat.h:40:18: error: conflicting declaration 'typedef void* GLsync'
40 | typedef gpointer GLsync;
| ^~~~~~
In file included from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtGui/qopengl.h:127,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/qsggeometry.h:44,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/qsgnode.h:43,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/qsgrendererinterface.h:43,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/qquickwindow.h:44,
from ../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtQuick/QQuickWindow:1,
from ../gst-plugins-good-1.20.3/ext/qt/qtglrenderer.cc:6:
../gstreamer1.0-plugins-good/1.20.3-r0/recipe-sysroot/usr/include/QtGui/qopengles2ext.h:24:26: note: previous declaration as 'typedef struct __GLsync* GLsync'
24 | typedef struct __GLsync *GLsync;
| ^~~~~~
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2763>
* When dealing with rendition streams, we attempt to synchronize the media
playlist against the variant stream. This helps with speeding up the correct
initial fragment search and avoids issues when streams at activated at a much
later time.
* Also add checks for variant stream existence before attempting to use them
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2679>
When updating playlists, there is a possibility that the playlists don't
perfectly align, but the last entry of the previous playlist is *just* before
the first entry of the new playlist.
In those cases, we still can transfer the timing information from one playlist
to another, but we do not want to return that segment as being the matching one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2679>
When matching playlists, there is a possibility that rendition streams will not
have been updated in time (for example because that stream started later, or
playback was paused). This would cause several playback failures and seeking
failures.
In order to still fall back on our feet, attempt to synchronize that rendition
playlist against the current variant playlist. This will attempt to match the
stream time using SN/DNS/PDT/...
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2679>
If we have been updating too slowly and have gone out of the current live
window, inform the baseclass accordingly.
This is different from the case where we have been updating quicker than what
the server provides.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2679>
