When caps reconfiguration is called, the new downstream frame size might be
different. Thus, if the downstream caps change,the display's texture map is
reset.
In addition, during pipeline shutdown, textures in texture map have to be
released, since each one have a reference to the GstVaapiDisplay object, which
is a dangerous circular reference.
https://bugzilla.gnome.org/show_bug.cgi?id=769293
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Check earlier if upstream video source has activated the dmabuf-import
io-mode (hack to disappear soon), thus we can avoid the re-assignation of a
new allocator.
Add the method gst_allocator_get_vaapi_image_size() for the
GstVaapiVideoAllocator, which gets the size of the allocated images with the
current video info.
This method replaces the direct call to the allocator's image info when the
pool is configured.
Depends on media, video size is sometimes updated with new allocator.
It leads to dismatch between bufferpool's set size and real allocated buffer size.
In this case, it causes every buffer is freed during release in bufferpool,
which should be reused. This affects performance.
https://bugzilla.gnome.org/show_bug.cgi?id=769248
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
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
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
This is a helper function to improve the readability of
ensure_sinkpad_buffer_pool(). It makes clearer when the buffer pool needs to be
re-instantiated.
This buffer pool may still be processing buffers when a caps renegotiation is
done. This one-liner patch deactivates the pool to drain it before it
de-allocation.
Right now, the decoders create a buffer pool for their sink pad which is not
used at all, because the decoders have never proposed it to upstream.
This patch avoids the buffer pool instantiating when the element inherits from
the GstVideoDecoder class.
This patch is a bit of optimization, since the bufferpool configuration is get
when the pool is created. Hence, we only need to request it when the pool from
the allocation query is reused.
If the offered pool in decide_allocation() vmethod doesn't have the
VAAPI_VIDEO_META option, it is destroyed immediatly and the pointer cleared,
so it could be created later.
Use GST_{ERROR,WARNING}_OBJECT instead of GST_{ERROR,WARNING}, thus the logs
will show the name of the vaapipluginbase instance that failed.
Also, the code-style is fixed, where some error labels need to be surrounded
by braces.
gst_video_info_set_format() and gst_video_info_from_caps() call, internally,
gst_video_info_init(), hence it is not required to call it before them. This
patch removes these spurious calls.
This function helper make sense for GStreamer 1.2, but it is not helpful for
greater version since the validation is already done in the API implementation.
Thus, it is removed.
If the backend driver vendor string is not in a white-list, and the
environment variable GST_VAAPI_ALL_DRIVERS is not set either, the decoder will
change it state from NULL to READY, hence the auto-plug mechanism will look
for another decoder.
This patch assumes the GstContext has already being shared along the pipeline
and the element has a valid GstVaapiDisplay instance.
https://bugzilla.gnome.org/show_bug.cgi?id=764673
In bug 757598 was added the set_context() vmethod chain up in
GstVaapiPluginBase. But it is buggy, since the parent_class address is
assigned to the last element which called gst_vaapi_plugin_base_class_init().
No error has shown up since none of the element's base classes redefined
set_context() vmethod from GstElement, so always the correct function was
called. Still this code is wrong and this patch make it right.
Since set_context() is the same code, a macro is used to implement that code
in all the gst-vaapi elements.
https://bugzilla.gnome.org/show_bug.cgi?id=765368
Instead of using the srcpad template caps for filtering the peer caps, the
function gst_vaapi_find_preferred_caps_feature(), now receives a new parameter
for the element's allowed caps.
With this modification, the vaapipostproc element simplifies a bit its code.
https://bugzilla.gnome.org/show_bug.cgi?id=765223
The native format parameter in gst_vaapi_find_preferred_caps_feature() can be
saved if the out format is used for both: in and out. Thus the code is more
readable.
https://bugzilla.gnome.org/show_bug.cgi?id=765223
When resolving bug 753914, a custom allocation query was added, overlapping
the responsibilities of GstVideoDecoder.
But with the merge of the patches from bug 764421 this overlapping was not
required anymore. This patch restores this situation setting the
allocation_caps in the GstVideoCodecState when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=764316
-- Maintaing decoded surface resoluton and actual display resoultion separately
-- Before pushing every frames downstream, check for the requirement of pool negoation and
output_state negotiation: This is needed to avoid multiple issuses with cropping,
multi-resoluton video handling, more complex multi resolution decode scenarios for vp9decode,
possible wrong behaviour from upstream element to report uncropped values etc. Due to these reasons,
We can't just reliably use the resolution change notification from libgstvaapi for pool renegotiation too.
This is slight overhead, but safe enough. Optimization could be possible though.
https://bugzilla.gnome.org/show_bug.cgi?id=753914
Since we are only supporting current GStreamer version, since 1.3
gst_buffer_pool_config_add_option() checks if the option to add is
already set. There is no need to do it ourselves.
icamerasrc is another gstreamer plugin using to capture RAW
frames from camera device. It is based on libcamhal library.
There are some properties available to control icamera behavior.
Signed-off-by: Lim Siew Hoon <siew.hoon.lim@intel.com>
Tested & Reviewed: Zhu Haiyang <haiyang.zhu@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=759481
Fixme: This is the similar workaround we done for v4l2src.
The workaround will be removed once we fix#755072
