GigE Vision packet loss horizontal lines in live images

The live image looks perfect until something moves. Then one or two horizontal streaks, about a millimetre or two wide, sweep through the frame, and the moment the scene freezes they are gone. On a GigE Vision camera that pattern is network packet loss, not a faulty sensor: packets that never arrived leave holes in the image, and because acquisition buffers are reused without being cleared, each hole keeps the previous frame's pixels until motion exposes it. This page is for anyone commissioning a GigE or 10GigE camera who sees those streaks. You will confirm the diagnosis from the camera's own statistics in a few minutes, check whether the link has the packet budget for the stream you asked for, and apply the fixes in the order that pays: port, packet size, buffering, then hardware.

The streaks are stale pixels, not sensor faults

GigE Vision splits every frame into numbered packets before they go on the wire. With the usual 1500-byte packet size, about 1440 bytes of each packet carry image data and the rest is protocol header. Lose one packet and the frame arrives with a hole of roughly 1440 contiguous pixels in mono 8-bit — most of one row on a 1920-pixel-wide sensor, and about the width of the streak you see on screen.

The host receives frames into a fixed pool of acquisition buffers and reuses them without clearing. A hole that is never refilled keeps whatever sat in that memory last frame. In a stationary scene those stale pixels match the new ones, so the hole is invisible. The moment the laser spot, the part or the belt moves, the hole shows where the pixels used to be: a horizontal smear, at a different position every frame, tracking the bursts of loss.

Stills often look clean for the same reason. In a single capture the packet resend mechanism has a whole frame period to recover what it lost, so the saved image arrives complete; the continuous stream has no such headroom. When loss grows heavier the symptom changes — frames arrive blank or the stream stalls — which is the same fault in a louder form, and the packet loss diagnosis for blank frames covers that end of it.

Why the link drops packets, most likely first

1. A shared or busy host port. Office traffic, a file copy, a viewer rendering on a second display, a second camera on the same NIC — all of it competes with the stream. A CPU stall of a few tens of milliseconds stops the driver servicing the receive queue, the NIC discards what it cannot store, and loss lands in bursts.
2. 1500-byte packets on a heavy stream. Every packet is an interrupt and a buffer event. A stream near the gigabit limit generates tens of thousands of packets per second, and desktop network paths fall behind. The safe default is also the expensive one: 9000-byte packets cost about six times fewer events for the same data.
3. Packet size larger than the path MTU. A switch that does not take jumbo frames silently drops every oversized packet, and the image breaks up from the first frame. That is a configuration mismatch, not congestion — see when packet size exceeds the network MTU.
4. A link negotiating below gigabit. A damaged cable, a dirty connector or a duplex mismatch can settle the port at 100 Mbit/s and cut the budget by a factor of ten; some cameras then refuse a large packet size outright, which shows up as a packet size error when the link drops below gigabit.
5. Microbursts at a switch. Several cameras bursting into one uplink overflow per-port buffers even when the average load looks comfortable.
6. Resend saturation. Packet resend is a repair mechanism, not extra capacity: retransmissions ride the same link, so once loss is heavy, the repair traffic adds load and the loss grows.

Confirm packet loss in five minutes

1. Read the statistics while something moves. Run the live stream, pass a part through the field for a minute, and open the transport statistics in the SDK or frame grabber driver. Lost-packet and resend counters that climb while the scene moves confirm the diagnosis outright; counters at zero with streaks still present point at a different cause.
2. Halve the data rate. Drop the frame rate or shrink the ROI. Streaks that vanish at half rate mean the stream is over the link's real budget.
3. Drop the packet size as a test, not as the fix. Setting the packet size to 1500 bytes (some paths settle lower still, at 4000 or 2000) tells you whether the network mishandles large frames — some NICs and inexpensive switches do. If streaks stop at 1500 but the camera can no longer hold its frame rate, the path needs jumbo frames configured properly, not a permanently smaller stream.
4. Bypass the switch. Connect the camera straight to the host NIC. A clean image on the direct cable indicts the switch or whatever else rides it.
5. Check the negotiated speed and run the test packet. Confirm the port settled at 1000 Mbit/s full duplex, and run the driver's packet-size test before streaming; a test packet that is not received means the packet size and the MTU disagree somewhere in the path.

The fixes, in the order that pays

One camera, one port

The first fix costs one PCIe slot: put the camera on a port of its own, with nothing else riding it — no office VLAN, no display traffic, no second camera. Two cameras need two ports, and the port and bandwidth budget for two cameras on one host works that arithmetic in advance. The MV-GE2002P is a dual-port PoE NIC.

Jumbo frames, end to end

Set the packet size to 9000 on the camera and the MTU to 9000 on the NIC and on every switch port in the path, then run the test packet again. For the same image data, that cuts the per-second packet count about sixfold — from the tens of thousands toward ten thousand — so the receive path services six times fewer events. One 1500-byte hop anywhere in the path undoes it, silently, from the first frame.

Headroom when jumbo is impossible

