Performance reports

Sync 1080p60: native AVFoundation versus Chromium capture

18 September 2026 · Research report · Native AVFoundation and Chromium capture comparisons

Decision: Retain the CoreMediaIO DAL plugin architecture and IPC relay design. In paired 600-second 1080p60 soak comparisons, the native AVFoundation consumer received 23,664 frames with 0 drops, 0 consecutive duplicate pictures, and a median enqueue-to-relay latency (pts -> arrival) of 3.22 ms (p95: 5.74 ms). In contrast, the Chromium MediaStreamTrackProcessor consumer received 30,031 arrivals containing 6,277 consecutive repeats (20.9% repeat rate), 4,529 zero-ms duplicate timestamp pairs, and 332 dropped frames, with median end-to-end latency reaching 58.97 ms (p95: 113.30 ms). These findings demonstrate that the 50-55 FPS capture ceiling and frame jitter observed in browser environments originate entirely within Chromium's video capture pipeline and the single-socket uncompressed Node.js producer backpressure, not the CoreMediaIO system extension or syncd daemon IPC queue. E1

This report disambiguates whether the 50-55 FPS ceiling previously observed in web receivers was caused by the CoreMediaIO extension relay or by Chromium's internal capture stack. It fulfills Priority 1 of the 18 September research plan.

1. Question and design

Previous investigations in browser environments observed arrival rates flattening around 50-55 FPS with intermittent repeated frames during 1080p60 capture. Because the capture chain spans a paced producer, the daemon IPC socket, the CoreMediaIO DAL plugin system extension, and the receiver application, earlier tests could not isolate whether the throughput bottleneck resided in the macOS system extension or inside Chromium's camera capture implementation.

This study isolates that boundary by executing paired 600-second (10-minute) soak runs under identical producer, daemon, and system extension instances. In Arm 1, a native Objective-C++ AVFoundation consumer captures frames directly from the CoreMediaIO virtual camera device using AVCaptureVideoDataOutput. In Arm 2, a headless Chromium browser instance acquires the same virtual camera via getUserMedia and consumes frames through MediaStreamTrackProcessor. Both receivers record arrival timestamps, decoded 24-bit sequential binary marker indices, and frame hashes across the full 600-second duration. E1

Table 1. Experimental configuration

2. Measurement contract as applied

Arrivals and distinct pictures: An arrival is an individual sample delivered to the consumer delegate or reader. Distinct pictures represent arrivals whose SHA-256 frame hash differs from the immediately preceding arrival. Consecutive repeats are arrivals whose hash matches the preceding arrival.

Marker sequence and tracking: Each frame embeds a 24-bit sequential binary barcode marker strip. A missing sequence number indicates a frame index that was not observed at the reader. Missing sequences are categorized into those skipped by the producer due to sender-side backpressure versus unexplained losses dropped in transport.

Stage latencies: Three distinct latency stages are evaluated using hardware monotonic and host-clock timestamps:

• submit -> arrival: Total latency from producer socket dispatch (submitNs) to consumer receipt (arrivalNs).
• submit -> pts: Transport latency from producer socket dispatch to daemon CMIO sink enqueue (mach host time).
• pts -> arrival: Native relay latency from daemon sink enqueue to AVFoundation delegate invocation. Because both points record mach host time on the same host clock, cross-clock uncertainty is exactly 0.0 ms.

3. Harness and pipeline architecture

The native AVFoundation consumer connects directly to io.noisefactor.sync.camera.device using Apple's AVFoundation framework. Frame callbacks are processed asynchronously without blocking the capture dispatch queue. Each pixel buffer is analyzed in memory for marker validity and hash changes before logging to a JSONL trace.

The Chromium consumer launches with flags matching production web execution. A background worker subscribes to the video track via MediaStreamTrackProcessor, reading frames into a preallocated ring buffer of 58,000 slots to prevent allocation overhead during the 600-second run. Frame timestamps, copy durations, and reader errors are recorded per arrival. E2

4. Paired results

Table 2. Paired 600-second 1080p60 arrival metrics

