plugins: base: add GstVideoAggregator subclass support

libs: image: init all image fields correctly.

doc: fix pipeline typo in vaapipostproc

libs: encoder: modify 265 VPS header fields.

vps_base_layer_internal_flag and vps_base_layer_available_flag
have been clearly defined now.

libs: display: fix a resource leak in X11 pixmap format.

libs: utils: delete useless gst_vaapi_profile_caps_append_encoder.

libs: encoder: get surfaces resolution the same time with formats.

We can get all the information about the video format at one shot
when we create the test context for getting the supported formats.

The current way to get the width and height ranges are inefficient,
since it calls the function gst_vaapi_profile_caps_append_encoder()
and it creates another temporal context to detect the resolution
information.

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

libs: encoder: vp9: fix code style

libs: encoder: set entrypoint based on tune automatically

Some profile, such as H265_MAIN_444 on new Intel platform, may only
support ENTRYPOINT_SLICE_ENCODE_LP entrypoint. This leads two
problems:

1. We need to specify the tune mode like `vaapih265enc tune=low-power`
   every time when we need to use this kind of profile. Or we can not
   create the encoder context successfully.

2. More seriously, we set the entrypoint to a fixed value in
   init_context_info() and so the create_test_context_config() can not
   create the test context for these profile and can not get the
   supported video formats, either.

We now change the entrypoint setting based on the tune option of the
encoder. If no tune property provided, we just choose the first
available entrypoint.

libs: encoder: set context info profile by encoder

Instead of init_context_info() setting the passed profile, it is
assumed that it has to be set by each encoder.

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

libs: context: add invalid entrypoint symbol

The symbol GST_VAAPI_ENTRYPOINT_INVALID is just a representation of
zero, which was already used as an invalid value tacitly. This patch
only makes it explicit.

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

libs: pixmap: Fix a pixmap creation crash.

We use GST_VAAPI_OBJECT_NATIVE_DISPLAY with wrong parameter for x11
pixmap creation, which causes crash if we run the internal test case
of:

test-decode --pixmap

plugin: encode: set allowed_sinkpad_caps to empty.

We now set encode->allowed_sinkpad_caps to NULL if we fail to get
surfaces formats. This causes two problem:
1. gst_video_encoder_proxy_getcaps use NULL as its caps parameter,
which changes its behavior. It will use encode's sinkpad template
rather than empty caps to do the clip job. So even if we fail to set
allowed_sinkpad_caps, gst_video_encoder_proxy_getcaps can still return
valid caps.
2. We should just set the allowed_sinkpad_caps once. The NULL point
make the ensure_allowed_sinkpad_caps function works again and again.

libs: encoder: Add NULL pointer check for context when finalize.

Context may be NULL if pipeline fail in early stage, and the
ensure_context will not be called. Need to add a pointer protection
for it.

plugins: base: do not reset can_dmabuf

Don't reset the can_dmabuf field.  This restores the
close/reset logic that existed prior to commit
ca2942176b5632e07eebac23336954f9aaf1cb26 in regards to
dmabuf support.

Plugins only call gst_vaapi_plugin_base_set_srcpad_can_dmabuf
once during startup, but may need to reset the other private
fields multiple times during negotiation.  Thus, can_dmabuf
should be exempt from the resets.

Fixes #208

plugin: encode: Refine encode's sink caps.

The old manner to get the encode's sink caps is not correct.
Such as 264 encode, it gets:

video/x-raw(memory:VASurface),
format=(string){ ENCODED, NV12, I420, YV12, YUY2, UYVY, Y210,
P010_10LE, AYUV, Y410, Y444 }, width=(int)[ 32, 4096 ],
height=(int)[ 32, 4096 ], framerate=(fraction)[ 0/1, 2147483647/1 ];
video/x-raw(memory:DMABuf), format=(string){ I420, YV12, RGBA },
width=(int)[ 32, 4096 ], height=(int)[ 32, 4096 ],
framerate=(fraction)[ 0/1, 2147483647/1 ];
video/x-raw, format=(string){ NV12 }, width=(int)[ 32, 4096 ],
height=(int)[ 32, 4096 ], framerate=(fraction)[ 0/1, 2147483647/1 ]

where the formats for memory:VASurface and memory:DMABuf are superfluous.
All the "I420, YV12, YUY2, UYVY, Y210, RGBA" can not be really used as
input format for encoder.

