On Fri, 3 Feb 2017 18:37:52 +0100 u-9...@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-9...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
