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 :)
M.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
