around the time of the failures to read frames documented in another issue, the total system memory use was up to 6gb on a jetson xavier running two streamlight containers. Restarting both streams dropped the total system memory use down to 1.5gb. Until that point, the containers had been running for just 2hrs, and they have run for much longer in the past.
things to investigate:
- size of the frame queue from which the worker threads read frames. If this queue is not being drained quickly enough, we can just increase the number of workers which is currently set at one thread per requested FPS
- does this occur as well with youtube streams? only observed in rtsp thus far
around the time of the failures to read frames documented in another issue, the total system memory use was up to 6gb on a jetson xavier running two streamlight containers. Restarting both streams dropped the total system memory use down to 1.5gb. Until that point, the containers had been running for just 2hrs, and they have run for much longer in the past.
things to investigate: