[Live-devel] openRTSP

Andro Debevere andro.debevere at ugent.be
Thu Feb 25 03:07:06 PST 2010


Yes, all streams are contained in one single RTSP session ( I know this is
not common practice ;) but for archiving purposes, we need to bundle the
streams in one session so we can store them all together).

I did not ran into the limit of sockets per thread but using netstat, I
found out that sometimes two pairs of sockets used the same RTP and RTCP
port numbers. The socket-port number relationship is many to one and in the
end it conflicts with the select statement as it only marks one socket as
readable in the read set.

I solved the issue by creating an instance of the NoReuse class before
initiating the media subsessions in order to disable the reuse of port
numbers or addresses (setsockopt(SO_REUSEADDR) set to false), which was the
cause of this problem.
Maybe it is better to unset the reuseFlag in the GroupsockHelper class by
default?

Also, in the MediaSubsession::initiate(int useSpecialRTPoffset) function
only the pointer value of fRT(C)PSocket is checked after the creation of a
Groupsock object. But if the socket creation call returns -1 in the
constructor, the program will continue using the invalid socket handle.
Apart from the pointer value of fRT(C)PSocket, the value of fSocketNum
should be checked.

A last remark in the MediaSubsession::initiate(int useSpecialRTPoffset)
function: I noticed that when the user does not specify a start port value
(fClientsPortNum) sockets are created and checked if they are bound to an
even port. If they don't they are added to a socketHashTable and a new
socket is created until successful. Why not just create two sockets and
trying to bind them to a given port number, just as is done when the user
actually does give a start port number, but with the difference that you
choose the start port value yourself and don't return if one or both bind
calls fail but retry with the port number value + 2.

Kind regards.

-----Original Message-----
From: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Tuesday, February 23, 2010 11:40 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] openRTSP

>Therefore, we went deeper into the code until the point of the 
>BasicTaskscheduler. Here we see that after calling the select 
>statement in the "void BasicTaskScheduler::SingleStep(unsigned 
>maxDelayTime)" function, we only get a limited number of readable 
>sockets as a return value. If, for example, we have 52 media tracks, 
>we create at least 104 sockets (52 for RTP and 52 for RTCP), but the 
>result value is never 104 or higher, no matter how long we wait in 
>between two select calls.

You might have run into an OS-imposed limit on the number of sockets 
you can create within a single process.  Depending on your OS, you 
might be able to increase this limit.

Is it really the case that a *single* RTSP session contains 52 audio 
tracks?  Or do you have separate RTSP sessions (i.e., separate 
"rtsp://" URLs) for each audio track?  If it's the latter case, then 
it might make more sense to do this using several processes 
(application instances) - one for each audio track - rather than 
trying to do everything within a single process.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel



More information about the live-devel mailing list