What distributed video transcoding does and why you'd use it
Distributed transcoding splits a single video file across multiple computers on your network, each handling a portion of the work at the same time. Instead of one machine grinding through a two-hour file for hours, you send chunks to three or four machines and finish in a fraction of the time. Linux Mint gives you the tools to set this up without paying for cloud services or proprietary software.
You need distributed transcoding when a single machine can't finish the job in reasonable time — converting a large video library, preparing files for multiple formats, or working with 4K footage on older hardware. A typical use case: you have five machines on your home network and want to convert ten hours of video to H.265 format. Splitting the work across all five cuts the wall-clock time from twelve hours to under three.
The trade-off is complexity. You'll manage multiple machines, coordinate file transfers, and troubleshoot network issues. For a one-off conversion, a single powerful machine is simpler. For regular work or large batches, distributed computing pays for itself in time saved.
Key Takeaways
- FFmpeg on Linux Mint handles the actual transcoding; distributed computing frameworks like GNU Parallel or custom scripts divide the work across machines.
- You split video files into segments, send each segment to a different machine for encoding, then reassemble the output — the bottleneck is usually network speed and disk I/O, not CPU.
- GNU Parallel is the simplest entry point for small networks; it runs commands across multiple machines with one line of code.
- NFS (Network File System) or Samba shares let all machines read the source video and write output to a central location, avoiding manual file copying.
- Testing on two machines first catches network and timing problems before you scale to five or ten.
Setting up FFmpeg and checking your network
Start by installing FFmpeg on every machine that will do transcoding work. Open a terminal on each Linux Mint system and run:
sudo apt update && sudo apt install ffmpeg
Verify the installation by typing ffmpeg -version. You should see version information and a list of codecs. All machines should have the same FFmpeg version or very close versions — mismatches can cause subtle encoding differences.
Next, confirm your network can handle the traffic. Transcoding generates large files: a one-hour 1080p video is typically 2–5 GB. If you're using WiFi, switch to Ethernet. Test the connection speed between two machines using iperf3. Install it with sudo apt install iperf3, start a server on one machine with iperf3 -s, and run iperf3 -c [server-ip] on another. You want at least 100 Mbps sustained; gigabit Ethernet is ideal.
Sharing files across machines with NFS
All machines need access to the source video and a place to write the output. NFS (Network File System) is the standard choice on Linux. Pick one machine as the server — usually the one with the most storage — and configure it to share a folder.
On the server machine, install NFS:
sudo apt install nfs-kernel-server
Create a folder for your video work, for example /home/username/video-transcode. Edit the NFS exports file:
sudo nano /etc/exports
Add a line like:
/home/username/video-transcode 192.168.1.0/24(rw,sync,no_subtree_check)
Replace 192.168.1.0/24 with your actual network range. Save and exit, then restart NFS:
sudo systemctl restart nfs-kernel-server
On each client machine (the ones doing the work), install the NFS client:
sudo apt install nfs-common
Create a mount point and mount the shared folder:
mkdir ~/video-transcode && sudo mount -t nfs [server-ip]:/home/username/video-transcode ~/video-transcode
Replace [server-ip] with the server's actual IP address. Test by creating a file on one machine and checking it appears on another.
Using GNU Parallel to distribute encoding jobs
GNU Parallel is the simplest tool for distributing work across machines. It takes a list of tasks and runs them on remote systems via SSH. Install it on the machine you'll use to coordinate the work:
sudo apt install parallel
Before using Parallel, set up passwordless SSH between your coordinator machine and all worker machines. On the coordinator, generate a key if you don't have one:
ssh-keygen -t rsa -N ""
Copy the key to each worker:
ssh-copy-id username@[worker-ip]
Test the connection: ssh username@[worker-ip] echo "connected" should print "connected" without asking for a password.
Now create a straightforward transcoding job. If you have a file called input.mp4 in your shared folder, you can encode it to H.265 with:
ffmpeg -i ~/video-transcode/input.mp4 -c:v libx265 -crf 23 ~/video-transcode/output.mp4
To split this across three machines, use Parallel to run the same command on each:
parallel -j 3 --sshlogin user@192.168.1.10,user@192.168.1.11,user@192.168.1.12 ffmpeg -i ~/video-transcode/input.mp4 -c:v libx265 -crf 23 ~/video-transcode/output-{}.mp4 ::: 1 2 3
This runs three separate encoding jobs in parallel, each writing to a different output file. The {} placeholder gets replaced with 1, 2, or 3 for each job.
Splitting a single file across multiple machines
The approach above works when you have multiple files to encode. For a single large file, you need to split it into segments, encode each segment on a different machine, then reassemble them.
FFmpeg can extract a portion of a video using the -ss (start time) and -t (duration) flags. For a two-hour video, calculate the segment duration: 120 minutes ÷ 3 machines = 40 minutes per segment.
Create a script called split-and-transcode.sh:
#!/bin/bash INPUT="$1" OUTPUT_DIR="$2" MACHINES=("192.168.1.10" "192.168.1.11" "192.168.1.12") SEGMENT_DURATION=2400 # 40 minutes in seconds for i in "${!MACHINES[@]}"; do START=$((i * SEGMENT_DURATION)) ssh user@${MACHINES[$i]} "ffmpeg -i ~/video-transcode/$INPUT -ss $START -t $SEGMENT_DURATION -c:v libx265 -crf 23 ~/video-transcode/${OUTPUT_DIR}/segment-$i.mp4" done
Run it with bash split-and-transcode.sh input.mp4 output. Each machine encodes its segment in parallel. When all jobs finish, you have three files: segment-0.mp4, segment-1.mp4, segment-2.mp4.
Reassemble them using FFmpeg's concat demuxer. Create a file called concat.txt:
file 'segment-0.mp4' file 'segment-1.mp4' file 'segment-2.mp4'
Then run:
ffmpeg -f concat -safe 0 -i concat.txt -c copy final-output.mp4
The -c copy flag copies the already-encoded data without re-encoding, so reassembly is fast.
Monitoring progress and troubleshooting common problems
When jobs are running across multiple machines, you lose visibility into what's happening. SSH into each worker and check the FFmpeg process:
ps aux | grep ffmpeg
This shows whether encoding is active and how much CPU it's using. Check disk space on the shared NFS server:
df -h ~/video-transcode
Transcoding can fill a drive quickly; if you're below 10% free space, stop the jobs and delete intermediate files.
The most common problem is network timeouts. If a worker machine loses connection to the NFS share mid-job, the encoding fails silently. Prevent this by mounting NFS with the hard option, which retries indefinitely instead of giving up:
sudo mount -t nfs -o hard,intr [server-ip]:/path ~/mount-point
Another frequent issue is codec mismatch. If one machine has an older FFmpeg without libx265 support, that job will fail. Run ffmpeg -codecs | grep hevc on each machine to confirm H.265 is available.
If reassembly fails with a "non-monotonic DTS" error, the segments were encoded with slightly different settings. may support all machines use identical FFmpeg commands, including the same -crf (quality) value and frame rate.
Scaling beyond three machines and optimizing performance
Once you have two or three machines working, adding more is straightforward: add their IPs to your Parallel command or your split script. However, returns diminish quickly. A network bottleneck usually appears around five machines — the shared NFS server can't feed data fast enough to keep all workers busy.
To optimize, use -preset in FFmpeg to trade speed for quality. -preset fast encodes quicker but produces larger files; -preset slow takes longer but compresses better. For distributed work, use -preset medium as a balance.
If your network is the bottleneck, consider copying the source file to local storage on each worker before encoding, then copying the output back to the NFS share. This trades disk I/O for network I/O and often speeds things up.
Monitor CPU usage on each worker with top or htop. If CPU is below 80% while encoding, your network or disk is the limiting factor, not processing power. If CPU is maxed out, you've found the real constraint.
Frequently Asked Questions
Can I use my GPU to speed up transcoding on multiple machines?
Yes, if your machines have NVIDIA or AMD GPUs. Compile FFmpeg with GPU support (usually --enable-cuvid for NVIDIA) and use -c:v hevc_nvenc instead of libx265. GPU encoding is much faster but requires identical hardware on all machines — mixing GPU and CPU workers complicates reassembly.
What if one machine is much faster than the others?
Assign it more work. Instead of one segment per machine, give the fast machine two segments and the slow machines one each. Adjust the SEGMENT_DURATION in your script or use Parallel's --load option to balance jobs based on actual CPU usage.
Do I need a dedicated server machine?
No, but it helps. The NFS server handles file I/O for all workers, so a dedicated machine with fast storage (SSD preferred) reduces bottlenecks. If you don't have a spare machine, one of your worker machines can also serve NFS, though it will be slower at encoding.
How do I know if distributed transcoding is actually faster?
Time a single-machine encode first: time ffmpeg -i input.mp4 -c:v libx265 -crf 23 output.mp4. Then time your distributed version. If distributed is slower, your network is the bottleneck — switch to local storage or use fewer machines.
Can I use this setup for live streaming or real-time encoding?
Not reliably. Distributed transcoding introduces latency from network transfers and job coordination. For live work, use a single powerful machine or a dedicated streaming encoder.