vaapipostproc: don't copy the GstParentBufferMeta if use_vpp

Otherwise a reference to a DMABuf input buffer is kept until the output
buffer is deleted.

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

libs: display: remove unnecessary legacy code since gobjectification

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

libs: display: remove unused code

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

vaapiencode: h264: log output caps

vaapiencode: h264: find profile in available and allowed caps

The commit 67e33d3de225d0e006d7bf606e7abb20d4544eab ("vaapiencode: h264:
find best profile in those available") changed the code to pick a profile
that is actually supported by the hardware. Unfortunately it dropped the
downstream constraints. This can cause negotiation failures under certain
circumstances.

The fix is split in two cases:

1\ the available VA-API caps doesn't intersect with pipeline's allowed
caps:
 * The best allowed profile (pipeline's caps) is set as the encoding
   target profile (it will be adjusted later by the available profiles
   and properties)

2\ the available VA-API caps does intersect with pipeline's allowed
caps:
 * The intersected caps are fixed, and its profile is set as the
   encoding target profile. In this case the is not the best profile,
   but the minimal one (if VA-API reports the profiles in order).
   Setting the minimal profile of the intersected caps is better for
   compatibility.

This patch fixes other tests related with caps negotiation, for
example, it handles baseline profile, even when VA only supports
constrained-baseline.

Original-patch-by: Michael Olbrich <m.olbrich@pengutronix.de>
https://bugzilla.gnome.org/show_bug.cgi?id=794306

libs: encoder: h265: increase log2_max_pic_order_cnt range according to spec

The specification says,
"log2_max_pic_order_cnt_lsb_minus4 shall be in the range of 0 to 12, inclusive."

This patch changes the upper limit from 6 to 12.

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

plugins: guard GstGL code

libs: decoder: h264: use g_clear_pointer()

libs: decoder: mpeg4, vc1: remove unused header

libs: decoder: remove unused forward declaration

fix configure.ac regression

Fixes regression introduced by 77527d67abe

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

libs: remove gstbitwriter

Since it is deployed in gstreamer-core, there is no need to use
our custom version.

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

vaapih264dec: add constrained and progressive profiles

Those profiles have been added in the version 2012-01
and 2011-06 of the AVC spec (A.2.4.1 and A.2.4.2).

Both are supported by VAProfileH264High

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

plugin: remove custom GstGL context handling

Instead of using our own context handling for looking for GstGL
parameters (display, context and other context), this patch changes
the logic to use the utility function offered by GstGL.

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

plugins: GstGL API must use the member variables

This commit basically is a revert of commits 8092537 and fc1c415

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

plugins: pass members as parameters of gst_gl_ensure_element_data()

The parameters of gst_gl_ensure_element_data() have to be not
local variable since they are going to be used to see if they're
set in gst_element_set_context() inside the API.

This is basically a revert of commit 3d56306c

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

meson: fix USE_GLES_VERSION_MASK

1. The macro in the code is USE_GLES_VERSION_MASK
2. glesv3 is provided by glesv2 pkg-config, then it's required to
   check headers

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

libs: egl: utils: mark context as wrapped when it is

The returning egl context may be null, so we should check the
return value.

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

libs: egl: utils: fix usage of GstGL macros

Include gl.h for the required GstGL symbols.

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

meson: use -Wl,-Bsymbolic-functions where supported

Just like the autotools build.

meson: use get_pkgconfig_variable()

Use get_pkgconfig_variable() method, of dependency class, rather
than using run_command().

meson: fix miscellaneous meson warnings

WARNING: Passed invalid keyword argument "rqeuired".
gst-libs/gst/base/meson.build:11: WARNING: Passed invalid keyword argument "version".
gst-libs/gst/base/meson.build:11: WARNING: Passed invalid keyword argument "soversion".
gst-libs/gst/vaapi/meson.build:223: WARNING: Passed invalid keyword argument "version".
gst-libs/gst/vaapi/meson.build:223: WARNING: Passed invalid keyword argument "soversion".

display: drm: Allow finding DRM paths out of the PCI subsystem

This removes hard-coded checks on the parent subsystem of potential DRM
devices. These checks were set to exlude devices that do not originate
from the PCI bus, which is only a valid approach on x86 devices.

Other devices may have a DRM device originating from the platform
subsystem, so the checks that were previously restricted to PCI are
extended to cover platform devices as well.

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

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>

videocontext: support wl-display in "gst.vaapi.app.Display"

Through "gst.vaapi.app.Display" context, users can set their own
VADisplay and native display of their backend.

So far we support only X11 display, from now we also support Wayland
display.

Attributes:
- wl-display : pointer of struct wl_display .

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

libs: display: wayland: add gst_vaapi_display_wayland_new_with_va_display()

Implements new API function so that users could create GstVaapiDisplay
with their own VADisplay within a native display as backend.

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

wayland: don't poll if there are no pending frames

Otherwise the following poll may not return for an arbitrary amount of
time. This can happen if another wayland event queue has flushed and read
our events.

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

libs: encoder: h265: 16 bit rounding of picture width and height

pic_width_in_luma_samples/pic_height_in_luma_samples can be 16-bit rounded
instead of 32-bit.

In addition, codedbuf_size must be calculated according to this change.

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

Automatic update of common submodule

From 3fa2c9e to ed78bee

vaapiencode: h264: find best profile in those available

Instead to look for the best profile in the allowed profiles by
downstream, the encoder should look for the base profile in the
available profile in VA-API.

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

Back to development

Release 1.14.0

libs: decoder: h264: ensure num_ref_frames is greater than 0

Even if it is the h264parse fault or bad video file, vaapih264dec
should set a proper value for VAPictureParameterBufferH264.num_ref_frames
as the driver might use it.

Also see "info.ref_frames = dpb_size;" in
gstvaapidecoder_h264.c::ensure_context

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

Release 1.13.91

Release 1.13.90

vaapipostproc: change how the metadata is copied

Instead of copying the metada in prepare_output_buffer() vmethod,
it is done in append_output_buffer_metadata() thus deinterlaced
buffers could also have the proper metas.

GstVideoCropMeta now it is copied internally and it is decided via
transform_meta() vmethod.

A new internal method, copy_metadata() was added to handle VPP
transformation where non-GstVideoVaapiMeta metas were lost.

postproc: Copy meta data from input to output

This will ensure that meta data without memory tags will be copied. This
was noticed when testing ROI.

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

tests: element: rewrite ROI test

Rewrote the ROI test to use GstVideoRegionOfInterest meta rather
than injecting GstEvents. These meta are added as a pad probe in
the queue src pad.

Also

* Use of navigation messages to control de test
* Use signal watch for processing messages
* Change to H265 rather than H264 since current intel-vaapi-driver
  only supports ROI on kabylake.
  TODO: add a parameter to change the encoder/decoder to test.

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

libs: encoder: reimplement ROI using meta

Check input buffers for ROI metas and pass them to VA. Also added a
new "default-roi-delta-qp" property in order to tell the encoder what
delta QP should be applied to ROI by default.

Enabled it for H264 and H265 encoders.

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

Revert "libs: encoder: add api gst_vaapi_encoder_add/del_roi"

This reverts commit 7a6f690340dcb3b82c59efa777d4453227851de8.

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

Revert "tests: simple-encoder: add an option to set ROI"

This reverts commit c21345c4787bb6342adddea1190f53fe62abff04.

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

Revert "vaapiencode: handle custom event GstVaapiEncoderRegionOfInterest"

This reverts commit 8f1b88dac0e64a211325cdcb2cda693b80229bd1.

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

plugins: copy input buffer metas

When importing buffers to a VA-base buffer, it is required to copy
the metas in the original buffer, otherwise information will be
lost, such as GstVideoRegionOfInterestMeta.

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

libs: surface: cast to uintptr_t pointer

According to Debian package auto-building, uintptr_t is not an
unsigned long in i386 arch, raising an "incompatible pointer type"
error.

This patch adds a casting for compiler's satisfaction in i386.

libs: encoder: add zero as valid value for periodic keyframe.

Enabled zero as valid value for keyframe-period property.

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

libs: encoder: code-style fix

vaapidecode: generate system allocated buffers

Generate system allocated output buffers when downstream doesn't
support GstVideoMeta.

The VA buffer content is copied to the new output buffer, and it
replaces the VA buffer.

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

vaapipostproc: handle system allocated buffers when required

When downstream can't handle GstVideoMeta it is required to send
system allocated buffers.

The system allocated buffers are produced in prepare_output_buffer()
vmethod if downstream can't handl GstVideoMeta.

At transform() vmethod if the buffer is a system allocated buffer,
a VA buffer is instanciated and replaces the out buffer. Later
the VA buffer is copied to the system allocate buffer and it
replaces the output buffer.

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

plugins: add gst_vaapi_copy_va_buffer()

This helper function aims to copy buffers with VA memory to dumb
buffers, when GstVideoMeta is not available dowstream.

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

plugins: add COPY_OUTPUT_FRAME flag

This patch add the member copy_output_frame and set it TRUE when
when downstream didn't request GstVideoMeta API, the caps are raw
and the internal allocator is the VA-API one.

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

plugins: store the first downstream allocator if available

The allocator will be required if we need to allocate a buffer
to store the frame with the expected strides.

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

vaapibufferpool: add gst_vaapi_video_buffer_pool_copy_buffer()

This function will inform the element if it shall copy the generated
buffer by the pool to a system allocated buffer before pushing it
to downstream.

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

vaapibufferpool: don't change config when forcing video meta

VA-API based buffer might need a video meta because of different
strides. But when donwstream doesn't support video meta we need to
force the usage of video meta.

Before we changed the buffer pool configuration, but actually this
is a hack and we cannot rely on that for downstream.

This patch add a check fo raw video caps and allocator is VA-API,
then the option is enabled without changing the pool configuration.
In this case the element is responsible to copy the frame to a
simple buffer with the expected strides.

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

vaapipostproc: set discont flag at vpp deinterlacing

When deinterlacing with VPP the discont flag was not forwarded to
the new created buffer. This patch sets the discont flag if input
buffer has it.

vaapibufferpool: remove wrong gcc annotation

libs: encoder: h264,h265: extend max periodic keyframe.

Increased max values of periodic key frame for h26x codecs.
This allow more fine tunning of encoder that in certian scenario
want higher periodic key frame.

For example: it doesn't want a key frame each 10 seconds but
each 120 seconds.

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

Back to development

Release 1.13.1

vaapi: dist new header

vaapi: register vaapisink as marginal on wayland

vaapsink, when used with the Intel VA-API driver, tries to display
surfaces with format NV12, which are handled correctly by
Weston. Nonetheless, COGL cannot display YUV surfaces, making fail
pipelines on mutter.

This shall be solved either by COGL or by making the driver to paint
RGB surfaces. In the meanwhile, let's just demote vaapisink as
marginal when the Wayland environment is detected, no matter if it is
Weston.

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

plugins: update mesa's vendor string in whitelist

Mesa has updated its VA-API Gallium driver vendor string:

https://cgit.freedesktop.org/mesa/mesa/commit/?id=5db29d62ce1fefa3f2ee6e4a4688576fde4bde4a

This patch tries to cover both, the old and the new one.

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

meson: make version numbers ints and fix int/string comparison

WARNING: Trying to compare values of different types (str, int).
The result of this is undefined and will become a hard error
in a future Meson release.

plugins: handle vaapi allocator in allocation query

In propose_allocation() if the numer of allocation params is zero, the
system's allocator is added first, and lastly the native VA-API
allocator.

In decide_allocation(), the allocations params in query are travered,
looking for a native VA-API allocator. If it is found, it is reused as
src pad allocator. Otherwise, a new allocator is instantiated and
appended in the query.

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

vaapivideomemory: remove unused macro

GST_VAAPI_VIDEO_ALLOCATOR_NAME was added in commit 5b11b8332 but it
was never used, since the native VA-API allocator name has been
GST_VAAPI_VIDEO_MEMORY_NAME.

This patch removes GST_VAAPI_VIDEO_ALLOCATOR_NAME macro.

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

vaapisink: don't mask button events for foreign windows

Don't subscribe to button press events when using a foreing window,
because the user created window would trap those events, preveting the
show of frames.

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

autotools: use -fno-strict-aliasing where supported

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

meson: use -fno-strict-aliasing where supported

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

vaapi: add NULL-sentinel to kernel_names

The array needs to be NULL-terminated according to the
gst_plugin_add_dependency() documentation.

vaapipostproc: remove spurious code

This assignation is dead code, since gst_video_info_from_caps() set
to 1 by default.

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

vaapipostproc: if no p-a-r in out caps define a range

Instead of copying the pixel-aspect-ratio from the sink caps, define
an open range for the src caps pixel-aspect-ratio. Later it will be
defined.

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

vaapisink: check for display's color-balance properties

Check for display's color-balance properties, available by the VA-API
driver, before setting them.

Also logs an info message of those unavailable properties.

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

plugins: re-using buffer pool breaks renegotiation

at propose_allocation() we should not reuse the proposed buffer,
because it could break renegotiation.

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

plugins: use g_clear_object() to unref sinkpad_buffer_pool

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

build: meson: add missing GstGL dependency

libs: utils: egl: add missing guards for GstGL

plugins: remove dmabuf-import hack

Remove the hack to check if an upstream element has enabled the
property io-mode enabled as dmabuf-import.

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

libs: egl: utils: use eglGetPlatformDisplay()

eglGetDisplay() is currently broken in Mesa for Wayland.  Also using
eglGetDisplay() is rather fragile, and it is recommended to use
eglGetPlatformDisplay() when possible.

In order to do that, this patch uses the helper in GstGL. If
gstreamer-vaapi is not compiled with GstGL support, eglGetDisplay()
will be used.

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

vaapipostproc: lock ensure_filter with postproc_lock

gst_vaapipostproc_ensure_filter might free the allowed_srcpad_caps
and allowed_sinkpad_caps. This can race with copying these caps in
gst_vaapipostproc_transform_caps and lead to segfaults.

The gst_vaapipostproc_transform_caps function already locks
postproc_lock before copying the caps. Make sure that calls to
gst_vaapipostproc_ensure_filter also acquire this lock.

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

tests: test-filter: fix dereference before null check

Null-checking op_info suggests that it may be null, but it has already
been dereferenced on all paths leading to the check.

There may be a null pointer dereference, or else the comparison
against null is unnecessary.

tests: y4mreader: fix string state checkup

str cannot be null in that moment, but it may be the end of string.

tests: y4mreader: use int for fgetc

Assigning the return value of fgetc to char truncates its value.

It will not be possible to distinguish between EOF and a valid
character.

tests: y4mreader: fix incompatible cast

Passed pointer in parse_int() are unsigned int (32 bits, unsigned) but
they are dereferenced as a wider long (64 bits, signed). This may lead
to memory corruption.

meson: fix fallback for gstreamer-gl-1.0, it's now in -base

Automatic update of common submodule

From e8c7a71 to 3fa2c9e

videoconvert: gst_element_post_message() is transfer full on msg

For this reson we need not to unref the message, even if it failed.

Revert "vaapivideocontext: possible memleak when no bus attached"

This reverts commit 0438a3e62660e64ed390b6bb83bfb560b91664aa.

test: vaapicontext: process have-context bus message

test: vaapicontext: app context is not persistent

vaapivideocontext: only vaapisink process app context

gst.vaapi.app.Display context is made for applications that will
provide the VA display and the native display to used by the
pipeline, when are using vaapisink as overlay. There are no use
case for encoders, decoders, neither for the postprocessor.

In the case of the vaapisink, it shall query for gst.vaapi.Display
upstream first, and then, if there is no reply,
gst.vaapi.app.Display context will be posted in the bus for the
application. If the application replies, a GstVaapiDisplay object
is instantiated given the context info, otherwise a
GstVaapiDisplay is created with the normal algorithm to guess the
graphics platform. Either way, the instantiated GstVaapiDisplay
is propagated among the pipeline and the have-message bus message.

Also only vaapisink will process the gst.vaapi.app.Display, if
and only if, it doesn't have a display already set. This is
caused because if vaapisink is in a bin (playsink, for example)
the need-context is posted twice, leading to an error state.

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

vaapivideocontext: log the name of GstVaapiDisplay

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

vaapivideocontext: possible memleak when no bus attached

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

libs: window: wayland: remove unused header include

Remove wayland-client.h include since there is no exposed symbols from
it.

libs: encoder: h264,h265: guard rate control's macroblock

macroblock parameter appear on VA-API 1.0.0. It should be guarded.

Automatic update of common submodule

From 3f4aa96 to e8c7a71

libs: encoder: h264: Add Hierarchical-B encode

Frames are encoded as different layers. Frame in a particular
layer will use pictures in lower or same layer as references.
Which means decoder can drop the frames in upper layer but still
decode lower layer frames.

B-frames, except the one in top most layer, are reference frames.
All the base layer frames are I or P.

eg: with 3 temporal layers

    T3:             B1            B3              B5              B7

    T2:                   B2                              B6

    T1:   I0                                P4                        P8

    T1, T2, T3: Temporal Layers
    P1...Pn:   P-Frames:
    B1...Bn:   B-frames:
    T1: I0->P4 , P4->P8 etc..
    T2: I0--> B2 <-- P4
    T3: I0--> B1 <-- B2, B2 --> B3 <-- P4

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918

libs: encoder: h264: Add Hierarchical-P encode

Frames are encoded as different layers. A frame in a particular
layer will use pictures in lower or same layer as references.
Which means decoder can drop the frames in upper layer but still
decode lower layer frames.

eg: with 3 temporal layers

T3:             P1            P3              P5              P7

T2:                   P2                              P6

T1:   P0                                P4                        P8

T1, T2, T3: Temporal Layers
P1...pn:   P-Frames:
P0->P1 , P0->P2, P2->P3, P0->P4......repeat

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918

libs: encoder: h264: Fix frame_num generation

The frame_num generation was not correctly implemented.
According to h264 spec, frame_num should get incremented
for each frame if previous frame is a referece frame.

For eg: IPBPB sequece should have the frame numbers 0,1,2,2,3

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918

libs: encoder: h264: Add new property "prediction-type"

Adds new property "prediction-type" to select different reference
picture selection modes like hierarchical-p, hierarchical-b etc.

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918

libs: encoder: h264: Add machinery for implementing hierarchical-prediction

Adds some basic building blocks to ease the implementation
of hierarchical prediction modes.

-- add an utility method to find temporal level of each frame
-- define max_ref_frame count based on temporal level count
-- add temporal_level_div[] for finding temporal level each frame
to be encoded.
-- find ip_period based on temporal level count

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918

libs: encoder: h264: Add property "temporal-levels"

Adds new property "temporal-levels" to select the number of
temporal levels to be included in the encoded stream.

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918

libs: encoder: objects: Add a reference flag

We can have p-frame as non-ref and also b-frame as ref
which are not supported yet. Reference flag
is the first machinery needed for more advanced
reference picture selection modes.

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918