Since commit a79a756b79 we could change to ignore-pcr automatically at 500ms
into a live stream when no PCR is seen by then. However the stream counting in
program change detection was wrongly considering ignore-pcr programs to have a
separate PCR PID, even though we are actually ignoring the PCR PID completely,
resulting in an erroneous program switch getting triggered from the different
stream count. This in turn would send an EOS and switch out the pads for what
actually is still the same program, while we intended to simply apply a
workaround for broken encoders.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3089>
Check that `self` and `self->callback` are defined. `self` can be set to
`NULL` in `remove_listener`, and `self->callback` can be set to `NULL`
inside `gst_amc_surface_texture_jni_set_on_frame_available_callback`.
This can cause a segfault since the Java object can outlive the C
object, and call the callback after `remove_listener` is called.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3056>
Current default G_MAXINT is not a correct value under any circumstances.
This creates an issue with screen capture, during which we currently do
not get any framerate info causing G_MAXINT to show up, where elements
downstream can possibly misbehave - for example, `vtenc` causes
a kernel panic.
Replace with 30/1 to avoid such scenarios.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2946>
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/2904>
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/2881>
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/2881>
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/2876>
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/2818>
There might be a sequence of event and buffer flow:
- Got stream-start/caps/segment events
- Got flush events
- And then buffers with a new segment event
In the above case, stream-start and caps event might not be reached to
peer proxysrc if peer proxysrc is not ready to receive them.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2774>
Gallium drivers historically have reported strange dmabuf sizes, from always
zero to the whole frame (multiple fds). The simplest solution is to use lseek
SEEK_END to get the prime descriptor size.
Also the allocator raises a warning if both values differ in order to report
it to driver.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2657>
Some problematic H265 stream may miss the reference frame in the DPB,
and get some message like: "No short term reference picture for xxx".
So there may be empty entries in ref_pic_list0/1 when passing to
decode_slice() function of sub class. We need to check the NULL pointer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2647>
This allows the reception of streams that don't exactly match
the codec preferences. In particular, the ssrc in the codec preferences
is local sender SSRC, the other side is expected to send a different SSRC.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2632>
Intel DXVA driver crashes sometimes (from GPU thread) if
ID3D11VideoDecoder is released while there are outstanding view objects.
To make sure the object life cycle, holds an ID3D11VideoDecoder refcount
in GstD3D11Memory object.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2513>
d3d11screencapture can miss a cursor shape to draw or draw an outdated cursor shape.
- AcquireNextFrame only provides cursor shape when there is one update
- current d3d11screencapture skips cursor shape when mouse is not drawn
So, if a gstreamer application uses d3d11screencapture with cursor initially not drawn
"show-cursor"=false and then switches this property to true, the cursor will not be
actually drawn until AcquireNextFrame provides a new cursor shape.
This commit makes d3d11screencapture always update the cursor shape information, even
if the mouse is not drawn. d3d11screencapture will always have the latest cursor shape
when requested to draw it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2488>
