gstvaapisurface_drm: fix code-style

plugins: remove unused header

Remove the include of gst/allocators/allocators.h since it is not used.

vaapivideobufferpool: remove GL_TEXTURE_UPLOAD_META

Since gstreamer-vaapi is coupled with gstreamer releases, there is no need to
keep compatibility definition.

This patch removes the definition of
GST_BUFFER_POOL_OPTION_VIDEO_GL_TEXTURE_UPLOAD_META since it is in
gst-plugins-base version 1.2.2

plugins: add gst_vaapi_buffer_pool_caps_is_equal()

This is a helper function to improve the readability of
ensure_sinkpad_buffer_pool(). It makes clearer when the buffer pool needs to be
re-instantiated.

plugins: deactivate buffer pool before unref

This buffer pool may still be processing buffers when a caps renegotiation is
done. This one-liner patch deactivates the pool to drain it before it
de-allocation.

plugins: no sinkpad bufferpool when decoder

Right now, the decoders create a buffer pool for their sink pad which is not
used at all, because the decoders have never proposed it to upstream.

This patch avoids the buffer pool instantiating when the element inherits from
the GstVideoDecoder class.

plugins: avoid to get/set pool config twice

This patch is a bit of optimization, since the bufferpool configuration is get
when the pool is created. Hence, we only need to request it when the pool from
the allocation query is reused.

plugins: destroy pool earlier if non-vaapi

If the offered pool in decide_allocation() vmethod doesn't have the
VAAPI_VIDEO_META option, it is destroyed immediatly and the pointer cleared,
so it could be created later.

vaapivideobufferpool: split caps validation

When validating the caps from bufferpool config, this patch distinguishes the
error from no caps received (NULL) from the invalid caps (cannot be converted
into GstVideoInfo structure).

plugins: check for caps in query earlier

Check for caps as soon gst_query_parse_allocation() returns.

plugins: remove unused variables

This variables stopped to be used since commit 001a5c63, which removed the
gstvaapiuploader.

plugins: fix potential memleak from commit 9159328

If gst_video_info_from_caps() fails it is required to unref the instantiated
pool.

vaapipostproc: handle if gst_video_info_from_caps() fails

Return FALSE is the received caps cannot be transformed into a GstVideoInfo
structure.

plugins: handle if gst_video_info_from_caps() fails

Let's play safe and return error if, somehow, the received caps are wrong.

plugins: relate errors to instance

Use GST_{ERROR,WARNING}_OBJECT instead of GST_{ERROR,WARNING}, thus the logs
will show the name of the vaapipluginbase instance that failed.

Also, the code-style is fixed, where some error labels need to be surrounded
by braces.

plugins: use GstVideoInfo accessors

Instead of access to GstVideInfo members directly, use their accessors
macros. This patch makes more resistance to future changes in GStreamer core.

remove spurious gst_video_info_init()

gst_video_info_set_format() and gst_video_info_from_caps() call, internally,
gst_video_info_init(), hence it is not required to call it before them. This
patch removes these spurious calls.

vaapipluginbase: code-style: rename goto label

The error labels have error_ prefix, but this one.

vaapivideomemory: use allocator custom alloc flag

Instead of a dummy alloc() vmethod, the allocator instance set the flag
GST_ALLOCATOR_FLAG_CUSTOM_ALLOC, which is used by the framework to avoid call
gst_allocator_alloc() on the allocator.

vaapivideobufferpool: relate errors to instance

Use GST_ERROR_OBJECT instead of GST_ERROR, thus the logs will show the name of
the vaapivideobufferpool instance that failed.

plugins: remove gst_vaapi_plugin_base_set_pool_config()

This function helper make sense for GStreamer 1.2, but it is not helpful for
greater version since the validation is already done in the API implementation.
Thus, it is removed.

gstvaapipluginbase: Fix typo in doc

encoder : h264: Disable b-frame encode in low-power mode

This is a workaround since vaapi-intel-driver doesn't have
support for B-frame encode when utilizing low-power-enc
hardware block.

Fixme :We should query the VAConfigAttribEncMaxRefFrames
instead of blindly disabling b-frame support and set b/p frame count,
buffer pool size etc based on the query result.

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

encoder: h264 : Use "tune=low-power" for enabling lowpower encode

Remove the duplicate property "low-power-enc" and use the
tune property for enabling low power encoding mode.

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

gstvaapiencoder:Use internal api to dervie configured VAEntrypoint

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

encoder: h264: Add support of low power/high performance encoding mode

Added a new property "low-power-enc" for enabling low power
encoding mode. Certain encoding tools may not be available
with the VAEntrypointEncSliceLP.

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

Add mapping for Macroblock level rate control (VA_RC_MB)

gstvaapidisplay: Add VAEntrypointEncSliceLP support

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

