On Thu, Nov 1, 2018 at 10:12 PM Philip Langdale <phil...@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 <phil...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
