rtspsrc cpu optimization

[Sebastian Dröge]

On Do, 2014-10-23 at 12:00 -0400, Eloi Bail wrote:

> > 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 ?

You need to do some more detailed profiling with your real pipeline to
see where exactly (in which function!) all the time is spent. Without
knowing this there's not much that can be said about all this.

> 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.

udpsrc should wake up once per RTP packet and then send it downstream.
There should be a direct relationship between the number of packets
received and udpsrc doing something.

It basically waits on the UDP socket until something is available, then
reads exactly one packet and then sends it downstream. Due to the nature
of UDP and RTP reading more than one packet at once into the same buffer
would cause the RTP framing to disappear, and would make the stream
unusable. There might be some ways how this could be improved in udpsrc
with scatter-gather read operations, that needs to be checked. But in
any case we must make sure that we create one GStreamer buffer per
RTP/UDP packet.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20141023/9f90f86d/attachment.sig>