http://wiki.pitivi.org/wiki/Building_with_GES has a script to build the latest dev version of pitivi (and its requirements) in a folder so that they don't interfere with packages from your distro.
I hope there will be a ppa available whenever they reach beta. The constant crashes _are_ annoying. I think they should offer the option to autosave frequently.
But in any case, PiTiVi has allowed me and my kids to make some fun home movies with cool soundtracks and all, and we have no training or experience in video editing. Kudos to the devs.
Just out of curiosity, is the new and shiny Gnome sHell 3.10 close button planned/supported/already implemented? PiTiVi was always very Gnome centric so I wonder if they will jump in with this feature...
As one of pitivi's maintainers (by the way we are three ), I absolutely agree with you, and the other maintainers do as well, which is why I spent the last six months, part of it as a google summer of code (http://www.google-melange.com/gsoc/p...thieu_du/23001), doing absolutely nothing else than bug fixing, and I intend to continue doing so until we deem pitivi stable enough that it deserves to be named 1.0.No, that dude should have the ambition to write a robust and reliable application no matter what underlying media library he chooses to base it upon.
Nobody has been *blaming* anybody, we've always praised gstreamer as being the multimedia framework of choice for the open-source world, backed and maintained by multiple industry players, with a great architecture and an ever growing set of plugins to tap into.Blaming gstreamer is too easy, and blaming doesn't make a better product for the end-user trying to actually edit videos.
However, gstreamer-editing-services and before it the python editing backend of pitivi were and are the first implementations of non-linear editing functionnalities making use of the framework, and as such they uncovered a lot of issues with gstreamer dynamic pipeline capabilities.
The framework has been designed in order to allow dynamic reconfiguration of pipelines, but not all the plugins have been tested with that in mind, for the record 75 % of the time I've spent on bug fixing has been in various gstreamer elements, let me take a simple example :
The oggdemux plugin had an issue which made it lose frames on seeks, for example you would seek at one second in your file, and in some situations have a black output until a new keyframe was reached, which would lead to black frames in the resulting video playback and render.
(https://bugzilla.gnome.org/show_bug.cgi?id=700537). This has been fixed, and will profit to totem, pitivi and any other applications using gstreamer to play and seek ogg files.
Don't get me wrong, pitivi of course has its own issues, not related to gstreamer, but pitivi is only the top of the iceberg, a mere 30 000 lines of code on top of a one million+ lines of code framework. You can't expect all the bugs to only come from the tip of the iceberg.
That's an interesting point, but our answer to that problem is slightly different. The strength of basing our architecture on gstreamer is precisely that we *should* be able to decode any formats supported by gstreamer, and encode in any of them as well. Restricting this would mean double encoding with loss of information, as most compressing algorithms are lossy (you can of course use only huffman compression for instance, but that means you'll have to live with one gigabyte per minute rushes when you go full HD).How about actually restricting what gstreamer-functionality and combinations of codecs/formats/filters that are allowed to only those that are properly tested and found stable ?
What we decided to do instead, was to actually test major formats combinations in various high level scenarios (making a transition between two different formats and rendering in another format for instance). That test suite is still work in progress, but it already helped us uncovering and fixing tons of issues across the stack, and will continue doing so, and also help us prevent regressions in the future. It's available here : http://cgit.freedesktop.org/gstreame.../integration.c if you want to have a look, there are already 196 test cases in it.
What we will do, instead of restricting formats, is "greenlighting" formats that we estimate well supported enough. You'll still have the option to use any other formats supported by gstreamer, but knowing that these are not (yet) sufficiently tested for us to greenlight them.
The future for us is yet another six months of bugfixing, doing it the right way and developing our test tools along the way. Plans include frame-by-frame comparison, live editing scenarios serialization (what happens if I add a clip, seek three times in a row, add another clip with a transition etc ...), and also systematic testing of other types of plugins (effects for example).
There is a reason why we nicknamed this release "charming defects", it is because we want to make clear that we are aware that there still is a lot of issues, but we believe that the community can see through them, look at the "charming" way we do things (the clutter timeline is quite nice if you ask me), and help us progress to beta then 1.0 through useful feedback and clever patches.
Rest assured that our ambition *is* to make a robust application, and have the tools to prove it with each new release, and feel free to come on our irc and talk about it with us !
Even something written in "safe languages" like haskell or prolog are at the whims of their interpreters.
However, you later say "more or less", so obviously that requirement isn't as hard as you said in the beginning
It is, I'm running it on F20 here but it's not yet packaged, someone in our channel expressed his interest in packaging it, not sure when he'll find time. We already found and fixed new bugs since Sunday though, but we're coming to a monthly release schedule now, more or less in sync with gstreamer.