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.
When validating the caps from bufferpool config, this patch distinguishes the
error from no caps received (NULL) from the invalid caps (cannot be converted
into GstVideoInfo structure).
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.
Instead of a dummy alloc() vmethod, the allocator instance set the flag
GST_ALLOCATOR_FLAG_CUSTOM_ALLOC, which is used by the framework to avoid call
gst_allocator_alloc() on the allocator.
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.
This is a workaround since vaapi-intel-driver doesn't have
support for B-frame encode when utilizing low-power-enc
hardware block.
Fixme :We should query the VAConfigAttribEncMaxRefFrames
instead of blindly disabling b-frame support and set b/p frame count,
buffer pool size etc based on the query result.
https://bugzilla.gnome.org/show_bug.cgi?id=766050
Added a new property "low-power-enc" for enabling low power
encoding mode. Certain encoding tools may not be available
with the VAEntrypointEncSliceLP.
https://bugzilla.gnome.org/show_bug.cgi?id=766050
Instead of using gst_video_info_to_caps () to generated the fixed src caps,
this patch enables the first step for caps negotiation with a possible
following caps filter.
_get_preferred_caps() will traverse the possible src caps looking for the one
wit the preferred feature and the preferred color format. Then the color
format, the frame size and the frame rate are fixated.
https://bugzilla.gnome.org/show_bug.cgi?id=758548
Instead of the allowed_srcpad_caps variable, this patch uses the othercaps
from fixate_caps() vmethod to find the preferred caps feature and color
format.
https://bugzilla.gnome.org/show_bug.cgi?id=758548
When running transform_caps() vmethod, returning the srcpad caps, the caps are
early restricted to the element properties set: width, height, format and
force keep aspect.
A new file was added gstvaapipostprocutil.{c,h} where the utilities functions
are stored.
https://bugzilla.gnome.org/show_bug.cgi?id=758548
Instead of #ifdef it should be used #if becasuse USE_GST_GL_HELPERS is always
defined in config.h, but it would be 0 or 1 depending on the configure output.
https://bugzilla.gnome.org/show_bug.cgi?id=765702
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
Since commit 859a2b2, in vaapidecode, allocation query can be different from
the negotiated caps.
When connecting the vaapidecoder to the vaapipostprocessor, the last one will
resize the frame to the negotiated, if and only if, some other parameter is
activated to avoid the passthrough. If it is not, the surface won't be mapped
into a image. If not, the image won't be resized and the output buffer would be
mapped.
This patch will break the passthrough if the allocation query is different
from the negotiation caps, forcing the resizing.
https://bugzilla.gnome.org/show_bug.cgi?id=765095
