Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/www/news.openmovieeditor.org/wp-includes/functions-formatting.php 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!
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.
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.
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
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.
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.
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