Reducing mjpg-streamer delay


Hi all,

I just started working with mjpg-streamer and I'm trying to figure out how to reduce the constant delay in the video. I can do anything from 640x480@30fps up to 1280x720@20fps with no problems, but at any resolution and any framerate, there is always about a 1.5 second delay. Any suggestions on how to reduce that?



Our of curiosity, as you seeing any correlation on either the beaglebone CPU or your laptops browser processor utilization? I ask because either could be contributing to delays. We have noticed that video is a lot choppier on older laptops... the mjpeg video display via the browsers is not terribly efficient.


How would I check that on the beaglebone? I have zero experience with linux command line. My laptop isn't bogged down at all and CPU utilization is very low. Only a few percent due to the video.

Video is always extremely choppy in browsers, again at every resolution, every framerate. I've been using VLC because it runs smooth as silk.


If you have a more recent version of the Cockpit software, it has the % displayed on the bottom of the screen. Alternately, if you login to the beagle you can run the 'top' command (ctrl-c or x to exit). It shows all of the running processes that you can add up to get rough %cpu used.

On the server, we tend to use the development build of chrome as they have the gamepad support. On a fast computer, the video should be smooth, but it does chew up a core as the video does not tend to work across multiple cores when using a browser. (In task manager you would see a browser process using 25% cpu on a 4 core processor).

I'll do some more testing, but interestingly enough, when I was using the browser and VLC side by side, VLC has a noticeably longer delay.


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?


So I've tested it out, and it looks like it is 100% Chrome/VLC's fault. Chrome and VLC both have a 1.0-1.5 second delay, and Firefox/Safari have a 0.1-0.2 second delay. Good to know. Thanks. I'll have to check out other browsers and see if any others are even faster.


I'm interested in tinkering with mjpg_streamer as well but don't know where to get started. I assume there is a script that launches it on startup, but I don't know where to look. Any direction that would help get me started would be greatly appreciated.


As of 2.5RC2, the code uses a significantly improved video technique for the browser. If you are running in to lots of video latency, I recommend upgrading to at least this version first:


Take a look at this file. I have highlighted where it sends the options to MJPEG streamer.


Hi Brian.

I have some questions about the camera, and I hope you can help me out.

What is the std fps rate and camera latency seen in a standard build?

My problem is that i don't seem to be able to get a higher fps then 2...
Actually, on my laptop I never get more then 1.8, it's a "crappy" budget series Compaq.

I've also tried it my sons laptop, a gaming laptop with I7 core
and 8gb Ram and he's the one that got 2 fps...

Other results/settings that my be interesting... Cpu load, from cockpit, is between 35 and 45. Latency is between 50 and 150. All of these numbers is from my laptop, the only difference on my sons laptop is that the latency is "never" above 10...

I've read "all" the posts i could find on the issue and I'm surprised that there isn't more ppl asking questions about this. This has led me to believe that it's a local problem with my ROV. Except that I get the exact same results on both of my ROV's,.. I've an "older" 2.6 and a brand new 2.7. The 2.6 is Eric's old ROV and it has the same setup now that it had when I bought it in January.

I hope you can tell me more on this subject.


PS. For those of you that didn't know it you can get the fps's when clicking on the
latency "meter", you can alternate between latency and FPS.


Hi again Brian, and others.

I might be barking up the wrong tree here...

When you click on the latency field it changes into a field called FPS, what is that?
I supposed that it was framerate, but I might be wrong on this.

I had my ROV out for a test drive today, and it dawned on me that the framerate couldn't be as low as 1.8, based on the art of observation and reason... ;-)

I've searched all over the forums and dozuki but I'm unable to find a good source of documentation on the OSD, HUD or GUI...

Anyone able to help me out here?



Hey Peter,

There are two latency counters on the page.

At the bottom right, by default is shows the time in ms from the point the browser sent a request to the the beaglebone on the ROV and the beaglebone's node.js process then responds back to it. We see that time as low as 6ms, usually around 20ms. There is another counter that you can activate that will add a FPS counter to the top left of the screen. Now, this FPS counter is counter is a little misleading, it is trying to do a javascript task 30 times per seconds and shows what is is actually able to go get. If that is below 30, it indicates the local laptop or computer is struggling to keep up.

The actual framerate is currently targeting 10fps. However, I do have a sense that sometimes that is not being achieved. I have some ideas on how to add a true FPS count for the screen... may work on that today.