Re: [Live-devel] BUGS in rtsp interleaved
Hi Ross, Thanks for help and I solved the problem. The reason of problem is that RTPINTERFACE_BLOCKING_WRITE_TIMEOUT_MS value is not high enough and it causes failure send function in sendDataOverTCP. Probably the root reason is poor network quality. Thanks again Sincerely. On 22.01.2020 13:39, Ross Finlayson wrote: Cihan, Note that the ‘interleaving’ (RTP/RTCP-over-RTSP) is happening only for your ‘front-end’ stream, which you are accessing using the VLC RTSP client application. Unfortunately we can’t help you specifically with problems with VLC, as that is not our software. Instead, for testing, I suggest that you use our “openRTSP” command-line RTSP client application as your ‘front-end’ RTSP client; see http://www.live555.com/openRTSP/ However, I suspect that your problem, in reality, has nothing to do with ‘interleaving’. You can test this by first running openRTSP rtsp://192.168.1.100:555/proxyStream and then running openRTSP -t rtsp://192.168.1.100:555/proxyStream I suspect that you will end up with the same result in each case. If the “LIVE555 Proxy Server” stops "sending RTP packets after several seconds”, then it most likely means that the ‘back end’ server (in your case, the "Hanua IP Cam”) has stopped streaming to the proxy server. (Again, this would have nothing to do with ‘interleaving’, which is happening only with the ‘front end’ stream.) The only way we could figure out what is happening with the ‘back end’ stream is for you to show us the diagnostic output from the proxy server (which you are giving “live555ProxyServer” the “-V” argument). Ross Finlayson Live Networks, Inc. http://www.live555.com/ ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] BUGS in rtsp interleaved
> On Jan 23, 2020, at 1:32 AM, Cihan Kömeçoğlu wrote: > > Hi Ross, > > Thanks for help and I solved the problem. The reason of problem is that > RTPINTERFACE_BLOCKING_WRITE_TIMEOUT_MS value is not high enough and it causes > failure send function in sendDataOverTCP. Probably the root reason is poor > network quality. Sigh… By your own admission, your front-end stream’s output rate is exceeding the capacity of your network. Then WHY, OH WHY are you trying to stream RTP-over-TCP on your front-end connection?? Once again: If a RTP-over-TCP connection is so slow that it is eventually filling up the sender OS’s buffer, then that means that it’s exceeding the capacity of the TCP connection (which is based in part on the packet loss rate of the connection between the server and client; it can be *much* less than the nominal speed of your server’s network interface). In this case it’s more efficient to stream over UDP instead. Either way, you’ll get data loss, but the overall data loss rate will be less than it will be over the TCP connection. Over TCP, the data loss will be clumped together (at the time(s) when the sender OS’s buffer keeps filling up), and the overall end-to-end latency (between sender and client) will be higher. Also, if you get to a situation where your OS’s output buffer is filling up, the LIVE555 code is forced to start using blocking I/O for many of its network packet writes. This will cause the server to stall everything else that it might be doing. In your case, you are experiencing stalls of up to ***500 ms***, which is crazy. As I have explained many times, one should stream over TCP *only if* you have a firewall - between the server and client - that blocks UDP packets. You should never stream over TCP just because you want to avoid data loss. If your stream’s data rate exceeds the capacity of the network connection (server->client), then you *will* lose data, no matter how you choose to stream it. But it’s much better to stream over UDP. However, if you really want to avoid all data loss, then you should be copying your data using something like HTTP, rather than streaming it. Ross Finlayson Live Networks, Inc. http://www.live555.com/ ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] BUGS in rtsp interleaved
Hi Ross, Yes as you said , there is a firewall and nat between client and server. thats why I have to use TCP. I will increase send buffer size also and thinking to change sendTCP function to not fail even sendbuffer is full. On 23.01.2020 16:29, Ross Finlayson wrote: On Jan 23, 2020, at 1:32 AM, Cihan Kömeçoğlu wrote: Hi Ross, Thanks for help and I solved the problem. The reason of problem is that RTPINTERFACE_BLOCKING_WRITE_TIMEOUT_MS value is not high enough and it causes failure send function in sendDataOverTCP. Probably the root reason is poor network quality. Sigh… By your own admission, your front-end stream’s output rate is exceeding the capacity of your network. Then WHY, OH WHY are you trying to stream RTP-over-TCP on your front-end connection?? Once again: If a RTP-over-TCP connection is so slow that it is eventually filling up the sender OS’s buffer, then that means that it’s exceeding the capacity of the TCP connection (which is based in part on the packet loss rate of the connection between the server and client; it can be *much* less than the nominal speed of your server’s network interface). In this case it’s more efficient to stream over UDP instead. Either way, you’ll get data loss, but the overall data loss rate will be less than it will be over the TCP connection. Over TCP, the data loss will be clumped together (at the time(s) when the sender OS’s buffer keeps filling up), and the overall end-to-end latency (between sender and client) will be higher. Also, if you get to a situation where your OS’s output buffer is filling up, the LIVE555 code is forced to start using blocking I/O for many of its network packet writes. This will cause the server to stall everything else that it might be doing. In your case, you are experiencing stalls of up to ***500 ms***, which is crazy. As I have explained many times, one should stream over TCP *only if* you have a firewall - between the server and client - that blocks UDP packets. You should never stream over TCP just because you want to avoid data loss. If your stream’s data rate exceeds the capacity of the network connection (server->client), then you *will* lose data, no matter how you choose to stream it. But it’s much better to stream over UDP. However, if you really want to avoid all data loss, then you should be copying your data using something like HTTP, rather than streaming it. Ross Finlayson Live Networks, Inc. http://www.live555.com/ ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] BUGS in rtsp interleaved
> On Jan 23, 2020, at 6:58 AM, Cihan Kömeçoğlu wrote: > > Hi Ross, > > Yes as you said , there is a firewall and nat between client and server. > thats why I have to use TCP. > > I will increase send buffer size also and thinking to change sendTCP function > to not fail even sendbuffer is full. You still don’t get it. If your stream is exceeding the capacity of your network, you *will* eventually get data loss, no matter how much buffering you add. Your only solution is to reduce the data rate of your stream (e.g., by changing your encoding parameters). (And if you modify the supplied code, you can expect no support on this mailing list.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Broken RTSP source sometime lead to handler not being called
I meet some problem with detecting that stream is broken. The path it takes is like this: It may be the case that connection is pending or while in connected state the command is send (write in sendRequest succeed) but reply is never arrived (RTSP source is overloaded for example). Is there any way to set or add timeout for commands being set so that a handler will be called upon timeout expiration? Best regards, Alexander. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Broken RTSP source sometime lead to handler not being called
You’re going to have to be a lot more specific. How are you using our software? Are you using it as a RTSP client, a RTSP server, a RTSP proxy server, or in some other way? And are you using one of our suppled applications, or are you referring to an application that you have written yourself (using our libraries)? And what specifically is happening that is causing an issue for you? Ross Finlayson Live Networks, Inc. http://www.live555.com/ ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] BUGS in rtsp interleaved
I understand you no problem. I will handle it. Maybe I could not clarify myself enough. Thanks for your help. On 23.01.2020 18:07, Ross Finlayson wrote: On Jan 23, 2020, at 6:58 AM, Cihan Kömeçoğlu wrote: Hi Ross, Yes as you said , there is a firewall and nat between client and server. thats why I have to use TCP. I will increase send buffer size also and thinking to change sendTCP function to not fail even sendbuffer is full. You still don’t get it. If your stream is exceeding the capacity of your network, you *will* eventually get data loss, no matter how much buffering you add. Your only solution is to reduce the data rate of your stream (e.g., by changing your encoding parameters). (And if you modify the supplied code, you can expect no support on this mailing list.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
