Build1 publisher2 min readPublished
Miraiclip routes every browser video edit through a validated command log
Miraiclip takes edits only as dispatched commands, keeps a microsecond-precision timeline and a full history, and emits every change as an RFC-6902 JSON patch. Everything a user touches, you write yourself.
The Engineer · Build desk
What happened
- Miraiclip, a framework-agnostic library for building video editors in the browser, is now published on npm under the MIT licence.
- The core is headless and holds project state, a microsecond-precision timeline and a full command history, with rendering delivered as a separate layer.
- Callers dispatch descriptive commands instead of calling methods that mutate state, and each command is deterministic, schema-validated, serializable and invertible.
- The renderer package pairs a WebCodecs decode pipeline with a PixiJS WebGL compositor on an audio-master clock, and the export path runs through that same compositor.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost Anything a user touches is the adopting team's code: the timeline widget, the trim handles, the keyboard map, because the core ships with zero UI dependencies.
- constraint Rendering off the client means operating headless Chrome in production, since the server-export package runs the identical browser pipeline from Node.
- capability One integration path can serve a click, an agent's plan and a replayed collaborator edit, because all three produce the same schema-validated command objects.
- decision Teams already maintaining their own frame-accurate playback and undo code have something to evaluate, and they will have to measure export speed on their own footage.
The sample project is set at 30 fps [5]. At that rate a frame lasts 33,333.33 microseconds, so an integer microsecond timeline pins a frame boundary only to within half a microsecond, about 0.0015 percent of a frame [19]. The sample edit lands clean regardless: a split at 2,000,000 microseconds inside a 5,000,000 microsecond clip is frame 60 of 150 [20]. Every command in that example is validated against a schema and invertible [4]. That is what makes the history replayable. On his lessons list, the author wrote that frame accuracy "means presented frames, not scheduled ones" [17].
Running one compositor on both paths is what gives preview and export their parity, though not pixel identity [12][15]. The sample builds the Pixi backend at 1280x720 while the project is 1920x1080 [10][5], which is 921,600 pixels against 2,073,600, or 44 percent [21]. Blur is on the built-in effect list [15]. If its radius is specified in pixels, that is where I would diff a preview frame against the exported one.
Read the decoder line too. The sample caps WebCodecs output with maxOutputDimensionPx: 1920 and comments it as a proxy preview [11]. The project is 1920 wide [5], so for 1080p sources that cap downscales nothing, and it only starts doing work on 4K footage [22].
The premise is the author's own, argued in a post about his own library. Frame-accurate playback, undo that never corrupts state, and exports that match the preview are "engine problems, not product problems", and every team pays for them again because there is nothing to reach for [3]. Because the command catalog is published as JSON schemas and doubles as a tool definition [8], a model that emits a malformed edit fails validation rather than mutating state [4]. Granular RFC-6902 patches are described as the substrate for multiplayer editing [7]. The caller still owns transport, presence and conflict policy.
The offline export is labelled faster than realtime in a code comment [16], and the post does not include benchmark numbers or a list of supported browsers [18]. For that comment to describe your render, your machine needs a hardware encoder WebCodecs will actually use for MP4 or WebM output [13]. It also needs decode headroom above your source frame rate, and an effect stack that fits the GPU passes you have spare. Where any of those is missing, the comment describes their machine.
Output can stream straight into a showSaveFilePicker writable so a long export does not accumulate in memory [13].
What to watch
- Published export benchmarks on named codecs and hardware would make the faster-than-realtime comment checkable on someone else's footage.
- A browser support matrix for the WebCodecs decode path. The renderer depends on that path.
- Whether anyone builds a sync layer on the RFC-6902 patch stream. That is the test of the collaboration claim.