Some context does not report any valid format that we can support.
For example, the HEVC 444 12 bits decoder context, all the formats
it reports is not supported now, which make the formats list a NULL
array. We should check that pointer before we use it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/372>
In h265, bigger profile idc may not be compatible with the small profile
idc. And more important, there are multi profiles with the same profile
idc. Such as main-422-10, main-444 and main-444-10, they all have profile
idc 4.
So recording the max profile idc is not enough, the encoder needs to know
all allowed profiles when deciding the real profile.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/349>
In h265, higher profile idc number does not mean better compression
performance and may be not compatible with the lower profile idc.
So, it is not suitable to find the heighest idc for hw to ensure the
compatibility.
On the other side, when the entrypoint of the selected profile is valid,
it means the hw really support this profile, no need to check it again.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/349>
Instead of generating allowed srcpad caps with generic information,
now it takes the size an formats limits from the decoder's context.
This is possible since srcpad caps are generated after the internal
decoder is created.
The patch replaces gst_vaapi_decoder_get_surface_formats() with
gst_vaapi_decoder_get_suface_attributes().
From these attributes, formats are only used for VASurface memory
caps feature. For system memory caps feature, the old
gst_vaapi_plugin_get_allowed_srcpad_caps() is still used, since
i965 jpeg decoder cannot deliver mappable format for gstreamer.
And for the other caps features (dmabuf and texture upload) the
same static list are used.
This patch also adds DMABuf caps feature only if the context
supports that memory type. Nonetheless, we keep the pre-defined
formats since they are the subset of common derive formats formats
supported either by amd/gallium and both intel drivers, since,
when exporting the fd through vaAcquireBufferHandle()/
vaReleaseBufferHandle(), the formats of the derivable image cannot
be retriebable from the driver. Later we'll use the attribute
formats for the DMABuf feature too, when the code be ported to
vaExportSurfaceHandle().
Finally, the allowed srcpad caps are removed if the internal decoder
is destroyed, since context attribues will change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/366>
Since negotiation depends on caps order, first is VA, then DMABuf,
later GLUploadTexture (deprecated) and finally raw.
Also, for decoders, the possible available color formats for DMABuf
is extended to all the possible VA color formats.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/366>
Currently vaGetSurfaceBufferWl() is used to create wayland buffers.
Unfortunately this is not implemented by the 'media-driver' and Mesa VA-API
drivers. And the implementation provided by 'intel-vaapi-driver' is not
compatible with a Wayland server that uses the iris Mesa driver.
So create the Wayland buffers manually with the zwp_linux_dmabuf_v1 wayland
protocol. Formats and modifiers supported by the Wayland server are taken
into account. If necessary, VPP is enabled to convert the buffer into a
supported format.
Fall back to vaGetSurfaceBufferWl() if creating buffers via dambuf protocol
fails.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/346>
Committing the first buffer for a surface must not be done before
ack_configure() has been sent for the xdg_surface.
With weston, the commit will fail with "error 3: xdg_surface has never been
configured".
Wait in gst_vaapi_window_wayland_show() until configure is done to avoid
this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/346>
The double reference lists may be required by drivers and there should
be no P frames in the of stream. The old way of converting P frames to
B frames is by setting `low-delay-b` property, which is unconvenient
and has bad user experience, since most of the users do not know when
to set this property, and if it is not set correctly, the encoding
pipeline fails or even hangs on some platforms. VA driver now provides
a attribute to query whether both reference lists must be un-NULL for
a profile/entrypoint pair.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/284>
In HEVC, P and B definitions are different from AVC: P frames have
just one reference list and so 1 MV, while B frames have two reference
lists and so 2 MVs. No matter B or P, ist reference lists can contain
forward/backward reference. So P and B can both have bi-directions
dependency, the difference is just their reference list
number (i.e. MV number). This is different from the AVC.
The *low delay b mode* refers to a special HEVC mode, in which the
stream just contain I and B frames, without P frames, and all B frames
only have forward direction dependencies (i.e. all inter frames have 2
reference lists but no backward reference in both lists). This is
similar to AVC I/P mode, but changing the P to the forward dependent
B.
The `low-delay-b` property is now just used to simply convert all P
frames to B frames when driver does not support P frames (so both
reference lists have the same references frames). This is a little
different from the meaning of low delay b mode (the two ref lists may
have the different reference frames). And the driver now can report
whether it supports P frames correctly, so there is no need to use
this property and deprecate it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/284>
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>
