libs: encoder: h265: add multi reference support

This is doing the same as h264 encoder as the following:

Using num_ref_frames provided and the result of the Query
VAConfigAttribEncMaxRefFrames, it determines the size of reference list
and perform encoding with multi reference frames as the following:

1\ The num_ref_frames is being considered as the number of
reference picture list0
2\ Encoder adds 1 reference frame more to the reference picture list1
internally if b-frame encoding.
3\ If num_ref_frames is bigger than the number of refrence frames
supported in the driver, it will be lowered.

Also this patch includes:
- Set num_negative_pics and num_positive_pics according to the number of
refs.
- Set delta_poc according to the number of refs.
- Increase max_dec_pic_buffering according to the number of refs
- Change max_num_reorder_pics according to num of bframes

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

libs: encoder: h265: add refs property

Users can provide the number of reference frame by this property,
which is exaclty same as h264.

The value of the property will be considered as the number of
reference picture list0 and will add 1 reference frame more to the
reference picture list1 internally if b-frame encoding.

If the value provided is bigger than the number of refrence frames
supported in the driver, it will be lowered.

The maximum value is aligned to the value of the driver supported now.

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

libs: encoder: h264/5: determine num_ref_idx_active_override_flag according to reference list

Follows the specification as below:

7.4.7.1 in Rec. ITU-T H.265 v4 (12/2016)
num_ref_idx_active_override_flag equal to 1 specifies that the syntax
element num_ref_idx_l0_active_minus1 is present for P and B slices and
that the syntax element num_ref_idx_l1_active_minus1 is present for B
slices.
num_ref_idx_active_override_flag equal to 0 specifies that the syntax
elements num_ref_idx_l0_active_minus1 and num_ref_idx_l1_active_minus1
are not present.

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

libs: encoder: h265: keep idr_period equal to keyframe period

Remove FIXME code, which makes previous assignation spurious.
This also means to make idr_period equal to keyframe period,
which is same as h264 encoder.

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

Request minimum buffer even if need_pool is FALSE

When tee is used, it will not request a pool, but still it wants to
know how many buffers are required.

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

libs: encoder: h264_fei: VA-API 1.0 compat

Use VA_ENC_PACKED_HEADER_H264_SEI compat macro for VA-API 1.0
compatibility.

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

Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>

vaapisink: Fix rendering in drm display

Make sure vaapisink create a va surface backed buffer pool and all
required attributes get assigned correctly for drm display type.

This is needed to make the below pipeline working:
gst-launch-1.0 filesrc location= raw_video.mov ! videoparse format=uyvy
width=320 height=240 framerate=30/1 ! vaapisink display=drm

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

FEI: Add test applications to showcase fei use case

test-fei-enc-out: A simple fei encoding application to output mv, mbcode and distortion
eg:
 ./test-fei-enc-out -i sample_320x240.nv12 -w 320 -h 240 -o out.264 -v mv.out -d out.dist -m out.mbcode -e 1

test-fei-enc-in: A simple fei encoding application for testing input fei buffers
eg:
./test-fei-enc-in -c h264 -o out.264 -e 4 -q 1 sample_i420.y4m

Fixme: Running test-fei-enc-in in PAK mode with mv and mbcode input buffers
       from saved files is still not working

People contributed:
            Wang, Yi <yi.a.wang@intel.com>
            Leilei <leilei.shang@intel.com>
            Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
            xiaominc <xiaomin.chen@intel.com>
            Li, Jing B <jing.b.li@intel.com>

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

FEI: plugin: Add vaapih264feienc element

A new FEI based encoder element for h264 is added: vaapih264feienc

FEI is a an extension to VA-API which is providing low level
advanced control over different stages of encoding.
Extending vaapih264enc with fei support is possible, but it will
make the code too much complicated and will be difficult
to debug. So adding the new encoder element, but keeping
the rank as 0 , vaapih264enc will stay as the primary
encoder for normal use cases.

The vaaih264feienc is mainly useful for customers who want to play
with MotionVectors and Macroblock Predictions. Also user can
do one stage of encoding(eg: only the Motion Vector Calculation)
in software and offload trasformation/entroy-coding etc to
Hardware (which is what PAK module is doing) using FEI element.

vaapih264feienc can work in  different modes using fei-mode properoty

eg: gst-launch-1.0 videotestsrc ! vaapih264feienc fei-mode=ENC+PAK ! filesink location=sample.264

