Stream smart camera live video and metrics to a custom dashboard

Your smart camera station already makes the pass/fail decision. Now production wants the live picture and the reject counts on a web page — a dashboard your own team built, not the camera vendor's viewer. The pattern that works splits the job in two: video leaves the device encoded (H.264 or MJPEG), and metrics leave the device as small JSON pushed over HTTPS or MQTT to your backend, which serves both to the browser. Below is the bandwidth arithmetic that defends the split, a transport comparison with latencies, the three-plane architecture, an uplink sizing rule, and the smart cameras and vision controllers that terminate each lane in a typical cell.

Why won't raw camera frames survive the trip to a browser dashboard?

A raw 1920×1080 NV12 frame is 3,110,400 bytes — about 3.1 MB — and at 20 fps that is 62.2 MB/s, or 498 Mbps: roughly 12× the 256 KiB message size browsers report for a data channel, so the frame never fits through in one piece.

The arithmetic is set by the pixel format alone:

Browsers set the second wall. A WebRTC data channel carries messages up to a size the browser reports when the channel opens: the standards floor is 64 KiB and current browsers commonly report 256 KiB. One raw frame is about 47× the floor and 12× the common ceiling, so it fails outright or fragments into a reassembly job that arrives late. A WebSocket to your relay server hits the same wall one hop later and pays the 498 Mbps twice — once out of the device, once into the server.

The browser never needed those bytes. Its video element decodes an H.264 stream from a media path built for exactly that. Encode at or next to the sensor and the 498 Mbps problem dies before it exists; the next trap is buffering ahead of the encoder, and encoded image pipeline latency: finding hidden frame buffering shows where those queues hide.

How much bandwidth do H.264 and MJPEG actually save?

Encode before the frame leaves the device: H.264 at 1080p20 runs 2-8 Mbps (plan 4), about 124× less than the 498 Mbps raw rate, while full-resolution MJPEG lands at 25-50 Mbps and a 640×360 MJPEG stream at roughly 3-6 Mbps.

Worked example, from the raw frame up. A JPEG compressor at its common 10:1 to 20:1 working points turns one 3.11 MB frame into 155-311 KB. At 20 fps that is 3.1-6.2 MB/s, or 25-50 Mbps. Shrink to 640×360 — one-ninth of the pixels — and the same quality settings give 17-35 KB per frame, about 3-6 Mbps. An H.264 encoder compares consecutive frames and spends bits only on what changed, so it holds the full 1920×1080 at 2-8 Mbps.

The figures assume moderate motion; a conveyor crossing the view pushes H.264 toward the top of its range and a static bay toward the bottom, so plan at 8 Mbps per full-resolution stream and the estimate survives contact with the floor. Encode where the frames already are: on a single-camera station that is the camera itself, as in the SC5000X-series model below — 6 MP mono resolution on GigE, a 1/2.4" sensor, rolling shutter, 8 mm M12-mount lens.

Which transport should carry the live video: WebRTC, MJPEG or HLS?

Use WebRTC when an operator steers by the picture and needs sub-second latency — 150-500 ms is typical on a LAN — MJPEG over HTTP when simplicity on the plant network beats bandwidth, and HLS only for many passive viewers who can wait 6-30 s.

Pick by viewer count and patience. A monitoring page showing one image per station is MJPEG at 640×360: the device side is a JPEG encoder and the browser side is an image element. If the page also reads codes off that picture, decoding barcodes from a live RTSP or MJPEG video stream starts from exactly this feed. The moment an operator aligns or focuses while watching, or the path crosses a WAN, move to WebRTC with H.264. Keep HLS for wall displays, where a 6-30 s delay costs nothing and ordinary HTTP caching does the scaling.

MJPEG fails in two boring ways: a torn JPEG after a network hiccup and stray boundary bytes around each frame — corrupt JPEG data and extraneous bytes in MJPEG streams: the fix covers both. Demuxing or re-wrapping the H.264 yourself means meeting its parameter sets first; extracting SPS and PPS NAL units from an H.264 camera stream shows where they sit.

A dashboard is not always a browser. On an HMI terminal the terminal's player decides the path, and displaying an IP camera stream on an HMI terminal walks that case; a SCADA dashboard takes the same feed through its video player component, as in playing an IP camera stream in a SCADA dashboard video player.

How do metrics reach the backend without riding the video pipeline?

Push them outbound from the device app: a 500-byte JSON payload posted once per second is 4 kbps — one-thousandth of a 4 Mbps video stream — over HTTPS or MQTT straight to your backend, while the browser fetches its numbers from your backend, not from the camera session.

The video session is a poor carrier for three reasons. Platforms advertise stream topics built from serializable image messages, so a JSON buffer never becomes a subscribable topic. A metrics history that exists only while a browser session is open is worthless for audits. And a burst of results queues behind megabyte frames on the same channel. Under about ten devices at 1 Hz, plain HTTPS POST with retry-and-backoff is the whole design; past that, or when the backend restarts often, publish to MQTT with QoS 1 and let a broker fan out. The broker path also carries command traffic in the other direction — keeping a camera open and ready between MQTT-triggered grabs is the same discipline on the subscribe side.

The arithmetic stays trivial on purpose: 500 bytes × 8 bits = 4,000 bits per second, call it 5 with TLS and TCP overhead — 0.125% of one 4 Mbps stream. Two lanes, two failure domains, one dashboard. Worst-case images ride neither lane continuously: push them as files when they occur, the way NG images go to an HMI over FTP, and post result strings the same app writes, as in smart camera OCR string output over TCP.

