PHP-FFmpeg-video-streaming: packaging DASH and HLS from PHP

What the package does and what it does not

PHP-FFmpeg-video-streaming is described as a package that uses FFmpeg to bundle media content for online streaming, including DASH and HLS, and that additionally provides the capability to implement DRM for HLS packaging. It also offers a range of options to open files from cloud storage and to save files to cloud storage.

So the scope is packaging, not delivery. The library produces the segmented output that a player or an origin expects to find on disk or in an object store, and the actual serving of that content is somebody else's problem.

The project sits under the quasarstream organisation and has a documentation site at quasarstream.com/op/php/ffmpeg-streaming, with the homepage for this package linking to the streaming product page. The readme also points to a full documentation page describing all features and components.

The repository itself is small and conventional for a PHP package: a src/ directory, a tests/ directory with phpunit.xml, a composer.json, a LICENSE, a SECURITY.md, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, a renovate.json for dependency updates, and a _config.yml.

The topics list is wide and describes the integrations the package supports: aws-s3, google-cloud-storage, microsoft-azure, cloud, dash, dash-video, mpeg-dash, hls, hls-live-streaming, hls-packaging, hls-video, drm, ffmpeg, php-ffmpeg, php-packages, video, video-stream and video-streaming.

The licence is MIT, the primary language is PHP, and the release history shows active maintenance. v1.2.19 added PHP 8.4 support in October 2025, v1.3.0 fixed issue 147 in November 2025, and v1.3.1 from 2026-06-15 is titled as fixing a PHP 8.4 deprecated notice. The last push to the repository was on 2026-06-15 as well, so the tree matches the newest release rather than running ahead of it.

The representation ladder, as the API expresses it

The basic usage example shows the shape of the API, and it is worth reading closely because the design is fluent and per-format.

use Streaming\Representation;

$r_360p  = (new Representation)->setKiloBitrate(276)->setResize(640, 360);
$r_480p  = (new Representation)->setKiloBitrate(750)->setResize(854, 480);
$r_720p  = (new Representation)->setKiloBitrate(2048)->setResize(1280, 720);

$video->hls()
    ->x264()
    ->addRepresentations([$r_360p, $r_480p, $r_720p])
    ->save();

A Representation carries a bitrate in kilobits and a resolution, and the ladder is built as a list of them handed to addRepresentations. The three rungs here are a sensible one: 276 kbitrate at 640 by 360 for a weak connection, 750 at 854 by 480, and 2048 at 1280 by 720.

The chain itself is the interesting part. The call starts with $video->hls(), which selects the output format, then ->x264() selects the video codec, then ->addRepresentations() attaches the ladder, and ->save() performs the work. Every step returns the object, so the pipeline reads as a sequence of decisions rather than as a configuration array.

Because hls() is a method rather than a constructor argument, the same video object would offer a sibling for DASH by calling a different method, which is how the same source material can be packaged for two delivery formats. The topic list's separate entries for dash-video, mpeg-dash, hls-packaging and hls-video suggest the library treats those as distinct output types rather than one generic stream.

The design is a builder over FFmpeg. That is what makes the package pleasant to use from PHP, and it is also what means the mapping from these calls onto FFmpeg command line arguments and manifests is where the behaviour lives, so that is the part to read in the documentation rather than guessing from the fluent surface.

The hosted product next to the open package

Half of the readme is a comparison table between two subscription plans from Quasarstream, Basic and Pro, and it is worth reading because it shows where the open package stops and the commercial product starts.

Both plans include authentication, an access-control list, video on demand in HLS and DASH, HLS encryption with a single key and key rotation, video quality settings from 144p to 4K or auto mode, real-time progress monitoring with a progress bar for live upload and transcoding progress, a dark and light theme, and three months of support on Basic.

The Pro-only rows are the ones that matter for understanding the package's boundary. Live streaming from a browser webcam, IP cameras or live streaming software. Bespoke player design. Adding subtitles and additional audio tracks. Monetisation through subscriptions, pay-per-view or ads. Advanced analytics with views, watched hours and visited countries. DRM systems covering Widevine, FairPlay Streaming and PlayReady. Social media integration with like, comment, share and embed. A cloud-based CDN through Amazon S3, Google Cloud Storage and Microsoft Azure. Tailored features on request, and customisable support.

That list is a good description of what a hosted OTT platform does beyond packaging. The open package covers transcoding and packaging, which is the part you can run on your own infrastructure. DRM is the partial overlap, since the readme says the package can implement DRM for HLS packaging, while the commercial product lists Widevine, FairPlay and PlayReady, the three browser DRM systems that require a licence server.

The distinction to hold on to is that HLS encryption and DRM are not the same thing. The package supports encrypted HLS output, which is a file-level key mechanism. The multi-DRM systems in the Pro column are a different mechanism involving the player and a licence server, and the package does not claim them.

The readme also points to an online demo for the hosted product and to booking a demo, which is the commercial path.

Where the package is the wrong tool

The first limitation is the FFmpeg dependency and the host requirement. This is a wrapper around an external binary, and the binary has to be present and working on the machine doing the transcoding. FFmpeg builds vary in which encoders and muxers they include, so a package that works on a distribution's build may fail on a minimal container image with a different codec set, and the failure will surface as an FFmpeg error rather than as a clear message from the library.

The second is that it is a packaging library and not a pipeline. It turns media into HLS and DASH output, and it does not watch a source directory for new files, retry a failed transcode, spread the work across workers, keep a manifest up to date as more renditions arrive, or serve the result with the right cache headers and CORS. All of that is the surrounding application, and in a real video-on-demand setup it is most of the work.

The third is the gap between the open package and the Pro column. Live streaming, a player, subtitles and alternate audio tracks, analytics, monetisation and multi-DRM are all listed as commercial-only features of the hosted product. A team that reads the table as a feature matrix for the library will be misled, and a team that needs any of them is buying a platform rather than adopting a package.

The fourth is the operational reality of transcoding at scale. Encoding three representations of a video is CPU-heavy and slow enough that a request-time handler will time out, so you need a queue, a worker pool and somewhere to put the results. The package hands you a fluent call and a save(); everything about scheduling, retry and idempotency is yours.

The fifth is the rename. The Packagist badge in the readme points at aminyazdanpanah/php-ffmpeg-video-streaming, while the repository and homepage are under quasarstream. The composer package name and the vendor namespace are therefore not what the GitHub URL suggests, and any tutorial written before the move may name a package that no longer resolves.

Editorial conclusion

PHP-FFmpeg-video-streaming fits a PHP application that already stores source media and needs to produce adaptive streaming packages from it, since the representation ladder, the HLS and DASH packaging and the cloud storage handling are all driven from PHP rather than from a shell script you maintain. It is the wrong choice if you need a streaming server, a live encoder or a player, since the package only produces packaged output. Before adopting it, confirm FFmpeg is installed and that the version supports the formats you need, and note that the package is published on Packagist under the name aminyazdanpanah/php-ffmpeg-video-streaming, that the newest release is v1.3.1 from 2026-06-15 fixing a PHP 8.4 deprecation notice, and that the last push was on the same day.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. quasarstream/PHP-FFmpeg-video-streaming on GitHub
4. README
5. Releases