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

[Robin Stevens]

Hi,

I'm not especially interested in OS X support, however I am interested in
C# interoperability.

I've written my own wrapper and imposed a classist approach on top of the
API. It deals with the subset I need, so is incomplete.

I would have benefited tremendously from better documentation; in
particular higher level stuff than just the api calls, something that talks
about what the various components (AVCodec, AVFrame, etc) are, how they are
used, the order in which they should be initialised etc.

My class library makes this somewhat discoverable: object B requires object
A ref in constructor, implying object A must be created first.

I've put my work on GitHub, though it's out of date, for anyone else who's
interested.

I'd be willing to contribute to a documentation project: but I'm far from
an expert and such a project would really benefit from the support of a
core dev; perhaps just on a discussion/interview basis.

Cheers
Rob

On Friday, January 23, 2015, Bradley O'Hearne <brado at bighillsoftware.com>
wrote:

>
> > On Jan 22, 2015, at 9:10 PM, David T. <juiyout at gmail.com <javascript:;>>
> 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
> Libav-user at ffmpeg.org <javascript:;>
> http://ffmpeg.org/mailman/listinfo/libav-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20150123/4f24d94d/attachment.html>