Important Note: ENC only mode won't produce any encoded data which is expected.
But ENC alwys requires the output of PAK in order to do the inter-prediction
over reconstructed frames.
Similary PAK mode alway requires MV and MBCode as input, so unless there is an
upstream element providing those buffers, PAK only won't work as expected.

In a nutshell, ENC_PAK and the ENC+PAK modes are the only options we can verify
with vaapih264feienc. But ideally, EN+PAK mode verification is enough to make sure
that ENC and PAK are working as expected since ENC+PAK mode always invoke ENC and PAK
separately in vaapih264feienc.

People contributed:
        Wang, Yi <yi.a.wang@intel.com>
        Leilei <leilei.shang@intel.com>
        Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
        xiaominc <xiaomin.chen@intel.com>
        Li, Jing B <jing.b.li@intel.com>

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

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>

FEI: plugin: Add virtual methods to base encode

Two new virtual methods are added to gstvaapiencode.

load_control_data():  load the FEI input buffers set by the upstream elements
save_stats_to_meta(): save the FEI output buffers to Meta for downnstream elements

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

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>

FEI: plugin: Add fei specific video meta

GstVaapiFeiVideoMeta holds the below fei codec objects:
  GstVaapiEncFeiMbCode
  GstVaapiEncFeiMv
  GstVaapiEncFeiMvPredictor
  GstVaapiEncFeiMbControl
  GstVaapiEncFeiQp
  GstVaapiEncFeiDistortion

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

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>

FEI: libs: Add FEI encoder

Adding FEI encoder to core lib.

The code is splitted into three session:

1: gstvaapiencoder_h264_fei.{h,c}
This is the replica of gstvaapiencoder_h264.{c,h} but with FEI.
All the modes ENC, PAK and ENC_PAK are running based
the code in these files.

2: gstvaapifeienc_h264.{h,c}
Abstract implementation intended for ENC (only VME) operation.

3: gstvaapifeipak_h264.{h,c}
Abstrct implementation intended for PAK (only the PAK module)

Right now ENC_PAK, ENC and PAK are running based on code
in gstvaapiencoder_h264_fei.{h,c}. The abstract implementations
in gstvaapifeienc_h264.{h,c} and gstvaapifeipak_h264.{h,c} are
needed if user request for ENC+PAK mode operation.

ENC+PAK: Here we need to invoke two sequence of
vaBeginPicture/vaRenderPicutre/vaEndPicture for each frame,
first for the ENC only and the second for PAK only.
Each mode associated with separate context ,but same pool of surfaces are
shared between the modes.
This is more useful once we have custom BRC algorithms.

Other Contributors:
                   Wang, Yi <yi.a.wang@intel.com>
                   Leilei <leilei.shang@intel.com>
                   Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
                   xiaominc <xiaomin.chen@intel.com>
                   Li, Jing B <jing.b.li@intel.com>

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

FEI: libs: Add fei codec objects to GstVaapiEncPicture

All the codec objects(vaapi buffers) supposed to be
submited in vaRenderPicutre are associated with a GstVaapiEncPicture
for each frame, follow the same design for FEI too.

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

FEI: libs: Add fei codec objects in codedbufferproxy

MbCode, MV and Distortion buffers (fei codec objects)
can be treated as output of different fei modes based user request.
For eg: MbCode and MV are the output of ENC only. MbCode, MV and Dist
can be dumped as output in ENC_PAK mode for analysis purpose.
So treating them as a part of CodedBufferProxy too.
Here we avoided Qp, MbControl and MvPredictor codec objects since
there is no practical use case of treating them as "output buffers".

Other contributors:
               Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
               xiaominc <xiaomin.chen@intel.com>
               Leilei <leilei.shang@intel.com>
               Li, Jing B <jing.b.li@intel.com>

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

FEI: libs: Add fei codec objects to surface proxy

Add fei codec objects to surface proxy since handling the
fei buffers(codec objects here) external to gstvaapisurfaceproxy
will make the code complicated. Especially considering the behavior
of encoder where the input frame order from upstream and output
frame order to the downstream are not sequential.

Other contributors:
              Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
              xiaominc <xiaomin.chen@intel.com>
              Leilei <leilei.shang@intel.com>
              Li, Jing B <jing.b.li@intel.com>

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

