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
gst_vaapi_decoder_state_changed() returns void. This patch fixes the
compilation where the toolchain uses restrictive flags as clang.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
The use of gst_caps_is_always_compatible() for this optimization may lead to
false positives. It is better to stick to gst_caps_is_strictly_equal() to know
if it is required a re-negotiation.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=750835
Delaying the pool re-negotiation untill we push all decoded (and queued)
frames downstream. Otherwise for the multi-resolution videos, the
GstVideoVideoMemory will be having wrong resolution and which leads
to nasty behaviours, especially when using software renderers.
sample media file: RAP_B_Bossen_1.bin
case explained:
The first SPS Nal will report resoultion of 448x256 and having crop rectangles to
get the final resoultion 416x240.
Starting from 25 th frame, the resolution will change to 416x240. But parser
elements won't report this since the effective croped resolution is same in
both cases. Here the core libgstvaapi will detect this through it's internal
parsing and do all context/pool destory/reset stuffs. Also it will notify this
change to plugins in advance. But if the plugin try to do re-negotiaion of pool
immediately, this will not sync with the resolution of already decoded and queued
frames and which will lead to failure in gst_video_frame_map() in downstream(if we use the
software renderer). So we have to delay the pool renegotiation in vaapidecode,
untill we push all decoded frames downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=753914
Currently we are sharing the input GstVideoCodecState with
GstVaapiDecoder(gst-libs/gst/vaapi) by just doing ref and unref for
each caps change. This is troublesome in many cases, for eg: if
resoultion changes with in a singe stream. Because, when ever there
is a resolution change, GstVideoDecoder will first change the Codec_state->caps
fields with new resolution, but since we are using the same codecstate (ref)
in gstvaapidecode.c, the caps check for input caps change will always fail.
https://bugzilla.gnome.org/show_bug.cgi?id=753914
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>
When seeking, the decoder is reset, but the buffer pool is not
re-negotiated, but in reset_full() the code forgets if the negotiated buffer
pool has the GLTextureUpload meta.
The decoder knows that GLTextureUpload meta was negotiated in
decide_allocation(), but this method is not called when seeking.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=752929
Add initial infrastructure in core codec library and vaapidecode to mark
corrupted frames as such. A corrupted frame is such a frame that was
reconstructed from invalid references for instance.
https://bugzilla.gnome.org/show_bug.cgi?id=751434
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
This is a naïve approach to the calculation of the VA-API decoding latency. It
takes into consideration when the frame-rate has some insane value.
https://bugzilla.gnome.org/show_bug.cgi?id=740419
Fix link when building plugin elements without HEVC support. e.g. don't
try to call into gst_vaapi_decoder_h265_set_alignment() if there is no
support HEVC enabled in libgstvaapi.
Also, drop disabled codecs from static template caps. Add the missing
HEVC static template caps into vaapidecodebin too.
This a cosmetic refactor: gst_vaapidecode_internal_flush() removes its only
label; gst_vaapidecode_finish() is more readable and gst_vaapidecode_purge()
shares the same error message of gst_vaapidecode_internal_flush() when flush
fails.
Add the method gst_vaapidecode_purge(). This method releases the
flushed frames from the decoder.
This new method add more readablity to gst_vaapidecode_destroy()
When a frame is rejected by downstream, the message is logged twice. This
patch removes one of those logging messages.
Also, the reject of a frame doesn't mean an alarming error. This patch demotes
the log message from error to info.
We get one reference when the frame is passed to decode_handle_frame()
and create another one in gst_vaapi_decoder_push_frame().
Usually the frame is handled in gst_vaapidecode_push_decoded_frame().
Here the frame is always released twice:
gst_video_decoder_finish_frame() + gst_video_codec_frame_unref() or
gst_video_decoder_drop_frame() + gst_video_codec_frame_unref().
In gst_vaapidecode_reset_full() both references to the frame must be
released as well.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=743226
The support for GStreamer 1.0 has been obsoleted in 0.5.10 release.
GStreamer 1.2 is the a minimal requirement for building the gstreamer-vaapi.
This patch removes all the pre-processor conditional code compilation guarded
for gstreamer-1.0.
Thus, all the video converters were removed too.
https://bugzilla.gnome.org/show_bug.cgi?id=745728
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
The purpose of gstcompat.h is to couple the API differences among
gstreamer-1.0 and gstreamer-0.10. Since gstreamer-0.10 is obsolete, the code
in this compatibility layer shall be removed.
Nevertheless, the gstcompat.h header should be kept, if new incompatibilites
appear in the future, but it shall live in gst/vaapi, not in gst-libs.
This patch removes the crumbs defined gstcompat.h and moves it to gst/vaapi.
In order to avoid layer violations, gstcompat.h includes sysdeps.h and all
the includes in gst/vaapi of sysdeps.h are replaced with gstcompat.h
https://bugzilla.gnome.org/show_bug.cgi?id=745728
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
In GStremer v1.6 a new vmethod drain() was added in GstVideoDecoder
class. This patch implements this new method.
https://bugzilla.gnome.org/show_bug.cgi?id=742922
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Since in bug #745728 the support for GStreamer 1.0 is going to be dropped,
this patch removes the method reset() which was deprecated in GStreamer 1.2.
https://bugzilla.gnome.org/show_bug.cgi?id=742922
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Since GStreamer 1.2 the vmethod reset() in GstVideoDecoderClass was deprecated
and flush() was added.
This patch set the vmethod flush() if the installed GStreamer version is 1.2 or
superior. Otherwise, reset() is set.
v2: 1) In order to avoid symbol collision, the old method gst_vaapidecode_flush()
was renamed to gst_vaapidecode_internal_flush().
2) The new vmethod flush() always do a hard full reset.
v3: 1) Call gst_vaapidecode_internal_flush() first in flush() vmethod, in order to
gather all collected data with gst_video_decoder_have_frame()
https://bugzilla.gnome.org/show_bug.cgi?id=742922
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
In commit 2f8c115 (vaapidecode: use the query virtual methods in 1.4)
a bug was introduced: when calling the parent's query function of the
src pad, the one of the sink pad is called instead. This patch fixes
this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=746248
Sometimes, for example, when switching video streams but keeping
the same sink, the surface will be released after the decoder is
stopped and replaced. This caused a crash because the release
callback was called on an invalid pointer.
The patch adding an additional reference to the decoder object in the buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=745189
Signed-off-by: Olivier Crete <olivier.crete@collabora.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
GstVideoDecoder, the base class of vaapidecode, added support for
pad queries as virtual methods. This patch enables the use of that
support, while keeping support for lower versions of gstreamer.
This patch is important because GstVideoDecoder takes care of other
queries that might be important in the pipeline managing.
v2: 1) rebase to current master
2) fix indentation with gst-indent
3) simplify the patch layout
4) fix the context query
5) initialise the filter to NULL
6) improve the query log message for gst-1.2
https://bugzilla.gnome.org/show_bug.cgi?id=744406
Because the decoder uses the thread from handle_frame() to decode a frame,
the src pad task creates an unsolveable AB-BA deadlock between
handle_frame() waiting for a free surface and decode_loop() pushing
decoded frames out.
Instead, have handle_frame() take responsibility for pushing surfaces,
and remove the deadlock completely. If you need a separate thread
downstream, you can insert a queue between vaapidecode and its downstream
to get one.
Another justification for the single thread implementation is,
there are two many point of locking in gstreamer-vaapi's current
implementation which can lead to deadlocks.
https://bugzilla.gnome.org/show_bug.cgi?id=742605
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
vaapidecode keeps an output state that use the format
GST_VIDEO_FORMAT_ENCODED, while it crafts a different src caps
for a correct negotiation.
I don't see the rational behind this decoupling, it looks like
unnecessary complexity. This patch simplify this logic keeping
in sync the output state and the src caps.
This patch improves the readability of the function
gst_vaapidecode_update_src_caps() and simplify its logic. Also,
the patch validates if the buffer pool has the configuration for
the GL texture upload meta, in order to set the caps feature
meta:GLTextureUpload. Otherwise, the I420 format is set back.
https://bugzilla.gnome.org/show_bug.cgi?id=744618
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
When vaapidecode finishes the decoding of a frame and pushes it,
if, in the decide_allocation() method, it is determined if the
next element supports the GL texture upload meta feature, the
decoder adds the buffer's meta.
Nonetheless, in the same spirit of the commit 71d3ce4d, the
determination if the next element supports the GL texture upload
meta needs to check both the preferred caps feature *and* if the
allocation query request the API type.
This patch, first removes the unused variable need_pool, and
determines the attribute has_texture_upload_meta using the
preferred caps feature *and* the allocation query.
Also, the feature passed to GstVaapPluginBase is not longer
determined by has_texture_upload_meta, but by the computed
preferred one.
https://bugzilla.gnome.org/show_bug.cgi?id=744618
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Currently the src caps are set immediately after the sink caps are set, but in
that moment the pipeline might not fully constructed and the video sink has
not negotiated its supported caps and features. As a consequence, in many cases
of playback, the least optimized caps feature is forced. This is partially the
responsible of bug #744039.
Also, vaapidecode doesn't attend the reconfigure events from downstream,
which is a problem too, since the video sink can be changed with different
caps features.
This patch delays the src caps, setting them until the first frame arrives to
the decoder, assuming until that very moment the whole pipeline is already
negotiated. Particularly, it checks if the src pad needs to be reconfigured,
as a consequence of a reconfiguration event from downstream.
A key part of this patch is the new GstVaapiCapsFeature
GST_VAAPI_CAPS_FEATURE_NOT_NEGOTIATED, which is returned when the src pad
doesn't have a peer yet. Also, for a better report of the caps allowed
through the src pad and its peer, this patch uses gst_pad_get_allowed_caps()
instead of gst_pad_peer_query_caps() when looking for the preferred feature.
v3: move the input_state unref to close(), since videodecoder resets at
some events such as navigation.
v4: a) the state_changed() callback replaces the input_state if the media
changed, so this case is also handled.
b) since the parameter ref_state in gst_vaapidecode_update_src_caps() is
always the input_state, the parameter were removed.
c) there were a lot of repeated code handling the input_state, so I
refactored it with the function gst_vaapi_decode_input_state_replace().
https://bugzilla.gnome.org/show_bug.cgi?id=744618
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Some frameworks (EFL) expect BGRA textures for storage. However,
adding support for that broadly into GStreamer framework implies
two kinds of hacks: (i) libgstgl helpers currently do not support
BGRA textures correctly, (ii) we need to better parse downstream
suggested caps and intersect them with what the VA plugin elements
can offer to them for GL texturing.
