DEV Community: Aihangsoft Tools

Trimming Video in the Browser: Why "Precise" and "Fast" Give Different Cuts

Aihangsoft Tools — Mon, 28 Sep 2026 01:43:03 +0000

There are two ways to cut a clip, and they answer different questions. A precise cut re-encodes the video, so the cut lands on exactly the frame you chose. A fast cut copies the compressed stream without decoding it, so the cut snaps to the nearest keyframe and the start can shift. Neither approach is wrong. Each is a trade between accuracy and speed.

The rest of this post explains why, with the actual ffmpeg commands for both.

Why a cut cannot always be arbitrary

Video is not stored as a sequence of independent frames. Most frames are described relative to other frames. A keyframe, also called an I-frame, is self-contained: it can be decoded on its own. The frames after it carry only the differences. The stretch from one keyframe to the next is a GOP, a group of pictures.

This is why a stream copy cut cannot start anywhere. If you ask to start at 4.2 seconds and there is no keyframe at 4.2 seconds, the tool cannot decode from there, because the frames at 4.2 seconds are defined relative to an earlier keyframe. Copying the compressed bits from 4.2 seconds would produce a broken first frame.

Encoders decide where keyframes go. A typical encoder places one every few seconds, plus at scene changes where a fresh reference makes sense. That spacing is usually not exposed to you, which is why a stream copy cut can land up to about one GOP away from where you asked. The longer the GOP, the larger the possible offset.

Both modes exist because of this constraint.

Fast mode: stream copy

Fast mode never decodes the video. It copies the compressed packets from one point to another:

ffmpeg -ss 00:00:04 -i input.mp4 -t 6 -c copy output.mp4

-ss 00:00:04 is the start time.
-i input.mp4 is the source.
-t 6 keeps 6 seconds from that start.
-c copy is the key flag: copy every stream as is, with no re-encode.

Because nothing is re-encoded, this is fast and lossless. The audio and video bytes are identical to the source, just a different slice of them.

The catch is the start point. With -ss placed before -i, ffmpeg seeks to the nearest point it can actually begin at, which is a keyframe. If the nearest keyframe is at 3.9 seconds and you asked for 4.2 seconds, the output begins at 3.9 seconds. The cut can only ever land on keyframes.

Placing -ss before -i also makes the seek fast, because ffmpeg jumps to the nearest keyframe instead of decoding from zero. Move -ss after -i and it decodes from the start of the file up to the requested point, which is slower. For a stream copy, the keyframe limit still applies either way.

Precise mode: re-encode

Precise mode decodes and re-encodes the selected range, so the cut lands on the frame you chose:

ffmpeg -ss 00:00:04.2 -i input.mp4 -t 6 -c:v libx264 -crf 20 -preset veryfast -c:a aac -b:a 128k -movflags +faststart output.mp4

-c:v libx264 re-encodes the video with H.264.
-crf 20 is the quality target. CRF stands for Constant Rate Factor: lower means higher quality and a bigger file, higher means smaller and rougher. 20 is a visually good default.
-preset veryfast trades compression efficiency for speed. A slower preset squeezes a slightly smaller file at the same quality, at the cost of encoding time.
-c:a aac -b:a 128k re-encodes the audio to AAC at 128 kbps.
-movflags +faststart moves the MP4 index to the front of the file, so playback can start before the whole file has downloaded.

Because this path decodes and rebuilds the frames, the start can be 4.2 seconds exactly. It also means the output is a new generation of encoding, and it takes far longer than a copy.

Which one to use

Use fast mode when the original must stay bit for bit identical, when speed matters, and when being off by a fraction of a second is acceptable. It is the right choice for a rough cut, or for a pre-trim before another step.

Use precise mode when the start and end must land on exact frames, for example cutting on a beat, on a title card, or to a fixed length with no drift. If you are unsure, prefer the precise cut and accept the re-encode: fast mode is for speed, not for accuracy.

Doing this in the browser

Both modes are plain ffmpeg, so both run under ffmpeg.wasm. The engine is around 30 MB and is fetched on first use, then cached and works offline. Because the same engine runs the same command line, switching between modes is just a change of flags, with no second implementation that behaves differently.

