Closed karrih closed 11 hours ago
Hi,
I have a question about the frame buffering logic. It seems that the application can set maximum capacity for the queue when constructing rtc.VideoStream:
video_stream = rtc.VideoStream(track, capacity=1)
This is useful, since I consume frames at a slower rate than what the video track produces, and I only want to sample the latest video frame at each iteration. But it seems that the frame events themselves originate from the following _ffi_queue, which in turn is not capped: https://github.com/livekit/python-sdks/blob/c19f24a88a73d8e28e141b96fb2dca328d092a8d/livekit-rtc/livekit/rtc/video_stream.py#L71
_ffi_queue
Does this mean that even with capacity=1, my app may theoretically incur an arbitrarily large delay due to the internal buffer growing in size?
Hi,
I have a question about the frame buffering logic. It seems that the application can set maximum capacity for the queue when constructing rtc.VideoStream:
video_stream = rtc.VideoStream(track, capacity=1)This is useful, since I consume frames at a slower rate than what the video track produces, and I only want to sample the latest video frame at each iteration. But it seems that the frame events themselves originate from the following
_ffi_queue, which in turn is not capped: https://github.com/livekit/python-sdks/blob/c19f24a88a73d8e28e141b96fb2dca328d092a8d/livekit-rtc/livekit/rtc/video_stream.py#L71Does this mean that even with capacity=1, my app may theoretically incur an arbitrarily large delay due to the internal buffer growing in size?