Originally posted by liam
View Post
Announcement
Collapse
No announcement yet.
PiTiVi Alpha Powered By GStreamer Services, GTK3
Collapse
X
-
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.
Leave a comment:
-
Originally posted by oyvind View PostOne 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.
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
Leave a comment:
-
Originally posted by Mathieu Duponchelle View PostAs 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.
Originally posted by Mathieu Duponchelle View PostNobody 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.
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.
Originally posted by Mathieu Duponchelle View PostThat'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).
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.
Originally posted by Mathieu Duponchelle View PostThe 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 !
Leave a comment:
-
Originally posted by oyvind View PostNo, 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.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.
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.
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 !
Leave a comment:
-
Originally posted by ssam View PostSome 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.
Simple word: terrible.
I'd never use VFR video files for editing any more. If I had, I would convert them to H264 (or some lossless format for quality).
Leave a comment:
-
Gnome sHell 3.10 close button?
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...
Leave a comment:
-
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.
Leave a comment:
-
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.
Leave a comment:
-
Originally posted by bkor View PostThe 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
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.
Leave a comment:
Leave a comment: