On 7 maj 2014, at 21:28, Ross Finlayson <finlay...@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.ekh...@d-pointer.com
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
