The vaCreateContext do not need to specify the surfaces for the
context creation now. So we do not need to bind any surface to the
context anymore. Surfaces should be the resource belong to display
and just be used in encoder/decoder context.
The previous manner has big limitation for decoder. The context's
surface number is decided by dpb size. All the surfaces in dpb will
be attached to a gstbuffer and be pushed to down stream, and the
decoder need to wait down stream free the surface and go on if not
enough surface available. For more and more use cases, this causes
deadlock. For example,
gst-launch-1.0 filesrc location=a.h264 ! h264parse ! vaapih264dec
! x264enc ! filesink location=./output.h264
will cause deadlock and make the whole pipeline hang.
the x264enc encoder need to cache more than dpb size surfaces.
The best solution is seperating the surfaces number and the dpb size.
dpb and dpb size shoule be virtual concepts maintained by the decoder.
And let the surfaces_pool in context maintain the re-use of all surfaces.
For encoder, the situation is better, all the surfaces are just used
as reference frame and no need to be pushed to down stream. We can
just reserve and set the capacity of the surfaces_pool to meet the
request.
Fix: #147Fix: #88
Co-Author: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/353>
This commit tries to centralize the selection of vaCreateSurfaces
version, instead of having fallbacks everywhere.
These fallbacks are hacks, added because new drivers use the latest
version of vaCreateSurfaces (with surface attributes) [1], meanwhile
old drivers (or profiles as JPEG decoder in i965) might rather use the
old version.
In order to select which method, there's detected hack: each config
context has a list of valid formats, in the case of JPEG decoder the
list only contains "rare" 4:2:2 formats (ICM3, GRAY8) which aren't
handled correctly by the current gstreamer-vaapi code [2].
The hack consist in identify if the format list contains an arbitrary
preferred format (which is suposedly well supported by
gstreamer-vaapi, mostly NV12). If no prefered colour format is found,
the the old version of vaCreateSurfaces is used, and the surfaces wil
be mapped into a image with their own color format.
1. https://bugzilla.gnome.org/show_bug.cgi?id=797143
2. https://bugzilla.gnome.org/show_bug.cgi?id=797222
FEI encoders are not actively mantained neither tested, and it is
using infrastructure that is changing and FEI is stopping this
effort.
Also it is required to rethink how FEI can be used in GStreamer.
The symbol GST_VAAPI_ENTRYPOINT_INVALID is just a representation of
zero, which was already used as an invalid value tacitly. This patch
only makes it explicit.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
GstVaapiMiniObject and GstVaapiObject are deprecated.
This is the first step to remove them by porting GstVaapiSurface as
a GstMiniBuffer descendant.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
The GstVaapiMiniObject is obsolete and we need to replace it. This
patch turns GstVaapiContext into a plain C structure with its own
reference counting mechanism.
Also this patch removes unused overlays attributes.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
The context overlay was an optimization to apply a video composition
to all the surfaces bound to a context.
But since commit 18031dc6 this optimization was disabled, so it is
better just get rid of it.
In commit 18031dc6 surface's parent context is not assigned because of
circular references. Since then (2013), there's has no issue with
subpictures attached to a context, the current only users of this API.
This patch cleans up all of related code with the unused surface's
parent context.
VA_ROI_RC_QP_DELTA_SUPPORT return value will be ignored when the
rate control mode is set as CQP. In CQP mode, it shouldn't check
roi_rc_qp_delta_support return value from driver backend.
https://bugzilla.gnome.org/show_bug.cgi?id=797087
In gst_vaapi_context_reset(), if the context has to be destroyed, make
sure to create it first before allocating its associated surfaces.
This patch fixes a regression introduced in commit 82872f4 because
the formats available in the current context now are ensured before
creating the context's surfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=797277
Check input buffers for ROI metas and pass them to VA. Also added a
new "default-roi-delta-qp" property in order to tell the encoder what
delta QP should be applied to ROI by default.
Enabled it for H264 and H265 encoders.
https://bugzilla.gnome.org/show_bug.cgi?id=768248
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
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.
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>
If GstVaapiContextInfo has just initial information, without frame's
width and height, skip the creation of the VAContext, just keep the
VAConfig.
https://bugzilla.gnome.org/show_bug.cgi?id=769266
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Split the funcion context_create() into context_create() and
config_create().
Decoupling VAConfig and VAContext during context creation, we could
query the VAConfig for the supported surface's formats without creating
a VAContext.
https://bugzilla.gnome.org/show_bug.cgi?id=769266
This patch ensures to get the formats, as filter does, available in the
decoder / encoder context.
The context fills up the array as soon it is created, otherwise the pipeline
could get stalled (perhaps this is a bug in my HSW backend).
https://bugzilla.gnome.org/show_bug.cgi?id=752958
As gst-indent generated ugly code in these cases, this patch changes the used
idiomatic into other one.
No functional changes were introduced.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Only supporting vaapidecode ! vaapisink combination for now.
Missing dependencies:
1: No support for P010 video format in GStreamer
2: No support for P010 vaGetImage()/vaPutimage() in vaapi-intel-driver
3: As a result of 1&2 , we have no support for Vaapi Video memory mapping
through GstVideoMeta.
Right now we only set chroma format (YUV420 with more than 8 bits per channel)
for surface pool and keeping GST_VIDEO_FORMAT as ENCODED. The underlying format
of the surfaces is implementation (driver) defined, which is P010.
When we query for the VAConfigAttribEncJPEG, we get a value which packs the
VAConfigAttribValEncJPEG structure, but we did not assign it. This patch
assigns the returned value to the attribute.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=744042
Reword surface pool allocation helpers so that to allow for a simple
form, e.g. gst_vaapi_surface_pool_new(format, width, height); and a
somewhat more elaborated/flexible form with optional allocation flags
and precise GstVideoInfo specification.
This is an API/ABI change, and SONAME version needs to be bumped.
Add support for dynamic growth of the VA surfaces pool. For decoding,
this implies the recreation of the underlying VA context, as per the
requirement from VA-API. Besides, only increases are supported, not
shrinks.
It is a requirement from VA-API specification that the VA context got
from vaCreateContext(), for decoding purposes, binds the supplied set
of VA surfaces. This means that if the set of VA surfaces is to be
changed for the current decode session, then the VA context needs to
be recreated with the new set of VA surfaces.
Request the correct chroma format for decoding grayscale streams.
i.e. make lookups of the VA chroma format more generic, thus possibly
supporting more formats in the future.
This means that, if a VA driver doesn't support grayscale formats,
it is now going to fail. We cannot safely assume that maybe grayscale
was implemented on top of some YUV 4:2:0 with the chroma components
all set to 0x80.
Don't force allocation of VA surfaces in YUV 4:2:0 format. Rather, allow
for the upper layer to specify the desired chroma type. If the chroma
type field is not set (or yields zero), then YUV 4:2:0 format is used
by default.
Add gst_vaapi_get_config_attribute() helper function that takes a
GstVaapiDisplay and the rest of the arguments with VA types. The aim
is to have thread-safe VA helpers by default.
Make sure to configure the encoder with the set of packed headers we
intend to generate and submit. i.e. make selection of packed headers
to submit more robust.
Introduce GstVaapiContextUsage so that to explicitly determine the
usage of a VA context. This is useful in view to simplifying the
creation of VA context for VPP too.
Unknown attributes, or attributes that are not supported for the given
profile/entrypoint pair have a return value of VA_ATTRIB_NOT_SUPPORTED.
So, return failure in this case.
Move GstVideoOverlayComposition handling to separate source files.
This helps keeing GstVaapiContext core implementation to the bare
minimal, i.e. simpy helpers to create a VA context and handle pool
of associated VA surfaces.
Improve documentation and debug messages. Clean-up APIs, i.e. strip
them down to the minimal set of interfaces. They are private, so no
need expose getters for instance.
