On Fri, Jan 23, 2015 at 7:57 PM, Carl Eugen Hoyos <[email protected]> wrote: > > So what you suggest - iiuc - is that instead of > improving the documentation of current FFmpeg you > want to invest your time in developing another > wrapper for FFmpeg? >
I would personally prefer to improve the current documentation. I have my own need for a particular type of wrapper (https://github.com/rdstevens/ffmpeg.net - sadly out of date) and in that context it is possible to make an API which is reasonably discoverable. I don't think that level of discoverability is true of the C structs-and-functions API that the ffmpeg libraries currently use. My only criticism of the current API is that it is a reasonably high barrier to entry. That's not entirely a bad thing, and certainly I would expect anyone wishing to contribute to the libraries to get themselves over that barrier as an absolute minimum. For someone wishing to just *use* the library - ie. people on this mailing list... well frankly it's quite hard to do. (I spent far too long once upon a time trying to figure out a bug in my code: it turns out you need to set certain parameters *before* calling av_codec_open... who knew? Probably the old hands, but the docs didn't contain this handy nugget anywhere I could find it.) Sorry to ramble. I don't mean to criticise ffmpeg: after all it's a labour of love, generously given for free to whomever wants it. So I'm certainly not demanding you do anything about it. What I would like to see, and would be happy to contribute to, is some documentation that describes the classes in the system, how they relate to each other, how they are intended to be used, and some of the thinking behind the design decisions. A guide that says: if you want to know what flags a codec supports, you need to look *here* in the code. That sort of thing... Cheers, Rob _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
