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
> 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
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, a
> 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 f
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
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
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. t
