Onboard H264 motion artifacts: why moving scenes break up

Onboard H264 encoders keep embedded vision streams small, and they do it well until something moves. A still scene records sharp; the moment the part, the conveyor or the robot arm moves, the picture breaks into blocky patches and flicker. This page is for integrators recording from smart cameras and embedded vision modules with hardware encoders. You will compute the bitrate a moving scene actually needs, set it, decide when MJPEG beats H264, and tell an encoder-budget problem apart from a hardware fault.

Why does still video look clean and moving video break up?

The stream is not damaged: a still scene compresses almost for free, while motion multiplies the detail each frame must carry, and a bitrate sized for the still scene — often near 0.05 bits per pixel — cannot follow, so detail is dropped as blocky patches and noise.

An H264 stream is mostly P-frames: each frame stores only what changed since the last one. A static scene changes almost nothing, so the encoder meets its target with room to spare and the picture looks excellent. Motion changes every pixel, and at a fixed target the rate controller has one response — raise the quantization parameter and throw away detail. What reads as noise in a moving clip is quantization error, not sensor noise. The encoder does exactly what the bitrate allows; the target is simply below what the content demands. That is why the same stream that records a bench test beautifully breaks up the moment the camera sees a live line.

Which cause should I check first?

Check the bitrate first: it decides the outcome in most cases, and the test takes a minute — divide the configured bitrate by width x height x frame rate and read the result as bits per pixel per frame against the 0.1-0.2 range.

Work down the list; the first three tests take a minute each.

1. Bitrate too low. Compute bpp = bitrate / (width x height x fps). Below 0.05 the stream breaks up in motion in nearly any encoder; below 0.1 only flat, low-texture scenes survive.
2. Auto bitrate sized for the still scene. Auto modes adapt slowly and hold a target chosen for quiet content. Test: force a fixed target and re-record the same moving scene.
3. Low-latency mode on. Low-latency modes shrink the encoder rate buffer, so motion spikes overshoot before rate control reacts. Test: record with low latency off; the encoded-image pipeline latency guide shows where that buffering hides.
4. Noisy sensor inflating demand. High gain turns noise into detail the encoder must code. Test: add light or exposure time, then re-record.
5. Codec budget shared out. Several encoder instances on one module share codec cores and bus bandwidth; symptoms are empty files, stalls and dropped frames. Test streams one at a time, the way three depth cameras dropping to low fps are isolated.
6. Encoder or firmware fault. Only after the first five: artifacts that persist at 0.3 bpp, or one stream failing alone at a generous target, belong with the vendor's support team.

How many bits per pixel does a moving scene need?

Budget 0.1-0.2 bits per pixel per frame for H264 with motion: the low end holds for mono, low-texture scenes, the high end for color or textured ones, and below about 0.05 bits per pixel motion noise shows in almost any encoder.

The range comes from encoder practice across broadcast and surveillance work: H264 spends most of its bits on motion, and 0.1-0.2 bpp is where moving content reaches watchable to inspection grade. The need scales linearly with resolution and frame rate, so the formula travels between cameras even though a fixed Mbps value does not.

A larger sensor shows the same linearity. At 4056 x 3040 and 30 fps: 4056 x 3040 = 12,330,240 pixels, and 12,330,240 x 30 = 369,907,200 pixels per second. At 0.15 bpp that asks 369,907,200 x 0.15, about 55 Mbps. If the module cannot sustain it, cut the frame rate first: at 15 fps the same sensor needs about 28 Mbps at identical per-frame quality.

How do I set the bitrate so motion stops breaking up?

Set an explicit bitrate of pixels x frame rate x 0.15 bits — for a 640 x 480 sensor at 60 fps that is about 2.8 Mbps — then confirm the encoder holds it while the scene moves; auto modes rarely keep that reserve during motion.

1. Switch rate control from auto to a fixed target and enter the value from the arithmetic above.
2. Leave low-latency off unless the application needs it; where it stays on, raise the target by 20-30% to pay for the smaller buffer.
3. Re-record the moving scene and step through frames at full zoom. Continuous moving edges instead of dissolving 16-pixel squares mean the budget is right.
4. If the module sags under the target — bitrate dips, frames drop — halve the frame rate before cutting quality: the 640 x 480 example falls to about 2 Mbps at 30 fps and about 1 Mbps at 15 fps at 0.2 bpp.
5. Write the value into the startup configuration so it survives reboots; why camera bitrate settings revert after a power cycle explains the mechanism and the fix.

Should I switch to MJPEG instead of fighting H264?

Switch to MJPEG when you need every frame clean and can afford the bandwidth: independent frames end the motion tail, but they cost roughly 3-5x the H264 bitrate at similar quality, which a 640 x 480, 60 fps stream turns into about 7-9 Mbps.

MJPEG codes every frame independently: no temporal prediction means no quality dip after movement starts, and quality holds constant frame to frame. At 0.4 bpp the 640 x 480 example needs 18,432,000 x 0.4 = 7,372,800 bits/s, about 7.4 Mbps. Choose MJPEG for short clips, intermittent motion, textured moving parts that still block at 0.2 bpp H264, or whenever the downstream tools read MJPEG natively — the barcode decoding from RTSP and MJPEG streams guide covers the streaming side.

Why do two of three cameras give empty files when all three encode?

Empty files usually mean the module ran out of hardware encoder instances, not that a camera failed: most embedded SoCs drive a limited number of codec cores, so enable the streams one at a time and keep the total bitrate within the module's codec budget.

If all three encode alone but fail together, the total exceeds the budget: three 4 Mbps streams push 12 Mbps through one codec block. Encode only the streams that leave the module and keep locally processed ones raw, or split streams across modules. A stream that stays empty on its own at a generous bitrate is a support case, not a settings problem.

How do I verify the fix and keep it from coming back?

Verify with a moving test target and a frozen bitrate: record the pattern while it swings through the frame, step through the file frame by frame at full resolution, and check the stream's measured bitrate stays within about 10% of the value you set.

Read back what the encoder really negotiated from the stream headers — extracting SPS and PPS from an H264 stream shows how. For multi-camera rigs, the multi-camera disk recording guide covers the recorder-side budget.

The decisions, per case: a still-heavy scene that already looks clean at 0.05 bpp needs nothing. A moving scene gets pixels x fps x 0.1-0.2 bits — mono at the low end, textured color at the high. A module that cannot sustain the target loses frame rate first, then ROI, then moves to MJPEG at 0.3-0.5 bpp. Streams beyond the codec budget move to raw streaming with a host encoder — the simplest path to reason about, because the encoder lives on the host where you set every value. Browse the area scan cameras and board-level cameras, use the camera finder or start the camera configurator; more stream-side debugging sits on the systems topic page.

For help matching a camera and an encoder path to your frame rates, contact the applications team — expert support comes with every order.