Closed king-shak closed 4 years ago
Here is a histogram of the capture times after implementing the solution described above. The fix will be coming in a PR soon with some others.
This is done, will come in the next commit which should fix some other issues currently open.
I kinda messed up pushing my branch to git - but master now has the fixes for this issue and #2
The way the capture thread currently works (checkout out the ProcessOutput class) is when it receives a frame, it checks an event to see if the processing thread (see class Pipeline) is done processing the last frame and waiting on another time. If the pipeline is not ready, it'll drop the frame and wait on the next one. The issue is that we're dropping about 33% of frames because some frames come quicker than others, leading to a synchronization issue. The proposed fix is to re-implement ProcessOutput so that it'll use double buffering to provide the Pipeline with the frames. And no events - the Pipeline will acquire a lock whenever it wants to read a frame, and ProcessOutput will acquire that same lock whenever it swaps the pointers.