View a machine vision camera feed in a browser: what works

You plugged the camera in, found its IP address, typed it into the browser and got a timeout. That is the normal result, not a fault: industrial machine vision cameras do not serve web pages. This explainer is for anyone who needs a live feed from a GigE Vision, USB3 or PoE 3D camera on a laptop, tablet or line-side panel. It covers why the direct IP route fails, the three working paths - vendor viewer, MJPEG gateway, RTSP restream - what each costs in bandwidth and latency, and how a depth camera's 16-bit data reaches a screen. The closing section picks one path per case, and a short checklist catches the mistakes that cost an afternoon.

Can I open the camera's IP address in a browser and see the image?

Usually not. An industrial machine vision camera - GigE Vision, USB3 Vision, most 3D sensors - streams over its own protocol and hosts no web page, so the browser finds nothing at that address and returns a timeout or a refused connection.

A browser fetches pages over HTTP and plays media that arrives over HTTP: MJPEG, HLS, WebRTC. A machine vision camera speaks GigE Vision or USB3 Vision - protocols an SDK discovers and drives directly - with no HTTP listener on board. Nothing to fetch means nothing to render. Exceptions sit at the edges of the catalog: network cameras built for surveillance embed their own MJPEG or H.264 servers, a few smart cameras expose a web configuration page, and a small set of area scan cameras with HDMI output go straight to a monitor with no browser in the loop - the Interface filter of the camera finder isolates them. For the camera classes in this guide, plan on one of the three routes that follow.

Why does the browser show nothing, or the wrong page, at that address?

Three causes cover almost every case: the camera has no HTTP server, the host sits on a different subnet than the camera, or another device already owns that IP and answered with its own page. Work them in that order.

Many GigE and PoE cameras boot into the 169.254.0.0/16 link-local range, so put your NIC in the same range before judging anything - 3D camera link local address: configure both ends and wait shows both ends of that setup. A ping that answers proves the control stack is alive, not that a page exists; on 3D sensors the gap between ping and image is its own fault tree, covered in 3D camera ping works but no image: reset apps and check the trigger. When a page does load but belongs to something else, a second device holds the address - camera IP conflict: ping works but the web page is wrong nails that one down.

1. Set the host NIC into the camera's subnet.
2. Ping the address; no reply means cabling or discovery, not browsers - start from the camera cables.
3. Try the camera's address over HTTP exactly once. A refused or timing-out port means no web server; stop hunting for a page and move to a viewer or a gateway.

What is the fastest way to see the feed on the bench?

The vendor viewer: install the viewer that ships with the camera's SDK, let it discover the camera, and you have live full-resolution frames with exposure, gain and trigger controls inside ten minutes - nothing you write will beat it for a first look. It reads the same GenICam feature tree your production code will set, so settings proven in the viewer transfer directly.

Two quirks cost time if you meet them cold. Viewers are Windows-first, so check the SDK's Linux story before planning a Linux bench session. And most GigE Vision cameras accept one controlling client at a time - close the viewer before your gateway or robot code opens the device, the exact trap in camera works in vendor tool but not in ROS: one client at a time. Runtime mismatches between viewer and SDK produce their own silence, as in GigE camera works in the vendor viewer but not in MAX.

For a laptop session, the LS-CMR-0166 is a 12 MP USB3 area scan camera with a 1/1.7" sensor, 30 fps and a 4000 × 3000 resolution; it runs over the LS-CBL-0219, a 3 m USB3.0 high-flex drag-chain cable.

A GigE pair for the same test: the MV-CU020-90GC, a 2.5 MP color camera with a 1/1.7" sensor and a global shutter, and the LS-CBL-0199, a 3 m high-flex GigE cable with screw locks.

How do I put the camera feed into a browser with no plug-ins?

Serve MJPEG over HTTP: your gateway program grabs each frame from the SDK, re-encodes it as JPEG and writes it into one endless multipart HTTP response that any browser displays inside a plain image tag. No plug-in, no per-browser install - every current browser renders it.

The response is a sequence of JPEG parts inside one open connection:

Content-Type: multipart/x-mixed-replace; boundary=frame

--frame
Content-Type: image/jpeg

<JPEG bytes>
--frame

The boundary name is your choice; the content type is fixed by the standard. Treat the browser copy as a preview: downscale each frame before the JPEG encode and keep full-resolution frames on the host for processing. Host-side decoding is where CPU goes - MJPEG viewer high CPU usage: why the browser is faster measures where that cost lands. If your source is a UVC-class USB camera, the device hands you MJPEG directly and the gateway only forwards it, the pattern in UVC camera MJPEG streaming on Linux for vision applications.

