Like build_template_raw_caps_by_codec(), this function can detect and
build the caps for specified codec based on the query of the profiles.
The result is coded caps such as video/x-h265, video/x-h264. The result
can be used as the template of encode's src or decode's sink.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/354>
The synthetic profiles, such as H264 baseline, H265 intra, etc. are
added at the end of processing all available VA profiles. This
generated an non-optimal caps for negotiation, since the synthetic
profiles don't have frame size ranges.
This patch adds those possible synthetic profiles when the associated
profile is processed, with its frame size ranges.
Now allowed sink caps are simpler.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/363>
This helper function iterate all profiles and entrypoints belong
to the specified codec, query the VAConfigAttribRTFormat and list
all possible video formats.
This function is used by each codec to get the template sink caps
(for encode) or src caps(for decode) at register time, when just
all possible formats are listed and no need to be very accurate.
So there is no context created for the performance reason. Most
codecs just use YUV kinds of formats as the input/output, so we do
not include RGB kinds of formats. User can specified more formats
in extra_fmts(For example, jpeg may need BGRA) if needed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/315>
We may build this plugin with window system support but run it without
window system. Without this patch, the following pipeline will trigger a
segfault when running it without window system.
gst-launch-1.0 filesrc location=input.264 ! h264parse ! vaapih264dec ! fakesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/319>
The Mesa Gallium driver is poorly tested currently, leading to bad user
experience for AMD users. The driver can be added back to the white list at
runtime using the GST_VAAPI_ALL_DRIVERS environment variable.
In commit 18031dc6 surface's parent context is not assigned because of
circular references. Since then (2013), there's has no issue with
subpictures attached to a context, the current only users of this API.
This patch cleans up all of related code with the unused surface's
parent context.
When the downstream has any caps, then raw video feature will
be used. At this situation, the preferred format should be chose
from caps which contains "vide/x-raw" feature instead of from
the fist allowed caps.
Fixes#142
When downstream has any caps, vaapi should not shovel vaapi featured
buffers, but rather plain raw video, assuming always the worst case
scenario (downstream cannot handle featured video memory but raw
system memory buffers).
This patch query the peer caps without any filter, to know if
donwstream just ask for any caps, if so jump to the color space
checking, otherwise do the caps intersection and continue with the
feature selection algorithm.
Fixes: #139
gl_platform_type in gst_vaapi_get_display_type_from_gl_env generate
unused-variable warning and may block build when Werror enabled.
Several functions like gst_vaapi_display_egl_new_with_native_display
have no prototype warning and link error when GL is enabled but EGL
is disabled. Fix all these warning and link error.
https://bugzilla.gnome.org/show_bug.cgi?id=797358
Signed-off-by: Junyan He <junyan.he@intel.com>
On systems with an Nvidia card, this error is output each time
the registry is rebuilt, which happens pretty often when
using gst-build as a development environment.
https://bugzilla.gnome.org/show_bug.cgi?id=796663
gst_vaapi_display_egl_new_with_native_display() has been broken since
it wasn't used.
Currently it's needed to call this API to create a display providing
the EGL display, so it could avoid duplicated calls to the native
display (eg. eglTerminate).
Signed-off-by: Victor Jaquez <vjaquez@igalia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795391
Instead of using our own context handling for looking for GstGL
parameters (display, context and other context), this patch changes
the logic to use the utility function offered by GstGL.
https://bugzilla.gnome.org/show_bug.cgi?id=793643
Set if source pad can handle dmabuf only if the GstGL context comes
from downstream.
It is possible to know that at two moments:
1\ In the case of GstGLTextureUpload caps feature is negotiated and
downstream pool reports back gst.gl.GstGLContext.
2\ When GstGLContext is found as GstContext from dowstream.
https://bugzilla.gnome.org/show_bug.cgi?id=788503
In function gst_vaapi_find_gl_context() add a direction parameter to
return back the direction where the GstGL context was found.
This is going to be useful when checking if downstream can import
dmabuf-based buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=788503
When creating the test display for querying capabilites, it try in
certain order: DRM, Wayland and finally X11. GLX nor EGL are tried
since they are either composited with X11 or Wayland.
The reason for this is to reduce the posibility of failure that could
blacklist the plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=782212
Instead including particular gstgl header files in a header file
that doesn't export a gstgl symbol, the main gstgl header file is
included in gstvaapipluginutil.c where the symbols are used.
https://bugzilla.gnome.org/show_bug.cgi?id=786597
When these definitions are false, they are undef in the
preprocessor, not a defined value of 0. When they are unset the
compile fails with:
'GST_GL_HAVE_WINDOW_WAYLAND' undeclared (first use in this function)
https://bugzilla.gnome.org/show_bug.cgi?id=780948
Particularly in GNOME Wayland, the negotiated or created GL context
defines a GLX environment, but VAAPI fails to create a GLX VA
display because there is no a DRI2 connection.
This patch retries to create the VA display if VA cannot create one
with the GL context parameters. Now using the old list of display
types.
This should also work in the case of systems with two GPU, when the
non-VAAPI has the graphics environment, and the VAAPI-enabled one
shall work headless.
https://bugzilla.gnome.org/show_bug.cgi?id=772838
If a GstVaapiDisplay is not found in the GStreamer context sharing,
then VAAPI elements look for a local GstGLContext in gst context
sharing mechanism ('gst.gl.local.context').
If this GstGLContext not found either then, only the VAAPI decoders
and the VAAPI post-processor, will try to instantiate a new
GstGLContext.
If a valid GstGLContext is received, then a new GstVaapiDisplay will
be instantiated with the platform, API and windowing specified by the
instantiated GstGLContext.
Original-Patch-By: Matt Fischer <matt.fischer@garmin.com>
https://bugzilla.gnome.org/show_bug.cgi?id=777409
In order to register only the available encoders, this patch queries the
created test VA display, which uses the currently used back-end (X11,
Wayland, DRM, …) on the used display device.
https://bugzilla.gnome.org/show_bug.cgi?id=724352
The function gst_vaapi_create_display_from_gl_context() cretes a
GstVaapiDisplay given a GstGLContext. But it didn't created a GLX VA display
when the GL platform was GLX, but a plain X11 VA display.
This patch fixes that, by querying the GL platform earlier.
https://bugzilla.gnome.org/show_bug.cgi?id=766206
Move some of the logic in gst_vaapi_plugin_base_driver_is_whitelisted() to a
new function gst_vaapi_driver_is_whitelisted(), in this way, it can be used
when registering the plugin's feature set with the test VA display.
https://bugzilla.gnome.org/show_bug.cgi?id=724352
