|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
|
|
HelloHi everyone,
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. 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. 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. 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!) 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! Cheers, Josh ---- http://joshmatthews.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 http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Pitivi-pitivi mailing list Pitivi-pitivi@... https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi |
|
|
Fwd: HelloI sent this message to the list three days ago, but I don't see it in the archives. Is this working?
Cheers, Josh ---------- Forwarded message ---------- From: Josh Matthews <josh@...> Date: Fri, Sep 26, 2008 at 1:48 AM Subject: [PiTiVi] Hello To: pitivi-pitivi@... Hi everyone,
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. 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. 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. 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!) 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! Cheers, Josh ---- http://joshmatthews.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 http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Pitivi-pitivi mailing list Pitivi-pitivi@... https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi |
|
|
HelloHi everyone, 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. 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. 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. 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!) 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! Cheers, Josh ---- http://joshmatthews.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 http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Pitivi-pitivi mailing list Pitivi-pitivi@... https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi |
|
|
Re: HelloHi,
On Tue, 2008-09-30 at 14:46 -0400, Josh Matthews wrote: > Hi everyone, > 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. Brandon is working exactly on that at the moment. If you explain more about what you find good/bad about maya's graph editor.. we can come up with better solutions. > > 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. This one is going to be helped a LOT by the fact we're using 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 clips/effects * Yet be able to create complex combinations of sources/effects. > > 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. Attributes are properties of the GstElement ... for which there is a keyable interface (GstController) to modify those properties through time. > > 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!) What exactly was bad about those software ? Bad UI ? Bad handling of single frames ? > > 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! We're planning a release right now, and afterwards there should a 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 ! :) Edward P.S. If you can, there's also an IRC channel where most of us are : #pitivi on irc.freenode.net > > Cheers, > Josh > > ---- > http://joshmatthews.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 > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ Pitivi-pitivi mailing list Pitivi-pitivi@... https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi ------------------------------------------------------------------------- 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 http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Pitivi-pitivi mailing list Pitivi-pitivi@... https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi |
|
|
Re: HelloI've been idling in #pitivi as jdm for several days now, for the record. Now, on to the meat of the response:
Good things about Maya's graph editor - the ability to see and edit multiple curves at the same time, locking of curves, infinite tracking and zooming. GStreamer and Gnonlin's abstractions sound really good for the task, so uh, well done! Re: stop motion, I'll give an overview of my experiences with Final Cut for a 4:20 film. In short, it was ghastly. FCP did not like the number of frames we were using and became quite unresponsive at times. It was really difficult to change the duration of certain frames, if we wanted to stretch out some shots - anything under 1 second was a bit of a crap shoot for some reason. Sometimes it would work, other times it would change to something like 3 seconds. Also, the default duration for each frame when imported was 5 seconds or something rediculous, so we had to change it every time. Applying transitions across shots (ie. a cross-dissolve through 100 frames) seemed impossible, as FCP wants to transition between clips, and clips in this case meant a frame which was 1/5 of a second. These sorts of problems harangued me the whole time I edited my film. Hope these ideas help! Cheers, Josh On Wed, Oct 1, 2008 at 5:10 AM, Edward Hervey <bilboed@...> wrote: Hi, ------------------------------------------------------------------------- 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 http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Pitivi-pitivi mailing list Pitivi-pitivi@... https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi |
|
|
Re: Fwd: Hello>I sent this message to the list three days ago, but I don't see it in the archives. Is this working?
The list is receiving it, as far as I know. Ubuntu On Sun, Sep 28, 2008 at 2:33 PM, Josh Matthews <josh@...> wrote:
------------------------------------------------------------------------- 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 http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Pitivi-pitivi mailing list Pitivi-pitivi@... https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi |
| Free Forum Powered by Nabble | Forum Help |