gstvaapiprofile : Add VAEntrypointEncSliceLP definitions

This is for implementations that supports low_power/high_performance
variant for slice level encode.

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

vaapipostproc: negotiate frame size fixation

Refactor _fixate_frame_size(). Now, instead of fixating the frame size only
using the sink caps, also it use the next capsfilter.

This code is a shameless copy of gst_video_scale_fixate_caps() from
https://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst/videoscale/gstvideoscale.c?id=1.8.1#n634

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

vaapipostproc: don't use GstVideoInfo for src caps

Instead of using gst_video_info_to_caps () to generated the fixed src caps,
this patch enables the first step for caps negotiation with a possible
following caps filter.

_get_preferred_caps() will traverse the possible src caps looking for the one
wit the preferred feature and the preferred color format. Then the color
format, the frame size and the frame rate are fixated.

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

vaapipostproc: move gst_vaapipostproc_fixate_srccaps()

Move gst_vaapipostproc_fixate_srccaps() to gstvaapiposptprocutil.

No functional changes.

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

vaapipostproc: simplify code

Change a convoluted snippet to find the preferred color format in the peer
caps.

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

vaapipostproc: use othercaps for preferred caps

Instead of the allowed_srcpad_caps variable, this patch uses the othercaps
from fixate_caps() vmethod to find the preferred caps feature and color
format.

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

vaapipostproc: add fixate_caps() vmethod

Instead of fixating the srcpad caps in transform_caps() vmethod, this patch
implements the fixate_caps() vmethod and moves code around.

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

vaapipostproc: set early properties restrictions

When running transform_caps() vmethod, returning the srcpad caps, the caps are
early restricted to the element properties set: width, height, format and
force keep aspect.

A new file was added gstvaapipostprocutil.{c,h} where the utilities functions
are stored.

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

vaapipostproc: log the caps transformation

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

vaapipostproc: no GLTextureUpload in sinkpad

As the vaapipostproc does not process frames with the VideoGLTextureUpload
meta, the feature is removed from the sink pad template.

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

vaapibufferpool: do not create texture upload meta if dmabuf

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

build: update git.mk

plugin: fix macro processor check

Instead of #ifdef it should be used #if becasuse USE_GST_GL_HELPERS is always
defined in config.h, but it would be 0 or 1 depending on the configure output.

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

tests: display: guard possible unused variables

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

tests: inforce gstreamer code-style

encoder: h265: Enable cu_qp_delta_enabled_flag for CBR

It seems driver requires enablement of cu_qp_delta_enabled_flag
for modifying QP values to controll the CBR mode bitrate.

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

encoder: h265: Add CBR Encoding support

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

gstvaapisurface: explicitely clear TILING flag if dmabuf

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

gstvaapisurface_drm: release image when done

Otherwise intel-vaapi-driver will fail to process the exported surface because
it will find it is currently derived, so considered as busy.

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

vaapipostproc: already have a surface proxy if dmabuf

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

various gst-indent

vaapidecode: search driver in whitelist

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

plugins: rework set_context() vmethod definition

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

vaapipostproc: resize if negotiated and allocation caps are different

Since commit 859a2b2, in vaapidecode, allocation query can be different from
the negotiated caps.

When connecting the vaapidecoder to the vaapipostprocessor, the last one will
resize the frame to the negotiated, if and only if, some other parameter is
activated to avoid the passthrough. If it is not, the surface won't be mapped
into a image. If not, the image won't be resized and the output buffer would be
mapped.

This patch will break the passthrough if the allocation query is different
from the negotiation caps, forcing the resizing.

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

vaapidecode: improve code readability

No functional changes.

vaapidecode: move GstCapsFeatures near to its use

Move the handling of the GstCapsFeatures just after it is used, in order to
avoid handling its memory.

vaapidecode: caps negotiation checks

Check that GLUploadTexture is not negotatiated if gstreamer-vaapi is not
compiled with GL support.

plugins: remove param in gst_vaapi_plugin_base_decide_allocation()

vaapidecode: bail early if not caps in decide_allocation()

plugin: use allowed caps filter from element

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

plugin: remove function parameter

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

vaapidecode: warns if driver will do color conversions

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

plugin: honour negotiated format

Instead of setting the requested format by the caller, the function
gst_vaapi_find_preferred_caps_feature() now returns, in the output parameter,
the negotiated format.

A new helper function was added: gst_vaapi_find_preferred_format(), which,
given the format list from the negotiated caps, will choose the best one, if
possible, given the native format.

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

plugin: simplify caps feature selection

This patch simplifies the function gst_vaapi_find_preferred_caps_feature().

Instead of intersecting custom caps to find the preferred feature, the peer
caps are traversed in order to find the preferred feature, according to an
ordered feature priority list.

In the case of GLTextureUploadMeta, the colour format is computed using
GstVideoInfo of the selected fixed caps.

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

