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

[Miroslav Slugeň]

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 :)

M.