openshot.developers team mailing list archive

[Jonathan Thomas <jonathan.oomph@xxxxxxxxx>]

Andy,
Yes, I am confident I can do it, as I've already put down quite a bit of
code and I am really feeling good about it all.  The formats and codecs will
still be driven by FFmpeg and which codecs it was installed with.  LV2 is
also supported by the CLAM audio library, so that should not be an issue.  I
am just trying to push myself to get everything wrapped up quickly so I can
get it onto LaunchPad.  =)

Also, once we get a somewhat working and complete version of the framework,
we can branch OpenShot and starting integrating everything in it's own
branch.  Finally, once the new branch is stable and all of us developers are
happy with OpenShot, we'll merge this branch back into the main trunk.
 Possibly this could be version 2.0 of OpenShot?

Thanks!
-Jonathan

On Mon, Apr 11, 2011 at 4:31 PM, Andy Finch <we.rocked.in79@xxxxxxxxx>wrote:

> One word -  Whoa!
>
> That is big news. If you're confident you can do it, then go for it. It
> will be a huge advantage for Openshot to have it's own library, and as you
> say will eliminate a lot of library problems if the library is under our
> control (although format support will still be ffmpeg dependent?).
>
> A quick word on the audio front - LV2 is rapidly becoming the new standard
> for audio plugins, so we should aim to support that as well as LADSPA :-)
>
> Look forward to seeing the results!
>
> Andy.
>
> On 11 April 2011 21:12, Jonathan Thomas <jonathan.oomph@xxxxxxxxx> wrote:
>
>> 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
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openshot.developers
>> Post to     : openshot.developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openshot.developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>