Performance penalty for GStreamer 1.0 compared to 0.10
Edward Hervey
bilboed at bilboed.com
Mon Dec 30 03:38:01 PST 2013
Hi,
The culprit is videoscale (or rather ORC used by it).
In some cases it attempts to use an ORC instruction (ldreslinb) which
does not have an optimized implementation for mmx or sse. And therefore
goes into a slow path.
Edward
On Sun, 2013-12-29 at 22:27 +0100, Peter Maersk-Moller wrote:
> Hi Andoni.
>
>
> Thanks for the feedback. Not sure what the upstream ppa is though.
>
> Yes my 1.2.2 was first compiled without ORC as the Orc required is
> 0.4.18 and the available version though Ubuntu package system is
> 0.4.17. However I compiled the 0.4.18 version. When configuring the
> gst-plugin-base for version 1.2.2 I now see
>
> configure: *** Orc acceleration enabled.
>
>
> Nevertheless after recompilation and installation, I still see the
> heavy performance penalty. That said, when I remove the format BGRA in
> the caps and subsequently have no format conversion, I see excellent
> performance.
>
>
> That said, why do I see the performance penalty when I believe I run
> the Orc enabled version and how does one go about verifying that it is
> in fact Orc enabled?
>
>
> Another thing is that it is a bit worrisome that plain vanilla Ubuntu
> shows the performance penalty too as it kind of falls back on
> GStreamer whether or not the error is there or in the Ubuntu package
> of GStreamer.
>
>
> Seems time for a bug report. Have to check on how to do that again.
>
>
>
> Kind regards
>
> Peter
>
>
>
>
>
>
>
>
>
>
> On Sun, Dec 29, 2013 at 7:48 PM, Andoni Morales <ylatuya at gmail.com>
> wrote:
>
>
>
> 2013/12/29 Peter Maersk-Moller <pmaersk at gmail.com>
> Hi
>
>
> I'm observing a heavy performance penalty for using
> GStreamer 1.0 (1.2.0, 1.2.1, 1.2.2) over GStreamer
> 0.10 (0.10.36). The penalty is in the area of 3-4
> times as much CPU time consumed for decoding a given
> video clip. Is this a known issue?
>
>
> For reproduction purpose (to generate a common test
> clip), you can use the following pipeline for about 60
> seconds before hitting ctrl-c
>
> 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
>
>
> The two nearly identical pipelines used for testing
> are shown further down in this email. The cpu usage is
> estimated using top. Here is what I see:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM
> TIME+ COMMAND
> 5757 stream 20 0 403m 43m 7272 S 28.6 1.1
> 0:05.76 gst-launch-0.10
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM
> TIME+ COMMAND
> 5763 stream 20 0 1068m 61m 5232 S 85.5 1.6
> 0:07.22 gst-launch-1.0
>
>
> So the 0.10 is using roughly 28.6% CPU while 1.0 is
> using 85.6%
>
>
> The pipelines used for playing the clip are these:
>
> /usr/bin/gst-launch-0.10 -v filesrc
> location=./video1024x576.mp4 do-timestamp=true !
> decodebin2 name=decoder ! ffmpegcolorspace !
> videorate ! 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,
> pixel-aspect-ratio=(fraction)1/1,
> interlaced=(boolean)false, width=(int)1280,
> height=(int)720, framerate=(fraction)25/1' ! queue !
> fakesink silent=true sync=true
>
> /usr/local/bin/gst-launch-1.0 -v filesrc
> location=./video1024x576.mp4 do-timestamp=true !
> decodebin name=decoder ! videoconvert ! videorate !
> videoscale ! videoconvert ! 'video/x-raw,
> format=(string)BGRA, pixel-aspect-ratio=(fraction)1/1,
> interlace-mode=(string)progressive, width=(int)1280,
> height=(int)720, framerate=(fraction)25/1' ! identity
> silent=true ! queue ! fakesink silent=true sync=true
>
>
> I used to be able to easily live decode up to 10 video
> clip concurrent of 720p video on my 8 core server
> while maintaining enough spare CPU to also mix video
> en most importanly, encode video again in 720p. That
> is not really possibly any more with the heavy penalty
> in performance I have to pay.
>
>
>
> It looks like it's caused by the I420->BGRA colorspace
> conversion. You are most likely not building gst-plugins-base
> with ORC support. I was able to reproduce the performance
> issue with the stock version of GStreamer shipped in Ubuntu
> but not with the upstream ppa
> (https://launchpad.net/~gstreamer-developers/+archive/ppa).
>
>
>
> Cheers,
>
> Andoni
>
>
>
>
> Kind regards
>
> Peter Maersk-Moller
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
>
> --
> Andoni Morales Alastruey
>
> LongoMatch:The Digital Coach
> http://www.longomatch.ylatuya.es
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
--
Edward Hervey
bilboed at bilboed.com
More information about the gstreamer-devel
mailing list