Sektor van Skijlen

Yes, that problem has popped up at the time when this mechanism was created; although its unfortunate influence on the receiver worker queue of the listener holder, this is considered...

This can be actually simple - the session ID doesn't have to be actually encrypted, if the application makes sure that this is set on the connection run by exactly...

Exactly. If any lengthy things should be done in order to get the user data, and the required passphrase, it can be prepared at this moment, cached under the session-id...

I don't think so. In Rendezvous mode you also don't know which party will be setting the streamid, that's why the streamid itself is not recommended to be used for...

If you think about having a signaling server in the form of SRT listener in order to allow both behind-NAT clients to connect to one another, then the only streamID...

The filesrc element doesn't make a live stream from the read source. `sync=true` is likely required in one of the elements, not sure in which one in your case (sorry,...

This is the error that is reported by the call to `srt_send` in non-blocking mode when sending was no longer possible due to full sender buffer. This is usually the...

Refactoring is always good, but this is a more general problem. This should be fixed completely differently - the logic of the handshake processing should be focused in one place...

A similar thing has been already introduced for the use of group locking - the `apiAcquire` and `apiRelease` pair and the scoped wrapper for it `GroupKeeper`. This is currently built...

The "shared resource" type is introduced exactly in order to not lock mutexes guarding the container access in order to run some longer procedure on an object contained in this...