[Ffmpeg-devel] refactoring ffmpeg.c forsharedlibrarycompatibility.
Mon Dec 18 09:07:36 CET 2006
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
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
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?
More information about the ffmpeg-devel