This is what I am currently tinkering with, too. So I want to share what I found so far regarding the video delay. It turns out that depends on
a) the performance of the computer running the browser
b) if the video has to be scaled in the browser, the delay increases
c) the browser used
(in this order). The mjpeg streamer on the beaglebone seems not to produce a significant delay.
When I run the cockpit software on my Atom powered netbook, there is significantly more delay than when I run it on my Core i7 laptop (both Windows 7). The delay decreases on both machines when the video is shown in its original size instead of beeing scaled up or down by css properties of the video frame in the cockpit html (this also reduces processing load and prolongs battery life of the computer).
Finally, using the high performance laptop and a no-scaling html/css, I noticed that the video delay is almost zero when I use Firefox (this implies that the mjpeg streamer does not add delay on the beaglebone). The dealy is only noticeable e.g. if you move your hand VERY fast in front of the camera. With Chrome, there is slightly more delay (maybe some 100ms) and also more flicker.
Since I never got my gamepad working with one of the Firefox game-api enabled nightly builds, I'm now thinking of splitting up gamepad control an video into two separate html files, showing the video with Firefox and controlling the ROV with Chrome.
The most convenient way however would be to show the video in VLC (which I run anyway to record the mjpeg stream) instead in the browser, but I never managed to reduce the latency enough when using VLC. Anyone who had success with that?