[FFmpeg-devel] [PATCH] Efficiently support several output pixel formats in Cinepak decoder

[Hendrik Leppkes]

On Fri, Feb 3, 2017 at 5:36 PM,  <u-9iep at aetey.se> wrote:
>
>> So, what I don't
>> understand then, is why below you're claiming that get_format() doesn't do
>> this. this is exactly what get_format() does. Why do you believe
>> get_format() isn't capable of helping you accomplish this?
>
> get_format() apparently returns to the caller a suitable format
> from the supplied list. I read the documentation as carefully as
> I can and my interpretation is that it is the application who
> is to define the function and that it is the ffmpeg framework which
> supplies the list of formats supported by the codec. I appreciate
> if somebody corrects me and/or improves the documentation.
>
> But actually this does not matter in the particular situation.
> None of the parties (the decoder, the framework, the application)
> has all the necessary knowledge to be able to make the optimal choice.
> It is the human operator/administrator who may know. The choice depends
> among others e.g. on how fast swscaler is on the particular hardware
> (use it or not?), how much is the contents sensitive to color
> depths and so on.
> How can get_format() help with answering these questions??).
>
> So get_format() is not a solution, mo matter how good or misleading
> its documentation is.

"The application" can implement the get_format callback anyway it
wants, ask the user by carrier pigeon for all we care - but such user
interaction does simply not belong into the avcodec library - hence we
have the get_format callback for that, so that the decision can be
moved outside of the codec library and into the calling user-code.
Clearly whatever application you are working with should implement
these choices, and you should not try to shoe-horn this into
libavcodec, where it clearly does not belong.

We do not want hacks around the established systems just because it
doesn't fit your use-case or workflow, sorry.

- Hendrik