FDC vs x264 / x265 — Codec A/B Methodology

What this measures

A single 10-minute clip captured directly from one outdoor camera, encoded three different ways, with file sizes and reconstructed-frame fidelity reported per codec. The FDC arm runs the production S-VIDIA NVR pipeline — motion detection followed by motion-gated encoding — using the FDC reference encoder's libcommon defaults verbatim.

Source clip

Captured (UTC)	2026-05-22T17:43:15Z
Source codec on the wire	H.264 over RTSP
Resolution	2688 × 1520
Frame rate	10 fps
Pixel format	yuvj420p
Duration	600 s (6,000 frames)
Motion presence (NVR detector)	100% of frames had detected motion

Source camera: lab / dev camera (Samsung ONVIF Profile S). Not a deployed customer-site camera.

Fairness boundary

All codecs encode from a once-decoded YUV 4:2:0 reference derived from the camera's H.264 RTSP stream. SSIM and PSNR are measured in 4:2:0 space against that reference, not against an uncompressed ground truth — the camera itself never emits uncompressed video.

x264 and x265 read the YUV 4:2:0 reference directly. The FDC arm requires YUY2 (4:2:2) input, so its source is a deterministic 4:2:0 → 4:2:2 chroma-upsample of the same reference. The FDC roundtrip is then decoded back to YUY2 and re-converted to 4:2:0 before measurement, so all three codecs are graded in the same colour space.

The FDC encoder is configured with the production motion gate ON — the same configuration deployed S-VIDIA NVRs run. On no-motion frames the encoder emits a 32-byte skip marker; the decoder repeats the previous good decoded frame at that index so the output stream stays time-aligned with the source for SSIM/PSNR. This compounds two effects in the file-size number — the codec itself and the motion-only-archive strategy — but that is how the product actually consumes disk in the field, which is the question the benchmark is built to answer. Because this clip ran at 100% motion, the motion-gate layer contributed nothing here; the savings shown reflect codec mechanics alone.

Codec parameters

Codec	Settings
x264	libx264 -preset medium -crf 23 -an
x265	libx265 -preset medium -crf 28 -an
FDC	vcore9 libcommon production defaults: dct=tmj, simd-mode=128, quality=19, sensitivity=8, motion-sensitivity=4, motion-zone=8, keyframe-every-ms=0, force-encode=false, vertical-flip=true

Pipeline

1. Capture capture.mkv from the source camera; decode once to source.yuv420p and upsample to source.yuy2.
2. Encode → x264-crf23.mp4, x265-crf28.mp4, fdc-motion.fdc (+ per-frame stats for the FDC arm).
3. Decode each encoded artifact back to *.rt.yuv420p.
4. Measure: ffmpeg -lavfi ssim/psnr against the reference; file sizes via filesystem; extrapolate GB/24h and GB/week from the clip-length encoded byte count.
5. Stills: 3 timestamps × 3 codecs × 400×400 centre-crop JPEGs from each round-tripped stream.

Results

Codec	File size	GB/24h	GB/week	SSIM	PSNR (dB)
FDC	255 MB	38.5	269.8	0.946	35.3
x264 CRF 23	471 MB	71.1	497.8	0.988	44.2
x265 CRF 28	322 MB	48.6	340.0	0.978	40.7

FDC archive footprint was 54% of x264 CRF 23 (~46% smaller) and 79% of x265 CRF 28 (~21% smaller) on this clip.

Known limitations

• The clip is from a lab / dev camera, not from a deployed Puget Sound trailer. Customer-site re-runs are deferred to the fleet-wide pilot (bundle 02).
• The clip ran at 100% motion. The motion-only-archive layer that compounds with the codec in real deployments did not engage here. The S-VIDIA platform-wide 60% storage figure assumes typical mixed-motion content; on a fully-active clip only the codec contributes.
• SSIM/PSNR are measured against the once-decoded YUV reference, not uncompressed ground truth.
• The harness ran on a Win11 ARM64 VM under x64 emulation; SSIM/PSNR and file sizes are unaffected but absolute encoder throughput is not representative of bare-metal x64.
• GB/24h and GB/week are linear extrapolations from a single clip; scenes with different motion characteristics will differ.

← Back to measured codec table on /technical-specifications