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

Stefano Sabatini stefano.sabatini-lala
Wed Jun 11 09:16:59 CEST 2008

On date Wednesday 2008-06-11 02:09:43 +0200, Ralf Terdic encoded:
> 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.

I thought a lot about this, I think the way to go is to implement an
FFmpegContext which would be filled by the CLI option parsing
mechanism, a GUI or you could easily use as well a programmatic
interface, then pass it to the routine that makes the transcoding,
also you should pass to this routine the informations regarding input
streams, output streams and the mapping between them (information
which I find quite obfuscated in the code as it is).

And even actually as it is the code may be still improved, many things
which are defined in ffmpeg.c should be defined using the AVOption

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

Yes it will be slightly slower, more levels of indirection, but it will
be a great step towards code reusability and flexibility.

FFmpeg = Freak & Foolish Meaningful Portable ExchanGer

More information about the ffmpeg-devel mailing list