Display an RTSP surveillance stream on an industrial HMI

You need a live picture of the cell on the controller's HMI: the operator glances at a tile instead of walking to the machine. This guide is for the controls engineer choosing that camera, wiring it into a cabinet network that already carries vision traffic, and landing a stable picture on the panel. The decision up front: a standard network (IP) camera streamed over RTSP does the surveillance job, and a machine-vision camera driven through an acquisition API does not. What follows are the latency to expect, the PoE wiring, the decode budget, the set-up steps and the checks that prove the picture before sign-off.

Which camera should feed an HMI surveillance view?

Use a standard network (IP) camera that streams H.264 over RTSP at 1080p and 15-25 fps, and leave the machine-vision cameras out of it: an RTSP camera serves many viewers across the network for roughly 2-6 Mbit/s per stream.

A machine-vision camera is built for a different contract. It sends uncompressed pixels, one viewer at a time, through a driver and acquisition library on the displaying machine — a 1080p model at 30 fps moves 498 Mbit/s, half a GigE link for a single window. An H.264 surveillance camera compresses the same scene to about a hundredth of that, and any device with a media player can render it.

A fixed 1080p bullet or dome body covers a cell overview, and PTZ buys nothing unless an operator has to steer. Set the encoder to 1920x1080, 25 fps and about 4 Mbit/s variable bitrate in the camera's web interface; that is the whole configuration.

What end-to-end latency will you actually see?

Plan for 0.5-2 seconds between an event in the cell and it appearing on the HMI, because the camera buffers frames, the decoder holds a 200 ms jitter buffer to stay stable, and the HMI widget adds its own render queue.

The delay is a chain of buffers: encoder, network, player jitter buffer, widget render. The jitter buffer dominates. Keep the decoder's input buffer near its 200 ms default — the rtspsrc latency property in a GStreamer-based pipeline — because public embedded-decoder testing shows 100 ms dropping frames at 25 fps. Cut the buffer below what your decoder sustains and the picture stutters instead of sharpening.

The first two routes are covered in displaying an RTSP camera stream in an HMI with a snapshot URL or VLC and restreaming an RTSP stream for display in an HMI browser. Browser panels pay a conversion tax: converting RTSP to HLS for a panel's web video widget walks the full path.

How do you wire and power the camera network?

Run one Ethernet cable from the camera to a PoE switch and a second from the switch to a spare controller LAN port; IEEE 802.3 allows 100 m per copper run, and PoE carries up to 15.4 W per port, enough for a fixed camera.

Give the camera its own subnet and its own controller NIC: for example 192.168.40.0/24 with the camera at 192.168.40.10 and the controller's second port at 192.168.40.1. Without PoE, size a 12 V DC supply from the camera's draw — a fixed 1080p camera takes about 5-10 W, rising to roughly 25 W once infrared LEDs and a heater run — so a 12 V 2 A supply (12 × 2 = 24 W) carries one camera with margin.

For a cabinet-to-camera run inside 15 m, a ready-made RJ45 camera cable with locking studs survives vibration better than a bare snap tab:

Longer runs stay inside the 100 m copper limit with standard Category cable; the camera cables category lists lengths from 1 m to over 20 m.

How much controller do you need to decode the stream?

One 1080p H.264 stream decodes comfortably on an entry controller with an Intel N-series processor, 8 GB of memory and integrated graphics; plan two to four streams before you move up to a Core i5 class machine with more LAN ports.

The decode itself is light work on modern silicon: integrated Intel graphics handle H.264 in a fixed-function block, so the CPU cores stay with the HMI runtime. Software decode works on a Core i3-class chip for a single stream; hardware decode leaves headroom for a second tile. For one stream the entry tier is enough:

The MV-VC2140-128G40-1T pairs an Intel N97 with 8 GB of memory, 3-4 LAN ports and 2 USB 3 ports, and the LAN port count is the quiet argument for a vision controller as the host: camera subnet, vision subnet and plant network each keep a port. Beyond four tiles, or once the same box also runs vision software, step up a tier — the vision controllers category lets you compare LAN port counts, PoE and memory across series.

Which steps put the stream on the screen?

Eight moves get it done: isolate the camera on its own subnet, set its encoder, run cable through a switch, prove the RTSP URL in a desktop player, then add a viewer widget or snapshot element to the HMI and measure what you got.

1. Isolate the camera. Set 192.168.40.10/24 on its own controller NIC, never on the GigE Vision subnet.
2. Set the encoder. H.264, 1920x1080, 25 fps, about 4 Mbit/s, keyframe interval 1-2 s. Note the exact RTSP path the camera's stream page prints: TCP port 554 is standard, the path after it is per brand.
3. Cable it. Camera to PoE switch to a spare controller LAN port.
4. Prove the URL at a desk. Open the stream in a desktop player before touching the panel. If it stutters, raise the player's caching setting in 100 ms steps until smooth; 200 ms is a common stable point.
5. Add the viewer widget. Use the HMI runtime's native RTSP element — showing a camera live stream in an HMI web viewer widget covers the layout. Where a platform's viewer lists format limits, RTSP support limitations of a SCADA IP camera viewer shows what one mainstream runtime refuses before you commit to it.
6. Or poll snapshots. Where the panel only accepts images, poll the camera's JPEG snapshot URL every 0.5-1 s and accept the loss of motion.
7. Enable auto-reconnect with a 10 s ceiling, so a camera reboot heals itself.
8. Run the sign-off checks below before you call the job done.

How do you prove the picture is good before sign-off?

Point the camera at a running stopwatch and read the difference between the stopwatch face in view and the same face on the HMI: on a healthy 1080p H.264 path that gap lands between 0.5 and 2 s, and reconnects complete inside 10 s.

Then check three things. Motion: wave a hand through the view and confirm smooth 25 fps movement without tearing. Recovery: unplug the camera cable for 10 s and watch the tile come back on its own inside the next 10 s. Bandwidth: switch port counters sit near 4 Mbit/s per stream, with no broadcast spikes on the vision subnet.

If the cell needs footage kept, recording a camera feed for inspection traceability is a software job on the same controller. Reading codes off the live picture is possible too — decoding barcodes from a live RTSP or MJPEG stream works for traceability scans, not for measurement.

When is this the wrong camera for the job?

The moment the picture has to trigger a decision — part present, dimension, robot guidance — RTSP is the wrong transport, because 0.5-2 s of variable latency cannot timestamp a frame against a machine event; a GenICam machine-vision camera takes over there.

Spec a GigE Vision or USB3 Vision camera acquired through GenICam: frames arrive in under 100 ms, uncompressed, with a hardware trigger line, and the HMI can still show that feed. Bridging a GigE Vision camera to RTSP for an HMI covers exactly that split, and connecting a GenICam camera to an industrial controller over Ethernet starts the acquisition side.

One box can host both halves when you size it for the larger job:

The MV-VC5525-256G70-NN pairs a 12th-gen Intel Core i5 with 32 GB of memory, PoE camera ports and 5+ LAN ports, so surveillance, vision and plant networks each keep a port. Start sizing at the vision controllers page, and questions about a specific cabinet reach the applications team through the contact page.