The gst_vaapi_plugin_base_get_allowed_raw_caps is used for both sink
pad and src pad, which cause some bugs. For sink pad, we need to verify
vaPutImage() while for the src pad we need to verify vaGetImage().
For vaapidecoderXXX kind of plugins, the case is more complex. We need
to verify whether the decoded result(in some surface, NV12 format most
of the time) can be vaGetImage to some raw image format. Add more check
to fix all these problems.
Fixes: #123
Signed-off-by: He Junyan's avatarHe Junyan <email address hidden>
6901324...
by
Jordan Petridis <email address hidden>
Run gst-indent through the files
This is required before we enabled an indent test in the CI.
Since gst_vaapi_find_preferred_caps_feature() returns a color format
from caps negotiation, different from the default one (NV12), the
postproc enables the color transformation. But when GL_TEXTURE_UPLOAD
feature is negotiated, no color transformation shall be done.
Nonetheless, with commit 3e992d8a the requested format changes
firstly, because there's no video sink yet, so ANY caps are
negotiated; but later, when there's a video sink and a caps
renegotiation, the GL_TEXTURE_UPLOAD is negotiated though the color
format conversion still ongoing. It is required to reset that
conversion.
This patch force default color format when GL_TEXTURE_UPLOAD is
selected as preferred, thus avoiding the color conversion.
libs: encoder: not call ensure_num_slices inside g_assert
g_assert will take no effect when glib's G_DISABLE_ASSERT macro is
defined. The function inside the g_assert will take no effect and
we will fail to set the correct slice number.
plugin: if any caps in downstream, negotiate raw video
When downstream has any caps, vaapi should not shovel vaapi featured
buffers, but rather plain raw video, assuming always the worst case
scenario (downstream cannot handle featured video memory but raw
system memory buffers).
This patch query the peer caps without any filter, to know if
donwstream just ask for any caps, if so jump to the color space
checking, otherwise do the caps intersection and continue with the
feature selection algorithm.
This code is just confused. It's asking for at least as many bits of
(z-axis) depth as the root window has bits of (color) depth. For rgb565
or rgb888 this is harmless, but at 10 bits per channel this demands a
30-bit or deeper Z buffer. While some hardware could in principle do a
32-bit Z buffer, Mesa does not expose such fbconfigs (at least on Intel
and AMD).
We're not actually using the Z buffer, so just stop asking for one.
vaapipostproc: before set surface proxy, check if it already been created and exist.
Fix the deinterlace black frame when playing with glimagesink:
gst-launch-1.0 filesrc location=test.264 ! h264parse ! vaapih264dec \
! vaapipostproc deinterlace-mode=1 deinterlace-method=1 ! glimagesink
