GigE Vision camera on an HMI: bridge GVSP to RTSP

Your panel wants a stream address, and the camera does not have one. HMI panels that show live video consume RTSP: you type an rtsp:// URL into the panel's camera object and it plays. A GigE Vision camera speaks GVSP instead — it pushes raw frames over UDP to the one host that requested them, with no URL, no directory and no media server. Point the panel straight at the camera and the widget stays empty.

The fix is a bridge machine between the two, with one Ethernet port facing the camera and one facing the panel network: it acquires the stream with the camera's GenICam stack, encodes it once to H.264, and re-serves it as an RTSP address the panel can pull. Below you will find the sizing arithmetic, an eight-step set-up, the tests that prove the stream and the mistakes that cost the most time.

Why the panel cannot open a GVSP camera

Panels and media players speak RTSP, often with ONVIF discovery layered on top for point-and-click set-up. Both need the camera to run a media server that publishes an address. GVSP — the GigE Vision Stream Protocol — is a different kind of link: the host writes registers to the camera over GigE Vision, and the camera fires the raw image packets back to that host alone. Nothing advertises itself, nothing hands out a URL, and no panel-side setting changes that.

It also means one data consumer per camera. If your inspection software has the stream, the panel cannot have it too; the camera serves one receiver at a time, and that is a property of the protocol, not a firmware option.

So treat this as a dialect problem, not a broken camera. GigE Vision area scan cameras are built to feed one acquisition host at full link rate; cameras with an onboard RTSP server are a different product class. For background on what a panel expects from the camera side, this GigE camera RTSP requirements note covers the gap from the RTSP end.

What the bridge does

Three jobs run on one machine, in a line:

camera NIC → GenICam acquisition → H.264 encoder → RTSP server → plant NIC → panel

The acquisition half opens the camera exactly as inspection software would: a GenICam/GenTL producer sets exposure, packet size and streaming, and raw frames land in host memory. Those frames are used twice — handed to the inspection pipeline if one runs on the bridge, and passed to the encoder. The encoder compresses to H.264 at a bitrate you choose, and the RTSP server publishes the result over TCP on port 554, or on 8554 when the service runs without root rights, under a path you name such as /cam1. The panel pulls that URL; two panels means two pulls.

Two facts shape the build. Media frameworks that panels and PCs use for playback cannot speak GigE Vision — OpenCV's VideoCapture, the usual first attempt, cannot open a GigE Vision camera — so the acquisition half must come from a GenICam stack, not a media library. And you do not have to write the bridge: open-source GStreamer-based RTSP servers built for GenICam/GigE Vision cameras do the acquire-encode-serve job as-is, and several camera SDKs ship an equivalent sample. M-JPEG is the simpler fallback where the server offers it, but its bandwidth runs several times the H.264 figure at the same resolution, so keep it off the plant Wi-Fi.

What you need

• A bridge machine with at least two Ethernet ports, one per side. A vision controller is the natural fit — fanless, mountable near the panel, and built to hold a camera driver stack:

• The MV-VC3301H-128G66 carries five or more LAN ports and includes a VM6200Pro vision runtime license; the MV-VC5525-256G70-NN adds PoE camera ports and 32 GB of memory for heavier duty; the MV-VC2140-128G40-1T covers a compact station for a camera and a panel on an Intel N-series core with three to four LAN ports.
• A plain switch on the panel side. The camera side needs no switch — cable it direct.
• An HMI panel with an RTSP live-view object and a free network drop.
• Software: the camera's GenTL producer, the GVSP-to-RTSP server of your choice, and your inspection runtime if the bridge doubles as the vision machine.

Worked example: sizing the links for a 5 MP mono camera at 25 fps

Inputs, with their source: sensor 2448 × 2048 px, mono, 8 bit — the typical 5 MP GigE class, and the arithmetic holds for any resolution you substitute; frame rate 25 fps, a common inspection rate; line rate 1,000 Mbit/s, which is Gigabit Ethernet, the physical layer GigE Vision rides on; encode setting 12 Mbit/s H.264, a normal starting point for this resolution and rate.

The rule: raw GVSP rate = width × height × bits per pixel × fps. Keep the camera NIC under about 80% of line rate — above that, UDP loss and jitter appear. The panel side carries only the encoded bitrate.

Arithmetic:

• 2448 × 2048 = 5,013,504 px
• × 8 bit = 40,108,032 bit ≈ 40.1 Mbit per frame
• × 25 fps = 1,002.7 Mbit/s — 100% of the 1,000 Mbit/s link, before the bridge even encodes
• Ceiling at the 80% target: 800 Mbit/s ÷ 40.1 Mbit = 19.9, so about 20 fps is the full-frame limit on one GigE port
• ROI lever: a half-height ROI of 2448 × 1024 = 2,506,752 px × 8 bit = 20.1 Mbit per frame; × 25 fps = 501.4 Mbit/s — 50% load with the full 25 fps kept
• Panel side: 12 Mbit/s is 1.2% of a gigabit plant link; ten panels pull 120 Mbit/s and still fit a standard switch