FEI: Add codec objects for fei usecase

There are 6 new va buffer types, each defined as a specific codec object.
Borrowed the code from gstvaapicodecobject , but made a clear separation
to avoid any possible mess-up. Because unlike the other gstvaaicodecobjects,
feicodecobjects can be shared between elements and also can be accessed
from different thread.

Unlike the other fei codecs object, VAEncMiscParameterTypeFEIFrameControl
object is not shared between elements.So we utilize the already
existing gst_vaapi_enc_misc_param_new(), but still keeping the code
in gstvaapfei_objects_priv.h in order to have a better
code readability.

Fixme:
-- Probably we need _locked_map() and _unlocked_map()
-- Context can be associated with PreEnc(not just Enoder)
once we have the proper support inplace, but for now we don't have
PreEnc support, so should be safe enough to use GstVaapiEncoder.

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

FEI: libs: add H264 fei specific utility functions

Added enum/flag type definitions for a number of FEI
input and output parameters.

Original author of the patch: Wang, Yi <yi.a.wang@intel.com>

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

Signed-off-by: Wang, Yi <yi.a.wang@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>

FEI: libs: Add virtual method for secondary context creation.

Add a new vitrual method ensure_secondary_context to the
base encoder which is only required for the FEI entrypoint, that too
only when user configures the ENC+PAK mode. ENC+PAK mode is not something
supported directly by libva or driver, but this can be enabled
from the middleware.

Original Author of this idea: Leilei Shang <leilei.shang@intel.com>

Signed-off-by: Leilei Shang <leilei.shang@intel.com>
Signed-off-by: xiaominc <xiaomin.chen@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712
https://bugzilla.gnome.org/show_bug.cgi?id=784667

FEI: libs: make sure the default context creation works as expected.

Current code always guess the entrypoint during init phase in case
if there is no entrypoint already configured in GstVaapiContextInfo.
Make sure FEI Entrypoint is not messing up with this logic.

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

FEI: libs: Add FEI functional mode configuration

FEI Entrypoint can work in either one of the 3 different modes:
VA_FEI_FUNCTION_ENC, VA_FEI_FUNCTION_PAK or VA_FEI_FUNCTION_ENC_PAK.

Add infrastructure in gstvaapicontext and gstvaapiencoder for this
functioal mode configuration.

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

FEI: libs: Add FEI Entrypoint mapping

Define the new mapping GST_VAAPI_ENTRYPOINT_SLICE_ENCODE_FEI
for VAEntrypointFEI.

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

FEI: Add support for FEI conditional build

FEI(Flexible Encoding Infrastructure) is an extension
to VA API. Define USE_H264_FEI_ENCODER based on
fei header file and required structures availability.

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

vaapidecode: force add h264 SVC profiles in caps

When vaapih264dec's base-only profile is set to TRUE, fake SVC profile
support in caps.

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

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>

libs: decoder: h264: decode SVC base layer only

Drops non-base NALs when the base-only property is set to TRUE.
This modifies the behavior for MVC streams with base-only too: All the
non-base units are dropped before they are decoded instead of dropping
the non-base frames.

The relevant part from the H264 spec is:
> Decoders that conform to one or more of the profiles specified in
Annex A rather than the profiles specified in Annexes G or H shall
ignore (remove from the bitstream and discard) the contents of all NAL
units with nal_unit_type equal to 14, 15, or 20.

To eliminate side effects from the offending units:
- PPS's with a broken seq_parameter_set_id (referring to dropped subset
SPS's) are ignored.
- The NAL parsing is skipped and their flags are set to
GST_VAAPI_DECODER_UNIT_FLAG_SKIP.
- Prefix units are not stored in prev_pi. Otherwise, parse_slice() would
use them even if they are flagged to be skipped. Subset SPS's and slice
extension units are not stored there either.

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

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>

libs: decoder: h264: check nalu validity in parser info finalize

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

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>

libs: encoder: remove unused cast macro

Remove internal macro to cast structure that are already declared
in the header.

Revert "libs: encoders: remove unused cast macros"

This reverts commit fd7d38f7d26b11e592638092b4073b5c1764f255.

libs: encoders: remove unused cast macros

They are only used inside the code, where another macro is defined.
Thus these exported macros have no use.

libs: decoder: h264: improve code-style

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

libs: encoder: h264: handle deprecated enum

