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>
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>
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>
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>
This is based on gtksink, but similar to waylandsink uses Wayland APIs
directly instead of rendering with Gtk/Cairo primitives.
Note that the long term plan is to move this into the existing extension
in `-good`, which requires the Wayland library to move the as well.
For this reason several files like `gstgtkutils.*` and `gtkgstbasewidget.*`
are straight copies and should be kept in sync.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1515>
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>
Depending on device feature level, d3d11 runtime can support
ID3D11Fence which is equivalent to ID3D12Fence.
Waiting using fence has performance-wise benefit over pulling
ID3D11Query status. If ID3D11Fence is not supported by device,
then ID3D11Query will be used instead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2790>
It may happens that bitstream doesn't provided SPS in decoding order
(like in VPSSPSPPS_A_MainConcept_1 conformance test file).
To be sure that the decoder got the correct SPS parameters process
SPS just before start decoding the frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2575>
