decoder: vc1: fails only on advanced profile

In commit 2eb4394 the frame coding mode was verified for progressive
regardless the profile. But the FCM is only valid in the advanced
profile. This patch checks for the advanced profile before verifying FCM for
progressive.

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

vaapi: DISPLAY envvar as dependency

In a multiple video cards system, a X11 environment may have different VA
capabilities. This patch tracks the DISPLAY environment variable to
invalidates the GStreamer features cache. Also tracks WAYLAND_DISPLAY.

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

decoder: vc1: Fail only on actual interlaced frames

In the earlier patch:

 f31d9f3 decoder: vc1: Print error on interlaced content

Decoding would error out if the interlace flag was set in the
sequence bdu. This isn't quite right because a video can have this
flag set and yet not have any interlaced pictures.

Here instead we error out when either parsing a field bdu or
decoding a frame bdu which has fcm set to anything other than
progressive.

Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=769250

Back to development

Release 1.9.2

decoder: vc1: Print error on interlaced content

Interlaced video is as yet unsupported in the vc1 element. Print
an error to make that more obvious.

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

encoder: h264: fix C90 mixed declarations and code

Commit 4259d1a introduced this compilation error. This patch fixes it.

encoder: h264,h265,mpeg2,vp8: use gst_util_uint64_scale() for bitrate

Use gst_util_uint64_scale() to calculate bitrate instead of normal arithmetic
to avoid overflows, underflows and loss of precision.

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

vaapiencode: h264,h265: validate fps numerator

Validate that fps numerator is non-zero so it can be used to calculate
the duration of the B frame.

Also it gst_util_uint64_scale() is used instead of normal arithmetic in
order to aviod overflows, underflows and loss of precision.

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

encoders: demote to RANK_NONE since not fit for autoplugging yet

Encoders claim to support a whole bunch of input formats but then
just error out if the format is not actually supported, even if
there's a converter in front. This means they're not fit for
autoplugging in encodebin or camerabin yet and therefore should
not have a rank. People can still use them in custom pipelines.

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

plugins: check dmabuf-import for sink pad allocator

Check earlier if upstream video source has activated the dmabuf-import
io-mode (hack to disappear soon), thus we can avoid the re-assignation of a
new allocator.

plugins: reset allocators if video info changed

If the frame size or format, change, the allocators are reset, so a new ones
can be created with the new video info.

plugins: remove sink pad allocator if caps change

If the negotiated sinkpad caps change, destroy the assignated allocator,
because it is not valid anymore.

pluginutil: const params to gst_video_info_changed()

Since they are not modified, we should mark them as const.

gstvaapivideomemory: allocator's image size getter

Add the method gst_allocator_get_vaapi_image_size() for the
GstVaapiVideoAllocator, which gets the size of the allocated images with the
current video info.

This method replaces the direct call to the allocator's image info when the
pool is configured.

plugins: update buffer pool size with new allocator's image size

Depends on media, video size is sometimes updated with new allocator.
It leads to dismatch between bufferpool's set size and real allocated buffer size.

In this case, it causes every buffer is freed during release in bufferpool,
which should be reused. This affects performance.

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

configure: remove gmodule-2.0 EGL dependency

Since commit 27429ce, EGL support doesn't depend on dynamic loading libraries,
thus the dependency to gmodule-2.0 is not mandatory anymore.

configure: Fix non-fatal PKG_CHECK_MODULES invocations

Some invocations of PKG_CHECK_MODULES were intended to be non-fatal if
the package is missing, but action-if-not-found was given as an empty
string which still causes the default action to run, which halts
execution.

Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=769237

libs: egl: remove dynamic library loading code

Since the upstream of gstreamer-vaapi, the library is not a public shared
object anymore. But the EGL support depended on this dynamic library, so the
EGL support was broken.

This patch removes the dynamic library loading code and instantiates the
EGL display using either X11 or Wayland if available.

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

vaapidecode: register only the available decoders

