GitLab

It seems driver requires enablement of cu_qp_delta_enabled_flag
for modifying QP values to controll the CBR mode bitrate.

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

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

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

Otherwise intel-vaapi-driver will fail to process the exported surface because
it will find it is currently derived, so considered as busy.

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

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

If the backend driver vendor string is not in a white-list, and the
environment variable GST_VAAPI_ALL_DRIVERS is not set either, the decoder will
change it state from NULL to READY, hence the auto-plug mechanism will look
for another decoder.

This patch assumes the GstContext has already being shared along the pipeline
and the element has a valid GstVaapiDisplay instance.

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

In bug 757598 was added the set_context() vmethod chain up in
GstVaapiPluginBase. But it is buggy, since the parent_class address is
assigned to the last element which called gst_vaapi_plugin_base_class_init().

No error has shown up since none of the element's base classes redefined
set_context() vmethod from GstElement, so always the correct function was
called. Still this code is wrong and this patch make it right.

Since set_context() is the same code, a macro is used to implement that code
in all the gst-vaapi elements.

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

Since commit 859a2b2f, in vaapidecode, allocation query can be different from
the negotiated caps.

When connecting the vaapidecoder to the vaapipostprocessor, the last one will
resize the frame to the negotiated, if and only if, some other parameter is
activated to avoid the passthrough. If it is not, the surface won't be mapped
into a image. If not, the image won't be resized and the output buffer would be
mapped.

This patch will break the passthrough if the allocation query is different
from the negotiation caps, forcing the resizing.

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

No functional changes.

Move the handling of the GstCapsFeatures just after it is used, in order to
avoid handling its memory.

Check that GLUploadTexture is not negotatiated if gstreamer-vaapi is not
compiled with GL support.

Instead of using the srcpad template caps for filtering the peer caps, the
function gst_vaapi_find_preferred_caps_feature(), now receives a new parameter
for the element's allowed caps.

With this modification, the vaapipostproc element simplifies a bit its code.

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

The native format parameter in gst_vaapi_find_preferred_caps_feature() can be
saved if the out format is used for both: in and out. Thus the code is more
readable.

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

If the downstream feature is system memory, the surface has to be mapped,
hence a warning message is logged saying that the driver has to do color
conversions. This might be troublesome because not all the color conversion
combinations are supported by the VA-API drivers, and there is not a reliable
way to know them before hand.

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

Instead of setting the requested format by the caller, the function
gst_vaapi_find_preferred_caps_feature() now returns, in the output parameter,
the negotiated format.

A new helper function was added: gst_vaapi_find_preferred_format(), which,
given the format list from the negotiated caps, will choose the best one, if
possible, given the native format.

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

This patch simplifies the function gst_vaapi_find_preferred_caps_feature().

Instead of intersecting custom caps to find the preferred feature, the peer
caps are traversed in order to find the preferred feature, according to an
ordered feature priority list.

In the case of GLTextureUploadMeta, the colour format is computed using
GstVideoInfo of the selected fixed caps.

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

Instead of accessing directly to the members of the structure, use the macros.

Make the comparisons more readable and simple.

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

Instead of keeping the structure GstVideoInfo when we are using its width and
height, we only keep these two guints.

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

As decoded_info is assured to be valid when gst_vaapidecode_update_src_caps()
is called, then we don't need to verify or replace it with the sinkpad info
(reference state).

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

Always set a valid format in decoded_info class variable.

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

No functional changes.

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

It is required to initialize {decoded,display}_info variables when the decoder
is open, not only at instance initialization.

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

active, do_pool_renego and do_outstate_renego class variables were used to
indicate when negotiate downstream once, but now that each time a new surface
resolution is pop out a renegotation verified, these variable are not required
anymore.

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

When resolving bug 753914, a custom allocation query was added, overlapping
the responsibilities of GstVideoDecoder.

But with the merge of the patches from bug 764421 this overlapping was not
required anymore. This patch restores this situation setting the
allocation_caps in the GstVideoCodecState when needed.

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

From 6f2d209 to ac2f647

The plugins should not expose the feature meta:GstVideoGLTextureUploadMeta in
their caps templates if they were not compiled either with GLX or EGL support.

The compiler might complain of gst_vaapi_create_display_from_handle() being
unused if both EGL and GLX are disabled. This patch avoid that compilation
error.

Call gst_vaapi_video_pool_finalize() in coded_buffer_pool_finalize().
Otherwise it is not called when the pool is destroyed and all objects
referenced by the GstVaapiVideoPool are never released.

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

If gst_vaapi_image_new_with_image() fails, the created derived image should be
destroyed, otherwise the surface cannot be processed because is being used.

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

Clear any status on the current stream:

stored frames, caps and decoder configuration

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

The subsampling_x, subsampling_y, bit_depth, color_space and color_range
fileds are moved from GstVp9FrameHdr to the global GstVp9Parser structure.
These fields are only present in keyframe or intra-only frame, no need to
duplicate them for inter-frames.

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

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

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

The configuration option --disable-examples will disable the compilation of
the sample apps in tests/ directory.

There is no difference in VAAPI surface caps between encoders and decoders.
Thus, the patch makes a simplification by removing encoders specific caps and
shares the same definition of VAAPI surfaces caps for all the elements.

With it we can remove a function declaration, making the code a bit
more readable.

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