Restream a GigE Vision camera over RTSP for remote viewing

You want the production office to watch a machine-vision camera in a browser or on a wall display, and the camera speaks only GigE Vision. That protocol moves uncompressed frames to a single application; it carries no media server, so no viewer can connect to the camera itself. The fix is a small bridge program that you control: grab each frame with the camera's SDK, encode it, and publish it as an RTSP stream from a second network port. This guide gives you the pipeline, the bandwidth and latency arithmetic that sizes it, the build steps, and the checks that prove the stream before an operator leans on it.

Why the camera never speaks RTSP itself

GigE Vision and RTSP solve different problems, and camera firmware does only the first job. GigE Vision is a machine-vision transport: uncompressed Bayer or mono frames, hardware trigger paths, camera-side timestamps and packet resend, on a dedicated 1 Gbit/s link configured through GenICam features. RTSP is a media session: a compressed video stream negotiated with each viewer over the plant network. There is no encoder, no media server and no second client inside a machine-vision camera, so the direct answer to whether the camera can serve RTSP is no.

If you run commercial vision software, check it before writing anything: several packages grab the camera and republish an RTSP or web stream, and that saves the whole build. If your stack is your own code, the bridge is a small service on the host. Either way the camera side is standard: area scan cameras expose a GenICam interface, which is exactly what the bridge grabs. Support pages for individual models reach the same conclusion — this RTSP stream requirements note for a GigE camera works through one model's case — so plan on building the bridge rather than hunting for a hidden camera setting.

The bridge: grab, encode, serve

Three stages run in one process. The grab stage pulls completed frames from the camera's GenICam producer on the camera NIC. The encoder compresses each frame to H.264 or MJPEG. The server accepts RTSP connections on the plant NIC and fans the encoded output out to viewers. Between the stages sit small queues, and queues, not cameras, are where viewing delay hides:

# Illustrative loop: these names are ours, not any SDK's API.
nic          = "camera NIC"     # dedicated port, private subnet
fps          = 30               # target frame rate, integer
latest_frame = None             # newest completed frame
while service_running:
    frame = grab_one_frame(timeout_ms = 100)   # a single GenICam frame
    if not frame.complete:
        discard(frame)         # a lost packet ruins this frame
        continue
    latest_frame = frame       # keep only the newest
    encoded = h264_encode(latest_frame, bitrate_mbit = 6, b_frames = 0)
    rtsp_publish(encoded)      # the server fans this out to viewers

Two queue rules decide how the bridge feels. Keep only the newest frame at the grab stage: a relay that stacks three or four frames trades freshness for nothing, and the point here is watching the line now. Your inspection grab may legitimately want the opposite — camera streaming buffer count explains why streaming applications keep three frames in flight. Never encode an incomplete frame either: when the camera NIC drops a packet, discard it and wait for the next one, the rule behind incomplete frames stay incomplete, or the encoder's frame timing falls apart. And buffering added anywhere between SDK and socket shows up in the viewer's delay, the failure mode behind encoded image pipeline latency.

What you need

• The GigE camera with its SDK (a GenICam producer for your OS) already grabbing at the target frame rate.
• A host with two network ports: one NIC for the camera on a private subnet, one NIC on the plant network for viewers.
• An encoder and an RTSP server library; a GStreamer-based server covers both stages, and open-source projects already pair a GenICam grab loop with one.
• An RTSP-capable player for testing, and a player or decoder box for the wall display.

The engineering PC carries trials fine, but a service that runs every shift belongs on a vision controller in the panel: fanless, rich in LAN ports, and built to sit next to the cameras. If the camera side itself needs settling first, the camera finder is the place to start.

For a single-camera cell, the MV-VC2140-128G40-1T has 3-4 LAN ports, 2 USB 3 ports, 8 GB memory and an Intel N-series processor — a camera NIC, a plant NIC, and ports to spare.

A cell that also switches its lights from the same box fits the MV-VC3301H-128G66, which has 5+ LAN ports, 4 built-in light channels, 8 GB memory and an Intel Core i3 processor.

Build it step by step

1. Dedicate the camera NIC. Static IP addresses on a private subnet, nothing else on that port, and the camera's packet size set to the largest the NIC accepts — GigE Vision cameras commonly go up to 9000-byte jumbo packets, and header overhead is why small packets waste a link.

2. Prove the raw grab. Run the SDK's grab at the target rate for ten minutes with a drop counter of zero, before any encoder exists. Torn or blank frames at this stage are NIC problems, and GigE Vision stream packet loss walks that diagnosis.

3. Respect the frame-rate ceiling. A camera sustains exposure time plus readout time per frame, and no encoder changes that; maximum frame rate on a hardware trigger does that arithmetic. Pick a rate the camera holds all shift, not one it holds in a burst.

