Restream an RTSP stream for display in an HMI browser

You paste the camera's rtsp:// address into the HMI's browser element and get a blank rectangle. That result is normal: browsers render web pages over HTTP, and no common browser engine speaks RTSP, so editing the URL inside the element cannot fix it. The fix is to change the protocol, not the element. Run a small media gateway on an always-on machine in the cell: it pulls the RTSP stream from the camera once and serves it back over HTTP as MJPEG or WebRTC. The browser element then loads an ordinary http:// page and shows the live feed. This how-to covers the gateway set-up, the exact URL to use, which mode to pick and how much network the restream adds. By the end, the feed runs in the runtime display and on every web client that opens the page.

Why the rtsp:// URL renders blank

A browser element is a web page loader. RTSP is a separate streaming protocol with its own connection set-up and its own player, and no browser engine supports it natively, so the element has nothing it is allowed to render. A second failure catches people too: many cameras serve their built-in web viewer with headers that forbid embedding, so the page opens on its own but stays empty inside the HMI. Both are protocol and policy problems, not a setting you missed.

Check first whether your HMI ships a dedicated camera viewer that accepts RTSP; binding the URL there beats any restream. A reference on which HMI camera viewers support RTSP directly and where they stop shows what such viewers accept and what they refuse. With no native viewer, restreaming is the dependable route; where motion is rare, the snapshot URL and VLC alternatives avoid extra software entirely.

What you need

• The camera's RTSP URL with its path and port. Copy both from the camera's manual or its ONVIF discovery page; most cameras expose a full-resolution main stream and a smaller sub-stream.
• An always-on machine on the camera's network: the vision controller, an edge box or a cell PC. A locked-down runtime-only device cannot install software, so it cannot host the gateway.
• The gateway software itself, a single binary for Windows or Linux.
• TCP port 1984 free on that machine, the gateway's default HTTP port.
• Access to the HMI element's URL property and to the firewall between it and your HMI clients.

Run the gateway and name the stream

1. Install the gateway on the always-on machine and start it as a plain process. The Windows binary runs directly; add autostart before rollout, not during testing.
2. Create a go2rtc.yaml file next to the binary. The key names below are the gateway's own defaults; cam1, the IP addresses and the RTSP path are illustrative, so copy the real path from your camera's manual:

api:
  listen: ":1984"   # HTTP port the HMI will call
  origin: "*"       # allows the HMI page to embed the stream
streams:
  cam1:             # your name; the browser URL carries it after src=
    - rtsp://192.168.1.50:554/  # source: the camera's sub-stream URL

3. Start the gateway and open http://192.168.1.10:1984 in an ordinary browser on your laptop. The dashboard should list cam1 as connected.
4. Open http://192.168.1.10:1984/stream.html?src=cam1, the stream page. It offers MJPG and RTC links: MJPG plays in any browser, RTC plays as WebRTC. Confirm the picture moves.
5. If this page works in the laptop browser, the gateway side is done. Anything broken here is a camera URL or credential problem, not an HMI problem, so fix it before touching the visualization.

Point the HMI browser element at the stream page

Set the element's URL property to the stream page: http://192.168.1.10:1984/stream.html?src=cam1. Three details decide whether the feed shows on every client:

• Use the gateway's IP address, never localhost. localhost resolves on each client, and only the machine hosting the gateway has something listening there.
• Keep origin set to "*" in go2rtc.yaml. It is what allows the HMI's page, served from a different origin, to embed the stream.
• Open TCP 1984 in the firewall for every subnet that views. When the feed appears on the runtime device but not in the web client, this is the usual cause: the runtime reaches the gateway, the plant client does not.

Test in order: a plain browser on the gateway host, a plain browser on an HMI client, then the element in the runtime, then the element in the web client. If the element loads but the picture is frozen or empty, the MJPEG viewer URL checklist works through the faults one by one.

MJPEG, WebRTC or HLS

The stream page lists the modes each stream supports. They differ in latency, CPU and what an element can play:

The MJPEG figure follows from the frame rate: at 15 fps a frame arrives every 66.7 ms, and a browser shows two to four of them behind live. WebRTC buys smoother motion with more CPU per session. If the panel's video player only takes HLS, the route is an RTSP-to-HLS conversion on a server, and that conversion walkthrough for web panel video players shows the set-up and the seconds it adds. For an operator view, start with MJPEG on the sub-stream and move to WebRTC only if the picture stutters.

