Clear decoders out on a flush but keep the same instance,
rather than completely recreating them. That avoids
unecessarily freeing and recreating surface pools
and contexts, which can be quite expensive
https://bugzilla.gnome.org/show_bug.cgi?id=781142
As in gstreamer-vaapi a common base class is used, the specific
default category is passed to the base-plugin initializator, thus
the log messages are categorized with the used plugin.
Nonetheless, when the gst-debug is disabled in compilation time,
it is needed to pass NULL to the base-plugin initializator. This
patch does that.
https://bugzilla.gnome.org/show_bug.cgi?id=780302
Rename to be consistent with H.264 and also H.265 encoder. The
meson build assumed this was already consistently named, and so
previously was not able to actually build the H.265 decoder.
https://bugzilla.gnome.org/show_bug.cgi?id=778576
Use new -base API gst_video_decoder_allocate_output_frame_full() to
pass the current proxy/surface to the pool.
The pool will will export thins given surface instead of exporting a
brand new surface that will never be filled in with meaningfull data.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
When a new sink caps arrive the internal decoder state is updated
and, if it is, request a downstream renegotiation.
Previously, when new caps arrived the whole decoder where destroyed
and recreated. Now, if the caps are compatible or has the same codec,
the internal decoder is kept, but a downstream renegotiation is
requested.
https://bugzilla.gnome.org/show_bug.cgi?id=776979
This reverts commit 3285121181.
videodecode's negotiate() vmethod is also called when events arrive,
but this would mean that the proper configuration of sink pad might
not be complete, thus we should not update the src pad.
Let's keep the old non-vmethod negotitate().
Since the differentiation of negotiation caps and allocation caps,
there is no need to add a video crop meta with the negotiation caps.
Hence, removing it.
https://bugzilla.gnome.org/show_bug.cgi?id=773948
This is related with bug 758907 when no vaapipostproc is used (no
vaapidecodebin). In order to negotiate downstream we need to destroy
the source pad allocator, otherwise the same allocated buffers are
used, failing the mapping.
The variable member allowed_sinkpad_caps is constructed querying the
current VA display. Bearing that in mind, the variable shall be freed
when the VA display changes or is removed.
This patch moves the freeing of allowed_sinkpad_caps to close(), when
the VA display is freed.
In commit 6d11a00 were introduced a regression when gstreamer-vaapi is
compiled with out EGL/GLX support: it shall not support
GST_VAAPI_MAKE_GLTEXUPLOAD_CAPS.
This patch guards the inclusion of GST_VAAPI_MAKE_GLTEXUPLOAD_CAPS in the
allowed src caps for vaapedecode if EGL/GLX.
Just as vaapipostproc, VA decoder's context can be queried to get the possible
raw formats, so, the src caps can negotiate the exact caps that the context
supports.
In the spirit of the codec split, this patch removes the documentation of
vaapidecode and adds a page per each possible decoder.
Nonetheless, only those available in the compilation system are going to be
instrospected, because the rest are not registered.
vaapidecode has a member named allowed_caps, but this name is not enough
explicit. This patch renames allowed_caps to allowed_sinkpad_caps.
No functional changes were included.
https://bugzilla.gnome.org/show_bug.cgi?id=773497
set_format() is called by upstream when the stream capabilites has changed.
Before, if the new stream is compatible with the old one the VA decoder was
not destroyed. Nonetheless, with this behavoir, the VA decoder ignores
when the upstreamer parsers gets more details of the stream, such as the
framerate. Hence, when the src caps are negotiates, the further sink caps
updates are ignored.
This patch forces the VA decoder destroying and recreation when set_format()
is called.
https://bugzilla.gnome.org/show_bug.cgi?id=770921
In order to register only the available decoders, this patch queries the
created test VA display, which uses the currently used back-end (X11, Wayland,
DRM, …) on the used display device.
https://bugzilla.gnome.org/show_bug.cgi?id=724352
Split the vaapidecode to all the supported codecs with the format
vaapi{codec}dec.
vaapidecode is stil registered as a GObject type, but not as a
GStreamer feature, so it can be used internally by vaapidecodebin without
changing its code too much.
https://bugzilla.gnome.org/show_bug.cgi?id=734093
Delay the GstVaapiDisplay instantiating until when changing the state from
READY to PAUSE. In this way the element has more chances to find an already
created GstVaapiDisplay, or a GL context, in the pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=766206
Since the driver checkup is done at registering, there is no need to do it
when changing the element state from NULL to READY. This patch remove this
vmethod from vaapidecode.
To avoid surface-exhausted situation during reverse playback,
drop frames except for key frame.
Also, to avoid the corruption of the parser state, flush() vmethod
doesn't destroy the VA decoder when playing in reverse.
https://bugzilla.gnome.org/show_bug.cgi?id=742922
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
The queue in GstVaapiDecode adds an extra reference to the frames. This patch
unref that extra reference earlier making the code simpler to follow.
https://bugzilla.gnome.org/show_bug.cgi?id=768652
Calling drain() vmethod means "decode any data it can at this point, but that
more data may arrive after". Hence, vaapidecode should check if there is data
in the output adapter and process them, without destroying the decoded picture
buffer (dpb).
Since this operation is done by gst_vaapidecode_internal_flush(), the operation
was refactored into a new function gst_vaapidecode_flush_output_adapter().
https://bugzilla.gnome.org/show_bug.cgi?id=768652
Calling flush() vmethod means "to flush all remaining data from the decoder
without pushing it downstream".
Nonetheless flush() is calling gst_vaapidecode_internal_flush(), which calls
gst_video_decoder_have_frame() if there is still something in the input
adapter, which may push buffers to downstream by calling handle_frame().
This patch changes this behavior by calling gst_vaapidecode_purge() rather
than gst_vaapidecode_internal_flush(), which does what we want: flushes the VA
decoder and releases all the rest of decoded frames.
https://bugzilla.gnome.org/show_bug.cgi?id=768652
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
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
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 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
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
Don't expose the the vaapidecode GType, instead expose a function
which will register element.
This is the first step to split the decoder by codecs.
https://bugzilla.gnome.org/show_bug.cgi?id=734093
In commit 6034734d I forgot to add the caps filter intersection in the
getcaps() vmethod generating a regression when a capsfilter is set in the
pipeline.
This commit adds the caps filter intersection.
The usage of getcaps() vmethod is preferred than to handle manually the sink's
caps query.
In order to avoid function declarations, this patch moves the class_init()
method to the end of the file.
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>
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
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
The received caps query will bring the already negotiated caps, so they are
not expected to change.
This patch removes this verification which is dead code path.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=756686
Instead of calling gst_vaapi_find_preferred_caps_feature(), which is
expensive, we check the caps from the allocation query, to check the
negotiated feature.
In order to do this verification a new utility function has been implemented:
gst_vaapi_caps_feature_contains().
As this new function shared its logic with gst_caps_has_vaapi_surface(), both
have been refactorized.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=756686
There is a regression from commit 3d8e5e. It was expected the buffer pool
allocation occur before the caps negotiation, but it is not.
This patch fixes this regression: the caps negotiation is done regardless the
allocation query from downstream.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=756686