We should get:
video/x-raw, format=(string){ NV12 }, width=(int)[ 32, 4096 ],
height=(int)[ 32, 4096 ], framerate=(fraction)[ 0/1, 2147483647/1 ];
video/x-raw(memory:VASurface), format=(string){ NV12 },
width=(int)[ 32, 4096 ], height=(int)[ 32, 4096 ],
framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw(memory:DMABuf),
format=(string){ NV12 }, width=(int)[ 32, 4096 ],
height=(int)[ 32, 4096 ], framerate=(fraction)[ 0/1, 2147483647/1 ]

as the correct result.

libs: display: code clean up

libs: display: refine the profile/entrypoint map.

The old way make the one config for each profile/entrypoint pair,
which is not very convenient for description the relationship
between them. One profile may contain more than one entrypoints
to within it, so a set like data structure should be more suitable.

libs: surface: port to GstMiniObject

GstVaapiMiniObject and GstVaapiObject are deprecated.

This is the first step to remove them by porting GstVaapiSurface as
a GstMiniBuffer descendant.

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

libs: surface: rename create function names to init

There are several internal functions with 'create' name, but they
don't create any new structure, but rather it initializes that
structure. Renaming those function to reflect better their purpose.

libs: surface: use macro accessors

libs: surface: fix internal documentation

libs: codedbuffer: port to GstMiniObject

GstVaapiMiniObject and GstVaapiObject are deprecated.

This is the first step to remove them by porting GstVaapiCodedBuffer
as a GstMiniBuffer descendant.

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

libs: image: port to GstMiniObject base class

GstVaapiMiniObject and GstVaapiObject are deprecrated. This is the
first step to remove them, by porting GstVaapiImage as a
GstMiniObject.

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

libs: context: port to a plain C structure

The GstVaapiMiniObject is obsolete and we need to replace it. This
patch turns GstVaapiContext into a plain C structure with its own
reference counting mechanism.

Also this patch removes unused overlays attributes.

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>

plugin: encode: change the dmabuf caps to all supported formats.

The encode's dmabuf caps definition is obsolete, it can support
more formats now. Re-define it to include all supported formats
in video format map.

libs: encoder: h264fei: remove unnecessary check

Issue detected by Coverity

`info_to_pack.h264_slice_header` is always allocated by
gst_vaapi_feipak_h264_encode(), thus checking it to free it afterwards
in doesn't make much sense.  But it requires to be free on the error
path.

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

In gst_vaapi_encoder_h264_fei_encode: All paths that lead to this null
pointer comparison already dereference the pointer earlier

libs: encoder: h264fei: remove unnecessary assert

Issue detected by Coverity

An unsigned value can never be negative, so this test will always
evaluate the same way.

In add_slice_headers: An unsigned value can never be less than 0

libs: encoder: h264fei: remove unnecessary check

Issue detected by Coverity

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

In gst_vaapi_encoder_h264_fei_encode: All paths that lead to this null
pointer comparison already dereference the pointer earlier

libs: encoder: h264fei: don't free memory on stack

Issue detected by Coverity

`info_to_pak` variable in gst_vaapi_encoder_h264_fei_encode() is
declared in the stack, but it is free in
gst_vaapi_feienc_h264_encode() as if declared on the heap.

This patch initializes the structure and removes the free.

A non-heap pointer is placed on the free list, likely causing a crash
later.

In gst_vaapi_encoder_h264_fei_encode: Free of an address-of
expression, which can never be heap allocated.

libs: encoder: h264fei: fix surface leak

Issue detected by Coverity

If the FEI mode is not handled the created resources should be
released and return and error code.

The system resource will not be reclaimed and reused, reducing the
future availability of the resource.

In gst_vaapi_encoder_h264_fei_encode: Leak of memory or pointers to
system resources

tests: check return calling of gst_navigation_event_parse.*

This issue was detected by Coverity.

If the function returns an error value, the error value may be mistaken
for a normal value.

In cb_mouse_event: Value returned from a function is not checked for
errors before being used

plugin: encode: set sink's raw caps to GST_VAAPI_FORMATS_ALL.

Then encode plugin just supports raw formats declared in vaapi video
format map. This modification makes the template caps more precise.

plugins: base: add GstPad param to internal helper functions

The base plugin public API function implementations determine
which pad should be passed to the internal helper functions.
Currently, only the base plugin static sinkpad and static
srcpad are supported/used.  However, this change enables future
API functions to be added that can accept a pad (i.e. request pad)
from an element subclass (e.g. a GstVideoAggregator subclass).

plugins: base: manage pad-specific data in a single struct

Define a struct (GstVaapiPadPrivate) to encapsulate the
pad-specific data (i.e. buffer pool, allocator, info,
caps, etc.).

