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
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
If the downstream feature is system memory, the surface has to be mapped,
hence a warning message is logged saying that the driver has to do color
conversions. This might be troublesome because not all the color conversion
combinations are supported by the VA-API drivers, and there is not a reliable
way to know them before hand.
https://bugzilla.gnome.org/show_bug.cgi?id=765223
Instead of setting the requested format by the caller, the function
gst_vaapi_find_preferred_caps_feature() now returns, in the output parameter,
the negotiated format.
A new helper function was added: gst_vaapi_find_preferred_format(), which,
given the format list from the negotiated caps, will choose the best one, if
possible, given the native format.
https://bugzilla.gnome.org/show_bug.cgi?id=765223
This patch simplifies the function gst_vaapi_find_preferred_caps_feature().
Instead of intersecting custom caps to find the preferred feature, the peer
caps are traversed in order to find the preferred feature, according to an
ordered feature priority list.
In the case of GLTextureUploadMeta, the colour format is computed using
GstVideoInfo of the selected fixed caps.
https://bugzilla.gnome.org/show_bug.cgi?id=765223
As decoded_info is assured to be valid when gst_vaapidecode_update_src_caps()
is called, then we don't need to verify or replace it with the sinkpad info
(reference state).
https://bugzilla.gnome.org/show_bug.cgi?id=764316
active, do_pool_renego and do_outstate_renego class variables were used to
indicate when negotiate downstream once, but now that each time a new surface
resolution is pop out a renegotation verified, these variable are not required
anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=764316
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
The plugins should not expose the feature meta:GstVideoGLTextureUploadMeta in
their caps templates if they were not compiled either with GLX or EGL support.
The compiler might complain of gst_vaapi_create_display_from_handle() being
unused if both EGL and GLX are disabled. This patch avoid that compilation
error.
There is no difference in VAAPI surface caps between encoders and decoders.
Thus, the patch makes a simplification by removing encoders specific caps and
shares the same definition of VAAPI surfaces caps for all the elements.
The P010 video format is the native format used by the vaapi intel driver
for HEVCMain10 decode . Add support for planes and images of this video format.
https://bugzilla.gnome.org/show_bug.cgi?id=759181
Instead of using a single value for the texture type, use an array with 4
elements, just as the GstVideoGLTextureUploadMeta, avoiding a buffer
overflow.
https://bugzilla.gnome.org/show_bug.cgi?id=764231
After the decoding of first frame, try to extract the exact
decoded surface format using vaDeriveImage and keep this
as the format in decoded_info.
https://bugzilla.gnome.org/show_bug.cgi?id=753914
-- 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
This will help to consoidate the out caps negotiation to a single place,
which will make the code simpler, allows to get the exact decoded format
if needed and the selected chroma type too.
https://bugzilla.gnome.org/show_bug.cgi?id=753914
