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

[wm4]

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.)

> 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....

> 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.

There are two parts to this. One part is that seeking in libavformat is
terrible. Another is that the layer which handles file formats can't do
any form of frame-exact seeking, because it would require decoding some
video and audio (i.e. too low level).

Yet another is that with raw files, it will often seek by assuming some
random constant bitrate. Here it pretty much depends whether you
actually want this (in order to avoid that your video player or so has
to read _all_ data until the seek target), or if you need it more
exact. For the latter case, I think simple on-the-fly indexing could be
added, although it would also require dealing with the terrible seeking
code.

> 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user