Record video from a camera feed for inspection traceability

Traceability clips answer the question that arrives months later: what did the camera actually see when this part passed? A short MP4 per inspection cycle, saved next to the pass/fail result, settles customer disputes and shows new operators what a good part looks like. This guide walks through recording a camera feed into MP4 clips on a standard machine-vision set-up: choosing the pixel format and frame rate the encoder expects, sizing the bitrate, and planning storage. The worked example sizes a 6-second clip at 1280 × 1024 and 30 fps, then turns that into a per-shift storage number you can order against.

What you need

A recording set-up needs four things: a camera your software can pull frames from, a host that keeps up with the stream, an MP4 encoder, and storage sized to your clip rate. Any of the shop's area scan cameras streams frames through the standard machine-vision APIs, and a vision controller bundles the camera ports and the archive disk in one fanless box.

For the encoder, use the record function in your vision software or a VideoWriter-style library; both take finished frames and compress them. The Python recording walkthrough covers the capture loop in full — this guide adds the sizing and the checks that keep the file playable.

For full-rate color clips over USB3, the LS-CMR-0166 reads 4000 × 3000 at 30 fps. A 1280 × 1024 clip at the same rate uses a small slice of that headroom.

Set the pixel format and frame rate first

Encoders consume finished 8-bit frames: three-channel BGR for color, one channel of gray for mono. Feed a writer raw Bayer or 16-bit data and it either refuses the frame or writes a header with zero playable frames — the BGR frame requirement is the top cause of empty recordings.

Convert color on the host, not on the wire. A practical GigE link moves roughly 100 MB/s of image data, and pulling already-converted BGR from a GigE camera can halve the delivered frame rate; the Bayer versus BGR comparison shows the arithmetic. Grab Mono8 or Bayer on the wire and convert in host memory.

Lock the frame rate before you open the writer. Set the camera's acquisition frame rate, keep exposure below the frame period — 33.3 ms at 30 fps, so aim for 25 ms or less — and hand the writer exactly that rate. Camera attributes move together: changing pixel format can halve the frame rate, and exposure limits the RGB frame rate.

Size the bitrate before you record

Two settings fix the file size: quality per pixel and clip duration. Encoders target a bitrate, and bitrate is pixels times frame rate times bits per pixel:

Plan 0.75 to 1 bit per pixel when someone may pause the clip to read an etched marking, serial or date code; small text stays legible on a still frame at that level. If the clip only has to show motion (part present, arm moved, guard closed), 0.2 to 0.4 bits per pixel reads fine and cuts the file by more than half. Constant-bitrate mode makes storage predictable; variable-bitrate mode spends fewer bits on flat background frames.

Duration follows the cycle. A triggered clip covers about two seconds before the trigger plus a few after, which lands most inspection clips between 4 and 8 seconds.

Worked example: a 6-second clip at 1280 × 1024 and 30 fps

The inputs, and where each comes from:

• Clip window: 1280 × 1024 pixels, a typical cropped machine-vision ROI.
• Frame rate: 30 fps, the locked camera rate.
• Duration: 6 s — 2 s of pre-trigger buffer plus 4 s after the trigger.
• Quality target: 1 Mbit per frame, the pause-and-read planning range for legible markings.

The rule in words: clip size equals bitrate times duration, and bitrate equals pixels times frame rate times bits per pixel.

1. Pixels: 1280 × 1024 = 1,310,720.
2. Bits per pixel at the target: 1,000,000 ÷ 1,310,720 = 0.76, inside the 0.75–1 pause-and-read range.
3. Bitrate: 1 Mbit per frame × 30 fps = 30 Mbit/s. Cross-check: 1,310,720 × 30 × 0.76 = 29.9 Mbit/s.
4. Clip size: 30 × 6 ÷ 8 = 22.5 MB per clip.
5. Frames per clip: 30 × 6 = 180.

The uncompressed feed is the other number to check. BGR8 at this window is 1,310,720 × 3 bytes = 3.93 MB per frame, which is 118 MB/s at 30 fps — past a practical GigE link and easy for USB3. On GigE, grab Mono8 or Bayer instead: 1.31 MB × 30 = 39.3 MB/s on the wire, converted to BGR in host memory. The 22.5 MB result lands in the same size class as real 6-second clips of this kind, about 23 MB.

Decision: at one part every 10 s the line writes 360 clips per hour — 360 × 22.5 MB = 8.1 GB per hour, or 64.8 GB per 8-hour shift. That is the number to order against. Below about 60 GB per shift a plain SSD or HDD archive runs untouched; above it, add bulk storage or cut the bitrate. Dropping to 15 Mbit/s (0.38 bits per pixel, fine for motion review) halves the load to 32.4 GB per shift.

