rtspsrc cpu optimization

[Olivier Crête]

On 10/14/2014 04:25 PM, Eloi Bail wrote:
> On Tue, Oct 14, 2014 at 3:40 PM, Olivier Crête
> <olivier.crete at collabora.com> wrote:
>> For each receive pipeline, you should only have two threads involved in
>> the streaming, one taking packets from the network socket to the
>> jitterbuffer. And one taking packets from the jitterbuffer. If you have
>> audio and video, then that's a total of 4 threads.
>>
> 
> We are only dealing with video. According to gdb on X86, I see lot of
> thread creation  and only some exiting !
> http://fpaste.org/141895/17469141/
> So you think it is not a normal behavior ?
> I will look deeper on it.

This is a normal behavior, there are a lot of threads in GStreamer,
especially in the RTP stack. But most of them don't do much, such as
just as receiving or sending RTCP (once per 5 seconds), etc. Only two
should be involved in streaming and therefore appear in perf.


>> There is also a rtpbin containing all of those. The number of elements
>> doesn't really affect the number of threads or the performance much.
> 
> we are already using rtpbin in rtspsrc. It looks like rtpbin take a
> "lot" ( comparing to live555) of CPU.
> If you say that pipeline design does not affect the performance,
> that's good to know.

I'd be curious to know why we are using so much more CPU than live555,
let me know what you find.


-- 
Olivier Crête
olivier.crete at collabora.com