HMI camera widget grey: MJPEG vs RTSP and snapshot JPEG URLs

The line runs, the camera works in a browser tab and in a desktop player, and the HMI camera widget sits there grey. You have tried ports 80, 8080, 8000 and 554 and nothing changed. This guide is for controls and quality engineers wiring IP cameras, smart cameras and area scan cameras into HMI and SCADA screens. The port was never the problem: the widget is an image object, and it has been handed video. Work through the sections in order and you will identify the payload the camera actually sends, pick the URL the widget can render, set a poll rate with a bandwidth budget, and know when a converter is worth the build.

Why does the camera widget stay grey when the camera works everywhere else?

The widget is grey because it received a payload it cannot render: most HMI camera widgets draw MJPEG streams and single JPEG stills, and they cannot decode the RTSP H.264 video your camera sends, so no port number you try will change that.

Grey and black are different faults. Grey means the widget drew nothing, so the payload or the address is wrong. Black inside a loaded page means the page's own player failed, and that case has its own section below.

The ports were never the problem. TCP port 554 carries RTSP; ports 80 and 8080 carry HTTP. A widget that renders images cannot decode an RTSP payload over any port, which is why 80, 8080, 8000 and 554 all failed the same way.

Rank the causes by how often they end a ticket: an RTSP or H.264 feed handed to an image widget, credentials the widget cannot supply, an HMI server that cannot reach the camera, and pages that refuse to be embedded. Test in that order; the first one settles most cases.

For the sibling fault where the feed exists but the binding points at the wrong field, see the camera widget that shows no feed; an MJPEG viewer that shows no video is the same story one step later.

What can an HMI camera widget actually render?

Almost every HMI camera widget renders two things: an MJPEG stream delivered as multipart/x-mixed-replace over HTTP, and a single JPEG or GIF image at a URL it re-fetches on a poll rate you set in seconds.

Everything else needs a video decoder the HMI renderer does not carry: RTSP, H.264, H.265, WebSocket transports and ONVIF-negotiated streams. The same URL plays in a desktop media player and dies in the widget because the player owns a decoder and the widget owns an image renderer. An ONVIF profile negotiates streams between devices; it does not teach the widget to decode them.

The working requirement is a second feed from the camera: an MJPEG sub-stream, usually at reduced resolution, or an HTTP snapshot path that returns one JPEG per request. Nearly every networked camera with a web interface offers one or both among its stream settings.

For the widget-side configuration of both feed types, MJPEG and JPEG still streaming set-up for an HMI camera viewer walks through it end to end.

How do you test what the camera is actually serving?

Run three ten-second tests before touching the HMI: play the URL in a desktop media player, open it in a plain browser tab, and check the HTTP response header from the HMI server, because each test tells you the payload type.

1. Play the URL in a desktop media player. If an rtsp:// address plays, the camera serves RTSP and no widget setting will fix it; move on to the converter sections.
2. Open the URL in a plain browser tab. One static picture means you have found the snapshot path. A picture that updates by itself, with no player controls, is the MJPEG multipart stream, and the widget can take it directly.
3. Repeat the HTTP request from the HMI server, not your desk PC. A command-line request (curl is fine) to the snapshot URL should answer HTTP 200 with a content type of image/jpeg; the MJPEG stream answers with multipart/x-mixed-replace. Your desk PC succeeding while the server times out means routing or VLAN, not the widget.
4. Read the response headers before embedding a page. An X-Frame-Options value of DENY or SAMEORIGIN, or a frame-ancestors restriction, means the camera's web UI refuses to run inside a widget; the next section covers it.

Note where each URL came from: the snapshot path usually sits in the camera's web UI under its image or snapshot settings, and the MJPEG stream is normally a secondary stream type beside the H.264 main stream.

Two pages finish the polling side: grabbing images from an IP camera over an HTTP snapshot URL and snapshot polling of an IP camera still image on a timer.

Why does the camera's login page load but the video stays black?

A page that logs in but shows a black rectangle means the browser loaded the camera's HTML but cannot run its video: the page either forbids embedding, or its player asks for RTSP or a WebSocket the embedded viewer never opens.

Both failures live on the page side, not the network. The header case: the camera's web server sends X-Frame-Options or a Content-Security-Policy frame-ancestors rule, and the browser refuses to draw the page inside the widget. The decoder case: the video element asks for RTSP, a WebSocket or a browser plugin that modern embedded viewers removed, so the menus render and the picture area never does.

Either way, stop fighting the camera's web UI. Take its snapshot URL or MJPEG address and let the camera widget do the drawing. Refreshing an IP camera snapshot in an iframe without authentication errors handles the login half; embedding an IP camera stream in an HMI or SCADA window covers the layout.

For the decoder-side fault in detail, troubleshooting a black camera picture when an HMI plays an RTSP feed works through it case by case.

How do you stop a snapshot JPEG from freezing on one frame?

Append a query string value that changes every poll — the widget then treats the URL as new and fetches a fresh JPEG; without it, the client or an intermediate cache can serve the first frame forever.

