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

[Bradley O'Hearne]

On Jan 24, 2015, at 4:03 PM, wm4 <nfxjfg at googlemail.com> wrote:
>> 
> That's pretty ridiculous. Just because it's not documented as well as
> you want it, it's proprietary?

Mine was a statement of pragmatism: if the design, intent, class relationships, and nuances of uses and behavior are unknown, and largely locked in the minds of its creators, then from a pragmatic point of view (that being the ability to readily understand, use, and leverage the full depth and breadth of the API), yes, it is a pragmatically proprietary body of knowledge.

> Anyway, documentation for open source things is bound to be worse than
> with (popular) closed source APIs, simply because if something is not
> documented, you could just read the source code, find out how it's
> supposed to work, and send a patch to improve the documentation.

That circular reasoning is the achilles heel of many open source projects — which turn their otherwise very valuable content into relatively less valuable assets, even to the point of relegating the use of of the API into a liability, because it is so difficult to understand, and products which use the API become built-in time-sinks to debug and support. Reading source code often doesn’t communicate design or intent, so “just read the source code” is a phrase much easier said than done. In the case of FFmpeg, what is missing in terms of documentation isn’t a method explanation or header doc here or there, it is more tantamount to a full book’s worth of information, which is why I’ve stated prior the realistic audience for being able to produce this is likely a pretty select group of folks. 

> (Also, I've never encountered an API that really clearly defined
> everything 100%, whether it was proprietary or open source. If it's
> open source, at least you can find out yourself, and maybe even
> contribute a patch for clarification.)

You might try taking a look at Cocoa API doc, reference guides, and sample code from Apple you despise so much. They are by no means perfect, but it is a world different from what we’ve got to work with in FFmpeg. Again, we’re not talking a simple patch here and there. We are talking a significant writing endeavor. 

> I don't know what you got "lambasted" for, but you probably either
> touched a sensible subject, got into some flamewar and internal
> politics, or you did something honestly stupid.

Your assumptions are wrong. I reported behavior, asked design questions, provided full source code and a running app for OS X. Without actually debugging or looking at the source code I provided, devs just denied what I reported, and turned things into a personal issue rather than answer the question. I’ve been on this mailing list for almost three years now, and while I applaud the questions that get answers, my observation is that this mailing list particularly does not like extended discussion of any kind, but particularly design issues and architectural decisions. 

> Getting asked for source code if you ask for help is quite reasonable.

Which is why I provided complete source code (twice, a year apart) and a fully running app on Github. No luck. It did make for a few useful discussions off-list with a few others who had similar problems they couldn’t get solved on-list — and those were worthwhile. 

> Anyway, in this case I got upset because someone was arguing for
> questionable Apple vendor-lockin

For a Mac app, yeah, I’d love a wrapper native to the platform I’m working on. It changes nothing that exists already in the FFmpeg API. It merely adds an option for those who can benefit. You don’t want to use it, fine — but it hurts nothing, and helps plenty.

> , instead of doing something portable,

That’s your requirement, not others — the entire point of the effort I was proposing was smoothing the skids on a particular platform. I fail to see the downside of this. Again, it changes nothing that exists already. If you don’t want a native API, don’t use it. 

> or - got forbid - actually improving FFmpeg.

I couldn’t do it if I wanted to, and I’d speculate the case is the same for many. You have to know all those things we’ve been talking about which aren’t documented anywhere. The advantage of a wrapper is that you can expose only functionality which is more or less understood and known (the well-beaten paths, if such a thing exists) and can have confidence in its behavior, hide the rest, simplifying much for the end-user. When other behavior becomes known, it can then be exposed at a higher level.

> Seriously, you're talking
> about how bad FFmpeg is,

I said nothing of the sort. I specifically said "FFmpeg may be awesome and feature-rich — I’m not debating that “.

> and you want to solve it by putting a shiny
> Apple-only wrapper around it?

Absolutely. I’m not a prisoner of tech-religious views, I believe in the best tool for the job. If an Apple-wrapper improves usage on Apple platforms, and allows me to ship a more stable, more quickly implemented and more easily supported product using FFmpeg, then that’s justification for me. Same with a Windows-wrapper: if it allows the same on a Windows platform, then that’s justification for me. It affects nothing of the current FFmpeg API…it merely uses the current FFmpeg API as a building block to provides a higher-level, distilled API for users who wish to deal at that level of abstraction.

The better question is this — why would people want to oppose the providing of something which has absolutely zero effect on the FFmpeg API, but enhances the alternatives for using it? 

> Instead of improving FFmpeg? And you post
> that on a FFmpeg mailing list? I can't help but to make fun of this.

I knew I wouldn’t be disappointed — the turf war surfaces: somehow using FFmpeg as a foundation for building something which can widen the potential audience which might use FFmpeg is viewed as a threat. The whole point was to expand the FFmpeg offering and usability options: entirely appropriate for the mailing list. But point taken…providing higher-level functions and greater usability equals a threat to FFmpeg and offense to the mailing list. That’s about as good an answer as I could get to my original question. 

> I don't think it's wrong to get political about evil companies, or to
> make fun of people trapped by evil companies. Also, trolling is fun.

That might be fun for you, but not for people who are trying to get a job done, and could either care less about politics or who don’t have the luxury of dictating to the boss or client what platforms they market their products on. 

That statement right there more or less captures what I’ve observed over the years as the active personality of the Libav-user mailing list (not everyone mind you, but some of the more dominant voices present), and that’s exactly what I’ve faced in the past with questions or attempts to understand things at a deeper level. It isn’t a way to endear newcomers who want to ask honest questions, it isn’t a way to build a tight-knit community of people who want to contribute. Quite frankly, it is one additional (and huge) reason why wrappers would be far superior to a user’s FFmpeg experience is that they might avoid this kind of thing entirely.

In truth, I appreciate your candor. It pretty much aligns with what my gut told me would likely surface prior to posting my original question about this — I just thought it worth the risk to ask if it benefitted some. Honesty, no matter whether the answer was the one hoped for or not, is valuable. 

Cheers, 

Brad