openshot.developers team mailing list archive

[Jonathan Thomas <jonathan.oomph@xxxxxxxxx>]

Hi everyone!  I have some *Big OpenShot News *today to announce to everyone!
 I know I've been real quiet the past 4 to 6 weeks, but all of that is about
to change.  I have been developing a new video editing library, written in
C++, based on FFmpeg, and patterned after the animation framework used by
Blender.  I have been thinking about this for a long time, and have a very
clear vision for what I am creating.  Let me breakdown my decision, and give
some supporting facts:

*MLT* has been a* great framework*, but almost all of the bugs and
complaints we get are related to MLT: crashes, choppy HD video playback,
choppy audio, poor JACK support, poor multi-core performance, scaling
issues, poor key-frame support, limited de-interlacing options, and issues
with frame accuracy when seeking.  As we move forward with OpenShot, it is
important we solve and improve these highly complex issues.  The way I see
it, we have 3 options when it comes to improving the video framework
that OpenShot uses.

   - *Option 1:* Enhance the MLT framework
      - With an aging C code base, limited key-frame support, buggy
      multi-threading, the work required and the risk is very high to
enhance some
      of the core features in MLT.  C has no error handling, no support for
      object-oriented code, and other issues that make development
more difficult.
   - *Option 2:* Switch to the AML
framework<https://launchpad.net/ardome-ml> (developed
   by Charlie Yates, one of the original developers of MLT)
      - Although I was initially excited about this option, it has become
      difficult to contact Charlie, and the framework has not been
modified since
      mid-2010.  However, this project inherits much of it's code from another
      (even older project), and thus it is quite complex.
   - *Option 3:* Create a new framework, with complete control over
   stability, design, and features
      - This is a high risk option, but has the greatest advantage, as the
      code base can be designed around OpenShot, and only contain the
features we
      need

After much research and consideration, I have chosen option 3.  This
required creating many simple proof-of-concept C++ applications and many
conversations with the upstream projects that would be involved in such
an endeavorer.  At this point, I have proven all the concepts that needed
proving, and I am feeling very confident about the design and implementation
at this point.
*
*
*My focus* has been to develop a framework that has the following features:

   - C++ code base.  Object-oriented.  Simple API and design.  Good use of
   Exceptions and error handling.  Prevent crashing at all costs.
   - Multi-processor aware (take advantage of all available processing
   cores)
   - Powerful bezeir curve-based keyframe system (every setting and
   parameter should support keyframes)
   - A node-based audio system, including JACK support, and LADSPA filters.
    Also, strong audio analysis, including waveforms, spectral analysis, time
   stretching / shrinking, and 3D audio (i.e. dolby / surround sound).  I have
   spent much of my time improving my understand of audio processing. =)
   - FFmpeg <http://www.ffmpeg.org/>-based, for decoding and encoding
   - Use a powerful image processing module:
ImageMagick++<http://www.imagemagick.org/Magick++/>
   - Use a powerful audio processing module: CLAM
Audio<http://clam-project.org/>
   - Python interface designed specifically for OpenShot (to minimize the
   impact to OpenShot changing multimedia back-ends)
   - All meta data available via the API (list of profiles, list of effects,
   parameters of effects, etc...)

What's next?  Soon (i.e. in the next 2 weeks hopefully) I will wrap up my
initial framework code and start setting up the project in LaunchPad.
 Realistically, there is about 6 weeks of work left for me to achieve all
the features I want.  The development of this framework will be fast and
will be very focused, so I don't expect this to take very long to complete.
 Of course, once LaunchPad has the source code, we will need to "hopefully"
recruit some other C++ programmers to help us out, especially with the build
process and packaging.

*The big picture:*

   - *Great Stability*
   - *Better Performance*
   - *A huge increase in the number of image and audio effects (including
   JACK support)*
   - *Animation key-frame system that rivals Hollywood animation packages*
   - *Much simpler framework (i.e. less code to maintain)*

Hopefully I have convinced everyone that this is a good decision, and not
some knee jerk decision. =)  I am very excited about this, and I have no
doubt we can achieve these results very quickly.  Soon I will announce this
on my blog, but I wanted to get feedback from our OpenShot Developers team
first.  So, please let me know what you think.

Thanks!
-Jonathan