Thank you!
I confirm that with version live.2022.12.01.tar.gz I can receive
streams with rtsp-over-https using calls like
openRTSP -T 8881 rtsps://127.0.0.1:12345/whatever
where 8881 would be the https port. The port in the url (12345) is
meaningless. "rtsps" in the url sounds misleading, but thi
> On Dec 2, 2022, at 9:41 AM, Gajdosik Johannes wrote:
>
> Hello Ross,
> I am sorry, it is not fixed yet.
Arggh! Unfortunately I can’t reproduce the exact situation you’re
encountering, so I had to guess the solution, without testing it.
> Analysis: Here is the modified code in RTSPClient::
Hello Ross,
I am sorry, it is not fixed yet.
Analysis: Here is the modified code in RTSPClient::connectionHandler1.
...
// The connection succeeded. If the connection came about from an
attempt to set up RTSP-over-HTTP, finish this now: if
(fHTTPTunnelingConnectionIsPending && !setupHT
> On Dec 1, 2022, at 2:32 AM, Gajdosik Johannes wrote:
>
> Hello Ross,
>
> Now I use the new version live.2022.11.29.tar.gz. And still get the same
> SIGSEGV:
OK, please try again with the next version: 2022.11.30. I think I’ve fixed it
for real this time.
Ross Finlayson
Live Networks, I
ction connectResult is set:
int connectResult = connectToServer(...)
On my computer connectResult is always 0, because connect returns EINPROGRESS.
Therefore fOutputTLS->connect can never be called and fOutputTLS is always
uninitialized.
Later, when the connection is established, connectionHander1 is called
Johannes,
Thanks for the report.
Yes, there was a bug in the RTSP client’s implementation of RTSP-over-HTTP
streaming, when done over TLS. I have just installed a new version
(2022.11.29) of the code that should fix this. (But should you still encounter
problems, let us know.)
Ross Finlays
