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

vaapidecode: properties callback in decoders map

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

meson: find python3 via python3 module

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

libs: encoder: h264: submit sps in case of IDR picture

If the picture is IDR, also submit a SPS header.

This means when frame number reaches to keyframe-period or an force
key unit event arrives, we insert SPS/PPS again.

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

libs: encoder: h264: set the frame as IDR if forced key unit

GST_VIDEO_CODEC_FRAME_IS_FORCE_KEYFRAME() is a flag usually used to manage
the `frame-lost` event in the case of streaming, such as RTP.

In case of this event, it is needed to start new GOP rather than just
produce an I-frame.

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

libs: encoder: h264: insert AU delimiter

Insert an AUD as the first NAL of each encoded frame.

Some applications require Access Unit Delimiter for decoding the
stream.

The AU delimeter insertion is done only when the aud parameter is
TRUE (by default is disabled). The reason of this it is because this
header is only available from Intel Gen9 and the VA intel driver
should be 1.8 or superior. Otherwise, the output will be corrupted.

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

Signed-off-by: Victor Jaquez <vjaquez@igalia.com>

libs: encoder: h264: initialize all elements of view_ids

Currently when num_views is changed by multiview-mode on sink caps, it produces
wrong MVC encoded stream since the array view_ids is not set properly according
to changed num_views.

So this patch initializes all of the array sequentially to handle this case.
Side effect is not going to happen by this patch since this array is being
handled by num_views.

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

Revert "encoder: h264: Use high profile by default"

This reverts commit 4aec5bdd7207fc0e45813ef14c9c0ad5174a8f75.

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

libs: encoder: h264: set profile via capsfilter

Until now, the encoder ignored the profile in src caps and chose one
according with the given parameters. But the encoder must honor the
profile specifed in src caps.

This patch do that, and if the encoder needs to choose the profile,
it will do it by following these rules:

1\ If given parameters are not compatible with given profile, the
   encoder will bail out with an error.
2\ The encoder will choose the higher profile indicated in the
   src caps.

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

vaapiencode: h264: set profile to src caps

So far vaapi encoder does not set profile to src caps. This patch makes it
setting profile to src caps, which is determined by itself.

In addition, if encoder chose different profile, which is not negotiated with
downstream, we should set compatible profile to make negotiation working.

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

vaapiencode: h264: verify if requested profile is supported

Check if the requested profile in source caps, is supported by the
VA driver. If it is not, an info log message is send saying that
another (compatible?) profile will be used.

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

vaapiencode: h264: improve set_config() vmethod

First check if downstream requests ANY caps. If so, byte-stream is
used and the profile will be choose by the encoder. If dowstream
requests EMPTY caps, the negotiation will fail.

Lately, byte-stream and profile are looked in the allowed caps.

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

vaapiencode: h264: check for avc in set_config()

The check for avc stream format was done in the vaapi encoder's
vmethod get_caps(), but that is wrong since it has to be check
when encoder set_format().

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

vaapipostproc: set multivew-mode flags to src caps

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

vaapipostproc: add support for DMABuf caps feature

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

Signed-off-by: Julien Isorce <j.isorce@samsung.com>

vaapidecode: add support for DMABuf caps feature

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

Original-patch-by: Julien Isorce <j.isorce@samsung.com>

vaapipluginbase: force dmabuf allocator if DMABuf caps feature

Instantiate all dmabuf allocator for src pad buffer pool if the
src caps ask for memory:DMABuf feature.

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

vaapipluginutil: add support for DMABuf caps feature

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

Signed-off-by: Julien Isorce <j.isorce@samsung.com>
Signed-off-by: Victor Jaquez <vjaquez@igalia.com>
vaapipluginutil: add support for DMABuf caps feature

vaapipluginbase: dmabuf memory map trial for raw caps

Only push dmabuf-based buffers with raw caps if gst_memory_map()
succeeds. Otherwise, use the the vaapi surfaces allocator.

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

Original-patch-by: Julien Isorce <j.isorce@samsung.com>

vaapivideomemory: add gst_vaapi_dmabuf_can_map()

This new method checks the specified allocator can create GstMemory that can
be mapped.

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

vaapivideobufferpool: fix regression with video metas

There is another regression with 7a206923 when setting the video
info for the video meta, it should be the one from the image's
allocator rather from the allocation caps.

Test pipeline:

  gst-launch-1.0 filesrc location=bug766184.flv ! decodebin \
      ! tee ! videoconvert ! videoscale                     \
      ! video/x-raw, width=1920, height=1080 ! xvimagesink

plugins: update buffer size with the one reported by allocator

There is a regression in 7a206923, since the buffer pool ditches all
the buffers generated by them because the pool config size is
different of the buffer's size.

