vaapivideomemory: log error if not VA image

Log an error message if the test image for surface downloading
cannot be allocated or mapped.

vaapivideomemory: remove unused macros

These macros are not used. Let us remove them.

vaapivideomemory: rename video for allocation_info

Since video_info stores the GstVideoInfo of the allocation caps,
it is clear if we rename it as allocation_info, to distinguish it
later from negotiation_info.

vaapivideomemory: add real GstVaapiDmaBufAllocator

Instead of defining GstVaapiDmaBufAllocator as a hackish decorator of
GstDmaBufAllocator, now, since the expose of the GstDmaBufAllocator's
GType, GstVaapiDmaBufAllocator is a full feature GstAllocator inherited
from GstDmaBufAllocator.

https://bugzilla.gnome.org/show_bug.cgi?id=755072

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

vaapivideomemory: errors in gst_vaapi_dmabuf_allocator_new()

Add a helper function to initialize the gst_debug_vaapivideomemory,
to use it either by the GstVaapiVideoAllocatorClass or
GstVaapiDmabufAllocator (which is a decorator of GstDmaBufAllocator).

Later, log possible errors when calling gst_vaapi_dmabuf_allocator_new ()

https://bugzilla.gnome.org/show_bug.cgi?id=755072

vaapiencode: release internal encoder at stop()

As the internal encoder is created at start(), let's release it at
stop() vmethod, to be consistent.

gst_vaapiencode_destroy() is called since it also resets the input and
output states, which is something that the base class does internally
after calling stop() vmethod.

https://bugzilla.gnome.org/show_bug.cgi?id=769266

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

Automatic update of common submodule

From f49c55e to 39ac2f5

vaapiencode: call ensure_encoder() at start()

Currently, specific encoder is created during set_format(). This might
lead to race condition when creating profiles with multiple encoders.

This patch moves ensure_encoder() call to start() vmethod to ensure
avoiding the race condition.

https://bugzilla.gnome.org/show_bug.cgi?id=773546

vaapidecodebin: bring back dynamic configuration

In commit ca0c3fd6 we remove the dynamic configuration if the bin
because we assumed that the bin will be always static as it is
registered.

Nonetheless we were wrong, because it is possible to request, with a
property, to avoid the use of the post-processor.

Since we want to add a way to disable the post-processor through
environment variables, this remove feature is required again.

If the environment variable GST_VAAPI_DISABLE_VPP is defined the
postprocessor inside of the vaapidecodebin is disabled, then
vaapidecodebin is an alias of the old vaapidecode.

https://bugzilla.gnome.org/show_bug.cgi?id=775041

vaapidecode: implement negotiate() vmethod

Instead of decorating the negotiate() method, let us override it,
so the stream is locked while called.

https://bugzilla.gnome.org/show_bug.cgi?id=775040

common: use https protocol for common submodule

https://bugzilla.gnome.org/show_bug.cgi?id=775110

build: add LIBVA_WAYLAND_CFLAGS to libgstvaapiegl

In case libva-wayland has its headers not installed in default
locations (like /usr/include), the build fails to include "wayland-client.h":

   CC       libgstvaapi_egl_la-gstvaapiutils_egl.lo
 In file included from gstvaapidisplay_wayland.h:27:0,
                  from gstvaapidisplay_egl.c:35:
 /usr/include/va/va_wayland.h:31:28: fatal error: wayland-client.h: No such file or directory
  #include <wayland-client.h>

As we already passed VA_CLAGS, /usr/include/va/va_wayland.h could be found, but it is
our fault not to instruct the system that we ALSO care for va_wayland. We correctly query
for libva-wayland.pc in configure and use this in other places as well. It is thus only
correct and consequent, to do it also at this spot.

https://bugzilla.gnome.org/show_bug.cgi?id=773946

vaapivideocontext: log a message if no bus

Raise a warning if there is no bus when the element tries to post a
message.

vaapisink: create display at open()

Instead of creating the VA display before setting the bus to the
element, it is created when the element is opened.

Basically, this commit is a revert of
5e5d62cac79754ba60057fc2516135aad8d7de35

That was done when the GStreamer's context sharing was not mature
enough as now. There is no reason to keep this hack.

vaapidecode: don't add video crop meta

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

