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 [[email protected]] on behalf of Ross
Finlayson [[email protected]]
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
[email protected]<mailto:[email protected]>
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.
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
