> On Jan 23, 2015, at 12:57 PM, Carl Eugen Hoyos <[email protected]> wrote: > > But this is what this mailing list is here for. > Or to say it differently: It is the only thing > we - the FFmpeg developers - expect from you.
Carl — my observation over the years is that this list isn’t particularly tolerant of anyone who tries to dive deep, particularly in discussing architecture, design decisions, or potential weaknesses or shortcomings of the API. There appears to be a pretty clear aversion to discussing these things to any length or depth, and attempts to do so seem to be met by responses turning things personal. > 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? On documentation: I cannot improve the documentation of FFmpeg. I’d venture to say that there’s probably few who can — I would guess that the only people who realistically could write documentation to any depth and accuracy, while capturing the hidden nuances of behavior and configuration options are probably a select subset of FFmpeg devs who have been around long enough to have worked on a majority of the codebase, and are carrying a significant amount of that knowledge in their heads. Beyond that, the barrier to being equipped to contribute solid documentation is pretty steep. No doubt, more documentation of the current FFmpeg API would be gladly welcomed by all. But more documentation isn’t going to change the complexity of the API. FFmpeg may be awesome and feature-rich — I’m not debating that — but it has chosen to expose its API in a way that inflicts considerable complexity on its users. For the typical consumer of the API, it isn’t intuitive, easy to understand, or easy to debug and support. Any newcomer to the code has a comparatively steep learning curve before they can begin maintaining or extending code using FFmpeg. FFmpeg doesn’t encapsulate things which it could otherwise provide, and as such I’d wager that there is significant duplication of effort amongst the users of FFmpeg to accomplish the exact same tasks. Put simply — I believe a completely different API offering would be a extremely beneficial, whether the current FFmpeg API is further documented or not. With a new API geared toward users, I believe documentation could be produced which made things relatively easy to understand. I’m not suggesting a wrapper as an alternative to documentation. I’m suggesting a wrapper as a pathway to understandable documentation and overall better usability. It isn’t a question of which is better, a current API or another one. The issue is one of abstraction, encapsulation, and the intended consumer. I’m sure the current FFmpeg API would be the choice of many if not most. But I’d wager that there would be some that would greatly benefit from a simpler, more abstracted API. Neither has to preclude the other — they can both coexist and be offerings that have their own constituency. There are many, many examples of this very thing all around us in the tech world…perhaps the simplest of which is the relationship between machine language and a programming language like C. It isn’t a question of “better” per se — one is the foundation of the other — it is a question of usability and the needs of the audience who has to use it. >> frameworks: QTKit, AVFoundation, AudioToolbox, >> VideoToolbox. > > I am sorry if I misunderstand this: > You do realize that three of these > frameworks are supported by FFmpeg? > And that patches improving this support are > (of course) welcome! I’m not exactly sure what you mean by “support”, so no, I suppose I don’t realize it. What I do know is that I’ve never been able to get an answer for anything which specifically involved OS X or use of FFmpeg with these frameworks. In fact, I’ve been told outright that the reason I’m likely not getting answers is because I’m running on OS X, and if I want answers, I need to change my code to something the devs use. I hope that clarifies things adequately. Brad _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
