H.264 Camera Module: How Vadzo Imaging Cameras Compress Video on Board
An uncompressed 1080p30 stream in YUV422 carries about 124 MB per second; a USB 2.0 link sustains roughly 40 MB per second. The two numbers do not meet, and closing that gap on the board is the whole job of an H. 264 camera module. Vadzo Imaging builds sixteen of them across USB and GigE, from the 1080p Merlin-290CRS to the 13MP Innova-1335CRA, each encoding before the data reaches your host. What follows is the arithmetic and the specifications behind every Vadzo H. 264 camera module
What Is H.264, and Where Does It Run on a Camera?
A video compression standard, also called AVC, that stores the differences between frames rather than every frame in full.
What matters for a camera is where it runs. On an embedded module, the encoding happens on the board, in a hardware video encoder between the image pipeline and the interface. That hardware video encoder has two consequences you inherit: the host receives compressed data rather than pixels, and the settings belong to the camera rather than to your software. Anything the camera discards is gone before your application sees the frame.
Profiles and levels cap resolution, frame rate, and bitrate. For an embedded design, the question is not which profile is best but which one your host decodes in hardware, because a software decode on a small SoC costs more than the encoder saved.
How Does H.264 Compress Video Inside the Module?
How does h.264 compresses video comes down to two stages: redundancy inside each frame, then between frames. The second produces nearly all of the savings, because consecutive frames of a real scene are mostly identical.
I-Frame and P-Frame
An I-frame is a complete, self-contained image, compressed much as a JPEG is. A P-frame is not an image at all: it describes how the picture changed since the previous frame, as motion vectors plus a residual. The I-frame and P-frame split is the core of the format.
A P-frame is typically five to ten times smaller than the I-frame it depends on. That ratio is where the compression comes from, and it is the weakness: a P-frame is meaningless without the frames before it. The I-frame and P-frame chain is why a single lost packet is expensive.
Keyframe Interval and GOP Length
Because P-frames depend on what came before, the camera inserts a fresh I-frame periodically. That spacing is the keyframe interval camera setting, and the run from one I-frame to the next is the gop length setting; the same instruction from two directions, so a keyframe interval camera value of 60 and a gop length setting of 60 mean the same thing.
A typical GOP is 30 to 60 frames, so at 30 fps, a new I-frame every one to two seconds. Longer compresses better; shorter recovers faster from a lost packet. Recording favors long, live viewing; a poor link favours short.
The H. 264 compression ratio follows. A 1080p30 stream at 1 Gbps raw encoded at 6 Mbps gives an H. 264 compression ratio near 165 to 1; at 4K, 4 Gbps down to 20 Mbps is close to 200 to 1. Every discarded bit was image information your sensor captured.
How Much Bandwidth Does a 1080p Camera Need?
How much bandwidth does a 1080p camera need depends on whether it is compressed. Uncompressed, about 124 MB per second at 30fps and 249 MB per second at 60fps. Compressed at good quality, roughly 4 to 8 Mbps and 8 to 12 Mbps, which is 0.5 to 1.5 MB per second.
The arithmetic is simple enough to do rather than assume: width by height by bytes per pixel by frame rate. YUV422 is two bytes per pixel, so a 4K30 camera is about 498 MB per second, close to 4 Gbps. No embedded camera interface except USB 3.2 Gen 1 carries that, and even there, nothing is spare.
Chroma subsampling 4:2:0 changes the numbers before the encoder starts, storing color at a quarter of the luminance resolution and bringing the frame to about 1.5 bytes per pixel. H.264 encodes in 4:2:0 by default, so chroma subsampling 4:2:0 does part of the reduction before any compression happens. It is invisible in most scenes, but visible on fine colored detail such as thin red text on a dark background.
How Is the Right H.264 Bitrate Chosen?
How the right H. 264 bitrate is chosen is answered by considering resolution, frame rate, and scene motion, then checking against the link. Too low and the camera blocks up on movement; too high and it wastes capacity and storage on quality nobody sees. H.264 bitrate control has the largest single effect on how a camera looks in service, and H.264 bitrate control is the setting most often left at whatever the module shipped with.
H.264 Bitrate for 1080p
For H. 264 bitrate for 1080p, 4 Mbps holds up on a mostly static scene such as a corridor or a fixed inspection station. Continuous movement, a road or a production line, needs 6 to 8 Mbps at 30fps to avoid blocking. At 60fps add roughly half again rather than double, since frames are more alike at higher rates. That is the H. 264 bitrate 1080p range to write into a specification.
H.264 Bitrate for 4K
For H. 264 bitrate 4 K, 15 Mbps is the practical floor at 30 fps, and 20 to 25 Mbps is where a detailed scene stops showing artefacts. Four times the pixels does not need four times the bitrate, since compression works better on larger frames, but it needs roughly three times. Any camera claiming H. 264 bitrate 4 K at 1080p rates is discarding detail the sensor captured.
Constant Bitrate and Variable Bitrate
Constant bitrate streaming holds the data rate fixed and lets quality fall when the scene gets busy; variable bitrate streaming holds quality fixed and lets the rate move with the content. Both are selectable on every Vadzo H. 264 camera module: constant bitrate streaming where the link budget is fixed, as on a wireless or shared network; variable bitrate streaming where storage has headroom and quality is the constraint. A variable-rate camera on a marginal link is the usual reason a system looks perfect in a quiet room and drops frames the moment something moves.
Does H.264 Add Latency?
Encoding and decoding both cost time, and on a Vadzo module that cost is worth budgeting rather than discovering. H.264 encoder latency runs one to three frames, and H. 264 decode latency another one to two, roughly 65 to 165 ms at 30fps before the network, with the low hundreds of milliseconds realistic end-to-end. The delay is structural: a P-frame cannot be encoded until its reference exists, nor presented until the decoder holds it, so H. 264 encoder latency and H. 264 decode latency are floors, not tuning targets. That is fine for monitoring and recording on any module in the range, and it rules out closed-loop control, since an arm correcting from a stream 200 ms old is correcting for where the target used to be. Vadzo offers uncompressed output on the same sensors for those builds.
Does H.264 Reduce Image Quality?
The format is lossy, so some of what the sensor captured does not survive the encoder, and the useful question on a Vadzo module is where that loss lands. H.264 image quality loss is not spread evenly: flat areas compress almost for free while fine texture and sharp edges go first, so H. 264 image quality loss shows as blocking on movement, smeared detail, and ringing along high-contrast edges. That is why the Merlin-234CGS is specified at 6 to 10 Mbps rather than 4 to 8 Mbps at the same resolution: it is the global shutter part, bought for motion, and motion costs the encoder bits. Set the bitrate for the busiest scene the camera will see, not the calmest.
Can H.264 Video Be Used for Measurement or Inspection?
Measurement is the one application where an H. 264 camera module is the wrong choice, because compression error is systematic rather than random and does not average out. Noise tends towards zero over enough samples, which is why noisy uncompressed data still supports precise measurement; compression error is the same transform applied the same way every frame, so the bias survives a thousand repeats and a defect smaller than the transform block can vanish entirely. Where the application derives a number from pixel values, the same Vadzo sensors are available uncompressed: YUV over USB 3.2 Gen 1 on the Falcon range, raw MIPI CSI-2 on the Bolt range.
H.264 on Each Camera Interface
H.264 over USB 2.0
A USB 2.0 camera link sustains roughly 40 MB per second. That carries 1080p30 uncompressed only with difficulty, and nothing above it. With H. 264 over USB 2.0, the same camera carries 4K comfortably, since a 20 Mbps stream uses about six percent of the bandwidth. H.264 over USB 2.0 is not an optimisation: it is what makes resolution above 1080p possible here.
H.264 over GigE
Gigabit Ethernet gives roughly 880 Mbps usable: enough for one 1080p30 camera uncompressed, not enough for 4K. With H. 264 over GigE, a single 4K camera uses a small fraction of the link, letting several cameras share one switch. A reach of a hundred metres is why the interface is chosen, and H. 264 over GigE makes that reach usable at high resolution.
H.264 over Wi-Fi
A wireless link sustains well under 100 Mbps in practice and varies second to second. H.264 over wi-fi is therefore always required on a wireless camera, and constant bitrate is almost always right, because variable bitrate exceeds the link the moment the scene gets busy. A shorter GOP helps too, since packet loss is more likely over H. 264 over wi-fi.
Streaming and Storage from the Camera
An RTSP H. 264 stream is how most network cameras publish video: RTSP handles session setup, the video travels over RTP, and any compliant client opens the URL without vendor software. The specification does not require H.264, but it is what almost every client expects, so an RTSP H. 264 stream is what you will be asked for.
An ONVIF H. 264 camera adds standardized discovery and configuration, letting a management platform find the camera and change resolution, bitrate, and profile without a custom client. For a product working alongside third-party recording software, an ONVIF H. 264 camera often dictates the specification more than image quality does.
H.264 storage per day is bitrate times the seconds in a day: a 4 Mbps 1080p camera is about 43 GB, an 8 Mbps camera about 86 GB, a 20 Mbps 4K camera about 216 GB. Run the H. 264 storage-per-day figure against camera count and retention before choosing the disk.
Choosing a Camera by Bitrate and Interface
Everything above reduces to one question: which camera, on which interface, at which bitrate. Vadzo Imaging offers sixteen modules with H.264 output across USB and GigE. The six below cover the range, and the last column is the figure that decides whether a design works.
Model | Sensor | Resolution | Shutter | Typical H.264 bitrate | Buy Now |
Merlin-290CRS | Sony IMX290 | 1080p | Rolling | 4 to 8 Mbps at 30fps | |
Merlin-234CGS | onsemi AR0234 | 1080p | Global | 6 to 10 Mbps at 30fps | |
Merlin-415CRS | Sony IMX415 | 4K | Rolling | 15 to 25 Mbps at 30fps | |
Innova-678CRS | Sony IMX678 | 4K | Rolling | 15 to 25 Mbps at 30fps | |
Innova-821CRS | onsemi AR0821 | 4K | Rolling | 15 to 25 Mbps at 30fps |
Read the table by constraint rather than by resolution.
If the host sits a few metres from the camera, the Merlin range on USB 2.0 is the answer. The Merlin-415CRS illustrates the whole article: a 4K sensor on a link sustaining 40 MB per second, possible only because a 20 Mbps stream uses six percent of it. The Merlin-290CRS is the 1080p option on the same interface, for a lit scene and a tight budget.
If anything moves during exposure, the Merlin-234CGS is the global shutter camera. Its bitrate runs higher than rolling-shutter parts at the same resolution, and that is not a defect: global shutter is specified for scenes with motion, and motion costs the encoder bits. Budget for the upper end of its range.
If the camera is far from the host, the GigE side applies, and there the choice is about the scene rather than the link. The Innova-678CRS uses a Sony STARVIS 2 sensor for poor illumination. The Innova-821CRS reaches 140 dB using DR-Pix dual gain, for frames holding bright and dark regions together. The Innova-1335CRA is the detail camera at 13MP, and the one case where the storage arithmetic deserves checking first: at 25 Mbps a single camera passes 270 GB per day.
Every H. 264 camera module in the range exposes the same encoder settings described above, so the bitrate, GOP, and rate-control decisions carry across the lineup. The full list of sixteen, with sensors, resolutions, shutter types, and output formats, is on the H. 264 camera module page.
Frequently Asked Questions
What is H.264?
H.264, also called AVC, is a video compression standard that reduces data by storing the differences between frames instead of every frame in full. On an embedded camera, the encoding runs in a hardware block on the module, so the host receives compressed data rather than pixels, and anything discarded is gone before the host sees the frame. It is implemented in hardware on virtually every processor made since the mid 2000s. Every Vadzo module with H.264 output does the work on the camera rather than on your host.
How does H.264 compress video?
In two stages: redundancy inside each frame, then between frames, the second producing nearly all of the savings. A complete self-contained frame is an I-frame; a frame stored as the change since the previous one is a P-frame, five to ten times smaller. The camera inserts a fresh I-frame every 30 to 60 frames, the keyframe interval or GOP length. Both are adjustable on the Vadzo modules above.
How much bandwidth does a 1080p camera need?
Uncompressed in YUV422, about 124 MB per second at 30fps and 249 MB at 60fps. Compressed at good quality, roughly 4 to 8 Mbps at 30fps, under 1 MB per second. The calculation is width times height times bytes per pixel times frame rate, worth doing before choosing an interface rather than after. On USB 2.0, that difference decides whether the camera works at all.
How is the right H.264 bitrate chosen?
From resolution, frame rate, and scene motion, then checked against the link. At 1080p30, 4 Mbps suits a static scene and 6 to 8 Mbps suits continuous movement. At 4K30, 15 Mbps is the floor and 20 to 25 Mbps is where artefacts stop showing. Use constant bitrate when the link budget is fixed, variable when quality matters more. The typical bitrate for each Vadzo module is in the table above.
Does H.264 add latency?
Yes. Encoding costs one to three frames and decoding another one to two, roughly 65 to 165 ms at 30fps before the network, and the low hundreds of milliseconds end to end. The delay is structural, since a P-frame cannot be encoded or presented without its reference. Imperceptible for monitoring and recording, disqualifying for closed-loop control where video drives an actuator. For those builds, Vadzo supplies uncompressed output on the same sensors.
Does H.264 reduce image quality?
Yes, permanently, since the format is lossy. The loss is uneven: flat areas compress almost for free while fine texture and sharp edges degrade first, so quality falls exactly when the scene becomes busy. A single lost packet corrupts the picture until the next I-frame, which, with a two-second GOP, means up to two seconds of damage. Setting a sensible bitrate on the camera matters more than any other adjustment.
Can H.264 video be used for measurement or inspection?
No. Compression error is systematic rather than random, so unlike noise it does not average out across repeated measurements. An edge softened by the encoder is softened the same way every frame, so the bias survives any sampling, and a defect smaller than the transform block can be discarded entirely. Measurement work needs uncompressed output: YUV over USB 3.2 Gen 1 or raw over MIPI CSI-2, both of which Vadzo supplies alongside the H.264 range.
