summaryrefslogtreecommitdiff
path: root/gst/vaapi/gstvaapipluginutil.c
AgeCommit message (Collapse)AuthorFilesLines
2020-07-31plugins: add gst_vaapi_caps_set_width_and_height_range()Víctor Manuel Jáquez Leal1-20/+28
This utility function is called internally by gst_vaapi_build_caps_from_formats() and can be used outside. This function sets frame size and framerates ranges. Also gst_vaapi_build_caps_from_formats() is simplified. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/374>
2020-07-29vaapipluginutil: simplify gst_vaapi_find_preferred_caps_feature()Víctor Manuel Jáquez Leal1-20/+10
Generalize the way how the preferred color format is chosen. Also use new GStreamre API as syntatic sugar. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/370>
2020-07-29plugin: util: rename h26x_encoder_get_profiles_from_caps().He Junyan1-4/+3
Change its name to encoder_get_profiles_from_caps(). Other codecs such as VP9 also needs to use this function. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/188>
2020-07-23plugin: util: add helper function build_template_coded_caps_by_codec()He Junyan1-0/+74
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>
2020-07-23plugins: utils: rename build_template_caps_by_codec.He Junyan1-2/+2
Rename the function build_template_caps_by_codec() to the name of build_template_raw_caps_by_codec(). It can be used to collect all raw video formats for encode's sink and decode's src. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/354>
2020-07-23vaapidecode: merge common profiles before setting size rangeVíctor Manuel Jáquez Leal1-0/+31
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>
2020-07-21plugin: util: Add the missing DMA buffer input in template caps.He Junyan1-1/+2
We pass the wrong parameter to gst_vaapi_build_caps_from_formats() and lose the DMA feature in caps. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/362>
2020-05-16plugins: util: Add a helper function to detect supported caps.He Junyan1-0/+105
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>
2020-05-16plugin: encode: extract the allowed caps maker as a helper function.He Junyan1-0/+59
Extract all logic about making caps for encode's sink as a standalone helper function. It can be reused. Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/315>
2020-04-26vaapipluginutil: Use GST_VAAPI_DISPLAY_TYPE_DRM for Mesa3D GBMHaihao Xiang1-0/+5
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>
2020-01-24plugins: renable Mesa Gallium driverVíctor Manuel Jáquez Leal1-0/+1
2020-01-19vaapih264enc: accept baseline as constrained baseline compatibleVíctor Manuel Jáquez Leal1-0/+2
2020-01-14plugin: util: add helper function to detect profiles in caps.He Junyan1-0/+63
2020-01-08plugins: add iHD driver in whitelistVíctor Manuel Jáquez Leal1-0/+1
2019-09-06pluginutil: Remove Mesa from drivers white listPhilippe Normand1-1/+0
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.
2019-08-20libs: remove surface's parent contextVíctor Manuel Jáquez Leal1-1/+1
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.
2019-04-11plugins: find the preferred format from right caps.Wangfei1-8/+19
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
2019-03-30vaapipluginutil: Fix #endif for USE_X11Danilo Spinella1-1/+1
2019-02-27plugin: if any caps in downstream, negotiate raw videoVíctor Manuel Jáquez Leal1-6/+18
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
2018-11-05plugins: Fix build error when GL is enabled while EGL is disabled.Junyan He1-10/+11
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>
2018-06-26pluginutil: downgrade unsupported driver loggingMathieu Duponchelle1-1/+1
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
2018-06-14libs: display: remove gst_vaapi_display_unref()Víctor Manuel Jáquez Leal1-3/+3
Use gst_object_unref() instead. https://bugzilla.gnome.org/show_bug.cgi?id=796470
2018-06-12plugins: fix compilationVíctor Manuel Jáquez Leal1-1/+1
gstvaapipluginutil.c:171:1: error: old-style function definition [-Werror=old-style-definition]
2018-06-12plugins: refactor gst_vaapi_create_display_from_gl_context()Víctor Manuel Jáquez Leal1-117/+153
gst_vaapi_create_display_from_gl_context() was a spaghetti mess. This path refactors it, in order to make the code readable and easy to follow. https://bugzilla.gnome.org/show_bug.cgi?id=796564
2018-06-12plugins: handle EGL when creating VAAPI display from glVíctor Manuel Jáquez Leal1-2/+20
If GstGL reports a EGL platform force to create a EGL display using the native EGL display. https://bugzilla.gnome.org/show_bug.cgi?id=795391
2018-06-12display: egl: create VaapiDisplayEGL with native EGL displayHyunjun Ko1-9/+32
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
2018-05-21plugins: guard GstGL codeVíctor Manuel Jáquez Leal1-0/+2
2018-04-26plugin: remove custom GstGL context handlingVíctor Manuel Jáquez Leal1-9/+24
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
2018-02-13plugins: update mesa's vendor string in whitelistVíctor Manuel Jáquez Leal1-1/+1
Mesa has updated its VA-API Gallium driver vendor string: https://cgit.freedesktop.org/mesa/mesa/commit/?id=5db29d62ce1fefa3f2ee6e4a4688576fde4bde4a This patch tries to cover both, the old and the new one. https://bugzilla.gnome.org/show_bug.cgi?id=793386
2017-10-20plugins: only dmabuf on srcpad if downstreamVíctor Manuel Jáquez Leal1-0/+2
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
2017-10-20vaapivideocontext: return the direction of gl contextVíctor Manuel Jáquez Leal1-1/+2
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
2017-10-16Avoid infinite loop when vaapi_create_display failsThibault Saunier1-1/+1
Which might be the case when using, for example, xvfb.
2017-10-03plugins: try to create test display in orderVíctor Manuel Jáquez Leal1-2/+22
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
2017-08-22plugins: include main gstgl headerVíctor Manuel Jáquez Leal1-0/+3
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
2017-08-01plugins: avoid dead code detectionVíctor Manuel Jáquez Leal1-2/+1
By using #elif macro, the static code analysis would stop to detect these lines as dead code. Also it is inforced the mutually exclusive environments.
2017-06-23vaapipluginutil: add support for DMABuf caps featureJulien Isorce1-0/+4
https://bugzilla.gnome.org/show_bug.cgi?id=755072 Signed-off-by: Julien Isorce <j.isorce@samsung.com> Signed-off-by: Victor Jaquez <vjaquez@igalia.com> vaapipluginutil: add support for DMABuf caps feature
2017-05-12plugins: remove par from caps negotiationVíctor Manuel Jáquez Leal1-2/+1
https://bugzilla.gnome.org/show_bug.cgi?id=781759
2017-04-27Revert "plugins: reject pixel-aspect-ratio with value 0/1"Víctor Manuel Jáquez Leal1-1/+1
This reverts commit c0be7b1890ea8da915a81ae82bc9f504aee7cc26.
2017-04-27plugins: reject pixel-aspect-ratio with value 0/1Víctor Manuel Jáquez Leal1-1/+1
Do not negotiate a pixel-aspect-ratio of 0/1. https://bugzilla.gnome.org/show_bug.cgi?id=781759
2017-04-11plugins: Fix usage of GST_GL_HAVE_WINDOW_* definesScott D Phillips1-4/+4
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
2017-03-03plugins: retry to create the VA displayVíctor Manuel Jáquez Leal1-3/+9
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
2017-01-27plugins: handle GL params through context queryVíctor Manuel Jáquez Leal1-4/+15
If the element instantiated the GL display and context, they should handle them too through the context query. https://bugzilla.gnome.org/show_bug.cgi?id=777409
2017-01-27plugins: create a GL context on certain conditionsVíctor Manuel Jáquez Leal1-0/+28
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
2016-11-03pluginutil: add gst_caps_is_video_raw()Víctor Manuel Jáquez Leal1-0/+15
2016-10-27docs: add missing long descriptionsVíctor Manuel Jáquez Leal1-0/+2
2016-07-29pluginutil: const params to gst_video_info_changed()Víctor Manuel Jáquez Leal1-1/+1
Since they are not modified, we should mark them as const.
2016-07-22vaapi: register only the available encodersVíctor Manuel Jáquez Leal1-0/+23
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
2016-07-22pluginutil: set GLX display typeVíctor Manuel Jáquez Leal1-1/+8
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
2016-07-22plugins: add gst_vaapi_driver_is_whitelisted()Víctor Manuel Jáquez Leal1-0/+48
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
2016-06-08pluginutil: add gst_video_info_force_nv12_if_encoded()Víctor Manuel Jáquez Leal1-0/+16
This lines repeat a couple times in the code, so it would be better to put it a helper function. https://bugzilla.gnome.org/show_bug.cgi?id=765435
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-31 21:06:24 +0000