[FFmpeg-devel] [RFC] ffmpeg.c refactoring

[Ralf Terdic]

On Wednesday 11 June 2008 09:00:34 Michael Niedermayer wrote:
> ive said this in the past to other people, what you want is:
> system/exec("ffmpeg");
>
> IIRC noone yet had a argument against that, so until one does, the way
> ffmpeg.c is implemented is correct.

Invoking ffmpeg in a shell is no viable option in a server environment. 
Forking a process for each invocation is too expensive, so if possible, you 
want to stay within the same thread, or at least within the same process. 
Besides, if you want feedback from the ffmpeg encoding, what do you do, parse 
the text output of exec("ffmpeg")? If the ffmpeg output changes slightly, 
your software is screwed up.

> Also as has been said before here on the list, if libav* are to hard to use
> directly, patches which simplify it by adding new functions combining
> common sequences of operations are welcome.

libav* may be hard to use, but the real problem is, they are too low-level. An 
encoding API on top of libav* is needed. The functionality is all there in 
ffmpeg.c, but the way it's written, it can't be reused.

> > This is no question of idealistic design improvement, it's mainly about
> > helping those who want to do a bit more than start ffmpeg in a shell.
>
> "bit more" is what?

Access it as an API. The world is full of useless (because outdated) ffmpeg or 
libav* wrappers. Why not eliminate the need of such wrappers by improving the 
ffmpeg design?

> > And to
> > all performance fanatics, keep in mind it's reusability vs. a tiny
> > performance loss through an additional layer of indirection. As far as
> > I'm concerned, reusability wins.
>
> Its not about performance at all its about people not knowing how to code.
> And trying to solve that by rewriting what they lack understanding of
> instead of thinking how the existing could be used.

People aren't *either* elite ffmpeg developers *or* idiots. Some of those who 
are in between might be happy to have an API at their hands, which they can 
use without understanding all the libav* internals.

Ralf