On Mon, 13 Feb 2017 09:03:09 +0100 Miroslav Slugeň <thunde...@email.cz> wrote:
> Dne 13.2.2017 v 05:03 wm4 napsal(a): > > On Sun, 12 Feb 2017 21:07:40 +0100 > > Miroslav Slugeň <thunde...@email.cz> wrote: > > > >> Dne 12.2.2017 v 20:59 Hendrik Leppkes napsal(a): > >>> On Sun, Feb 12, 2017 at 8:51 PM, Miroslav Slugeň <thunde...@email.cz> > >>> wrote: > >>>> This patch is for discussion only, not ready to commit yet. > >>>> > >>>> 1. Cuvid decoder actualy support scaling input to requested resolution > >>>> without any performance penalty (like libnpp does), so this patch is > >>>> proof > >>>> of concept that it is working like expected. > >>>> > >>> I don't think scaling is something a decoder should be doing, we don't > >>> really want all sorts of video processing jumbled up into one > >>> monolithic cuvid thing, but rather keep tasks separated. > >>> > >>> - Hendrik > >>> _______________________________________________ > >>> ffmpeg-devel mailing list > >>> ffmpeg-devel@ffmpeg.org > >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> Yes, but when you transcoding from FHD or 4K to SD quality it could save > >> alotof GPU resources. > >> > >> We have one example where "ONE" Quadro P5000 (2xNVENC) is downscaling > >> about 74 FHD streams to SD at realtime. > >> > >> I know it is not something that is acceptable in current ffmpeg, maybe > >> libav could adopt this patch. > > You mean the Libav project? They'd be even less likely to accept such a > > patch. > > > > Anyway, I don't think this would be slower than doing it in some sort > > of separate cuda video filter. > > _______________________________________________ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > This is not true, NVDEC (cuvid) is separate chipset and has its own > NVDEC load in nvidia-smi monitoring tool, while resizing with libnpp is > completly done on CUDA cores. In NVDEC only deinterlacing ADAPTIVE is > using CUDA cores more intensively, cropping and resizing in NVDEC is for > free :) I wasn't talking about libnpp. I'm assuming they provide their processing stuff as separate APIs somewhere. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
