RunPod FFmpeg at $0.33/hr isn't cheap. Price it per video.

You priced a video pipeline, found RTX 4090s renting for about thirty-four cents an hour, and the spreadsheet said you'd never pay for managed transcoding again. Then the hourly number refused to become a cost per video. The gap between the two is where most GPU-rental plans quietly fall apart.

Quick answer: A RunPod FFmpeg worker on a rented RTX 4090 lists at roughly $0.32 to $0.34 an hour, and Vast.ai community hosts sit in the same band, but the effective rate runs 20% to 40% higher once restarts and provisioned-but-idle minutes land on the invoice, before storage, egress, a retry queue, and the hours spent keeping the image current. One rented card only beats a per-minute video API above roughly 90 hours of input video a month, every month. Below that you're renting idle silicon, which is why FFmpeg Micro bills per second of input video with no idle line item at all.

A GPU sticker rate is a rental rate, not a processing rate

Renting a GPU bills wall-clock hours, and FFmpeg does not consume a card in wall-clock hours. On a 4090, H.264 NVENC with NVDEC decode runs about eight to twelve times realtime for 1080p, so a 60-second clip occupies the encoder for five to eight seconds. A thousand one-minute clips a day is under two hours of actual encoding.

You still pay for twenty-four. At $0.33 an hour that's $237.60 a month for a card doing real work about 7% of the time.

The effective rate is worse than the sticker because the meter doesn't start at the first frame. Billing begins when the pod provisions, which includes pulling a multi-gigabyte FFmpeg-plus-CUDA image, and a first-hand writeup on kdpisda.in titled "GPU Transcoding on vast.ai: Cheap, Fast, Not Yet Reliable" is the clearest public account of what that costs on unverified hosts: restarts, hosts that vanish mid-job, and time paid for capacity that never encoded anything. Budget 20% to 40% above the listed rate, which turns $238 into $285 to $333.

RunPod's serverless workers solve the idle problem by billing per active second, and they charge roughly two to three times the pod rate for the privilege, plus a cold start while the container comes up. That's not a loophole in the math. It's the market pricing idle capacity for you.

The line items that never appear in a GPU price comparison

The compute rate is the only number comparison guides publish, and it's rarely the largest part of running your own GPU transcoder. Storage is billed per GB-month on network volumes and keeps billing while the pod is stopped, because your FFmpeg image and model files have to live somewhere. Egress mostly lands on the other side of the wire: pulling a thousand 20 MB inputs out of Amazon S3 is 20 GB at about $0.09 per GB, so $1.80, and that scales badly the day someone starts sending 4K masters.

Then there's everything that makes the worker a service, not a script:

Put an hourly rate on that. Two engineer-days to get a reliable image and queue, then an afternoon a month, is roughly $800 up front at a $100 blended rate. That single build cost outweighs three months of the card.

NVENC is not CRF, so the quality math changes the cost math

The flag half of these plans assume doesn't exist on the GPU. -crf belongs to libx264 and libx265; NVENC's nearest equivalent is -cq inside a VBR rate-control mode, and it behaves differently enough that a "same settings, now on GPU" migration usually ships a different-looking file.

The quality setting the encoder silently ignores

Setting -cq by itself does almost nothing, because h264_nvenc still has a default bitrate target that overrides it. You have to zero the bitrate out:

# Ignored: -cq loses to the encoder's default bitrate target
ffmpeg -i in.mp4 -c:v h264_nvenc -cq 23 out.mp4

# Applied: VBR with no target bitrate, so constant quality governs
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i in.mp4 \
  -vf scale_cuda=1920:1080 \
  -c:v h264_nvenc -preset p5 -tune hq \
  -rc vbr -cq 23 -b:v 0 -maxrate 12M -bufsize 24M \
  -c:a copy out.mp4

Even configured correctly, NVENC trades compression for speed. Plan on 20% to 40% more bits to match what x264 at CRF 23 gives you, and verify with VMAF on your own content rather than trusting a preset table. You can close much of that gap with -preset p7 and -multipass fullres, and that cuts throughput by more than half, exactly the throughput the cost model was built on. Bigger files also mean more egress and more storage, so the quality shortfall shows up twice.

Where the GPU stops helping entirely

