FFmpeg-over-IP – Connect to remote FFmpeg servers

Published: (March 10, 2026 at 02:26 PM EDT)
3 min read

Source: Hacker News

Use GPU‑accelerated ffmpeg from anywhere — a Docker container, a VM, or a remote machine — without GPU passthrough or shared filesystems.

The Problem

GPU transcoding is powerful, but getting access to the GPU is painful:

  • Docker containers need --runtime=nvidia, device mounts, and driver version alignment between host and container.
  • Virtual machines need PCIe passthrough or SR‑IOV — a complex setup that locks the GPU to one VM.
  • Remote machines need shared filesystems (NFS/SMB) with all the path mapping, mount maintenance, and permission headaches that come with them.

You just want your media server to use the GPU for transcoding. You shouldn’t need to restructure your infrastructure to make that happen.

The Solution

Run the ffmpeg-over-ip server on any machine that has a GPU. Point your application at the client binary instead of the local ffmpeg. The client pretends to be ffmpeg, forwards arguments to the server, and the server runs a patched ffmpeg that tunnels all file I/O back through the connection. Files are never stored on the server.

CLIENT (has files, no GPU)              SERVER (has GPU)
========================              ==========================
Media server invokes "ffmpeg"         Daemon listening on :5050
        |                                      |
ffmpeg-over-ip-client               ffmpeg-over-ip-server
        |                                      |
+--------- TCP connection ------------>+
        |                                      |
Local filesystem (real files)      patched ffmpeg
                                   (file I/O tunneled back to client)
  • No GPU passthrough.
  • No shared filesystem (NFS/SMB).
  • Just one TCP port.

Releases include pre‑built ffmpeg and ffprobe binaries with broad hardware‑acceleration support (NVENC, QSV, VAAPI, AMF, VideoToolbox, and more) — built on the jellyfin‑ffmpeg pipeline. No need to install ffmpeg separately on either side.

Quick Start

See the quick‑start guide to get up and running in a few minutes.

Upgrading from v4

Refer to the migration guide for breaking changes and upgrade steps.

Configuration

Full configuration reference (config file search paths, server/client options, rewrites, logging, address formats) is available in the configuration docs.

Docker

Instructions for Docker integration, Unix socket setup, and debugging tips can be found in the Docker documentation.

How It Works

  1. Your media server calls ffmpeg-over-ip-client with normal ffmpeg arguments.
  2. The client connects to the server and sends the command with HMAC authentication.
  3. The server launches its patched ffmpeg, which tunnels all file reads and writes back to the client.
  4. stdout/stderr are forwarded in real time; when ffmpeg exits, the client exits with the same code.

Multiple clients can connect to the same server simultaneously — each session gets its own ffmpeg process.

Supported Platforms

PlatformClientServer + ffmpeg
Linux x86_64
Linux arm64
macOS arm64
macOS x86_64
Windows x86_64

Troubleshooting

Common issues and debugging tips are documented in the troubleshooting guide.

Building from Source

See CONTRIBUTING.md for build instructions, testing, and project structure.

Security

  • Authentication: HMAC‑SHA256 with a shared secret. Every command is signed.
  • Single port: Only the server listens on a port; the client makes outbound connections only.

License

The project uses a split license:

  • The FIO layer and ffmpeg patches (fio/, patches/) are GPL v3 (derived from ffmpeg).
  • Everything else is MIT.

See the full license details in LICENSE.md.

0 views
Back to Blog

Related posts

Read more »

RISC-V Is Sloooow

Triaging I went through the Fedora RISC‑V trackerhttps://abologna.gitlab.io/fedora-riscv-tracker/ entries, triaged most of them currently 17 entries remain in...