Announcement

Collapse
No announcement yet.

PiTiVi Alpha Powered By GStreamer Services, GTK3

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

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