[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 22:24:46 EET 2017

On Sat, Mar 04, 2017 at 08:33:03PM +0100, Timo Rothenpieler wrote:
> >Which criteria would make a decoder (or any tool) a wrong place
> >for something it does much better than anyone else?
> It's about having scaling-functionality in libavcodec, while it belongs into
> libavfilter, but the cuvid API does not offer that possibility.

You take for granted "it belongs 'there'" but my question was not about
"where" but "why".

In these particular cases (cuvid, cinepak) a libxxxx can perform at
best only a small fraction as good as the decoder itself.

So, again, what is our criteria to choose the most suitable place?

libxxxxxxx exist for a good reason, in many cases they are best as
providers of a certain functionality, compared to multiple spread ad-hoc

OTOH when they are _not_ good at providing a functionality, and for
fundamental reasons can not be made as good as an alternative,
then why insist on using them?


More information about the ffmpeg-devel mailing list