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

u-9iep at aetey.se u-9iep at aetey.se
Sat Mar 4 21:30:27 EET 2017


On Sat, Mar 04, 2017 at 09:16:30AM -0800, Philip Langdale wrote:
> On Wed, 1 Mar 2017 11:58:39 +0100
> Timo Rothenpieler <timo at rothenpieler.org> wrote:
> > 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.

I find it kind of intriguing that doing an operation at a place
where it is most efficient (also where it seems to belong by the codec
or hardware design) is being called "ugly".

> 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.

The cinepak decoder is another precedent of the same kind, even if not
regarding scaling but pixel formats.

"Doing the operation where it costs least" looks like a reasonable
criteria, doesn't it?

Which criteria would make a decoder (or any tool) a wrong place
for something it does much better than anyone else?

Regards,
Rune



More information about the ffmpeg-devel mailing list