Test pipeline:

  gst-launch-1.0 filesrc location=big_buck_bunny_1080p_h264.mov \
      ! qtdemux ! vaapih264dec ! vaapipostproc ! xvimagesink    \
      --gst-debug=GST_PERFORMANCE:5

The allocator may update the buffer size according to the VA surface
properties. In order to do this, the video info is modified when the
allocator is created, which reports through the allocation info the
updated size, and set it to the pool config.

libs: decoder: h264: initialize active_sps/pps in reset

Since commits in https://bugzilla.gnome.org/show_bug.cgi?id=781142 landed,
they introduced regression in seek.

Formerly, once seek is done, decoder drops P-frames until I-frame arrives.
But since the commits landed, it doesn't drop P-frame and does try to
decode it continuously because active_sps is still alive. See ensure_sps function.
But there are prev_frames and prev_ref_frames reset already, then it
causes assertion.

So it's necessary to reset active_sps/pps also in reset method.

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

libs: encoder: fix compilation with old versions of libva

There are some symbols that are not used when compiling with old
version of libva and those generates a compilation error.

Original-patch-by: Matt Staples <staples255@gmail.com>

libs: encoder: Fix the quality level clamping

Change the hard-coded range of quality-level from {1-8} to {1-7},
since it is the range Intel Open source driver supports.
Also perform the range clamping only if the user provided
quality-level is greater than the max-range suppored by the driver,
because there could be non-intel drivers giving lower value than
the hard-coded max value 7.

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

libs: encoder: log out the name of the profile

Instead of printing a number, it is more readable to log out, in
case of error, the name of the failing profile.

libs: encoder: h264: changes raw number of profile to macro name of its

Changes raw number of profile to macro name of its to improve readability.

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

vaapivideobufferpool: remove allocation_vinfo private attribute

There is no need to keep this attribute internally since it is
already managed by the allocator.

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

vaapivideobufferpool: refactor set_config()

Refactor the set_config() virtual method considering a cleaner
approach to allocator instanciation, if it it not set or if it is
not valid for the pool.

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

plugins: distinguish allocation and negotiation caps

The vaapi video decoders might have different allocation caps from
the negotiation caps, thus the GstVideoMeta shall use the negotiation
caps, not the allocation caps.

This was done before reusing gst_allocator_get_vaapi_video_info(),
storing there the negotiation caps if they differ from the allocation
ones, but this strategy felt short when the allocator had to be reset
in the vaapi buffer pool, since we need both.

This patch adds gst_allocator_set_vaapi_negotiated_video_info() and
gst_allocator_get_vaapi_negotiated_video_info() to store the
negotiated video info in the allocator, and distinguish it from
the allocation video info.

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

vaapivideomemory: rename qdata quarks and ids

Also the parameter names were renamed to reflect their origin
and purpose.

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

vaapivideobufferpool: rename local variables

Renamed local video info structure names in set_config() vitual
method. The purpose of their renaming is to clarify the origin
of those structures, whether come from passed caps parameter
(new_allocation_vinfo) or from the configured allocator
(allocator_vinfo).

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

vaapivideobufferpool: rename video info structures

Renamed private GstVideoInfo structure video_info to allocation_vinfo
and alloc_info to negotiated_vinfo.

The purpose of these renaming is to clarify the origin and purpose of
these private variables:

video_info (now allocation_vinfo) comes from the bufferpool
configuration. It describes the physical video resolution to be
allocated by the allocator, which may be different from the
negotiated one.

alloc_info (now vmeta_vinfo) comes from the negotiated caps in
the pipeline. It represents how the frame is going to be mapped
using the video meta.

In Intel's VA-API backend, the allocation_vinfo resolution is
bigger than the negotiated_info.

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

libs: encoder: set framerate if bigger than 0/1

Just set the framerate parameter if the framerate numerator and
denominator are bigger than zero.

Otherwise, in Intel Gen6 driver, a warning is raised disabling the
bitrate control.

Original-patch-by: Hyunjun Ko <zzoon@igalia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783532

libs: encoder: bitrate target percentage calculation

If the rate control is set to Constant Bit Rate (CBR) the target
percentage is 100%, otherwise is 70%

libs: encoder: h264,h265,mpeg2,vp8,vp9: refactor ratecontrol param

Centralize the common configuration for the Rate Control parameter,
thus can be overloaded per each specific encoder.

libs: encoder: h264,h265,mpeg2,vp8,vp9: refactor framerate param

Since the framerate VA parameter is calculated equally among all the
encoders, it is better to handle it in the base encoder class.

libs: encoder: vp9: Adds CBR and VBR Encoding support

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

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

libs: encoder: vp8: Adds VBR Encoding support

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

