❔ Producer Consumer ISourceBlock<T>, periodically flushing consumed data

Hi, I've the following scenario: I've a camera continuously acquiring frames and a c# app receiving it and storing it in a
List<MemoryStream>
List<MemoryStream>
. Once per minute, the memory stream is copied, passed to a task in charge of rendering a video file from such frames, and then emptying the original stream in order to use it for consequent frames. Now I'm trying to perform video rendering in real-time, as frames are received by the program. I've seen this guide from Microsoft about using
ISourceBlock<T>
ISourceBlock<T>
to implement a buffer that can be used in a producer-consumer scenario. This is good for me, since I can have a task receiving data from the camera and producing data in the buffer and a parallel task consuming data from the buffer. The problem is, once per minute I need the rendering task (the consuming one) to finalize the video file it has been adding frames to. At the same time, I need the producer task to continue producing frames, in the same buffer or in a different one. In order to accomplish this, the only way that came up to my mind is the following: 1) when the producer start producing data belonging to a new video file that's supposed to belong to a new video, it starts a new task, passing to it bufferA. The consumer will start consume data as it is produced. 2) when the producer has produced all data related to the video file that is being parallely rendered, it calls
ITargetBlock<T>.Complete()
ITargetBlock<T>.Complete()
to notify the consumer that frames for this video have finished and it needs to finalize the video rendering. 3) then the procuder will continue producing data, this time putting it in a bufferB. 4) rendering of frames in buffer B is completed 5) buffer A is cleared and producer start filling it again etc...
2 Replies
alkasel#159
alkasel#159OP2y ago
The idea is the producer task would use two buffers alternatively, since it cannot "dispose" a buffer as long as the consumer has not finished using it. Anyway I think this approach is not the best, and it feels a bit dirty. Furthermore, if the rendering task is too slow, in step (5) the produced could clear the buffer before the consumer has consumed it all. How can I do something better? up
Accord
Accord2y ago
Looks like nothing has happened here. I will mark this as stale and this post will be archived until there is new activity.
Want results from more Discord servers?
Add your server