Edward,
Nicely said. =)  Who knows, in the future OpenShot might switch it's video
back-end to GStreamer Editing Services also, or some other Gstreamer
back-end.  But for now, we'll stick to MLT and keep watching the
developments of PiTiVi and Gstreamer.

Thanks!
-Jonathan

On Thu, Feb 17, 2011 at 2:39 AM, Edward Hervey <[email protected]> wrote:

> On Mon, 2011-02-14 at 22:35 +0100, Gendre Sebastien wrote:
> > Hello everybody.
> >
> > OpenShot video is a video editor more advanced than PiTiVi bit with a
> > similar UI. It use ffmpeg, GTK and Python. So, why don't merge the
> > better parts of these two softwares (like using the GStreamer
> > non-lineare engine and UI of PiTiVi, core of OpenShot, etc) for make a
> > better software?
>
>   It's too late to do any merging imho.
>
>  The amount of work to do any kind of merging right now is just *way*
> too high for either project.
>
>  The goals for UI, design, processing are also different (we care about
> GStreamer a *lot*). I'd love to reach a point where the only
> differentiation is UI/design and not processing backends.
>
>  Jonathan's decision to switch to MLT instead of Gst/GNonLin made sense
> back then. We shouldn't have as much code as we have in PiTiVi right now
> for the whole editing-related logic, it just makes creating A/V editing
> apps way too hard. MLT makes that easier and therefore it makes sense
> OpenShot decided to use that.
>
>  The GStreamer Editing Services has the goal of providing APIs with an
> editing logic while still providing the full flexibility of GStreamer
> which is a key differentiator. We should be able to switch PiTiVi to it
> this year, remove a lot of code from PiTiVi while at the same time
> offering more features in PiTivi.
>
>  Finally, I think it *is* good for both OpenShot and PiTiVi to have
> some sane competition going on.
>
>     Edward
>
>
> >
> ------------------------------------------------------------------------------
> > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> > Pinpoint memory and threading errors before they happen.
> > Find and fix more than 250 security defects in the development cycle.
> > Locate bottlenecks in serial and parallel code that limit performance.
> > http://p.sf.net/sfu/intel-dev2devfeb
> > _______________________________________________ Pitivi-pitivi mailing
> list [email protected]
> https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi
>
>
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Pitivi-pitivi mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Pitivi-pitivi mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi

Reply via email to