Since commit 32bf6f1e GLTextureUpload is broken because i965
doesn't report properly RGBA support. It could be possible to use RGBx
but GLTextureUpload only regotiates RGBA.
The simplest fix to this regression is adding synthetically the RGBA
format in the internal format map.
Instead of break at the fist foud quirk in the table, iterate all over
so it would be feasible to add several quirks for one driver per
element in array.
This mechanism comes from ffmpeg vaapi implementation, where they have
their own quirks.
A specific driver is identified by a substring present in the vendor
string. If that substring is found, a set of bitwise flags are store.
These flags can be accessed through the function
gst_vaapi_display_has_driver_quirks().
The purpose for this first quirks is to disable the put image try for
AMD Gallium driver (see [1]).
1. https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/72
FEI encoders are not actively mantained neither tested, and it is
using infrastructure that is changing and FEI is stopping this
effort.
Also it is required to rethink how FEI can be used in GStreamer.
The old way make the one config for each profile/entrypoint pair,
which is not very convenient for description the relationship
between them. One profile may contain more than one entrypoints
to within it, so a set like data structure should be more suitable.
Improve the mapping between va format and gst format. The new map
will be generated dynamically, based on the query result of image
format in VA driver. Also consider the ambiguity of RGB color
format in LSB mode.
When running several vaapi elements at the concurrently, at
initialization, there is a race condition when extractin the avaible
formats for images and subpictures.
This patch add a lock when the those arrays are filled.
https://bugzilla.gnome.org/show_bug.cgi?id=797039
Gobjectification for GstVaapiDisplay was almost done by the commit 185da3d1.
But still something breaking GObject code convention remains, which is
calling gst_vaapi_display_new() in each decendants.
This patch replaces it with gst_vaapi_display_config(), defined in private
header.
https://bugzilla.gnome.org/show_bug.cgi?id=796470
The function name was gst_vaapi_display_create_unlocked(), nonetheless
it wasn't called unlocked. In order to keep the semantics this patch
renames the gst_vaapi_display_create_unlocked() as
gst_vaapi_display_create(), removing the previous function
gst_vaapi_display_create().
https://bugzilla.gnome.org/show_bug.cgi?id=796470
This is, practically, a revert of commit dcf135e2.
The parent logic is useful for the EGL display, which is a decorator
of the real windowing subsystem (X11 or Wayland). Thus it is avoided
calling vaInitialize() and vaTerminate() twice.
https://bugzilla.gnome.org/show_bug.cgi?id=795391
This is a difference between the GObject API and the GstVaapi one: the
GValue passed to get a property value, in GObject has to be
initialized with g_value_init(), but in GstVaapi is has not.
In order to overcome this mismatch, this patch call g_value_init()
internally only in the passed one is not already initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=788058
Shuffled some code to avoid to find the properties descriptor in the
array twice, adding the internal functions _set_property() and
_get_property().
https://bugzilla.gnome.org/show_bug.cgi?id=788058
Redirect libva's logs to GStreamer logging mechanism. This is
particularly useful when VA is initialized, because it always logs
out the drivers details.
In order to achieve this a new helper function was added as a wrapper
for the vaInitialize() function.
https://bugzilla.gnome.org/show_bug.cgi?id=777115
