# Add video processing to Activepieces Canonical: https://rendobar.com/blog/activepieces-video-processing/ Author: Abdelrahman Essawy Published: 2026-09-02 Updated: 2026-09-02 --- ## Key takeaways - One npm package adds 9 actions and 2 triggers to Activepieces, covering the same surface the SDK does. - Run a Media Job parks the flow on a waitpoint. In a verified run the flow paused 12 seconds in and finished at 20, with the step itself accounting for 546 ms of execution. - The form is built from GET /jobs/types/{type}/schema, so all 9 live job types appear in the dropdown and a new one needs no piece release. - The published bundle is 139 KB with zero runtime dependencies, down from 936 KB of raw input, because the framework is inlined the way every catalog piece does it. - Self-hosted Activepieces installs it unrestricted. On Activepieces Cloud, installing a piece outside their catalog is part of the Ultimate plan. Flow builders are good at moving small pieces of JSON between APIs. They are bad at waiting. The same problem shows up in [n8n](/blog/n8n-ai-agent-video-tools/), and it has the same answer there. A transcode that takes four minutes does not fit the shape of a step expected to answer immediately, and the usual workaround is a loop that asks whether the job is done yet until it is. ## Short version Rendobar has an Activepieces piece. It is on npm as `@rendobar/piece-rendobar`, and Activepieces installs it by package name from Settings, Pieces, Install Piece. It adds nine actions and two triggers. The part that matters is what happens while a job runs. **Run a Media Job** creates a waitpoint, hands Rendobar the resume URL as the job's callback, and parks the flow. Nothing executes in between. In a verified run against production the flow paused 12 seconds in and finished at 20 seconds, and the step itself accounted for **546 ms**. ## Waiting without burning a worker A polling step is not free. It occupies an execution for the entire job, and on a hosted plan that is the resource you are actually paying for. The longer the job, the worse the trade. A waitpoint inverts it. The flow submits once, stops, and resumes only when something external says it is time. _The flow is parked between the two green markers. A four minute encode and a four second one cost the same in execution time, which is none._ There is a failure mode worth naming. A waitpoint is useless if the callback cannot reach it, which is the normal case on a laptop or behind a firewall. The action checks whether the resume URL it was given is publicly reachable, and if it is not, it polls instead. That fallback needs no configuration, and it is why the Maximum Wait field exists. ## The form is built from the API, not from a list Most integrations hardcode their fields. Every new capability upstream means a new release downstream, and an integration that is a month behind is one that cannot reach half the product. This piece reads `GET /jobs/types/{type}/schema` and builds the form from the response. Choosing a job type replaces the fields underneath it with that job type's real parameters, descriptions included. _Picking compress.target added Source, For and Target. Picking ffmpeg instead produces a command field and a key value editor for input files._ All nine live job types appear in that dropdown, and a job type that ships next month appears without a piece release. The same schema drives the Variant dropdown, which is why it reads "Not used by this job type" rather than sitting there empty and ambiguous. ## What else is in it Eight more actions round out the surface: read a job, list recent jobs, read a job's logs, upload a file, share an output as a public URL, cancel a running job, check the account balance, and call any endpoint the piece does not wrap. Two triggers fire when a job finishes, one on a webhook and one by polling for instances that cannot receive one. Upload is worth a note. It streams rather than buffering, so putting a large file through a flow does not require holding it in memory first. ## Installing it _Installed from npm into a self-hosted instance. The version column is the npm version, so upgrading is a reinstall at a new number._ The package is MIT licensed and publishes from CI with npm provenance, so the tarball on the registry is attested to have been built from [the public repository](https://github.com/rendobar/activepieces-piece). It has zero runtime dependencies, because the framework is inlined at build time the way every piece in the Activepieces catalog does it, and that makes the artifact 139 KB from 936 KB of raw input. ## Where this stops Two limits, both real. **Activepieces Cloud gates custom pieces behind the Ultimate plan.** Installing a piece that is not in the Activepieces catalog is an Enterprise feature on their pricing page. Self-hosted instances have no restriction. So this reaches self-hosted users and Ultimate customers, and not the Free, Plus or Team tiers. **The timings above are one run.** Twelve seconds to pause and twenty to finish describes one ffmpeg job on one file, and the pause point depends on how quickly Rendobar picks the job up. What does not vary with load is the shape: the flow holds no execution while it waits. That is a property of the waitpoint, not a measurement. If you want the same behaviour from code rather than a flow, the [job type schema endpoint](/changelog/job-input-descriptor/) is the same one the piece reads, and [per-job callbacks](/changelog/per-job-callbacks/) are the mechanism underneath the waitpoint.