Multiple browsers, one IP camera: why the stream flickers

An IP camera or a networked vision sensor serves its live image to a browser as an MJPEG stream over plain HTTP. Add a second and third operator opening the same dashboard and the picture starts flashing: a black gap, a frozen frame, a refresh, again. On the floor this gets blamed on the browser, the network or the viewing software's licence, and it is almost always none of them. It is the camera's simultaneous-connection limit. Below is the number behind it, a two-minute test that proves it, the bandwidth arithmetic for your viewer count, and the proxy set-up that lets any number of browsers watch one camera steadily.

Why does one IP camera flicker when several browsers view it?

Every browser tab opens its own unicast MJPEG connection to the camera, and the camera holds only a handful at once: current industrial IP camera datasheets print a maximum of 5 simultaneous unicast connections, so extra tabs evict earlier ones. The evicted tab reconnects, its reconnect evicts someone else, and the page flashes in a loop. That loop is the flicker you see — not a display fault, a session fight.

On top of the session cap, every connected client shares one encoder inside the camera, so per-viewer frame rate falls as viewers join even before the cap bites.

How many simultaneous connections can one camera serve?

Plan on five. Two current industrial IP camera datasheets print the same line — a maximum of 5 simultaneous unicast connections and 50 multicast clients — so treat 5 direct browser connections as the ceiling and design for three.

Count tabs, not users. A dashboard gadget that embeds the camera's address holds one HTTP session for as long as the page stays open; eight SCADA clients with the camera on screen are eight sessions, whoever is logged in. Eviction, not bandwidth, is what you see first.

Networked smart cameras and vision sensors follow the same rule: the inspection engine and the live MJPEG view share one port, so operator viewing competes with inspection traffic. A model such as the MV-SC6050C-08M-XBN — 5 MP, color, GigE interface, with its own multi-color light source — serves its live view to a browser exactly like a surveillance camera does.

How do I prove the connection limit is the cause?

Open viewers one at a time and note the count where flicker starts: if the stream is stable alone and breaks at a repeatable number of tabs — typically the fifth or sixth — the camera's session cap is your flicker. Work through it in order:

1. Close every browser, app and dashboard that touches the camera. Open a single tab with the stream and leave it ten minutes. A lone viewer that still flickers has a different cause — jump to the last troubleshooting section.
2. Open the camera's own web interface and find its client or session list, which most models keep on a status page. You should see exactly one client: your tab.
3. Add viewers one at a time, waiting a minute each, and re-read the list. Note the count at which the oldest client disappears or the picture begins to flash.
4. Close one tab and re-read the list. A slot that stays occupied after its tab closes is a half-closed TCP session holding it, which lowers the working limit below the printed one.
5. Point one dashboard at the proxied URL and repeat step 3. The camera must now show a single session — the proxy — no matter how many browsers are open.

If the break point lands on a repeatable tab count, you have your answer. Nothing about the viewing software's licence mode changes that count; the session table lives in the camera.

What does proxy mode change on the camera?

It collapses every browser connection into one: the proxy — your HMI server, a vision controller or a small stream service — holds the only connection to the camera and re-serves a copy to each browser. From the camera's point of view, viewer count stops existing.

Turning proxy mode on is a per-gadget setting on most HMI and SCADA platforms: the gadget's URL changes from the camera's address to a path on the server, and the server does the fetching. The classic failure is a dashboard where one widget was left pointing straight at the camera — those clients bypass the proxy, count against the cap, and the whole page starts flashing again.

When a proxied client disconnects, the server must close its socket promptly or you leak connections at the proxy instead of the camera; the guide on MJPEG stream restart: closing the client socket and busting the cache covers that failure. For embedding the re-served stream in an operator page, see showing a camera live stream in an HMI web viewer widget. A walkthrough of SCADA IP camera MJPEG stream configuration shows the gadget-side settings end to end.

What hardware should the stream proxy run on?

On whatever already terminates your camera traffic: the HMI or SCADA server in proxy mode covers a dozen viewers; a vision controller is the better host when the cell already has one, and a small open-source proxy service covers the rest. Serving JPEG frames to browsers is light work next to encoding them.

