On Tue, 2008-09-30 at 14:46 -0400, Josh Matthews wrote:
> Hi everyone, Brandon is working exactly on that at the moment. If you explain more
> I've been working on and off on a video editor in C++ for most of a
> year, but I came across PiTiVi recently and it appears to be a much
> more mature and promising project. I've read through just about every
> link on the wiki, and I'm pretty excited by what's there (and also in
> my 5 minute test of the program). I'm an amateur filmmaker, and my
> desire to create my own editing program stemmed from several
> shortcomings I found in my usage of commercial products (iMovie, Final
> Cut, and Adobe Premiere). My goals for my editor were as follows:
> 1) Powerful keyframe editing abilities
> My current day job is a software developer at Autodesk (I've worked on
> both Maya and Studio), and I wanted to create a tool like Maya's graph
> editor to allow me to easily set and modify keyframes. This stemmed
> from a 24 hour film competition I took part in, where for one scene I
> had an overlay that was supposed to fit inside of a TV as the shot
> zoomed out. As far as I could tell, there was no way to link size and
> motion keys in Premiere, which made the whole shot exceedingly
> difficult to work with and change. A visualizer like Maya's graph
> editor would have been perfect for this task.
about what you find good/bad about maya's graph editor.. we can come up
with better solutions.
This one is going to be helped a LOT by the fact we're using
> 2) DAG-based backend
> Every part of the editor would be a series of input and output
> connections to nodes. A clip would be a node, outputting to a clip
> sequence. If an effect were applied to a clip, the output of the clip
> would pass to the effect, which would now output to the clip sequence.
> Transitions would take two inputs and output the correct image. This
> would allow for smarter redraws (if one effect's parameters change,
> anything before it doesn't need to redraw) and pave the way for a
> simple and effective undo/redo system.
GStreamer... whose processing pipelines are ... DAG :)
So when you're using pitivi ... all the multimedia processing is in
fact done in DAG (GstPipeline) of nodes (GstElement).
The problem is that DAG don't solve everything in the world of video
editing. You can't represent a timeline (easily) only by using a DAG
(i.e. How do you represent the graph of 3 clips playing one after
another ? Imagine that with a short movie with 300 clips). And you also
have the case where most of the time you actually want to NOT-KNOW that
you have interacting with DAG (most editors, whatever the level, don't
care about it).
The compromise we have in pitivi is that the time-positions and
priority of any object (clips, effects) within a composition is done
through an 'abstraction' set of GStreamer elements called gnonlin.
GNonLin offers a container type (GnlComposition) which can dynamically
create the DAG for any given position. It does this by knowing about the
time-position/priority of the nodes (GnlObject) contained within. So for
a given position in time you always have a DAG, but the connected
nodes/layout will change through time.
Those DAG can also be done at smaller level that a full blown
pipelines, at which point the producers/consumers are no longer nodes
(GstElement) but pads providing data from upstream/downstream elements.
You can put those in containers (GstBin) which are in fact subclasses of
nodes (GstElement) ... and re-use them as often as you wish. You can
very easily create a rotozoom node by combining a rotation element and a
scale element into one container. And you can use that new node in your
composition at whichever position you want.
You therefore get the benefits of:
* Simple interface for setting the positin/duration of your
* Yet be able to create complex combinations of sources/effects.
Attributes are properties of the GstElement ... for which there is a
> 3) Any attribute is part of the DAG, and keyable
> Anything on a node that could be changed would be able to be animated.
> Because everything is represented as outputs and inputs in the DAG, it
> lends itself to easy undo/redo.
keyable interface (GstController) to modify those properties through
What exactly was bad about those software ? Bad UI ? Bad handling of
> 4) Support for stop-motion workflows
> I didn't have much planned out here, but my experience trying to do
> stop motion in both iMovie and Final Cut convinced me that there had
> to be a better way (it was ghastly!)
single frames ?
We're planning a release right now, and afterwards there should a
> Currently, the only public code I have of my editor is a prototype
> frontend I was working on that could play a movie file using ffmpeg,
> allowing pause, stop, etc. and a timeline widget I created using
> Guichan. Unreleased is my backend work with the dependency graph,
> with a working undo/redo and keyframing system. I don't know whether
> any of these ideas interest you, but most important to me in a video
> editor are the graph editor and stop-motion workflow. I'd love to
> help with PiTiVi in whatever way I can. I'm excited to learn more
> about the plans for PiTiVi's future!
decent part of refactoring to provide more features and an easier
terrain to implement more features.
Seeing how interested you are in the keyframe editor, maybe exchanging
your point of views with Brandon could be a good thing.
Thanks for your interest ! :)
P.S. If you can, there's also an IRC channel where most of us are :
#pitivi on irc.freenode.net
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> _______________________________________________ Pitivi-pitivi mailing list Pitivifirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi