[Ffmpeg-devel] refactoring ffmpeg.c forsharedlibrarycompatibility.

[Michael Niedermayer]

Hi

On Sun, Dec 17, 2006 at 11:00:52PM +0100, V?ctor Paesa wrote:
> > 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?
> 
> I prepared 500 images (JPG), actual processing is the same in both
> scenarios, but scenario A takes a lot more time to run due to spawning 500
> processes:
> 
> time for i in img???.jpg
> do
>   ffmpeg -f image2 -i ${i} -f image2 out${i}
> done
> 
> real    0m40.141s
> user    0m26.421s
> sys     0m19.009s
> 
> 
> time ffmpeg -f image2 -i img%03d.jpg -f image2 outimg%03d.jpg
> 
> real    0m4.522s
> user    0m3.858s
> sys     0m0.452s

this result is meaningless as it is not what was proposed
what you tested is reading 500 images in a single ffmpeg "session"
what was proposed was executing the whole ffmpeg 500 times from the start
just not with exec() but with a call to a "libffmpeg"

furthermore any program which is designed to run ffmpeg more or less from
main() for each image of a significant number of images is missdesigned
no matter if it does that through exec() or by a direct call to libffmpeg
its completely brainless if we redesign and bloat ffmpeg to improve 
support for missdesigned applications, so unless someone comes up with a
real case where that fork time matters id say proposal rejected

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates