[Live-devel] High CPU usage streaming TCP and UDP with OnDemandServerMediaSubsession

[Chris Richardson (WTI)]

Hi Ross,

 

I have recently updated the LIVE555 libraries I am using, ultimately to
version 2014.08.23, though I originally updated to 2014.07.25 and the same
problem happens.  The problem is that the library is using a large amount of
CPU when streaming both UDP and TCP from the same
OnDemandServerMediaSubsession.  I can reproduce this problem both on my
embedded system (with my own setup code) and on an Ubuntu Linux machine
running an almost un-modified version of testOnDemandRTSPServer (the only
change is setting reuseFirstSource to 'True').

 

To test this yourself:

 

1.       Modify testOnDemandRTSPServer by setting reuseFirstSource to True.

2.       Start an instance of 'top' to watch the CPU usage.

3.       Start one copy of openRTSP, streaming using TCP via -t.  CPU usage
should be very low.  For me it is < 1%.

4.       Start another copy of openRTSP, streaming using UDP.  CPU usage
should now be very high.  For me it is > 90%.

 

For my testing I was reading pre-recorded H.264 data via 'h264ESVideoTest'.

 

I think the core problem is that RTPInterface (via
StreamState->fRTCPInstance-> fRTCPInterface) is not properly handling
receiving RTCP over both the TCP socket and UDP socket at the same time:

 

1.       Some RTCP data comes in over the UDP socket.

2.       The code eventually gets into RTPInterface::handleRead, which tries
to read the data from the TCP socket, since fNextTCPReadStreamSocketNum is
valid.  This read fails with EAGAIN almost all the time, and no data is
processed.

3.       On the next iteration through the event loop, the UDP socket is
still readable, since no data was read from it, and once again the code gets
into RTPInterface::handleRead, which tries to read the data from the TCP
socket.  This results in the UDP RTCP socket being kept in a continuously
readable state, which then causes the event loop to spin.

 

I dug through the changes for the previous months and discovered that a
change to RTPInterface::handleRead in the 2014.03.25 version causes this
problem to occur.  The attached patch undoes the change and fixes this
problem.  Applying this patch might cause other problems though, since I
think you removed it for the following reason given in the change log for
2014.03.25:

 

"- Fixed an issue in the "RTPInterface" code that could cause
"SetSpecificRRHandler()" to not

work properly when RTP/RTCP is being carried over TCP."

 

Thanks for your time, and please let me know if you would like me to test
anything else or send additional data.

 

Thanks,

 

Chris Richardson

WTI

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140826/e3214874/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RTPInterface.patch
Type: application/octet-stream
Size: 361 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140826/e3214874/attachment.obj>