[FFmpeg-devel] [PATCH] (for discussion): cuvid: allow to crop and resize in decoder
michael at niedermayer.cc
Mon Feb 13 15:08:30 EET 2017
On Mon, Feb 13, 2017 at 12:43:51PM +0100, Hendrik Leppkes wrote:
> On Mon, Feb 13, 2017 at 11:36 AM, Timo Rothenpieler
> <timo at rothenpieler.org> wrote:
> > Am 12.02.2017 um 20:59 schrieb Hendrik Leppkes:
> >> 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.
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel