[FFmpeg-devel] [PATCH 2/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

Hendrik Leppkes h.leppkes at gmail.com
Thu Nov 1 23:16:53 EET 2018


On Thu, Nov 1, 2018 at 10:12 PM Philip Langdale <philipl at overt.org> wrote:
>
> On 2018-11-01 14:05, Timo Rothenpieler wrote:
> > On 01.11.2018 21:54, Carl Eugen Hoyos wrote:
> >> 2018-10-26 17:56 GMT+02:00, Philip Langdale <philipl at overt.org>:
> >>
> >> Could you add some sample numbers about how fast the cuda
> >> variant is compared to cpu?
> >
> > I don't think such numbers are overly useful by themselves.
> > The primary benefit here is that it's now possible to decode,
> > deinterlace and encode all without pulling the frames out of VRAM.
> >
> > Though it would definitely be interesting. I guess hwupload +
> > yadif_cuda + hwdownload vs. normal yadif is a fair comparison?
>
> Yeah, the comparison is a bit fuzzy, because you completely
> change how you think about solving the problem depending on whether
> you have a filter available or not. But I did get some data previously.
>
> For cpu decode + cpu yadif, the yadif slowdown is ~50%
> For gpu decode + gpu yadif, the yadif slowdown is ~25%
>
> That means, the fps reported by `ffmpeg` when down by 50%/25%
> respectively. This was with null encoding.
>
> I can collect data for the up/down case, but I do think it's
> unrealistic - no one would actually do that.
>

One might do something like this:

NVDEC -> hwdownload -> yadif -> x264
NVDEC -> cuda_yadif -> hwdownload -> x264

How do those compare, maybe when you replace x264 with null?

- Hendrik


More information about the ffmpeg-devel mailing list