Pmk2 Paella Player Bundle Laravel Package

Product Decisions This Supports

• Lecture-capture / multi-stream player UX. The bundle is the Pumukit 2 glue that wires the Paella Player (HTML5, multi-stream, presenter + slides synchronized) into a video platform's player layer. It is directly relevant to any roadmap decision about "two-up" video experiences: instructor + slide deck, sign-language inset, multi-camera, or screen-share-and-face layouts.
• Build vs. buy vs. integrate for the player. The package is small integration code, not a player. It is useful evidence that the integration surface is thin — a route, a track-mapping transform, and a template — and that the heavy lift (rendering, sync, captions, accessibility) belongs to the upstream JS player. That argues for integrating a maintained player rather than building one.
• Player abstraction / pluggability. The bundle exists because Pumukit treats the player as a swappable component (there are sibling player bundles). If your product roadmap includes multiple playback experiences (live vs. VOD, audio-only, multi-angle), this is a reference architecture for a player-adapter boundary rather than a hardcoded front end.
• Vertical prioritization (education, training, enterprise L&D). Paella's differentiator is synchronized multi-stream playback, which is a genuine requirement in academic capture and corporate training. This package is a data point that such a requirement is met with open-source components — useful when sizing whether a "lecture capture" epic is a differentiator or table stakes.
• Reference implementation for an integration spike, not a dependency decision. Appropriate use is a timeboxed spike or a reading exercise to estimate effort for a Paella-backed player in our stack, not adding it to the bill of materials.

When to Consider This Package

Consider it only if all of the following hold:

• You are operating (or explicitly forking) a Pumukit 2 deployment and need Paella wired into its track/series model.
• You are on a Symfony stack of that vintage (Symfony 3.x-era), with the corresponding PHP version constraints — not Laravel, despite being packaged as "a PHP package."
• You intend to own the code: fork it, vendor it, and accept full maintenance. There is no upstream support, no security patching, and a single-digit star count with zero dependents — no community to lean on.
• The scope is genuinely small: mapping Pumukit tracks to Paella's manifest/data.json shape and rendering a template. If you expect more than that, you will be disappointed.

Look elsewhere if:

• Your product is Laravel or modern PHP (8.1+). This is a Symfony bundle; the framework coupling, service-container wiring, and templating are not portable in any practical sense. Treat it as documentation, not a dependency.
• You are greenfield. Adopt Paella Player upstream directly (it is actively maintained as a JS project) and write your own thin manifest adapter — roughly the same effort as un-vendoring this bundle, with a live upstream.
• You need a single-stream player. Video.js, Plyr, or a native <video> element is simpler, better supported, and cheaper. Multi-stream sync is the only reason to take on Paella's complexity.
• You need a commercial SLA, security response, or an actively maintained dependency. Last release was March 2019; the package is effectively abandoned.
• You need captions/accessibility guarantees beyond what the upstream player offers, or DRM, or adaptive-bitrate at scale — those are platform-level decisions this bundle does not inform.

Risk summary for a dependency scorecard: abandoned (2019), negligible adoption (1 star, 0 dependents), single-vendor origin (Teltek), framework-locked, and scored 0.125 by whatever health metric produced this row. Any adoption should be classified as fork-and-own, never consume upstream.

How to Pitch It (Stakeholders)

To executives — one paragraph: We evaluated this package and are not adopting it as a dependency. It is a small, unmaintained (last release 2019) Symfony plugin that connects an open-source multi-stream video player called Paella to a specific video platform, Pumukit. It has effectively no user base and no support path, so taking it on would mean owning it forever. What it does tell us is valuable: the "professor plus slides, side by side" playback experience our education and training customers ask for is achievable with mature open-source components and only a thin layer of our own code. Recommendation: no procurement, no dependency; treat it as a free reference design and budget a small spike if the multi-stream player epic gets prioritized.

To engineering — the working notes: It is a Symfony bundle for Pumukit 2, not a Laravel package — the listing is mislabeled. Expect Symfony 3.x-era service definitions and PHP constraints that will not run on our stack without work. The valuable parts are the track-to-Paella manifest mapping and the player-swap pattern; the rest is boilerplate. If we pursue multi-stream, vendor Paella Player from its live upstream and implement our own adapter behind a player interface — that is the same amount of code, minus the dead dependency. If someone insists on reusing this specific code, it must be forked into our repo, pinned, and accepted as unsupported. Effort estimate for the equivalent integration on our stack: small, one engineer, one sprint — dominated by manifest mapping and UI, not by player work.