Announcement

Collapse
No announcement yet.

PiTiVi Alpha Powered By GStreamer Services, GTK3

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

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


            • #16
              Originally posted by Mathieu Duponchelle View Post
              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.
              This sounds great indeed.

              Originally posted by Mathieu Duponchelle View Post
              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.
              Understandable, gstreamer is large and complex, and fixes in it will benefit all users of the library. However, the reason for my posts is the frustration that Pitivi (and many other video editors) has always been so unstable, but it has a rather nice UI. So it is from the viewpoint of an end user. I've often given Pitivi a shot after a new release, but lose hope when the crashing starts. Now I'm looking forward to the 1.0-release !

              Originally posted by Mathieu Duponchelle View Post
              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.
              Green-lighting sounds like a good solution ! Then I can know what to avoid, and convert input if necessary.

              Originally posted by Mathieu Duponchelle View Post
              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 !
              I'm excited to hear about this, will be fun to compare with Openshot 2.0.

              Comment


              • #17
                Originally posted by oyvind View Post
                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.
                ....so.....exactly no sophisticated project (except something like tex, maybe) can meet this requirement under all circumstances, let alone a nle.
                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

                Comment


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

                  Comment


                  • #19
                    Originally posted by liam View Post
                    ....so.....exactly no sophisticated project (except something like tex, maybe) can meet this requirement under all circumstances, let alone a nle.
                    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
                    Don't take my first post so literally. I exaggerated to make a point.

                    Comment

                    Working...
                    X