I have having difficulty reproducing this error - in part because it requires
the RTSP client to behave in a strange way (including sending a “SETUP” command
for a track that has already been “SETUP”).
Could you please explain specifically what the RTSP client is doing to
reproduce this? E.g.,
Russell,
Thanks for the note. This patch will be included in the next release of the
software.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
ps. When I saw the name “Shotover”, I suspected a Kiwi connection. From your
website, I see that I was correct!
___
Attached is a patch for live555 to avoid usage of `gmtime`, which is not
guaranteed to return a pointer to data in thread-local storage, so could
race with other threads. Unfortunately, there is no cross-platform
replacement, so this adds an ifdef to call the corresponding threadsafe
alternatives.
OK, the problem here is how we have (tried to) protect access to the
“fTriggersAwaitingHandling” variable, in order to make it safely accessible
(writeable) by a non-LIVE555 thread. To date, we have declared this variable
as “volatile”, but that isn’t the proper mechanism for inter-thread
comm
> On Jun 7, 2023, at 11:27 PM, Faisal, Manir wrote:
>
> Hello, Looks like live555 library natively supports 1.0 (RFC 2326) Is there
> any plan to port to version 2.0 (RFC 7826)?
Not at present - because almost nobody else has implemented RTSP 2.0. I.e.,
there would be almost no other RTSP
Hello,
Looks like live555 library natively supports 1.0 (RFC 2326) Is there any plan
to port to version 2.0 (RFC 7826)?
Regards,
Manir
The information transmitted by and/or attached to this email is intended only
for the person or entity to which it is addressed. This email and any
attachm
Hi,
Here is more information about the issue and an attached test program that is
able to reproduce the issue(s).
First let's define:
LT : LIVE555 thread
NT : non-LIVE555 thread
EH1 : EventHandler1
EH2 : EventHandler2
TAW : fTriggersAwaitingHandling
triggerEvent called but eventHandler is not:
