Ffmpeg Bundle Laravel Package

Product Decisions This Supports

• Media pipeline groundwork — and nothing more. This package does not add capability. It registers alchemy-fr/PHP-FFMpeg as a Symfony DI service plus binary/config wiring. Every decision it "supports" is really a PHP-FFMpeg decision: video upload processing, thumbnail/sprite generation, format normalization, audio extraction, watermarking.
• Build vs. buy at the micro level, not the product level. The real choice is "write ~50 lines of service registration ourselves" vs. "take a dependency for it." This is the smallest possible unit of buy-side leverage, so evaluate it on cost-of-ownership, not features.
• Framework-strategy flag. Despite being queried as a Laravel/PHP package, this is a Symfony bundle. For a Laravel roadmap it is disqualified at the framework boundary — no service provider, no config publishing, no Laravel container integration. That's a decision input in itself: it says your media tooling is being sourced from the wrong ecosystem.
• Roadmap prioritization input. Because it exposes nothing PHP-FFMpeg doesn't already expose, adopting it does not de-risk or accelerate any media feature. It should not appear on a roadmap as an "enabler."
• Scaling decision trigger. Evaluating it forces the right question early: is video transcoding a core competency worth self-hosting (CPU-bound workers, queue design, storage lifecycle), or should it be outsourced to a managed transcoder (Mux, Cloudflare Stream, AWS MediaConvert)? That's a genuine product/infra decision with real cost implications, and this package only serves the self-host branch.

When to Consider This Package

• Only if you are on Symfony (roughly the 2.x–4.x era this targets), the need is internal or prototype-grade, you are comfortable vendoring/forking, and you accept it as unmaintained.
• Only if the alternative is worse — e.g., a team unfamiliar with Symfony DI that would otherwise hardcode exec('ffmpeg ...') calls in controllers.
• Look elsewhere when:
  • You're on Laravel or any non-Symfony framework — hard stop, wrong ecosystem.
  • You need active maintenance. Zero stars, zero dependents, score 0, no downstream users is a strong abandonment signal. No ecosystem pressure means no bug reports, no security patches, no compatibility fixes.
  • Your base library is stale. It pins to alchemy-fr/PHP-FFMpeg, superseded by the community-maintained PHP-FFMpeg/PHP-FFMpeg. Adopting this bundle inherits a deprecated dependency two levels deep.
  • You're on PHP 8+ / modern Symfony — version constraints and untyped legacy code are likely friction, not help.
  • You need production concerns: queue-backed async transcoding, progress reporting, timeouts, per-tenant resource limits, observability. A service-registration wrapper gives you none of that.
  • You'd rather own the ~50 lines. For a dependency this thin, copying the service definition into your own provider removes an entire supply-chain and maintenance liability at near-zero cost.
• Minimum due-diligence gate before any adoption: confirm PHP/Symfony version constraints, confirm it resolves against a maintained PHP-FFMpeg fork, run a CVE/abandonment check, and identify a named internal owner willing to fork it.

How to Pitch It (Stakeholders)

To executives: This is a small convenience wrapper, not a product enabler. It has zero community traction — no stars, no dependents, no downstream users — which we should read as unmaintained. It also depends on a deprecated base library. The cost of writing the equivalent wiring ourselves is measured in hours; the cost of owning an abandoned third-party dependency in a production media path is measured in incidents. Recommendation: do not adopt. If we pursue video, the decision worth funding is self-hosted transcoding vs. a managed service, not which bundle registers the service.

To engineering: It's a Symfony bundle that registers PHP-FFMpeg in the container with binary-path config. That's the whole value proposition. It targets an older Symfony generation and builds on alchemy-fr/PHP-FFMpeg, which is superseded by PHP-FFMpeg/PHP-FFMpeg. Recommended path: depend directly on the maintained fork and register the service in our own small service provider — roughly a service definition, a config tree, and a factory. That keeps us on a supported base library, removes an unmaintained link from the chain, and costs less than auditing the one we'd be replacing. Also note the framework mismatch if this surfaced from a Laravel evaluation — it doesn't apply to our stack.