This crash could happen at any time a RTP and RTCP buffer arrived
simultaneously in ssrcdemux.
The problem was that sticky-event arriving while the rtp and rtcp pads
were being set up could arrive just too late to be included in the initial
forwarding.
The fix checks if the stickies have been sent on the srcpad about to be
pushed on, and if not sends them. It also blocks any stickes from
being forwarded *prior* to this happening, to avoid them arriving on
the srcpad multiple times.
Since the test loops 1000 times, this will make running under valgrind
take forever, so use the RUNNING_ON_VALGRIND variable to detect we
are running under valgrind, and reduce the loop-count to 2 in that case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/992>
We already declare the support of HEVC screen content extension profiles
in the profile mapping list, but we fail to generate the correct VA picture
parameters buffers. This may cause the GPU hang.
We need to fill the buffer of VAPictureParameterBufferHEVCExtension correctly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2255>
The function of gst_h265_get_profile_from_sps() is better than the
function gst_h265_profile_tier_level_get_profile() when we recognize
the profile of the stream, becaue it considers the compatibility.
It is also used by h265parse to recognize the profile. So it is
better to keep the same behaviour with the parse and other decoders.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2255>
We already declare the support of HEVC range extension profiles in
the profile mapping list, but we fail to generate the correct VA
picture and slice parameters buffers. This may cause the GPU hang.
We need to fill the buffer of VAPictureParameterBufferHEVCExtension
and VASliceParameterBufferHEVCExtension correctly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2255>
Missing RTP dep causes build error on Windows
webrtc-sendrecv.c.obj : error LNK2019: unresolved external symbol
__imp_gst_rtp_header_extension_set_id referenced in function start_pipeline
webrtc-sendrecv.c.obj : error LNK2019: unresolved external symbol
__imp_gst_rtp_header_extension_create_from_uri referenced in function start_pipeline
... and match required GStreamer to gst-example project version
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-examples/-/merge_requests/40>
If the converter configuration is set to not fill any borders, or if the
border fill color is not full opaque, then the pad has to be handled
as potentially transparent and can't be considered to obscure another
one.
This prevents pads from being wrongly skipped and doing alpha-blending
with uninitialized memory.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1172>
AV12 is an internally conceived format that is actually the
combination of NV12 and an alpha plane.
This format is to add to gstreamer's webM transparency support for
vp8 and vp9. To this end, two I420 streams are independently decoded
simultaneously for the actual content and the alpha plane respectively
and these are then combined into A420.
This patch adds GL conversion support so that it is possible to convert
from AV12 to RGBA for the purposes of rendering it on a display.
The reverse conversion is also supplied.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1152>
AV12 is an internally conceived format that is actually
the combination of NV12 and an alpha plane.
This format is to add to gstreamer's webM
transparency support for vp8 and vp9. To this end, two
I420 streams are independently decoded simultaneously for
the actual content and the alpha plane respectively
and these are then combined into A420.
Since most hardware decoders output NV12, this patch adds
NV12+A to make the same workflow possible.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1152>
VA-API HEVC decoding needs to known which is the last slice of a
picture, but slices are processed sequencially, so we know the
last slice until all the slices are already pushed into the
VABuffer array.
In order to mark the last slice, they are pushed into the
VABuffer array with a delay of one slice: the first slice is
hold, and when the second slice come, the first one is pushed
while holding the second, and so on. Finally, at end_picture(),
the last slice is marked and pushed into the array.
Co-author: Victor Jaquez <vjaquez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2246>
One of the main reasons of vaapidecodebin was because it mitigated the
possible surface exhaustion. But that problem is currently
solved. Nowadays, vaapidecodebin brings more problems than it
solves. Thus this patch demotes vaapidecodebin to NONE rank while
bumping PRIMARY + 1 the most common decoders.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/426>
