Announcement

Collapse
No announcement yet.

PiTiVi Alpha Powered By GStreamer Services, GTK3

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • PiTiVi Alpha Powered By GStreamer Services, GTK3

    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...

    http://www.phoronix.com/vr.php?view=MTQ3Mjk

  • #2
    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.

    Comment


    • #3
      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.

      Comment


      • #4
        Originally posted by benmoran View Post
        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.

        Comment


        • #5
          Originally posted by ssam View Post
          ....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

          Comment


          • #6
            Thou shalt not crash

            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.

            Comment


            • #7
              Originally posted by oyvind View Post
              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

              Comment


              • #8
                Originally posted by bkor View Post
                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
                The main problem seems to be that there are far too many video editors and nothing works reliably or is feature full.

                Comment


                • #9
                  I am fairly sure the devs are aware of and making good progress on stability. They are also adding more automated tests http://jeff.ecchi.ca/blog/2013/09/04/fix-it-thrice/

                  Comment


                  • #10
                    Originally posted by bkor View Post
                    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.

                    Comment


                    • #11
                      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.

                      Comment


                      • #12
                        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.

                        Comment


                        • #13
                          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...

                          Comment


                          • #14
                            Originally posted by ssam View Post
                            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've tried to edit some WMV files with H264 files.
                            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).

                            Comment


                            • #15
                              Originally posted by oyvind View Post
                              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.
                              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.
                              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.

                              Blaming gstreamer is too easy, and blaming doesn't make a better product for the end-user trying to actually edit videos.
                              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.
                              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 ?
                              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).
                              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 !

                              Comment

                              Working...
                              X