[FFmpeg-devel] [RFC] ffmpeg.c refactoring
Wed Jun 11 13:58:10 CEST 2008
FFMPEG is not getting converted in my linx server.
Plz update me
On Wed, Jun 11, 2008 at 5:39 AM, Ralf Terdic <contact at jswiff.com> wrote:
> Hi there,
> I'm aware that this has been addressed a few times before, but I haven't
> 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
> 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
> no-go with multithreading) , and with exit() calls which may kill my Java
> So I either have to reimplement av_encode() based on the libav* libraries,
> 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
> ffmpeg, and many suffer from the same problem.
> I think it would be a great idea to aim at separating the options parsing
> 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
> 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.
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
More information about the ffmpeg-devel