Pipeline performance problems
Locked
 
|
Greetings,
I have some serious problems with gst pipelines. Originally it was a python application and I thought the problem is with the my application, but it turns out the problem is with gstreamer or at least with my pipeline. Here's the pipeline: $ time gst-launch -e videotestsrc pattern=snow num-buffers=250 ! \ video/x-raw-yuv,width=640,height=480,framerate=25/1 ! \ ffmpegcolorspace ! queue ! vp8enc ! queue ! webmmux ! filesink \ location="test.webm" Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Redistribute latency... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 145388989110 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... real 2m25.609s user 2m26.189s sys 0m0.136s It takes over two minutes for this pipeline to complete which is rather strange. If I use xvimagesink instead of filesink, then it takes a wee bit over 10 seconds to complete. As expected. So, what am I doing wrong? I tried with various settings for vp8enc and webmmux, I tried different queue placement and the result is always more or less the same. If I press CTRL-C after some time, waiting for EOS is displayed for quite some time and the video is only a second or two long. If resolution is increased, then everything takes much much longer. I am running this on quad i5 with 4GB of RAM and there is almost no disk activity during recording. Kernel, OS and Gstreamer versions below: Linux pond 3.2.0-19-generic #30-Ubuntu SMP Fri Mar 16 16:27:15 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Ubuntu Precise Pangolin 12.04 gst-launch-0.10 version 0.10.36 GStreamer 0.10.36 https://launchpad.net/distros/ubuntu/+source/gstreamer0.10 Plugin Details: Name: vp8 Description: VP8 plugin Filename: /usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstvp8.so Version: 0.10.22.3 License: LGPL Source module: gst-plugins-bad Source release date: 2012-02-09 14:42 (UTC) Plugin Details: Name: matroska Description: Matroska and WebM stream handling Filename: /usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstmatroska.so Version: 0.10.31 License: LGPL Source module: gst-plugins-good Source release date: 2012-02-20 _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Pipeline performance problems
|
|
On 03/22/2012 11:37 AM, David Klasinc wrote:
> Greetings, > > I have some serious problems with gst pipelines. Originally it was a > python application and I thought the problem is with the my > application, but it turns out the problem is with gstreamer or at > least with my pipeline. > > Here's the pipeline: > > $ time gst-launch -e videotestsrc pattern=snow num-buffers=250 ! \ > video/x-raw-yuv,width=640,height=480,framerate=25/1 ! \ > ffmpegcolorspace ! queue ! vp8enc ! queue ! webmmux ! filesink \ > location="test.webm" > > Setting pipeline to PAUSED ... > Pipeline is PREROLLING ... > Redistribute latency... > Pipeline is PREROLLED ... > Setting pipeline to PLAYING ... > New clock: GstSystemClock > Got EOS from element "pipeline0". > Execution ended after 145388989110 ns. > Setting pipeline to PAUSED ... > Setting pipeline to READY ... > Setting pipeline to NULL ... > Freeing pipeline ... > > real 2m25.609s > user 2m26.189s > sys 0m0.136s > > It takes over two minutes for this pipeline to complete which is > rather strange. If I use xvimagesink instead of filesink, then it > takes a wee bit over 10 seconds to complete. As expected. pipeline lokks like. Is it gst-launch -e videotestsrc pattern=snow num-buffers=250 ! \ video/x-raw-yuv,width=640,height=480,framerate=25/1 ! \ ffmpegcolorspace ! queue ! xvimagesink -- or -- gst-launch -e videotestsrc pattern=snow num-buffers=250 ! \ video/x-raw-yuv,width=640,height=480,framerate=25/1 ! \ ffmpegcolorspace ! queue ! vp8enc ! queue ! webmmux ! decodebin2 ! xvimagesink For the first one it obviously is faster (no encoding). For the 2nd one it would be suprising. Please also note that testing an encoder with the snow pattern is ecpected to be slow, as there is hadly anything that can be compressed. Stefan > > So, what am I doing wrong? I tried with various settings for vp8enc > and webmmux, I tried different queue placement and the result is > always more or less the same. If I press CTRL-C after some time, > waiting for EOS is displayed for quite some time and the video is only > a second or two long. If resolution is increased, then everything > takes much much longer. > > I am running this on quad i5 with 4GB of RAM and there is almost no > disk activity during recording. > > Kernel, OS and Gstreamer versions below: > Linux pond 3.2.0-19-generic #30-Ubuntu SMP Fri Mar 16 16:27:15 UTC > 2012 x86_64 x86_64 x86_64 GNU/Linux > > Ubuntu Precise Pangolin 12.04 > > gst-launch-0.10 version 0.10.36 > GStreamer 0.10.36 > https://launchpad.net/distros/ubuntu/+source/gstreamer0.10 > > Plugin Details: > Name: vp8 > Description: VP8 plugin > Filename: /usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstvp8.so > Version: 0.10.22.3 > License: LGPL > Source module: gst-plugins-bad > Source release date: 2012-02-09 14:42 (UTC) > > Plugin Details: > Name: matroska > Description: Matroska and WebM stream handling > Filename: > /usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstmatroska.so > Version: 0.10.31 > License: LGPL > Source module: gst-plugins-good > Source release date: 2012-02-20 > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Pipeline performance problems
|
|
On 03/22/2012 11:53 AM, Stefan Sauer wrote:
> ximagesink can't render webm, so how exactly is the xvimagesink based > pipeline lokks like. Is it > gst-launch -e videotestsrc pattern=snow num-buffers=250 ! \ > video/x-raw-yuv,width=640,height=480,framerate=25/1 ! \ > ffmpegcolorspace ! queue ! xvimagesink This is the pipeline without filesink and no encoding, yes. > For the first one it obviously is faster (no encoding). For the 2nd one > it would be suprising. Please also note that testing an encoder with the > snow pattern is ecpected to be slow, as there is hadly anything that can > be compressed. I can understand that with encoding it will be somewhat slower, but the performance drop is significant. Initial pipeline what I was working with used ximagesrc as a source and I had the same performance issues. I wanted to exclude ximagesrc that is why I was trying with videotest. With ximagesrc everything is even worse. This is an example: $ time gst-launch -e ximagesrc startx=0 starty=0 endx=1919 endy=1079\ num-buffers=250 use-damage=0 ! video/x-raw-rgb,framerate=25/1 ! \ videorate ! queue ! ffmpegcolorspace ! vp8enc ! queue ! webmmux ! \ queue ! filesink location="test.webm" Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock Redistribute latency... ^CCaught interrupt -- handling interrupt. Interrupt: Stopping pipeline ... EOS on shutdown enabled -- Forcing EOS on the pipeline Waiting for EOS... Got EOS from element "pipeline0". EOS received - stopping pipeline... Execution ended after 333779194456 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... real 5m33.906s user 5m32.701s sys 0m0.564s Times here are horrible. I waited for two minutes or so for gst to stop capturing then I pressed CTRL-C. After that, I was waiting for more than three minutes for EOS. Any help will be greatly appreciated. Regards, David _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Pipeline performance problems
|
|
On 03/22/2012 12:15 PM, David Klasinc wrote:
> $ time gst-launch -e ximagesrc startx=0 starty=0 endx=1919 endy=1079\ > num-buffers=250 use-damage=0 ! video/x-raw-rgb,framerate=25/1 ! \ > videorate ! queue ! ffmpegcolorspace ! vp8enc ! queue ! webmmux ! > \ queue ! filesink location="test.webm" The problem is in the VP8 encoder. This happens with x264enc: $ time gst-launch -e ximagesrc startx=0 starty=0 endx=1279 endy=1023\ num-buffers=150 use-damage=0 ! video/x-raw-rgb,framerate=15/1 !\ videorate ! queue ! ffmpegcolorspace ! x264enc ! queue ! matroskamux !\ queue ! filesink location="test.mkv" Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 10582065296 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... real 0m10.689s user 0m9.877s sys 0m0.320s With vp8 I pressed CTRL-C after around 30 seconds and this happened: $ time gst-launch -e ximagesrc startx=0 starty=0 endx=1279 endy=1023\ num-buffers=150 use-damage=0 ! video/x-raw-rgb,framerate=15/1 !\ videorate ! queue ! ffmpegcolorspace ! vp8enc ! queue ! webmmux ! \ queue ! filesink location="test.webm" Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock Redistribute latency... ^CCaught interrupt -- handling interrupt. Interrupt: Stopping pipeline ... EOS on shutdown enabled -- Forcing EOS on the pipeline Waiting for EOS... Got EOS from element "pipeline0". EOS received - stopping pipeline... Execution ended after 70585427853 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... real 1m10.686s user 1m9.884s sys 0m0.200s Pipeline is exactly the same except for encoder and muxer. True, it could also be a muxer problem. :) Any thoughts, ideas on how to improve performance? Rgrds, David _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Pipeline performance problems
|
|
On 03/22/2012 03:00 PM, David Klasinc wrote:
> On 03/22/2012 12:15 PM, David Klasinc wrote: >> $ time gst-launch -e ximagesrc startx=0 starty=0 endx=1919 endy=1079\ >> num-buffers=250 use-damage=0 ! video/x-raw-rgb,framerate=25/1 ! \ >> videorate ! queue ! ffmpegcolorspace ! vp8enc ! queue ! webmmux ! >> \ queue ! filesink location="test.webm" > > The problem is in the VP8 encoder. This happens with x264enc: > > $ time gst-launch -e ximagesrc startx=0 starty=0 endx=1279 endy=1023\ > num-buffers=150 use-damage=0 ! video/x-raw-rgb,framerate=15/1 !\ > videorate ! queue ! ffmpegcolorspace ! x264enc ! queue ! matroskamux > !\ queue ! filesink location="test.mkv" Doing live encoding of 1280x1024 at 25 fps + the conversion from rgb to yuv will require a fast CPU and a optimized encoder. Please discuss with the libvpx developers if you are not happy abouts its performance. Also running a profiler (such as oprofile and getting data about where the cpu is spend is useful). Also grabbing the screen using ximagesrc seems to have quite some overhead, although I can't suggest any alternative. Stefan > > Setting pipeline to PAUSED ... > Pipeline is live and does not need PREROLL ... > Setting pipeline to PLAYING ... > New clock: GstSystemClock > Got EOS from element "pipeline0". > Execution ended after 10582065296 ns. > Setting pipeline to PAUSED ... > Setting pipeline to READY ... > Setting pipeline to NULL ... > Freeing pipeline ... > > real 0m10.689s > user 0m9.877s > sys 0m0.320s > > > With vp8 I pressed CTRL-C after around 30 seconds and this happened: > > $ time gst-launch -e ximagesrc startx=0 starty=0 endx=1279 endy=1023\ > num-buffers=150 use-damage=0 ! video/x-raw-rgb,framerate=15/1 !\ > videorate ! queue ! ffmpegcolorspace ! vp8enc ! queue ! webmmux ! \ > queue ! filesink location="test.webm" > Setting pipeline to PAUSED ... > Pipeline is live and does not need PREROLL ... > Setting pipeline to PLAYING ... > New clock: GstSystemClock > Redistribute latency... > ^CCaught interrupt -- handling interrupt. > Interrupt: Stopping pipeline ... > EOS on shutdown enabled -- Forcing EOS on the pipeline > Waiting for EOS... > Got EOS from element "pipeline0". > EOS received - stopping pipeline... > Execution ended after 70585427853 ns. > Setting pipeline to PAUSED ... > Setting pipeline to READY ... > Setting pipeline to NULL ... > Freeing pipeline ... > > real 1m10.686s > user 1m9.884s > sys 0m0.200s > > Pipeline is exactly the same except for encoder and muxer. True, it > could also be a muxer problem. :) > > Any thoughts, ideas on how to improve performance? > > Rgrds, > David > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Pipeline performance problems
|
|
Yes, you are waiting a long time after sending the EOS because the queues are all filled up (since vp8 encoding is very slow) and that's the time needed for the encoder to process the whole queued data. If you need live encoding try simpler formats like mjpeg (jpegenc), or downscale the stream you want to record... Also note that if you let your current pipeline running it will eventually exhaust your queue maximum memory. Regards Florent Le 22 mars 2012 19:48, "Stefan Sauer" <[hidden email]> a écrit :
On 03/22/2012 03:00 PM, David Klasinc wrote: _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |