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
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
Add a mutex to postproc to protect concurrent access to data members.
Previously set_caps() could release the allowed_srcpad_caps while
transform_caps was in the middle of using it.
Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=766940
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 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
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
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.
-- 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
When transforming downstream caps we should check for ANY caps from peer pad,
otherwise we get a segmentation fault.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=759893
When the source caps change, the filter is destroyed and recreated.
Nonetheless, this happens every time the vaapipostproc starts, since the caps
change detection algorithm does not take in consideration when the caps are
set by first time.
This patch intents to be an optimization, to avoid a useless filter
destroy-creation cycle when the sources caps are set for first time.
The new helper function video_info_update() is a refactorization to avoid
duplicated code.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=758007
The signature is video_info_changed(old_vip, new_vip). Nonetheless the callers
swapped the the order. This didn't raise problems since the comparison of both
structures were not affected by its semantics.
But still it would be better to fix this to keep the coherence of the code.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=758007
The current context query handling design is flawed: the function
gst_vaapi_reply_to_query() returns FALSE either if the query is not a
GST_CONTEXT_QUERY of if the query could not be handled correctly. But the
pad query function should handle differently each case.
This patch changes the gst_vaapi_reply_to_query() for
gst_vaapi_handle_context_query() and changes it usage in all the vaapi plugins
to match the correct context query handling.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
Refactor the main vaapi caps strings into three macros:
GST_VAAPI_MAKE_SURFACE_CAPS, GST_VAAPI_MAKE_ENC_SURFACE_CAPS and
GST_VAAPI_MAKE_GLTEXUPLOAD_CAPS.
Those are in gstvaapipluginutil.h so all the elements could use them, instead
of re-declaring them every time.
No functional changes.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Working on bug #744042 I realized that the gstvaapiuploader is practically not
used.
This patch removes the gstvaapiuploader and add the method
gst_vaapi_plugin_base_get_allowed_raw_caps () that returns the raw caps that
the system can handle, which is used by vaapisink and vaapipostproc.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=752777
The Current code path is falling back to passthorugh mode if there is no
vpp property set by the user explictily. But we should not use the
passthrough mode if the negotiated src pad caps have a differnt color space
format than sink pad caps (Even though the user didn't set the format property
explicitly).
https://bugzilla.gnome.org/show_bug.cgi?id=748184
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
This is a workaround to deal with the va-intel-driver for non-native
formats while doing advanced deinterlacing. The format of reference surfaces must
be same as the format used by the driver internally for motion adaptive
deinterlacing and motion compensated deinterlacing.
A permanent solution could be to do the color space conversion internally
for reference surfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=730925
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
In order to reduce the noise, the query type log was downgrade from INFO to
DEBUG, and the shared display address log message is assigned to the object.
The problem with this is that creating the filter causes the display to
be selected, and the caps query happens while linking the element. So,
if the downstream or upstream element is using a specific display
object, it won't be propagated correctly to the postproc as it already
has a display at this point.
https://bugzilla.gnome.org/show_bug.cgi?id=747945
