Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=459979
--- Comment #31 from Dan Dennedy dan@dennedy.org 2008-12-10 15:27:25 EDT ---
we need to be sure nothing will hardcode the libraries pathes
...
MLT already attempts to dlopen all so in lib/mlt.
That's really bad. We are in $prefix/lib64/mlt on x86_64 ppc64 sparc64
Sorry for my miscommunication. I did not mean literally "lib/mlt." It is actually *defaulted* to $(libdir)/mlt, where there is a ./configure option --libdir. The application can override this via API, and there is an environment variable as well.
Once that said, I'm not sure I can support one more split between mlt non-ffmpeg enabled and mlt-freeworld ffmpeg enabled.
I don't want this project to be a nuisance with too many configurations. First of all, I think I should split up my ffmpeg module because there are some elements for deinterlace and color space conversion that are unencumbered and then encumbered format/codec-oriented elements. That would let you or someone else just make a separate package with the encumbered elements similar to gstreamer-ffmpeg. MLT has libdv and libvorbis modules that still make it usable without the encumbered ffmpeg elements. I do not yet think it is necessary to have good, bad, and ugly packages separate from the framework lib, do you? I think the framework and majority of plugin modules can be in one package. In that case, I need to make it easier/possible to separately build the encumbered ffmpeg module. Feedback welcome.
Is there any package using mlt that can be in Fedora once mlt is in?
kdenlive, which was rewritten for KDE4 and proving to be fairly usable and stable.