testRTSPClient problems

[wangdanhui_jx at aliyun.com]

yes, i know you said, but i think the problem is when a client not receive data, it will do while in  MultiFramedRTPSource::doGetNextFrame1, return after receive RTCP BYE from server(about 2min) .  in  doGetNextFrame1 the other client can't receive data. 

i try to check stream in thread, if 15 sec not receive ,  i  shutdown the client,but it will crash



wangdanhui_jx at aliyun.com
 
From: live-devel-request
Date: 2017-09-21 03:00
To: live-devel
Subject: live-devel Digest, Vol 166, Issue 11
Send live-devel mailing list submissions to
live-devel at lists.live555.com
 
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.live555.com/mailman/listinfo/live-devel
or, via email, send a message with subject or body 'help' to
live-devel-request at lists.live555.com
 
You can reach the person managing the list at
live-devel-owner at lists.live555.com
 
When replying, please edit your Subject line so it is more specific
than "Re: Contents of live-devel digest..."
 
 
Today's Topics:
 
   1. Your problems with "testRTSPClient" (Ross Finlayson)
 
 
----------------------------------------------------------------------
 
Message: 1
Date: Wed, 20 Sep 2017 00:38:17 -0700
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use
<live-devel at ns.live555.com>
Subject: [Live-devel] Your problems with "testRTSPClient"
Message-ID: <82B00BEC-9459-473E-A46F-D00366D5D925 at live555.com>
Content-Type: text/plain; charset=utf-8
 
> sorry. it will return after 1min32sec  as receive BYE . 
 
What is probably happening here is that your RTSP server is not receiving any RTCP ?RR? (Reception Report) packets from the client, and is therefore concluding that the client is no longer alive.  The server therefore 'times out? and closes the session (and sends a RTCP ?BYE? when it does this).
 
It appears that you have a firewall - somewhere between the client and the server - that is blocking RTCP packets from the client.  If you fix (or remove) this firewall, the server will start receiving RTCP ?RR? packets from the client, and will no longer 'time out? the connection after ~ 1min32sec.
 
(Another way to solve this is to arrange for your client to periodically send a ?keep-alive? RTSP command (e.g., ?OPTIONS?) back to the server - to tell the server that the client is still alive.  For an example of how to do this, see how our ?openRTSP? application <http://www.live555.com/openRTSP/> implements the ?-K? option; see ?playCommon.cpp?, lines 371-374.)
 
 
Another problem you have (though less serious than the first problem) is that RTCP ?SR? (Sender Report) packets from the server 192.168.11.114 are not reaching the client.  You can see this by the exclamation point (i.e., ?!?) at the end of the ?Presentation time?s for that server; ?testRTSPClient? outputs this when the presentation time has not been synchronized by the arrival of a RTCP ?SR? packet.
 
This is not serious, as long as the stream contains only a video track.  However, if you want to have both a video and an audio track, and have them properly synchronized, then it?s important that the server send out RTCP ?SR? packets, and that the client be able to receive them.
 
 
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
 
 
 
 
------------------------------
 
Subject: Digest Footer
 
_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
 
 
------------------------------
 
End of live-devel Digest, Vol 166, Issue 11
*******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20170921/94d5d2e2/attachment.html>