The video never leaves the device. There is no upload step, so a large source is fine on a slow connection, and nothing is left on a server afterwards. The output is always MP4, written with +faststart so it can stream while it downloads. The shortest range you can keep is 0.2 seconds.

What this tool does not do

One continuous range. It trims a single segment. To remove several pieces, you run it more than once.
Cutting is not reversible. Once the frames are dropped, they are gone from the output. Keep the source file.
It does not change the resolution or the codec. The output matches the input video. Re-encoding on the precise path keeps the same frame size and the same H.264 format; it does not resize the video or convert it to another codec.
It is not a compressor. Precise mode re-encodes, but the goal is an accurate cut, not the smallest possible file.
Long videos are limited by memory. A browser tab has a memory ceiling, so a very long or very high resolution source can fail where a desktop build of ffmpeg would not.

If you want a smaller file rather than a shorter clip, trim first and compress afterwards, or accept that a re-encode is the cost of an accurate cut.

Where to go next

The full write-up, including the cases where keyframe misalignment actually bites, is at https://www.aihangsoft.top/blog/trim-video-online.html. The trimmer runs entirely in your browser and is free.

Why Your Video-to-GIF Conversions Look Dirty, and the Two-Pass Palette Fix

Aihangsoft Tools — Mon, 28 Sep 2026 01:40:37 +0000

Most video-to-GIF conversions look dirty for one reason: they quantize every frame against a generic palette. A fixed 256-color table has no idea that your clip is mostly dark green grass with a single red ball in it. The fix is a two-pass approach: build a palette that belongs to this one video, then map the video onto it.

That is the whole idea. The rest of this post is the mechanics, plus an honest list of what a GIF still cannot do.

Why a generic palette fails

A typical converter does one of two things. It maps every frame onto the web-safe 216-color table, which ignores the real colors of your clip entirely. Or it builds one palette from the first frame and reuses it for the whole clip, which only works if the color story never changes. One cut, one camera pan, or one light change, and the reused palette is wrong for everything after it.

Either way, the 256 slots get spent on colors that are not in your video, and the colors that are in your video get approximated.

GIF gives you 256 colors, and that is a hard ceiling

A GIF frame is not RGB. It is an indexed image: each pixel is an index into a color table, and that table holds at most 256 entries. Video is roughly 16.7 million possible RGB values. Converting to GIF is lossy quantization, and no filter chain can bring back what the index step discards.

Dithering helps with the symptom. It spreads the quantization error spatially so gradients stop banding into flat steps. But dithering is a perceptual trick, it does not add colors. On noisy live-action footage it also adds visible grain and can make the file bigger, because a noisy pattern compresses worse.

So the goal is not a clean image. The goal is a palette built from your actual frames, so the 256 slots land where the colors are.

The two-pass filter chain

Both passes live in a single filter_complex graph, which is why the split filter appears:

ffmpeg -i input.mp4 -filter_complex "[0:v] fps=15, scale=480:-2:flags=lanczos, split [a][b]; [a] palettegen=max_colors=256 [p]; [b][p] paletteuse=dither=sierra2_4a:diff_mode=rectangle" -loop 0 output.gif

Walking through the pieces:

fps=15 reduces the source to 15 frames per second. GIF has no inter-frame compression worth depending on, so every kept frame is a full indexed image. Fewer frames means a smaller file. 15 is a common balance point for screen recordings and short UI clips.
scale=480:-2:flags=lanczos resizes to 480 px wide and computes the height to preserve the aspect ratio, forced to an even number by -2. lanczos resamples more sharply than the default bilinear filter, which matters because a soft downscale hides detail the color step is about to mangle anyway.
split [a][b] duplicates the processed stream. This is the part people skip and then wonder why nothing works. palettegen has to look at the video to build a palette, and paletteuse has to apply that palette to the same frames. Without split, one branch would consume the stream and the other would have nothing, or you would build a palette from a different input than the one you convert. The split feeds both branches from a single decode.
palettegen=max_colors=256 emits one PNG holding the 256 colors chosen across the sampled frames.
paletteuse=dither=sierra2_4a:diff_mode=rectangle applies the palette. sierra2_4a is an error-diffusion dither that looks cleaner than classic Floyd-Steinberg on video. diff_mode=rectangle restricts the error diffusion to the rectangle that actually changed between two frames, which speeds the encode up and keeps static regions from shimmering.
-loop 0 writes the Netscape looping extension with an infinite loop count. Without it, the GIF plays once and stops.

