[Live-devel] Logging or debug info

Ross Finlayson finlayson at live555.com
Wed May 7 11:28:01 PDT 2014


> Based on what I see it seems as if Live555 does not properly clean up the first session when the
> connection breaks. Instead it seems to close the wrong connection when the time out occurs.

No, based on your description I'm not seeing any incorrect server behavior.  The server is timing out the first connection (and deleting the "RTSPClientConnection" object) 65 seconds after you kill the first client (without having it send a "TEARDOWN").  The second client then causes a new "RTSPClientConnection" object to get created.  (It happens to have the same address - 0x10c008000 - as the old "RTSPClientConnection" object, but it's a new object.)

The reason why the server stops streaming to the second client after the first client has timed out is most likely due to a problem with your own additions to the server - i.e., either your own "OnDemandServerMediaMediaSubsession" subclass, and/or your own "FramedSource" subclass.

First, when your "OnDemandServerMediaMediaSubsession" subclass's constructor calls the "OnDemandServerMediaMediaSubsession" constructor, then make sure that the "reuseFirstSource" parameter is "True".  This ensures that - if two or more clients request the stream concurrently - then your "FramedSource" subclass (i.e., your data source class) will be created only once.

Second, you must allow for the possibility of your "FramedSource" subclass object being closed, then recreated - perhaps multiple times.  If you set "reuseFirstSource" to "True" (as noted above), then you will never see your "FramedSource" subclass constructor being called more than once before the destructor is called - but you may see "constructor", "destructor", "constructor", "destructor", etc.  Your "FramedSource" subclass's constructors and destructors must allow for this to happen.

Finally, if you want to test the behavior of your server, then you should first do so using our "openRTSP" client (note the "-t" option to request RTP/RTCP-over-TCP streaming), not with some random other client (that might use a different - perhaps broken - RTSP client implementation).  Similarly, if you want to test the behavior of your own client, then you should first do so using "testOnDemandRTSPServer" or the "LIVE555 Media Server" as the server.  This is common sense.  If you want to test a client-server combination, then start with one combination that you know works OK ("testOnDemandRTSPServer" with "openRTSP"), then change only one end at a time as you continue your testing.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140507/88d0a2e8/attachment-0001.html>


More information about the live-devel mailing list