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

[Ralf Terdic]

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.

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.

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

Ralf