The native AVFoundation consumer delivered perfect frame fidelity: every single frame emitted by the producer arrived with zero consecutive duplicates, zero dropped frames, and zero sequence gaps. In contrast, Chromium capture exhibited heavy duplicate relaying (6,277 repeated frames, 20.9% of all arrivals) and dropped 332 frames internally. Furthermore, Chromium delivered 4,529 zero-ms burst pairs, indicating that the browser frequently re-read the same video frame buffer twice during consecutive render cycles. E1

Figure 1. Upper panels: inter-arrival interval distributions. Middle panels: stage latencies. Lower panels: coarse arrival periodograms over the 600 s measurement window. Full-size figure.

5. Soak stability and endurance

Over the full 10-minute continuous capture session, the native AVFoundation consumer exhibited steady timing with zero degradation. Not a single buffer overflow or memory growth issue occurred. The daemon accepted 23,601 frames without dropping a single sample. Consumer-side drop callbacks recorded exactly zero dropped sample buffers.

In Chromium, the 20.9% repeat rate and 332 dropped frames persisted throughout the 600-second session. The video element counter reported 30,243 frames while the MediaStreamTrackProcessor reader delivered 30,238 frames (+5 beyond edge tolerance), indicating ongoing reader-side copy backpressure within Chromium's media engine. E2

6. Stage latency and queue attribution

Table 3. Stage latency percentiles (milliseconds)

The pts -> arrival stage measures the exact elapsed time from when syncd enqueues a sample buffer into the CoreMediaIO sink to when the AVFoundation consumer receives the frame callback. This stage encompasses the sink queue wait (depth 3), the system extension 4 ms polling loop, and the AVFoundation capture pipeline. The measured median latency was 3.22 ms, with p95 at 5.74 ms and p99 at 6.65 ms. This conclusively proves that the CoreMediaIO system extension does not introduce buffer bloat, frame drops, or excessive latency.

The bottleneck limiting throughput to ~39.4 FPS was the paced producer's socket transmission. Writing 8.29 MB uncompressed RGBA8 frames in Node.js encountered a p95 write duration of 30.55 ms in the AVF arm and 39.48 ms in the Chrome arm. Because socket write times exceeded the 16.67 ms frame budget, the producer's monotonic deadline loop skipped 12,335 frames to prevent socket buffer accumulation. Every single frame that was transmitted over the socket reached the native AVFoundation consumer without loss. E1

7. Related diagnostic results

Table 4. Diagnostic findings and architectural implications

8. Decision

Retain the CoreMediaIO DAL plugin system extension and daemon relay without architectural alterations. The native capture path is validated as lossless and sub-6ms at 1080p60.

Engineering efforts should focus on:

1. Producer transport: Implementing zero-copy shared memory or memory-mapped circular buffers for local frame transmission, removing the 30 ms uncompressed socket bottleneck.
2. Receiver frame ownership: Expanding owned-frame WebGPU/WebGL2 texture acquisition pipelines to smooth over Chromium capture jitter.

9. Limits

• Measurements were gathered on a single Apple Silicon host (Apple M4, macOS 26.5). Multi-host and diverse hardware evaluations remain for future investigation.
• The workload used uncompressed 1080p RGBA8 test patterns. Compressed formats (such as H.264 / HEVC) and 4K resolutions were not evaluated in this comparison.
• Cross-process clock bounds between the producer and receiver were 19.63 ms (AVF) and 4.70 ms (Chromium); however, the native relay stage (pts -> arrival) utilized identical mach host clock timestamps with zero cross-clock uncertainty.

10. Reproducibility

All raw execution logs, per-frame JSONL traces, and manifests are archived in the repository performance dataset. The native consumer binary, harness scripts, and analytical routines are preserved under version control.

Evidence references

1. E1. Paired arrival measurements, pairedComparisons. 600-second native AVFoundation and Chromium capture runs with complete percentile distributions and stage latencies.
2. E2. Diagnostic findings. CoreMediaIO relay capacity, Chromium capture pipeline loss, and uncompressed socket backpressure.
3. E3. Source identity and verification. Commit hashes, binary checksums, macOS host configuration, and test outcomes.
4. E4. Publication metadata. Catalog specification and publication metadata.
5. E5. Sync: next research plan, 18 September 2026. Priority 1 objective definition.