Keep the expected data rate below about half of the roughly 115 MB/s a gigabit link actually delivers once headers and inter-frame gaps are paid. Shrink the ROI, lower the frame rate, stream mono 8-bit instead of a 12-bit format. Then raise the driver's receive buffer count and enable the high-performance NIC driver, which moves packet memory off the standard network stack — here is how much it gains. A software trigger that fires seconds late is often the same packet-size problem wearing a different symptom.

A frame grabber for multi-camera cells

Past two cameras, per-port budgets get easier on a frame grabber: the multi-camera bandwidth budget divides the link before any camera is placed. Every gigabit port carries about 115 MB/s of usable payload, so four ports are four independent budgets. The MV-GE1104 is a four-port GigE frame grabber.

When gigabit per link is not enough

10GigE cameras raise the per-link budget by a factor of ten, and the same rules apply: jumbo frames, one camera per port, a budget per link. The MV-GT2104 is a quad-port copper 10GbE NIC.

Worked example: packet budget for a 1920 × 1200 mono 8-bit camera at 40 fps

The inputs, and where each comes from: 1920 × 1200 pixels at mono 8-bit, 1 byte per pixel (the sensor readout and pixel format); 40 fps (the inspection cycle asked of the camera); about 1440 bytes of image data per 1500-byte packet and about 8940 per 9000-byte packet (roughly 60 bytes of protocol header per packet); and about 115 MB/s of usable payload on a gigabit link (125 MB/s line rate less Ethernet, IP, UDP and GigE Vision overhead and inter-frame gaps).

• Frame size: 1920 px × 1200 px × 1 B = 2,304,000 B ≈ 2.30 MB
• Data rate: 2.304 MB × 40 fps = 92.2 MB/s
• Link load: 92.2 ÷ 115 ≈ 80% of usable payload — the stream fits, with about 23 MB/s of headroom for resend bursts
• Packets at 1500-byte size: 2,304,000 ÷ 1440 = 1600 per frame, so 1600 × 40 = 64,000 packets/s
• Packets at 9000-byte size: 2,304,000 ÷ 8940 ≈ 258 per frame, so 258 × 40 ≈ 10,300 packets/s

The decision: at 64,000 packets/s, a 20 ms CPU stall drops about 64,000 × 0.02 = 1280 packets — roughly 1.9 MB of image that comes back as a resend burst on an already busy link. That is the regime where streaks show on a shared desktop port. With jumbo frames the receive path handles 10,300 packets/s, six times less work, and the same host runs the same camera clean. If the path cannot carry 9000-byte frames, run the camera at 30 fps instead: 1600 × 30 = 48,000 packets/s at 69.1 MB/s, which is 60% of usable payload and leaves real headroom. The working margin from this example: 48,000 packets/s ran clean where 64,000 did not, so plan a shared desktop port below about 50,000 packets/s, keep any stream at or below 80% of usable payload, and recompute both whenever the sensor or the frame rate changes.

When the lines are not packet loss

• Fixed position, present in stills. A line that sits in the same pixel rows in every saved image is optics or sensor: dust on the cover glass, a scratch, a dead column. Packet loss moves around; defects stay put.
• Periodic noise in stills too. Banding that appears in captured frames, spaced with the switching of a motor drive, is electrical interference picked up by unshielded cabling or a ground loop. Fix grounding and shielding; the network is innocent.
• No image, or a frozen repeat. A loose or damaged cable gives no image at all rather than streaks; the camera connected but no image checks cover that case.
• Motion smear with intact pixel data. A doubled or dimmed moving edge is motion blur from a long exposure: add light or shorten the exposure and it disappears with the shutter, not with the link.
• Banding tied to the exposure, not the traffic. Pulsed light on a rolling shutter leaves partial-exposure bands that move when the exposure time changes, not when the network load does.

Commissioning checklist

• Set the packet size before the first acquisition and run the test packet — the set-up order for GigE packet size exists for exactly this; negotiating it mid-stream is where mismatches hide.
• Match the MTU on the NIC and every switch port in the path to the camera's packet size, and confirm with one test packet, not by eye.
• Give each camera its own port, and budget about 115 MB/s per gigabit port before the second camera is assigned.
• Watch the lost-packet counters for the first hour at production speed, not just at bench frame rates.
• Use a gigabit-rated cable with solid conductors, shorter than 100 m, latches seated at both ends.
• Keep the stream at or below 80% of usable payload so resend bursts have somewhere to land.
• Recompute the budget whenever a camera or frame rate changes: a sensor with four times the pixels asks for four times the data rate.

The decision for each case

• Streaks only while the scene moves, counters climbing: packet loss. Dedicated port first, then jumbo frames at 9000 bytes end to end, then the budget from the worked example.
• Clean at reduced frame rate, streaks at full rate: the stream is over budget — jumbo frames or a slower stream; pushing resend harder makes it worse.
• Lines in stills at fixed positions: optics or sensor, not the network.
• No image or frozen frames: cabling and link negotiation.
• Two or more cameras: one port each, budget divided in advance, a frame grabber when the ports run out.

If you are sizing a cell now, start from the area scan cameras category and the camera finder, then pick the GigE frame grabbers that carry the host-side ports — the configurator starting at extras walks that part of the chain in order. The systems topic page collects the rest of the GigE diagnostics, and the contact page reaches application support when a live cell needs another set of eyes on its counters.