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

wm4 nfxjfg at googlemail.com
Fri Feb 3 21:21:37 EET 2017


On Fri, 3 Feb 2017 18:37:52 +0100
u-9iep at aetey.se wrote:

> On Fri, Feb 03, 2017 at 05:51:19PM +0100, Hendrik Leppkes wrote:
> > On Fri, Feb 3, 2017 at 5:36 PM,  <u-9iep at aetey.se> wrote:  
> > > 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.  
> 
> You suggest I should shoe-horn this into every application.
> Very helpful, thank you :)
> 
> As for "clearly", it is your personal feeling, not an argument.
> Seriously.
> 
> > We do not want hacks around the established systems just because it
> > doesn't fit your use-case or workflow, sorry.  
> 
> You should listen more on those who actually live in their workflows.
> It is there your code is being useful. Or not.
> 
> I happen to be in a suitable position (using the stuff and arranging it
> for others) to estimate what is useful.
> 
> Based on this I am trying to help ffmpeg.
> You are certainly free to refuse the help, for any reason :)

He didn't refuse help, he just explained how it is. We helped you
plenty by trying to explain you the mechanisms of this library.

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.

Back to being "constructive" - the only way your code could get
accepted is by implementing the get_format callback. There's a
precedent, 8bps.c, which would also show you how it's done. But maybe
it should be at most only 1 other output format that handles the most
efficient case, or so. There's really no reason to add them all.


More information about the ffmpeg-devel mailing list