remove the video converter from vaapi buffer meta

Since all the video converter were deprecated in gstreamer-1.2, we don't need
to handle them anymore in the vaapi's buffer meta.

This patch removes its usage and the buffer meta's API for that.

https://bugzilla.gnome.org/show_bug.cgi?id=745728

plugins: destroy source pad allocator and pool

First, deactivate source pad pool when the out caps change, and if so,
destroy texture map, the source pad allocator and pool only if the
new caps are different from the ones already set.

plugins: don't destroy sink pad allocator

Don't destroy sink pad allocator at _set_caps() because it will be done at
ensure_sinkpad_buffer_pool() if it is required.

plugins: first validate the out caps

When calling _set_caps() first validate the out caps before doing
anything else.

vaapidecode: negotiate after destroying allocator

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.

vaapivideomemory: remove GST_VAAPI_TYPE_VIDEO_INFO

Remove redundant GST_VAAPI_TYPE_VIDEO_INFO, since it is a duplicate of
GST_TYPE_VIDEO_INFO created before gstreamer 1.6, where the boxed type
was created.

https://bugzilla.gnome.org/show_bug.cgi?id=774782

plugins: update the src pad allocator video info

Update the size, stride and offset of the source pad allocator video
info, so the pool could set the correct GstVideoMeta

https://bugzilla.gnome.org/show_bug.cgi?id=774782

vaapivideomemory: add missing documentation

https://bugzilla.gnome.org/show_bug.cgi?id=774782

plugins: use early return without goto

https://bugzilla.gnome.org/show_bug.cgi?id=774782

plugins: add allocator to allocation query

This patch adds the created allocator to the allocation query either
in decide_allocation() and propose_allocation() vmehtods.

With it, there's no need to set the modified allocator's size in the
pool configuration.

https://bugzilla.gnome.org/show_bug.cgi?id=774782

vaapivideobufferpool: set correct buffer size

We should set the correct buffer size when we are configuring the pool,
otherwise the buffer will be discarded when it returns to the pool.

Indeed when the ref-count of a buffer reaches zero, its pool will queue
it back (and ref it) if, and only if, the buffer size matches the
configured buffer size on the pool.

This issue can be debugged with GST_DEBUG=*PERF*:6, see gstbufferpool.c

https://bugzilla.gnome.org/show_bug.cgi?id=774782

vaapivideomemory: check for memory allocator

When calling gst_vaapi_video_memory_copy() the allocator of the memory
to copy should be allocated by the vaapi allocator.

This patch does this verification.

vaapivideomemory: code style fixes

A cosmetic commit for enhance readability of the casts and method
preconditions.

vaapivideomemory: unroll gst_vaapi_video_allocator_free()

Instead of having a gst_vaapi_video_memory_free() that is only going to
be called by gst_vaapi_video_allocator_free(), let's just remove the first
and merged into the second.

vaapivideomemory: avoid virtual methods casting

Use the expected virtual method signatures for readability.

vaapivideomemory: remove unimplemented methods

Remove unimplemented method for allocator mem_share() and mem_is_span().

vaapivideomemory: fail if frame map can't get plane

If map() vmethod in GstVideMeta cannot get the plane data, return false,
thus the caller will not try to read invalid memory.

https://bugzilla.gnome.org/show_bug.cgi?id=774213

vaapivideomemory: lock map and unmap operations

In order to avoid race condition when two threads call map/unmap the same
VA surface, this patch mutex these operations.

https://bugzilla.gnome.org/show_bug.cgi?id=774213

vaapivideomemory: refactor vaapi memory unmapping

There were duplicated code in gst_video_meta_unmap_vaapi_memory() and
gst_vaapi_video_memory_unmap() when unmapping.

This patch refactors both methods adding the common function
unmap_vaapi_memory(). This also ensures, if direct rendering is enabled, it
is correctly reset.

Additionally, only when mapping flag has the WRITE bit, it set the image as
current, which was done in gst_video_meta_map_vaapi_memory() but no in
gst_vaapi_video_memory_map().

In order to make this, the mapping flags were required, so instead of
overloading mem_unmap() virtual function, mem_unmap_full() is overloaded.

https://bugzilla.gnome.org/show_bug.cgi?id=774213

vaapivideomemory: refactor vaapi memory mapping

