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

[u-9iep at aetey.se]

On Fri, Feb 03, 2017 at 08:21:37PM +0100, wm4 wrote:
> With your special use-case (special as in does not fit into the API
> conventions of libavcodec), you might be better off with creating your
> own standalone cinepak decoder. That's not a bad thing; there's plenty
> of multimedia software that does not use libavcodec. Part of the reason
> is that one library can't make everyone happy and can't fit all
> use-cases.

To make it a bit more clear, my use case is

- various devices and videobuffers
- different applications which are not feasible to patch/teach/replace

Replacing ffmpeg with something else or modifying the applications 
unfortunately does not fit there, that's also why get_format() does not help.

Fortunately there is a solution for controlling the libraries out-of-band
even if it is not exactly elegant (I am more than well aware of implications
when using environment variables). If anything better would exist I'd use
it. This matter belongs otherwise to system- and deployment administraton,
offtopic to discuss here but you can safely take my word.

This does not have to be "supported" by ffmpeg but it is useful, not
harmful to have the corresponding code at hand, at least as a reference
(disabled as it is).

An improvement would be namespacing the environment variables to be
used together with ffmpeg libraries, but as long as such use is strongly
discouraged there is no possibility to allocate a namespace.

Otherwise, you see, ffmpeg fits very well for the needs in my environment,
it _does_ make people happy.

> Back to being "constructive" - the only way your code could get
> accepted is by implementing the get_format callback. There's a

Sure.

Indeed, activating get_format() can become useful for someone,
I should not have omitted it.

This is a tiny change.

I am now posting an amended and additionally commented patch.

Regards,
Rune