Option one is the HMI or SCADA server itself, in proxy mode: one setting, no new hardware. Option two is a vision controller already in the cell — it terminates the camera network on one interface and the plant network on another, so viewer traffic never crosses the camera subnet, and it can run inspection and re-serve in one box. The MV-VC3301H-128G66 offers 5+ LAN ports, 8 GB of memory and 4 built-in light channels; the MV-SVC2506-16G60-128G dedicates 4 camera GigE ports plus a configuration and a communication port, with 16 GB of memory.

Option three is a small dedicated proxy service. Open-source MJPEG proxies exist for exactly this job; one documents about 300 MB of memory for two streams, so the load is negligible on any fanless controller. Two serving-side pitfalls: a reverse proxy in front will time out long-lived MJPEG connections and fail with stream error 0 on long-running proxied streams, and CPU on the serving process climbs with viewer count — MJPEG viewer CPU usage: why the browser is faster explains where it goes.

How much bandwidth do the viewers need?

Per viewer, take the JPEG frame size times the frame rate times 8: a 1080p stream at 15 fps with 150 kB frames is about 18 Mbps per viewer, and that multiplies — five direct viewers force 90 Mbps out of the camera.

Worked example, typical indoor camera settings:

• Average JPEG frame at 1080p: 150 kB, which is 150,000 byte.
• Bits per frame: 150,000 × 8 = 1,200,000 bit = 1.2 Mbit.
• At 15 fps: 1.2 Mbit × 15 = 18 Mbit/s per stream.
• Five browsers, direct: 5 × 18 = 90 Mbit/s leaving the camera.
• The same five browsers through a proxy: 18 Mbit/s from camera to proxy, then 5 × 18 = 90 Mbit/s from proxy to viewers.

Now put those against the ports. Fast Ethernet is a 100 Mbps link: five direct viewers spend 90 of it — 90% — on live viewing, before any inspection traffic. GigE is 1,000 Mbps: the proxy's 90 Mbps is 9% of one port. That asymmetry, not raw camera speed, is why the proxy pattern scales. A Fast Ethernet vision sensor such as the MV-SC3050XC-16M-ATN-H — 5 MP, color — carries inspection and viewing on the same port, so it benefits most.

If several cameras feed one host, the same arithmetic stacks per camera: multiple GigE cameras on one computer: bandwidth and CPU budget works the full budget.

When is the connection limit not the problem?

When the stream flickers with a single viewer: one tab, one connection, still flashing means lighting beat or exposure, not sessions — mains-frequency lamps and short exposures draw black bars across the image. Work the lighting first: the diagnosis and fix are in camera image flickers: causes and fixes for mains beat and triggers, and black bars in camera images: lighting flicker versus exposure tells the two patterns apart.

Three more look-alikes: a camera that reboots under load (check the PoE budget on its switch port); a Wi-Fi hop between camera and viewers, where every stream is a separate airtime allocation; and a proxy that drops idle MJPEG connections, which produces the same flashing at the browser. Finally, if your camera supports multicast — the same datasheets allow 50 multicast clients — VMS players and NVRs on an IGMP-snooping switch can share one stream. That serves video-wall clients, not browsers; browsers still arrive by the proxy.

What should I check before adding more viewers?

Run this list before you scale past a handful: count tabs, switch every gadget to the proxied URL, cap the viewing stream's resolution, and confirm the camera still shows exactly one session at full viewer load.

• Count tabs, not users — every open dashboard tab is one session for as long as it stays open.
• One proxied URL per gadget — a single widget aimed at the camera's address brings the cap back for everyone.
• Serve the substream to viewers — the camera's low-resolution second stream is plenty for operators and costs a fraction of the full-rate feed.
• Re-check the session list at full load — one client, the proxy host, whatever the viewer count.
• Cap the viewing frame rate at the camera — operators rarely need more than the inspection rate.
• Past about twenty viewers, add a multicast tier for multicast-capable clients or a second proxy — do not stack direct connections.
• Keep the camera's direct address off operator machines — access control stays with the proxy, not with every browser.

If you are specifying the cell rather than repairing it, the system configurator walks camera, controller and viewing in one pass, and the camera finder filters networked models by interface. For a single local screen, a vision sensor browser display for local operator viewing skips the proxy tier entirely.