In order to handle correctly seek and other operations, vaapiencode should
flush all the remaining data from the encoder without pushing it downstream.
This patch implements the flush() vmethod, only after of pausing the
source pad task, and restarting it again after the flush stop.
https://bugzilla.gnome.org/show_bug.cgi?id=767176
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
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
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
Though USE_{JPEG,VP8,VP9,H265}_ENCODER macros definition depend on USE_ENCODER
macro, it is clearer to nest them, showing explicitly the dependency relation.
Under certain conditions the element might receive a positive context query
but without a context instance. This situation will lead to a segmentation
fault when traversing the context list in the pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=767946
Change defaults for max-bframes, cabac, and dct8x8 to be enabled
by default. This will cause the default profile to be high instead
of baseline. In most situations this is the right decision, and
the profile can still be lowered in the case of caps restrictions.
Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757941
Without this, all dpb pictures are not released during flush,
because we used the global dpb_count variable for checking the
dpb fullness which get decremented in dpb_remove_index()
routine during each loop iteration.
https://bugzilla.gnome.org/show_bug.cgi?id=767934
If vaapisink received a caps query before getting a VA display, it returned
only the surfaces related caps. This behavior broke the autovideosink
negotiation.
This patch returns the pad's template caps if no VA display, otherwise the
caps are crafted as before.
https://bugzilla.gnome.org/show_bug.cgi?id=767699
Clarify that vaapi context resets are never needed for vp9, but
that ensure_context() needs called when the size increases so that
new surfaces can be allocated.
Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=767474
In cases where we know the video meta must be present, add it to
the pool configuration.
Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=766184
if gst_buffer_pool_set_config returns FALSE, check the modified
config and retry set_config if the config is still acceptable.
Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=766184
There's no need to check for the display in the plugin object when
decide_allocation() vmethod is called, because the display will created or
re-created along the method execution.
Get the pool config just before use it, to avoid a memory leak if the
allocator cannot be instantiated. Similarly, return FALSE if the configuration
cannot be set, avoid keep a not used allocator in the pool.
Instead of instantiating an allocator per vaapivideobufferpool, only one
allocator is instantiated per element's pad and shared among future pools.
If the pad's caps changes, the allocator is reset.
https://bugzilla.gnome.org/show_bug.cgi?id=765435
Originally, vaapivideobufferpool has a set of boolean variables for the
buffer configuration options.
This pach changes these boolean variables for a single bitwise, just as
it is used in pluginbase. Hence, the internal enum was moved to
vaapivideobufferpool header.
https://bugzilla.gnome.org/show_bug.cgi?id=765435
This patch refactors the code in pluginbase in order to centralize the buffer
pool instantiation. As the buffer pool config may have different options, these
are gathered using a bitwise flag.
https://bugzilla.gnome.org/show_bug.cgi?id=765435
Originally vaapivideobufferpool instantiates its own allocator regardless the
received configuration, and it relies in custom configuration options to
choose which kind of allocator instantiate.
This patch transfers the responsibility of the allocator instantiate to
vaapipluginbase and pass it to the vaapivideobufferpool through its
configuration.
* gst/vaapi/gstvaapipluginbase.c
+ set_dmabuf_allocator(): inserts a dmabuf allocator in the bufferpool
+ ensure_sinkpad_buffer_pool(): set a normal vaapi video allocator in
bufferpool configuration
+ gst_vaapi_plugin_base_propose_allocation(): call set_dmabuf_allocator() if
needed.
+ gst_vaapi_plugin_base_decide_allocation(): set a normal vaapi video
allocator in bufferpool configuration
* gst/vaapi/gstvaapivideobufferpool.c
+ gst_vaapi_video_buffer_pool_set_config(): instead of instantiate the
allocator, process the received one through its configuration.
* gst/vaapi/gstvaapivideobufferpool.h: removed
GST_BUFFER_POOL_OPTION_DMABUF_MEMORY since it is not used anymore.
* gst/vaapi/gstvaapivideomemory.c
+ gst_vaapi_is_dmabuf_allocator(): new helper function to identify a dmabuf
allocator with the vaapi qdata.
https://bugzilla.gnome.org/show_bug.cgi?id=765435
