Color space conversion CPU utilization

[asp]

Hi,

I'm running into a problem, where a simple color space conversion seems
to be consuming a non-trivial amount of CPU. Consider the following
pipeline (ran on 1080p source):

gst-launch-1.0 -e rtspsrc
location=rtsp://user:pwd@10.10.10.54/video.h264 ! decodebin ! x264enc
threads=6 speed-preset=1 ! video/x-h264, profile=baseline ! splitmuxsink
max-size-time=15000000000 location=file-%03d.mp4


This pipeline runs at 66% CPU. Now, when I change it to

gst-launch-1.0 -e rtspsrc
location=rtsp://user:pwd@10.10.10.54/video.h264 ! decodebin !
videoconvert ! "video/x-raw, format=BGRA" ! videoconvert ! "video/x-raw,
format=I420" ! x264enc threads=6 speed-preset=1 ! video/x-h264,
profile=baseline ! splitmuxsink max-size-time=15000000000
location=file-%03d.mp4

the CPU utilization nearly doubles (to slightly over 120%).

Is there a way to optimize it? My current (non-gstreamer) code is using
ffmpeg's swscale to convert color space, and the effect of that
conversion on overall performance is quite negligible.

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

[Sebastian Dröge-3]

On Do, 2016-03-24 at 21:05 -0400, Alex wrote:

> Hi,
>
> I'm running into a problem, where a simple color space conversion seems 
> to be consuming a non-trivial amount of CPU. Consider the following 
> pipeline (ran on 1080p source):
>
> gst-launch-1.0 -e rtspsrc 
> location=rtsp://user:pwd@10.10.10.54/video.h264 ! decodebin ! x264enc 
> threads=6 speed-preset=1 ! video/x-h264, profile=baseline ! splitmuxsink 
> max-size-time=15000000000 location=file-%03d.mp4
>
>
> This pipeline runs at 66% CPU. Now, when I change it to
>
> gst-launch-1.0 -e rtspsrc 
> location=rtsp://user:pwd@10.10.10.54/video.h264 ! decodebin ! 
> videoconvert ! "video/x-raw, format=BGRA" ! videoconvert ! "video/x-raw, 
> format=I420" ! x264enc threads=6 speed-preset=1 ! video/x-h264, 
> profile=baseline ! splitmuxsink max-size-time=15000000000 
> location=file-%03d.mp4
>
> the CPU utilization nearly doubles (to slightly over 120%).
>
> Is there a way to optimize it? My current (non-gstreamer) code is using 
> ffmpeg's swscale to convert color space, and the effect of that 
> conversion on overall performance is quite negligible.

Why do you want to convert to BGRA just to convert back to I420? What
is the actual pipeline you want to get running?

Colorspace conversion in the CPU, and especially for high
resolutions/framerates, is a quite expensive task. Depending on which
formats you convert from and to. Once you know the actual formats
you'll have to convert between, we could add fast-paths for them (if
not existing yet) or optimize the conversion. If ffmpeg can do the same
conversion faster, we should be able to find a way to optimize ours
too.

But in any case, it would be good to know between which formats you
really need to convert in your real pipeline :) And that also includes
the format that comes out of decodebin for your media.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

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

[asp]

Sebastian, thanks for the response!

The pipelines above are just to illustrate the situation -- in the actual pipeline there's a filter which only supports RGBA/BGRA. So, the conversion taking place is from YUV420P to BGRA and back.

Coming from ffmpeg-backed implementation, this conversion was not, obviously, free -- but wasn't as expensive either. Unfortunately I don't have 0.10 built with x264enc handy to compare, but I'd imagine ffmpegcolorspace would be close(r) to what we used to have. I may end up trying to build it as an external filter for 1.0 and see how it compares.

Again, thanks for your thoughts, and let me know if you have any other ideas.

[Sebastian Dröge-3]

On Fr, 2016-03-25 at 07:00 -0700, asp wrote:

> Sebastian, thanks for the response!
>
> The pipelines above are just to illustrate the situation -- in the actual
> pipeline there's a filter which only supports RGBA/BGRA. So, the conversion
> taking place is from YUV420P to BGRA and back.
>
> Coming from ffmpeg-backed implementation, this conversion was not,
> obviously, free -- but wasn't as expensive either. Unfortunately I don't
> have 0.10 built with x264enc handy to compare, but I'd imagine
> ffmpegcolorspace would be close(r) to what we used to have. I may end up
> trying to build it as an external filter for 1.0 and see how it compares.

ffmpegcolorspace is not based on swscale and usually much slower than
both videoconvert and swscale. Ok, so the conversion you need to have
faster is I420 to BGRA (or RGBA? which one?) and back?

Can you file a bug about that? If there are no fast paths for that yet,
we should add them. And possibly also assembly implementations if they
don't exist yet.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


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

[asp]

Thanks -- done: https://bugzilla.gnome.org/show_bug.cgi?id=764201