> On Jan 22, 2015, at 9:10 PM, David T. <[email protected]> wrote: > >>> My purpose here is to poll the list members to ask if anyone would find any >>> value at all if someone created an OS X / Cocoa / Swift (and possibly iOS) >>> wrapper for Libav? > > So far we have delivered several projects on iOS. But we have not found any > deficiency (which you didn't describe) on using FFmpeg on OS X. Perhaps you > could tell us exactly what you expect a new API should do compared to current > conventions, what would a new API solve?
Hey David — thanks so much for your reply — I was wondering if this even piqued anyone’s interest, so I’m really happy to be able to dialog with someone on this. My purpose here isn’t to recite a laundry list of problems encountered, or debate design issues, or poke holes in FFmpeg in general. Suffice to say that I think the degree to which issues are encountered depends heavily on your use-case. Those that have use-cases which are a bit off the beaten path (of FFmpeg samples, for example) probably have run into various issues…I’ve had people periodically contact me off-list for issues similar to the ones I’ve encountered, so I know I’m not the only one running into them. But again, my purpose is not to debate FFmpeg use cases or problems. What I believe would be more universally agreeable (and safer turf for discussion, which is my desire) is the fact that FFmpeg is very scantily documented and very confusing to get started with. Options are extremely limited if you run into a problem and generally lead to hours upon hours of reading source code and debugging, with little other recourse. I don’t think it would be anything controversial to say that FFmpeg doesn’t offer what I’d term a “consumer’s API” — that is, an API that is built for intuitiveness and easy use by third parties, which hides its nasty internal implementation details and implications. I would characterize FFmpeg the same way I’d characterize many technical books that are out there — created for those with the foreknowledge of the authors, rather than those coming in cold. More to the specific case of OS X and iOS — those developing on those platforms will likely be using one or more of the following frameworks: QTKit, AVFoundation, AudioToolbox, VideoToolbox. It would be very nice to be able to deal in terms of: a) Data structures native to those frameworks, and b) Swift. I believe with such an API, the learning curve would be much smoother, some of the nastiness of the FFmpeg API’s could be hidden, and a lot of common mistakes could be eliminated. I also think that some very common use cases could be encapsulated into simple, well-documented API calls. While it might not express the entire richness or capability of FFmpeg, it might handle some of the common stuff well. I hope that communicates with some clarity the general idea. Let me know if you are interested. On a side note — I’m curious about how your company is using FFmpeg in iOS, and if your use-case with video is static (operating on a known, existing video asset) or real-time (video being captured/created on the fly). Feel free to contact me off-list if you care to share. Cheers, Brad _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
