Pumukit Hard Video Editor Bundle Laravel Package

Technical Evaluation

Architecture fit — poor for a Laravel estate. Despite the "Laravel/PHP package" framing, teltek/pumukit-hard-video-editor-bundle is a Symfony bundle built exclusively for the Pumukit video management platform (Teltek's Symfony-based VMS). It is not a framework-agnostic library and exposes no Laravel service provider, facade, or config contract. It is structurally bound to Pumukit's domain model (MultimediaObject, Track, Series, Job), its admin UI bundles, its role/permission system, and its encoder/worker subsystem. Installing it into a Laravel application is not a configuration problem; it is an incompatible-runtime problem. Realistic value is therefore reference implementation, not dependency — we would mine its ffmpeg/MLT invocation logic and re-implement it as a Laravel job pipeline.

What it actually does. Pumukit natively supports soft (non-destructive) editing via clip/playlist object relationships. This bundle is the hard counterpart: it commits an edit to disk by re-encoding a new track — concatenating segments, applying transitions/overlays, and registering the result back onto the MultimediaObject. That is a meaningfully different capability from trimming metadata, and it is the part worth studying.

Integration feasibility.

• Composer install requires the Pumukit metapackage and a pinned Symfony generation (Pumukit's active line is Symfony 3/4-era). Conflict risk with any modern Laravel/Symfony app is effectively 100%.
• Runtime hard dependencies on external binaries — ffmpeg/ffprobe and, for MLT-based composition, melt. Container images must pin these builds; codec availability becomes part of the artifact contract.
• Requires writable scratch storage sized to full-length intermediate renders, plus Pumukit's transcoding profile definitions to select target codecs/bitrates.
• No standalone entry point: no console command or HTTP API you can call without the Pumukit kernel booting.

Technical risk — high, and concentrated in provenance.

The 0.71 score here reads as "interesting capability, near-zero ecosystem validation." Opportunity 24.22 suggests low competitive urgency — correctly, because nobody outside Pumukit wants this bundle.

Key questions for the team.

1. Do we actually need hard (destructive re-encode) editing, or does a non-destructive EDL/timeline model with lazy render satisfy the product requirement? Hard editing is expensive and irreversible.
2. If hard editing is required, is the ffmpeg filter-graph approach the bundle uses the right one, or would an MLT/melt or GStreamer pipeline be more maintainable?
3. Are we willing to run a Symfony/Pumukit sidecar service purely to reuse this, versus a ~2–4 week re-implementation in Laravel?
4. What is the license on the Pumukit family, and does it permit extracting the command-building logic?
5. Who owns codec/container support and ffmpeg version upgrades if we fork?

Integration Approach

Stack fit — adopt the pattern, reject the package. Recommendation: do not add this as a dependency. Treat it as a design reference for a native Laravel implementation.

Mapping the capability onto a Laravel application:

• Orchestration → queued Jobs (ProcessHardEditJob) on a dedicated media queue, dispatched from a controller or Filament/Nova action.
• Composition → build the ffmpeg command (-filter_complex with concat, trim, setpts, fade) or an MLT XML graph, generated from a stored edit-decision list (EDL) rather than from Pumukit objects.
• Domain → our own MediaAsset, EditRender, RenderSegment models replacing MultimediaObject/Track.
• Profiles → config-driven transcode profiles (config/media.php) replacing Pumukit's profile documents.
• Auth/ACL → Laravel Policies/Gates replacing Pumukit roles.
• Callbacks → Laravel events + broadcasting replacing Pumukit's notification bundle.

Migration path. There is no incremental migration from this bundle — nothing of ours consumes Pumukit today. The only porting artifacts are: the ffmpeg argument construction, the segment-trimming math, and the output-validation checks. Budget roughly:

1. Spike (1 week): reproduce one hard edit end-to-end with raw ffmpeg to validate the EDL model.
2. Port logic (2–3 weeks): job, EDL→filter-graph compiler, profile config, output registration, cleanup.
3. Harden (1–2 weeks): failure handling, temp-file GC, idempotency, metrics.

Compatibility. If a Pumukit system is already in the estate (e.g., a legacy lecture-capture deployment), install the bundle there, inside the existing Pumukit image, pinned to its exact Symfony/Pumukit minor and to a pinned ffmpeg build. Never bridge the two stacks in-process — integrate over the wire (shared object storage + internal API) if both must coexist.

Sequencing (if we proceed).

1. Confirm hard-editing requirement and its irreversibility trade-off with product.
2. License and provenance review; snapshot the upstream repo to a pinned internal mirror before any refactor.
3. Containerize the toolchain (ffmpeg/melt pinned, GPU optional) and validate codec matrix against our source material.
4. Build EDL schema + filter-graph compiler behind a feature flag.
5. Shadow-run against sample assets; compare output against expected durations/frame counts.
6. Cut over; keep the Pumukit reference implementation available read-only for the first release cycle.

Operational Impact

Maintenance. Forking or vendoring this code creates a permanent internal ownership line. With one upstream star and zero dependents, expect no upstream fixes — every ffmpeg CLI change, codec deprecation, or CVE in the binary chain is ours alone. Mitigate by keeping our implementation minimal (a filter-graph compiler plus a job) so the surface we own is ~1k lines rather than a Symfony bundle graph.

Support model. No community, no issue-tracker throughput, no vendor SLA. Escalation path for any defect is "read the source." This is acceptable only for a capability we own outright; it is unacceptable for anything on a critical path we don't staff.

Scaling. Hard editing is CPU-bound and linear in output duration — re-encoding a 60-minute lecture is minutes-to-tens-of-minutes of wall clock, not seconds. Design implications:

• Dedicated worker pool, isolated from web/API workers; autoscale on queue depth, not CPU average.
• Per-job resource caps and a concurrency limit derived from core count; oversubscription causes thrash and timeouts.
• Scratch disk sized to concurrent jobs × largest intermediate; a single 1080p50 intermediate can be several GB. Use node-local NVMe and delete aggressively.
• GPU encode (NVENC/QSV) is the only meaningful cost lever; validate quality parity before committing.

Failure modes to instrument explicitly.

• Partial/truncated output — ffmpeg exits 0 on some soft failures; validate duration, frame count, and stream presence before promoting the artifact.
• Orphaned temp files — crashed jobs leave multi-GB scratch; needs a TTL sweeper independent of job lifecycle.
• Zombie ffmpeg processes — worker restarts and timeouts leave encodes running; enforce process-group kill and a hard wall-clock cap.
• Codec/container mismatch — source with variable frame rate, unusual pixel format, or no audio stream breaks naive filter graphs.
• Storage blowout — output tracks double per-asset footprint; retention policy must be explicit.
• Irreversibility — a hard edit destroys the prior cut; require an explicit "render as new version" model and never overwrite the master.

Ramp-up. Two distinct skills, neither commonly held: (a) ffmpeg/MLT filter-graph authoring — error-prone, weakly typed, learned by inspection; (b) Pumukit internals, only if a Pumukit system is actually in scope. Budget 2–3 weeks for a competent PHP engineer to reach independent productivity on the Laravel re-implementation, and treat the ffmpeg knowledge as the long pole. Document the filter-graph compiler with golden-file tests — that is the only defense against silent quality regressions.

Bottom line for the steering group. Low adoption, no ecosystem, hostile stack fit, and a hard dependency on fragile binary tooling. Use it as a spec, not a dependency; fund a small owned implementation; expect media-processing, not web-app, operations.