On Sun, 25 Jan 2015 00:53:36 +0100 Info || Non-Lethal Applications <i...@non-lethal-applications.com> wrote:
> > > On 25 Jan 2015, at 00:46, wm4 <nfx...@googlemail.com> wrote: > > > > On Sun, 25 Jan 2015 00:25:34 +0100 > > Info || Non-Lethal Applications <i...@non-lethal-applications.com> > > wrote: > > > >>>> 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. > > > > Sure, that's kind of hard to do with Cocoa/Swift. > > > > (Also, C++ APIs are useful for C++ code only.) > > Not exactly. They don’t work in Swift (there are also ways to use C++ source > there) but they can be used in Objective-C (then called Objective-C++) > without any action on the developer’s side. > You simply need to change the file extension from m to mm. Not a big deal. > > >> 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. > > > > I don't think the FFmpeg project would be opposed to adding such a > > high-level (C) API. It was often talked about, but of course nobody has > > time etc…. > > Well, then the only solution is creating a high level wrapper? > > Well yes, it has to be a new API, because there's no API in FFmpeg yet which can access both demuxer and decoder. Unless by wrapper you mean an _external_ wrapper, which is something I've argued against in this thread. _______________________________________________ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user