Phoronix: PiTiVi Alpha Powered By GStreamer Services, GTK3
The Pitivi 0.91 Alpha release was tagged on Sunday and with it is a major rework of the entire Pitivi architecture, which is now powered by the GStreamer Editing Services and supports GTK+3 for its tool-kit...
Sweet- this is what I was looking forward to. Aside from easing PiTiVi development, this will likely do a lot for the overall user experience. PiTiVi is already pretty good at being focused and robust, so anything that can add to and improve that formula is welcome.
Nice. I've used PiTiVi a few times in the past for video editing, and always though the interface was really good. It's actually quite powerful despite it's simple interface. I think a nice easy to use editor like this is always going to be needed.
Hopefully the switch over to the new Gstreamer Services will help with the stability. PiTiVi does crash a lot, but it's almost always related to the particular video file you're editing. It handles most codecs fine, but certain containers bring it down instantly. I found that throwing files into an MKV container before editing really improves the reliability. Hopefully this new version will be more robust.
I found that throwing files into an MKV container before editing really improves the reliability. Hopefully this new version will be more robust.
Some video codecs are very bad fits for editing. Interframe compression means that you need to decode frame N-1 before you can decode frame N (you might need N-2, N-3 etc as well). Also seeking is hard in a variable rate codec, because you can't tell where frame N might be in the file (i guess MKV adds some metadata to help with this). Pitivi's proxy editing plans should solve it at some point in the future.
....i guess MKV adds some metadata to help with this...
That's what I was thinking. Whatever the reason, it sometimes does the trick for when you don't want to reencode first.
The proxy editing feature sounds perfect. For better or worse, the most likely types of videos people will edit with PiTiVi are probably in some compressed format and proprietary container (smartphones, handycams). It sounds like proxy editing could smooth this out: https://bugzilla.gnome.org/show_bug.cgi?id=609136
One requirement only for a video editor: it must not crash when you look at it. And not if you decide to click on it either. Never. Ever. Seriously. Sadly, this property is missing or underestimated by far too many projects (including current Pitivi "stable"). Don't add features until it is more or less verified that the current set of features cannot make it crash. Do spend a lot of time making tests. Don't support combinations of input/output codecs and formats that are untested. Don't add lots of useless "effects" until the basics of video editing are robust and well functioning. Don't fscking crash in my face and ruin my creativity.
The dude writing Pivity should obviously ensure Gstreamer is perfect?!? Very high demand to put on such a small project. This is not a Firefox sized project
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. Blaming gstreamer is too easy, and blaming doesn't make a better product for the end-user trying to actually edit videos. Pitivi is unusable due to high crash rate, what's the point in making an application that rarely works properly again ? You'll go mad hitting Ctrl+S in fear of sudden crashes and loss of work. Not saying it's easy to write such complex software, but it's necessary to do it well and thoroughly if you want a usable product in the end.
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 ? For example, better force input to be mjpeg+pcm wrapped in AVI if that is the only thing that's remotely stable, instead of allowing every odd codec+container out there (that gstreamer+gnonlin supports in theory). You'll potentially force the end-user to convert raw input material to a supported codec/format combo before importing in project, but that's a lot better than being unstable.