Build that URL in the widget as text: constant base, separator, counter. Choose the poll rate from what the operator judges: 1 s is the workhorse for line status, 0.5 s for a fast cycle under an operator's eye, 2 s or more for tanks and passive corners. Below about 0.5 s the request itself — fetch, encode, transfer, typically 100-300 ms — becomes the limit, and you are asking for a stream, which is the converter's job.

Authenticate in the URL the HMI server polls. Most cameras accept credentials inline or offer an anonymous, read-only snapshot account, and because the server fetches once per interval for every open screen, the camera sees one client however many stations are watching.

Three pages close the remaining gaps here: snapshot URL refresh rates and set-up on an HMI, an MJPEG stream URL with username and password and what to check when an IP camera snapshot stops loading.

How much network bandwidth does each option cost?

Budget roughly 12 Mbps for a 1080p MJPEG stream at 15 fps, about 0.8 Mbps for the same camera polled once per second, and 2-4 Mbps for an H.264 RTSP stream — MJPEG costs three to six times the bandwidth of H.264.

The 100 kB frame assumes a 1920×1080 JPEG at typical camera web quality; a busy scene can double it and a still corner can halve it, so treat 12 Mbps as a planning midpoint. The 2-4 Mbps H.264 figure is the usual 1080p planning number at moderate motion. The ratio is the whole trade: RTSP uses little bandwidth on the wire and is impossible for the widget, MJPEG is expensive and renders natively, and the polled snapshot is nearly free.

The arithmetic bites twice: the network pays per stream, and an MJPEG stream also costs the HMI server rendering work that a snapshot poll does not.

Decision: snapshot polling for status and operator awareness; MJPEG at reduced resolution when 5-15 fps of motion matters; H.264 only through a converter.

When is an RTSP-to-MJPEG converter the right fix?

Add a converter when operators need full-motion video, roughly 10 fps or more with smooth motion; a small service on a PC pulls the camera's RTSP stream, decodes H.264, and re-serves MJPEG feeds the widget renders natively.

Run it on a machine that can already reach the camera; a server on the camera's VLAN is the clean spot. The converter holds one RTSP session per camera and publishes an MJPEG URL per feed, and every widget on every screen points at the converter instead of at the camera. Hand-written it is a small job — decode H.264, re-encode each frame as JPEG, serve the parts — and packaged converters do the same with less code.

Before building anything, run the snapshot poll for a week. Operators judging a jam, a misfeed or chute overflow do well at 1-2 fps, and most requests for video turn out to be requests to see one chute.

Converting an RTSP camera feed to MJPEG for an HMI viewer shows one worked set-up end to end. For the browser-side variant, see restreaming an RTSP stream for display in an HMI browser and showing an RTSP camera stream in an HMI through a snapshot URL or a media player.

How do you show a machine-vision camera image on the HMI?

Machine-vision cameras do not give the HMI a URL at all: a smart camera or GigE Vision area camera serves images to your integration over its SDK or a GigE Vision stream, so you grab frames in your own small service and re-serve them as MJPEG or JPEG.

The pattern is the converter pattern with the SDK in place of RTSP. Inspection stays on the camera or the vision controller, your service fetches the result image, and the widget polls it at the rate chosen above. Reading camera images from a PC through APIs covers the fetch, and bridging a GigE Vision camera's GVSP stream to RTSP covers the stream variant.

A smart camera fits this pattern directly, because inspection runs on the device and the HMI needs only the result picture. The LS-SMC-0063 is a 1.6 MP GigE smart camera with a 16 mm lens rated at 60 fps, and the MV-SC5060XM-08M-WBN is a 6 MP mono GigE smart camera with an 8 mm M12-mount lens over a 1/2.4" rolling-shutter sensor.

For frames from a larger sensor, a capture PC holds the GigE Vision stream and serves stills; the MV-CU020-90GC is a 2.5 MP color GigE camera with a 1/1.7" global-shutter sensor on a C-mount.

Start from smart cameras and area scan cameras, or filter the camera finder by interface and resolution.

What keeps the next camera widget from going grey?

Most grey widgets stay fixed when the payload type is written down: record each camera's snapshot path, MJPEG URL and RTSP address in the panel documentation, poll through the HMI server, and give every camera a reserved address so the widgets survive a reboot.

• Payload type per camera, written down — snapshot JPEG, MJPEG or RTSP-only; that one line decides the whole integration.
• A reserved address per camera — a DHCP renewal to a new IP greys that camera's widgets on every screen at once.
• Server-side polling — the HMI server fetches once per interval for all screens, keeping the camera at one HTTP client.
• A bandwidth budget per camera — 1 s at 1080p is about 0.8 Mbps; multiply by the camera count before sizing the link.
• A read-only snapshot account, not the admin login — the widget URL is readable by anyone who can open the configuration.
• A week of snapshot-only running before building a converter — it settles whether operators need motion at all.

When the picture on the screen should come from a machine-vision camera, the system configurator walks camera, lens and trigger choices in order, and the contact page puts the awkward cases to the applications team. The rest of the integration fixes collected here sit on the systems topic page.