Andrei,
Thanks for the note. This change will be included in the next release of the
software.
You should understand, however, how you got into this situation: Your client
is receiving the stream via TCP (instead of via RTP/UDP), but the stream’s bit
rate is exceeding the capacity of the net
Hi all,
I believe I found a server bug. If a client connects from unreliable network,
server may lock up. In that state, it does not accept new connections, it
cannot be stopped, and if connection improves, it does not become responsive
again. The problem is confirmed on Raspbian and macOS so f
> That’s what I thought. I may add support for client-side RTSP-over-HTTPS sometime in the future, but (in order to
test this properly) I won’t do so until I also implement this in our RTSP server.
I fully understand that you need some kind of reference implementation on the
server side.
At the
> Simple and unsuccessful beats complicated and successful?
Of course, not.
However, for the tests I needed, the socat "tricks" proved to be simple and
successful.
I would like to stress that it is about tests, not a production quality
solution.
I just needed RTSP sources with different transpor
On Dec 15, 2021, at 2:09 AM, Laszlo Ast wrote:
>
> I successfully used stunnel
...
> socat was the simplest solution.
Simple and unsuccessful beats complicated and successful?
It sounds like you’ve got some weeks or months to wait for a non-guaranteed
solution, so unless you’re going to writ
> Did you try stunnel or nginx as the HTTP to HTTPS proxy? Those are more likely to implement the wide array of TLS
functionality your end devices require than the more limited socat.
I successfully used stunnel, and possibly tried traefik and caddy, but it was
some weeks ago.
I also considered
On Dec 14, 2021, at 4:35 PM, Laszlo Ast wrote:
>
> different tricks (socat and RTSP proxies)
Did you try stunnel or nginx as the HTTP to HTTPS proxy? Those are more likely
to implement the wide array of TLS functionality your end devices require than
the more limited socat.
__