>> 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. > > The main issue is actually that the FFmpeg API is pretty low-level, > while many users expect something higher level. (Somewhat typical: a > user wants frame N of video in a specific format. Yeah, implementing > this using the raw FFmpeg API will take some time.)
I’d like to chime in on that one. While I’m using FFmpeg on OS X only (at least right now), I wouldn’t insist of having an OS X only wrapper. A C++ cross-platform one would work just as well for me. Alternatively, it would be really cool to add a high-level API for the most common use cases to the roadmap: Getting frame N of video in a specific format, getting audio samples from N to M in a specific format. As one of the main issues of libavformat seems to be its seeking abilities, it would make a lot of sense from my perspective to encapsulate these issues in a higher level API. If this is not provided, every user will need to handle seeking issues he encounters with a specific format/codec combination with a new if (case x) doY(); statement. If it was encapsulated, seeking issues could be solved over time. I don’t know FFmpeg good enough to know if there’s a policy / design philosophy that doesn’t allow for something like this. Best regards, Flo _______________________________________________ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
