Strict Standards: Redefining already defined constructor for class wpdb in /home/www/ on line 46

Deprecated: Assigning the return value of new by reference is deprecated in /home/www/ on line 35

Strict Standards: Redefining already defined constructor for class WP_Object_Cache in /home/www/ on line 410
Open Movie Editor News » Blog Archive » The Open Movie Editor Roadmap

The Open Movie Editor Roadmap

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/www/ on line 83


what needs to be done for the development of the Open Movie Editor before it can be called a 1.0?

Interlacing might be an annoyance, but it is a reality in current video technology, so a complete video editor needs to handle it. However, it is more complex than simple having a good deinterlacing filter available. First of all, it needs to be handled at all possible levels, and if possible automagically, yet predictable. Consumer camcorders almost always produce interlaced footage, even though avarage consumers might not understand the term, how it affects them, and how they need to handle it. Therefore ideally, the video editing software should support them by doing the “right” thing depending on the available knowledge.

Currently there is not much interlacing handling in OME, almost nothing I have to admit.

What needs to be done? Some filters, like color based filters do not need to be aware of interlacing, they will work always. Filters that introduce distortion, like blur or scale, need to be aware of interlacing and they need to take it into account. Therefore a mechanism is needed to detect interlacing, either bei meta-data-tags of video files, or by image analysis, preferable both.

Automatic deinterlacing needs to be introduced at appropriate processing steps. Computer screens are not interlacing, so everything that is displayed on screen needs to be deinterlaced automagically, although an override for expert users should be available. For rendering automagic deinterlacing should be enabled for formats that are not likely to support interlaced playback, like for example web-based video formats, youtube, etc. However, for delivery formats like DVDs, and other media that supports interlacing, no automagic deinterlacing should be done. And of course subtle overriding possibilities for expert users and for debugging needs to be present. Do the right thing per default! Make it difficult to screw up!

High Definition
Handling High Definition Media is another point that is mostly about performance, current computers are barely able to handle it, and software needs to be especially careful to be able to utilize every last bit of available processing power, and not waste any.

There are two ways to handle High Definition Media, and depending on the situation, one or the other, or a combination of both of them is better to be used. The first one is multi-core processing, utilizing threads or a similar technology, and the other way is using the image processing and parallel computing power available in OpenGL 3D graphics hardware. Using 3D graphics hardware has advantages for certain operations, for example when it is necessary to display the video data on screen, for editing. However, one severe disadvantage is that such tricks will only work on carefully selected high end or semi high end graphics hardware, so some kind of fallback mechanism is always necessary to not exclude users in less powerful platforms.

Multi-Core processing is useful of course for owners of machines with many-core processors, especially for rendering and as fallback, when 3d-hardware is not available.

Currently OME only uses a simple subset of OpenGL, which is not optimized for performance but for compatibility. OME does no multi-core processing.

The plan is to support 3D-OpenGL based simple YUV-RGB conversion during playback first, because this would enable simple HD editing, which is IMHO the most important and desired feature.

The second step would be to port the filter infrastructure to OpenGL and Multi-Core based methods, which would enable to also work with filters while keeping realtime playback. This is more complicated and likely to happen later, possible after 1.0.

Key Frames/Automation
Simple keyframe and automation features are likely very easy to implement, so they will happen sooner or later, depending on how well the other more difficult stuff progresses.

This feature is only necessary for more advanced compositing style work, but might come in handy every once in a while even for simple projects.

Currently OME only does automation for audio volumes.

Easy Installation
This is a problem that is bothering a lot of users, and might even prevent some from participating as OME users, however, getting this right is a tedious problem, especially considering that OME is still lacking in other departments that need more priority. Ideally this problem should be handled by distributions like Debian and Ubuntu, but still someone needs to do the work, and I have no whip to force anyone.

The most important tasks are:

  • Provide complete and up to date packages for libquicktime (currently debian+ubuntu miss the ffmpeg_lqt plugin)
  • Provide complete and up to date packages for gavl, gmerlin and gmerlin_avdec
  • Provide up to date packages of ffmpeg, as an important codec was added only recently
  • Provide decent jack-audio integration, or alternatively PortAudio, which works ok currently (Linux Pro/Non-Pro Audio is a well known mess)

If all those preconditions are fulfilled, providing a package of OME, or compiling it from source should be sufficiently easy.

If it is not possible to include a certain plugin in the base-package of libquicktime, it should at least be available optionally as part of an extended or not-free repository.

Help for those tasks is available from the Open Movie Editor packagers Mailing-List

Rendering Codecs
A lot of questions for OME concern the lack decent and easy to use rendering formats and options. Those currently available are A) limited B) To many and to complex to understand. Currently OME simple exposes all the available rendering options from libquicktime. There are many of those, but when the ffmpeg_lqt and x264_lqt plugins are missing, then a number of important formats are missing. This happens in common distributions as explained in the above point.

Some formats, like ogg-vorbis/theora or flv are not available through libquicktime, so here an alternative rendering backend would be necessary. Sidenote: ogg-vorbis/theora will be added as soon as firefox ships with a player for that format integrated per default, before it will be considered non-mainstream, and therefore mostly useless.

What needs to be done else? A decent and usable interface needs to be conceived, more obscure options need to be hidden from the user, OME is a editor first, and not a dedicated encoding tools. Those codecs available need the descriptive names, and the documentation needs to make clear what format to choose for what opportunity. Presets for DVD/Youtube, etc. need to be available. Maybe DiracPro as an intermediate codec.

Video Speed
Playback speed adjustments for video need to be done. Preferable in a simple realtime adjustable fashion. Necessary for freeze frame effects, slowed down playback, fast forward, and preferable also adjustable over time. Cannot be done easily as some kind of filter effect, needs to be integrated into the timeline, and needs dedicated tweaking knobs or something in the timeline.

Likely not to difficult to provide a “simple” (not doing any motion interpolation) implementation, but currently the more difficult things have priority.

Multi Cam
Support for editing shots that were done concurrently with multiple cameras would be nice, but not so much of a priority right now.

Some individuals have volunteered already to support translation efforts, but I would prefer to get the core feature-set ready before starting this, because else it would need to be constantly updated, as OME is very much work in progress. Also gettext, the software tool necessary for translations is not yet integrated into the sourcecode, so this would need to be done too.

Anyone interested in this translation thingi is invited to join the Open Movie Editor translators Mailing-List, it will be announced there when OME is ready for translating.

Documentation, yeah whatever….

Some kind of decent “official” web-platform would be nice, so that contributors can collaborate on documentation, however, I have no concrete plans of any kind..

There are of course a lot of other very interesting and cool ideas about what OME should and could be able to do, but what is listed above is currently the bare minimum to call it a day.

Cheers, and have fun

5 Responses to “The Open Movie Editor Roadmap”

  1. Eibriel Says:

    Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/www/ on line 83

    I think.. first, Internacing, and second High Definition, Rendering Codecs and Key Frames.


  2. burkhard Says:

    Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/www/ on line 83

    Some comments:

    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, the packager sometimes sends patches upstream. Debian packages are e.g. here: A Fedora guy complained about things in gavl. I told him basically, that the problem is not in gavl but in Fedoras packaging policies.

  3. lauchazombie Says:

    Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/www/ on line 83

    thanks for the aweosome job in this project!

  4. Punong Bisyonaryo Says:

    Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/www/ on line 83

    I really love Open Movie Editor and am using it for some video projects. (I have a simple video slideshow on

    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

  5. oracle Says:

    Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/www/ on line 83


    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.


Leave a Reply