Worked example: bandwidth of a 640x480 at 15 fps MJPEG view

The inputs come from the configuration this article recommends (sub-stream size, operator refresh rate, standard uncompressed color format and default-quality JPEG behavior):

• 640 x 480 pixels per frame, a typical camera sub-stream
• 15 fps, the refresh an operator watching a process needs
• 1.5 bytes per pixel uncompressed, YUV 4:2:0 color
• JPEG compression near 10:1 at default quality for typical machine-view content; textured scenes land nearer 5:1, flat scenes nearer 20:1

MJPEG sends one JPEG per frame, so the bandwidth is the uncompressed frame size times the frame rate, in bits, divided by the compression ratio:

• 640 × 480 = 307,200 pixels per frame
• 307,200 × 1.5 = 460,800 bytes per frame uncompressed
• 460,800 × 15 = 6,912,000 bytes/s, about 6.9 MB/s uncompressed
• 6,912,000 × 8 = 55,296,000 bit/s, about 55 Mbit/s uncompressed
• 55,296,000 ÷ 10 = 5,529,600 bit/s, about 5.5 Mbit/s per viewer

One 640x480 MJPEG view at 15 fps therefore costs about 5.5 Mbit/s per connected client, about 0.7 MB/s. Decision: that is roughly 5 percent of a 100 Mbit/s switch port, so several panels sit alongside the camera's RTSP pull without a second thought. Keep total restream traffic under about half of any link's capacity; beyond that, give the gateway its own port or VLAN. The same arithmetic says a 1920x1080 main stream at 15 fps carries 6.75 times the pixels, about 37 Mbit/s per viewer — the reason HMI panels get the sub-stream and full resolution stays on demand.

Where the gateway runs

A runtime-only visualization device, the kind that boots straight into its runtime with no desktop, cannot host the gateway. Put it on a machine that already lives in the cell and stays powered: the vision controller that runs your inspection software, or a small controller dedicated to cell services.

The MV-VC3301H-128G66 is that kind of host: an Intel Core i3 controller with a 128 G SSD and 5+ LAN ports, so the gateway, your vision software and separated network segments share one always-on box.

Two more hosts cover the common layouts:

The MV-VC5525-256G70-NN adds PoE camera ports, so a compact cell can power the camera and restream from one chassis. The MV-VC2140-128G40-1T carries a 1 T HDD alongside its SSD, which suits a gateway that also archives clips.

Checks before the panel goes live

• Autostart: launch the gateway on boot. A blank element at shift start is almost always a gateway nobody restarted after a power cut.
• Fixed addressing: give the gateway a static IP or a DHCP reservation. The element URL is typed once and never updated.
• Reachability: load the stream page from a client on each viewing subnet, and open TCP 1984 where it fails.
• Camera sessions: with the gateway in place, the camera sees one RTSP client per stream whatever the panel count, so strict concurrent-session limits stop mattering. The flicker several browsers cause when they share one camera directly also disappears.
• CPU headroom: watch the gateway host with three or four clients connected. MJPEG at the size computed above is light; WebRTC sessions are the ones that add up.
• Element fit: size the browser element to the stream's aspect ratio, or the image-scaling rules for HMI widgets apply and a stretched stream reads as a fault.

When to skip the gateway

• Your HMI has a native camera viewer that binds RTSP: use it, and the web-viewer widget approach shows what that path looks like.
• The scene changes only between events: an HTTP snapshot polled on a timer costs a fraction of a video restream and installs nothing.
• You need the data, not the picture: decoding runs on frames rather than on a displayed page, and barcode decoding from a live RTSP or MJPEG stream starts from the same gateway output.
• The operator only needs a view at the machine: a vision sensor's own browser display can cover it without touching the HMI, and the smart cameras and vision sensors range is where those live.

Pick the host from the vision controllers category by LAN port count and memory against the number of streams you plan to serve. If the view belongs on a web dashboard instead of inside the runtime, embedding a live camera feed in a web dashboard takes the same gateway output further, and the systems topic page collects the neighboring guides. When a stream still refuses to appear, the /contact/ page reaches the applications team with your camera model and HMI.