> On Jan 23, 2015, at 8:35 AM, Joshua Kordani <jkord...@lsa2.com> wrote: > > On 1/22/15 9:02 PM, Bradley O'Hearne wrote: >> >> Would anyone be interested in such an API? > > I've been derided on IRC for trying to work through how the various classes > interact, and as far as I'm concerned the sooner I can stop using this user > hostile library the better. I have code that works now, but any changes I > make to the project I'll probably end up doing by hand.
Thank you to everyone who has responded thus far. I’m going to consolidate my replies to everyone who has responded into one email to save # of messages. To the comment above, I guess I can only say I feel your pain, my experience has been the same, though I didn’t realize this was the same state of affairs on IRC. Unfortunate. Part of my reference to documentation in a new API was specifically to get at this very issue you raised, which is not only API doc, but the ability to communicate a higher-level architectural understanding of logical interactions to those who have to use it. After being on the mailing list long enough, I think it is fair to say that unless there’s a clandestine effort underway, this isn’t coming for the existing libraries, and quite frankly, it seems pretty high barrier to entry to even begin this. My hope was that with a distilled API wrapper, it might hide this problem somewhat, and provide something simple and very straightforward that would be intuitive and easy to understand and document. > On Jan 23, 2015, at 8:19 AM, wm4 <nfx...@googlemail.com> wrote: > > On Thu, 22 Jan 2015 19:02:10 -0700 > Bradley O'Hearne <br...@bighillsoftware.com> wrote: > > >> Perhaps I’m the only one on the planet using Libav on Apple platforms, > > Certainly not. We just use clean, portable software, instead of very > crappy proprietary Apple technology. Nothing wrong with a preference. But understand that others don’t necessarily share that opinion, others don’t necessarily have a choice when having to follow management or client direction, and “crappy proprietary Apple technology” is a bit of a dubious criticism given the codebase we are referring to here. Quality criticisms aside, for all practical purposes, despite the fact that FFmpeg is open source, it is pragmatically proprietary, because the key architecture / design / nuances of the product are locked in a very few developers’ heads, not thoroughly documented and known. There is nothing “open” or “accessible” about FFmpeg at all, unless you consider getting lambasted for asking design questions on the mailing list and being relegated to reading through undocumented source code for a month “open”. Sure it is free of licensing charges, but FFmpeg is not free — unless you have got a vanilla use-case encapsulated in the canned examples, you are most likely in for a deep-sea expedition, and you’ll most definitely be investing a large amount of time trying to understand how to use it. But perhaps more important than this, FFmpeg purports to support OS X, and so when someone comes to this project and mailing list asking questions relevant to FFmpeg on OS X, they shouldn’t be subjected to a firestorm of flak simply because of what platform they are using. They shouldn’t be asked to post source code and then after they do so, be told that no one is going to care or look at it if it isn’t submitted for a different platform — that’s ridiculous anyway, as the context of the question *is on* OS X. If for some reason to the FFmpeg dev OS X is considered an outcast which no one wants to support, then fine — put a big neon sign on the front page of the FFmpeg web site which says: “FFmpeg does not work on OS X, it is not being developed on OS X, it is not supported on OS X, we do not recommend using OS X, and please do not post questions to the mailing list about FFmpeg on OS X.” I understand not everyone can run every platform, but if someone approaches the list using a supported platform, they shouldn’t have to wade through a religious debate in order to even get to the point where they can talk about the actual question they have. > On Jan 23, 2015, at 1:58 AM, Info || Non-Lethal Applications > <i...@non-lethal-applications.com> wrote: > >> >> Would anyone be interested in such an API? > > So, yes. I would love to see a high-level wrapper taking the implementation > specific burdens off our shoulders. > Basically, all I'd want is: > - give me a frame at this index (and if there’s some inter frame coding to be > done, just do it for me) > - give me audio samples starting from x and ending at y This is really good feedback. If anyone else cares to respond, I’m interested. Thanks again to everyone who has responded thus far. Brad _______________________________________________ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
