Trying to comply with GStreamer's element names, this patch renames the
encoders using the name format vaapi{codec}enc.
In this way, the plugin documentation is linked correctly.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
As gst-indent generated ugly code in these cases, this patch changes the used
idiomatic into other one.
No functional changes were introduced.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
In gstvaapipluginbase.c we are using the macro USE_GST_GL_HELPERS to guard the
code related with GstGL. Nonetheless, in gstvaapipluginbase.h we are using
HAVE_GST_GL_GL_H macro in order to include the GstGLContext's header.
We should use only one to be homogeneous. This patch sets USE_GST_GL_HELPERS
in the header file.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
This dependency was added in gstvaapidecodebin with the call
gst_missing_element_message_new().
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
This header is not used anymore since it declares parsers that are
already in GStreamer 1.6
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
As gstreamer-vaapi now only supports from GStreamer 1.6, this patch removes
all the old GStreamer version guards.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Since we don't install libraries anymore, it makes no sense to keep
versioning them according to the gstreamer's version.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
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 gst_vaapi_plugin_base_get_input_buffer() fail to copy the input buffer
into a VAAPI buffer, the return value is GST_FLOW_NOT_SUPPORTED, and it was
ignored by the vaapisink, leading to a segmentation fault.
This patch ignores the frame that generated the GST_FLOW_NOT_SUPPORTED
returned by gst_vaapi_plugin_base_get_input_buffer(), avoiding the
segmentation fault, but doing and effort to continue rendering. This is
the same behavior of ximagesink.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=759332
As gsth265parse was added in GStreamer 1.4, and gstreamer-vaapi still support
GStreamer 1.2, the patching of gsth265parse must be conditional to the target
GStreamer version.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755525
This is a continuation of commit fc8a0d12
When declaring BUILT_SOURCES, those files should not be distributed. This
patch avoids the distribution of the generated source code.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755525
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
When runnig the `make dist` target from a clean tree, it fails because
if could not find the copied files from codecparsers submodule.
They weren't copied because they weren't declared as built sources.
This patch removes the stamp mechanism and use the actual file list to copy
as the built sources. Also it fixes the duplication of the parser files.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755525
Rather than create a dummy display, if none has propagated as a context, we
should try to get the one from vaapidecode.
As the bin is already in READY state, the vaapidecode should be also in that
state. That means that the contexts have been negotiated, and it should have
already a display.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757957
The former approach to left the bin unfinished has some problems: the context
cannot be shared because the vaapidecode is unlinked in many cases, leading to
creating a VADisplay twice.
Initially the bin is fully functional, constructed as
(-----------------------------------)
| vaapidecodebin |
| (-------------) (-------) |
|<--| vaapidecode |--->| queue |--->|
| (-------------) (-------) |
(-----------------------------------)
When the context is shared and the VADisplay has VPP capabilities, before
changing to READY state, the bin is reconfigured dynamically, adding the
vaapipostproc element afeter the queue:
(--------------------------------------------------------)
| vaapidecodebin |
| (-------------) (-------) (---------------) |
|<--| vaapidecode |--->| queue |--->| vaapipostproc |--->|
| (-------------) (-------) (---------------) |
(--------------------------------------------------------)
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757957
Delay the bin configuration until changing to READY state. This is because we
should add the vaapipostproc element until the vaapidecode has emitted the
HAVE_CONTEXT message, so de gst_bin_add() could set the context set to
vaapipostproc.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757957
Since gstreamer 1.4 is not required to have pad query functions if the query
vmethods are used.
This patch guards out the pad query functions for gstreamer < 1.4
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757629
GstVideoEncoder, the base class of vaapiencode, added support for pad queries
as virtual methods since gstreamer 1.4. This patch enables those vmethods,
while keeps support for previous versions of gstreamer.
This patch is relevant since GstVideoEncoder takes care of other queries that
we are currently ignoring.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757629
A caps query can occur before the element has a display. In that case, the
element can return its pad's template. But when the element already has a
display, and the caps probe fails, the element shall return an empty caps, so
the auto-plug could try with another decoder.
If the element has a display and the caps probe works, then the computed caps
should be returned.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
Caps query can happen before the element has a bus. The display creation should
be should occur on the context negotiation, when the bus is already configured.
Then at caps query no display should be created.
Instead of force the display creation, we graciously fail the allowed_caps()
creation.
This change only applies for vaapidecode and vaapisink. The vaapipostroc, as a
basetransform descendant, seems to be not affected by this, nor the encoders.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
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
When processing the GST_CONTEXT_QUERY we should not lose the previous
context in the query, we should only add our display structure.
This patch copies the old context, if it is there, and stamp our display on
it. Otherwise, a new context is created.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
This function set the display to an already created context. This function is
going to be used later.
Also, gst_vaapi_video_context_new_with_display() now uses this function.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
Since the context messages are sync'ed, the display assignation happens in the
same thread, hence we can know if the display was found or not as soon we call
for it.
In order to take advantage of it, gst_vaapi_video_context_prepare() receives,
as a new parameter, the address of the plugin's display, and reports back if
the display was found and set.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
Instead of setting the display to the plugin directly after its creation, do
it through the gstreamer's context mechanism, avoiding double assignations.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
The context structure is named "display" which is too generic. The contrary
happens, for example, with GstGL, what uses the same name as the context, and
its logs make more sense.
This patch renames the context structure with the same name as the
context, thus GST_PTR_FORMAT can pretty print it.
https://bugzilla.gnome.org/show_bug.cgi?id=757598
First, refactorized run_context_query() into _gst_context_run_query(), adding
a new parameter: the pad direction, in order to simplify the code.
Second, added a new helper function: _gst_context_query(), which is a generic
context query function. It isolates the operation of running the query and
sets the context if found, also it enhances the logs.
_gst_context_query() is similar to the one used in GstGL. Perhaps, in the
future this helper function will be merged into the core libraries of
GStreamer.
Finally, gst_vaapi_video_context_prepare() was rewritten to use
_gst_context_query().
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
Refactor the extraction GST_CAT_CONTEXT logging using a only once
initializator, so we could get the debug category from different code
paths, safely.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
gst-indent does not handle correctly some expression like function
declaration with attributes, breaking the following expressions.
This patch makes gst-indent to ignore the attributed function
declartion so the followed function definition is not mangled, such
as happened in commit b4154a
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
The display returned by gst_vaapi_video_context_get_display() increments the
references. Thus, we have to unref the returned display.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757595
Though caps features are supported since GStreamer 1.2, there are some
issues with the features caps negotiation in that version. Nonetheless,
those issues are fixed in GStreamer 1.4. So, the memoy:VASurface caps
feature negotiation is relaxed for GStreamer 1.4.
The guard is the same as in vaapisink's caps template.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=756686
