[Ffmpeg-devel] refactoring ffmpeg.c forsharedlibrarycompatibility.

[Jaime V.]

Michael Niedermayer wrote:
 > furthermore any program which is designed to run ffmpeg more or less from
 > main() for each image of a significant number of images is missdesigned


I hope i was not misunderstood. I dont want to recall or redefine 
libffmpeg. This has nothing to do with the FFmpeg library API.

I mean just a refactorization of the ffmpeg.c application.

I think one of the biggest advantages lies in the simplified API for end 
users who are not so well into the library and wish to perform trivial 
tasks, which are already implemented in ffmpgeg.c.
Like i explained in my other post this approach reduces the programming 
and maintaining overhead for trivial tasks as the library behind evolves.

It is clearly not quite aimed at the advanced ffmpeg developer who has 
no problem in unleashing the power of the library itself... but provides 
a useful tool to the common user(Fussvolk).

Of course it would be quite inefficient to call the whole main() every 
time. Thats why i proposed refactorizing ffmpeg.c. Not redesigning it or 
  bloating it. I dont want to add nor remove any new functionality. I 
thought about allowing programmers to reuse the already existing code in 
there.
I dont think it would be a "missdesign" to try to keep it simple on the 
user end. Even if it implies not being perfect.


If there was a way of loading the library  and being able to just 
re-call the main functionality by just reseting the variables then we 
quite have scenario Victor explained. No need to reload libffmpeg but 
ffmpeg.c

I'd also like to point at my real case:
i only need to use the transcoding function on audio or video files 
using my custom protocol...

The librarys API is not easy to understand as a beginner.
Ffmpeg.c is being fixed anyway on every API change... why not open that 
door to users?