This helper function iterate all profiles and entrypoints belong
to the specified codec, query the VAConfigAttribRTFormat and list
all possible video formats.
This function is used by each codec to get the template sink caps
(for encode) or src caps(for decode) at register time, when just
all possible formats are listed and no need to be very accurate.
So there is no context created for the performance reason. Most
codecs just use YUV kinds of formats as the input/output, so we do
not include RGB kinds of formats. User can specified more formats
in extra_fmts(For example, jpeg may need BGRA) if needed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/315>
We may build this plugin with window system support but run it without
window system. Without this patch, the following pipeline will trigger a
segfault when running it without window system.
gst-launch-1.0 filesrc location=input.264 ! h264parse ! vaapih264dec ! fakesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/319>
Since bufferproxy and surface are not referenced circularly, there's
no need to keep, in the buffer proxy, a reference to the GstMemory
where it is held. This patch removes that handling.
The bufferproxy may reference the surface and the surface may also
reference the bufferproxy, producing a circular reference, which might
lead to serious resource leak problems.
Now make the relationship clearer, the bufferproxy's references is
transfered to surface, while bufferproxy just keeps the surface's
address without increasing its reference count.
The surface can be created through a bufferproxy like in
gst_vaapi_surface_new_with_dma_buf_handle(), and the surface might
get its bufferproxy via gst_vaapi_surface_get_dma_buf_handle(). In
both cases the surface holds a bufferproxy's reference.
The old way of refer memory by bufferproxy is not a good one, since it
make the logic error prone.
Now it is established a map between surface-bufferproxy and its GstMemory,
caching the memory bound by a surface looked for the specified surface.
Delete the GST_VAAPI_VIDEO_BUFFER_POOL_ACQUIRE_FLAG_NO_ALLOC flag.
In fact, no one is using that flag, and all vaapi buffers should
have GstVaapiVideoMeta.
This fixed segfault when running the pipeline below with iHD driver
(commit efe5e9a) on ICL
gst-launch-1.0 videotestsrc ! vaapivp9enc tune=low-power ! vaapivp9dec ! \
fakesink
This options is added to synchronize with other gstreamer packages
build configuration.
Though, to avoid breaking distro configuration it is set, as default,
the issues gitlab's url, instead of the used string
"Unkown package origin".
Also, set_quoted is used for string based cdata.
In hevc, we can consider the -intra profile a subset of the none
-intra profile. The -intra profiles just contain I frames and we
definitely can use the none -intra profiles's context to decode
them.
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
This is a workaround for intel-media-driver bug
https://github.com/intel/media-driver/issues/865
The driver will force the RC method to CBR for HEVCe
when it parses the HRD param. Thus, any RC method
param submitted "prior" to the HRD param will be lost.
Therefore, VBR, ICQ and QVBR for HEVCe can't be
effectively enabled if the RC method param "precedes"
the HRD param.
To work around this issue, set the HRD param before
the RC method param so the driver will parse the RC
method param "after" the HRD param.
Afaict, other codecs in the driver (and other drivers)
do not appear to be dependent on the order of HRD and
RC param submission.
GstVaapiPixmap is an abstract base class which only implementation
were GstVaapiPixmapX11. This class were used for a special type of
rendering in the tests apps, utterly unrelated in GStreamer.
Since gstreamer-vaapi is no longer a general-user wrapper for VA-API
we should remove this unused API.
This removal drops libxrender dependency.
