Apparently mesa 22.3.0 has updated the egl headers, and eglplatform.h now
contains commit
3670d645f4
after which xlib headers don't get included by default anymore but are
dependent upon whether USE_X11 was defined.
This breaks headless builds of gstreamer-vaapi because we always define
an internal define USE_X11 as either 1 or 0.
Change these defines to GST_VAAPI_USE_XYZ instead to avoid this.
Fixes#1634
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3555>
Attribute's value should use returned value from get_attribute for
VAConfigAttribRTFormat, since VAProfileHEVCMain10, in AMD Mesa Gallium,
can process either VA_RT_FORMAT_420 and VA_RT_FORMAT_420_10, which isn't
considered in gstreamer-vaapi design, where encoder's src pads will
expose only 4:2:0 color formats but no 4:2:0 10bit. So, this is a workaround
for this issue while new vah265enc is released.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3397>
Starting with Meson 0.62, meson automatically populates the variables
list in the pkgconfig file if you reference builtin directories in the
pkgconfig file (whether via a custom pkgconfig variable or elsewhere).
We need this, because ${prefix}/libexec is a hard-coded value which is
incorrect on, for example, Debian.
Bump requirement to 0.62, and remove version compares that retained
support for older Meson versions.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1245
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3061>
Nouveau driver currently only exposes postproc entry. But
vaapidecodebin is registered independent if there are decoders or not,
exposing a segmentation fault.
This patch removes the encoder/decoder/codec arrays if no entries are
found, and if no decoders are found vaapidecodebin is not
registered. Also for vaapipostproc if no postproc entry is found.
Also, if general decoder, used by vaapidecodebin, doesn't have a sink
pad string, don't register the glib type.
Fixes: #1349
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2865>
They are part of gst_dep already and we have to make sure to always have
gst_dep. The order in dependencies matters, because it is also the order
in which Meson will set -I args. We want gstreamer's config.h to take
precedence over glib's private config.h when it's a subproject.
While at it, remove useless fallback args for gmodule/gio dependencies,
only gstreamer core needs it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2031>
Showing existing keyframe have special meaning in AV1. All the references
frame will be refreshed with the original keyframe information. The refresh
process (7.20) is implemented by saving data from the frame_header into the
state. To fix this special case, load all the relevant information into the
frame_header.
As there is nothing happening in between this and the loading of the key-frame
into the state, this patch also remove the separate API function, using it
internally instead.
Fixes#1090
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1971>
According to va_dec_hevc.h, pic_param->st_rps_bits should be set
for accelorater to skip parsing the *short_term_ref_pic_set
(num_short_term_ref_pic_sets) structure.
Also modified fill_picture to get parser info as a parameter,
in order to get slide_hdr->short_term_ref_pic_set_size.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1886>
Often, users will need to scale inputs (e.g.
with vaapipostproc) before they are submitted
to the vaapioverlay. However, this results in
multiple VPP passes/operations in the pipeline
which creates unnecessary process overhead.
This change allows for inputs to be submitted
at original scale to vaapioverlay with per-sinkpad
scale dimensions specified so they can be scaled
and blended/composited in a single VPP pass/operation
to avoid the unnecessary process overhead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1380>
Don't set VAAPI vpp blend flags if alpha == 1.0,
i.e. fully opaque. This can avoid extra processing
overhead on some drivers that apply blending
unconditionally when flags are present, even if the
end result is the same without blend flags (i.e. all
opaque alpha channels).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1380>
Platform wise, is not possible, as far as I known, to have Wayland
without kernel's DRM. Though, it's possible to configure
gstreamer-vaapi without DRM but Wayland support, with the enhanced
handling of dmabuf in vaapisink for Wayland, vaapisink will always
fail. Given both issues, configuration with no DRM but Wayland, makes
things more complex, and a simpler approach is to refuse that
configuration.
This patch disables Wayland support if there isn't DRM support. Also,
it disables the display test for Wayland, relying only on DRM and
X11.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1606>
Formats map is instantiated at the end of the display
instantiation. The problem is the Wayland display which looks for a
format in a callback, before the map is populated.
If user compiles gstreamer-vaapi with DRM support, the map is
populated with a DRM display at GStreamer plugin registration. But if
not, or a VA driver is not available, the plugin will try with a
Wayland driver, which cause the NULL de-reference.
Nevertheless, in the case of no DRM support, and if the Wayland
display doesn't get a reply from the format conversion is not a
problem.
So the solution is the trivial one, check if the format map is already
populated before de-reference it.
Fixes: #977
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1606>
