Display an MJPEG stream in an HMI screen

You have an IP camera watching a machine, a queue or a loading zone, and the operator needs to see it on the HMI screen next to the line status. Most SCADA and HMI runtimes on Windows draw screen objects through an embedded browser engine that is far more limited than a desktop browser, so the usual failure is a frame showing a login page, one frozen picture, or nothing at all. The reliable path is to point the display object straight at the camera's MJPEG-over-HTTP stream URL instead of the camera's web page. This guide shows you how to find that URL, wire it into a screen, size the stream against the network, and which fallback still works when the runtime cannot render motion.

What an HMI can actually render

MJPEG over HTTP is the simplest moving picture a camera can serve. The response is a single never-ending reply with the content type multipart/x-mixed-replace, and a complete JPEG image follows each boundary marker. A display object that understands it replaces the picture again and again, which reads as video.

Whether the runtime understands it comes down to the browser engine it embeds. Engines built on Internet Explorer draw only the first JPEG frame and need a plugin for motion, while Firefox and Chromium-based engines play the stream as delivered (Motion JPEG). That is why one SCADA version shows live video and an older build on the same network freezes — the camera and the URL did not change.

RTSP with an H.264 payload is a different protocol, not an image format a frame object can load. An RTSP address in an image object draws nothing; it needs a media player component or a restream into MJPEG or stills, which the RTSP display guide covers. For the wider embedding context — screen layout, several cameras, security zones — see Embed an IP camera stream in an HMI or SCADA window.

What you need

• The camera's IP address and a viewing account with read-only rights — create one now rather than reusing the admin login
• The stream paths from the camera's settings page or manual: one Motion JPEG path and one JPEG snapshot path
• A desktop browser on the same network, to test addresses before they go into screens
• One screen in the HMI project with a frame, image or web-view display object on it

Point the display object at the MJPEG URL

The steps below take ten minutes on a bench and end with motion on the screen.

1. Log in to the camera's web page with the viewing account, open its live view, and note the address that actually updates. The live-view page usually embeds the stream URL; the viewer shows no video guide walks through separating the real stream from the page around it when the obvious address turns out to be the page, not the stream.
2. Paste the stream URL into a desktop browser on its own. A working Motion JPEG URL fills the tab with a continuously refreshing picture and asks for the login once.
3. Confirm what is being served: the browser's developer tools, on the network tab, should show a content type of multipart/x-mixed-replace on the long-running request. That one line is the difference between motion and a frozen first frame.
4. In the HMI editor, place a frame, image or web-view object on the screen and set its source or link property to the full stream URL: scheme, address, port if it is not 80, and path.
5. Supply the viewing account the way the runtime expects, from its own connection settings rather than inside the URL where that is possible. If the runtime never offers a login and the picture stays blank, the HMI browser authentication guide covers why URL logins fail in embedded browsers and what to configure instead.
6. Run the screen in runtime mode, not the editor preview, and watch for a minute: frames should arrive at the frame rate the camera is set to, with no lag that grows over time.
7. Check the load on the switch port that feeds the screen node. It should land near the prediction in the next section; a port running several times higher means one tile is pulling full resolution.

In a tag-based SCADA platform, the same two addresses — Motion JPEG for motion, snapshot for stills — are what the MJPEG and JPEG still streaming setup guide wires into screens and clients.

Size the stream to the network

formula
frame bytes ≈ width × height × 3 / compression ratio
stream rate ≈ frame bytes × 8 × fps (bit/s)

Both inputs are camera settings: the JPEG quality sets the compression ratio, and 10:1 to 25:1 covers the range cameras actually offer. Measure one frame from your own camera — its settings page or the stream headers print the size — then scale linearly from there.

Scaling rules: halve the frame rate and the rate halves; double width and height together and the bytes go up four times; tighten quality from 15:1 to 25:1 and the same frame drops from 61 kB to 37 kB. The expensive direction is resolution: a 1920 × 1080 stream at 15 fps and 15:1 is 6,220,800 / 15 ≈ 415 kB per frame, which lands near 50 Mbit/s — half of a 100 Mbit/s uplink for a single tile.

