From f49c55e to 742c09d

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

vaapipostproc didn't negotiate the proper multiview caps losing
downstream information.

This patch enables the playing of MVC encoded stream by setting
the proper multiview mode/flags and views to src caps, according
to sink caps.

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

When state of vaapisink is changed from PLAYING to NULL, the handle_events
flag is set to FALSE, and never recovered, and then event thread is never
going to run.

So we should allow to set the flag only when users try it.

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

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

When downstream negotiates a pixel-aspect-ratio of 0/1, the
calculations for resizing and formatting in vaapipostproc and
vaapisink, respectively, failed, and thus the pipeline.

This patch handles this situation by converting p-a-r of 0/1 to
1/1. This is how other sinks, such as glimagesink, work.

Since it's created by itself, it should be unref-counted
after gst_buffer_pool_config_set_allocator call. Afterwards,
this allocator will be ref-counted again when assigning to priv->allocator.

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

Sometimes a video decoder could set different buffer pool
configurations, because their frame size changes. In this case we
did not reconfigure the allocator.

This patch enables this use case, creating a new allocator inside
the VAAPI buffer pool if the caps changed, if it is not dmabuf-based.
If so, it is just reconfigured, since it doesn't have a surface pool.

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

gcc 7.0.1 gives a memset-elt-size warning in gst_vaapi_encoder_vp9_init:

 'memset' used with length equal to number of elements without
 multiplication by element size [-Werror=memset-elt-size]

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

This is a regression introduced by e829b62 which
override the reference flags and caused issues with
latest intel-vaapi-driver.

The current implementation is updating the POC values only
in Slice parameter Buffer.But we are not filling the
picture order count and reference flags in VAPictureH264
while populating VA Picture/Slice structures.The latest
intel-vaapi-driver is directly accessing the above fields
from VAPicutreH264 provided as RefPicLists, which resulted
some wrong maths and prediction errors in driver.

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

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

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

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

Just like in configure.ac.

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

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

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

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

Fix reserved length of bits for bit_depth_luma_minus8 and bit_depth_chroma_minus8

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

From man open(2):

    The O_CLOEXEC, O_DIRECTORY, and O_NOFOLLOW flags are not specified
    in POSIX.1-2001, but are specified in POSIX.1-2008.  Since glibc
    2.12, one can obtain their definitions by defining either
    _POSIX_C_SOURCE with a value greater than or equal to 200809L or
    _XOPEN_SOURCE with a value greater than or equal to 700.  In glibc
    2.11 and earlier, one obtains the definitions by defining
    _GNU_SOURCE.

And indeed, with the uClibc C library, O_CLOEXEC is not exposed if
_GNU_SOURCE is not defined. Therefore, this commit fixes the build of
gstreamer-vaapi with the uClibc C library.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

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

Update the URL where the release source tarballs can be downloaded.

The "Reporting bugs" section gives
https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamer-vaapi as the
link to report a bug, but this link says "Sorry, entering a bug into the
product gstreamer-vaapi has been disabled.".

This commit fixes the URL to point to the proper location, and also
removes the following paragraph that is no longer correct.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

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

The AC_CHECK_HEADERS macro was failing to locate some headers, in
particular the va_enc_* headers due to missing compiler flags.

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

Reduce frame num gaps so that we don't have to create unnecessary
dummy pictures, just throw them away.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

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

A value of width/height property should be set to out caps,
if negotiation had been going properly.
So we can use srcpad_info when making decision of scaling.

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

Use the sink caps pixel-aspect-ratio to fixate the src caps, if it
is not already set.

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

if the vaapipostproc is configured to not do deinterlacing, the
interlace-mode in the src caps should be the same as the input caps.

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

warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]

Thus a race condition segfault is avoided.
Original-patch-by: Matt Staples <staples255@gmail.com>

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

If the frame is a cloned picture, its PTS comes from its parent
picture.  In addition, the base decoder doesn't set a valid PTS to
the frame corresponding to the cloned picture.

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

If src pad caps have changed, it needs to notify it downstream. In
addition, do not set passthrough if they have changed.

Otherwise, transform sometimes starts processing before caps change.
The passthrough value will be set in fixate later in this case.

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

Removes GstVideoGLTextureUploadMeta caps feature if the driver
doesn't support opengl.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

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

When the allowed source pad caps are generated, the GLTextureUpload caps are
only inserted if the driver support OpenGL.

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

In commit 6d11a009 were introduced a regression when gstreamer-vaapi is
compiled with out EGL/GLX support: it shall not support
GST_VAAPI_MAKE_GLTEXUPLOAD_CAPS.

This patch guards the inclusion of GST_VAAPI_MAKE_GLTEXUPLOAD_CAPS in the
allowed src caps for vaapedecode if EGL/GLX.

Just as vaapipostproc, VA decoder's context can be queried to get the possible
raw formats, so, the src caps can negotiate the exact caps that the context
supports.

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

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

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

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

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

This patch fixes failures of intensive_state_change scenario of
gst-validate

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