[Ffmpeg-devel] refactoring ffmpeg.c for sharedlibrarycompatibility.

Víctor Paesa wzrlpy
Sun Dec 17 15:18:38 CET 2006

> V?ctor Paesa <wzrlpy at arsystel.com> writes:
>> Hi,
>>> Hi
>>> On Sun, Dec 17, 2006 at 06:48:20PM +0800, Jaime V. wrote:
>>>> Hi,
>>>> I'd like to refactorize ffmpeg.c in order to write a function to
>>>> initialize and teardown variables in it and need some help for it.
>>>> I willing to undertake the deed and maybe it can contribute this way
>>>> to
>>>> the project. :)
>>>> Frustrated by the common beginners difficulty of trying to use ffmpeg
>>>> in
>>>> a project to transcode some videos i came up with the idea of using
>>>> the
>>>> already implemented ffmpeg.c as a library. This makes it easier for
>>>> beginners to use ffmpeg from within existing projects or foreign
>>>> environments such as MSVC. This also comes in handy when using own
>>>> protocols.
>>> exec("ffmpeg(.exe)", ...)
>> There two advantages on this proposal:
>> a) Spawning processes is slower that using this high level library,
> I can't imagine a situation where that overhead would be significant
> at all.

Is not significant if you're transcoding (tipically) large multimedia
files, but imagine a file open dialog that has got a file preview/file codec
info window. In this case as soon as you click on a filename it needs to
launch ffmpeg to get that thumbnail/info, and the time is noticeable.

>> b) its API could be less prone to changes than the current low level
>> API.
> The same can be said of the command line interface.

IIRC, not all the changes in libav* API have produced a change in the
ffmpeg program options.


More information about the ffmpeg-devel mailing list