There were duplicated code in gst_video_meta_map_vaapi_memory() and
gst_vaapi_video_memory_map() when doing the READ and WRITE mapping.

This patch refactors both methods adding the common function
map_vaapi_memory().

Additionally, only when flag has the READ bit it calls
ensure_images_is_current(), which was done in
gst_video_meta_map_vaapi_memory() but no in
gst_vaapi_video_memory_map().

https://bugzilla.gnome.org/show_bug.cgi?id=772151

vaapidecode: unref allowed_sinkpad_caps at close()

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.

vaapisink: finish event thread at stop()

The thread that handles window's events should be finished during
pipeline's shutdown, otherwise it will remain alive during pipeline
re-activation, leading to unexpected problems.

This patch fixes failures of intensive_state_change scenario of
gst-validate

https://bugzilla.gnome.org/show_bug.cgi?id=774241

vaapipostproc: enhance debug message

"gst_pad_push" is not a good description of the event.

postproc: honor gst_pad_push() return value

Returning GST_FLOW_ERROR always when gst_pad_push fails might lead to
deadlock during seek.

This patch returns the same error of gst_pad_push() and log out the
return value.

https://bugzilla.gnome.org/show_bug.cgi?id=774030

vaapidecode: guard GST_VAAPI_MAKE_GLTEXUPLOAD_CAPS

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.

vaapivideomemory: increment map counter only if succeeded

Previously the frame map counter increased independently if the map succeeded
or not. This leaded to critical messages and crashes if the frame was unable
to be mapped, but the counter increased.

This patch increases the map counter only if the map operation occurred.

https://bugzilla.gnome.org/show_bug.cgi?id=773939

plugins: set negotiation caps in src allocator

When the allocator is created, it stores the allocation caps. But sometimes
the "allocation caps" may be different from the "negotiation caps".

In this case, the allocator should store the negotiation caps since they
are the ones used for frame mapping with GstVideoMeta.

When vaapispostproc is used, this is not a problem since the element is assume
to resize. But when using a vaapi decoder only, with a software renderer, it
fails in this case.

https://bugzilla.gnome.org/show_bug.cgi?id=773323

vaapidecode: generate source pad caps

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.

libs: decoder: add _get_surface_formats()

This function exposes the available formats of the surfaces in the the current
context to the plugins.

libs: context: ensure context formats

This patch ensures to get the formats, as filter does, available in the
decoder / encoder context.

The context fills up the array as soon it is created, otherwise the pipeline
could get stalled (perhaps this is a bug in my HSW backend).

https://bugzilla.gnome.org/show_bug.cgi?id=752958

libs: move get_surface_formats to utils_core

The query of all the supported formats for a VA config were only used by the
postprocessor (vaapifilter). But, in order to enable the vaapidecoder to
negotiate a suitable raw format with downstream, we need to query these
formats against the decoder's config.

This patch is the first step: moves the code in filter's ensure_image() to a
generic gst_vaapi_get_surface_formats() in vaapiutils_core, so it can be
shared later by the decoder.

https://bugzilla.gnome.org/show_bug.cgi?id=752958

plugins: remove set_sinkpad_dmabuf_allocator()

Since when the sink pad allocator is created, it is decided if the required
one is vaapi allocator or dmabuf allocator, there is no need to force its set
again.

plugins: ensure display when getting raw caps

When running gst-discoverer-1.0, in certain media, vaapipostroc is stopped
meanwhile it is transforming caps. The problem is that stop() calls
gst_vaapi_plugin_base_close(), which nullifies the element's va display, but
the va display is used in tranform_caps() when it is extracting the possible
format conversions. This display disappearing generates warning messages.

This patch holds a local reference of va display at ensure_allowed_raw_caps()
hence it doesn't go away meanwhile it is used, even if the
gst_vaapi_plugin_base_close() is called in other thread.

https://bugzilla.gnome.org/show_bug.cgi?id=773593

plugins: fix code style for errors

libs: fix code style for errors

plugins: update GstGL deprecated symbol

GST_GL_TYPE_CONTEXT was deprecated. Now it is GST_TYPE_GL_CONTEXT.

plugins: direct render when raw video

Enable the direct rendering with linear surfaces if the negotiated src caps
are video/x-raw without features.

