Efficiently change color space for vaapih264enc

[ambyjkl]

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?

Thanks :)



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Victor Jaquez]

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
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[ambyjkl]

Hey vmij
That worked! I did try it before, but at that time, possibly due to some
other mistake in my pipeline, vaapipostproc didn't satisfy the caps on both
sides. That lead me into believing it's only for "post"
processing.Misleading name indeed.

Also, there is another question I wanted to ask you, and that is how
ximagesrc works in the scenario. Is there some copying involved there as
well, or does it just copy memory references? Does vaapi manage to keep it
in the GPU? It would be for the best to avoid any and all CPU overhead as
much as possible.

Thanks



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mer. 23 oct. 2019 11 h 55, ambyjkl <[hidden email]> a écrit :

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.

Please consider using vaapipostproc

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?

Thanks :)



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel