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

[saszahir ahamed]

Hi

FFMPEG is not getting converted in my linx server.

Plz update me

Thanks
Shakir

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
> 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
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>