blur adds motion blur to video by blending frames, not by filtering

Motion blur is produced by weighting and blending frames

The core idea of f0e/blur is that motion blur is not a filter you apply to a picture, it is a result of averaging what the sensor saw over a fraction of a second. Blur takes consecutive frames of a clip and blends them together, so anything that moved during the exposure is smeared while anything static stays sharp.

The distinction shows up in the description of the tool's own output. The README notes that this motion blur does not blur non-moving parts of the video, like the HUD in gameplay footage. That is the behaviour you want from a real camera exposure, and it is also the thing a naive directional filter cannot do, because a filter has no idea which pixels moved.

The application is native, written in C++, and the repository is laid out like a desktop project rather than a Python script. It has a CMakeLists.txt, CMakePresets.json, a vcpkg.json, a flake.nix and a flake.lock, a mise.toml for tool versions, an installer/ directory, a ci/ directory and a tests/ directory, plus .clang-format, .clang-tidy and .clangd for tooling. A .pre-commit-config.yaml and .gitmodules indicate the project manages its own dependency submodules.

The last push to the repository was on 2026-10-12. Tagged releases include v2.45 on 2026-05-12, v2.44 on 2026-02-19 and v2.43 on 2026-01-25. The licence field on the repository says GPL-3.0, which matters for anyone who wants to wrap the tool in a commercial pipeline.

Blur amount and output fps are one knob expressed twice

Because the effect is produced by blending frames, the strength of the blur and the output frame rate are the same decision viewed from two ends. Blur amount is documented as 0 for no blur, 1 for fully blending every frame together, and anything above 1 for more blur or ghosting. Output fps can be set as a number such as 600 or as a multiplier such as 5x.

The README gives a table of blur amounts for 60fps footage: above 1 for maximum blur, 1 for normal blur, 0.5 for medium blur and 0.2 to 0.3 for low blur. Crucially it also gives the conversion rule for when the framerate changes, so that the same perceived blur is preserved.

[new blur amount] = [old blur amount] × ([new fps] / [old fps])

So normal blur at 30fps becomes 0.5, and the same visual result can be produced at a different frame rate by scaling the amount rather than by guessing. This is the single most useful line in the documentation for anyone who has already produced a result they liked.

Interpolation is the other half. The interpolated fps setting is a separate value, either a set frame rate or a multiplier written with an x suffix such as 5x. The advice given is around five times the input frame rate, with a ceiling noted for SVP at ten times the input. Pushing it further is where output quality degrades, which is worth understanding before chasing more frame rate than the source can support.

Weighting decides which frame dominates the blend

Not every blend is an equal average. Blur exposes a weighting function setting, with options that include equal, gaussian_sym, vegas, pyramid, gaussian, ascending, descending and gaussian_reverse.

equal
gaussian_sym
vegas
pyramid
gaussian
ascending
descending
gaussian_reverse

The equal option blends each frame equally, and the ascending and descending variants tilt the weight towards the start or the end of the window, which changes whether the smear leads or trails the subject. The repository also carries a comparison document for these functions at tests/plot_weighting_functions/weighting_functions.pdf, so you can read the curves before rendering rather than after.

For anyone who needs a specific weight profile, the setting also accepts custom comma-separated frame weights, with higher numbers making a frame more visible in the blend and lower numbers less so.

5, 3, 3, 2, 1

This is a small feature with a large effect on the result, because the weighting curve is what separates a natural trail from a flat ghost. It is also the kind of thing that is hard to reproduce in a general purpose tool, where you are limited to a fixed kernel.

RIFE and SVP split the platforms and the bill

Interpolation is done by an external model, and blur supports two of them: RIFE and SVP. The documentation compares them on two axes, quality and speed, and the order reverses between them. RIFE is listed as more accurate than SVP but considerably slower, and SVP as faster than RIFE.

The platform default is not the same everywhere. On macOS the default interpolation program is RIFE, unlike Windows and Linux. The reason given is specific rather than technical: using SVP for interpolation on macOS requires SVP Manager to be running, otherwise you get a red border around videos. SVP Manager is a paid product that is not affiliated with Blur, it provides a 30 day trial and then costs $24.99 for a lifetime licence. RIFE can always be used on macOS, but it is slower.

There is also a pre-interpolation stage, which enables a more accurate but slower AI model before the main interpolation pass, with its own frame rate setting.

The practical consequence is that the same render can cost very different amounts of time and money on the three operating systems, and that a team standardising on one model needs to standardise the platform too.

