> On Jan 26, 2015, at 3:42 AM, Robin Stevens <[email protected]> wrote: > > Improving and documenting the real API is the best option, but has no > realisitic prospect of success. I someone like me came along and > started suggesting (breaking) changes to the existing API (like > AVFrame, AVAudioFrame, AVVideoFrame), I would (rightly) be shot down > in flames.
Agreed, which is why a wrapper approach has merit: - It introduces no changes (disruptive or otherwise) to the existing API. - It can expose FFmpeg functionality which is well-understood, hide functionality which is not, and expose additional functionality later when its use becomes understood. The entire FFmpeg API could be theoretically black-boxed within a wrapper API if necessary. - It can refine the data structures the API user must deal with. - It can provide higher-level value-added, aggregated functionality for common operations which are use-case driven. The interface which a mechanic deals with in your automobile engine is not the same one a driver wants to deal with on their dashboard while they are driving. One does not preclude the other; but rather one builds on and leverages the other. - It provides an immediate path for improvement of API and documentation for end-users. - It opens the door for immediate progress, without being mired in the politics of doing so. There’s a reason the FFmpeg API is the way it is, and has remained that way for years: the pragmatic consensus (read: when it comes down to action) is that things are sufficient the way they are, and that there’s resistance to significant change. Both desire for improvement and resistance to it (even so far as considering improvements a threat) have been illustrated in this discussion thread. The likelihood of significant improvement and progress is very low when that is the culture. Brad _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