In order to register only the available decoders, this patch queries the
created test VA display, which uses the currently used back-end (X11, Wayland,
DRM, …) on the used display device.

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

vaapi: register only the available encoders

In order to register only the available encoders, this patch queries the
created test VA display, which uses the currently used back-end (X11,
Wayland, DRM, …) on the used display device.

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

vaapidecode: split all the codecs

Split the vaapidecode to all the supported codecs with the format
vaapi{codec}dec.

vaapidecode is stil registered as a GObject type, but not as a
GStreamer feature, so it can be used internally by vaapidecodebin without
changing its code too much.

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

vaapidecodebin: simplify the code

Since the elements dependant of the VA video processor are now only registered
if it is available, vaapidecodebin code can be simplified a lot, removing all
the code required to check if the VA video processor was available.

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

vaapidecode: delay the GstVaapiDisplay instantiating

Delay the GstVaapiDisplay instantiating until when changing the state from
READY to PAUSE. In this way the element has more chances to find an already
created GstVaapiDisplay, or a GL context, in the pipeline.

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

pluginutil: set GLX display type

The function gst_vaapi_create_display_from_gl_context() cretes a
GstVaapiDisplay given a GstGLContext. But it didn't created a GLX VA display
when the GL platform was GLX, but a plain X11 VA display.

This patch fixes that, by querying the GL platform earlier.

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

plugins: add gst_vaapi_plugin_base_find_gl_context()

Using the GstContext mechanism, it is possible to find if the pipeline
shares a GstGLContext, even if we are not to negotiating GLTextureUpload
meta. This is interesting because we could negotiate system memory caps
feature, but enable DMABuf if the GstGLContext is EGL with some extensions.

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

plugins: remove gst_vaapi_plugin_base_driver_is_whitelisted()

Since nobody is calling gst_vaapi_plugin_base_driver_is_whitelisted(),
it is deleted.

plugins: remove common change_state() vmethod

Remove the common change_state() vmethod for all the plugins, since no one is
using it.

vaapidecode: remove change_state() vmethod

Since the driver checkup is done at registering, there is no need to do it
when changing the element state from NULL to READY. This patch remove this
vmethod from vaapidecode.

vaapi: register vaapipostproc only if supported

Query the GstVaapiDisplay to know if the driver supports video
postprocessing. If does, then register vaapipostproc and vaapidecodebin
elements.

This patch will simplify the design of vaapidecodebin.

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

vaapi: don't register if VA driver is unsupported

Using the test VA display, the driver name is queried, and if it is not
white-listed, the plugin rejects to register any element.

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

plugins: add gst_vaapi_driver_is_whitelisted()

Move some of the logic in gst_vaapi_plugin_base_driver_is_whitelisted() to a
new function gst_vaapi_driver_is_whitelisted(), in this way, it can be used
when registering the plugin's feature set with the test VA display.

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

vaapi: instantiate a VA display when registering

This patch tries to instantiate a GstVaapiDisplay when registering the plugin
features, if it fails, no gstreamer-vaapi element is registering.

The purpose of this patch is to avoid a situation where the user has
gstreamer-vaapi installed but their VA-API setup is not functional, which may
lead to unexpected behavior.

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

vaapi: declare external dependencies

There are two main external dependencies that define the feature set of this
plugin: a) the kernel and b) the VA driver

This patch tracks both dependencies, if any of them change, GStreamer will
re-inspect the plugin.

The kernel is tracked through the device files /dev/dri/card*

