jtanx
commented
11 years ago I should also note; one prospect that was briefly considered, but never used was mjpg-streamer, which can supposedly stream images from a webcam. This may be of use for the 'exploding can' video feed, which doesn't require the use of OpenCV.
However, this would have to run entirely independently of the current server software, which may/may not make things more complicated.
I suspect that this is because the driver (uvcvideo) will be using a producer/consumer style buffer to store frames which it continuously captures.
Passing images through FastCGI and then through a HTTP connection will be far slower than the driver can "produce" images, which may be the cause for the lag.
I suggest trialing an approach where a thread continuously takes images from the camera, stores them in a double buffer, and the most recent image is returned by Camera_GetImage. This requires adding an additional thread to the program dedicated to taking images (in a similar way to how the sensors continuously capture data points); currently images are captured as needed by the calling thread.
If this doesn't improve matters, it may be necessary to look into alternative methods for streaming images via nginx. Unfortunately whilst this may fix the lag when viewing images in a web browser, it will not solve any lag on the data points from dilatometers or other sensors which need to use OpenCV. It will also introduce yet another external dependency.
Investigating how uvcvideo actually works and "fixing" it is likely to turn into a research project all by itself.