Like build_template_raw_caps_by_codec(), this function can detect and
build the caps for specified codec based on the query of the profiles.
The result is coded caps such as video/x-h265, video/x-h264. The result
can be used as the template of encode's src or decode's sink.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/354>
The synthetic profiles, such as H264 baseline, H265 intra, etc. are
added at the end of processing all available VA profiles. This
generated an non-optimal caps for negotiation, since the synthetic
profiles don't have frame size ranges.
This patch adds those possible synthetic profiles when the associated
profile is processed, with its frame size ranges.
Now allowed sink caps are simpler.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/363>
Instead of using dmabuf allocator in source pad, when raw video caps
are negotiated, it uses VA allocator as before, since it is stable
in more use cases, for example transcoding, and more backend drivers.
Dmabuf allocator is only used when dmabuf caps feature is negotiated.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/352>
iHD doesn't provide a full implemention for rendering surfaces and
i965 has problems in wayland. And I suspect this path is followed
by other driver implementations.
This patch demotes the rank of vaapisink to secondary, so it will
not be autoplugged avoiding bad experience of users.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/336>
When the element's state changes to NULL, it can still receive
queries, such as the image formats. The display is needed in such
queries but not well protected for MT safe.
For example, ensure_allowed_raw_caps() may still use the display
while it is disposed by gst_vaapi_plugin_base_close() because of
the state change.
We can keep the display until the element is destroyed. When the
state changes to NULL, and then changes to PAUSED again, the display
can be correctly set(if type changes), or leave untouched.
Fix: #260
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/343>
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>
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.
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>
The strides and offsets could be the same, but the allocation
size might be different (e.g. alignment). Thus, ensure we also
set the flag to copy from VA memory to system memory when alloc
size differs.
Fixes#243
