Performance penalty for GStreamer 1.0 compared to 0.10

Tue Jan 7 05:17:54 PST 2014

Hi Sebastian.

The bug report for performance penalty for videoconvert and videoscale for
version 1.2.0-1.2.2 over 0.10.36 has been created as bug 721701 with link
https://bugzilla.gnome.org/show_bug.cgi?id=721701

Please note that both videoscale and videoconvert appear to have the bug
both with out-of-the-box ubuntu as well as my own  build 1.2.2 where Orc
"is enabled".

Platform is a dual Xeon with 4 cores each, so not an exotic hardware.

Below is the text from the bug report detailing how to see the penalty.

Best regards
Peter Maersk-Moller

----------------
It appear that version 1.2.0-1.2.2 and perhaps previous versions introduce
a dramatic performance penalty for video scaling and video format
conversion of I420 to BGRA when compared to version 0.10.36. This
performance penalty is present for common Ubuntu installations ranging from
12.04 until 13.10 as well as with a newly build version of GStreamer 1.2.2
with orc-0.4.18. It is checked that Orc is enabled when building
gst-plugins-base.

The following examples are all executed on Ubuntu 13.10 with GStreamer
1.2.2 for version 1.0 and GStreamer 0.10.36 for version 0.10. The system is
a dual Xeon Quad core configuration with a total of 8 cores.

First we create two test samples of 60 seconds each (just hit ctrl-c after
running 60 seconds:

  $ gst-launch-1.0 -e -v videotestsrc pattern=18 is-live=true !
'video/x-raw, width=1024, height=576, format=I420' ! videoconvert ! x264enc
! 'video/x-h264, profile=main' ! avimux ! filesink
location=video1024x576.mp4

  $ gst-launch-1.0 -e -v videotestsrc pattern=18 is-live=true !
'video/x-raw, width=1280, height=720, format=I420' ! videoconvert ! x264enc
! 'video/x-h264, profile=main' ! avimux ! filesink
location=video1280x720.mp4

Now we start top in another window to check cpu load and try decode and
convert the latter file with 0.10 and 1.0

  $ /usr/bin/gst-launch-0.10 -v filesrc location=./video1280x720.mp4
do-timestamp=true ! decodebin2 name=decoder ! ffmpegcolorspace !
'video/x-raw-rgb, bpp=(int)32, depth=(int)32, endianness=(int)4321,
red_mask=(int)65280, green_mask=(int)16711680, blue_mask=(int)-16777216,
width=(int)1280, height=(int)720' ! queue ! fakesink silent=true sync=true

and

  $ /usr/local/bin/gst-launch-1.0 -v filesrc location=./video1280x720.mp4
do-timestamp=true ! decodebin name=decoder ! videoconvert ! 'video/x-raw,
format=(string)BGRA, width=(int)1280, height=(int)720' ! queue ! fakesink
silent=true sync=true

On my system, the 0.10 version will happily run at roughly 24-25 % CPU load
while the 1.0 version runs at roughly 51%

Now we add videoscaling by using the first file we created and scale it
before converting it:

  $ /usr/bin/gst-launch-0.10 -v filesrc location=./video1024x576.mp4
do-timestamp=true ! decodebin2 name=decoder ! videoscale ! ffmpegcolorspace
! 'video/x-raw-rgb, bpp=(int)32, depth=(int)32, endianness=(int)4321,
red_mask=(int)65280, green_mask=(int)16711680, blue_mask=(int)-16777216,
width=(int)1280, height=(int)720' ! queue ! fakesink silent=true sync=true

and

  $ /usr/local/bin/gst-launch-1.0 -v filesrc location=./video1024x576.mp4
do-timestamp=true ! decodebin name=decoder ! videoscale ! videoconvert !
'video/x-raw, format=(string)BGRA, width=(int)1280, height=(int)720' !
queue ! fakesink silent=true sync=true

On my system, the 0.10 version will happily run at roughly 33-34 % CPU load
while the 1.0 version runs at roughly 101%

Here is what I see when building the plugin base:

configure: *** Plug-ins without external dependencies that will be built:
    adder
    app
    audioconvert
    audiorate
    audioresample
    audiotestsrc
    encoding
    gio
    playback
    subparse
    tcp
    typefind
    videoconvert
    videorate
    videoscale
    videotestsrc
    volume

configure: *** Plug-ins without external dependencies that will NOT be
built:

configure: *** Plug-ins that have NOT been ported:

configure: *** Plug-ins with dependencies that will be built:
    alsa
    cdparanoia
    ivorbisdec
    libvisual
    ogg
    pango
    theora
    vorbis
    ximagesink
    xvimagesink

configure: *** Plug-ins with dependencies that will NOT be built:

configure: *** Orc acceleration enabled.

So I assume Orc acceleration for video scale and videoconvert is enabled.

On Fri, Jan 3, 2014 at 9:24 AM, Sebastian Dröge
<sebastian at centricular.com>wrote:

> On Fr, 2014-01-03 at 01:46 +0100, Peter Maersk-Moller wrote:
> > Hi Edward.
> >
> > Do you have more information on when GStreamer (Orc) specific is using
> the
> > slow path?
> > GStreamer 0.10 was doing it fast, but in my case 1.2 does it slow doing a
> > simply I420 1024x576 to 1280x720 followed by a I420 to BGRA conversion?
> >
> > Should we/I create a bug report for it? I think so as main stream Ubuntu
> > runs with the performance penalty. In this context and given
> implementation
> > for mmx/sse is missing as reported by Edwrad I don't quite see why Andoni
> > could not reproduce it with the version he linked to.
>
> Yes, please create a bug for this. Make sure to mention exactly which
> video format conversions are happening and which elements are all
> involved.
>
> At least for videoconvert we should add some more fast-paths for common
> conversions.
>
> > Sebastian D. in your fix for I420 to BGRA conversion I think you wrote it
> > was only a partial implementation. What is missing there?
>
> Which one? The broken I420->BGRA conversion is completely fixed now, but
> the high-quality version of it is disabled now because it currently
> can't be implemented with orc properly.
>
> --
> Sebastian Dröge, Centricular Ltd - http://www.centricular.com
> Expertise, Straight from the Source
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140107/853352f9/attachment-0001.html>