[Live-devel] 100% cpu usage when 1 or more client connects to RTSP server
Shaan Nobee
shaan.nobee at mauritiustelecom.com
Thu Mar 12 04:12:39 PDT 2015
Hello Ross,
Hope that you're doing fine.
I digged a bit deeper into the problem and ran gprof to do profiling on the application.
Below are the results.
59.62 0.62 0.62 9593542 64.63 106.32 BasicTaskScheduler::SingleStep(unsigned int)
15.39 0.78 0.16 19190028 8.34 10.42 DelayQueue::synchronize()
5.77 0.84 0.06 57557157 1.04 1.04 HandlerIterator::next()
4.81 0.89 0.05 9593542 5.21 5.21 HandlerIterator::HandlerIterator(HandlerSet&)
3.85 0.93 0.04 19190029 2.08 2.08 TimeNow()
2.88 0.96 0.03 9593542 3.13 13.55 DelayQueue::handleAlarm()
2.88 0.99 0.03 9592398 3.13 3.13 BasicUDPSource::incomingPacketHandler1()
1.92 1.01 0.02 9593542 2.08 12.51 DelayQueue::timeToNextAlarm()
0.96 1.02 0.01 9592402 1.04 1.04 HandlerIterator::reset()
0.96 1.03 0.01 DelayQueue::findEntryByToken(long)
0.96 1.04 0.01 HandlerSet::lookupHandler(int)
0.00 1.04 0.00 9593541 0.00 0.00 HandlerIterator::~HandlerIterator()
0.00 1.04 0.00 9592398 0.00 0.00 BasicUDPSource::incomingPacketHandler(BasicUDPSource*, int)
0.00 1.04 0.00 3094 0.00 0.00 DelayQueue::removeEntry(DelayQueueEntry*)
0.00 1.04 0.00 3093 0.00 10.42 DelayQueue::addEntry(DelayQueueEntry*)
0.00 1.04 0.00 3093 0.00 0.00 DelayQueueEntry::DelayQueueEntry(DelayInterval)
0.00 1.04 0.00 3092 0.00 10.43 BasicTaskScheduler0::scheduleDelayedTask(long, void (*)(void*), void*)
0.00 1.04 0.00 3088 0.00 0.00 AlarmHandler::~AlarmHandler()
0.00 1.04 0.00 3088 0.00 0.00 DelayQueueEntry::~DelayQueueEntry()
0.00 1.04 0.00 3082 0.00 10.28 AlarmHandler::handleTimeout()
0.00 1.04 0.00 3081 0.00 0.00 DelayQueueEntry::handleTimeout()
0.00 1.04 0.00 2988 0.00 0.00 BasicTaskScheduler::schedulerTickTask(void*)
What's happening is that the BasicUDPSource::incomingPacketHandler1() function is being called too many times.
I added a counter in the function and it seems that this line of code is being called many many times (line 65 in BasicUDPSource.cpp):
if (!isCurrentlyAwaitingData()) return;
I modified the line to:
if (!isCurrentlyAwaitingData()) {usleep(500);return;}
And since then the CPU usage does not go up to 100% but stays around 1%! :)
I don't know if it's a correct thing to do and what its implications could be.
When I'm running the stream, the audio is a bit choppy but I'm not sure that's related to this modification or my bandwidth. (I'll do some further tests to confirm this)
Do you have any idea why this line would be called so many times and maybe a better solution?
I double checked the ffmpeg command and everything seems normal.
Thanks!
Shaan
________________________________
From: live-devel [live-devel-bounces at ns.live555.com] on behalf of Ross Finlayson [finlayson at live555.com]
Sent: Wednesday, March 11, 2015 3:25 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] 100% cpu usage when 1 or more client connects to RTSP server
1. Actually it seems that reuseFirstSource variable is not used in the original testOnDemandRTSP for the UDP mpegts example(and in my code too).
Yes, you’re correct. The “MPEG2TransportUDPServerMediaSubsession” implementation sets the “reuseFirstSource” parameter to True when it calls the parent ("OnDemandServerMediSubsession”) constructor, so - in this particular case - the “reuseFirstSource” variable in the “testOnDemandRTSPServer” code isn’t used (and therefore isn’t relevant to you, if all you are doing is streaming from UDP input sources). My mistake.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
Shaan Nobee
- Corporate Office
Tel: +2302037117 | Mob: +23052518816 | Fax: +2302116996
shaan.nobee at mauritiustelecom.com<mailto:shaan.nobee at mauritiustelecom.com>
www.mauritiustelecom.com<http://www.mauritiustelecom.com/> | www.orange.mu<http://www.orange.mu/> | [Orange on Facebook] <http://www.facebook.com/orangemauritius?ref=hl> | [Orange on Twitter] <http://https//twitter.com/OrangeMauritius>
[Mauritius Telecom]<http://www.mauritiustelecom.com/> [Orange Mauritius] <http://www.orange.mu/>
This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Mauritius Telecom - Orange is not liable for messages that have been modified, changed or falsified.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150312/197e15ce/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo-fb.jpg
Type: image/jpeg
Size: 899 bytes
Desc: logo-fb.jpg
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150312/197e15ce/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo-twitter.jpg
Type: image/jpeg
Size: 1046 bytes
Desc: logo-twitter.jpg
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150312/197e15ce/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo-mt.png
Type: image/png
Size: 5883 bytes
Desc: logo-mt.png
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150312/197e15ce/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.gif
Type: image/gif
Size: 504 bytes
Desc: logo.gif
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150312/197e15ce/attachment.gif>
More information about the live-devel
mailing list