Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
Using YUY2 as the input of the encoder can generate main 4:2:2 bit
streams and using Y210 as the input of the encoder can generate main
4:2:2 10 bit streams.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/334>
|
|
|
|
|
|
From now on always the baseline is going to be treated as constrained without
need of setting a property.
Since the property was added along the development cycle (1.17 / commit
866a9f06) and never released, we assume that it is safe to remove it.
Fixes: #252
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/328>
|
|
commit 7ac2a207 added a regression by erroneously assumed that
GstVaapiVideoMeta is actually a GstMeta, which is not.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/327>
|
|
So this could hint filters how to use these metas.
Had to change the return value for texutre upload meta in order
to flag it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/326>
|
|
xxx_register_type will detect the template sink caps and is needed
to be called at init time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/315>
|
|
Use gst_vaapi_detect_codec_caps to get more precise template caps.
Also implement gst_vaapiencode_vp9_register_type, which should be
called at plugin register time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/315>
|
|
Use gst_vaapi_detect_codec_caps to get more precise template caps.
Also implement gst_vaapiencode_vp8_register_type, which should be
called at plugin register time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/315>
|
|
Use gst_vaapi_detect_codec_caps to get more precise template caps.
Also implement gst_vaapiencode_mpeg2_register_type, which should be
called at plugin register time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/315>
|
|
Use gst_vaapi_detect_codec_caps to get more precise template caps.
Also implement gst_vaapiencode_h265_register_type, which should be
called at plugin register time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/315>
|
|
Use gst_vaapi_detect_codec_caps to get more precise template caps.
Also implement gst_vaapiencode_h264_register_type, which should be
called at plugin register time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/315>
|
|
Use gst_vaapi_detect_codec_caps to get more precise template caps.
Also implement gst_vaapiencode_jpeg_register_type, which should be
called at plugin register time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/315>
|
|
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/315>
|
|
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>
|
|
Extract all logic about making caps for encode's sink as a standalone
helper function. It can be reused.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/315>
|
|
We store GstVaapiTextureGLX and GstVaapiTextureEGL's private data in
the qdata of miniobject and avoid extending the base texture class.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/317>
|
|
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.
|
|
|
|
Using Y410 as the input of the encoder can generate main_444_10 bit
streams.
|
|
|
|
Since they should only be controlled by caps negotiation.
|
|
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 might generated errors on automatic tools such as CI. Let's
rather just raise a warning and let continue.
|
|
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
|
|
Base class's sink pad caps are already set when calling set_format().
There's no need to call it again in gst_vaapidecode_negotiate().
|
|
If caps update fail a dead lock occurs since the stream mutex is not
unlocked.
|
|
This reverts commit dd428cc4a12c2d5c694fcd3303811cf486002c9d 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.
|
|
If we do not have functional VPP, then cropping and video
direction is non-functional and we should avoid calling
any of the gst_vaapi_filter* APIs.
|
|
If we don't have functional vpp then we should not call
gst_vaapi_filter_set_colorimetry.
|
|
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.
|
|
|
|
Since now they can be handled by vaapipostproc.
|
|
The default output colorimetry is persuaded by the output
resolution, which is too naive when doing VPP cropping
and/or scaling. For example, scaling 4K(sink)->1080P(src)
resolution (i.e. both YUV) results in bt2020(sink)->bt709(src)
colorimetry selection and some drivers don't support that
mode in vpp.
Thus, if output (i.e. downstream) does not specify a
colorimetry then we use the input resolution instead of the
output resolution to create the default colorimetry. Also,
note that we still use the output format since it may be a
different color space than the input. As in the example
above, this will result in bt2020(sink)->bt2020(src)
colorimetry selection and all drivers (afaik) should support
that in vpp.
|
|
We always need a srcpad colorimetry for VAAPI VPP
operations.
Also, check the return value of _set_colorimetry.
|
|
If colorimetry has been set by a capsfilter (e.g.
vaapipostproc ! video/x-raw,colorimetry=bt709) then
don't try to override it. Previously, the aforementioned
capsfilter will fail to negotiate if default colorimetry
is not the same as the capsfilter (e.g. 4K resolutions).
|
|
Set the input and output colorimetry for vpp filter.
|
|
Some code can be optimized since only if the dmabuf allocator is set,
the internal flag of dmabuf is TRUE, thus there's no need to evaluate
the allocator address.
|
|
If the requested allocator in set_config() is not a VAAPI valid one,
reject the configuration, instead of lying and using a private one.
This patch superseeds !254 and !24
|
|
|
|
If the configured meta doesn't request vaapi meta then it is not a
vaapi buffer pool. Bail out as soon as possible.
|
|
set_config() vmethod should fail gracefully, thus upstream could
negotiate another pool if possible.
Instead of sending error messages to the bus, let demote the level
to warning.
|
|
Instead of creating a new allocator when upstream requests a different
allocator, this patch tries to reuse the internal allocator if it was
already initializated.
If the stream changes, then either one will be unref and a new
allocator is created.
|