Pass also the caps, since they are needed to know the requested caps features.

plugins: move src allocator error to instantiator

Just as we did in ensure_sinkpad_allocator(), let's move the error message
into the ensure_srcpad_allocator() from the caller,
gst_vaapi_plugin_base_decide_allocation()

plugins: enable direct upload if raw video

Enable the direct upload with linear surfaces if the negotiated sink caps are
video/x-raw without features.

pluginutil: add gst_caps_is_video_raw()

plugins: receive caps in ensure_sinkpad_allocator()

Instead of receiving the GstVideoInfo structure as parameter, get the original
GstCaps from ensure_sinkpad_buffer_pool(), in this way we could decide better
which allocator instantiate.

vaapivideomemory: destroy derived image at unmap

If the allocator was configured to use direct upload or rendering, the
generated derived image created at mapping needs to be destroyed after
unmapping, because, in order to process the surface, it should not be marked
as "busy" by the driver.

vaapivideomemory: enhance logs for direct modes

Print, conditionally, only the enabled direct mode.

vaapivideomemory: add direct upload flag

Adds the direct-upload flag in the GstVaapiVideoAllocator and
GstVaapiVideoMemory.

It still doesn't apply any functional change.

vaapivideomemory: set direct rendering at run-time

The way to experiment with the direct rendering is through and internal
compiler pre-processor flag.

The current change set enables a way to specified at run-time, as a flag
passed to the allocator at instanciation time.

vaapivideomemory: log in perf category when copy

Log in performance category when the derive image handling fails, falling back
to memory copy.

vaapivideomemory: error log is derive image fails

Instead of a silently failure of the derive image, this patch log an error
message according to the failure.

vaapivideomemory: store surface alloc flags in qdata

For sake of consistency, we should add the requested surface allocation flags
to the object's qdata structure.

vaapivideomemory: category init when object define

Move the Gstreamer debug category initialize to the GObject definition.

libs: vaapitexturemap: trivial code-style fix

libs: display: egl: avoid recreate native display

Instead of passing the native descriptor of the display, just pass the received
GstVaapiDisplay and reuse it.

plugins: log the GstVaapiDisplay name

Now that GstVaapiDisplay is descendant of GstObject, it has a human-friendly
name. Log it instead of the memory address.

libs: window: egl: pass native va display

When creating a GstVaapiWindowEGL, it also creates native window by its own
native display. It should pass the native display, either X11 or Wayland.

https://bugzilla.gnome.org/show_bug.cgi?id=768266

libs: display: GstVaapiDisplay as GstObject descendant

This patch is to change the inheritance of GstVaapiDisplay to GstObject,
instead of GstVaapiMiniObject. In this way we can use all the available
infrastructure for GObject/GstObject such as GstTracer, GIR, etc.

In addition, a new debug category for GstVaapiDisplay is created to make it
easier to trace debug messages. It is named "vaapidisplay" and it transverse
all the VA display backends (DRM, GLX, EGL, Wayland, ...)

This patch is a step forward to expose GstVaapiDisplay for users in a future
library.

https://bugzilla.gnome.org/show_bug.cgi?id=768266

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

Back to development

Release 1.10.0

vaapidecodebin: resurrect disable-vpp property

https://bugzilla.gnome.org/show_bug.cgi?id=773589

vaapidecodebin: name the internal queue

https://bugzilla.gnome.org/show_bug.cgi?id=773589

vaapidecodebin: remove unused variables

Since vaapipostproc is only registered if the driver supports it, all the
support for dynamic loading were removed. Though some leftovers remained.

https://bugzilla.gnome.org/show_bug.cgi?id=773589

docs: document environment variables

https://bugzilla.gnome.org/show_bug.cgi?id=773544

docs: replace vaapidecode with each codec

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.

docs: add missing long descriptions

vaapipostproc: use GST_*_OBJECT when possible

Since we can have several vaapipostproc operating in a pipeline, it is useful
to know which one is generating the logging message.

https://bugzilla.gnome.org/show_bug.cgi?id=773497

vaapidecode: rename member to allowed_sinkpad_caps

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

plugins: fix code style for errors

https://bugzilla.gnome.org/show_bug.cgi?id=773497

vaapivideomemory: comment style

