Statamic Video Tools Laravel Package

Technical Evaluation

Scope correction: despite the Laravel/PHP framing, this is a Statamic addon, not a framework-agnostic Laravel package. It only delivers value if the target application is (or will be) a Statamic site. For a plain Laravel app, this is effectively a decision to adopt Statamic first — a much larger commitment than a composer require. That distinction should be settled before any further evaluation is done.

Architecture fit: The design is sound for self-hosted, privacy-sensitive video. Encoding, transcription, thumbnailing, and streaming packaging all happen in-process on infrastructure the team already controls, driven off Statamic's asset pipeline and queue. The {{ video }} tag and <x-video> component mean presentation is a first-class concern rather than something the team builds from scratch, and the CP fieldtype keeps operators out of the CLI. The published VideoConversionCompleted / VideoAssetProcessed events are the right seam for cache busting and downstream automation — this suggests the authors understand that encoding is asynchronous and that the rest of the app needs to react to state changes rather than poll.

Integration feasibility: Straightforward on a Statamic stack — install, configure presets, ensure ffmpeg and whisper.cpp binaries plus a model file are present on the worker hosts, and point the queue at the conversions. On anything else, feasibility collapses to "rewrite or port."

Technical risk (ranked):

1. Compute and storage cost is the headline risk, not a footnote. Multi-format output (AV1, H.264, HEVC, HLS ladders) plus optional dual-source alpha output plus a local Whisper transcription means a single upload can fan out to 6–10 encode jobs and a transcription job. A 10-minute 4K upload can saturate a worker for a long time. AV1 in particular is slow in software and often has no hardware encoder path on typical cloud instances.
2. Native binary dependencies. ffmpeg and whisper.cpp must be installed, versioned, and kept present on every worker host. This is a real departure from the "composer install and go" expectation most Laravel teams have, and it interacts badly with ephemeral/serverless compute and with autoscaling worker pools built from a stock PHP image.
3. Whisper model lifecycle and licensing. Model size (base/small/medium/large) drives CPU and RAM; model weights are large artifacts that need distribution and possibly licensing review. Auto-transcription on every upload also means a compliance question if uploads include third-party voices.
4. v1.0.0 maturity. No prior versions means no deprecation surface and no migration burden, but also no track record. Expect rough edges in preset conditions and CP polling under load.
5. Security surface. User-supplied media passed to ffmpeg and to a model runner is a known class of risk (crafted files, option injection, resource exhaustion). Presets must be developer-controlled, not CP-editable by non-admins.

Key questions for the maintainer:

• Minimum PHP / Laravel / Statamic versions, and is Statamic 4 and 5 both supported?
• Is the addon free, paid, or freemium? (The "no monthly fees" claim refers to transcoding services, not necessarily the addon license.)
• What hardware baseline is assumed for AV1 and HEVC — is hardware acceleration supported or software-only?
• Are jobs truly chunked/resumable, or single long-running processes? What is the timeout guidance?
• Where do HLS segments live, and is there a retention/cleanup story?
• Does transcription run by default on upload, and can it be deferred or gated by condition?
• How does whisper.cpp get installed in a containerized deploy — is there a documented Dockerfile?

Integration Approach

Stack fit: Only a fit for Statamic sites on Laravel. If the product is not on Statamic, stop here — the correct next step is evaluating a standalone encoding layer (e.g. a queue-driven ffmpeg wrapper plus a transcription service), not this addon.

Migration path: Greenfield for this addon (v1.0.0), so there is no data migration. The real migration is operational: replacing an existing third-party transcoding service (Mux, Cloudflare Stream, Transcoder API) with self-hosted encoding. That means backfilling poster/thumbnail renditions and, if desired, existing HLS ladders — or, more pragmatically, leaving legacy assets on the old provider and applying this only to new uploads. Recommend the latter for the first release; bulk re-encoding is a separate project with its own cost model.

Compatibility: Unverified. Confirm PHP and Statamic versions against the app's locked constraints before scheduling work. Confirm the queue driver — this addon assumes a real worker (redis/database + supervised queue:work), not sync, and will not behave acceptably on sync in any environment with real video.

Sequencing:

1. Prove the native dependency chain on the actual deploy target (Docker image or VM) — ffmpeg with AV1 and HEVC encoders present, whisper.cpp compiled, model file staged. This is the single highest-risk step and should be timeboxed first.
2. Stand up one preset (H.264/MP4 only) on a staging environment. Measure wall-clock encode time and peak memory for a representative worst-case upload.
3. Add HLS and poster/thumbnail; verify Glide resizing and the animated WebP preview in the CP asset browser.
4. Add transcription last, gated by a preset condition, with a chosen model size and an explicit decision on whether it runs on every upload.
5. Wire the two Laravel events into static cache busting and any downstream webhooks before general availability.
6. Only then enable alpha/dual-source output, which doubles encode work for affected assets and should be scoped to a specific collection or preset rather than applied globally.

Operational Impact

Maintenance: Two native dependencies to track and patch (ffmpeg, whisper.cpp) plus periodic Whisper model updates, on top of the addon's own upgrade cadence. That is meaningfully more maintenance than a SaaS transcoder, where the vendor absorbs codec churn. Assign clear ownership — this tends to rot quietly when the person who set it up moves on.

Support: Support burden shifts in character: fewer "vendor outage" tickets, more "my video is stuck at 40%" tickets. The CP status fieldtype with live polling and per-preset re-run buttons materially reduces this — operators can self-serve a retry without a developer. Budget supporting documentation for the retry workflow and for what "failed" means per preset.

Scaling: Scales by adding queue workers, but only if the workers can encode efficiently. Three practical limits: (1) CPU-only AV1 is expensive enough that encode time may exceed upload cadence at moderate volume; (2) storage grows multiplicatively per asset (5 formats + HLS segments + poster + thumbnails, and roughly double for alpha assets) with no built-in retention policy mentioned; (3) transcription competes for the same CPU as encoding, so a burst of uploads can starve both. Recommend a dedicated queue for video work and a dedicated queue for transcription so a slow Whisper job never blocks a time-sensitive encode.

Failure modes to instrument before launch:

• ffmpeg or whisper.cpp missing/not on PATH on a newly autoscaled worker — fails silently per job.
• Worker OOM on high-resolution or long-duration input; needs a memory limit policy and a pre-flight check against duration/resolution.
• Job timeout on long encodes (AV1 especially) — define timeout per preset and consider a hard rejection above a duration threshold.
• Disk exhaustion from HLS segments and intermediate files, particularly if temp files aren't cleaned on failure paths.
• Partial success: some presets complete, others fail. Confirm the asset isn't marked "ready" until the required preset set succeeds, otherwise the front end serves a broken <video> element.
• Corrupt or malicious uploads passed to the encoders; enforce MIME validation and run encoding as a low-privilege user.

Ramp-up: Low for content editors — the tag/component and CP fieldtype are self-explanatory, and preset conditions hide the complexity. Moderate for the implementing developer: they need working fluency in codec/container tradeoffs, HLS ladder design, alpha-channel handling across Safari vs Chrome/Firefox, and queue-based media pipelines. This is not a "read the README over lunch" integration; plan for a spike and a proof of concept before committing to a delivery date. The documentation file is the primary onboarding asset and should be reviewed for completeness on install, presets, and troubleshooting before the team depends on it.