Camera over Ethernet: raw pixel data into GPU memory

A camera that feeds a GPU pipeline spends most of its life moving bytes, not computing on them. Push a large sensor's stream through a conventional network stack and every packet is processed by the kernel, buffered, copied into your application, then copied again across PCIe onto the card — at millions of packets per second. Camera over Ethernet is the lean alternative: raw pixel data packed into UDP payloads and written by the network card straight into GPU memory, with the CPU out of the data path. This guide explains how the direct path works, sizes a realistic stream by the numbers, and shows where it beats a standard GigE Vision stack — and where the standard stack is still the right answer.

What camera over Ethernet actually is

Camera over Ethernet (CoE) is a transport protocol, not a camera interface standard. It encapsulates raw pixel data in UDP payloads riding on ordinary Ethernet frames: no compression, no feature database, no re-request logic inside the stream — just pixel bytes in a known layout, packet after packet.

The sending side is typically an FPGA-based sensor bridge. It takes the camera's parallel or serial data in, chops each frame's lines into UDP payloads, and stamps sequence numbers so the receiver can spot gaps. The receiving side is a network card built for the pattern: its DMA engine writes the payloads directly into GPU memory instead of into kernel socket buffers.

Setting the stream up — sensor format, packet size, destination address — happens once, through the bridge's configuration tools. Only the continuous pixel stream skips the CPU. That is the whole trick: GigE Vision, the standard behind most area scan cameras, spends part of every packet's handling on discovery, GenICam feature access and the resend mechanism that recovers lost packets. CoE strips those services out of the data path and leaves the payload.

How the packets reach GPU memory without the CPU

The default route for a network camera on a general-purpose host is long. Each packet crosses the NIC's interrupt, the kernel protocol stack, a socket buffer, a copy into application memory and a final copy across PCIe onto the GPU. Every hop costs CPU cycles and adds latency; the camera-to-GPU data transfer guide measures what the copies cost.

The direct path removes the middle. The NIC's DMA engine is told once where the GPU's receive buffers live, and from then on it writes each UDP payload there itself. The application reads finished frames and never touches a packet. Per-packet CPU cost drops to nearly nothing, which is what lets one host carry several high-rate cameras at once.

Two conditions have to hold. The NIC and platform must support peer-to-peer DMA into GPU memory; a card without it delivers to kernel memory and you pay the copies anyway. And on compact embedded hosts, where the GPU and the camera share one small pool of DDR, that pool must be planned before the stream starts — there is a worked reserved-memory setup for GPU and camera on an embedded board covering exactly that case.

Sizing the link for a 25 MP camera at 60 fps and 8-bit pixels

The inputs: 25,000,000 pixels per frame (the size class of the larger area scans on this site), 60 frames per second (a sorting or guidance loop rate), 8-bit mono output, a four-lane 25 Gbit/s Ethernet link (the transport class this protocol targets, 100 Gbit/s in total), and ordinary 1,500-byte UDP payloads.

The rule in words: multiply pixels per frame by frames per second by bits per pixel to get the payload rate; add protocol overhead to get the line rate.

The arithmetic:

• 25,000,000 px × 60 frames/s = 1,500,000,000 px/s
• 1,500,000,000 px/s × 8 bit = 12,000,000,000 bit/s = 12 Gbit/s of payload, or 1.5 GB/s
• 12,000,000,000 bit/s ÷ 12,000 bit per packet = 1,000,000 packets per second — the rate a kernel stack would chew through, and the reason the direct path exists
• each packet carries 62 bytes of preamble, headers and inter-frame gap, so efficiency is 1,500 ÷ 1,562 ≈ 0.96 and the line rate needed is 12 ÷ 0.96 ≈ 12.5 Gbit/s
• the link carries 4 × 25 = 100 Gbit/s, so headroom is 100 ÷ 12.5 ≈ 8×

Raise the output to 16-bit pixels and the stream doubles to 24 Gbit/s of payload, about 25 Gbit/s of line rate — still a quarter of the link.

Decision: this case clears the multi-gigabit threshold. One 10GigE port moves an effective payload of about 9.6 Gbit/s, enough for 9.6 Gbit/s ÷ (25,000,000 px × 8 bit) ≈ 48 fps — short of the 60 fps target. The 100 Gbit/s link carries the camera eight times over, with room to double the frame rate and double the pixel depth before the link, not the protocol, becomes the limit.

Where the direct path earns its keep

Three situations pay for the specialized transport.

Large sensors at real frame rates. Once the payload rate crosses roughly 9.5 Gbit/s — the working capacity of one 10GigE port — the CPU struggles before the wire does. GPU inference, 3D reconstruction and holographic capture all sit above that line.

Latency-critical guidance. In a pick cell, each memory copy between wire and GPU adds delay to the control loop. The wire itself already sets a floor — the link-bandwidth latency floor guide works it out — and direct DMA removes everything stacked above it.

Several cameras, one host. When two or more high-rate cameras share a machine, the port layout follows the budget, not the software; the multi-camera GigE bandwidth budget divides the link first. The same bridge pattern also carries non-camera sensors — anything that emits time-stamped sample blocks — onto one synchronized stream.

When the standard GigE Vision stack is the right answer

Below roughly 1 Gbit/s of payload, the direct path is machinery you do not need. A 2 MP sensor at 30 frames per second with 8-bit pixels produces 2,000,000 × 30 × 8 = 480,000,000 bit/s — half of a gigabit link's capacity, a light load for a modern network stack. Tuned drivers close most of the remaining gap on standard hardware; the high-performance NIC driver measurements show how much a driver swap alone buys. You keep discovery, the GenICam feature model and packet resend — and a compact global-shutter camera like this is exactly the class that fits:

On a dedicated, managed link with the MTU set end to end, loss is rare and the validation is a formality. When torn or blank frames do appear, the packet-loss diagnostics guide walks the usual causes in order.

Hardware that carries a stream like this

For a stream above one gigabit, the camera side is a 10GigE model with a global shutter:

The MV-CH250-25TC-F-NF is a 25 MP 10GigE camera with a global shutter and an F-mount. In the worked example's terms, a 25 MP camera at 8-bit output saturates one 10GigE port near 48 fps; the direct path over a wider link is what lifts that ceiling. The camera finder filters by interface, so narrowing to the 10GigE class takes one step.

On the host side, a multi-port card carries the streams in; both of these are 10GigE parts:

The quad-port card suits multi-camera hosts; the dual-port frame grabber suits a smaller build. Beyond that class sit frame grabbers with more ports or interfaces a network card does not speak — the accessories finder filters by interface and port count. If the whole station still needs sizing, the configurator starts at the camera and walks the capture side in order.

Checks before you commit

• Run the multiplication first. Pixels per frame × frames per second × bytes per pixel picks the port; everything downstream follows it.
• Confirm the receive path. The NIC and platform must support writing UDP payloads into GPU memory, or the stream lands in host RAM and the CPU still pays per packet.
• Reserve memory on embedded hosts. The shared DDR pool has to cover camera buffers and GPU working space at once.
• Set the MTU end to end. Jumbo payloads cut per-packet work by a factor of six at 12 Gbit/s.
• Size buffers to the DMA pitch. If the application reads a frame at the wrong row stride, the access fails; the GPU frame pitch and planes guide shows the failure and the fix.
• Give each camera its own port. On multi-camera hosts, divide the link budget before writing any code.

If you send us the three inputs — pixels per frame, frames per second, bytes per pixel — we will size the link and the receive side with you; free expert support comes with every order. More host-side networking lives on the systems topic page.