Nouveau driver currently only exposes postproc entry. But
vaapidecodebin is registered independent if there are decoders or not,
exposing a segmentation fault.
This patch removes the encoder/decoder/codec arrays if no entries are
found, and if no decoders are found vaapidecodebin is not
registered. Also for vaapipostproc if no postproc entry is found.
Also, if general decoder, used by vaapidecodebin, doesn't have a sink
pad string, don't register the glib type.
Fixes: #1349
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2865>
Without this change cleanup function for g_autoptr is not defined for
GstPlayMediaInfo, GstPlaySignalAdapter, GstPlayVideoRenderer,
GstPlayVideoOverlayVideoRenderer and GstPlayVisualization. Cleanup
function was defined in gstplay.h, but missing in other header files.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2888>
When stopping the element, make sure the pad task
is stopped before destroying the part readers.
Closes a race where the pad task might access
a freed pointer.
Also add a guard against this sort of thing
by holding a ref to the reader in the pad loop.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2901>
When playing live, it's possible that one stream reaches
the end of the available playback window and goes to sleep
waiting for a manifest update, and the manifest update
introduces a new period. In that case, the sleeping
stream needs to wake up and go 'properly' EOS before we
can advance the input to the new period.
Accordingly, make sure that a stream's last_ret value
is not marked as EOS if it's just sleeping waiting for a live
manifest update.
Also fix the output loop to go back and re-check if it's
time to switch to the next period after dequeuing and
discarding an EOS event.
https://livesim.dashif.org/livesim/periods_20/testpic_2s/Manifest.mpd
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2895>
The parent refcount is of the *transformed* buffer, not the input
buffer.
Also update the docs to clarify that @transbuf is the transformed
buffer, and not the buffer on which a transformation is being
performed.
Due to this bug, modifying the structure of a meta that has been
copied to another buffer fails with:
gst_structure_set: assertion 'IS_MUTABLE (structure) || field == NULL' failed
Add a test for the same.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2890>
Newer compilers ( clang 15 ) have turned stricter and errors out instead
of warning on implicit function declations
Fixes
gstssaparse.c:297:12: error: call to undeclared library function 'isspace' with type 'int (int)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
while (isspace(*t))
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2879>
Ideally new() functions should simply call g_object_new() and not much
else, so let's do that here and handle all the construction properly in
a GObject way.
Now a play object created via g_object_new() is actually usable.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2880>
Ideally new() functions should simply call g_object_new() and not much
else, so let's do that here and handle all the construction properly in
a GObject way.
Now a player object created via g_object_new() is actually usable.
In addition, also fix the video-renderer property so that reading it
returns an object of the correct type.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2880>
That is, get rid of unnecessary and wrong special-casing.
This could always use gst_rtsp_url_get_request_uri_with_control() but as
we only have the control base URI as string it is easier to just call
gst_uri_join_strings().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2868>
This was showing up as a memory leak in GTK's
gstreamer media backend:
40 bytes in 1 blocks are definitely lost in loss record 18,487 of 40,868
at 0x484586F: malloc (vg_replace_malloc.c:381)
by 0x50D5278: g_malloc (gmem.c:125)
by 0x50EDBA5: g_slice_alloc (gslice.c:1072)
by 0x50EFBCC: g_slice_alloc0 (gslice.c:1098)
by 0x51F2F45: g_type_create_instance (gtype.c:1911)
by 0x51DAE37: g_object_new_internal (gobject.c:2011)
by 0x51DC080: g_object_new_with_properties (gobject.c:2181)
by 0x51DCB20: g_object_new (gobject.c:1821)
by 0x9855F86: UnknownInlinedFun (gstplayer-wrapped-video-renderer.c:109)
by 0x9855F86: gst_player_new (gstplayer.c:579)
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1374
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2875>
Otherwise we won't send the protection packets for the last few
packets when a stream ends.
Also send EOS on the FEC src row pad immediately, and on the FEC src
column pad after draining is complete. This makes it so that the FEC
src pads on rtpbin behave the same way as the RTCP src pads on rtpbin
when EOS is received on the send_rtp_sink pad.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2863>
When a new segment event arrives, it immediately updates
the current stored segment, which was used for calculating
the running time of the current text buffer for every
passing video frame. This means a segment that arrives
after the text buffer might get used to (mis)calculate
the running times subsequently.
Instead, calculate and store the right running time
using the current segment when storing the buffer. Later
the stored segment can get freely updated.
This fixes the case where pieces of video and text streams
are seamlessly concatenated and fed through the text overlay.
Previously, it could lead to the current text buffer suddenly
have a massive running time and blocking all further input.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2802>
Radeon mesa gallium driver has a bug which adds P010_10LE sink caps
format. This patch removes formats which arent 420 chroma.
gst_caps_set_format_array() wasn't used because the fix traverse
several structures with potential different formats.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2844>
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>
GLib's GRecMutex will allocate another heap memory for CRITICAL_SECTION
struct and g_rec_mutex_lock/g_rec_mutex_unlock use WIN32 APIs actually.
We don't need such intermediate function calls and redundant heap allocation.
Just call WIN32 APIs directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2845>
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>