How much bandwidth does a browser feed need?

Take a 1280 × 720 JPEG preview at about 60 kB per frame and 12 fps: 60 kB × 12 = 720 kB/s, or about 5.8 Mbit/s per viewer - small on wired GigE, heavy once viewers multiply or Wi-Fi joins the path. The same frame uncompressed would be 1280 × 720 × 3 = 2.8 MB, about 265 Mbit/s at 12 fps, which is why nobody sends raw frames to a browser.

Each browser connection is unicast and carries its own full copy: five viewers on the example stream pull 5 × 5.8 = 29 Mbit/s from the gateway host. A Wi-Fi hop that measures 50 Mbit/s of real throughput carries 50 ÷ 5.8 ≈ 8 viewers before it degrades; a wired gigabit link has paper room for about 170, but the JPEG encoding load on a modest host caps you nearer ten. Plan MJPEG for one to five viewers and switch formats beyond that. The browser stream rides your office LAN, not the camera link - for the camera side's own cable and distance limits, see 5GBASE-T camera interface: bandwidth, cables and distance.

When should I restream as RTSP, HLS or WebRTC?

Switch when viewers pass about five, the path leaves the wired LAN, or the feed must reach a panel across the plant: H.264 over HLS or WebRTC carries the same 720p preview at roughly 1-2 Mbit/s instead of 5.8 Mbit/s per viewer. No current browser opens an rtsp:// link directly - general-purpose plug-ins are gone - so the stream has to arrive as HTTP somewhere.

Two server-side routes do the conversion. A media server encodes camera frames to H.264 and repackages them: classic HLS segments arrive 6-30 s late, low-latency HLS cuts that to 2-5 s, and WebRTC lands under 0.5 s when someone at the line reacts to the picture. The lighter route runs a JavaScript RTSP client in the browser over a WebSocket proxy - a few hundred milliseconds, no media server beyond the proxy. Building the sender side from a GigE Vision camera is covered in restream a GigE Vision camera over RTSP for remote viewing; the display side on line panels is the subject of restream an RTSP stream for display in an HMI browser. For a permanent screen, host that page on an industrial panel PC bolted where the operator stands.

How do I view a depth or 3D camera in a browser?

Render first, stream second: a depth camera outputs 16-bit depth alongside color and calibration that no browser displays, so your gateway converts each depth frame into a color-mapped 8-bit RGB image - or a rotating point-cloud render - and streams that like any other camera. The stream plumbing does not change; the rendering step is new.

A color scale over a fixed range (say 300-1500 mm mapped blue to red) plus an on-frame scale bar in millimetres turns the picture into a measurement tool instead of art. For full 3D, render the point cloud with WebGL and drive the orbit angle over a WebSocket so a finger on the tablet rotates the part. What those streams contain is detailed in 16-bit depth and 8-bit infrared streams on one depth camera, and the pixel-to-XYZ math that builds the cloud is in 2.5D height map to 3D point cloud: pixels to XYZ. Any 3D sensor works as the source - the MV-DPS200P-02, a projected structured-light 3D camera, is one starting point.

Which option should I pick for my case?

Use the vendor viewer for a bench check today; MJPEG for one to five viewers on the wired LAN; RTSP-to-HLS or WebRTC when the feed crosses the plant or serves many browsers; a rendered depth view for any 3D camera. That sentence settles four bench requests in five.

• Bench proof in the next ten minutes: vendor viewer, full resolution, exposure and gain in the same feature tree production will use.
• One to five viewers, wired LAN, laptops and tablets: MJPEG gateway, 5.8 Mbit/s per viewer at the 720p example.
• Many viewers, a Wi-Fi hop, or plant-wide reach: H.264 restream - HLS for review stations, WebRTC where an operator reacts to motion.
• Permanent line display: the HLS page on a line-side panel, no tablets carried around.
• Depth or 3D source: color-map depth to RGB with a millimetre scale bar, then stream as above.

Before you order or write code:

• Set the host NIC into the camera's subnet before judging anything.
• Try the camera's address over HTTP exactly once; a refused port means no server, not a defect.
• Close the vendor viewer before the gateway opens the camera.
• Fix preview size and fps first, then run the bitrate formula against your measured link.
• Match latency to the task: seconds are fine for review, under 0.5 s for anyone reacting to the picture.
• On 3D sensors, read the laser-class label before you lean in to look.

Start the hardware side here:

Ask us through the contact page which gateway fits the camera you have, and find more integration notes on the systems topic page.