The VA driver is tracked through the files VA_DRIVERS_PATH/*_drv_video.so,
where VA_DRIVERS_PATH is the one defined in libva package configuration. Also,
the environment variables LIBVA_DRIVERS_PATH and LIBVA_DRIVER_NAME are tracked
since they modify the driver lookup.

Additionally, the environment variable GST_VAAPI_ALL_DRIVERS is tracked too.

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

vaapidecode: remove unneeded initializations

GObject's memory is set to zero, so there is no need to initialize to zero or
NULL it's class variables.

plugins: remove undefined macros

Revert "gstvaapisurface_drm: release image when done"

This reverts commit 1dbcc8a0e199f2da6a0ab8e949f13341916128a3  and commit
372a03a9e38acbf435eb80bf31d9a9844069e504.

While the dmabuf handle is exported, the derive image must exist, otherwise
the image's VA buffer is invalid, thus the dmabuf handle is never released,
leading into a file descriptors leak.

encoder: h265: fix code-style

vaapipostproc: update filters at color balance

This is a fix for a regression of previous commit, which updates the filters
only when the property is set, because it is also required to update the
filter when the color balance interface change its values.

vaapipostproc: make it enable/disable pass-through mode

In case that sink caps and src caps are same, and no filtering parameter set,
pass-through mode is enabled.
If new filtering parameter is set during playback, it makes it reconfiguring,
so that pass-through mode is changed

In addition, updating filter is performed during reconfiguration, if needed.

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

vaapipostproc: checking and updating filter parameter only when it's set

This patch is to avoid checking filter value at every frame.

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

decoder: h265: handle the SEI NAL units included in codec_data

The prefix/suffix SEI nal units can appear in codec_data too
which weren't handled before. Parse these SEI headers to
fix the segfault.

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

build: doc: do not redefine MAINTAINERCLEANFILES

MAINTAINERCLEANFILES is defined in gtk-doc-plugins.mak, thus instead of
overload it, the files should be added.

encoder: h264: Fix MVC encode while enabling dct8x8

Pack the transform_8x8_mode_flag and other necessary rbsp data
in packed_pps header for MVC encode.

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

vaapisink: demote a debug message to trace

Reduces noise when debugging.

wayland: Error check before using cached wl_display

A planar(or some other) buffer allocation may fail on the driver, then
the wayland connection becomes invalid, not able to send request or
receive any event. So we need to set up a new wayland connection if
there's an error detected on the cached wl_display.

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

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

Automatic update of common submodule

From ac2f647 to f49c55e

vaapiencode: demote a log to trace level

Removes noise when debugging.

vaapiencode: implement flush() vmethod

In order to handle correctly seek and other operations, vaapiencode should
flush all the remaining data from the encoder without pushing it downstream.

This patch implements the flush() vmethod, only after of pausing the
source pad task, and restarting it again after the flush stop.

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

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

decoder: vc1: flush dpb only if opened

Flush the decode picture buffer, if and only if, the decoder is
started. Otherwise the dpb structure might be NULL.

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

vaapidecode: drop non-keyframe in reverse playback

To avoid surface-exhausted situation during reverse playback,
drop frames except for key frame.

Also, to avoid the corruption of the parser state, flush() vmethod
doesn't destroy the VA decoder when playing in reverse.

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

Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>

vaapidecode: unref output frame earlier

The queue in GstVaapiDecode adds an extra reference to the frames. This patch
unref that extra reference earlier making the code simpler to follow.

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

vaapidecode: remove gst_vaapidecode_internal_flush()

As gst_vaapidecode_finish() is the only callee of
gst_vaapidecode_internal_flush(), it is better to inline it.

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

vaapidecode: flush output adapter at drain()

Calling drain() vmethod means "decode any data it can at this point, but that
more data may arrive after". Hence, vaapidecode should check if there is data
in the output adapter and process them, without destroying the decoded picture
buffer (dpb).

Since this operation is done by gst_vaapidecode_internal_flush(), the operation
was refactored into a new function gst_vaapidecode_flush_output_adapter().

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

vaapidecode: call purge at flush()

Calling flush() vmethod means "to flush all remaining data from the decoder
without pushing it downstream".

Nonetheless flush() is calling gst_vaapidecode_internal_flush(), which calls
gst_video_decoder_have_frame() if there is still something in the input
adapter, which may push buffers to downstream by calling handle_frame().

This patch changes this behavior by calling gst_vaapidecode_purge() rather
than gst_vaapidecode_internal_flush(), which does what we want: flushes the VA
decoder and releases all the rest of decoded frames.

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

test: elements: remove spurious linkage

Element tests only need to link against gstreamer libraries.

configure: Require GLib >= 2.40 like everywhere else

Back to development

Release 1.9.1

tests: elements: rotate orientation event

tests: elements: Add testsuite for vaapisink

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

vaapisink: add support for GST_TAG_IMAGE_ORIENTATION

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

vaapipostproc: return caps template if no display

This patch is a fix for my bad review of commit 6d73ca8d. The element should
be able to return the available raw caps handled by the VA display, but that
only should happen when there a VA display. If there's none, the element
should use the caps template.

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

vaapipostproc: don't require a vaapi display for all caps queries

This delays the requirement of having a GstVaapiDisplay until later

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

utils: report VP9 profiles

Add VP9Profile0-3 name mapping.

vaapi: nest includes under USE_ENCODER macro

This is a missed changeset from commit 1c05c53, since also header includes
should be nested.

vaapi: nest encoders under USE_ENCODER macro

Though USE_{JPEG,VP8,VP9,H265}_ENCODER macros definition depend on USE_ENCODER
macro, it is clearer to nest them, showing explicitly the dependency relation.

vaapivideocontext: check if query context is NULL

Under certain conditions the element might receive a positive context query
but without a context instance. This situation will lead to a segmentation
fault when traversing the context list in the pipeline.

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

remove unused glibcompat.h

glibcompat.h is no longer doing anything. Remove it.

Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=767886

encoder: h264: Use high profile by default

Change defaults for max-bframes, cabac, and dct8x8 to be enabled
by default. This will cause the default profile to be high instead
of baseline. In most situations this is the right decision, and
the profile can still be lowered in the case of caps restrictions.

Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757941

vaapidecodebin: element warning if missing element

Raise an element warning if a required element is not available, thus the
pipeline will post a warning message and the application will be informed.

decoder: h265: fix to release all dpb pictures

Without this, all dpb pictures are not released during flush,
because we used the global dpb_count variable for checking the
dpb fullness which get decremented in dpb_remove_index()
routine during each loop iteration.

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

Automatic update of common submodule

From ac2f647 to f363b32

vaapi: fix minor leaks

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

vaapi: remove an already included header

gst/gst.h is already included in gstcompat.h

vaapidecodebin: add vp9 in sink pad template

vaapisink: return caps template if no display

If vaapisink received a caps query before getting a VA display, it returned
only the surfaces related caps. This behavior broke the autovideosink
negotiation.

This patch returns the pad's template caps if no VA display, otherwise the
caps are crafted as before.

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

decoder: vp9: Update comment about context resets

Clarify that vaapi context resets are never needed for vp9, but
that ensure_context() needs called when the size increases so that
new surfaces can be allocated.

Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=767474

gstvaapicontext: control reset_on_resize with option

Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=767474

vaapivideobufferpool: add video meta to config when needed

In cases where we know the video meta must be present, add it to
the pool configuration.

Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=766184

plugins: retry pool config

if gst_buffer_pool_set_config returns FALSE, check the modified
config and retry set_config if the config is still acceptable.

Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=766184

vaapivideomemory: internal attributes to methods

Mark as internal the functions used by VA-API dmabuf allocator.

plugins: remove precondition for decide_allocation()

There's no need to check for the display in the plugin object when
decide_allocation() vmethod is called, because the display will created or
re-created along the method execution.

plugins: avoid possible memory leaks

Get the pool config just before use it, to avoid a memory leak if the
allocator cannot be instantiated. Similarly, return FALSE if the configuration
cannot be set, avoid keep a not used allocator in the pool.

plugins: use GstParentBufferMeta

Instead of using the VASurface proxy's notify, which is internal gstvaapi API,
use the GStreamer's GstParentBufferMeta.

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

plugins: cache VASurfaces from dmabufs

This patch avoids the creation of a VASurface each time a new input buffer is
processed, caching them in the input buffer itself.

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

libs: change gst_vaapi_surface_new_with_dma_buf_handle()

Instead of passing the data already in GstVideoInfo, let's just pass the
GstVideoInfo structure.

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

plugins: use an unique allocator per pad

Instead of instantiating an allocator per vaapivideobufferpool, only one
allocator is instantiated per element's pad and shared among future pools.
If the pad's caps changes, the allocator is reset.

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

vaapivideobufferpool: share options flag with pluginbase

Originally, vaapivideobufferpool has a set of boolean variables for the
buffer configuration options.

This pach changes these boolean variables for a single bitwise, just as
it is used in pluginbase. Hence, the internal enum was moved to
vaapivideobufferpool header.

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

plugins: add gst_vaapi_plugin_base_create_pool()

This patch refactors the code in pluginbase in order to centralize the buffer
pool instantiation. As the buffer pool config may have different options, these
are gathered using a bitwise flag.

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

pluginbase negotiates allocator with bufferpool

Originally vaapivideobufferpool instantiates its own allocator regardless the
received configuration, and it relies in custom configuration options to
choose which kind of allocator instantiate.

This patch transfers the responsibility of the allocator instantiate to
vaapipluginbase and pass it to the vaapivideobufferpool through its
configuration.

* gst/vaapi/gstvaapipluginbase.c
  + set_dmabuf_allocator(): inserts a dmabuf allocator in the bufferpool
  + ensure_sinkpad_buffer_pool(): set a normal vaapi video allocator in
    bufferpool configuration
  + gst_vaapi_plugin_base_propose_allocation(): call set_dmabuf_allocator() if
    needed.
  + gst_vaapi_plugin_base_decide_allocation(): set a normal vaapi video
    allocator in bufferpool configuration
* gst/vaapi/gstvaapivideobufferpool.c
  + gst_vaapi_video_buffer_pool_set_config(): instead of instantiate the
    allocator, process the received one through its configuration.
* gst/vaapi/gstvaapivideobufferpool.h: removed
  GST_BUFFER_POOL_OPTION_DMABUF_MEMORY since it is not used anymore.
* gst/vaapi/gstvaapivideomemory.c
  + gst_vaapi_is_dmabuf_allocator(): new helper function to identify a dmabuf
    allocator with the vaapi qdata.

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

vaapivideobufferpool: keep only current video info

Instead of keeping old and new GstVideoInfo video structure, we only keep one,
the current one, the negotiated. The old one is not needed at all.

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

pluginutil: add gst_video_info_force_nv12_if_encoded()

This lines repeat a couple times in the code, so it would be better to put it
a helper function.

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

pluginutil: add gst_video_info_changed() helper

This function is shared among different elements, so let factorized it.

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

vaapipostproc: Add colorimetry attributes to src caps

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

vaapidecode: remove chroma-site and colorimetry from src caps

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

vaapipostproc: add postproc_lock to protect data members

Add a mutex to postproc to protect concurrent access to data members.
Previously set_caps() could release the allowed_srcpad_caps while
transform_caps was in the middle of using it.

Signed-off-by: Scott D Phillips <scott.d.phillips@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=766940

encoder: vp9: Add simple algorithms for reference picture selection

Added two modes(as properties) for reference picture selection:

ref-mode-0: AltRef and GoldRef pointing to the recent keyframe
and LastRef is pointing to the previous frame.

ref-mode-1: Previous frame (n) as LastRef , n-1 th frame as GoldRef
and n-2 th frame as AltRef

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

encoder: vp9: Define Max frame width and height

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

encoder: vp9: Add more propertis for tuning encode quality

Added three tuning properties:
1: filter_level
2: sharpness_level
3: luma ac quant-table index

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