Thank you a lot - the idea with timer+changeResponseHandler did the job. Just
timer should be scheduled in very early steps and not after Play was issued.
The problem were like that - I have numerous different RTSP sources - some
them were buggy ( IP Cameras ) - they send a reply to WRONG socket
> So it can be very helpfull to have a deadline timeout for getting command's
> response (of course with callback being called).
You can cancel a pending RTSP command by calling the function
RTSPClient::changeResponseHandler(unsigned cseq, responseHandler*
newResponseHandler)
(see “live
Thank you for replying,
This is RTSP client implemented based on testRTSPClient code supplied with
library sources.
What is happening is that upon errors in streaming from RTSP capable camera,
sometimes no callback is called.
If RTSP source reports problems (reply is sent) - code handles it w
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 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
