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

[Måns Rullgård]

V?ctor Paesa <wzrlpy at arsystel.com> writes:

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

Really?  And how much this time is due to fork overhead, and how much
is from actual processing?

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

That's more or less equivalent to what I said.

-- 
M?ns Rullg?rd
mru at inprovide.com