One of the applications we have under development here is Pitivi. For outside developers it could seem as if Pitivi has been standing still for a while. This is both very true and very false. Edward who is the lead developer on Pitivi have had little time to put into enabling more features in the GUI and polishing up the look and feel of the GUI lately. On the other hand improving Pitivi is only half about working on ‘pitivi’, the other part of the equation is fixing bugs in GStreamer itself and gnonlin. Both of these libraries have seen a lot of bugfixes over the last few months and Jokosher is a living testament to their effect.
Pitivi being both audio and video is more complex, but also for Pitivi these fixes have made the application more stable and producing less error messages. Doing some QA work over the last few days I found that AVI (Divx) and MOV (Quicktime) files both transcoded dependably to Ogg Theora.
More work is needed to make MPEG and Windows Media transcode as dependable, but this shouldn’t be to hard to rectify. Once we got the input formats working dependably for Pitivi I guess it would be time to go through the output formats. I haven’t tested yet, but there has been quite a lot of work done to enable and fix more muxers in recent months so maybe some combinations already work fine.
Edwards next target for Pitivi is enabling cutting in the GUI. That means that we at least allow cutting and gluing of video clips which should be a step toward providing useful functionality beyong transcoding.
Of course a lot more could be enabled quickly in the GUI if more python hackers came onboard to help out. If you are getting into Python and is interested in helping out, please stop by #pitivi on irc.freenode.net
Christian,
I was wondering if it would be useful to make the PiTiVi sound channel accept Jokosher projects. As such Jokosher could take care of the audio editing and transcoding. PiTiVi would then /only/ have to deal with editing video and cutting the Jokosher sound track.
As such PiTiVi/Jokosher would form a suite of tools which could be used together. Clicking on a PiTiVi sound channel to edit it, would open Jokosher. Thus PiTiVi could concentrate on non-linear video editing i.e. doing one thing well.
Aidan, (i’m a jokosher dev and) this has been discussed in the past, but the main problem would be integrating the two projects without making it feel like a kludge. This is what adobe does when you have the whole suite of their products installed, but changing entire interfaces is not smooth, and I don’t think would be very usable. But if you want to propose something that you think would work, we’re all ears.
I would agree that a jokosher link would be nice, but I want basic audio editing available directly within pitivi. For instance, I had a screencast that had the music missing, so I wanted to slice out the audio after the initial commentary ended, and then insert auido. I don’t want to open another app to do this; it’s a very basic operation.
Maybe you could add an “Advanced” editing option, which edits with jokosher? I agree that there’s overlap, but it needs to be done smoothly.
Similarly, being able to paint on the windows to do basic emphasis would be nice (e.g. circling action).
Any timeframe for the slicing and splicing? I needs it pretty badly for some videos I’ve done. I’d thought it was further along. :(
[also, if you could provide .debs for ubuntu…. :]
I’m not a developer myself, but I would think that Pitivi is a very attractive project to join for a developer. First, because it must be fun to work on a video editor, and also because it’s written in Python (the most developer friendly language AFAIK). I guess that once you release something that’s useful for basic editing it will attract more attention from users and developers. I really wish you good luck. A video editor is really needed in Linux. And now that the Diva project seems abandoned (?) Pitivi is even more important.
Is there a possibility of a rethink on the gstreamer Python port? A Ctypes approach would a) exactly match the gstreamer API, would therefore b) have complete documentation, and c) be easier to maintain and stay current w/ gstreamer.