A camera image inside an HMI window forks the project the moment you ask for it: point an image or web widget at the camera's HTTP snapshot URL and refresh it on a timer, or embed a media player that pulls the camera's RTSP stream. The two routes differ in what an operator can judge, in the bandwidth the link carries and in the CPU the client spends decoding. This guide gives the decision rule with the numbers behind it, the wiring steps for both routes, a worked bandwidth example and the checks that catch failures before go-live.
The decision: motion or a status check
Ask one question: must the operator judge motion as it happens, or only confirm a state?
Judging motion — a chute filling, a door swinging, a picker at work — takes the RTSP path. An embedded player renders the camera's configured stream, typically 25-30 frames per second for an HD network camera, and buffers it, so plan for roughly 0.5-2 s of glass-to-glass delay.
Confirming a state — door closed, spool present, pallet in place — needs only the snapshot path. The still is one JPEG per refresh; the mechanics are in Grab images from an IP camera over an HTTP snapshot URL. On a 2 s timer the operator sees 5 images in a 10 s glance and never motion, which is exactly enough for a status check and exactly wrong for judging movement.
Bandwidth rarely decides. A 300 KB still fetched every 2 s costs about 1.2 Mbit/s, a configured 4 Mbit/s stream costs 3.3 times that, and both fit a 100 Mbit/s line with a factor of 25 or more to spare — the worked example below shows the arithmetic. If you catch yourself refreshing a still faster than about once per second, you are paying stream money for frozen frames; take the stream.
Display alone needs neither ONVIF, a video management server nor the camera vendor's SDK. Plain reachable URLs carry both routes; those extras buy discovery, pan-tilt-zoom control, events, recording and user management, covered near the end. And for an occasional look rather than a permanent tile, the manually fired one-button snapshot live view skips the timer entirely.
| Snapshot URL | RTSP stream | |
|---|---|---|
| What the operator sees | One still per refresh | Full motion at the camera's frame rate |
| Typical update rate | 0.2-0.5 Hz with a 2-5 s timer | 25-30 fps on a configured HD stream |
| Judge motion live | No | Yes |
| Glass-to-glass delay | Refresh interval plus fetch time | 0.5-2 s of decoder buffer |
| Bandwidth per 1080p tile, example | About 1.2 Mbit/s at a 2 s refresh | 2-8 Mbit/s as configured |
| ONVIF, VMS or SDK required | No | No, the player speaks RTSP |
| Best for | Periodic status checks | Live supervision |
Decision: RTSP when motion judgement is the requirement, a snapshot on a 2-5 s timer when a state check is the requirement, and a refresh under 1 s means the still was the wrong choice.
What you need
- The camera's integration sheet: the still path, the RTSP address, credentials, and whether a second, lower-resolution substream exists.
- A desktop media player for testing the stream outside the HMI.
- An HMI or SCADA runtime that hosts an image or web widget for stills, or a media-player and web-viewer component for motion. Platforms differ: some ship a dedicated camera-viewer part with its own list of supported RTSP transports and limits, so read the IP camera viewer component's RTSP support limits before promising motion in that window.
- A network route from the HMI client to the camera subnet, with HTTP and RTSP reachable.
One boundary note: this pattern belongs to network cameras of the CCTV class. Machine-vision area scan cameras stream over GigE Vision or USB3 into vision software through their SDK and publish no snapshot or RTSP URL, so their display lives inside the vision application.
Wire it in, step by step
- Choose the route from the motion question. A state check takes the snapshot on a 2-5 s timer; live judgement takes RTSP. Write the choice down, because it drives every later setting.
- Collect both URLs from the integration sheet. The still sits at a fixed path on the camera's address, in the shape of http://<camera-ip>/snapshot.jpg — the manual names your exact path. The stream is an rtsp:// address on TCP port 554 by default, again with the path from the sheet. Note the substream address too if one exists.
- Test the still in a browser. The image must load on request. Save it and read its file size in KB, because that number feeds the bandwidth budget. Time a few fetches; on a local network expect well under a second.
- Test the stream in a desktop player. Open the rtsp:// address in VLC or any desktop media player. If video plays there, the camera and URL are proven, and a gray or black tile later in the HMI points at the widget's decoder or buffer settings, not at the camera.
- Add the widget. For stills, use the HMI's image or web part with a timer set to at least twice the measured fetch time, and append a value that changes on every fetch — the current time works — so caches never serve the first frame twice. For motion, embed the player or web-viewer part as in Show a camera live stream in an HMI web viewer widget and Embed an IP camera stream in an HMI or SCADA window. Point tiles at the substream and keep the full-resolution stream for recording or a single large view; lower the component's buffer setting only as far as the delay budget requires.
- Budget the network and the clients. Apply the worked example per tile, then multiply by simultaneous viewers, because unicast RTSP sends one copy per client. For several viewers of one camera, look at multicast or a restreaming server; the tile layout side is covered in Display multiple IP camera streams on one HMI screen.
Worked example: a 1080p camera polled every 2 s against a 4 Mbit/s stream
Inputs, declared so you can swap in your own: a 1080p camera at 1920 × 1080 pixels whose JPEG still weighs 300 KB — consistent with about 1.2 bits per pixel, and trivial to check by saving one still; a refresh timer of 2 s, the common monitoring cadence; a main stream configured to 4 Mbit/s at 25 fps, a typical HD H.264 setting when configurations run 2-8 Mbit/s; a 10 s operator glance.
The rules in words: the still path's bandwidth is bytes per fetch times eight bits, divided by the refresh interval. The stream path's bandwidth is the configured bitrate, continuously. Frames seen is frame rate times watch time.
Arithmetic: 300 KB × 8 = 2,400 kbit per fetch; 2,400 ÷ 2 s = 1,200 kbit/s, or 1.2 Mbit/s. The stream runs 4 Mbit/s continuously, 3.3 times the still path. Frames in the 10 s glance: stills 10 ÷ 2 = 5 images; stream 25 × 10 = 250 frames.
Both fit a 100 Mbit/s segment with a factor of 25 or more to spare, so bandwidth does not pick the winner here — frames per glance do: 250 against 5. The threshold worth remembering sits at the refresh timer: at 1 s the still path costs 2.4 Mbit/s, more than half the stream's rate, while still showing frozen frames. Poll slower than once per second or take the stream; between the two there is no good setting.
Checks before go-live
- Delay on both routes. Hold a running seconds display in front of the lens. The snapshot tile shows the second your timer last fired plus fetch time; the RTSP tile lags by its buffer, typically 0.5-2 s. Read your real numbers off the screen.
- Update count. Watch each tile for 10 s: about 250 updates on a 25 fps stream, 5 on a 2 s timer. Fewer means the buffer or timer is set wrong.
- Decode load at the real tile count. Each HD tile is one full H.264 decode at the camera's frame rate. A desktop CPU absorbs several without effort; thin clients and low-power panel hardware commonly run out past about 6-10 HD tiles, so test the actual count on the actual hardware — the decode budget of industrial panel PCs is the thing to check if the view runs on one.
- Link load. Read the switch port counters for one minute with the display fully populated and compare against the budget. A number far above it means a tile silently fell back to the main stream.
Mistakes that cost hours
- Testing only inside the HMI. Prove both URLs outside first: browser for the still, desktop player for the stream. After that, HMI-side failures are configuration, and the IP camera viewer URL and stream error checklist walks the usual causes for viewer components.
- Every tile on the main stream. Bandwidth and decode cost multiply per tile; the substream exists for exactly this job.
- A timer faster than the fetch. Requests overlap, images queue and the tile falls behind. Keep the interval at least twice the measured fetch time.
- Assuming the machine-vision camera serves RTSP. GigE Vision and USB3 cameras hand frames to vision software through their SDK; the snapshot-and-RTSP pattern belongs to network cameras.
When plain URLs are not enough
Recording, retention, playback and per-user rights outgrow direct URLs quickly. Put a video management server between cameras and HMI: it restreams one clean feed, handles storage and keeps credentials in one place. Direct URLs still suit one camera and one window.
Pan-tilt-zoom control, alarm events and profile switching need ONVIF or the vendor SDK — display never does. If a specification demands ONVIF by name, scope it to the functions that actually move or signal.
Analysis is a different reader. When the stream feeds code rather than eyes, pull it into vision software instead of the HMI: Acquire an RTSP stream from an IP camera in your vision program covers acquisition, and Decode barcodes from a live RTSP or MJPEG video stream works a full processing case.
A pure web client that cannot host a native player still gets motion through a gateway that re-serves the camera as MJPEG. A 640 × 360 JPEG of about 30 KB at 10 fps runs near 2.4 Mbit/s (30 × 8 × 10 ÷ 1000) — modest bandwidth, at the cost of H.264's compression.
Where this leaves you
Pick by the motion question, prove both URLs outside the HMI, then budget tiles, decoders and bandwidth with the worked example before go-live. If the image feeds inspection — measurement, codes, presence — rather than supervision, choose a machine-vision camera with the camera finder and size the optics in the system configurator. The systems topic page collects the rest of the display and streaming guides, and you can contact us for a second opinion on a display architecture.
Questions
Does displaying a camera image in an HMI require ONVIF?
No. Display needs two reachable URLs: an HTTP still and, for motion, an RTSP address that an embedded player consumes. ONVIF adds standardized discovery, profile management, pan-tilt-zoom control and event subscription — worth wiring when the HMI must steer the camera or react to its alarms, unnecessary for a picture. The vendor SDK is the same story: it matters for manufacturer-specific functions, not display. If a specification demands ONVIF by name, scope the requirement to the features that genuinely need it.
How much delay does an RTSP stream add compared with a snapshot?
RTSP buffers: expect roughly 0.5-2 s from scene change to pixel change in a typical embedded player, set mainly by the component's buffer configuration. A snapshot is as old as your refresh interval — a 2 s timer plus tens of milliseconds to fetch the JPEG. Measure both in your own HMI by holding a running clock in front of the lens and reading the offset; the buffer setting moves the stream number, the timer moves the still number.
Can several HMI clients watch the same RTSP camera at once?
Yes, but unicast RTSP opens one stream per client, so five viewers of a 4 Mbit/s stream pull 20 Mbit/s and each player decodes its own copy. Three fixes: point secondary viewers at the camera's lower-rate substream, enable multicast if the camera and network support it, or restream once through a media or video management server and let every client connect to that single copy.
Why does the snapshot in my HMI never update?
Three usual causes. The client cached the first JPEG: append a value that changes on every fetch, such as the current time, to the still's URL so each request looks new. The HMI page is served over HTTPS while the still comes over HTTP, and the browser blocks the mixed content. Or the refresh timer never runs in the runtime client. A time overlay drawn by the camera itself tells you immediately which case you have.
Which cameras can I use this snapshot-and-RTSP pattern with?
Network cameras of the CCTV class: an HTTP still and an RTSP stream are standard features there, with the exact paths in each camera's integration sheet. Machine-vision cameras are the exception — area scan models stream over GigE Vision or USB3 into vision software through their SDK and publish no RTSP or snapshot URL. For those, display happens inside the vision application; the two worlds rarely mix.