# Zvid rendering speed reproduction kit, v1

Report: https://zvid.io/benchmarks/rendering-speed

This kit uses the project the author confirmed was used in the reported test. A new run produces new evidence; it does not recover the original five run times or measure the three competitors. Zvid's historical result is an author-reported **21-second arithmetic mean of five runs**, including queue time. Competitor seconds in `reported-results.csv` are calculated as 21 multiplied by the reported ratios, not raw observations.

## Download

Save these four files in one folder using their original names:

- [benchmark.mjs](https://zvid.io/benchmark-data/rendering-speed/v1/benchmark.mjs)
- [project.json](https://zvid.io/benchmark-data/rendering-speed/v1/project.json)
- [assets.json](https://zvid.io/benchmark-data/rendering-speed/v1/assets.json)
- [SHA256SUMS.txt](https://zvid.io/benchmark-data/rendering-speed/v1/SHA256SUMS.txt)

The checksum list also covers the [report](https://zvid.io/benchmark-data/rendering-speed/v1/report.md), [JSON evidence record](https://zvid.io/benchmark-data/rendering-speed/v1/report.json), [reported-results CSV](https://zvid.io/benchmark-data/rendering-speed/v1/reported-results.csv), and citation downloads. Verify downloaded file hashes against this list. Media files are preserved on Zvid's CDN with content hashes in `assets.json`; the runner verifies all project input media before submitting any render.

Requirements: Node.js 22 or later, a Zvid account on Hobby or above, and at least 300 available credits. Create a key at https://app.zvid.io/api-keys. Five 60-second Full HD renders reserve **300 credits total**. Running without `--run` shows instructions and spends no credits.

Set `ZVID_API_KEY` to your own key using your shell's environment-variable mechanism. Also set `BENCHMARK_PLAN` to the exact account plan and `BENCHMARK_CLIENT_REGION` to your client region. Never publish your key or shell history containing it.

```sh
node benchmark.mjs --help
node benchmark.mjs --run --out ./my-results
```

The output directory must not exist. The script writes `project.json`, `results.json` and `runs.csv` there, saving after every attempt. Output URLs can expire; retain the finished MP4s and their hashes separately. The script never retries a render submission automatically. If submission or polling has an uncertain outcome, it stops so you can check the existing job before creating another paid job.

## Measurement protocol

1. Use the exact project and byte-identical input assets. It contains twelve five-second video clips, two title elements and one ambient soundtrack, at 1920 × 1080, 30 FPS, with a 60-second MP4 output.
2. Run five requests sequentially, with concurrency one and no warm-up. The runner downloads and hashes source media before timing begins. This can affect CDN cache state; renderer cache state is uncontrolled. Avoid other jobs on the account and record any concurrent activity.
3. The client clock uses a monotonic timer from immediately before POST submission until receipt of the completed status response. It includes submission, queue time, network latency and polling delay. Polls are two seconds apart after each response; polling adds up to an interval plus request latency in ordinary operation. This is an observed request-to-completion time, not pure render-engine time. Downloading the output is excluded.
4. Server-created and server-finished timestamps, when returned, are recorded separately. Their difference includes server queue time. Never mix server time with client time in a comparison. Missing server timestamps stay null.
5. Keep every attempt, slow run, error and timeout. The runner reports successful count, unsuccessful count, arithmetic mean, median, minimum and maximum for each timing metric separately. The mean is the sum of successful times divided by successful count. A five-run result requires five successful runs; failed attempts remain part of the evidence. An interrupted session is an incomplete sample.
6. Check each downloaded video with a media inspector for duration, dimensions, frame rate and audio, then inspect text, cuts, fades and framing. The runner records completion and output URLs; it does not automatically certify visual equivalence.

## Comparing services

Translate the same timeline into each service's native request format. Preserve media bytes, duration, resolution, frame rate, audio, fonts, fades and export format. Publish each actual request, output and checksum so readers can assess equivalence. Record service plan, region, date and time, concurrency, caching assumptions and failures. Interleave service order across rounds to reduce time-of-day bias.

Use the same clock definition on every service. Compute `competitor mean / Zvid mean` from newly measured means, and `(1 - Zvid mean / competitor mean) * 100` for percentage time saved. Do not reuse the historical ratios as new observations. Five runs describe a small workload sample; report the range and avoid generalizing to every project or account tier.

This kit supplies a Zvid runner. Native competitor requests and competitor credentials are not included. Historical competitor identities remain numbered, and their original per-run timing records are unavailable.

## Citation and versioning

For historical results, cite Mina Ramzy, *Zvid rendering speed benchmark: 21-second mean for a 60-second Full HD video*, Zvid, published September 20, 2026; evidence release 1.0 updated October 21, 2026. Use https://zvid.io/benchmarks/rendering-speed#cite and retain the versioned report alongside your article.

For your own run, cite the kit version and publish your run date, raw `runs.csv`, `results.json`, project hash, conditions and inspected outputs. The historical test date is unknown; September 20 is the page's original publication date.

Contact: https://zvid.io/contact