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

[wm4]

On Fri, 23 Jan 2015 20:26:35 +0000
Robin Stevens <rdstevens at gmail.com> wrote:

> On Fri, Jan 23, 2015 at 7:57 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> >
> > So what you suggest - iiuc - is that instead of
> > improving the documentation of current FFmpeg you
> > want to invest your time in developing another
> > wrapper for FFmpeg?
> >
> 
> I would personally prefer to improve the current documentation.

Go ahead.

> I have my own need for a particular type of wrapper
> (https://github.com/rdstevens/ffmpeg.net - sadly out of date) and in
> that context it is possible to make an API which is reasonably
> discoverable.

Improving the FFmpeg API, instead of writing the 100th wrapper, would
actually benefit everyone.

> I don't think that level of discoverability is true of the C
> structs-and-functions API that the ffmpeg libraries currently use.

Idiotic prejudices against C APIs are not helpful here. FFmpeg is
mostly not a good C API and could be better, simple as that.

Keep in mind that non-C APIs are mostly useless to other languages.

> My only criticism of the current API is that it is a reasonably high
> barrier to entry. That's not entirely a bad thing, and certainly I
> would expect anyone wishing to contribute to the libraries to get
> themselves over that barrier as an absolute minimum.

Part of the high entry barrier is that the library is so low level.

> For someone wishing to just *use* the library - ie. people on this
> mailing list... well frankly it's quite hard to do.
> 
> (I spent far too long once upon a time trying to figure out a bug in
> my code: it turns out you need to set certain parameters *before*
> calling av_codec_open... who knew? Probably the old hands, but the
> docs didn't contain this handy nugget anywhere I could find it.)

So I wonder what your .net wrapper is supposed to help here. It
basically turns all public fields into trivial properties that get or
set the field. What's the use?

Anyway, yes, that's one of the problem with this "let's dump everything
into a big struct" API. A big class with hundreds of getters and
setters is better?

> Sorry to ramble. I don't mean to criticise ffmpeg: after all it's a
> labour of love, generously given for free to whomever wants it. So I'm
> certainly not demanding you do anything about it.
> 
> What I would like to see, and would be happy to contribute to, is some
> documentation that describes the classes in the system, how they
> relate to each other, how they are intended to be used, and some of
> the thinking behind the design decisions.
> 
> A guide that says: if you want to know what flags a codec supports,
> you need to look *here* in the code.
> 
> That sort of thing...

Well, it's certainly welcome.

Now what could happen in the worst case if you send a patch, it will be
that everyone will comment how wrong your new documentation is, and it
will need a few iterations until it gets accepted. I can imagine that
this can push away contributors. But what can we do; we can't push
incorrect documentation either.

> Cheers,
> Rob