On Mon, Feb 13, 2017 at 12:43:51PM +0100, Hendrik Leppkes wrote: > 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.
scaling in some decoders is mandated by some specs some standards support reduced resolution which can switch from frame to frame without the decoder output changing There is also the possiblity of scalability where the reference stream has lower resolution IIRC. This is kind of different of course but, scaling code in decoders is part of some specifications. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
