[gst-devel] Pipeline performance assessment

[Andoni Morales]

2010/9/20 Baldur Gislason <baldur at medizza.com>:
> I have been doing some experiments with transcoding using gstreamer
> and I've had some pretty terrible performance.
> VLC has no problem performing the same task with as far as I can tell,
> identical encoder profiles, leaving plenty of resources behind, while
> with gstreamer I am maxing out one core and going about 40-50% on the
> remaining three, and not quite keeping up with real time transcoding.
> Machine is a 64 bit Linux system on an Intel Xeon E5507 quad core processor.
> I am decoding MPEG2 and encoding H.264.
> I was wondering if there was a recommended method of wathing the CPU
> time used by an element in a pipe.

To benchmark a pipeline/element in gstreamer you can use  the
'cpureport' element although you will need to apply some patches in
bugzilla to improve the precision in the results
(https://bugzilla.gnome.org/show_bug.cgi?id=627274)
You have to set the 'cpu-clock' property to CLOCK_THREAD_CPUTIME_ID to
get the time spent in the cpu by the encoder in the encoding thread,
which is created surrounding the encoder with queues. Otherwise you
will get the cpu time of the whole process instead of the cpu time of
the encoding thread.
This element post messages in the bus for each frame and the cpu % can
be get doing 'cpu-time' / 'actual-time' * 100

> My current pipeline goes like this:
> udpsrc -> mpegtsdemux
> demux -> decodebin2
> decoder -> x264enc -> queue -> mpegtsmux
> decoder -> audioconvert -> audioresample -> ffenc_aac -> queue -> mpegtsmux
> mux -> filesink (for testing purposes, would be udpsink in production)
> Is there any inherent problem with this configuration? I tried placing
> queues between decoder and encoders but that did not make any
> difference
> I have a hunch that the handling of the uncompressed video is
> inefficient but I'm not quite sure what the best tools are for finding
> bottlenecks of streaming applications.
You can try using queues with an unlimited size, in the unlikely case
where the video encoding thread is being blocked because of one the
queues being full.
Also, if you are looking to do real time, the default setting of the
x264 encoder might not be the best ones. A good reference are the
ffmpeg presets, which can me mapped to x264 settings using the
following guide:
http://rob.opendot.cl/index.php/useful-stuff/x264-to-ffmpeg-option-mapping/

Andoni
>
> Baldur
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>



-- 
Andoni Morales Alastruey

LongoMatch:The Digital Coach
http://www.longomatch.ylatuya.es