An Ethernet vision camera that already shows its live image on a web page is one element away from your operator HMI — yet these integrations regularly stall on a blank frame or a stream the browser refuses to load. This guide is for the engineer building a web HMI or dashboard who needs the camera view, and often the results panel, inside it. You will choose between an img tag and an iframe, learn which stream protocols browsers actually play, fix the causes behind nearly every blank embed, and size the network load with worked numbers. Everything assumes the camera sits on the same private LAN as the HMI host, which is the design worth building.
Can I embed my vision camera's image in a web HMI?
Yes — if the camera serves its image over HTTP, one iframe pointed at the camera's page URL, or one img tag pointed at its MJPEG stream URL, puts the live view inside your panel with no server code of your own. Three conditions make that true, and each has a section below. The camera must run a web server on its IP address. The stream it publishes must be a format a browser renders — MJPEG qualifies, RTSP does not. And the browser on the HMI client must reach the camera address directly, which is a routing question, not a software one. When the need is only an occasional look from a workstation, the sensor page alone does the job: see vision sensor browser display for local operator viewing. When the view belongs inside the HMI, read on.
Which cameras serve a stream a browser can display?
Ethernet smart cameras and vision sensors with a built-in web server do it out of the box; plain GigE Vision and USB3 area-scan cameras do not, because their interfaces are acquisition protocols, not web protocols. A smart camera on your LAN publishes its live page at an address like http://192.168.1.202:8087 — open it in a desktop browser and you see the image plus pass/fail data. That page, and the MJPEG stream underneath it, are exactly what you embed in the next section. The smart cameras class is where to look: the LS-SMC-0063 is a 1.6 MP smart camera with a 16 mm lens running at 60 fps, the MV-SC5060XM-08M-WBN is a 6 MP mono model with an 8 mm focal length, and the MV-SC3050XC-16M-ATN-H is a 5 MP color vision sensor on Fast Ethernet with a global shutter.
- Interface
- GigE
- Resolution
- Up to 3 MP
- Interface
- GigE
- Resolution
- 6-10 MP
- Interface
- Fast Ethernet
- Resolution
- 5 MP
Area scan cameras are the other case. GigE Vision is a point-to-point acquisition protocol with GenICam feature control; there is no HTTP server inside the camera to embed, and a browser cannot open the interface at all. The fix is not a different browser — it is the frame-server pattern further down. Both classes are in the camera finder.
MJPEG, RTSP or HLS: which protocol does the browser accept?
Browsers render MJPEG natively in an img tag and play HLS with a few seconds of delay; none of them plays RTSP, so an RTSP-only camera always needs a converter between it and the panel. MJPEG is a multipart HTTP response — an open-ended sequence of JPEG frames — and Chrome, Edge and Firefox display it directly in an img element. End-to-end latency on a LAN runs 100-300 ms, which is why it is the default for an operator view. Safari is the exception: it does not render MJPEG in an img tag, so give Safari clients the camera page in an iframe or an HLS stream.
H.264 over RTSP is the common output where a camera doubles for surveillance or long cable runs. Convert it rather than fight it: an ffmpeg relay re-encodes to HLS with 1 s segments for 2-5 s end-to-end latency, while a stock 6 s segment setup sits nearer 15-20 s. A WebRTC gateway gets under 500 ms when an operator steers the machine by what they see. The walkthrough of converting RTSP to HLS for HMI web video covers the relay configuration. If software on the host should consume the stream instead of a browser, decoding barcodes from a live RTSP or MJPEG video stream shows that path.
img tag or iframe: how do I embed the stream?
Use the img tag for just the picture in your own layout, and the iframe for the camera's whole page — live image plus pass/fail data — which is the fastest integration when that page already shows what operators need. The two sources sit one step apart on the same device:
img src: http://192.168.1.202:8087/stream.mjpg (bare MJPEG stream)
iframe src: http://192.168.1.202:8087 (camera page with readouts)
- Open the camera address in a browser on the actual HMI client machine, not your development PC, and confirm the image and readouts render. Keep the full address with its port.
- Choose the element. For a bare stream, find the MJPEG URL first: with the page open, bring up the browser developer tools, open the Network tab, and note the request whose type is multipart/x-mixed-replace or whose name ends in .mjpg — that request URL is the img src. For the full page, the address from step 1 is the iframe src.
- Add the element with that src and size it in the panel stylesheet — full tile width and a fixed aspect ratio, so the layout does not shift when the first frame lands.
- Give the view its own panel or its own page in the HMI. Views nested several menu levels deep are where iframe integrations break: the frame mounts once, navigation unmounts it, and it returns frozen. A panel that holds only the camera view is the reliable shape.
- Verify from a second client on the plant network: the image should appear within 1-2 s and track the scene.
Why is the embedded camera a blank frame?
In almost every case the browser is refusing the load, not the camera failing: mixed content, frame-embedding headers and routing to the camera subnet cover nearly all blank embeds, and each has a direct fix. Work down this table in order — the first three rows are the ones that hit most installs.
| What you see | Cause | Fix |
|---|---|---|
| Console shows a mixed-content message; tile stays empty | HMI page served over HTTPS, camera over plain HTTP | Proxy the camera through the HMI host over HTTPS, or serve the HMI over HTTP on the isolated cell network — few industrial cameras speak TLS |
| Direct URL opens fine; iframe stays blank; console mentions a frame refusal | Camera page sends X-Frame-Options DENY or SAMEORIGIN, or a CSP frame-ancestors rule | Allow embedding in the camera web config if it exposes the setting; otherwise strip the header in the proxy, or embed only the bare stream — an img tag is not affected by frame headers |
| Address times out from the HMI client but opens from the host | Camera sits on a machine VLAN the client cannot route to | Open the route, or proxy the camera through the dual-homed HMI host so clients need one address |
| One frame renders, then nothing | Safari client with an MJPEG img tag | Serve Safari the camera page in an iframe, or an HLS stream |
| Torn, gray or intermittently blank frames | Packet loss on a saturated link | Read the switch error counters and split the traffic; the diagnosis in GigE Vision stream packet loss: diagnose blank frames applies to any streaming link |
When the blank image is in the vision software itself rather than the HMI tile, start instead from blank image window troubleshooting for vision systems.
When does CORS block a camera image?
Only when your JavaScript reads the pixels: img and iframe display cross-origin without CORS, but fetch calls and canvas reads stay blocked until the camera answers with an Access-Control-Allow-Origin header. If the tile shows the picture, CORS is not your problem. It becomes one the moment you draw the stream onto a canvas to overlay boxes or measure. Set the img element's crossOrigin attribute to anonymous; the camera must then return that header on every response, and few vision cameras let you configure it. Without the header the canvas is tainted — it draws, but pixel reads and image exports throw a security error. The clean split: measure and annotate on the host that already holds the frames, send the outputs to the HMI as data, and keep the stream as a view. Browser-side processing does work when you own the serving side; webcam barcode scanning in browser-based vision systems shows the pattern on a stream you control.
My camera is GigE Vision only: where does the stream come from?
From a small frame server on the vision host: the application already holds every frame, so serve the latest one as MJPEG over HTTP and embed that URL — the browser never touches the acquisition interface. The loop is short: acquire over GigE Vision, downsample to viewing resolution, encode JPEG, answer HTTP requests with the multipart stream. One encode serves all viewers, and the network cost is the per-panel figure in the next section rather than full-rate camera traffic. Keep the roles separate — acquisition keeps its dedicated link and timing, and the HMI view is a decimated copy that can drop out without touching inspection. What the GigE Vision standard does and does not guarantee about host access is covered in camera compatibility: what GigE Vision guarantees.
A 20 MP GigE model like the MV-CS200-10GC feeds the host at inspection resolution while the HMI shows a downsampled copy.
- Sensor format
- 1"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- 16-25 MP
How much bandwidth does an embedded MJPEG stream use?
Budget about 7 Mbit/s per open panel for a 1.3 MP grayscale stream at 15 fps, and multiply by viewers: MJPEG is unicast, so every operator watching adds another stream from the camera.
Worked example, grayscale:
- Frame: 1280 × 1024 pixels ≈ 1.3 MP, JPEG quality 70. An industrial scene lands at 40-80 KB per frame; use 60 KB.
- Rate: 60 KB × 15 fps = 900 KB/s.
- To bits: 900 KB/s × 8 = 7,200 kbit/s ≈ 7.2 Mbit/s per panel.
- Four panels — three operators and an engineering station: 4 × 7.2 = 28.8 Mbit/s. That is noise on a gigabit link, which is why the frame server belongs on gigabit.
Color runs two to three times grayscale at the same quality, so the same viewing stream lands at 14-22 Mbit/s per panel. The levers, in order of value: drop to 10 fps (7.2 × 10 / 15 = 4.8 Mbit/s), crop to the region operators actually watch, then lower JPEG quality to 60 for roughly a further quarter off.
Which route should I build, and what do I check?
Embed the camera page in an iframe when it already shows image plus readouts, embed the bare MJPEG in an img tag for your own layout, convert to HLS when the only output is RTSP, and run a host frame server for a GigE Vision camera.
| Your situation | Route | Why |
|---|---|---|
| Smart camera page already shows image and readouts | iframe of the page | No integration code; operators see exactly what the device shows |
| Same camera, custom layout and annotations | img of its MJPEG URL | The stream behaves like any tile; annotations come from the host as data |
| RTSP is the only output | ffmpeg or gateway to HLS | Browsers refuse RTSP; tuned HLS adds 2-5 s, WebRTC gets under 500 ms |
| Plain GigE Vision or USB3 camera | Frame server on the vision host | The host holds the frames already; the browser stays off the acquisition path |
| Safari clients in the mix | iframe page or HLS | Safari does not render MJPEG in an img tag |
Sign-off checks:
- The camera address opens from the actual HMI client on the plant floor, not only from your desk.
- The browser console is clean: no mixed-content, frame or CORS messages.
- Navigate away and back: the stream restarts instead of freezing on the last frame.
- Three panels stay live for ten minutes at production rate, with frames current, not stale.
- Latency measured by waving at the scene stays under half a second on MJPEG routes.
- The stream is reachable only inside the private LAN, with no port-forward to the internet.
Planning a station that needs this view from the start? Walk the camera step of the configurator, then send the cell details through the contact page for a parts check.
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
Questions
Can the video tag play my camera's RTSP stream directly?
No. No current browser implements RTSP, so an rtsp:// URL in a video element fails with a plain error. Convert instead: an ffmpeg relay with TCP transport, re-encoding to H.264 with 1 s segments, produces an m3u8 playlist the video element plays everywhere; tuned that way, latency lands at 2-5 s. Use a WebRTC gateway when an operator positions parts against the image and needs under 500 ms.
How many HMI panels can watch one camera at once?
Each panel is its own unicast MJPEG connection, so the limit is the camera link and firmware, not the browser. At 7 Mbit/s per viewer, ten open panels draw 70 Mbit/s from the camera — comfortable on gigabit, most of a Fast Ethernet uplink. Multiply your measured per-panel figure by viewers plus a 30 percent margin, and check the device limit, which sits near 4-8 simultaneous clients on many vision sensors.
Why does the second camera view freeze while the first plays?
Browsers cap HTTP/1.1 at six concurrent connections per host, and an MJPEG stream holds its connection open indefinitely. When several iframes, streams and data polls all target one camera address, the seventh request queues and looks frozen. Fix it by giving each camera its own address or host name, or by proxying the streams through the HMI server, which fans them out over one connection per client.
Is a WebSocket JPEG push better than MJPEG?
Same bandwidth, more control. The server grabs a frame, encodes it as JPEG and pushes it as a binary WebSocket message; the client swaps the image source to a blob URL. Choose it when the camera publishes no MJPEG but you already hold the frames — the GigE Vision host is exactly that case — or when the server should decide which frame is worth sending, such as only on part-present.
What resolution and frame rate does an operator actually need?
For a person watching a machine, 800 × 600 to 1280 × 1024 at 10-15 fps is enough, and it holds each panel near 3-7 Mbit/s. Inspection still runs at full camera resolution on the host; the HMI view is a monitoring copy, not the measurement image. Use 5 fps for overview tiles and reserve 15 fps for the panel an operator uses to position parts by eye.