On Mon, Feb 13, 2017 at 11:36 AM, Timo Rothenpieler <t...@rothenpieler.org> wrote: > Am 12.02.2017 um 20:59 schrieb Hendrik Leppkes: >> 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. > > I'm generally in favor of adding this, but I don't see why ffmpeg.c > needs changes for this. > The decoder should already be free to return any video size it likes. > > CUVID is kind of a huge special case with its deinterlacing already, > cropping/resizing the output is quite trivial compared to that. >
We recently just had all sorts of discussions what decoders should and should not do, I don't think scaling in a decoder is a good thing to start doing here. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