https://bugzilla.gnome.org/show_bug.cgi?id=773497

vaapivideomemory: rename input parameter

In order to clarify the use of flag as input parameter, it is renamed to
surface_alloc_flag, since it is used when creating a VA surface with certain
properties.

https://bugzilla.gnome.org/show_bug.cgi?id=773497

vaapidecode: rename element description

So encoders and decoders have similar descriptions.

https://bugzilla.gnome.org/show_bug.cgi?id=773497

vaapiencode: h264, h265: rename codec name

So encoder and decoders have the same codec name.

https://bugzilla.gnome.org/show_bug.cgi?id=773497

plugins: simplify code

Merge two lines of variable declarations.

https://bugzilla.gnome.org/show_bug.cgi?id=773497

libs: minor correction for logical consistency

GstVaapiDecode is a descendant of GstVaapiMiniObject, so, thought we should
use its methods, even though it doesn't change functionality.

GstVaapiPixmap, GstVaapiTexture and GstVaapiWindow are descendant of
GstVaapiObject, hence its methods shall be used.

https://bugzilla.gnome.org/show_bug.cgi?id=772554

vaapivideomemory: add explanation about the call 'dup (dmabuf_fd)'

In short GstFdMemory is configured to call close when using
GstDmabufMemory.

https://bugzilla.gnome.org/show_bug.cgi?id=755072

build: clean up the dlopen usage

encoder: h264,h265: fix regression in offset count

In commit dc35dafa a bug was introduced because I assumed that
GST_CLOCK_TIME_NONE is zero when is -1. This patch fixes that mistake.

https://bugzilla.gnome.org/show_bug.cgi?id=772259

docs: update README

libs: display: egl: remove unused header include

The header gmodule.h is not used since the library dynamic loading for EGL
display was removed.

https://bugzilla.gnome.org/show_bug.cgi?id=772599

Release 1.9.90

vaapi: use new gst_element_class_add_static_pad_template()

https://bugzilla.gnome.org/show_bug.cgi?id=763083

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

plugins: reset textures at negotiation/shutdown

When caps reconfiguration is called, the new downstream frame size might be
different. Thus, if the downstream caps change,the display's texture map is
reset.

In addition, during pipeline shutdown, textures in texture map have to be
released, since each one have a reference to the GstVaapiDisplay object, which
is a dangerous circular reference.

https://bugzilla.gnome.org/show_bug.cgi?id=769293

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

libs: display{egl,glx}: cache GstVaapiTextures

instances when created and reuse

This patch improves performance when glimagesink uploads a GL texture.

It caches the GStVaapiTexture instances in GstVaapiDisplay{GLX,EGL}, using an
instance of GstVaapiTextureMap, so our internal texture structure can be found
by matching the GL texture id for each frame upload process, avoiding the
internal texture structure creation and its following destruction.

https://bugzilla.gnome.org/show_bug.cgi?id=769293

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

libs: vaapitexturemap: implement GstVaapiTextureMap

Implement GstVaapiTextureMap object, which caches VAAPI textures, so them can be
reused. Internally it is a hash table.

Note that it is GstObject based rather than GstVaapiObject, as part of the future
converstion to GstObject of most of the code.

https://bugzilla.gnome.org/show_bug.cgi?id=769293

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

encoder: vp8: Increase the allocation size for coded buffer

We are not getting enough compression for some streams and
encoded frame end up with more size than allocated.
Assuming a compression ratio of 4, which should be good enough
for holding the frames.

https://bugzilla.gnome.org/show_bug.cgi?id=771528

encoder: vp9: Fix refresh frame flag setting

While doing the mode-1 referece picture selection,
the circular buffer logic was not correctly setting the
refresh frame flags as per VP9 spec.
Make sure refresh_flag[0] get updated correclty after
each cycle of GST_VP9_REF_FRAMES.

https://bugzilla.gnome.org/show_bug.cgi?id=771507

vaapidecode: codec_data minimal size is 7

When the format of a H.264 stream is AVC3, the SPS and PPS are inside the
stream, not in the codec_data, so the size of codec_data might be 7.

This patch reduces the minimal size of the codec_data buffer from 8 to 7.

https://bugzilla.gnome.org/show_bug.cgi?id=771441

vaapidecode: reset decoder hard when set_format()

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