[Ffmpeg-devel] refactoring ffmpeg.c for sharedlibrarycompatibility.
Sun Dec 17 15:18:38 CET 2006
> V?ctor Paesa <wzrlpy at arsystel.com> writes:
>>> On Sun, Dec 17, 2006 at 06:48:20PM +0800, Jaime V. wrote:
>>>> 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
>>>> the project. :)
>>>> Frustrated by the common beginners difficulty of trying to use ffmpeg
>>>> a project to transcode some videos i came up with the idea of using
>>>> 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
>>> 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
> 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