IP camera video acquisition in LabVIEW: DirectShow vs snapshot URL

An Ethernet IP camera ships MJPEG or H.264 over RTSP or HTTP. It is not a GigE Vision or GenICam device, so LabVIEW's vision acquisition does not list it, and no amount of IMAQ wiring makes it appear on its own. There are two workable paths, and they solve different problems: install a DirectShow source filter that speaks the camera's stream and presents it to IMAQ as a local capture device, or skip the stream and pull single frames from the camera's HTTP snapshot URL. If you are wiring a network camera into a LabVIEW vision application, this guide gives you the decision rule, the setup steps for both paths, and the bandwidth, decode and latency arithmetic that decides which one survives on a production floor. It ends where both paths hit a hard limit — triggering and synchronization — and with the camera choice that removes the problem entirely.

Choose the path before you write code

Pick by use, not by convenience. The two paths deliver different things to your block diagram:

The decision in one line: monitor with the filter, measure with snapshots, and if a frame must be triggered or time-aligned, buy a GigE Vision camera instead — a GigE Vision device such as those in the area scan cameras category enumerates directly in the vision acquisition path, with no filter and no decoder.

What you need

• The camera's IP address, login and stream settings from its web interface.
• Its snapshot URL and, for the filter path, its RTSP or MJPEG URL.
• A DirectShow source filter that speaks that stream protocol; camera vendors and third parties publish these, and the filter must match the codec the camera emits.
• LabVIEW with the IMAQ vision functions for capture and processing.
• A wired Ethernet segment. Wi-Fi jitter shows up directly as frame jitter in both paths.

Path 1: live video through a DirectShow source filter

DirectShow is the Windows capture API that IMAQ's video functions read from. A source filter wraps the camera's network stream and registers itself as a capture device, so LabVIEW sees the IP camera next to any webcam or USB capture device and opens it like a local camera.

1. Install the filter on the acquisition PC and restart LabVIEW so it re-enumerates capture devices.
2. Test the filter outside LabVIEW first: open the camera in any DirectShow-based player and confirm you get a picture at the resolution and frame rate you set in the camera's web interface.
3. In LabVIEW, enumerate the video sources with the IMAQ video functions; the IP camera appears as a local device.
4. Open the source and select the video mode that matches the camera's stream. The encoder produces fixed resolutions and frame rates, and requesting a mode the stream does not contain is the most common black-screen cause.
5. Grab in a loop and hand frames to your processing. For a worked processing loop on a live MJPEG feed, the barcode decoding from a live video stream guide shows the pipeline end to end.

Verify: point the camera at a running stopwatch. The offset between the stopwatch face and your acquired frame is your true latency; expect between half a second and two seconds with surveillance-grade encoder settings.

If the stream stalls or tears, the usual causes are the camera's web interface holding the only stream session (small cameras serve one or two clients), a codec the filter needs missing on the PC, or a mismatched video mode. Finding and testing the stream URL itself is covered in Acquire an RTSP stream from an IP camera in your vision program, which wires the grab loop for general image-processing code; this section is the LabVIEW side of the same connection.

Path 2: stills from an HTTP snapshot URL

Nearly every IP camera also exposes an HTTP endpoint that returns exactly one JPEG. No filter, no codec install, no decoder dependency: your program controls the pace, and every image is a complete frame.

1. Find the snapshot URL for your model. The camera's HTTP API documentation defines it, and finding the MJPEG CGI URL on an IP camera when RTSP fails shows how to dig it out of the web interface when the documentation stops.
2. Add credentials if the endpoint requires them — the MJPEG stream URL with username and password guide covers the syntax — then test the URL in a browser: one full image should download.
3. In LabVIEW, call the HTTP client functions with that URL and read the response body as a byte string.
4. Decode the JPEG bytes with the IMAQ function that reads an image from a memory buffer. From there it is an ordinary IMAQ image.
5. Timestamp each grab on arrival and drive the request from a timed loop.

Verify: successive timestamps sit at your loop period, and covering the lens changes the decoded histogram within one cycle.

Two mistakes account for most failed polling loops. First, polling faster than the camera's internal frame rate returns the same frame twice and doubles your decode for nothing, so set the period to at least the camera's frame time. Second, opening a fresh connection on every poll can trip the camera's client limit; reuse the HTTP connection where the camera allows it. The timed-loop pattern with its pacing arithmetic is laid out in HTTP snapshot URL polling: IP camera still image on a timer.

Bandwidth and decode: the numbers that decide

Both paths live or die on decode cost, not on network size. Two estimates carry every sizing decision:

