Pumukit Soft Video Editor Bundle Laravel Package

Getting Started

Prerequisites for this bundle are the same as for PuMuKIT itself: a working PuMuKIT application (Symfony 2.x/3.x era), MongoDB reachable via Doctrine ODM, and ffmpeg/ffprobe on the host. This bundle is not a standalone package — it only makes sense as an add-on to an existing PuMuKIT install.

Install it into the PuMuKIT app, not your own project:

composer require teltek-software/pumukit-soft-video-editor-bundle

Register it (Symfony 2/3 style, since the last release is 2019):

// app/AppKernel.php
$bundles[] = new Teltek\Pumukit\SoftVideoEditorBundle\PumukitSoftVideoEditorBundle();

Then import its routes in app/config/routing.yml:

pumukit_soft_video_editor:
    resource: "@PumukitSoftVideoEditorBundle/Resources/config/routing.yml"
    prefix: /

Where to look first, in this order:

1. DependencyInjection/Configuration.php — this tells you what (if anything) is configurable: storage of clip data, ffmpeg paths, enabled track types.
2. Controller/ — the editor endpoint, usually taking a Multimedia Object id as a route parameter.
3. Resources/views/ — the Twig editor UI you will either link to or override.
4. Form/ — the form type backing the editor; this is your best API surface if you want to reuse the in/out point logic without the stock UI.

First use case: open an existing Multimedia Object in the PuMuKIT admin, navigate to the soft-editor route, mark in/out points over an already-transcoded track, save, and confirm the clip metadata round-trips (reload the page / query Mongo). Do that before touching any publishing or player work — it proves the bundle is wired correctly.

Implementation Patterns

Link, don't rebuild. The lowest-effort integration is adding a "Edit video" button in your PuMuKIT admin template that points at the bundle's editor route. You keep PuMuKIT's own upload/transcode pipeline untouched and use the bundle purely as an UI over the track metadata.

<a href="{{ path('pumukit_soft_video_editor_edit', {'id': mmobj.id}) }}">
    {{ 'Edit video'|trans }}
</a>

Treat clip data as the contract. Soft editing means nothing is re-encoded: the value stored on the Multimedia Object / Track is a list of ranges (in/out, order). Decide early who reads that field:

• the editor writes it,
• your player (HLS/DASH manifest, or a JS player with seek boundaries) reads it,
• your API/serializer exposes it to clients.

If you don't own all three, the feature never leaves the admin.

Reuse the Form type. If you need a custom workflow (e.g. "mark clips then send to approval"), instantiate the bundle's form in your own controller instead of duplicating the editor. That keeps range validation in one place.

Override the player/export path with a decorator. Because soft edits reference existing tracks, publishing "the clipped version" is your responsibility. The usual pattern is an event listener or a service decorator around PuMuKIT's track/player service that materializes the clip list into either:

• a playlist endpoint consumed by a front-end player (cheap, no ffmpeg), or
• an ffmpeg -f concat render in a job/queue when a downloadable file is required.

Pick the playlist route unless a stakeholder explicitly demands a file.

Template override over fork. PuMuKIT/Symfony resolves templates by bundle path, so override the editor view in app/Resources/PumukitSoftVideoEditorBundle/views/... rather than editing vendor code. Same for translations (es, en are likely the only ones shipped).

Gotchas and Tips

• It is effectively unmaintained. Last release April 2019, 3 stars, 0 dependents. Expect PHP 7.x, Twig 2 and Symfony 2/3 constraints; composer require will almost certainly conflict on a modern Symfony app. Plan on either pinning an old stack or vendoring the handful of classes you actually need.

• No community to ask. Fork it, and expect to be the maintainer. Read the code before trusting the README.

• Mongo schema drift. Clip data is embedded in the Mongo document. If you upgrade PuMuKIT/ODM, older documents may hydrate with missing/renamed fields. Write a small migration or a null-safe accessor early.

• Soft edit ≠ encoded output. Any export, download, or third-party embed will ignore the clip boundaries unless you implement concatenation yourself. This is the single most common misunderstanding with "soft" editors.

• Validate ranges server-side. in < out and out <= duration must be enforced on save; the UI alone is not enough, and a bad range breaks downstream concatenation silently.

• Assets and cache. After installing, clear both: bin/console cache:clear and whatever asset pipeline PuMuKIT uses. A 404 on the editor JS is the usual first symptom of a routing/asset miss.

• Debug routing with the container, not the docs:

  bin/console debug:router | grep -i soft
  bin/console debug:container | grep -i soft
  

  This gives you the real route names and service IDs to link against.

• Extension points worth knowing: service override in app/config/services.yml, a Twig template override for the UI, and an event subscriber on the Multimedia Object post-update hook to sanitize/normalize clips. Those three cover most customization without forking.

• Test on a real object with a long track. Boundary behavior at the very start/end of a track and at track transitions is where soft editors typically break, and short sample clips won't reveal it.