Add an interface to retrieve the data struct for a given
pad.

Finally, update the base plugin to use the data struct
throughout the implementation.

This will enable us to easily extend the base plugin in the
future to allow for N-to-1 pad subclasses (e.g. overlay/
composite).

plugins: use plugin base macros to access pad specific data

Don't access base struct fields directly since the underlying
definition can change.  Instead, use the accessor macros.

libs: decoder: Modify decode src's template raw formats

We do not need to maintain a standalone list of decoder's output
template for raw formats and that is easy to make mistake(for
example, the AYVU is wrong in that list, should be VUYA).
Just use GST_VAAPI_FORMATS_ALL to replace the raw formats list for
src template.

libs: postproc: Modify src/sink template raw formats

We need to provide more precise template caps for postproc's src
and sink pads. The GST_VIDEO_FORMATS_ALL make all video formats
available which are really superfluous.

Do not mix declaration and code

libs: decoder: h265: skip all pictures prior the first I-frame

Don't try to decode until the first I-frame is received within the
currently active sequence. i965 H265 decoder don't show any artifact
but it crashes.

Fixes: #98

libs: video-format: remove dead code

libs: video-format: add GST_VAAPI_FORMATS_ALL

GST_VAAPI_FORMATS_ALL collects all declared formats in video-format
as a caps template string, and make them available in caps with
memory:VASurface feature.

Fixes: #199

libs: video-format: change GST_VIDEO_FORMAT_AYUV to VUYA.

We only support VUYA format in gst vaapi now, need to correct
the mapping.

tests: check: vaapipostproc test_orientation_mouse_events

Test that vaapipostproc properly translates mouse events
when using video-direction (orientation).

tests: check: vaapipostproc test_crop_mouse_events

Test that vaapipostproc properly translates mouse events
when cropping.

tests: check: initial unit test support

Add minimal unit test toolchain files and a simple
vaapipostproc unit test.

tests: move examples and tests to subfolders

This makes way for adding unit (check) tests.

Remove autotools build

vaapipostproc: fix off-by-one coord translations

When translating navigation x,y coordinates for
video-direction, it is necessary to subtract 1
when using the video dimensions to compute the
new x,y coordinates.  That is, a 100x200 image
should map coordinates in x=[0-99],y=[0-199].

This issue was found with unit tests provided
in !182.

libs: window: x11: Avoid usage of deprecated API

build: halt meson configuration if no renderer API

We should halt meson configuration if there is no render API
installed (either DRM, Wayland or X11).

That behavior was already in autotools but missed in meson. This patch
brings it back.

Fixes: #196

libs: filter: fix default orientation regression

Fix regression introduced in f232f87f7082

libs: filter: use OP_DATA_DEFAULT_VALUE macro

libs: filter: use macro for returning op default value

The code is essentially the same for getting all op default
values.  Thus, use a macro to help minimize code duplication
and [hopefully] encourage using the same mechanism for all
default getters.

libs: filter: query param spec for default scale method

Related: #159

libs: filter: query param spec for default skin-tone values

Related: #159

libs: filter: query param spec for default video-direction

Related: #159

add .gitignore

vaapipostproc: Use level value for skin-tone-enhancement filter.

Currently the parameter of skin-tone-enhancement filter is forced
to zero. In fact it could be set different value by the user.
So create a new property named as "skin-tone-enhancement-level"
for accepting the used defined parameter value.
At the same time, skin-tone-enhancement is marked as deprecated.
When skin-tone-enhancement-level is set, skin-tone-enhancement
will be ignored.

libs: decoder: h264, h266: fix g_return_val_if_fail() missuse

g_return_val_fail() documentations says:

  If expr evaluates to FALSE, the current function should be
  considered to have undefined behaviour (a programmer error).
  The only correct solution to such an error is to change the
  module that is calling the current function, so that it avoids
  this incorrect call.

So it was missused in a couple parts of the H264 and H265 internal
decoders. This patch changes that to plain conditionals.

Also, it was included a couple code-style fixes.

libs: encoder: remove gst_vaapi_encoder_{ref,unref}()

Since GstVaapiEncoder is a descendant of of GstObject, there is no
need to keep a custom ref()/unref() methods. This patch deletes them.

libs: encoder: correct encoder's ref/unref function.

GstVaapiEncoder now is a standard gstobject and need to use
gst_object_ref/unref functions.

gst: encode: h264_fei: remove useless comparison

The expression "len >= 0" is always true since "len"
is an unsigned type.  And it is clear that the writers
intention was not to write "len > 0" since we handle
len == 0 in the ensuing "if (len < 3)" conditional
block.

