There are, right now, three new GstVA elements merged in
Just to recap, GstVA is a GStreamer plugin in
gst-plugins-bad (yes, we agree it’s not a great name anymore), to differentiate it from
gstreamer-vaapi. Both plugins use libva to access stateless video processing operations; the main difference is, precisely, how stream’s state is handled: while GstVA uses GStreamer libraries shared by other hardware accelerated plugins (such as
gstreamer-vaapi uses an internal, tightly coupled and convoluted library.
Also, note that right now (release 1.20) GstVA elements are ranked NONE, while
gstreamer-vaapi ones are mostly PRIMARY+1.
Back to the three new elements in GstVA, the most complex one is
vah264enc wrote almost completely by He Junyan, from Intel. For it, He had to write a H.264 bitwriter which is, until certain extend, the opposite for H.264 parser: construct the bitstream buffer from H.264 structures such as PPS, SPS, slice header, etc. This API is part of
libgstcodecparsers, ready to be reused by other plugins or applications. Currently
vah264enc is fairly complete and functional, dealing with profiles and rate controls, among other parameters. It still have rough spots, but we’re working on them. But He Junyan is restless and he already has in the pipeline an encoder common class along with a HEVC and AV1 encoders.
The second element is
vacompositor, wrote by Artie Eoff. It’s the replacement of
gstreamer-vaapi. The suffix
compositor is preferred to follow the name of primary video mixing (software-based) element:
compositor, successor of
videomixer. See this discussion for further details. The purpose of this element is to compose a single video stream from multiple video streams. It works with Intel’s media-driver supporting alpha channel, and also works with AMD Mesa Gallium, but without alpha channel (in other words, a custom degree of transparency).
The last, but not the least, element is
vajpegdec, which I worked on. The main issue was not the decoder itself, but
jpegparse, which didn’t signal the image caps required for the hardware accelerated decoders. For instance, VA only decodes images with SOF marker 0 (Baseline DCT). It wasn’t needed before because the main and only consumer of the parser is
jpegdec which deals with any type of JPEG image. Long story short, we revamped
jpegparse and now it signals sof marker, color space (YUV, RGB, etc.) and chroma subsampling (if it has YUV color space), along with comments and EXIF-like metadata as pipeline’s tags. Thus
vajpegdec will expose in caps template the supported color space and chroma subsampling supported by the driver. For example, Intel supports (more or less) RGB color space, while AMD Mesa Gallium don’t.
And that’s all for now. Thanks.