Most FFmpeg filters are CPU code. subtitles, ass, and drawtext all run in system memory, so a caption burn-in pipeline has to hwdownload every frame off the card, filter it, and hwupload_cuda it back. Community 4090 listings frequently pair that card with a handful of vCPUs on an older Xeon, so the slowest part of the machine does the work you actually care about. If your job is burning captions onto vertical clips, a rented GPU buys you very little.

Hardware scaling moved too: scale_npp was removed in FFmpeg 9 in favor of scale_cuda, so any Dockerfile or filter chain copied from a 2024 tutorial needs editing before it builds.

Per job, the crossover sits around 90 hours of video a month

Comparing a rental to an API only makes sense per unit of video, so here's the same workload priced three ways. FFmpeg Micro charges one token per 10 seconds of input, metered per second, which works out to about 4.3 to 5 cents per input minute depending on plan and top-up rate.

Read the bottom row honestly: at sustained volume, a rented card is roughly seven times cheaper per minute than any per-minute API, and no amount of framing changes that. If you're running a VOD library through a steady, predictable grinder, rent the GPU.

The top row describes most readers of this blog. An n8n workflow that fires on a webhook, a Make scenario watching a Drive folder, a UGC pipeline that gets busy on Tuesdays: those are bursty, and bursty workloads pay for idle capacity. At 400 minutes a month the rented card costs 59 cents per minute of video, twelve times the API rate, and the $238 arrives whether the webhook fires or not.

That asymmetry is the whole argument for a managed path. The FFmpeg Micro API bills the duration of the video you process, not how long the servers take, with no rounding up to the minute, and failed jobs are never billed. Trim a 30-second clip out of a one-hour recording and the charge is 30 seconds. There's no idle line because nothing is reserved.

When renting a GPU is genuinely the right call

GPU rental earns its keep on steady, high-duty-cycle throughput where the card is busy most of the day and one engineer already owns the pipeline. It also wins when you need hardware a managed API doesn't expose, such as AV1 encode on Ada silicon, or when compliance rules say the media cannot leave infrastructure you control. If a GPU pod is already running for inference, adding an FFmpeg step to it is close to free.

It's the wrong call for pipelines dominated by CPU filters, for anything under a few thousand minutes a month, and for teams with no one on call for a stuck encode at 2 a.m. The honest dividing line is duty cycle, not price per hour.

Common pitfalls when moving FFmpeg onto a rented GPU

Most surprises in a GPU transcoding bill come from mechanical issues, not from the encoding itself.

FAQ

Can you run FFmpeg on RunPod?

Yes, FFmpeg runs on RunPod in any container you bring, either as a persistent pod or a serverless worker, and with nvidia-container-toolkit it can use NVDEC and NVENC on the rented card. The work is not getting FFmpeg to run; it's the queue, retries, storage, and progress reporting you build around it to make it a service.

Is Vast.ai cheaper than RunPod for FFmpeg?

Vast.ai's community listings and RunPod's community tier both land around $0.32 to $0.34 an hour for an RTX 4090, so the sticker rates are close enough that reliability decides the real cost. Vast.ai's unverified hosts are usually the cheapest per hour and the most likely to interrupt a job, and an interrupted encode is billed time with no output.

Does NVENC produce the same quality as libx264 CRF?

NVENC does not match libx264 bit for bit at the same file size. NVENC on Ada hardware is close enough for most social and web delivery, but matching x264 at CRF 23 generally takes 20% to 40% more bitrate, and NVENC has no true CRF mode at all, only constant-QP and a constant-quality VBR mode driven by -cq.

How much does GPU transcoding cost per video?

Cost per video on a rented GPU is the hourly rate divided by how much video you actually push through it, not the rate divided by encode time. A $238-a-month 4090 processing 400 minutes costs about 59 cents per input minute; the same card processing 40,000 minutes costs about six tenths of a cent.

Do I need a GPU to transcode video at scale?

Most pipelines do not need a GPU. CPU encoding with libx264 at a sane preset handles social-format clips and 1080p web delivery fine, and the bottleneck in automation workflows is almost always queueing, upload, and retries rather than encoder throughput. A GPU pays off at sustained volume with the card busy most of the day, which is also why running FFmpeg inside your own n8n image is the wrong layer to optimize.

Run your own volume through the arithmetic before committing to a card: the per-job pricing comparison shows where a metered API lands against reserved capacity, and the free tier's 200 tokens cover about 33 minutes of video with no card required, enough to encode the same clip both ways and diff the output yourself.