Complete SDK export and verification measurements from the frozen, qualified 0.7.2a1 Docker image. Export includes watermarking, development C2PA signing and the SDK's read-back gate. Verify is a separate SDK call on the intact signed output.
The measured files
- Image: one unmarked AI-created hero source resized to a 1024 × 683 PNG.
- Video: one deterministic moving FFmpeg test pattern, 1280 × 720, 30 fps, ten seconds, H.264/yuv420p, no audio. Each video profile received identical input bytes.
First job and resident repeats
| Input / profile | First export | Warm export range | Warm export CPU, median | Warm Verify range | Session memory peak |
|---|---|---|---|---|---|
| PNG image | 4.49 s | 0.73–0.74 s | 1.10 CPU s | 0.14–0.14 s | 510 MiB |
| Economy5s | 10.63 s | 9.08–9.10 s | 13.24 CPU s | 1.39–1.40 s | 763 MiB |
| Economy2s | 15.10 s | 13.76–13.89 s | 21.54 CPU s | 1.38–1.42 s | 750 MiB |
| Resilient | 112.15 s | 103.77–105.11 s | 184.67 CPU s | 1.38–1.40 s | 858 MiB |
One first job in a fresh process, followed by two exports using the same SDK and resident workers. This is three observations per row, not a statistical estimate of real-world throughput. All 12 exports passed their read-back gate; all 12 separate verification calls recovered their expected ID.
What the numbers include
- AWS EC2 m6a.large: Linux x86-64, two vCPUs, 8 GiB host RAM. Each measurement container was limited to two CPUs and 4 GiB memory. Jobs ran sequentially, without a GPU.
- CPU time is the container cgroup CPU-usage delta, including child processes. It is different from wall time.
- Memory is the kernel's session cgroup high-water mark across the three jobs and checks. It can include charged file cache; it is not per-job process RSS or a minimum host-RAM recommendation.
- First job does not mean a cold machine or empty OS cache. SDK construction is recorded separately in the raw data; model/runtime work triggered during export is included in that export.
- Development signing only. Production certificate enrollment, remote TSA latency, queueing, concurrent jobs, HTTP transport and delivery transforms were not measured.
How to use this
Economy profiles reduce inference while still decoding and encoding the full video. Resilient spends substantially more compute on fresh per-frame marking. Choose a profile using your own content, short-clip requirements and delivery transformations, not these speed figures alone.
Verification here used intact SDK exports. These timings do not characterize a metadata-stripped blind scan, a long negative scan or resistance to cropping and removal. Recovery of these twelve expected IDs is not a general detection rate or compliance determination.
Inspect and reproduce
Download raw measurements and exact hashes ↗
Download the server-side measurement script ↗
Prepare /bench/input.png and /bench/input.mp4 in a writable benchmark directory. Run the script in a new container for each argument: image, economy_5s, economy_2s, resilient. Set BENCH_IMAGE_ID to the image identity you actually run, mount that directory at /bench, and apply the same CPU/memory limits. Keep network disabled during measurement; provision the pinned runtime first using the release quickstart. A new run needs new output directories.
ffmpeg -f lavfi -i testsrc2=size=1280x720:rate=30 -t 10 \
-c:v libx264 -threads 2 -preset fast -crf 20 -pix_fmt yuv420p input.mp4Record your own input hashes and runtime alongside results. The raw data records the source hashes and probe metadata used for this run. The image source remains in the editable website project; use an image you can share for your own reproduction.
Read the video-profile limitations ↗ · Plan operating costs ↗ · Check the real hero image ↗