vaapidecode: use macros for GstVideoInfo

Instead of accessing directly to the members of the structure, use the macros.

vaapidecode: refactor is_display_resolution_changed()

Make the comparisons more readable and simple.

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

vaapidecode: keep only display_{width,height}

Instead of keeping the structure GstVideoInfo when we are using its width and
height, we only keep these two guints.

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

vaapidecode: decoded_info is valid at src caps update

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

vaapidecode: always a valid format in decoded_info

Always set a valid format in decoded_info class variable.

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

vaapidecode: code style fixes

No functional changes.

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

vaapidecode: init {decoded,display}_info at open()

It is required to initialize {decoded,display}_info variables when the decoder
is open, not only at instance initialization.

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

vaapidecode: remove spurious class variables

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

remove custom allocation query

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

Automatic update of common submodule

From 6f2d209 to ac2f647

plugins: disable GL_TEXTURE_UPLOAD if no EGL/GLX

The plugins should not expose the feature meta:GstVideoGLTextureUploadMeta in
their caps templates if they were not compiled either with GLX or EGL support.

plugins: fix compilation when EGL/GLX is disabled

The compiler might complain of gst_vaapi_create_display_from_handle() being
unused if both EGL and GLX are disabled. This patch avoid that compilation
error.

libs: fix deleting a GstVaapiCodedBufferPool object

Call gst_vaapi_video_pool_finalize() in coded_buffer_pool_finalize().
Otherwise it is not called when the pool is destroyed and all objects
referenced by the GstVaapiVideoPool are never released.

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

surface: destroy derived image

If gst_vaapi_image_new_with_image() fails, the created derived image should be
destroyed, otherwise the surface cannot be processed because is being used.

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

vaapidecode: add stop function

Clear any status on the current stream:

stored frames, caps and decoder configuration

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

decoder: vp9: Align with the ABI changes in vp9 codecparser

The subsampling_x, subsampling_y, bit_depth, color_space and color_range
fileds are moved from GstVp9FrameHdr to the global GstVp9Parser structure.
These fields are only present in keyframe or intra-only frame, no need to
duplicate them for inter-frames.

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

decoder: vp9 : Add 10bit decoding support (Profile2)

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

gstvaapiporfile: Add more VP9 profile definitions

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

build: possibility to disable tests

The configuration option --disable-examples will disable the compilation of
the sample apps in tests/ directory.

unify caps template for VAAPI encoders and decoders

There is no difference in VAAPI surface caps between encoders and decoders.
Thus, the patch makes a simplification by removing encoders specific caps and
shares the same definition of VAAPI surfaces caps for all the elements.

vaapidecode: move gst_vaapidecode_negotiate() code

With it we can remove a function declaration, making the code a bit
more readable.

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

docs: generate vaapijpegdec documentation

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

decoder: h265: Fix offset calculation when there is more than one vps/sps/pps present in codec_data

The array_completeness, reserved bit and num_nal_units fields
in HEVCDecoderConfigurationRecord will be present for each VPS/SPS/PPS array list,
but not for each occurance of similar headers.

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

video-format: Keep the HW order preference while mapping to GstVideoFormats

gst/vaapi: keep precedence for NV12 over I420

Use NV12 as default "assumption" format all over.
NV12 is the default high priority format used my most of the
vaapi-drivers.

vaapidecode: Use video format derived from decoded surface as default src pad format

Use the surface format derived from first decoded surface
to negotiate the downstream video format capabilities.

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

Add P010 video format 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

libs: x11: allows 30-bit colour depth

The colour depth is clamped to 24 when it is not equal {15,16,24,32}. But this
fails with the NVIDIA binary driver as it doesn't advertise a TrueColor visual
with a depth of 24 (only 30 and 32). Allowing the depth to be 30, lets everything
work as expected.

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

gltextureupload: use an array for texture type

Instead of using a single value for the texture type, use an array with 4
elements, just as the GstVideoGLTextureUploadMeta, avoiding a buffer
overflow.

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

vaapidecode: Fix decide_allocation handling

Set the already configured pool in decide_allocation query
in cases where pool renegotiation is not required.

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

vaapidecode: Derive and save the decoded surface format

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

Make vaapidecode to advertise the cropped values in srcpad, but negotiate pool only if needed

-- 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

vaapidecode: Delay the output format setting until we have a decoded surface

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

vaapidecode: GST_VAAPIDECODE macro is a cast

This patch is the continuation of commit 1e1d3b1d because the function
gst_vaapidecode_get_type() got undefined since then.

Now, the macro GST_VAAPIDECODE is a simple cast to the GstVaapiDecode
structure. The rest of the GObject handling macros were deleted too.

Back to development

Release 1.8.0

Release 1.7.91

decoder: h265: Fix offset calculation in codec_data parsing

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