I agree that it is quite a hassle to keep all the dependencies of OME updated. However, I am working very closely with gmerlin, and there is simple very interesting stuff going on.
As I consider OME quite “Alpha” at the current state, it somehow has to track the edge closely, because this also allows me to suggest improvements to gmerlin, which in return will improve OME.
This is all very much a timing issue, sooner or later OME will stabilize, and then it will get easier to install newer versions. But right now development has so much momentum and flux that things break. In fact while this is inconvenient right now, it will move OME forward faster, and I think in the long term that this is the right decision.
I really love Open Movie Editor and am using it for some video projects. (I have a simple video slideshow on jplui.com).
That said, I really dislike how one always absolutely needs to use the latest, bleeding-edge gavl and quicktime libraries (been using 200805 build of OME and upgrading to 200810, and already a new library is need gmerlin-avdec is required). You cannot really fault the packagers and maintainers because although having latest libraries is nice, having stable and tested libraries is more important to them.
In that light, it would seem that no distribution will ever have an OME version that is even close to the version you will be releasing. (Ibex still has a 2k8 January build!)
I understand how OME could benefit from the latest codecs, but having to go through hoops to run a non-obsolete version of OME is quite a pain, especially for lesser-experienced users.
All that said, OME is the best video solution for linux. Period. My hats off to you! m(_ _)m]]>
thanks for the aweosome job in this project!]]>
Interlacing: Not sure if it’s a good idea if the displayed video is deinterlaced automatically, since it can lead to bad surprises, when the rendered movie is watched. Some codecs don’t support interlacing and will therefore look ugly. BTW, the most speed-optimized quick & dirty deinterlacer is GAVL_DEINTERLACE_BLEND.
Rendering codecs: In gmerlin-transcoder I can save/load profiles, which contain all encoder settings. A similar mechanism, along with some predefined profiles would probably do the trick. Hiding some “advanced” options is IMO not good, since they can improve quality significantly (e.g. custom quantization matrices for MPEG-2).
If you implement support for gmerlin-encoders, you’ll get Ogg/Theora, MPEG-1/2 (via mjpegtools) and ffmpeg.
Complete and up to date packages for gavl, gmerlin and gmerlin_avdec:
SuSe packages are at http://packman.links2linux.de/, the packager sometimes sends patches upstream. Debian packages are e.g. here:
http://debian-multimedia.org/dists/unstable/main/binary-i386/package/gmerlin.php. A Fedora guy complained about things in gavl. I told him basically, that the problem is not in gavl but in Fedoras packaging policies.
I think.. first, Internacing, and second High Definition, Rendering Codecs and Key Frames.