What does the three-plane architecture look like end to end?

Split the system into three lanes that meet only at your backend: a control plane to mint short-lived session tokens, a video plane from device straight to browser, and a data plane from device to backend; no lane should depend on another staying up.

1. Your backend authenticates the dashboard user, calls the device platform's session API over HTTPS, and receives a short-lived connection token plus a connection identifier.
2. The browser opens the peer-to-peer video session with that token: signaling crosses the platform, media runs device-to-browser as H.264 at your planned bitrate.
3. Independently, the device app pushes metrics to your backend over HTTPS or MQTT every 1-5 s.
4. The dashboard draws the picture from the peer connection and the numbers from a backend WebSocket or a 1 Hz poll.

Note where the video does not go: through your VPS. Every open dashboard is one more 4 Mbps flow leaving the station, so five tabs cost 20 Mbps of station uplink — count viewers, not just streams. When peer-to-peer fails behind symmetric NAT or a strict firewall, a relay carries the media, and the relay's bandwidth becomes an operating cost you budget like any other.

Each lane authenticates on its own: TLS everywhere, session tokens that expire in minutes and carry no device credentials, a per-device key on the metrics endpoint, and only outbound dials from the device so the plant firewall keeps no inbound hole. The app that pushes metrics is the same app running the inspection — starting an inspection automatically from a custom program covers the trigger side. If the picture must also reach a PLC HMI rather than a web page, expect a narrower path, as a smart camera image in a PLC HMI: what actually displays live explains.

How many dashboard streams can one station uplink carry?

A dedicated 1 Gbps uplink carries about 75 concurrent 8 Mbps H.264 streams: 1,000 Mbps × 0.75 usable line rate = 750 Mbps usable; 750 ÷ 8 = 93.75; hold 20% for bursts and plan about 75 concurrent streams; a 100 Mbps Fast Ethernet port caps at roughly nine.

The 0.75 is ordinary GigE accounting — real TCP transfers land between 700 and 940 Mbps of a 1,000 Mbps line. The 20% reserve exists so two viewers joining together do not queue their keyframe bursts behind each other. Fast Ethernet's nine streams serve one station; they do not serve a wall of them, which is what the GigE uplink is for.

A multi-camera cell needs one box where camera ports and the dashboard uplink meet without extra hardware. The VC3000-series controller below is that meeting point: 5+ LAN ports, 3-4 USB 3 ports, 4 built-in light channels, an Intel Core i3 processor, 8 GB of memory, no PoE on the camera ports.

How do you keep the connection alive across reboots?

Treat the device's root filesystem as disposable: write VPN, broker and certificate state to the persistent storage path the platform exposes, and make every connection outbound so a restart needs nobody on site.

Vision-device containers usually run on an overlay root filesystem: writes to the system area land in a scratch layer that the next boot or deploy discards. A tunnel agent that keeps its keys in its install directory therefore looks alive after a power cycle and carries nothing. Put secrets, leases and certificates on the persistent storage the platform exposes — app-private, shared and global scopes are the usual trio — and read the assigned service port from the environment variable injected at startup instead of hardcoding one.

If you truly need a tunnel to the backend, prefer the kernel-level route the OS network manager owns over a userspace agent, and prove it across ten real power cycles before calling it production. Better, skip the tunnel: outbound HTTPS and MQTT need no inbound path at all. The same clean-state discipline keeps your tests honest — starting from a known state when a camera test goes flaky on leftover settings is the debugging half of it.

What do you check before ordering hardware for the dashboard?

Order against the lanes, not the camera alone: a camera or controller that produces the encoded stream, GigE rather than Fast Ethernet on anything that streams, PoE camera ports if you want no separate switch, and fanless hardware rated for the cabinet it will live in.

Video lane

• Encoded output confirmed. H.264 or MJPEG from the camera platform, or a controller in the order to run the encoder — the 62-249× bandwidth cut happens there or not at all.
• GigE on streaming cameras. A Fast Ethernet port carries about nine 8 Mbps streams; GigE carries ten times that with the same reserve.
• Port count with room. 5+ LAN ports on the controller when the cell has three or more cameras plus an uplink, so inspection traffic and dashboard traffic never share a port.

Data lane

• PoE camera ports when you want one cable per camera and no switch to power or fail.
• Memory for the whole job. 8 GB runs a streaming and metrics service; move to 16-32 GB when the same box also runs the detection pipeline.
• Evidence out of band. Full-resolution NG stills pushed as files when they occur, never streamed.

Site

• Enclosure rating ordered with the electronics when the cell washes down or grinds dust, not retrofitted after the first failure.
• Uplink sized on viewers. Streams × viewers × 8 Mbps against the 75%-usable rule: about 75 per dedicated GigE uplink, about nine per Fast Ethernet port.

One typical cell, then: a 5 MP color SC6000-series camera with its own multi-color light source at the station, and a VC5000-series controller on the network side — 12th-generation Intel Core i5, 32 GB of memory, 256 GB SSD, PoE camera ports, 8 built-in light channels, 5+ LAN ports.

The decisions, per case. Single station, LAN viewers: a smart camera that encodes on-device, MJPEG at 640×360 or WebRTC H.264, 1 Hz HTTPS metrics. Multi-camera cell: a vision controller on the camera LAN and the uplink, H.264 everywhere, MQTT metrics. Remote or cellular site: H.264 at 2-3 Mbps per viewer, a 720p cap, and nothing raw ever sent. Tell us the camera count, resolution and frame rate — start at the smart camera finder or contact the applications team — and we will size the controller and the uplink with you.