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
Split the vaapidecode to all the supported codecs with the format
vaapi{codec}dec.
vaapidecode is stil registered as a GObject type, but not as a
GStreamer feature, so it can be used internally by vaapidecodebin without
changing its code too much.
https://bugzilla.gnome.org/show_bug.cgi?id=734093
Since the elements dependant of the VA video processor are now only registered
if it is available, vaapidecodebin code can be simplified a lot, removing all
the code required to check if the VA video processor was available.
https://bugzilla.gnome.org/show_bug.cgi?id=768899
Delay the GstVaapiDisplay instantiating until when changing the state from
READY to PAUSE. In this way the element has more chances to find an already
created GstVaapiDisplay, or a GL context, in the pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=766206
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
Using the GstContext mechanism, it is possible to find if the pipeline
shares a GstGLContext, even if we are not to negotiating GLTextureUpload
meta. This is interesting because we could negotiate system memory caps
feature, but enable DMABuf if the GstGLContext is EGL with some extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=766206
Since the driver checkup is done at registering, there is no need to do it
when changing the element state from NULL to READY. This patch remove this
vmethod from vaapidecode.
Query the GstVaapiDisplay to know if the driver supports video
postprocessing. If does, then register vaapipostproc and vaapidecodebin
elements.
This patch will simplify the design of vaapidecodebin.
https://bugzilla.gnome.org/show_bug.cgi?id=724352
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
This patch tries to instantiate a GstVaapiDisplay when registering the plugin
features, if it fails, no gstreamer-vaapi element is registering.
The purpose of this patch is to avoid a situation where the user has
gstreamer-vaapi installed but their VA-API setup is not functional, which may
lead to unexpected behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=724352
There are two main external dependencies that define the feature set of this
plugin: a) the kernel and b) the VA driver
This patch tracks both dependencies, if any of them change, GStreamer will
re-inspect the plugin.
The kernel is tracked through the device files /dev/dri/card*
The VA driver is tracked through the files VA_DRIVERS_PATH/*_drv_video.so,
where VA_DRIVERS_PATH is the one defined in libva package configuration. Also,
the environment variables LIBVA_DRIVERS_PATH and LIBVA_DRIVER_NAME are tracked
since they modify the driver lookup.
Additionally, the environment variable GST_VAAPI_ALL_DRIVERS is tracked too.
https://bugzilla.gnome.org/show_bug.cgi?id=724352
This is a fix for a regression of previous commit, which updates the filters
only when the property is set, because it is also required to update the
filter when the color balance interface change its values.
In case that sink caps and src caps are same, and no filtering parameter set,
pass-through mode is enabled.
If new filtering parameter is set during playback, it makes it reconfiguring,
so that pass-through mode is changed
In addition, updating filter is performed during reconfiguration, if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=751876
In order to handle correctly seek and other operations, vaapiencode should
flush all the remaining data from the encoder without pushing it downstream.
This patch implements the flush() vmethod, only after of pausing the
source pad task, and restarting it again after the flush stop.
https://bugzilla.gnome.org/show_bug.cgi?id=767176
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
To avoid surface-exhausted situation during reverse playback,
drop frames except for key frame.
Also, to avoid the corruption of the parser state, flush() vmethod
doesn't destroy the VA decoder when playing in reverse.
https://bugzilla.gnome.org/show_bug.cgi?id=742922
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
The queue in GstVaapiDecode adds an extra reference to the frames. This patch
unref that extra reference earlier making the code simpler to follow.
https://bugzilla.gnome.org/show_bug.cgi?id=768652
Calling drain() vmethod means "decode any data it can at this point, but that
more data may arrive after". Hence, vaapidecode should check if there is data
in the output adapter and process them, without destroying the decoded picture
buffer (dpb).
Since this operation is done by gst_vaapidecode_internal_flush(), the operation
was refactored into a new function gst_vaapidecode_flush_output_adapter().
https://bugzilla.gnome.org/show_bug.cgi?id=768652
Calling flush() vmethod means "to flush all remaining data from the decoder
without pushing it downstream".
Nonetheless flush() is calling gst_vaapidecode_internal_flush(), which calls
gst_video_decoder_have_frame() if there is still something in the input
adapter, which may push buffers to downstream by calling handle_frame().
This patch changes this behavior by calling gst_vaapidecode_purge() rather
than gst_vaapidecode_internal_flush(), which does what we want: flushes the VA
decoder and releases all the rest of decoded frames.
https://bugzilla.gnome.org/show_bug.cgi?id=768652
This patch is a fix for my bad review of commit 6d73ca8d. The element should
be able to return the available raw caps handled by the VA display, but that
only should happen when there a VA display. If there's none, the element
should use the caps template.
https://bugzilla.gnome.org/show_bug.cgi?id=768161
Though USE_{JPEG,VP8,VP9,H265}_ENCODER macros definition depend on USE_ENCODER
macro, it is clearer to nest them, showing explicitly the dependency relation.
Under certain conditions the element might receive a positive context query
but without a context instance. This situation will lead to a segmentation
fault when traversing the context list in the pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=767946
If vaapisink received a caps query before getting a VA display, it returned
only the surfaces related caps. This behavior broke the autovideosink
negotiation.
This patch returns the pad's template caps if no VA display, otherwise the
caps are crafted as before.
https://bugzilla.gnome.org/show_bug.cgi?id=767699
In cases where we know the video meta must be present, add it to
the pool configuration.
Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=766184
if gst_buffer_pool_set_config returns FALSE, check the modified
config and retry set_config if the config is still acceptable.
Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=766184
There's no need to check for the display in the plugin object when
decide_allocation() vmethod is called, because the display will created or
re-created along the method execution.
Get the pool config just before use it, to avoid a memory leak if the
allocator cannot be instantiated. Similarly, return FALSE if the configuration
cannot be set, avoid keep a not used allocator in the pool.
Instead of instantiating an allocator per vaapivideobufferpool, only one
allocator is instantiated per element's pad and shared among future pools.
If the pad's caps changes, the allocator is reset.
https://bugzilla.gnome.org/show_bug.cgi?id=765435
Originally, vaapivideobufferpool has a set of boolean variables for the
buffer configuration options.
This pach changes these boolean variables for a single bitwise, just as
it is used in pluginbase. Hence, the internal enum was moved to
vaapivideobufferpool header.
https://bugzilla.gnome.org/show_bug.cgi?id=765435
This patch refactors the code in pluginbase in order to centralize the buffer
pool instantiation. As the buffer pool config may have different options, these
are gathered using a bitwise flag.
https://bugzilla.gnome.org/show_bug.cgi?id=765435
Originally vaapivideobufferpool instantiates its own allocator regardless the
received configuration, and it relies in custom configuration options to
choose which kind of allocator instantiate.
This patch transfers the responsibility of the allocator instantiate to
vaapipluginbase and pass it to the vaapivideobufferpool through its
configuration.
* gst/vaapi/gstvaapipluginbase.c
+ set_dmabuf_allocator(): inserts a dmabuf allocator in the bufferpool
+ ensure_sinkpad_buffer_pool(): set a normal vaapi video allocator in
bufferpool configuration
+ gst_vaapi_plugin_base_propose_allocation(): call set_dmabuf_allocator() if
needed.
+ gst_vaapi_plugin_base_decide_allocation(): set a normal vaapi video
allocator in bufferpool configuration
* gst/vaapi/gstvaapivideobufferpool.c
+ gst_vaapi_video_buffer_pool_set_config(): instead of instantiate the
allocator, process the received one through its configuration.
* gst/vaapi/gstvaapivideobufferpool.h: removed
GST_BUFFER_POOL_OPTION_DMABUF_MEMORY since it is not used anymore.
* gst/vaapi/gstvaapivideomemory.c
+ gst_vaapi_is_dmabuf_allocator(): new helper function to identify a dmabuf
allocator with the vaapi qdata.
https://bugzilla.gnome.org/show_bug.cgi?id=765435
