# REAL Video Enhancer: four model families, three inference backends, one PySide6 window > A cross-platform desktop front end that runs frame interpolation, upscaling, decompression and denoising through one pipeline, with a backend choice per GPU vendor. It buys that breadth with a heavier hardware floor than a single-model tool asks for, and the documentation carries a few seams worth reading past. **TNTwise/REAL-Video-Enhancer** — Interpolate, Upscale, Decompress, and Denoise videos easily on Linux/Windows/MacOS. - Repository: https://github.com/TNTwise/REAL-Video-Enhancer - Website: https://discord.gg/mRReVBMQtN - Stars: 2,350 · Forks: 163 - Language: Python - License: AGPL-3.0 - Published: 2026-10-14 · Updated: 2026-10-14 · Language: en - Canonical page: https://hysenlabs.com/projects/tntwise-real-video-enhancer ## The v2 rebuild carries a Linux-only Rife ESRGAN app onto three desktops REAL Video Enhancer is described as a redesign of the original Rife ESRGAN App for Linux, rebuilt on `PySide6-essentials==6.8.0.2` so one window runs on Windows, Linux and MacOS. The FAQ frames the target plainly: `24->48FPS` interpolation, `1920->3840` upscaling, plus a decompression pass and a denoiser. The default branch is named `v2-main`, which is the clearest sign that this is a second-generation codebase rather than a patch on the old tool. What lands on top of the port matters more than the port itself. Scene change detection exists to keep hard cuts sharp instead of blending them into invented intermediate frames, and a preview pane shows the most recently rendered frame, so a bad run can be stopped early rather than left to finish. Discord RPC is wired in through `pypresence`, covering both the Discord system package and the Discord flatpak. On Windows the binary can be flagged as a trojan, and pyinstaller is named as the cause, so an antivirus quarantine on first launch is an expected event rather than evidence of a bad download. ## TensorRT, PyTorch and NCNN split along GPU vendor lines Backend selection is the first real decision, and the three entries divide by vendor. TensorRT covers NVIDIA RTX GPUs, PyTorch covers CUDA 12.6 and ROCm 6.2 capable cards, and NCNN covers anything exposing Vulkan 1.3. That middle row carries more weight than the recommended-hardware column, which names only Nvidia, because an AMD card stays in scope through PyTorch even though the spec sheet never mentions it. Every backend brings its own documented failure. TensorRT stalls for a long time before the first frame because it optimizes against the device once per input resolution, so a resolution switch pays that cost a second time. When the optimization itself fails, the stated cause is limited VRAM and the stated remedy is to fall back to CUDA or NCNN, which is an admission that the fastest path has no repair switch of its own. ROCm failures get a wiki page and one adjective. A Vulkan error out of NCNN is read as an out of memory condition tied to a weak iGPU or a very old GPU. ## Four model tables separate interpolation, upscaling, decompression and denoising Models are not one list but four, and every row credits an outside author rather than shipping weights in the tree. Interpolation covers `RIFE 4.6` through 4.25 including a 4.22-lite build, plus GMFSS and IFRNet. Upscaling offers `4x-SPANkendata`, the 4x-Nomos8k-SPAN series, `2x-OpenProteus`, `2x-AniSD`, AnimeJaNai V2 and V3 Sharp, and AnimeSR. Decompression is a single model, `1xDeH264_realplksr`, running at 1x so H264 blocks are cleaned without a resolution change. Denoising adds DRUnet and DnCNN. One detail in that table rewards a close look. Both denoise rows credit the author as czsn while both links resolve to github.com/cszn/DPIR, so a skim reads it as a duplicated credit when it is a typo carried across two rows of the same table. A second mismatch sits further out. The repository topics include real-esrgan, and the name still descends from the Rife ESRGAN App, yet no ESRGAN model appears in any of the four tables. Upscaling runs through SPAN variants, OpenProteus, AniSD, AnimeJaNai and AnimeSR instead. ## The MacOS floor is stated twice and the two answers differ The hardware table and the feature list disagree about the oldest Mac this runs on. The table puts the minimum at MacOS 14+, while the feature list claims MacOS 15+ arm/x86 support. One of the two numbers is stale, and nothing in the repository says which, so a Mac user picks before the first launch rather than after it. The rest of the table is steadier. CPU is dual core x64 minimum and quad core recommended. VRAM splits by backend, 4 GB for NCNN against 8 GB for TensorRT, with an editorial aside attached to why 8 GB cards keep appearing. RAM is 16 GB minimum and 32 GB recommended. Storage is 1 GB free for NCNN and 16 GB free for TensorRT, which reflects how much cache the NVIDIA path writes. The GPU minimum is any Vulkan 1.3 capable device, and the recommendation is an Nvidia RTX card from the 20 series upward. ## Cloning pins 2.4.1 while the default branch stays on v2-main Two clone lines are given, and the difference between them is the entire upgrade decision. ``` # Nightly git clone --recurse-submodules https://github.com/TNTwise/REAL-Video-Enhancer # Stable git clone --recurse-submodules https://github.com/TNTwise/REAL-Video-Enhancer --branch 2.4.1 ``` Nightly takes the default branch, `v2-main`, and pulls submodules in the same step. The stable line asks for `--branch 2.4.1` instead, which is the version the README badge advertises. Because the default branch carries a v2 marker while the stable line carries a plain 2.4.1, anyone building from source has to pick a moving target or a fixed one on purpose. What the clone does not do is fetch a Python environment, so `requirements.txt` and a working backend remain the reader's problem. ## The published build command is cut off mid-word Building from source has three documented routes: pyinstaller, recommended for Windows and Mac, cx_freeze recommended for Linux, and nuitka marked experimental. Supported interpreters are 3.10, 3.11 and 3.12. Then there is the command itself. ``` python3 bui ``` That single line is the closest thing to an install instruction in the whole README, and it does not parse. The trailing fragment matches no module, no script and no filename anywhere in the top-level layout, which lists `build.py` instead. Supplying the missing characters is the obvious repair, and cheap, yet the published text is what a newcomer pastes on a first attempt. ``` PySide6-essentials==6.8.0.2 requests numpy==2.1.3 lief psutil py-cpuinfo distro pypresence certifi yt-dlp validators packaging pillow ``` The dependency file pins the GUI toolkit and numpy exactly while leaving requests, lief, psutil and the rest floating, and it pulls in `yt-dlp` and validators, so input can arrive from a link rather than a file on disk. No build flag, output directory or signing step is documented, which leaves a first local build to guesswork around one missing character. ## Flatpak, Steam and an NSIS script cover the packaging Three packaging routes sit outside pip. Flatpak is published as `io.github.tntwise.REAL-Video-Enhancer`, Ubuntu 22.04+ is supported on both the executable and the Flatpak, and 20.04 still works but is called legacy. A Steam build lives at store app 4087640, which puts the app inside a store client rather than a package manager. Windows carries its own installer script in the tree, `REAL-Video-Enhancer.nsi`, next to `REAL-Video-Enhancer.py`, `backend/`, `src/`, `scripts/`, `icons/`, `screenshots/`, `colors.txt`, `resources.qrc` and `testcases.py`. Flatpak also sidesteps the common failure, backend detection breaking under PIP and portable Python. A packaged build owns that environment, so it is the first thing to try when the app cannot see an installed backend. Two smaller signals sit in the layout. `testcases.py` means some model and backend combinations get exercised somewhere, though no outcomes are published. `EXTRA_NOTES.md` exists to hold notes the README does not carry. ## The Colab notebook is the documented fallback, not the GUI The project names two tools it positions against, Flowframes and enhancr, and calls them outdated without publishing a measurement behind the word. It also describes itself as a redesign of the original Rife ESRGAN App for Linux, so the comparison target is an older app of its own lineage rather than a current rival. What separates this build is bundling: four model families, three backends and one window, instead of one model paired with one inference stack. For hardware that cannot keep up, the FAQ points at a separate Colab notebook repository, `TNTwise/REAL-Video-Enhancer-Colab`, as the answer to NCNN out of memory errors. That is a genuine difference in approach, local GUI against hosted notebook, where the GPU belongs to someone else and nothing is installed on your machine. If a card stalls the TensorRT optimization or the NCNN path, that notebook is the path this project points to, and it carries the cost of uploading footage and waiting in a queue. What the desktop build does not offer is any headless or scripting mode. No command line flags appear beyond the clone and build lines, which makes it a poor fit for unattended batch work and a reasonable one for a person watching a preview pane. The code sits under AGPL-3.0, so a modified build you distribute stays under the same terms, and the last push landed on 2026-09-02 with RVE-2.4.2 still sitting as a pre-release dated 2026-01-09. ## Conclusion Adopt it when you want interpolation, upscaling, decompression and denoising inside one desktop window and your card clears Vulkan 1.3 with 4 GB of VRAM on the NCNN path, and accept that 16 GB of RAM is the stated floor. Pass on it if your renders run unattended, since no headless or scripting mode is documented anywhere, or if one model is enough, because the upstream repositories stay directly reachable. Before a local build, repair the truncated `python3 bui` line against your own `build.py`, then weigh the 16 GB RAM figure against the machine in front of you. ## FAQ ### Does REAL Video Enhancer have a command line mode or is it GUI only? It ships as a GUI application. The README documents no headless mode and no command line flags beyond the clone and build commands. ### Why does REAL Video Enhancer fail to recognise an installed backend? Inference runs through PIP and portable Python, which the FAQ names as the source of detection failures. Reinstalling the app is the step suggested before opening an issue. ### Why does the first TensorRT inference in REAL Video Enhancer take so long? TensorRT runs device optimization once per input resolution before inference starts. Switching to a different resolution pays that cost again. ### Which REAL Video Enhancer backend should an AMD GPU use? PyTorch is the entry listing ROCm 6.2 capable GPUs, while TensorRT targets NVIDIA RTX and NCNN covers Vulkan 1.3 devices. The FAQ sends ROCm errors to a ROCm Help wiki page and calls ROCm buggy. ### What are the GPU and memory minimums for REAL Video Enhancer? The table asks for a Vulkan 1.3 capable GPU with 4 GB VRAM and 16 GB RAM for the NCNN path, plus 1 GB of free storage. TensorRT is listed at 8 GB VRAM and 16 GB free storage. ### Is REAL Video Enhancer still being worked on? The last push was on 2026-09-02 and the repository is not archived. The most recent tagged build is RVE-2.4.2, marked pre-release and dated 2026-01-09, while the README badge still reads 2.4.1. ## Sources - [License: AGPL-3.0](https://github.com/TNTwise/REAL-Video-Enhancer/blob/v2-main/LICENSE) - [Project website](https://discord.gg/mRReVBMQtN) - [README](https://github.com/TNTwise/REAL-Video-Enhancer/blob/v2-main/README.md) - [Releases](https://github.com/TNTwise/REAL-Video-Enhancer/releases) - [TNTwise/REAL-Video-Enhancer on GitHub](https://github.com/TNTwise/REAL-Video-Enhancer) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tntwise-real-video-enhancer