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-boun...@ns.live555.com [mailto:live-devel-boun...@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@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