libs: encoder: h265: Adds VBR Encoding support

Enables Variable BitRate mode, which does set FrameRate and RateControl
parameters.

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

libs: encoder: Describes more detail about the bitrate property

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

libs: encoder: h265: add rate control parameter

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

libs: encoder: h264,h265,mpeg2: add framerate parameter

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

libs: encoder: vp8,h264,h265,mpeg2: set misc param once

Instead of recalculating the miscellaneous buffer parameters for
every buffer, it is only done once, when the encoder is configured.
And for every buffer, the same structures are just copied.

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

libs: encoder: vp8,h264,h265,mpeg2: refactor misc parameters

This is patch pretends to decouple the assignation of the values
in the parameter structures and the VA buffer's parameters setting.

It may lead to some issues since HRD, framerate or controlrate may
not be handled by the specific encoder, but they are set in
the VA buffer's parameters.

I leave as it because this patch is just a transitional patch.

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

libs: encoder: vp8: fix frame rate calculation

According to the VA documentation:

     The framerate is specified as a number of frames per second,
     as a fraction.  The denominator of the fraction is given in
     the top half (the high two bytes) of the framerate field, and
     the numerator is given in the bottom half (the low two bytes).

     For example, if framerate is set to (100 << 16 | 750), this is
     750 / 100, hence 7.5fps.

     If the denominator is zero (the high two bytes are both zero)
     then it takes the value one instead, so the framerate is just
     the integer in the low 2 bytes.

This patch fixes the the framerate calculation in vp8 encoder
according to this.

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

libs: encoder: vp8: refactor FrameRate parameter

Move frame-rate parameter from ensure_misc_params() to
ensure_contro_rate_param() since it only has meaning when the
control rate is either VBR or CBR.

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

libs: encoder: h264,h265,mpeg2,vp8: refactor HDR

Move the Hypothetical Reference Decoder (HRD) parameter, from
ensure_misc_params() to ensure_control_rate_params(), since it
only shall be defined when the control rate is either VBR or CBR.

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

libs: encoder: h264,vp8,mpeg2: refactor control rate

Instead of filling the control rate param in ensure_misc_params(),
this patch refactor it out, as a first step to merge the same code
for all the encoders.

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

libs: encoder: h264, h265, mpeg2: remove assert

Remove spurious asserts for misc parameters. If they cannot be
allocated, FALSE is already returned.

libs: encoder: use VA quality level structure

Instead of using a proxy to story the buffer quality level, the
encoder now uses the native VA structure, which is copied to the
dynamically allocated VAEncMiscParameterBuffer.

This approach is computationally less expensive.

libs: standardize the FIXME comment

This is a trivial patch that makes homogeneous the FIXME tag in
comments.

For more info about these comment style:
http://wiki.c2.com/?FixmeComment

libs: encoder: vp8: set quality level regardless of rate control mode

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

libs: encoder: check for maximum number of slices

Right now, H264 and HEVC can set as a property the number of slices to
process. But each driver can set a maximum number of slices, depending
on the supported profile & entry point.

This patch verifies the current num_slices to process against the maximum
permitted by the driver and the media size.

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

libs: utils: mark functions as internals

The functions in this header are internal to the library.

libs: context: add missing documentation

Document the region-of-interest configuration variables.

tests: elements: vaapisink: handle nav events

The test app can now handle navigation events to rotate the
display.

tests: elements: clean up vaapisink test

- Use gst_element_send_event() instead of gst_pad_push_event()
- don't zero App structure
- check for pipeline parsing error
- only get vaapisink for property set

vaapisink: keep handle_events flag except that if user want to set

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

libs: window: x11: fix src rect info when using vpp

Since we started using VPP in VaapiWindowX11, we need to care about
the case that src rect and window's size are different.

So, once VPP has converted to other format, we should honor the
size of the VPP's surface as source rect. Otherwise, it is cropped
according the previous size of the source rect.

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

plugins: remove par from caps negotiation

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

tests: elements: add an example for ROI

This implements a pipleint to recognize difference between ROI and non-ROI.
See comments in this code in detail.

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

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

vaapiencode: handle custom event GstVaapiEncoderRegionOfInterest

Handles new custom event GstVaapiEncoderRegionOfInterest
to enable/disable a ROI region.

Writes a way to use new event to document.

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

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

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

$ simple-encoder -r inputfile.y4m

And you'll got an output file in H264 with two regions of interest.

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

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

libs: encoder: h264: set ROI params during encoding

Set ROI params during encoding each frame, which are set via
gst_vaapi_encoder_add_roi ()

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

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

libs: encoder: add api gst_vaapi_encoder_add/del_roi

