[Live-devel] Proxyserver Subsession Teardown

[Lakshmi Narayan.G]

Hi Ross,
In the latest live555ProxyServer, I am facing an issue with
multiple clients. My Stream source contains Both Audio and Video
subsessions. Using openRTSP as client1, I receive only the video stream
(/openRTSP -v rtsp://<URL>/) and another instance as client2. When I
close the client2 The ProxyServer sends PAUSE to the Stream Source even
when client1 is still running. Causing an undesirable video loss to client1.

On checking the source code, I could see that the TEARDOWN from client2
ends the Audio stream and calls /*closeStreamSource*/ function. This In
turn sends Pause command to the parent Session.

I am using the latest live555 (2016.02.22) proxyserver and openRTSP
client. For Stream source I am depending on this online stream
(rtsp://streaming1.osu.edu/media2/ufsap/ufsap.mov).

[Ross Finlayson]

I’m sorry, but I haven’t been able to reproduce this at all. When there are two (or more) ‘front-end’ clients streaming the same stream from the proxy server, then the closure of any one of the ‘front-end’ streams has no effect on what the proxy server does. It’s only when the *last* ‘front-end’ stream closes that the proxy server will send a “PAUSE” command to the ‘back-end’ server.

Please make sure that you have made no modifications to the supplied code. (We can’t provide any support otherwise.)


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

[Lakshmi Narayan.G]

Hi Ross,
Thank you for the reply. Yes It is PAUSE That is sent to the camera.
(mistake in subject). The scenario in which I am facing the issue, is as
follows

* REGISTER a camera with Video and Audio subsession.
* Client 1 - openRTSP -v rtsp://ip:port/streamid (VIDEO ONLY CLIENT)
* Client 2 - openRTSP rtsp://ip:port/streamid
* Stop Client 2

(Live.2016.02.22 unchanged code for Proxy and Client. Used
testOnDemandRTSPServer for camera with test.264 and test.mp3 as subsessions)

Observation: With client 2 Exiting, ProxyServer will cleanup the
resources allocated to the client, calls reclaimStreamStates() and in
this process does closeStreamSource if no longer in use.

as I checked - this was found to be a rough flow of code that sends
Pause to camera
/
/
/RTSPServer::RTSPClientSession::~RTSPClientSession()//
//reclaimStreamStates()//
//subsession->deleteStream()//
//~StreamState()//
//reclaim()//
//ProxyServerMediaSubsession::closeStreamSource//
//proxyRTSPClient->sendPauseCommand()/

This was verified for both UDP and RTP-over-TCP (Targeted usage will be
RTP-over-TCP)
Could we send PAUSE only to that particular subsession and handle the
same at the Camera side. Or any alternative way of handling this situation

*- Best Regards

* Lakshmi Narayanan.G
VVDN Technologies Pvt Ltd
**

I’m sorry, but I haven’t been able to reproduce this at all. When there are two (or more) ‘front-end’ clients streaming the same stream from the proxy server, then the closure of any one of the ‘front-end’ streams has no effect on what the proxy server does. It’s only when the *last* ‘front-end’ stream closes that the proxy server will send a “PAUSE” command to the ‘back-end’ server.
Please make sure that you have made no modifications to the supplied code. (We can’t provide any support otherwise.)
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
http://lists.live555.com/mailman/listinfo/live-devel

[Ross Finlayson]

Sorry, but I still can’t reproduce this. Please run your “live555 Proxy Server” with the “-V” flag (for verbose output), and post (to this mailing list) the output that illustrates the problem that you are seeing. Perhaps that will tell me what is happening for you.


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

[Ross Finlayson]

A correction: I am now able to reproduce the problem (so you no longer need to send me the proxy server output that illustrates this).

Yes, this is definitely a bug. (When the second (audio+video) client disconnects, the proxy server should be sending a RTSP “PAUSE” command only for the audio track; not for the entire stream.)

I will try to fix this in a future release of the software. Stay tuned...

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

[Ross Finlayson]

FYI, the latest version (2016.03.14) of the “LIVE555 Streaming Media” software should fix this problem.

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