Efficiently change color space for vaapih264enc

[Víctor Jáquez]

On Wed, 23 Oct 2019 at 04:40, ambyjkl wrote:
> Hi everyone, I have a pipeline where I want to record the screen into an h264
> stream using vaapi. Here is what I'm doing at the moment
> 
> gst-launch-1.0 \
> ximagesrc use-damage=false \
> ! queue \
> ! videorate ! video/x-raw,framerate=2993/100 \
> ! glupload ! glcolorconvert ! gldownload
> ! video/x-raw,format=I420,framerate=2993/100 \
> ! vaapih264enc \
> ! fakesink
> 
> As you can see I'm trying to utilize the gpu as much as possible. Since
> vaapi caps expect the video to be one of a few supported color channels, I'm
> having to convert color spaces. But the sad part is, on my setup, the
> glcolorconvert part is using more than double the CPU of everything else
> combined! This is because of the extra copying overhead of glupload !
> glcolorconvert ! gldownload, which copies into a gl buffer and back.
> However, this still seems to be faster than a CPU driven videoconvert in my
> case.
> 
> Since the final destination is vaapi anyway which is on the GPU, is there a
> way to optimize the pipeline by avoiding the gldownload and have vaapi work
> directly on the gl buffer? If not, is there something like vaapipostproc
> that would let vaapi manage the color space conversion itself *before* the
> encoding?

Have you tried vaapipostproc for that color conversion?

vmjl