4. Write the grab loop. Latest-frame-only, per-frame timestamps from the camera clock, incomplete frames discarded, as sketched above. If an older camera SDK predates GenICam, migrating it to GenICam acquisition is the cleanup that makes the loop portable.

5. Choose encoder and bitrate. MJPEG when viewers are few and delay matters most; H.264 when viewers multiply or the stream crosses a router. Configure H.264 at 6 Mbit/s for 1080p-class video with B-frames off; MJPEG needs roughly a tenth of the raw rate. The worked example below puts numbers on both.

6. Publish on the plant NIC. Bind the RTSP server to the second port, on the standard RTSP port 554 or a high port such as 8554 for a user-level service, and open the firewall for that port alone. Viewers then open an address of the form rtsp:// followed by the plant IP, the port and the stream name.

7. Watch from two seats. Open the stream from a wired viewer and a Wi-Fi viewer on the plant LAN at the same time. The wired view is the reference; if the Wi-Fi view stutters while the wired one stays clean, the wireless link owns the problem, not the bridge.

8. Measure the delay before anyone relies on it. Burn a frame counter or millisecond stamp into the image and read it next to a wall clock in the viewer; camera buffer timestamp latency shows how to interpret what you see. Expect roughly 0.2 to 0.5 s and pull it down at the player's buffering setting first.

The numbers: a 2.5 MP camera at 30 fps

The bench case is a 2.5 MP camera in free-run at 30 fps, 8-bit mono or Bayer output. A representative part is the MV-CU020-90GC.

Bandwidth

Raw, the camera puts 2,500,000 pixels × 1 byte × 30 fps × 8 bits = 600 Mbit/s on its NIC. A dedicated GigE port carries that: the practical ceiling on 1 Gbit/s of link is about 940 Mbit/s once protocol overhead is paid, and jumbo frames keep it there. MJPEG at the usual 10:1 JPEG compression takes 600 ÷ 10 = 60 Mbit/s, comfortable on a plant LAN. H.264 configured at 6 Mbit/s is 100 times below raw (600 ÷ 6), and one GigE viewer port then holds bandwidth for 940 ÷ 6 ≈ 156 unicast viewers — a count switch capacity and player behavior will never let you reach, but proof of how small the stream is.

Latency

Budget 5 ms of exposure, a 33 ms frame interval (1,000 ms ÷ 30 fps, which covers capture and readout at a fixed rate), one frame interval for a software H.264 encode with B-frames off, and 150 ms of player jitter buffer: 5 + 33 + 33 + 150 = 221 ms. Call it 0.2 s, and expect 0.15 to 0.5 s across player defaults; most software encoders at this resolution beat a full frame interval, which is the pleasant surprise in the budget.

Prove it before an operator relies on it

1. A ten-minute raw grab with the drop counter at zero. If grabs time out instead of dropping packets, the host's socket buffers are the usual cause, and GigE camera buffer timeouts on embedded Linux is the fix to read.

2. Encoder output rate equal to camera frame rate for ten minutes, with per-frame encode time under the frame interval.

3. Two simultaneous viewers, one of them on Wi-Fi, both playing smoothly.

4. A measured end-to-end delay inside your budget, read from the in-frame counter against a wall clock.

5. A soak test: disconnect the camera NIC for ten seconds and confirm the service recovers, reconnects and carries on without anyone logging in.

When the delay still misses the budget, what remains lives downstream of the bridge; reducing RTSP frame latency works that end. More stream and latency plumbing sits on the systems topic page.

When the bridge is the wrong answer

Robot guidance and any feedback loop keep the raw GenICam path: compressed, buffered video cannot hold the latency a control loop needs, and image-based control latency shows how little delay there is to spend. Evidence you will measure later belongs on the camera side too, because the RTSP copy is lossy by design. Analysis, though, can share the stream: barcodes decode fine from a healthy RTSP or MJPEG feed, as decoding barcodes from a live stream demonstrates. And before you stack cameras on one host, remember each raw feed still takes hundreds of Mbit/s on its own NIC no matter how few people watch; the port-and-bandwidth budget in two GigE cameras on one host comes before any encoder math.

The decision, case by case

• A handful of plant-LAN viewers and delay matters: MJPEG, about 60 Mbit/s at the worked example — the lowest-delay bridge you can build.
• Many viewers, or a route to another building: H.264 at 6 Mbit/s with B-frames off, about 0.2-0.5 s to the screen.
• Someone must act on what they see: check the process first. At 0.3 m/s belt speed, 0.3 s of delay means the viewer sees the part 90 mm (0.3 s × 0.3 m/s) behind where it really is. Monitoring tolerates that; a stop decision needing frame-accurate timing does not, and the PLC holds the real timing either way.
• The host is a controller with a camera NIC and a plant NIC, and the inspection path stays raw.

Tell us the camera model, frame rate and where the viewers sit through the contact page, and we will size the bridge host and encoder for the job.