You can also run this as two separate ffmpeg calls, first to a palette PNG, then to the GIF. The single graph just avoids an intermediate file and a second decode.

Three parameters decide the file size

With the pipeline fixed, size is controlled by three knobs, and they multiply:

Duration. GIF size is close to linear in the number of frames kept. 2 to 5 seconds is the practical range. Past that, the file grows faster than most people will tolerate. If you need a long clip, GIF is the wrong format.
Frame rate. 10, 15, 20 and 24 fps are the useful choices. 10 is visibly choppy on motion, 15 is fine for most UI and screen recordings, and 20 or 24 smooth things out at a size cost roughly proportional to the extra frames.
Width. 320, 480, 640 px, or the original width. Pixel count scales with the square of the width, so doubling the width quadruples the pixels, and the file grows in the same ballpark.

There is no quality dial on top of these. The format has LZW compression, but that is lossless over the indexed data, it only removes redundancy. It does not let you trade quality for size the way a video codec does.

Running this in the browser

That chain is plain ffmpeg, and ffmpeg can be compiled to WebAssembly. ffmpeg.wasm runs the same filters in the browser from the same command line.

The cost is upfront: the engine is around 30 MB and gets fetched on first use. After that it is cached and the conversion works offline. The benefit is that the video never leaves the machine. There is no upload step, a large source is fine on a slow connection, and there is nothing left on a server to clean up. For internal recordings or client footage, that is usually the deciding factor.

What a GIF still cannot do

256 colors maximum. A per-video palette spends those slots well, but it cannot exceed 256. Sky gradients and subtle skin tones will still break up.
No audio. The format has no audio track, in any tool.
Size is brutally sensitive to duration. Doubling the seconds roughly doubles the file. There is no high-quality mode that rescues a clip that is simply too long.
Reducing frame rate or width is irreversible. You are discarding frames and pixels, and there is no upscale back to the source.
No cropping, background removal, or text overlay. A converter converts. If you need a crop or a burnt-in caption, apply it to the source video first, then convert.

If those limits break your use case, an MP4 or WebM is the right answer and a GIF is not.

Where to go next

The full version of this write-up, with a trade-off table for the three frame rates and three widths plus a GIF versus MP4 comparison, lives at https://www.aihangsoft.top/blog/convert-video-to-gif.html. The converter there runs entirely in your browser and is free, with no upload and no account.

How browser-based file tools work (and why nothing gets uploaded)

Aihangsoft Tools — Sat, 26 Sep 2026 12:05:04 +0000

TL;DR: When a tool says your files never leave your device, that is an architectural claim, not a marketing one. Here is the stack that makes it true, and what it costs.

Most online file converters follow the same shape. Your browser uploads the file, a server runs something like ImageMagick or headless FFmpeg, and you get a download link. The work is real, and often fast. The catch is that your file left your machine, and it now sits in storage you do not control, under a retention policy you did not agree to.

A browser-based tool keeps the same user experience and removes the server. Reading the file, processing it and writing the result all happen inside the tab. That is not a small variation on the upload model. It removes a whole class of problems, because there is no transfer to intercept, no queue to wait in and no retention window to think about.

Two architectures, same three steps

Step	Server-based tool	Browser-based tool
Reading the file	Copied into their storage	Read by the File API, stays local
Processing	Their CPU, usually queued	Your CPU, inside the tab
Result	A download link that expires	A Blob, ready immediately
Who can read the file	Anyone with access to their storage	Only you

WebAssembly is the reason this works at all

WebAssembly is a compact binary format that runs at close to native speed inside a sandboxed virtual machine. Engines written in C, C++ or Rust are compiled to it and shipped as ordinary static files.

