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

[Michael Niedermayer]

On Wed, Jun 11, 2008 at 02:09:43AM +0200, Ralf Terdic wrote:
> Hi there,
> 
> I'm aware that this has been addressed a few times before, but I haven't seen 
> any clear outcome, that's why I'm reopening this discussion.
> 
> In short, the main problems I see in ffmpeg.c are:
> - more than 100 global variables
> - not enough separation of concerns (options parsing, transcoding)
> - bad reusability
> - file is too bulky to be manageable (almost 4000 lines is too much -- my 
> subjective opinion)
> 
> The current code structure may work very well when compiling it to an 
> executable, but it makes it impossible to reuse the code. One example: I need 
> to extract the transcoding logic to a thread-safe shared library, which I 
> invoke from Java, inside a multithreaded application server, to transcode 
> movies on-the-fly. No way to do that with all those global vars (obviously a 
> no-go with multithreading) , and with exit() calls which may kill my Java VM. 
> So I either have to reimplement av_encode() based on the libav* libraries, or 
> do a massive clean-up of ffmpeg.c. Both options suffer from the fact that 
> ffmpeg changes a lot, so either way, my code is very likely to stop working 
> if I use another ffmpeg revision.

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. That doesnt mean it shouldnt be cleaned
up but what i consider cleanup seems tp differ from what the dll/shared lib/
jave people do. Theres no reason to remove globals in an application like
ffmpeg.c for example.


> 
> My case is just one example, but there are tons of other projects which wrap 
> ffmpeg, and many suffer from the same problem.
> 

> I think it would be a great idea to aim at separating the options parsing from 
> the transcoding code, eventually resulting in a well-defined, easy-to-use, 
> thread-safe transcoding API and a smaller, better manageable ffmpeg.c.

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. Also other kinds of cleanups are welcome
but emphasis is on cleanup and that requires full understanding of the
current API. Messup and reimplementation due to complete lack of understanding
the current API is not welcome!


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


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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thouse who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080611/83782e44/attachment.pgp>