Unsure if the following is expected behaviour, but I doubt it is.
Reproduce:
- Start
voxl-streamer listening to hires_front_small_encoded
- Connect to the stream (e.g.,
ffplay -i rtsp://<voxl ip>:<port>/live)
- Confirm that the stream looks good
- Disconnect from the stream (CTRL-C the
ffplay command)
- Within 60 seconds, re-run the same
ffplay command
- Observe that the stream looks good but will freeze within 60 seconds (e.g., the command is restarted 15 seconds after initially closing the connection. The new stream will freeze after 45 seconds
- Observe that
voxl-streamer outputs Removed 1 sessions
- Disconnect from the new stream (CTRL-C
ffplay)
- Observe that
voxl-streamer outputs Removed 1 sessions again after 60 seconds
Based on behaviour and source code, what I think is happening:
When the first connection is closed, voxl-streamer detects this and decrements the number of clients. However, it takes 60 seconds for the gstreamer session to time out and close. During this time, if another client connects, there are now 2 gstreamer sessions and 1 voxl-streamer client. 60 seconds after the first connection is closed, the inactive gstreamer session is cleaned up. Since voxl-streamer doesn't know that this session was already inactive, when it closes, voxl-streamer decrements its number of clients even though the one client it has still has an active gstreamer session.