Pipeline performance problems

Florent fthiery at gmail.com
Sun Apr 1 05:35:42 PDT 2012


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" <ensonic at hora-obscura.de> a écrit :

> 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
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20120401/072b9572/attachment.html>


More information about the gstreamer-devel mailing list