openmovieeditor-developers Mailing List for Open Movie Editor
Status: Alpha
Brought to you by:
oracle2025
You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Burkhard P. <pl...@ip...> - 2009-04-20 22:17:46
|
Hi, the gmerlin plugin registry caching works only for plugins, for which a bg_cfg_section_t exists. This is not the case, if an empty registry is created in GmerlinFactory::GmerlinFactory. The solution is to try to load the registry in the constructor and save it in the destructor. The attached patch does that using bg_search_file_[read|write](), which results in a file ~/.gmerlin/openmovieeditor/config.xml. The path can of course be changed to anything else. After applying this patch, OME starts up significantly faster after the first time and valgrind complains less about uninitialized variables in some frei0r plugins (fixing the frei0r plugins would be another task...). Hope I got the coding style right, it differs pretty much from mine :) Burkhard |
From: Burkhard P. <pl...@ip...> - 2009-04-20 21:12:06
|
Hi, when installing libquicktime in /opt/gmerlin, the OME configure script fails to compile the test programs for lame and x264. The reason is that they include <lqt/lqt.h> instead of just <lqt.h>. Attached patch fixes that. Whether it would be better to let lqt require #include <lqt/lqt.h> is another question. But "fixing" that would break lots of other apps :) Burkhard |
From: Richard S. <or...@pr...> - 2008-10-06 06:46:01
|
Am Sonntag, den 05.10.2008, 23:08 +0200 schrieb David Hoffmann: > I have just compiled the latest Open Movie Editor from dracs > repository. In the "Interesting Ideas and Tasks to work on" I have > read about packaging and distribution. Do you know the CMake > (www.cmake.org) project? See http://www.cmake.org/Wiki/CMake_Projects > for project using this system. If you plan to port the editor for > Windows or Mac OS you'll have a solid base. With CPack you can easily > create Debian and other packages. See > http://www.cmake.org/Wiki/CMake:Packaging_With_CPack for introduction. Thanks for the hint. I indeed plan to port ome to osx/win32 one day, but this will not happen until I believe that it is sufficiently mature. So it will take some time. For now I think that for Linux this whole autoconf/automake thingi is the default, as everyone is using it, and it works fairly well. :-) Cheers -Richard |
From: David H. <dho...@go...> - 2008-10-05 21:08:37
|
Hi, I have just compiled the latest Open Movie Editor from dracs repository. In the "Interesting Ideas and Tasks to work on" I have read about packaging and distribution. Do you know the CMake (www.cmake.org) project? See http://www.cmake.org/Wiki/CMake_Projects for project using this system. If you plan to port the editor for Windows or Mac OS you'll have a solid base. With CPack you can easily create Debian and other packages. See http://www.cmake.org/Wiki/CMake:Packaging_With_CPack for introduction. Best regards, David |
From: Ø. K. <pi...@gi...> - 2008-06-14 12:10:48
|
On Sat, Jun 14, 2008 at 11:55 AM, Richard Spindler <or...@pr...> wrote: > Hi, > > for your information, I've compiled a list of popular or interesting > Filter Plugin Specifications, that are available for implementation in > Linux and Open Source/Free Software Applications. Not sure what qualifies as interesting or popular, but for the people finding the other items in the list interesting I think two of the projects I've been involved in also are of interest. GEGL development as it has been since development was last restarted under my lead is a continuation of work I've done in the past on video editing and compositing as well as interactive realtime video manipulation. The plug-in operation API as well as the GeglBuffer APIs were made public when GIMP integration started in the end of last december. GeglBuffer provides a coherent API for storage and access of large buffers (larger than RAM). The infrastructure is in place but not yet finally settled for adopting existing linear buffers as well as creating linear buffers as well. This make GEGL well suited for compositing processing of HD as well as potential 4k movies. The GeglOperation API provides base classes that use GeglBuffers as inputs and outputs. One of the major differences between GEGLs filter API and others is that GEGL strives towards always being capable of processing sub regions, this adds a bit of implementation overhead, the base classes provided have most of this implemented already. GEGL has recently gained the infrastructure to add optimized code paths (the reference implementations in GEGL should be as easily readable as possible). At the moment this is only used for the SIMD variants of processing but is planned to be extended to include some optimized variants for specific pixel formats. I've got plans to wrap some of the existing plug-in APIs as well to provide their functionality through bridge interfaces, there is already more than 100 operations available: http://gegl.org/operations.html ------------ Another API that is more of a "filter-scripting-language" has been adopted by other applications, the gluas API, which is a thin wrapper using lua for image processing with simple pixel getter and setter functions for different color spaces. http://pippin.gimp.org/plug-ins/gluas/ Various people in different places have posted gluas compatible scripts for use with different software packages. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ |
From: Richard S. <or...@pr...> - 2008-06-14 10:55:26
|
Hi, for your information, I've compiled a list of popular or interesting Filter Plugin Specifications, that are available for implementation in Linux and Open Source/Free Software Applications. *=* First of all there is frei0r, that I think everybody knows by now, since I've been pushing it for a while. ;-) http://freshmeat.net/projects/frei0r/ Implementing frei0r as a host is especially easy, particularly so if you already work with RGB or RGBA formats internally. Frei0r has its limitations, but it also has a decent selection of plugins available, which imho is one of the most obvious reasons to implement a host for a plugin format. *=* Then there are the Gmerlin Plugins, a list of them is available here: http://gmerlin.sourceforge.net/plugins.html#plugin_fv The API is slightly more complicated than frei0r, but it also allows for different colorspaces, and the available plugins can be operated in a range of different colorspaces. The plugins are also more technically focused, and some of them such as the colormatrix filter can be used as a backend for building other kinds of filters. btw. Gmerlin has a frei0r wrapper, and it also has ported a number of EffectTV filters. PS.: Gmerlin has a VERY broad plugin API, that also offers tasks that are for beyond simple video filters, this is why I don't think it necessarily competes with WEED for example. *=* There is Weed of course, which salsaman introduced recently: http://article.gmane.org/gmane.comp.video.piksel.user/3635 I am not really in a qualified position to discuss how Weed compares to gmerlin, although I would love to find out, or hear about the differences and advantages vs. disadvantages. Weed as far as I've seen has a decent selection of plugins available too, also based on EffectTV I think. *=* FreeFrame, an effect/filter API that seems to be widely popular in the visualists community is distinct due to its huge selection of hosts as well as plugins, lots of which do not qualify as free software though. :-( http://freeframe.sourceforge.net/ It appears to be simple and limited in its approach, although it has one technical feature that differentiates it from the others. Namely it specifies an extension that allows for OpenGL based filters. Using OpenGL, and especially the OpenGL Shading Language will likely have a significant impact in the near future of video processing, especially when performance is critical. Not only for realtime processing, but also for background rendering of High-Definition footage. As you might be aware, that both ATI and nVidia are massively pushing their GPUs for GPU based general purpose computing, and indeed the performance figures are impressive, when compared to CPU based designs. And especially for tasks as video filtering, GPUs are very well suited, and I guess that they can give you a lot more bang for the buck than CPUs. And since we care about free software, we should also care about enabling people to spend as little money as possible for as much performance as possible. *=* Ok, and now for something slightly different. The MathMap project is not a video filter API, strictly speaking. http://www.complang.tuwien.ac.at/schani/mathmap/ MathMap is a domain specific language for writing image filters. It is a nice environment to rapidly experiment with different algorithms and ideas, and I think that this can be a key for getting much more reusable video filters to the Open Source and Free Software community. Actually there is already a large collection of scripts available for it. I've already toyed with the idea of compiling mathmap plugins into frei0r or other videofilter plugins, but I've never had enough time or passion to make it happen. :-( There is however a blender-plugin generator in the MathMap source that might serve as a starting point for any takers. :-) (*hint*hint) ;-) And if someone happens to be into it, a translator that compiles the mathmap language into the OpenGL Shading Language would be very much appreciated. ;-) I guess those languages are slightly similar to begin with. *=* Where to go from here? What is still needed? Ok, we are getting higher resolution camera images, and multi-core CPUs, what in my opinion is still missing in all those approaches to plugin design, is a solid parallel multi-processing strategy. While it is up to the author to implement threading inside a plugin, I suggest that a reusable approach is more viable, and is ultimately less work for anyone involved. Considering that image processing is for the most cases a task that is very easy to parallelize, I think its only a matter of finding a common set of conventions and best practices to get it done. What do you think? Second: plugin composition. Combining basic plugins into more complex filtering networks can yield powerful meta-plugins, that can add a huge value to our video filter "offerings" :-P However, how can we pull together on the same string to achieve this? Ideally would be tools that allow to "compile" meta-plugins in a performance effective way, which might work with mathmap? And additionally, for plugins where this is not possible, some alternative mechanism would be useful. And of course as many apps as possible should benefit from such an effort. Any Ideas about how to pull this of? Sketches? Design-Document Brainstorms? Everything helps. ;-) *=* That's all folks, If I missed things or if you feel you have to add/debunk/flame anything, get it on. :-D Cheers, and have fun -Richard |