rtspsrc cpu optimization

[Eloi Bail]

> 7% on what platform? If it's anything above Core-i3, it is a significant
load
>

It is a quite old platform (
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC8347E)
with a  667 Mhz CPU.
Actually we used a proprietary solution based on live555 library. Recording
files on the same camera, CPU consumption is around 2% while it reach more
than 10% using gstreamer.

However it looks like gstreamer is stronger on RTP jitter.
I am a gstreamer lover and it is a fact that it offers lot of features
compared to other solutions. But it is a bit hard to justify such a
consumption difference.


> Jitter buffer handling isn't needed if your RTP packets are coming over
TCP,
> isn't it? You shouldn't have out of order packets unlike UDP

Indeed it would not be. As far as I know Gstreamer does not do that (only
RTSP packets) am I right ?

>
> Check where the load is, precisely which line is taking more cycles. That
> should give more clue
>

That is what I am trying to do. I was using too kernel tool *Perf*. I used
perf top running 0, then 1, 2 , 3, 4 pipelines (gst-launch-1.0 rtspsrc
location=rtsp://xxx ! fakesink)

See the result in attachment. I do not see for the moment that something
really consume CPU. I see increasing p_thread_mutex_lock.
Doing I see *also 10 simultaneous threads running* !

As live555 is monothread and event-driven it could explain such a
consumption difference.

I would like to decrease thread creation having less elements. Gathering
gstrtpsession, gstrtpssrcdemux, gstjitterbuffer, gstrtpptdemux into one big
"RtpBin" element would be a idea.

I would like to have first your advice.

Thanks,

Eloi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20141014/51219e2f/attachment.html>