> On Jan 25, 2015, at 11:04 PM, wm4 <[email protected]> wrote: >
This exchange appears to be turning personal (actually it did a message ago) and isn’t really headed in the direction of being productive, but I’ll address whatever makes sense to get the point across, and then I’ll bow out. > 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! That was not the gripe…you know it, I know it, everyone that uses FFmpeg knows it. The gripe is requiring an FFmpeg user to take a multi-month, Nicolas Cage-ian cross-country National Treasure quest which requires one to steal the Declaration of Independence, find the hidden lever on the desk in the Oval Office, kidnap the President, find the Book of Secrets in the Library of Congress, and then uncover the secret FFmpeg functionality engraved on a document hidden in a treasure room buried within Mount Rushmore in order to understand it. Forcing a user to read source code for a week or a month isn’t a virtue — it is a major weakness. Even then, many times the information uncovered is merely best guess, and doesn’t answer a host of contingencies. Users of FFmpeg shouldn’t have to guess at this stuff. > 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. The comparison was not undocumented closed source vs. undocumented open source. It was a comparison between *documented* closed source with reference guides and extensive sample code vs. relatively undocumented open source where the gaps aren’t able to be easily filled with other resources (mailing list discussions, samples, etc.). More specifically, for the domain in question, I’d take Apple’s (or for that matter, Microsoft’s) API documentation and resources 1000 times out of a 1000 over FFmpeg’s. Whatever the flaws in what Apple/Microsoft provide, they at least have an appreciation of the fact that third parties are the consumers of their APIs, and make attempts to provide understandings of them. > Sometimes I get the feeling those with "unsolved" problems just don't > understand enough about multimedia I’m sure that’s a theory that makes some feel better….it just isn’t true in my observation over the years. The issues I brought to this list weren't a matter of “feelings”. They were reports of specific behavior observed paired with source code which could reproduce it for anyone who cared to try, and instead of being answered, resulted in my being repeatedly called a “troll” for reporting them by an FFmpeg dev….of course no fault was ever found with the source (I don’t think it was ever even looked at) nor was any answer ever given. If devs can’t provide an answer, fine. But trying to hide that by attacking the person…that’s weak, and counterproductive. > 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. Suit yourself. I’d rather use a toilet than have someone direct me to the plumbing aisle at the hardware store whenever I need to use the restroom. > 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.) You’ve got every right to your opinion, and I respect that. But this is your personal bugaboo, and it isn’t where the entirety of the FFmpeg constituency lives. FFmpeg claims support on vendor-specific platforms, it embraces vendor-specific video and audio formats, and network protocols. Your gripe isn’t a technical issue — it is a political one. Your gripe with an FFmpeg wrapper is politically oriented — it is not user-oriented. Unless you specifically have a reason for desiring to work at a low level, and there certainly are legitimate reasons for wanting to do this, I’d guess that the majority of users would prefer to work at a higher level abstraction. Even if it weren’t “most”, it would certainly be substantial. I am fine to agree to disagree. Again, I respect your right to your opinion. I’m just amazed at the fact that turf trumps value here (“threat”). My sole purpose was to: - Increase the value of FFmpeg. - Provide an easily understandable abstraction to an otherwise very difficult to understand FFmpeg API. - Provide something which can be thoroughly documented. - Provide something less intimidating which more users would be willing to use and support in their products. - Contribute something of value where I am otherwise on weak footing to do so. In the providing of these things, there is *no* alteration or neglect of the FFmpeg API required — it is left entirely alone, and FFmpeg is the foundational building block underneath. I’m just floored that some would oppose the community having such a thing. But again, I DO appreciate your honesty. I can leave this conversation duly informed, and I’ve already reached a conclusion to my original question. Anyway, I think this discussion has run its course, so we probably don’t need to belabor the issue. I likely won’t be pursuing any public wrapper for FFmpeg. I have clients which need FFmpeg functionality (which I’ve already provided) but with expansive functionality and a higher-level API, and they need something they can understand, maintain, extend, and support. If I provide a wrapper (beyond the one I’ve already provided for them) I’ll keep it private so as not to offend the mailing list, and over time, I’ll consider a higher-level API something which needs to take place without FFmpeg as a building block, but either some other building block or rolled from scratch. Thanks again all…. Brad
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
