[Libav-user] Would anyone find an OS X / Cocoa / Swift wrapper for Libav useful?

[wm4]

On Sun, 25 Jan 2015 00:53:36 +0100
Info || Non-Lethal Applications <info at non-lethal-applications.com>
wrote:

> 
> > On 25 Jan 2015, at 00:46, wm4 <nfxjfg at googlemail.com> wrote:
> > 
> > On Sun, 25 Jan 2015 00:25:34 +0100
> > Info || Non-Lethal Applications <info at 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.