If the pad is already fixed the caps query have to be reply with the
current fixed caps. Otherwise the query has to be replied with the
autogeneratd src caps.
This path fix this by falling back to the normal caps query processing
if the pad is already fixed. Otherwise it will fetch the allowed src
pad caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/397>
The try-and-error approach for getting the possible image formats from
a surface has brought several problems in different drivers, from
crashes to drop in performance.
Instead of that we change the algorithm to determine the possible
image formats based in the surface chroma: only those available image
formats with same chroma are exposed as possible raw caps.
Do this is important to avoid performance degrading in raw sinks
which doesn't handle NV12 but it does YV12 or I420.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/381>
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>
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>
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>
When baseline-as-constrained is set, the decoder will expose support
for baseline decoding and assume that the baseline content is
constrained-baseline. This can be handy to decode streams in hardware
that would otherwise not be possible to decode. A lot of baseline
content is in fact constrained.
We do not need to maintain a standalone list of decoder's output
template for raw formats and that is easy to make mistake(for
example, the AYVU is wrong in that list, should be VUYA).
Just use GST_VAAPI_FORMATS_ALL to replace the raw formats list for
src template.
When the code path goes to push buffers downstream when no surface
available in decoder context, and it fails the code bails out with a
fatal error.
That behavior is wrong, since it shouldn't be fatal. The use case is
when the video stream is disabled.
This patch just ignores the errors in this situation and demotes the
level of a log message.
For surfaces with different chroma type, it is prefer to initialize
a format which chroma type should be same with surface chroma type
instead of using fixed NV12.
When create vaapi surface, it is better to use the chroma type get
from jpeg file instead of using fixed 420 format. And the correct
chroma type can be determined by horizontal_factor/vertical_factor
flags that get from jpegparse.
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.
https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/123
Signed-off-by: He Junyan <junyan.he@hotmail.com>
Add 444 10bit yuv format Y410, which can be used to decode
main-444 10bit streams. Currently, this feature is only
supported by media-driver in Icelake.
Add 422 10bit yuv format Y210, which can be used to decode
main-10-422 10bit streams. Currently, this feature is only
supported by media-driver in Icelake.
https://bugzilla.gnome.org/show_bug.cgi?id=797264
If the unit could not be parsed, just skip this nal and keep parsing
what is left in the adapter. We need to flush the broken unit in the
decoder specific parser because the generic code does not know about
units boundary. This increases error resilliance.
Before this, the broken unit would stay in the adapter and EOS would be
returned. Which stopped the streaming. Just removing the EOS would have
lead to the adapter size growing indefinitely.
https://bugzilla.gnome.org/show_bug.cgi?id=796863
Generate system allocated output buffers when downstream doesn't
support GstVideoMeta.
The VA buffer content is copied to the new output buffer, and it
replaces the VA buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=785054
When vaapih264dec's base-only profile is set to TRUE, fake SVC profile
support in caps.
https://bugzilla.gnome.org/show_bug.cgi?id=732266
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
