[FFmpeg-devel] [RFC] ffmpeg.c refactoring
Wed Jun 11 02:09:43 CEST 2008
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
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.
More information about the ffmpeg-devel