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

[Philip Langdale]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 1 Mar 2017 11:58:39 +0100
Timo Rothenpieler <timo at rothenpieler.org> wrote:

> >> 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.  
> 
> Would like to bring this back up.
> I'd like to merge this, as specially the scaling is freely done by the
> video asic, offering a possibility to scale without requiring non-free
> libnpp. And cropping so far is not possible at all.
> 
> Yes, scaling and cropping is not something a decoder usually does, but
> it exposes a hardware feature that has no other way of accessing it,
> which offers valuable functionality to users.
> 

I'm ok with it. I agree it's ugly, but if this is the only way, so be
it.

For what it's worth. there's precedence in crystalhd. I exposed the
hardware's ability to do downscaling, which was valuable because it
allowed you to downscale before memcpy, which made the difference
between playable and unplayable for some low end machines.


- --phil
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAli69m4ACgkQ+NaxlGp1aC5xwgCgkfrCp7/dMt4zl+APxZRCQ17c
tQQAoIZW+8Z57NbOsOTxFTqTpp4PVLWP
=43NP
-----END PGP SIGNATURE-----