Performance penalty for GStreamer 1.0 compared to 0.10
Peter Maersk-Moller
pmaersk at gmail.com
Thu Jan 2 16:46:48 PST 2014
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.
Sebastian D. in your fix for I420 to BGRA conversion I think you wrote it
was only a partial implementation. What is missing there?
Kind regards
Peter Maersk-Moller
On Mon, Dec 30, 2013 at 12:38 PM, Edward Hervey <bilboed at bilboed.com> wrote:
> 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
>
> _______________________________________________
> 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/20140103/cdc76d72/attachment.html>
More information about the gstreamer-devel
mailing list