[FFmpeg-devel] [PATCH] (for discussion): cuvid: allow to crop and resize in decoder

wm4 nfxjfg at googlemail.com
Mon Feb 13 10:09:45 EET 2017


On Mon, 13 Feb 2017 09:03:09 +0100
Miroslav Slugeň <thunder.m at email.cz> wrote:

> Dne 13.2.2017 v 05:03 wm4 napsal(a):
> > On Sun, 12 Feb 2017 21:07:40 +0100
> > Miroslav Slugeň <thunder.m at 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ň <thunder.m at 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 at 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 at 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.


More information about the ffmpeg-devel mailing list