rtspsrc cpu optimization

[Eloi Bail]

On Wed, Oct 22, 2014 at 3:32 AM, Sebastian Dröge
<sebastian at centricular.com> wrote:
> Are we talking about RTSP with RTP over TCP or over UDP? With UDP you
> should still get one RTP packet per read, and by adding the sleep you
> risk running the kernel buffer full if there are on average more than 1
> packet per ms.

RTP is done over UDP. To avoid kernel buffer full, I could increase its size.
I made some wireshark measures (see in attachement).
In average I have 105 packets / sec. I see cases when 40 packets are
received during 6ms.
So definitely I would need to be careful with that but it is not such
a high traffic. Notice also that the camera would not change. So I
will always deal with the same traffic.

> I think as a next step it would be required to see where exactly the
> high CPU usage comes from when reading from the socket, and then
> optimize these bits. As we're talking about RTP here there's not much
> you can do to get less packets (other than increasing the MTU or
> lowering the stream's bitrate), so that part is rather fixed.

Profling my pipeline with perf embedded and callgrind X86 did help me
so far (see perf top in attachement launching 0,1,2,3,4 pipelines
rtspsrc ! fakesink.

Some CPU stats:
- my whole pipeline generating mkv file (rtspsrc ! rtph264depay !
h264parse ! queue2 ! matroskamux ! filesink) consume about 10%.
- rtspsrc ! fakesink consume around 8%
- pthreads udpsrc0 (RTP sockets) is around 5% and jitterbuffer around 3%

I also see lot of time spent in pad_push and CPU gain removing locks
in pad_push. Actually it proves that udpsrc0 source is pushing more
buffer that  rtpptdemux sink can (congestion in push_pad). Right ?

That's why I tried to figure out how to manage bigger buffer in order
to push them less. Adding the sleep help me to have udpsrc0 consuming
1-2% and jitterbuffer 0-1%.

The point is that 10% CPU for each pipeline is too much for my HW
(http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC8347E).
I will run 8 pipelines like this so I definitely need to reduce the
consumption. Notice also that I am trying to replace a old proprietary
solution on top of live555 that consumed around 3%.

I read doc http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/chapter-scheduling.html.
udpsrc is in push mode and use basesrc task to push buffers. What I
don't understand is what drive the task execution period. It should
depend somehow from RTP bitrate but looking to the code I can not find
it.
According to wireshark analysis, packets/tick and Bits/tick are not
consistent at all. So I am wondering if task execution period is based
on high value or not.

> Which version of GLib are you using btw, and on which platform do you
> run your application? Sorry if you mentioned that in an earlier mail
> already.

I am using glib 2.36.3 and gstreamer 1.2.1.
Thanks for your help
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wireshark-camera-stats.pdf
Type: application/pdf
Size: 124318 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20141023/299e8d73/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: perf-top-0to4pipelines.log
Type: text/x-log
Size: 178494 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20141023/299e8d73/attachment-0001.bin>