- Is izotopsvk/ffmpeg-bundle compatible with Laravel?
- No. Despite showing up in Laravel package searches, it is a Symfony bundle that exposes its services through Symfony's bundle registration and dependency-injection extension mechanism, which Laravel's container never invokes. There is no service provider, no facade, no publishable configuration, and no package discovery support. For a Laravel application it is disqualified at the framework boundary before any feature discussion even starts.
- Can I just composer require izotopsvk/ffmpeg-bundle in a Laravel project?
- The download may succeed, but that is not a working integration. Laravel will not auto-register anything from the bundle, so you end up with dead code in the autoloader and an unowned transitive dependency surface that gives you nothing. Realistic integration effort is zero-to-negative: you would remove it immediately after inspecting what it actually contributes.
- Does this bundle support Laravel 10 or Laravel 11?
- Effectively no. Its symfony/framework-bundle and symfony/process constraints target the Symfony 2.x and 3.x era, which conflicts with the Symfony components Laravel 10 and 11 ship. Even in the rare case where Composer resolution passes, the package adds no Laravel-usable functionality, so there is nothing to gain from forcing it in.
- Where is the Laravel service provider or facade for this package?
- There isn't one, and none is planned, because the package is built exclusively for Symfony. If you want this behaviour in Laravel you must write the wiring yourself: a first-party MediaServiceProvider that binds an interface such as MediaTranscoder to a concrete implementation. The bundle's actual contribution is roughly fifty lines of container wiring and binary-path configuration, which any TPM should treat as internal work rather than delivered value.
- Which FFmpeg package should Laravel developers use instead?
- Use PHP-FFMpeg/PHP-FFMpeg, the community-maintained fork, rather than the legacy alchemy-fr lineage this bundle still depends on. Bind it as a singleton in your own service provider and resolve it through a first-party interface so a managed transcoder can be swapped in later without touching call sites. Keep binary paths, thread count, per-job timeout, temp directory, and target disk in config/media.php.
- Does izotopsvk/ffmpeg-bundle work with PHP 8.1+ and modern Symfony versions?
- It almost certainly does not. The dependency constraints point at the Symfony 2.x/3.x era, and the underlying media library is untyped legacy code that is itself stale. That creates two levels of staleness: adopting the bundle pins your project to an archived base library and inherits its outdated symfony/process behaviour. Check the composer.json constraints carefully before assuming anything resolves.
- How do I configure ffmpeg and ffprobe binary paths with this package?
- The bundle does it through Symfony's DI extension and bundle configuration, which has no equivalent in Laravel, so you cannot reuse its config file. In a Laravel app you instead define config/media.php with binary paths, thread count, job timeout, temp directory, and target disk, then inject that config into your transcoder service. Also pin the actual ffmpeg and ffprobe versions in your container images and assert codec availability at boot, because Composer does not pin the binaries.
- Is izotopsvk/ffmpeg-bundle maintained and safe to use in production?
- Treat it as unmaintained from day one: zero stars, zero dependents, a single maintainer, and no downstream ecosystem to generate bug reports, compatibility fixes, or security patches. On top of that, every operation shells out to an ffmpeg binary, so input paths, filter strings, and user-supplied metadata remain an attack boundary that needs explicit security sign-off. Shell-out transcoding on hosts that also serve web traffic is a common cause of incidents and often forces a dedicated worker tier.
- Can I use this bundle to generate thumbnails and transcode video inside queued jobs?
- The capability exists only insofar as it wraps the underlying PHP-FFMpeg library, but nothing here is Laravel-aware, so queue integration, retries, and timeouts are entirely your responsibility. Executing transcodes inside queued jobs should be the default assumption rather than an optimisation, with explicit max input size, duration limits, and p95 latency targets. If a managed transcoder such as Mux, Cloudflare Stream, or AWS MediaConvert is plausible within eighteen months, design an internal interface boundary now instead of adopting a wrapper.
- How do I test or mock FFmpeg processing in a Laravel application?
- Do not depend on a Symfony bundle to make this testable. Bind a MediaTranscoder interface and swap in a fake implementation in unit tests so you can assert the options, paths, and filter strings your code would pass to the binary. Keep a small fixture media set for real integration tests that run against an actual ffmpeg binary in CI, and never invoke shell-outs in fast unit test suites.