Feature: GPU deinterlace (yadif_cuda/bwdif_cuda) in capture path #165

New issue

Open

opened 2026-05-29 14:11:12 -04:00 by zgaetano · 0 comments

zgaetano commented

2026-05-29 14:11:12 -04:00

Owner

Context

SDI capture currently deinterlaces with CPU yadif (~0.5–1 vCPU/signal). With the master+preview encodes moving to NVENC, deinterlace becomes the remaining per-signal CPU cost.

Proposal

Use yadif_cuda / bwdif_cuda once frames are on the GPU, keeping the pipeline GPU-resident (decode/upload → deinterlace → encode) and CPU near-idle.

Caveat (from design doc §4.1)

The current capture ffmpeg is built without --enable-cuda-nvcc/--enable-libnpp, which the CUDA filters require. This needs the builder rebased on nvidia/cuda:12.x-devel (the Dockerfile comment already notes this). So this is: (1) rebuild ffmpeg with CUDA filter support, (2) swap the filter when on GPU.

Why

Design doc §5 capacity goal — needed to actually hit 8 signals/node; otherwise CPU deinterlace caps the count.

## Context SDI capture currently deinterlaces with CPU `yadif` (~0.5–1 vCPU/signal). With the master+preview encodes moving to NVENC, deinterlace becomes the remaining per-signal CPU cost. ## Proposal Use `yadif_cuda` / `bwdif_cuda` once frames are on the GPU, keeping the pipeline GPU-resident (decode/upload → deinterlace → encode) and CPU near-idle. ## Caveat (from design doc §4.1) The current capture ffmpeg is built **without** `--enable-cuda-nvcc`/`--enable-libnpp`, which the CUDA filters require. This needs the builder rebased on `nvidia/cuda:12.x-devel` (the Dockerfile comment already notes this). So this is: (1) rebuild ffmpeg with CUDA filter support, (2) swap the filter when on GPU. ## Why Design doc §5 capacity goal — needed to actually hit 8 signals/node; otherwise CPU deinterlace caps the count.