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.
That test case only works with drm display, so the build such as
meson -Dwith_x11=yes -Dwith_wayland=no -Dwith_drm=no -Dwith_egl=no
-Dwith_glx=no
gets a failure when run ninja test. Just enable this test when drm
is enabled.
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
If the dependent_slice_segment_flag is true, most slice info derived from last slice.
So we need check the slice type after we call populate_dependent_slice_hdr
Since commit 32bf6f1e GLTextureUpload is broken because i965
doesn't report properly RGBA support. It could be possible to use RGBx
but GLTextureUpload only regotiates RGBA.
The simplest fix to this regression is adding synthetically the RGBA
format in the internal format map.
Instead of break at the fist foud quirk in the table, iterate all over
so it would be feasible to add several quirks for one driver per
element in array.
The intel-media-driver (iHD) can't convert output color
primaries when doing YUV to/from RGB CSC. Thus, we must
keep the output color primaries the same as the input
color primaries for this case.
fixes#238
This reverts commit dd428cc4a1 because
it rewrites the buffer size whilst surface allocation flags are
stored when allocator_params_init() is called since fab890ce.
Fix: #239
When a vaapi allocator is instantiated, it first try to generate a
surface with the specified configuration.
This patch adds, in this tried buffer, the requested allocation flags.
Store surface allocation flags passed to the vaapi allocator in
GObject's qdata, because it might be used by the vaapivideobufferpool
when recreating the allocator given any resolution change.
When creating surfaces it is possible to pass to VA hints of its usage,
so the driver may do some optimizations.
This commit adds the handling of encoding/decoding hints.
In fact, gst_vaapi_create_test_display only test x11, wayland and
drm, no glx and egl entries. So if none of them is enabled, no
vaapi element can be detected.
The bug fixing, in commit 89f202ea, just considers the case when
surface's DMABuf is set through gst_buffer_pool_acquire_buffer(),
which is typically a decoder's behavior. But vaapipostproc doesn't
provide any surface when calling gst_buffer_pool_acquire_buffer(),
thus a surface is created when GstMemory is allocated.
If the surface proxy in buffer's meta is reset at
buffer_pool_reset_buffer(), that surface will be destroyed and it
won't be available anymore. But GstBuffers are cached in the buffer
pool and they are reused again, hence only those images are rendered
repeatedly.
Fixes: #232
I've just discovered iHD driver in Skylake doesn't have VideoProc
entry point, hence, in this platform, when vaapioverlay is tried to be
registered, critical warnings are raised because blend doesn't have a
display assigned.
As it is possible to have drivers without EntryPointVideoProc it is
required to handle it gracefully. This patch does that: only tries to
register vaapioverlay if the testing display has VPP and finalize()
vmethods, in filter and blend, bail out if display is NULL.