In VA-API 1.0 the enum VAEncPackedHeaderH264_SEI is deprecated, and
instead VAEncPackedHeaderRawData should be used.

This patch creates a compatibility symbol,
VA_ENC_PACKED_HEADER_H264_SEI, to expose the used enum according the
VA-API version.

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

libs: guard deprecated symbols

In VA-API 1.0 the H.264 baseline profile is deprecated. This patch
guards the H.264 baseline usage. Consider this commit as a
continuation of commit e0e0a474

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

Revert "build: check for libva-2.0"

This reverts commit 8f2eb70803099d4b533ecc10fc259041d8714210.

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

libs: macro to get a renamed value in VA-API 1.0

In VA-API 1.0 the union bits in VAEncMiscParameterBufferROI has
renamed one member from roi_value_is_qp_delat to
roi_value_is_qp_delta, which is the correct name.

In order to keep back compatibility a macro has added to access this
union member.

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

plugins: include main gstgl header

Instead including particular gstgl header files in a header file
that doesn't export a gstgl symbol, the main gstgl header file is
included in gstvaapipluginutil.c where the symbols are used.

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

libs: encoder: h264: fix enum namespace

Automatic update of common submodule

From 48a5d85 to 3f4aa96

libs: encoder: h264: remove spurious assignation

Coverity scan bug:

An assigned value that is never used may represent unnecessary
computation, an incorrect algorithm, or possibly the need for cleanup
or refactoring.

ip_period is assigned first to be rewritter inmediatly after. The
first assignation is spurious.

vaapidecode: fix mismatch of the return type

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

libs: remove unused header

Since libgstvaapi is not distributed, there is no need to check for
private header inclusion. Thus removing it.

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

libs: utils: move gstvaapisurface.h to private headers

Since the utils don't expose API defined in gstvaapisource.h, it is
moved to their private headers where they are used.

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

libs: utils: remove va.h include in header

And include gstvaapicompat.h in the C files, since the VA-API is not
exposed in the headers.

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

libs: encoder: remove va.h include

Since it is already managed by gstvaapicompat.h

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

build: consolidate the VA sub API includes

Include all VA sub APIs headers in a single point (gstvaapicompat.h),
since they are all already included in va.h after VA-API 0.38.

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

build: check for va_vpp.h

Thus, in config.h the macro HAVE_VA_VA_VPP_H is defined. This will
allow us to handle the inclusion of the header better.

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

meson: don't export symbols by default

Only plugin entry points should be exported.

libs: decoder: h265: remove spurious code

Coverity scan:

Logically dead code: The indicated dead code may have performed some
action; that action will never occur.

By using pointer arithmetic is impossible to get NULL.

libs: context: use attribs index instead pointers

Coverity scan bug:

Out-of-bounds write. This could cause an immediate crash or incorrect
computations.

Coverity basically found that it is possible to assign more than 4
attribs in the array.

In my opinion this was produced because code pattern used pointer
arithmetic, which is not readable nor maintainable.

This patch refactors config_create() to use an array index rather than
pointer arithmetic. Also a run-time check for index size was added.

vaapiencode: h264: remove spurious code

Coverity scan bug:

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

As len is guint32, there is no need to check it if it is equal or
bigger than zero.

vaapidecode: initialize variable

Coverity scan bug:

The variable will contain an arbitrary value left from earlier
computations.

Variable base_only is fetched from base-only property, and it may be
not assigned. It needs to be initialized.

libs: windows: wayland: fail if cannot remove last frame

Converity scan bug:

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

If g_atomic_pointer_compare_and_exchange() fails because the frame is
not the last one, the function fails. Thus, logging an info message.

libs: utils: glx: check return value

Coverity scan bug:

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

Function sscanf returns the number of assignations done. Validate this
return value with the number of expected variables to match.

libs: vaapi: object: remove unrequired NULL check

Coverity scan bug:

Dereference after null check: Either the check against null is
unnecessary, or there may be a null pointer dereference.

Variable klass has been validated as non-NULL several time before in
gst_vaapi_object_new() function, so there is no need to check it
again.

libs: encoder: h265: remove spurious assignation

Coverity scan bug:

An assigned value that is never used may represent unnecessary
computation, an incorrect algorithm, or possibly the need for cleanup
or refactoring.

ip_period is assigned first to be rewritter inmediatly after. The
first assignation is spurious.

