rtspsrc cpu optimization
Olivier CrĂȘte
olivier.crete at collabora.com
Tue Oct 14 14:01:41 PDT 2014
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
More information about the gstreamer-devel
mailing list