Why an MJPEG stream slows HMI pages: stream vs snapshot URL

An HMI page that showed one camera now crawls: the picture freezes, and every tag on the page stops refreshing. The usual cause is not the network and not the HMI — it is the URL in the camera gadget. A stream URL keeps a connection open and pushes JPEG frames continuously; a snapshot URL returns one JPEG and closes. This page is for anyone wiring camera views into HMI or SCADA screens. You will learn to tell the two URL types apart in a browser, compute what each costs per gadget, and set a refresh period that keeps the picture live without stalling the tags.

Why does one camera gadget slow the whole HMI page?

The gadget is pointed at a stream URL, so the camera pushes a new JPEG on one open connection 10-30 times per second; a snapshot URL sends one JPEG per refresh and closes, which at a one-second period is roughly 15× less data and 15× fewer decodes.

MJPEG is the format most HMI camera widgets speak: every frame travels as its own complete JPEG, one after another, on a connection that never closes. A snapshot endpoint is the other thing an embedded camera usually exposes: one request, one JPEG, connection closed. The URL decides, not the gadget — point an image gadget at a stream path and it faithfully pulls every frame the camera sends. Multiply that by every gadget on every loaded page, and the client has nothing left for its tag loop.

How do you tell a stream URL from a snapshot URL?

Open the URL in a plain browser window with nothing else running: if the image keeps updating forever and the tab never finishes loading, the URL is a stream; if one JPEG appears and the transfer ends, it is a snapshot.

Run that test on every camera URL in the project before you touch the HMI, because one wrong URL undoes the rest. Stream paths tend to announce themselves by name — a video, mjpeg or stream CGI — while a snapshot path answers once with an image and stops. Cameras that offer a stream almost always offer a still-image path too; find it in the camera's own web interface or manual. If RTSP addresses are all you were given, find the MJPEG CGI URL when RTSP fails shows where the real paths hide. To fetch the still image from your own code instead of a gadget, grab images over an HTTP snapshot URL covers the request and its failure modes.

What does each choice cost in bandwidth and decoding?

At VGA size a camera JPEG lands near 30 KB, so a 15 fps stream costs 3.6 Mbit/s per gadget while snapshot polling once per second costs 0.24 Mbit/s — fifteen times less data and fifteen times fewer JPEG decodes on the client.

Worked example, one 640×480 gadget at default camera quality: 640 × 480 = 307,200 pixels, and a default-quality JPEG lands near 30 KB, about 0.8 bit per pixel.

• Stream at 15 fps: 30 KB × 8 = 240 kbit per frame, and 240 × 15 = 3,600 kbit/s = 3.6 Mbit/s, with 15 JPEG decodes per second on the client.
• Snapshot polled every second: 240 kbit ÷ 1 s = 0.24 Mbit/s, one decode per second.
• Five gadgets on five loaded pages, streaming: 5 × 3.6 = 18 Mbit/s and 75 decodes per second. Polling: 5 × 0.24 = 1.2 Mbit/s and 5 decodes per second.

Resolution and quality move the number fastest. The same five pages fed by 1080p streams — a 1080p JPEG runs 100-250 KB, call it 150 KB — cost 150 × 8 × 15 = 18,000 kbit/s = 18 Mbit/s per gadget, and 5 × 18 = 90 Mbit/s across the page. That saturates the 100 Mbit/s ports common on HMI panels, and the tags then compete with video for what is left.

Why do the HMI tags stop updating too?

The tag update task and the camera gadgets share the same client: continuous JPEG decoding and a pile of open connections starve the page's update loop, and a camera that caps concurrent clients can stall gadgets so hard the page stops servicing its tags.

Work down this list, most likely cause first:

1. Wrong URL — a stream where a snapshot belongs. The browser test above settles it in a minute per camera.
2. Concurrent-client limit on the camera. Embedded web servers serve a fixed handful of viewers; open the same snapshot URL in two browser windows and watch whether the second stalls.
3. Link saturation. Real only with HD streams or 10/100 Mbit segments; compare your page against the table above.
4. Client decode or memory exhaustion. Watch the panel client's CPU while the page loads; if a plain browser renders the same URLs faster, the runtime is drowning in decodes, which why MJPEG viewer CPU usage runs high explains.