libs: encoder: h264_fei: fix potential overflow before widen

Found by static analysis. encoder->mb_width * encoder->mb_height
is evaluated using 32-bit arithmetic before widen.  Thus, cast
at least one of these to guint64 to avoid overflow.

libs: encoder: h264_fei: remove dead error condition

Found by static analysis.  The feipak is always null
when we reach the error target.

libs: utils: add missing break in switch

libs: video-format: Make all YUV format available

The YUV formats have no ambiguity for drivers, so we can add them all.
Some old driver(i965) does not implement full get/put image functions
but can use derive image funtions for the YUV format. It does not
report that kind of formats correctly in image query, but will derive
that YUV format image from surface. The dynamic mapping of YUV format
will block that manner.
Adding more YUV format mapping has no side effect. So considering the
legacy driver conformance, we add all YUV formats mapping statically
and dynamic mapping RBG formats

Fix: #189
Fix: #190

egl: Fix racyness in display thread creation

Multiple different scenarios could break the display thread creation and
end up blocking waiting for thread o be created.  Fix them all by
correctly waiting for a new boolean to become valid.

egl: don't advertise a wrapped EGLContext as actually wrapped

It's not actually wrapped as we create a new EGLContext from the passed
in EGLContext.  As a result, the created EGLContext was never destroyed.

libs: h264decoder: do not return error for unhandled NAL unit.

Some streams have error data introducing unknown NAL type. There are
also kinds of NAL types we do not want to handle. The old manner will
set a decoder error when encounter this, which cause a latent crash bug.
The decoder may successfully decode the picture and insert it into DPB.
But there are error NAL units after the AU which cause the post unit error
and make that frame dropped. The later output of the picture still want
to ref that frame and crash.
No need to set decoder error when can not recognize or handle the NAL
unit, just skip it and continue.

Fix: #191

libs: encoders: use GST_PARAM_USER_SHIFT to define internal params

This patch makes use of GST_PARAM_USER_SHIFT to define the internal
param in encoders to decide which parameters to expose. Thus
gstreamer-vaapi will not interfere with any change in GStreamer in the
future.

Also, the internal symbol was change to
GST_VAAPI_PARAM_ENCODER_EXPOSURE to keep the namespacing.

libs: Add BGR10A2_LE support for color space conversion.

Fix: #179

libs: surface: add pointer check for surface_new_from_formats.

The command line:
  gst-launch-1.0 filesrc location=some_name.mjpeg ! jpegparse !
  vaapijpegdec !  videoconvert ! video/x-raw,format=I420 ! vaapisink
will crash on i965 driver because of no pointer check.

We now generate the video format map between GST format and VA format
dynamically based on the image format returned by vaQueryImageFormats.
i965 driver does to report image format of 444P and Y800 forcc, while
the jpeg decoder context VASurfaceAttribPixelFormat use them. We can
not recognize these format and pass a NULL pointer to
gst_vaapi_surface_new_from_formats.
We need to add a pointer check here and let the fallback logic handle
this case correctly.
Other drivers work well.

libs: utils: guard the VAEntrypointFEI symbol

VAEntrypointFEI appeared in libva 2.0.0 (API version 1.0.0)

libs: video-format: Refine the video format mapping.

Improve the mapping between va format and gst format. The new map
will be generated dynamically, based on the query result of image
format in VA driver. Also consider the ambiguity of RGB color
format in LSB mode.

pluginutil: Remove Mesa from drivers white list

The Mesa Gallium driver is poorly tested currently, leading to bad user
experience for AMD users. The driver can be added back to the white list at
runtime using the GST_VAAPI_ALL_DRIVERS environment variable.

vaapipostproc: allow cropping via properties

Add crop-left, crop-right, crop-top and crop-bottom
properties to vaapipostproc.

vaapipostproc: rotate outbuf and crop meta if forwarding

When forwarding crop meta to downstream, the output
buffer and crop meta need to be rotated, too.

Test:
 for i in 90r 180 90l vert horiz ul-lr ur-ll
 do
  gst-launch-1.0 -vf videotestsrc num-buffers=500 \
   ! videocrop top=100 bottom=30 left=40 right=20 \
   ! vaapipostproc video-direction=$i \
   ! vaapisink & \
  gst-launch-1.0 -vf videotestsrc num-buffers=500 \
   ! videocrop top=100 bottom=30 left=40 right=20 \
   ! vaapipostproc video-direction=$i \
   ! identity drop-allocation=true \
   ! vaapisink
 done

vaapipostproc: fix output buffer WxH for crop meta forwarding

