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

[wm4]

On Sun, 25 Jan 2015 22:02:27 -0700
Bradley O'Hearne <brado at bighillsoftware.com> wrote:

> 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.

No, it's just the wrong choice of words.

> > 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. 

Oh no, a group of volunteers who do everything for free and let you use
their stuff for free demand that you put a _little_ effort into
understanding things!

> > (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. 

No, they're not perfect. And again, it's a different dynamic:
undocumented closed source is just as useful as what happens to be
known about it, while you can get more out of undocumented open source.

> > 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. 

I've searched the ffmpeg-devel mailing list, and didn't find your name.
Not even one mail! And my archive goes almost 2 years back.

> > 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. 

Sometimes I get the feeling those with "unsolved" problems just don't
understand enough about multimedia - which, with such a low level API,
is a prerequisite. Yes, the API docs can teach you only about the API,
not general multimedia concepts.

Now I don't want to accuse you or others of not knowing your stuff, nor
do I want to pretend that the problem is just "stupid users who don't
understand". But maybe there's sort of a mismatch of expectations that
leads to frustration. Yes, FFmpeg's API is awfully low level. Yes,
FFmpeg requires you to know a lot about multimedia formats and codecs.
No, FFmpeg doesn't actually abstract multimedia, rather it presents
you with the lowest common denominator. If there's a broken or very
unusual file, FFmpeg might be able to read it, but you get to keep both
pieces. If you have a problem with a certain file, it might actually be
broken, and not because you use underdocumented API wrong. So yes,
instead of shiny plastic, you get raw oil.

That doesn't preclude a high level API from being added, though.

(Just as a detail, don't make the mistake to think the high level API
could be to the low level one. Instead it would be a separate
sub-library alongside of the low level sub-libs, think libavhighlevel
or so.)

Somehow this discussion mixes several issues, like creating a high
level API, mistakes in the existing ffmpeg API, issues with the low
level API, and wrappers. Just because making a wrapper happens to solve
these problems for you on your platform (while not really improving the
general situation).

Also let me just add, cleaning up such a big API with so many users is
hard work. Actually one of the developers who did most for API
improvements lately (and who is on the Libav side) does Libav
development as pure hobby.

> > 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.

I don't know, writing a new wrapper for each platform, and duplicating
all the effort to de-low-level ffmpeg sounds very silly to me.

> > , 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.

Again, mixing several issues...

> > 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? 

Because duplicated effort that distracts from fixing issues in FFmpeg
directly. It just seems so illogical.

> > 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. 

See previous paragraph.

Yes, I see such vendor-specific things as a "threat". I couldn't care
less about them, but they annoy me anyway. (On the other hand, plugging
FFmpeg into existing vendor-specific frameworks is a sane solution.
Though Perian ceased existing, apparently due to Apple being assholes.)

> > 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.

I don't know, actually rarely any real FFmpeg devs show up on
libav-user, so libav-user is not really representative of "the FFmpeg
developers".

> 
> 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
> 
> 
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user