Tag traffic itself is tiny next to video, so stalling tags point at the client or the camera rather than the wire, unless HD streams are on the page. SCADA clients add a widget layer with its own URL quirks; the SCADA IP camera MJPEG stream configuration troubleshooting guide covers those checks.

What refresh period should a snapshot gadget use?

Poll once per second: a 30 KB VGA snapshot then costs 0.24 Mbit/s per gadget, the picture feels live to an operator, and the camera serves one short request per second per viewer — a load embedded web servers handle easily.

A 500 ms period doubles the cost to 0.48 Mbit/s per gadget; a two-second period halves it to 0.12 Mbit/s. Choose by what the operator must catch: a tank level or a gate reads fine at two seconds, and anything faster than the eye needs belongs to the vision system's result, not to a picture on the page. Tags are a separate knob — HMI tags commonly refresh each second and drop to 100-200 ms where logic watches a value — so let the tags carry measurements and keep the picture at human speed. When polling still looks slower than the period you set, why the snapshot update period looks sluggish lists the camera-side causes, and polling a still image on a timer shows the refresh mechanics end to end. For image-gadget URL errors on the HMI side, resolving IP camera viewer URL and stream errors walks that client's cases.

When is a stream the right choice?

One stream is fine when one operator watches one view full-screen and needs motion: 3.6 Mbit/s and 15 decodes per second fit any modern client — the failure mode starts at two or three streams on a page or several pages held open at once.

• Motion matters, one viewer: keep the stream, one per client, and budget 3.6 Mbit/s at VGA.
• Overview or monitoring: snapshot poll at one- to two-second periods; five gadgets cost 1.2 Mbit/s combined.
• The camera only speaks RTSP: an HMI image gadget cannot play it directly; a restreaming gateway converts it, as restream an RTSP stream for display in an HMI browser lays out.
• Someone wants to measure from the picture: that is the vision system's job, and the HMI should read the result instead.

What is the fix, in order?

Work through the page in this order: verify each URL in a browser, switch gadgets to the snapshot endpoint, set one-second periods, measure the returned JPEG, count loaded pages, then reload and watch the requests settle.

1. Open every camera URL in a plain browser, one at a time, and keep only the ones that return a single JPEG and end loading.
2. Point each gadget's image URL at the snapshot endpoint and set the refresh period to one second.
3. Save one returned JPEG and read its file size, then recompute the budget: size in KB × 8 ÷ period in s = kbit/s per gadget, multiplied by loaded gadgets.
4. Count loaded pages, not visible pages. If the HMI rotates pages automatically, stagger the switches by at least the refresh period.
5. Reload with the browser's request log open: each gadget should fire one short request per period, and tag values should resume.
6. Where one view must show motion, allow exactly one stream per client and leave every other gadget on snapshots.

How do you keep the page fast afterwards?

Re-run the browser test after every camera, firmware or page change, keep the combined snapshot budget in single-digit Mbit/s, and let one stream per client be the absolute maximum.

A tenth of the client's link is a good ceiling — single-digit Mbit/s on the 100 Mbit/s ports common on HMI panels — because it leaves the decodes and the tag traffic room to run. When a snapshot endpoint stops answering altogether, why the snapshot stops loading and how connection limits cause it walks the fixes. And after any camera firmware or quality change, save a snapshot and re-read the file size: a quality bump that takes the JPEG from 30 KB to 90 KB silently triples the page budget, from 0.24 to 0.72 Mbit/s per gadget at that period.

Which camera should feed an HMI page?

If the picture exists to show an inspection result, put a vision sensor on the job and read its verdict over the network as data, because a result line costs bytes and refreshes with the tags instead of pulling video.

A smart camera or vision sensor inspects on the device and hands the verdict to the network, so the page carries tag traffic instead of video. Smart cameras range from compact sensors upward:

When the station needs several cameras but the HMI should show one outcome, vision controllers gather the cameras on their LAN ports and present a single result to the network. The MV-VC3301H-128G66 pairs an Intel Core i3 processor with 8 GB of memory, a 128 GB SSD and 5+ LAN ports, with the vision software license included.

The decision per case: monitoring views go on one-second snapshot polls, the one motion-critical view keeps a stream with one client, and inspection points get a vision sensor whose result the HMI reads. To pick the camera side, start at the camera finder, walk the chain in the configurator, or browse more systems guides for the integration around the page.