Adding crop meta x,y to w,h only compensates for left,top
cropping.  But we also need to compensate for right,bottom
cropping.

The video meta contains the appropriate w,h (uncropped)
values, so use it instead.

Test:

 gst-launch-1.0 -vf videotestsrc num-buffers=500 \
  ! videocrop top=50 bottom=30 left=40 right=20 \
  ! vaapipostproc ! vaapisink & \
 gst-launch-1.0 -vf videotestsrc num-buffers=500 \
  ! videocrop top=50 bottom=30 left=40 right=20 \
  ! vaapipostproc ! identity drop-allocation=1 \
  ! vaapisink

vaapipostproc: handle size and direction together in src events

Mapping a pointer event needs to consider both size and
video-direction operations together, not just one or the other.

This fixes an issue where x,y were not being mapped correctly
for 90r, 90l, ur-ll and ul-lr video-direction. In these directions,
the WxH are swapped and GST_VAAPI_POSTPROC_FLAG_SIZE is set.  Thus,
the first condition in the pointer event handling was entered and
x,y scale factor were incorrectly computed due to srcpad WxH
swap.

This also fixes all cases where both video-direction and scaling
are enabled at the same time.

Test that all pointer events map appropriately:

for i in `seq 0 7`
do
 GST_DEBUG=vaapipostproc:5 gst-launch-1.0 -vf videotestsrc \
  ! vaapipostproc video-direction=${i} width=300 \
  ! vaapisink
 GST_DEBUG=vaapipostproc:5 gst-launch-1.0 -vf videotestsrc \
  ! vaapipostproc video-direction=${i} width=300 height=200 \
  ! vaapisink
 GST_DEBUG=vaapipostproc:5 gst-launch-1.0 -vf videotestsrc \
  ! vaapipostproc video-direction=${i} height=200 \
  ! vaapisink
 GST_DEBUG=vaapipostproc:5 gst-launch-1.0 -vf videotestsrc \
  ! vaapipostproc video-direction=${i} \
  ! vaapisink
done

vaapipostproc: advertise crop meta is handled

Advertise to upstream that vaapipostproc can handle
crop meta.

When used in conjunction with videocrop plugin, the
videocrop plugin will only do in-place transform on the
crop meta when vaapipostproc advertises the ability to
handle it.  This allows vaapipostproc to apply the crop
meta on the output buffer using vaapi acceleration.
Without this advertisement, the videocrop plugin will
crop the output buffer directly via software methods,
which is not what we desire.

vaapipostproc will not apply the crop meta if downstream
advertises crop meta handling; vaapipostproc will just
forward the crop meta to downstream.  If crop meta is
not advertised by downstream, then vaapipostproc will
apply the crop meta.

Examples:

1. vaapipostproc will forward crop meta to vaapisink
 gst-launch-1.0 videotestsrc \
  ! videocrop left=10 \
  ! vaapipostproc \
  ! vaapisink

2. vaapipostproc will do the cropping
 gst-launch-1.0 videotestsrc \
  ! videocrop left=10 \
  ! vaapipostproc \
  ! identity drop-allocation=1 \
  ! vaapisink

libs: encoder: clean two virtual func in encoder class

set_property and get_default_properties functions are no longer
needed for encoder class.

libs: encoder: delete old set_property and property enum feienc264

libs: encoder: delete old set_property and property enum in h264 fei

libs: encoder: delete old set_property and property enum in vp9

libs: encoder: delete old set_property and property enum in vp8

libs: encoder: delete old set_property and property enum in mpeg2

libs: encoder: delete old set_property and property enum in jpeg

libs: encoder: delete old set_property and property enum in h265

libs: encoder: delete old set_property and property enum in h264

libs: encoder: delete EncoderPropInfo related functions

libs: encoder: delete encoder_set_property

We no longer need this obsolete set_property function now after
switch to standard gobject's property manner.
Also delete the old encoder's property enum in the header file.

libs: encoder: delete properties_get_default for base class

plugin: encode: delete useless init_properties.

Also delete the get_properties function in encode class. We now
use g_object_class_list_properties to get all properties for
internal encoder class.

plugin: encode: delete set/get_property func in encode class

Use standard gobject's property functions to replace the old way.

plugin: encode: delete gst_vaapiencode_init_properties

No need to init the properties got by get_default_properties func
now. The properties are inited correctly in internal encoder class.

libs: encoder: delete 3 useless init macro

libs: encoder: delete get_default_properties of feienc

libs: encoder: delete get_default_properties of H264 Fei

libs: encoder: delete get_default_properties of VP9