The important part is that these are the real engines, not reimplementations:

qpdf for PDF encryption and decryption
FFmpeg for video and audio
Tesseract for OCR
pdf-lib and PDF.js for reading and writing PDFs
OxiPNG for lossless PNG optimization

A video encoded by the FFmpeg build in your tab is FFmpeg output, not a web approximation of it. That matters more than it sounds, because the old failure mode of browser tools was that they quietly did something worse than the desktop tool you were comparing them against.

Real first-load sizes, since these are files you actually download:

Engine	First-load size
FFmpeg core (video and audio)	about 30 MB
Tesseract plus English data	about 6.7 MB
qpdf WebAssembly	about 1.3 MB
PDF.js worker	about 1.4 MB

That is code, not your file. It is cached after the first run, and it does not grow with the document you feed it.

Canvas covers everything pixel-related

Images are the one category that does not need WebAssembly. The Canvas API exposes the same kind of drawing surface a native editor uses. createImageBitmap decodes a file, a canvas holds the pixels, and toBlob encodes the result back out to PNG, JPEG, WebP or AVIF. Cropping, resizing, watermarking and format conversion are pixel operations on that surface.

For PNG output you can pair Canvas with OxiPNG, which re-compresses the file losslessly instead of throwing quality away.

Web Workers keep the tab responsive

Heavy work on the main thread freezes the page, so long jobs belong in a Web Worker, a background thread with no DOM access. Video tooling hands work to FFmpeg inside a worker and receives log lines and progress events back, which is why the progress bar keeps moving while the encoder is busy.

One detail worth stealing: a single-threaded Tesseract build does not need SharedArrayBuffer, and therefore does not need the COOP and COEP headers that multi-threaded WebAssembly builds usually force on your whole site. Slightly slower per page, much smaller deployment constraint.

File and Blob are what replace the upload

This is the part that actually removes the network call. Slightly simplified, but this is the shape of the pipeline:

// Bytes come from disk into the page. No fetch, no POST.
const bytes = new Uint8Array(await file.arrayBuffer());

// Hand them to an engine running in the tab.
const output = await engine.run(bytes);

// Build the result and hand it back as a download.
const blob = new Blob([output], { type: 'application/pdf' });
const url = URL.createObjectURL(blob);

The bytes travel from disk to memory and back. There is no code path in that loop that talks to a network. It also means there is no upload size limit imposed by a server, only the memory limit of the device.

Verify it yourself in two minutes

Do not take the privacy line on a tool page on faith. Check it:

Open DevTools, go to the Network tab, and clear it.
Process a file.
Look at what showed up.

You will see the page, its CSS and its JavaScript, the engine on the first run, and web fonts. You will not see your document. Analytics scripts will also appear, and they report that a page was viewed, not what was in the file.

The stronger test: finish one run so the engine is loaded, then disconnect from the network and process another file without reloading. If it still works, the processing path never touched a server.

What it costs

Local processing is not free, and the honest version is worth stating:

A cold start is slow. The first run downloads the engine. On a slow connection that is a real wait.
Memory is the ceiling. Everything lives in one tab. A desktop tool streams a large file from disk, a browser tab has to hold it. Some tools publish a hard cap for exactly this reason.
A server can be faster. Video encoding is CPU-bound, and a browser build falls back to software encoding rather than a hardware encoder, so it does not get the GPU speedup a native build can use.

For a few megabytes of PDF or a one minute clip, none of this is felt, and you get privacy plus no quotas. For a two hour 4K recording, a desktop tool is the better answer, and it is worth saying so instead of pretending otherwise.

Where the model breaks

There is a category of job a browser tab cannot do: anything that depends on a large model. Background removal, object erasing and generative upscaling need weights that no reasonable page load budget covers, so those run on a server and the image is uploaded. A tool that does this should say so on the page, not in a footnote.

That is the useful test to apply to any tool that claims to be private. If it names a real engine and runs it in the tab, the file stays put. If it needs a bigger model than a browser can hold, it uploads, and it should admit it.

This post also lives on my blog at aihangsoft.top, where I build browser-based file tools that work this way.