Skip to content
PhramePhrame

Phrame NLE — remote editing

Phrame NLE — remote editing

Section titled “Phrame NLE — remote editing”

Edit remote media in a browser, frame-accurately, without the media ever reaching the browser. The timeline lives on the server, the compositing happens on the server, and what the editor receives is an encoded picture of the program.

Phrame NLE — the render happens on the server; the browser is a screen SERVER — decode, switch, composite. The essence stays here. TAMSsources · flowssegments tams-player ×Nseekable,frame-accurate phrame_switchone per track phrame_compositormulti-track+ key by reference VDI VDI nle-session — owns the timeline, drives the players phrame-webrtc-session — H.264 + Opus, WHEP VDI program MQTT control nle-web — browser: edit commands in, one video out WHEP · one authenticated viewer edit commandsREST + SSE Media essence and the compositing code never leave the server — the client receives an encoded picture, not the material

Why it matters

Section titled “Why it matters”

Editing has been the part of the production chain that stayed on a workstation. Everything else moved to software on commodity hardware; the edit suite kept its local storage, its local media, and its local application.

Phrame NLE moves it, and the reason it can is that the heavy work happens where the media already is. Storage is TAMS. The server holds the authoritative timeline, sources media by reference, decodes to exact frames, composites multiple tracks with keying, and streams the finished program to the browser. The browser sends commands and displays video.

What that buys:

  • Work from anywhere, with nothing to sync. No proxies to generate, no media to copy, no workstation to sit at. An editor needs a browser and a connection.
  • Frame accuracy that browsers cannot provide on their own. Frame-exact seeking in a browser is a documented platform limitation. Because the decode happens server-side, the editor is exact by construction rather than exact where the browser happens to cooperate.
  • The material and the effects never leave the building. Media essence and our compositing code stay on the server. A client that only ever receives an encoded picture cannot be used to extract either.
  • Edit near-live. TAMS grows on record, so material can be edited while it is still arriving, rather than after an ingest completes.

In one line: the edit suite becomes a URL, without giving away the media or giving up the frame.

Why this position is defensible

Section titled “Why this position is defensible”

The open-source browser-editor cohort converges on a client-side stack — WebCodecs, FFmpeg.wasm, WebGL, IndexedDB — with media on the client. That wins on server cost and offline privacy, and is structurally limited: browser frame inaccuracy, codec gaps at HEVC and 10-bit, memory ceilings on long-form and 4K, FFmpeg-WASM licensing exposure for closed products, and — decisively — it ships both the media and the effect code to a machine you do not control.

The commercial field leaves the same gap. Review tools are review, not editing. The browser-native editors are client-side. Desktop “cloud” offerings are local applications on synced proxies. The one pioneer of cloud editing did it through a proprietary codec and a client-side proxy, on a decade-old architecture. And server-rendered interactive editing streamed to a thin client is a pattern already proven at scale — in cloud gaming — but not yet in editors.

The moat is the integrated stack, not any single feature: a proprietary keyer and mixer, a frame-accurate render, WebRTC delivery, and a TAMS backend, behind a “just open a browser” experience. An open-source project cannot cheaply reproduce a render fleet or a broadcast keyer.

How it works

Section titled “How it works”

Media comes from TAMS by reference. Clips are addressed as a flow and a time range, not copied. Adding a clip to a timeline moves no essence.

Players decode to exact frames. One seekable player per source, feeding the Phrame bus. Because they are seekable rather than streaming, a scrub is a seek, not a wait for the next key frame.

Switches and the compositor build the program. Each track has a switch selecting which clip is live on it; the compositor combines the tracks and applies the overlay or key. This is the same vision-mixers code that runs live production — the editor is not a second, parallel implementation of compositing.

The program is encoded once and delivered to one viewer. phrame-webrtc-session reads the composited program from the Phrame bus, encodes H.264 and Opus, and serves a single authenticated viewer over WHEP. One process, one compositor, one viewer, no relay — that boundary is the isolation model, not an optimisation.

The browser is a client, not a source of truth. It sends edit commands over REST and receives state; it never holds the authoritative timeline. That is what keeps multi-user editing open as a future step rather than a rewrite.

Media-bin mode expands a bin into one warm player per clip, with the track switch selecting which is live. Cutting between clips then costs a switch rather than a decoder start.

Under the hood

Section titled “Under the hood”

The deployed channel is:

TAMS → tams-player ×N → phrame_switch (per track) → phrame_compositor
     → VDI program → phrame-webrtc-session (WHEP) → browser

with nle-session owning the timeline, driving the players and switches over MQTT, and minting the ES256 tokens the WHEP instances verify before accepting a viewer.

Net-new code is small on purpose. nle-session, nle-web, and the player and pool tooling are new; everything from the switch onward is existing platform components under a different configuration. The editor inherits the compositor, the Phrame bus and the WebRTC path rather than reimplementing them.

Binaries: nle-session (timeline, transport, orchestration), nle-source (a standalone seekable TAMS decoder), nle-pool-gen (expands a media bin into warm players and switch configurations), and nle-stamp.

Two monitors, two sessions. The program monitor is served from the compositor’s program output; the source monitor has its own compositor pass adding the strip and clock burn-ins before its own WHEP instance. They are separate phrame-webrtc-session instances on separate ports.

The channel ships as one image. nle-channel composes the supervisor, the mixer binaries, tams-player, output-processor and the WebRTC session into a single container for one-node-per-session deployment, built after its three dependencies at the same tag.

Delivery evolved. The original design carried the monitors over output-processor publishing WHIP into a mediamtx relay. That path was replaced by phrame-webrtc-session reading VDI directly: the NLE is single-viewer, so a relay’s fan-out and muxing bought nothing but latency.

Where the latency actually is — measured, and not where it was assumed — is covered under performance. The short version: server-side transit is tens of milliseconds, and the browser’s own jitter buffer is the dominant term.

Status. Under active daily development. This section describes the deployed channel as it stands, and it moves; where a claim here matters operationally, check it against the running system before relying on it.