[Libav-user] Would anyone find an OS X / Cocoa / Swift wrapper for Libav useful?

[Bradley O'Hearne]

> On Jan 26, 2015, at 11:26 PM, wm4 <nfxjfg at googlemail.com> wrote:
> 
> No, no. As I said before, there are barely any developers on this list.

I don’t believe that — as I’ve spoken with them in the past, but if this is true, there’s a major problem right there: complete disconnect with your user-base. If you don’t know the needs of API consumers and where the API is showing to be cumbersome or in need of revision or improvement, then you are missing some very valuable input. 

> I guess people don't like giving tech support (especially for free).

All the more reason FFmpeg needs to be well documented and intuitive.

> As for contributing... I haven't seen a single FFmpeg patch from you,

> Well, you're not contributing in the first place. Your suggested wrapper

If you spent a little less time trying to personally impugn people and listen to what they are actually saying, you might acknowledge the simple logic that thorough understanding of design/architecture/API function and ability to have productive discourse on such topics are pre-requisites to contributing. That’s the point — people likely aren’t contributing because they can’t — there’s no ability to easily understand the API, and more importantly its design intent, without dedicating your life to reading cryptic and undocumented source code, and even then it still isn’t clear. That’s probably the source of compounded frustration— people want to understand, they’d like to be able to contribute. But they pragmatically can’t…or to their credit and wisdom, they won’t contribute, because they hold a high standard for the code they produce, and they aren’t about to make a bad problem worse for lack of knowledge.

There is no nobility in haphazardly throwing a patch across the wire just to say you can (of course, maybe that explains some things). I have plenty of things I would like to change, (and I’d wager others do too) but I’m not about to do so until I have a thorough understanding of the implications of such not just to me, but throughout FFmpeg. That knowledge is not easily accessible or obtainable. Furthermore, each attempt I’ve made to discuss something like this results in a Holy Grail -esque taunting from the French soldiers on the wall. I’m not interested in that — I’m all about moving forward and shipping product. 

This thread was an attempt to go around those barriers of contributing to the FFmpeg codebase, and immediately contribute what I was able to: something I know for a fact is a need; something which wouldn’t step on anyone’s existing turf; something which would be 100% value-add and not either take away or change the existing API. It is clear such a thing won’t be well-received, so no-go. 

I’m an eternal optimist, and so I view every problem as creating an opportunity; every closed door leads to another open one. So I’ll roll my own. The strength of generalism is breadth: providing something to the widest audience — but that “thing” is rarely the best thing. The strength of specialization is depth: the best of breed for the task. Neither I nor my clients need anywhere near the full breadth of what FFmpeg provides — and I’d guess that is the case with most folks. I believe that the common needs, the 80-20, are probably relatively few compared with the entirety of what you *can* do with an API like FFmpeg. Just like what you *can* do with all the parts at a Home Depot is virtually infinite, what most people generally need boils down to some pretty common things, relatively few in number. 

There’s no need to duplicate the entirety of what FFmpeg provides…just a few well-worn paths. If you build it….they will come. 

Brad