libs: encoder: h264: fix copy & paste error

Coverity scan bug:

The copied code will not have its intended effect.

This is a bug from commit cdaf15b2, where the intention is to
initialize RefPicList1 while setting RefPicList0.

libs: encoder: h265: fix possible integer overflow

Coverity scan bug:

Unintentional integer overflow. The expression's value may not be what
the programmer intended, because the expression is evaluated using a
narrow (i.e. few bits) integer type.

Cast operator to guint64 before computation to avoid narrowing.

merge with 3c5a6add

libs: decoder: mpeg4: fail if return value is not OK

Coverity scan bug:

An assigned value that is never used may represent unnecessary
computation, an incorrect algorithm, or possibly the need for cleanup
or refactoring.

In the return value of decode_slice() or
gst_mpeg4_parse_video_packet_header() are not success, thus fail
decode_packet() function.

libs: decoder: h265: check for null

Coverity scan bug:

Dereference after null check: Either the check against null is
unnecessary, or there may be a null pointer dereference.

While looking for hte lowest poc, according to rest of the code, the
picture in the dbp (decoded picture buffer) might be NULL, thus we
could check for a NULL picture before assigned as found.

Also, split a comma operator because it is considered as a bad
practice because it possible side effects.

libs: decoder: h265: untaint loop control variable

Coverity scan bug:

Scalars (for example, integers) are not properly
bounds-checked (sanitized) before being used as array or pointer
indexes, loop boundaries, or function arguments are considered as
tainted.

In this case, num_nals were not checked before used as loop control.

libs: decoder: h264: remove unrequired NULL check

Coverity scan bug:

Dereference after null check: Either the check against null is
unnecessary, or there may be a null pointer dereference.

In the original commit for fill_picture_gaps() (commit 5abd2b90) the
prev_picture could be NULL, that's why the code did a null check. But,
since commit 52adebe7, the previous reference frames are tracked, thus
there is no need to check null anymore.

vaapidecode: fix gst_caps_new_simple call

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

vaapidecode: force add h264 MVC profiles in caps

When vaapih264dec's base-only profile is set to TRUE, fake MVC profile
support in caps.

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

libs: decoder: h264: decode MVC base view only

If processed SPS has mvc profile and the configuration is set to
base-only, the frame is drop.

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

vaapidecode: set h264 base-only to decoder

Set the base-only value when property is set and the internal
decoder is already instantiated or when the internal decoder
is created.

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

libs: decoder: h264: add setter for base-only mode

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

vaapidecode_props: h264: add base-only property

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

libs: encoder: h264: missing property enum documentation

libs: encoder: h264: add multi reference support

Using num_ref_frames provided and the result of the Query
VAConfigAttribEncMaxRefFrames, it determines the size of reference list
and perform encoding with multi reference frames as the following:

1\ The num_ref_frames is being considered as the number of
reference picture list0
2\ Encoder adds 1 reference frame more to the reference picture list1
internally if b-frame encoding.
3\ If num_ref_frames is bigger than the number of refrence frames
supported in the driver, it will be lowered.

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

libs: encoder: h264: add refs property

Users can provide the number of reference frame by this property.

The value of the property will be considered as the number of
reference picture list0 and will add 1 reference frame more to the
reference picture list1 internally if b-frame encoding.

If the value provided is bigger than the number of refrence frames
supported in the driver, it will be lowered.

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

libs: encoder: implements gst_vaapi_encoder_ensure_max_num_ref_frames

This function will query VAConfigAttribEncMaxRefFrames to get the
maximum number of reference frames supported in the driver.
This will be used for h264/h265 encoding.

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

vaapiencode: h265: compare an unsigned int if not zero

An unsigned value can never be negative, so this test (greater than
zero) will always evaluate the same way. Thus change it to just if
it's not zero.

plugins: check gst_gl_ensure_element_data() return value

Refactor gst_vaapi_plugin_base_create_gl_context() in order to check
the return value of gst_gl_ensure_element_data(). The result is a code
bit cleaner.

plugins: avoid dead code detection

By using #elif macro, the static code analysis would stop to detect
these lines as dead code. Also it is inforced the mutually exclusive
environments.

vaapivideobufferpool: don't shift by negative since it's undefined

The function g_bit_nth_lsf() may return -1 if the request bit position
is not avaible. Thus, this patch check if the return value is not -1
in order to continue.