Getting the app onto each platform is three different procedures

There are prebuilt binaries for all three major platforms, but the route to a working installation differs sharply. Windows has an x64 installer, macOS has an arm64 disk image, and Linux has an x64 tar archive that the README explicitly marks as requiring manual installation of dependencies.

The macOS path has a well known snag. On first launch you can get a 'Blur is damaged and can't be opened.' error, and the fix is to remove the quarantine attribute from the downloaded application.

xattr -dr com.apple.quarantine /Applications/blur.app

Beta builds are handled separately from stable releases. The author states that beta versions with new functionality are often released before they are considered stable, that they live in the Releases tab of the repository, and that update notifications for them can be switched on by enabling `include beta updates` in a `blur.cfg` file found in the config folder.

For automation there is a command line entry point as well, since the program can be used in the command line via `blur-cli`, with -h or --help for more information.

blur-cli

The README documents no build-from-source instructions, so anyone who needs a custom build is left to read the CMake and Nix files in the repository.

Two quality traps that the tool partly fixes for you

Motion blur from frame blending has two characteristic failure modes, and the documentation is unusually honest about both.

The first is smearing on footage that does not contain enough real motion information. Using blur on 60fps footage produces clean motion blur but occasionally leaves smearing artifacts, and the stated remedy is better source material: recording with software such as OBS at 120 or 180fps greatly reduces the artifacting. That is a real limit of the technique, not of the implementation, because there is no motion detail in the original frames to average.

The second is unsmooth output caused by duplicate frames. If the footage contains repeated frames, some blended frames look out of place and the video seems to stutter at those points. The 'deduplicate' option fills in duplicated frames with interpolated frames, so the sequence the blender consumes is regular even when the recording was not.

The interesting sample output in the README shows 600fps footage blurred with a 0.6 amount next to 60fps footage interpolated to 600fps and blurred the same way, and states that the interpolated result produces motion blur comparable to the genuine high frame rate original. That is the value proposition in one comparison, and it is a claim about appearance rather than a measurement.

Frameserver output skips a re-encode of your source

The workflow question for anyone using blur inside an editor is how many times your footage gets encoded. Rendering through the application on the input file means the source is decoded and re-encoded on the way in, and then your editor does it again on the way out. Blur supports rendering from frameservers as the alternative.

The procedure is: output the render to the frameserver, make sure the project is set to a high frame rate, and then drag the generated AVI into blur. The README warns that some video editing software limits the maximum project framerate, which is a practical constraint rather than a theoretical one.

The result is that the heavy work happens once, on the frameserver output, and the intermediate file is an AVI. In an editing pipeline this ordering matters, because a second generation of compression on footage that has already been blended will soften exactly the detail the motion blur is supposed to display.

This is also the main reason to reach for the command line form rather than the window, since a frameserver workflow is inherently a pipeline rather than an interactive task, and blur-cli is the documented way to drive the same operation from a script.

Where blur is the wrong tool

Blur is a native desktop application, not a library and not a filter plug-in, and that boundary rules out several legitimate use cases.

If you need to blur video in a headless render farm, in a CI pipeline, or inside a server-side media service, there is no documented library API to call. The command line companion exists, and it is the reasonable path for scripting on a machine with a display or a virtual one, but the documentation does not describe a daemon or a service mode. A ffmpeg or VapourSynth based pipeline, the two ecosystems named in the repository topics, fits that shape better.

The licence is the other boundary. GPL-3.0 is not a permissive licence, and embedding or redistributing the application inside a commercial product raises obligations that a permissive licence would not. Anyone weighing this should read the LICENSE file for themselves; the point here is only that the terms are the copyleft ones and not the MIT style notice used by many tools in this space.

Finally, the tool is aimed at people who want motion blur on footage that lacks it. If your source is already 600fps, blurring it will not add detail, it will only soften what you have.

Editorial conclusion

Adopt blur if your footage was recorded below the frame rate you need, because the frame blending plus interpolation path can approximate a 600fps look from 60fps input, and the deduplicate option exists for the duplicate frames that cause visible stutter. Do not adopt it if you need a scripted batch pipeline on a headless server, since the tool is a desktop application with a blur-cli companion rather than a library, and note the GPL-3.0 licence before shipping anything built on it. Before rendering, check the blur amount against the fps conversion formula, confirm your interpolation method works on your platform, and on macOS remove the quarantine attribute with xattr -dr com.apple.quarantine /Applications/blur.app or the app will not open.

Frequently asked questions

Official sources

1. f0e/blur on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases