Encode two H264 streams on one embedded VPU: budget the bitrate

Two cameras, one hardware encoder: the recurring question on a single-VPU embedded board is whether it can write two H264 files at the same time or whether a second encoder chip is needed. It can, frame by frame, as long as the combined pixel-per-second load stays inside the rating. This guide gives the arithmetic behind that budget: pixels per second per stream, the bitrate and file-size math for the write path, a worked two-camera rig with orderable parts, and the sustained capture test that proves the design.

One engine, two streams: how the sharing works

A VPU is fixed-function encoding silicon with a rated throughput, not a general-purpose processor. Each recorded file runs as its own encoder instance, and the silicon schedules the instances frame by frame: camera A's frame, then camera B's, then A again. The streams interleave rather than run in parallel lanes, so per-stream latency rises slightly while both files stay complete.

Two hard limits follow from that design. Each stream must fit the engine's per-instance frame-size cap on its own, and the combined pixel rate across both instances must stay under the engine's throughput rating. For a single-VPU part in this performance class, the documented rating is two concurrent 720p30 H264 streams — one per camera. Everything below is checked against that budget.

In GStreamer the structure does not change from the single-camera case: one pipeline per camera, each ending in the board's hardware encoder element and a file sink, with the encoder driver multiplexing both pipelines onto the one engine. What changes is how close the sum of the two loads sits to the rating.

The load budget: pixels per second

Convert every candidate stream to pixels per second and add them up. The documented two-stream rating works out to a fixed number: 1280 × 720 × 30 = 27.65 Mpixel/s per stream, so the combined budget is 55.3 Mpixel/s. Any stream set under that total, with each stream inside the per-instance frame cap, fits.

The table settles the common confusion. One 1080p60 stream is 124.4 Mpixel/s — 2.25 times the work of two 720p30 streams (124.4 / 55.3) — so an encoder that handles two HD cameras does not thereby handle one fast HD stream. Frame rate scales the load linearly, which is why one 1080p stream at 24 fps drops under the budget at 49.8 Mpixel/s. A 4K30 stream at 248.8 Mpixel/s is 4.5 times over and is not a hardware job on this class of part.

The bitrate budget: what reaches the disk

Frame capacity is budget one; bitrate is budget two. Bitrate sets picture quality per stream and the continuous data rate the storage path must carry. Derive the starting point from a reference instead of guessing. A documented H264 monitoring deployment runs about 10 Mbit/s per stream at 1080p-class resolution, and a 720p frame carries 44% of a 1080p frame's pixels (921,600 / 2,073,600 = 0.44), which puts the equivalent 720p30 figure at about 4.4 Mbit/s. Start at 4 Mbit/s constant bitrate (CBR) per stream.

Two 4 Mbit/s streams write 8 Mbit/s, which is 1 MB/s sustained — far under any industrial SSD's write rating, so storage never sets this limit; the encoder does. CBR keeps the write path flat. Variable bitrate averages the same rate but spikes on scene changes, and two encoders sharing one engine and one disk can spike together — buffer overruns are the result. Constant-bitrate overshoot on single-VPU boards is a known failure pattern, and this CBR bitrate overshoot reference for hardware H264 encoders covers the symptoms and fixes.

Too little bitrate fails differently: moving parts smear and break into blocks while static scenes look fine. That failure mode is covered in why moving scenes break up in onboard H264. Profile choice buys quality back at no load cost — main or high profile typically gives 20-30% better quality than baseline at the same bitrate — and after the first encode you can read the profile and level the encoder actually emitted, as shown in extracting SPS and PPS NAL units from an H264 stream. For the encoder-side settings themselves, this walkthrough on setting the H264 profile on an embedded VPU encoder shows where they live. Treat the two CBR allocations like any shared-host budget: two GigE cameras on one host NIC applies the same per-stream-plus-total discipline to network bandwidth.

A worked two-camera rig

Here is the budget applied to a real station: continuous evidence recording from two compact cameras while the same box runs the inspection application. Board-level cameras are the natural fit for a build like this, and the board-level camera selection guide for embedded vision machines covers the mount, interface and shutter trade-offs before you commit.

The two cameras:

The MV-CB016-10GM-M-W is a 1.6 MP GigE board-level camera with a global shutter and an M12 lens mount. The LS-BCM-0003 is a 3.1 MP USB3 board camera with an IMX252 sensor and a 120 fps rating.

Run each stream at 1280 × 720 and 30 fps and both land on one budget: 27.65 Mpixel/s per camera, 55.3 Mpixel/s combined — exactly the rating, with zero margin. For margin, run both at 25 fps (2 × 1280 × 720 × 25 = 46.1 Mpixel/s, about 17% headroom) or drop one camera to VGA at 60 fps. The USB3 camera's 120 fps rating is trigger headroom, not continuous duty: switch it to 640 × 360 at 120 fps for a short event and its load is 230,400 × 120 = 27.65 Mpixel/s — quarter the pixels of 720p at four times the rate, the same budget as one 720p30 stream.

Recording lands on a controller rather than a bare board. The MV-VC2140-128G40-1T is an N97-powered vision controller with 8 GB of memory, 3-4 LAN ports, 2 USB3 ports and 4 built-in light-output channels — enough ports for both cameras plus a network uplink.

This tier has no dedicated H264 engine, so the two streams encode in software on the processor's cores. A rule of thumb from general encoder practice: x264-class software encoding holds 720p30 in real time on one to two modern cores per stream. Plan four cores for the two streams, keep the rest for inspection, and if the same box also runs deep-learning checks, step up a tier:

All 3 share: Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

Read the comparison against the workload: 8 GB of memory carries recording plus rule-based inspection, 32 GB with the larger processing budget suits a box that also runs deep-learning inference, and the mid model includes a VM6200Pro vision license.

When software encoding wins, and when it loses

• Keep the hardware encoder when latency must be deterministic, power is limited, or the CPU must stay free for inspection — two streams at or under 720p30 is exactly its shape.
• Go software when one stream is high-resolution but slow (1080p24), when recording duty is uneven — one continuous stream plus a short trigger clip — or the board has idle cores anyway.
• Move up a class when both demands grow together: several recorded streams and inference on the same box.

Capacity at the top end is quoted in stream units: current accelerator cards publish up to 16 concurrent 1080p60 streams, and the same pixel-per-second math prices your job in those units, because one 1080p60 equals 2.25 two-720p30 budgets (124.4 / 55.3). The software route scales with cores and memory you can order; the hardware route scales with nothing. That is the whole trade.

Prove it before shipping: the four-hour test

Short demos pass and production fails because the failure modes accumulate: encoder queues back up under burst load, a passively cooled chassis reaches thermal steady state after the first hour, and write contention appears only when other processes run. The test costs a few hours of bench time; the field failure costs a returned system.

1. Start both pipelines at target settings — resolution, frame rate, CBR bitrate — writing to the target storage volume.
2. Run at least four hours. At 30 fps that is 30 × 3,600 × 4 = 432,000 frames per stream.
3. Count encoded frames against captured frames for each stream. Any difference is a dropped or duplicated frame.
4. Log the encoder-queue or overrun counters the BSP exposes, plus CPU load and chassis temperature.
5. Decode both files end to end and check the profile and level in the stream headers.

Pass means zero missing frames, a flat bitrate trace, and a stable temperature over the last hour. Re-run the test after any change to resolution, frame rate or bitrate: the arithmetic bounds the design, and the test proves it.

The decision, case by case

• Two cameras, each at or under 720p30: encode both in hardware. Set 4 Mbit/s CBR per stream and confirm with the four-hour test.
• One 1080p24 stream: still hardware — 49.8 Mpixel/s fits with about 10% headroom.
• One 1080p60 or 4K30 stream: not this encoder. Cut to 1080p at 24 fps, drop resolution, or move the job to software or a stronger box.
• Recording plus deep-learning inspection on one controller: software encoding with a four-core plan, or the 32 GB tier from the comparison above.
• Undecided: build both pipelines and let the 432,000-frame count decide.

For parts, start from the board-level cameras and vision controllers categories, or build the camera side in the camera configurator. The systems topic page collects the rest of the integration arithmetic, from NIC budgets to trigger timing, and if the budget does not close for your stream set, contact the applications team with your resolutions and frame rates.