vaapisink: fix memory leak

vaapipostproc: fix memory leaks

libs: display: when appending formats change pointers to indexes

Thus, it fixes an invalid read when YV12 or I420 are not supported by
the driver.

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

libs: encoder: h264: Add uncompliant mode reducing coded buffer size

Added a new property "compliance-mode", which default is the normal
strict compliant mode.

The second mode, "restrict-buf-alloc", is to limit the coded buffer
allocation size to improve performance in some specific Intel
platforms (there is asignificant performance improvement in parallel
encodings). Under this new mode, we use the MinCR field in A.3.1 for
pre-calculating the coded-buffer size.

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

libs: utils_h264: Extend LevelLimit table with MinCR field

Add MinCR(Minimum Compression Ratio) field to GstVaapiH264LevelLimits
based on Annex A.3

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

libs: utils: libva 1.0 changed the logging

The logging mechanism in libva has changed it's functions
signatures. This patch updates that for libva versions >= 1.0

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

libs: decoder: h264: libva 1.0 deprecated baseline

libva 1.0 deprecated H.264 baseline profile and FMO support
(commit b4f332b3).

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

build: check for libva-2.0

Check for libva-2.0 since libva's developers decided to increase the
library's version number.

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

build: blacklist only libva 0.99.0

Intel's MSDK uses libva 0.99.0, meanwhile open source libva bumped
its API version to 1.0.0. Thus we have to blacklist only the MSDK's
libva (0.99.0)

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

build: meson: remove gstvaapidisplaycache.c

This is a missing bit of commit ec3e10f6

configure: do not break configure if gtk+-3.0 devel missing

Fix PKG_CHECK_MODULES rule for with_gtk=check condition to
set USE_GTK=0 if gtk+-3.0 is not available.

Since commit 85856c29a70d6de4aea5b708e04e9eb418190623
Author: Hyunjun Ko <zzoon@igalia.com>
Date:   Wed Jul 5 15:59:43 2017 +0900

    tests: elements: add testsuite of vaapi context

...configure fails if gtk+-3.0 development files are missing.

The "with_gtk" option defaults to "check" in configure.ac
which implies that if it is not explicitly requested then
configure will only enable it if it's available on the system.

However, the PKG_CHECK_MODULES rule that get's activated on
"check" condition did not provide default when gtk+-3.0 devel
packages are not found on the system.  Thus, it resulted in
configure failure.

Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785452

tests: elements: add testsuite of vaapi context

Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=766704

vaapisink: fail if surface display is different

Replacing GstVaapiDisplay during rendering might be hiding problems
at some cases, even though it's safe currently since we use cache
of GstVaapidisplay.

Play safe by failing if this happens.

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

videocontext: support "gst.vaapi.app.Display" context

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

Attributes:
- display : pointer of VADisplay
- x11-display : pointer of X11 display (Display *), if they're using.

This patch creates GstVaapidisplayX11 if information provided through
"gst.vaapi.app.Display"

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

libs: display: x11: add gst_vaapi_display_x11_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=766704

libs: display: pass display info when foreign display

When creating a GstVaapiDisplay using a foreign VADisplay, and render
with that display, it also requires native display of the backend.

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

libs: display: remove cache

Remove a bunch of code that handles the VADisplay cache, since the
context sharing should be doing this correctly.

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

tests: elements: add test for vaapipostproc

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

postproc: reconfigure when width or height changes

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

libs: encoder: vp9: array terminated in zeros

There is a crash when setting ref-pic-mode since the #GEnumValue
array is not terminated with a structured with all memvers being
zero.

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

vaapiencode: h264: add plugin documentation

Comment how the profile is set and other parameters.

libs: decoder: h264: push frames as soon as possible

Push frames downstream as soon as possible instead of waiting until
they are ejected from the DPB.

This patch makes the decoder not comply with the H.264 specification,
but it is required for some video cameras.

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

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

vaapidecode_props: h264: set low-latency in decoder

Set the low-latency property if the H264 decoder is already
instantiated, thus you could change the behavior in run-time.

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

vaapidecode: set h264 low latency to decoder

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

libs: decoder: h264: add getter/setter for low latency mode

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

vaapidecode_props: h264: add low latency property

Adding support for private data.

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

vaapidecode_props: add skeleton for h264 decoder properties

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