Implements and exposes new api gst_vaapi_encoder_add/del_roi to set ROI regions.

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

libs: encoder/context: query region of interest support

Queries if the driver supports "Region of Interest" (ROI) during the config
creation.

  This attribute conveys whether the driver supports region-of-interest (ROI)
  encoding, based on user provided ROI rectangles.  The attribute value is
  partitioned into fields as defined in the VAConfigAttribValEncROI union.

  If ROI encoding is supported, the ROI information is passed to the driver
  using VAEncMiscParameterTypeROI.

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

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

libs: encoder: fix a comment

libs: encoder: guard quality level configuration

The quality level appeared in VA-API 0.36. So let's guard its
usage.

encoders: add quality level tuning

This patch adds the handling of VAEncMiscParameterTypeQualityLevel,
in gstreamer-vaapi encoders:

  The encoding quality could be set through this structure, if the
  implementation supports multiple quality levels. The quality level set
  through this structure is persistent over the entire coded sequence, or
  until a new structure is being sent. The quality level range can be queried
  through the VAConfigAttribEncQualityRange attribute. A lower value means
  higher quality, and a value of 1 represents the highest quality. The quality
  level setting is used as a trade-off between quality and speed/power
  consumption, with higher quality corresponds to lower speed and higher power
  consumption.

The quality level is set by the element's parameter "quality-level" with a
hard-coded range of 1 to 8.

Later, when the encoder is configured in run time, just before start
processing, the quality level is scaled to the codec range. If
VAConfigAttribEncQualityRange is not available in the used VA backend, then
the quality level is set to zero, which means "disabled".

All the available codecs now process this parameter if it is available.

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

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

Back to development

Release 1.12.0

Revert "vaapidecodebin: fix element's classification"

This reverts commit 8cbe03599a4f27c2001380e2ec150c4f4267a9cf.

build: Require libva < 0.99.0

libva >= 0.99.0 is not currently supported by gstreamer-vaapi, so
fail to configure instead of failing late in the build.

This libva is bundled in msdk[1] and it is ahead in time with
respect the official and open source libva[2]. GStreamer-VAAPI
only supports the latter for now.

1. https://software.intel.com/en-us/media-sdk/download
2. https://github.com/01org/libva/

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

vaapidecodebin: fix element's classification

This bin should have similar classification as decodebin which is
"Generic/Bin/Decoder" otherwise it will appear wrongly as video
decoder.

Signed-off-by: Victor Toso <victortoso@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782063

Release 1.11.91

Revert "plugins: reject pixel-aspect-ratio with value 0/1"

This reverts commit c0be7b1890ea8da915a81ae82bc9f504aee7cc26.

plugins: reject pixel-aspect-ratio with value 0/1

Do not negotiate a pixel-aspect-ratio of 0/1.

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

plugins: handle pixel-aspect-ratio with value 0/1

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.

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

vaapivideobufferpool: fix leak of created allocator

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

vaapivideobufferpool: create or reconfig allocator

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

test: elements: fix compilation flags

This issue was spotten on bug #766704

Original-patch-by: Hyunjun Ko <zzoon@igalia.com>

libs: windows: wayland: fix leak if failure of sync

Sometimes gst_vaapi_window_wayland_sync returns FALSE when poll returns EBUSY
during destruction.
In this case, if GstVaapiWindow is using vpp, leak of vpp surface happens.
This surface is not attached to anything at this moment, so we should release
it manually.

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

Automatic update of common submodule

From 60aeef6 to 48a5d85

libs: window: wayland: mark frames as done

When the frame listener callbacks 'done', the number of pending
frames are decreased. Nonetheless, there might be occasions where
the buffer listener callbacks 'release', without calling previously
frame's 'done'. This leads to problem with
gst_vaapi_window_wayland_sync() operation.

This patch marks as done those frames which were callbacked, but if
the buffer callbacks 'release' and associated frame is not marked
as 'done' it is so, thus the number of pending frames keeps correct.

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

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

libs: window: wayland: don't sync at destroy()

Don't call gst_vaapi_window_wayland_sync() when destroying the
wayland window instance, since it might lead to a lock at
gst_poll_wait() when more than one instances of vaapisink are
rendering in the same pipeline, this is because they share the
same window.

Since now all the frames are freed we don't need to freed the
private last_frame, since its address is invalid now.

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

Signed-off-by: Hyunjun Ko <zzoon@igalia.com>

libs: window: wayland: null buffer at destroy()

Fix leakage of the last wl buffer.

VAAPI wayland sink needs to send a null buffer while destruction,
it assures that all the wl buffers are released. Otherwise, the last
buffer's callback might be not called, which leads to leak of
GstVaapiDisplay.

This was inspired by gstwaylandsink.

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

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