Under the hood

How alter.video works

alter.video runs entirely in your browser. Your video is never uploaded to any server — all processing happens locally using FFmpeg compiled to WebAssembly.

What is FFmpeg WebAssembly?

FFmpeg is the most widely used open-source tool for video processing. It normally runs as a command-line program on servers or desktop machines. WebAssembly (WASM) is a binary format that lets native C/C++ code run inside a web browser at near-native speed.

The @ffmpeg/ffmpeg package ships FFmpeg compiled to WASM. alter.video loads this binary once (about 30 MB, cached by your browser afterwards) and uses it to process your video directly in the browser's sandbox.

Step-by-step: what happens when you click "Apply Edit"

  1. 01

    Load the engine

    The FFmpeg WASM binary is fetched (or retrieved from cache). Multi-threaded mode is used if your browser supports SharedArrayBuffer; otherwise it falls back to single-threaded.

  2. 02

    Write to virtual file system

    Your video file is read into memory as a Uint8Array and written to FFmpeg's in-memory virtual filesystem. Nothing is sent over the network.

  3. 03

    Build the filter graph

    Based on your selected operation (delete, speed up, slow down), the start time, end time, and speed factor, alter.video constructs an FFmpeg filter_complex argument string. This is the core of the editing logic.

  4. 04

    Run FFmpeg

    ffmpeg.exec() is called with the constructed arguments. FFmpeg processes the video inside the WASM sandbox. Progress events are emitted and shown in the UI.

  5. 05

    Read the output

    The processed video is read back out of the virtual filesystem as a Uint8Array, wrapped in a Blob, and made available as a download link.

  6. 06

    Clean up

    Both the input and output files are deleted from the virtual filesystem to free memory.

How the operations work

Delete

Removing a section

FFmpeg's trim and concat filters are used. The video before the selection and the video after the selection are each trimmed independently, their timestamps are reset with setpts=PTS-STARTPTS, and then concatenated back together without the gap.

Fast

Speeding up a section

The video is split into three segments: before, the selected section, and after. The middle segment has its presentation timestamps altered with setpts=(PTS-STARTPTS)/speed — dividing timestamps by the speed factor makes frames play faster. Audio is sped up with the atempo filter (chained if the factor exceeds the 2× per-node limit). All three segments are then concatenated.

Slow

Slowing down a section

The same three-segment approach as speed-up, but the middle segment uses setpts=(PTS-STARTPTS)*factor to stretch timestamps out. Audio uses atempo with the inverse factor (e.g. 0.5 for 2× slow). The final concat joins all three segments seamlessly.

Why re-encoding is required

All three operations use FFmpeg's filter_complex pipeline, which rewrites the video stream. This means the output is always re-encoded — you cannot stream-copy when applying filters. alter.video uses H.264 (libx264) with the ultrafast preset for speed, and AAC audio. This gives a good quality result quickly within the browser's WASM sandbox.

Privacy

Because everything runs in-browser, your video data never leaves your machine. There is no upload step, no server processing, no analytics on your content. The only network request is fetching the FFmpeg WASM binary on first use — and that binary is just code, not your data.