Worked example — one 1920 × 1080 MJPEG stream at 15 fps:

• Raw frame at 2 bytes per pixel (YUV 4:2:2): 1920 × 1080 × 2 = 4,147,200 bytes ≈ 4.15 MB.
• Before compression: 4,147,200 × 15 = 62.2 MB/s ≈ 498 Mbps. At a typical 10:1 JPEG ratio that lands near 50 Mbps per camera.
• Decoded into RGB for processing: 1920 × 1080 × 3 = 6.22 MB per frame, so 6.22 MB × 15 = 93 MB/s of continuous pixel traffic per stream.

Scale it: ten streams ≈ 930 MB/s of memory traffic plus ten decoder pipelines. Twenty streams need about 1 Gbps of wire, but the CPU gives out first — split the load across PCs, or push inspection onto the cameras themselves.

The same camera polled as snapshots: the still is a JPEG of one frame, roughly 4.15 MB / 10 ≈ 415 KB. At 2 polls per second that is 415 KB × 2 × 8 ≈ 6.6 Mbps per camera — twenty cameras ≈ 132 Mbps, trivial for a GigE switch — and decode happens only in 6.22 MB bursts at grab instants.

H.264 changes the wire, not the math: a 1080p camera at typical surveillance quality runs 2–8 Mbps per stream, so twenty fit on one link, but each frame still decodes to the same 6.22 MB and the encoder chain adds the latency below. The decoder side of H.264 in LabVIEW is its own subject; the H.264 video acquisition and decoding in LabVIEW walkthrough covers the decode setup end to end.

Latency: how far behind reality your frame is

The filter path inherits the encoder chain. The camera holds a group of pictures — I-frame intervals of 1–2 s are common in surveillance settings — B-frames wait for future frames, and several frames sit in buffers before delivery. Half a second to two seconds of lag is the normal outcome, and it grows with the GOP length you set in the camera.

The snapshot path replaces all of that with your own pacing: staleness averages half your poll period and never exceeds it. Poll at 2 Hz and the average frame is 250 ms old, worst case 500 ms, plus one camera frame time.

Put a number on the cost. A part moving at 100 mm/s travels 100 mm/s × 0.5 s = 50 mm between scene and image at worst-case 2 Hz polling. Monitoring does not care. A measurement that must locate that part does.

Trigger and sync: the hard limit of both paths

Neither DirectShow nor HTTP exposes a trigger. There is no line that starts an exposure, no way to choose the exposure time, and no timestamp you can align across two cameras — frames arrive on the encoder's schedule. If a photoelectric sensor says a part is present and you grab whatever arrives next, your image position error is sensor-to-frame latency multiplied by part speed.

Software gating helps monitoring but not metrology: grab continuously and process only while the sensor input is active, and the motion blur is still whatever the camera chose. Blur you can compute as blur = part speed × exposure time, so 100 mm/s × 10 ms = 1 mm — acceptable for a 10 mm feature, not for a 0.5 mm one.

When the inspection needs a triggered, motion-free frame, that is a GigE Vision camera: its opto-isolated trigger input fires the exposure at the sensor, the frame rate is deterministic, and the device enumerates in the vision acquisition path like any GenICam camera. The GenICam line settings behind a hardware trigger are what you would configure, and the Python hardware trigger grab loop shows the acquisition shape this enables outside LabVIEW.

When the camera choice is still open, remove the problem

If nothing has been purchased yet and the frames feed a decision, skip both workarounds and buy the supported path. The MV-CU020-90GC is a 2.5 MP color GigE camera with a global shutter: it enumerates directly, triggers on a hardware line, and costs the PC no decode at all.

If there is no room for a PC in the cell, the smart cameras family runs inspection on the device. The LS-SMC-0063 smart camera runs 60 fps inspection with its 16 mm lens and ships the verdict over the network, so nothing ever needs decoding on a host.

Keep the IP camera where it belongs: retrofit monitoring, remote sites, operator displays.

Checks before you commit

• Stopwatch latency on both paths, measured at production camera settings.
• Decode CPU at your full stream count for an hour; thermal throttling appears late, not in a two-minute test.
• Two simultaneous clients: open the camera's web interface while LabVIEW streams, and confirm the camera serves both. Small cameras often allow only one or two sessions.
• The snapshot still's pixel dimensions: some cameras return a scaled image unless the size parameter in the URL is set, so check what actually arrives.
• Recompute the bandwidth table with your camera's real frame size and frame rate from its stream settings; every number above moves with those two values.

More acquisition patterns sit on the systems topic page, and the camera finder narrows cameras by interface, resolution and shutter in a few clicks.