Decision: put this camera on a dedicated NIC and run it at 20 fps full-frame, or keep 25 fps with the half-height ROI. Above 80% of line rate the levers are frame rate, ROI and bit depth — never the encode bitrate, which only affects viewers. Software H.264 at this resolution costs roughly one to two modern desktop cores, so a Core i5-class bridge carries it alongside inspection; a compact N-series unit suits one camera at modest rates. Scale the same formula before you buy: a 12 MP sensor crosses the line at about 8 fps full-frame (98.3 Mbit per frame), a 25 MP class sensor at about 4 fps (200 Mbit per frame) — there the camera moves to a 10GigE model and the bridge needs a matching port.

Set up the bridge in eight steps

1. Cable it. Camera into the bridge's second NIC, direct, no switch; plant NIC into the panel switch.
2. Address it. Static IPs, DHCP off on the camera port. This guide uses camera subnet 192.168.10.0/24 with the bridge at 192.168.10.1 and the camera at 192.168.10.50, and 10.0.30.20 on the plant NIC — substitute your own plan's addresses.
3. Enlarge the packets. Set the camera's packet size to 9000-byte jumbo frames and enable jumbo frames on the camera NIC. Smaller packets multiply interrupt load and loss for no benefit.
4. Prove acquisition. Open the camera in your GenICam tool and confirm a raw stream. If it will not enumerate, fix the network first — the same camera-not-pingable subnet and link check applies whatever the camera type.
5. Start the bridge server. GenICam source at 192.168.10.50, H.264 encode at 12 Mbit/s, keyframe interval 1 s, RTSP listener on TCP 8554, path /cam1. Open-source GStreamer-based servers take these as four settings.
6. Open only the needed firewall holes. UDP inbound on the camera NIC; TCP 8554 inbound on the plant NIC; nothing else.
7. Test from a laptop on the plant network before touching the panel. Run ffprobe -rtsp_transport tcp rtsp://10.0.30.20:8554/cam1. You should see an h264 video line carrying 2448x2048 at 25 fps. No output means the server is not listening or the firewall is closed; video without audio is normal here.
8. Load the panel. In the live-view object's stream address field, enter rtsp://10.0.30.20:8554/cam1, select TCP transport, save and download the runtime to the panel.

Point the panel at the stream and set the latency expectation

An HMI live-view object typically has three fields that matter: stream address, transport and reconnect behaviour. Address rtsp://10.0.30.20:8554/cam1; transport TCP, which heals packet loss into clean frames at a negligible cost on a switched network; reconnect on, so a bridge reboot recovers by itself. If the widget still shows nothing, the usual cause is the URL landing in the wrong field — the IP camera widget shows no feed: put the RTSP URL in the binding field walkthrough names that trap, and the broader options for displaying an RTSP camera stream on an HMI cover snapshot and player fallbacks.

Expect 0.5 to 2 s from camera to panel. The encoder queues a few frames, and a client that joins mid-stream waits for the next keyframe; with the 1 s keyframe interval from step 5, the first picture appears in under a second and end-to-end delay sits near one second. A 10 s keyframe interval would make every panel hang for ten seconds on join, which is why the GOP is set short. Measure it once: toggle a machine light in view and count.

For an operator doing hand-eye work at the machine, that latency is disqualifying — do not tune RTSP below half a second. Drive a display straight from the bridge instead, as in displaying a camera image on a VGA output from a vision controller.

Common mistakes

The remaining failures are quiet but common:

• DHCP left on the camera port. The camera address drifts after a power cycle, the server cannot find it, and the panel shows the last decoded frame. Static, always.
• A long keyframe interval. It lowers the bitrate slightly and costs every joining client a long blank screen. 1 s is the right setting for panels.
• Two applications opening the camera. The bridge owns the GVSP stream; the inspection runtime must take its frames from the bridge, not open the sensor itself. A held GigE link refuses new clients — see connect a camera only when subscribed to free the GigE link.
• Waiting for ONVIF discovery. It will never list a GVSP camera. Type the URL.
• Bitrate set for office Wi-Fi. 12 Mbit/s rides a plant switch fine; the same number on a congested wireless link tears. Wire the panels.

When a bridge is the wrong answer

Three cases skip the bridge. Viewers are office PCs rather than panels: the same acquire-encode-serve pattern works, but you can drop the HMI specifics — the restream a GigE Vision camera over RTSP for remote viewing set-up is the plain version of this one. The operator needs machine-speed video at the station: use the direct display path from the previous section. The panel only needs a still every few seconds for a dashboard: a snapshot URL is lighter than a live stream and needs no encoder at all.

Where a bridge is right, it is a small, fixed build: one controller, two ports, one URL typed once into the panel. More stream-and-display patterns sit on the systems topic page, and the contact page is where to send the camera model and panel type if you want the settings checked before you order.