Drive sizes here are decimal (1 TB = 1,000 GB).

The archive writes at only 3.75 MB/s (30 Mbit/s ÷ 8), so bulk storage is a hard-drive job while the operating system lives on an SSD. The MV-VC2140-128G40-1T vision controller pairs a 128 GB SSD with a 1 TB HDD and carries four built-in light channels. At 64.8 GB per shift, that HDD holds about 15 shifts of clips before any offload.

The capture loop, step by step

Wire the loop once and it runs for the life of the station. The same structure works on an embedded board with hardware codecs — writing MP4 from a camera on an embedded board walks that variant.

1. Set the camera pixel format to 8-bit: Mono8 for mono sensors, Bayer for color with host-side conversion.
2. Lock acquisition to 30 fps and hold exposure at or under 25 ms so readout keeps margin.
3. Open the writer with a four-character codec tag — avc1 or H264 for H.264, mp4v as a fallback — the locked frame rate, and the exact frame size, 1280 × 1024.
4. Each cycle: grab, convert to 8-bit BGR, write, and check the writer's return. A failed write means a format or size mismatch; the empty-recording checklist lists the usual culprits.
5. Count frames as you go and close the clip at 180 frames (6 s at 30 fps). Release the writer before anything reads the file — a process killed with the file open produces the unplayable-file failure.
6. Prove it: reopen the clip, read the frame count (about 180) and duration (about 6.0 s), check the size on disk (about 22.5 MB), and time one playback against a watch.

Record only the inspection moment

Continuous recording turns traceability into filing work. Trigger instead: keep a ring buffer of the last 60 frames in memory — 2 s × 30 fps × 3.93 MB = 236 MB of RAM — and when the part-present trigger fires, write the buffered 60 frames plus the next 120 (4 s). The disk sees one 180-frame, 22.5 MB clip per part and nothing else.

The trigger that fires the light can start the clip too: triggering a vision light at the inspection moment shows the same pattern on the lighting side.

If the part moves under the trigger, a rolling shutter skews the image and motion blur softens it. The clip records that faithfully, which is honest traceability, but a global shutter gives a crisper still. The MV-CU020-90GC is a 2.5 MP global-shutter GigE camera with a 1/1.7" sensor in a C-mount.

Checks before you trust a clip

Run one recorded cycle with the line stopped, then one at full speed, before the archive goes live. Then, per clip:

• Frame count: reopen and count — about 180 for the example. Fewer frames means dropped frames; hunt the stall in conversion or disk writes before production.
• Playback speed: time 10 s of footage against a watch. A mismatch means the writer's fps does not match the delivery rate.
• Pause legibility: stop on a marking frame at 1:1 zoom. If text smears, raise the bitrate rather than the resolution.
• Size sanity: flat conveyor background compresses well under the target and full-frame texture above it, so tens of percent off 22.5 MB is normal with variable bitrate. A file stuck near zero kilobytes is broken, not efficient.

Common mistakes that write empty files

• Raw Bayer or 16-bit frames fed straight into the writer — convert to 8-bit BGR or gray first.
• Writer fps copied from a camera attribute that reads zero — use the reliable frame-rate method instead.
• Writer frame size one dimension off from the frames — encoders drop every frame rather than rescale.
• No close on exception — close the writer in the code path that always runs, and keep clips short so a crash costs seconds, not hours.
• Expecting sensor depth to survive — why 10-bit sensors ship 8-bit images explains the converter stage the clip inherits.

When video is the wrong record

MP4 is 8-bit and lossy, so the clip is context, never the measurement. Save a full-resolution lossless still — PNG or BMP — for every measured part, and let the MP4 carry what a still cannot: how the part moved, what the operator did, what the light did. When data must be re-processed later at full depth, use a frame container or image sequence; recording 12-bit grayscale without dropping to 8 bits covers the lossless path, and planning raw capture at 2000 fps shows the data-rate arithmetic once you outgrow an encoder.

Record the crop the inspector needs. Feeding the encoder 1280 × 1024 out of a 4000 × 3000 sensor spends the bits on the part instead of the conveyor background — same clip length, more usable detail.

Build the recording station

The decision in five numbers: 8-bit frames, 30 fps locked, 30 Mbit/s target, 22.5 MB per 6-second clip, 64.8 GB per shift at one part every 10 seconds. Choose USB3 for full-rate color or GigE with host-side conversion, and give the archive a bulk drive. The camera finder filters by interface, shutter and resolution; the vision controller category lists recording hosts by ports and storage, and industrial mini PCs cover the general compute side when you need more than the camera set-up. More capture-and-record guides sit on the systems topic page, and expert support comes with every order — tell us your cycle and we will size the archive with you.