Decision: keep operator overview tiles at 640 × 480 and 5–15 fps, under about 6 Mbit/s each, so four tiles cost around 22 Mbit/s and fit a 100 Mbit/s video VLAN with room to spare; the multiple streams on one screen guide covers the layout side. Reserve 1280 × 720 at 15 fps — 2,764,800 / 15 ≈ 184 kB per frame, about 22 Mbit/s — for one view where detail matters. On a link shared with office traffic or reached over a VPN, drop to snapshot polling from the next section.

When the runtime will not render MJPEG

If step 2 moves in a desktop browser but the frame in the runtime holds one frozen picture, the embedded engine is the limiting part, and you still have three working paths.

1. Snapshot polling. Point the same display object at the camera's JPEG snapshot URL and refresh it on a timer from a tag or a short script, adding a changing query parameter so the engine does not show a cached picture. A 61 kB snapshot at 1 Hz is 61,440 × 8 ≈ 0.5 Mbit/s per camera, so this is also the right answer on shared links and VPNs. The snapshot polling guide shows the timer pattern and the snapshots versus streams guide helps choose per screen.
2. A video player object. Screen platforms that deliver screens to a browser increasingly ship a player component that takes camera addresses directly; the video player component guide shows one connected to a live stream.
3. A restream. For cameras that only speak RTSP, a small restreamer on a line PC can translate the feed into Motion JPEG or periodic stills the runtime can load; the RTSP restream guide covers the set-up.

Motion costs runtime attention as well as bandwidth: a moving tile redraws continuously. If screens get sluggish as tiles go up, the MJPEG viewer CPU guide explains where the time goes and the stream versus snapshot performance guide compares both paths on real pages.

If the camera on the screen is an inspection camera

Everything above assumes a camera that publishes HTTP streams, which monitoring cameras do and machine-vision cameras generally do not. A GigE Vision or USB3 Vision area scan camera sends frames over GenICam to acquisition software; there is no address an HMI frame object can load, and the picture belongs in the vision application's own operator view.

When one device must deliver both the verdict and the picture, the tidy answer is a smart camera: inspection runs on the device and the HMI reads the result over the plant network. The MV-SC3050XC-16M-ATN-H vision sensor runs the inspection on its 5 MP global-shutter sensor and connects over Fast Ethernet.

For a station that needs its own illumination, the LS-SMC-0063 integrates a white light with polarized and transparent modes behind a 16 mm lens, running 1.6 MP at 60 fps, and the MV-SC5060XM-08M-WBN moves up to a 6 MP mono sensor on an 8 mm M12-mount lens over GigE.

Many smart cameras and vision sensors also serve a browser page for local viewing — the vision sensor browser display guide shows how to reach it, and the stream address behind that page is exactly what step 4's display object takes. Where the picture lives only in the camera's client software, show the inspection result on the HMI instead of the video — the verdict is what the operator acts on.

Common mistakes that cost an afternoon

• The object points at the camera's home page. You get the login page or a frozen banner instead of motion. The object wants the stream URL from step 1, not the web UI.
• RTSP arrives at an image object. An H.264 stream will never draw in a frame; route it through a player component, a restream or the snapshot URL.
• A proxy or recorder sits in front of the camera and re-chunks the multipart stream, and the object renders broken or half-drawn images; the two SOI markers guide shows what that looks like in the bytes.
• Six tiles at full resolution. 1080p tiles at 15 fps run about 50 Mbit/s each and one screen empties a 100 Mbit/s link; drop tiles to 640 × 480 or poll snapshots.
• The stream works at the bench and not in the cell. A different subnet or VLAN between the bench PC and the camera is the usual reason — check routes before blaming the screen.

If the frame still shows a login page or a frozen first frame after all of this, the SCADA camera stream configuration troubleshooting guide works the usual causes in order.

Where to go next

Set up this way, the screen carries a live picture that survives shift changes and runtime upgrades, and you know its cost on the network before it goes live. If the camera side is still open, the camera finder filters by interface, shutter and sensor, and the camera step of the system configurator walks the whole chain from sensor to screen. More HMI and streaming articles live under the systems topic page, and the team answers integration questions through the contact page.