[Live-devel] Logging or debug info

[Jan Ekholm]

On 7 maj 2014, at 21:28, Ross Finlayson <finlayson at live555.com> wrote:

>> 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.

My own subclasses are very shallow and I can not see what else (apart from isSSM) that could have any effect
on this. Nothing deadlocks in my code. What happens is that the wrong stream gets cut off. The connection to
the second client is not closed cleanly, as otherwise it would get EOF at some point.

> 
> 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.

reuseFirstSource is set to True, and it works ok with several clients streaming the same source: only one instance
is ever created.

> 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.

Yes, this also works. During the stream startup one instance is created so that the H264 parameters can be probed.
That instance is then destroyed and a new one created for the real streaming task. That part works ok. I even see the
USB camera light light up for the probe, go dark and then light up again when the real stream starts.

> 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.

I can test tomorrow with one of the test servers against my client. But even a badly working client
should not be able to cause problems (cut stream) for another unrelated client. 

-- 
Jan Ekholm
jan.ekholm at d-pointer.com