Announcement

Collapse
No announcement yet.

Flowblade 2.14 Video Editor Released, GTK4 Port Hopefully Ready Next Year

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

  • #11
    Does anyone know if it supports basic color management yet? Last time I tested it, it couldn't do the basic compositing right but that may have changed

    Originally posted by mxan View Post
    GTK 4 doesn't do anything better than GTK 3, in fact it's worse in several aspects - no accessibility, no theming, blurry text rendering (Emanuelle Bassi response: "What makes you think sharpness is a metric?"), worse performance and tons of bugs with the new renderers they're forcing on everyone with GTK 4.14.

    They should port to Qt instead, or collaborate with other projects to fork GTK 3.
    Gnome developers are the biggest clowns​, expecting anything more from them is big clown. But I disagree with worse performance. GTK4 has significantly higher performance the GTK3 does.

    Originally posted by Mateus Felipe View Post
    Did someone use this editor and can share their experience?

    Video editing in Linux, at least if we consider open source alternatives, has always been terrible.

    The better editor I used was Kdenlive, but it still was very featureless and crashed often. I also used Open shot and another one that I don't remember the name.

    'Ive never heard of this Flowblade before.
    Olive video editor was/is great, It is for sure an alpha editor, but it's node based system is really powerful, you can't save presets, but you can copy and paste them (the node system is run as an XML so you can save them to a file easily.) It is properly colormanaged with OCIO. You can even use your own ocio config files so if you need aces or HDR you can, although HDR is a bit of a weird situation since you can set the viewer for HDR but the rest of the UI is in SDR, it's still usable though. If you do try it you may want the GLSL PR since it allows custom GLSL effects right in as a node, and it works pretty well, this adds a LOT of filters that would otherwise need banged out on the node system.

    Olive has been put on hold since QT is too much of a mess, the developer is exploring other options and apparently godot is promising. I still use olive myself, and it's signifcantly better then any other free editor I find if you don't mind also using external tools for various other things.

    Comment


    • #12
      Originally posted by Mateus Felipe View Post
      Did someone use this editor and can share their experience?

      Video editing in Linux, at least if we consider open source alternatives, has always been terrible.

      The better editor I used was Kdenlive, but it still was very featureless and crashed often. I also used Open shot and another one that I don't remember the name.

      'Ive never heard of this Flowblade before.
      Kdenlive, shotcut, openshot and flowblade are all based on MLT.

      So you should expect similar capabilities, different workflows/focus. In terms of features I'd argue Kdenlive should be the one that has the most, judging from the outside based only on size and age.

      There are tons more options, like cinellara/lumiera, olive, pitivi, open video editor, etc.

      Even blender if you want.

      So there's plenty of choice, although I know nothing about features and stability. Stability seems to be a problem for everyone doing NLEs, or at least I'm led to believe so, since Adobe has struggled so much to make something that works.


      Then considering non open-source I guess the biggest are DaVinci resolve and Lightworks. One offering in a single suite a "complete workflow" with effects, mastering, colour correcting, and the other being so packed to the gills with kitchen sinks and complexity that I fully believe it fulfills the worst requitements for "professional" software.

      But honestly, I don't think the experience with modern FOSS NLEs is horrible or awful, for people trying things out there are plenty of videos on YouTube, but for the home gamer it is REALLY easy to just get one of the smaller ones and cut together simple edits of your family trip or w/e

      Comment


      • #13
        Originally posted by Eberhardt View Post
        Thanks for doing the job of debunking your statement yourself.

        In your own words you say, that accessibility exists (albeit not in an ideal state), that theming is not a problem of GTK4 itself, blurry text rendering has a fix (AFAIK the workaround isn't necessary since quite some time now), you have no idea about performance because you don't use GTK4 apps and the same story regarding the bugs.

        TL;DR you made all claims up, despite actually knowing they were wrong for the most part.
        It was never my statement in the first place. I was just saying "I think this is what they're talking about it".

        Originally posted by Eberhardt View Post
        I get it that you don't like GTK4. I don't like the look and feel of Qt for instance. But I know that's just a question of personal taste. I would never rant about KDE stuff because I rarely use it and I think they are doing a great job, it's just not for me.
        My only issue with GTK is that they spent over a decade building up people's trust that GTK 1.x and GTK+ 2.x were a safe base to build all sorts of non-GNOME desktops and apps on, and now, with GTK 3 and GTK 4, they're incrementally forcing GNOME-isms on non-GNOME GTK apps that don't have the manpower to rewrite on top of a new toolkit. (Some do. For example, the LXDE people tried a port to GTK 3 and, instead, chose to merge with the Razor-Qt team to make a successor to LXDE named LXQt.)

        If they weren't indirectly making a mess of tools with no suitable Qt alternatives like Inkscape, I'd have no problem with it whatsoever. (Some people do care. That's why GNOME 3 prompted the creation of Cinnamon and MATE and why their "run stock GNOME or GTFO" demands prompted System76 to GTFO and develop COSMIC. GNOME has single-handedly done more for desktop fragmentation than any other group in the last 20 years.)
        Last edited by ssokolow; 31 March 2024, 01:26 PM.

        Comment


        • #14
          A video editor written in Python?
          That's the last language I would choose for such a perf critical + complex type of project.
          Good proof of concept for python lovers though!

          Comment


          • #15
            Originally posted by rmfx View Post
            A video editor written in Python?
            That's the last language I would choose for such a perf critical + complex type of project.
            Good proof of concept for python lovers though!
            Is it written entirely in Python or just the UI glue? ...because it's possible it's as "written in Python" as a Qt Quick or Kirigami-based video editor would be written in QML.

            Hell, that's how I do my "written in Python" stuff. All the heavy lifting is in Qt or OpenCV or a custom Rust library or something, and PyQt is only used to gain a memory-safe way to bind to the QWidget APIs.

            Comment


            • #16
              Originally posted by DumbFsck View Post
              Kdenlive, shotcut, openshot and flowblade are all based on MLT.
              How often does MLT get new features or enhancements?

              Comment


              • #17
                Originally posted by ezst036 View Post

                How often does MLT get new features or enhancements?
                Latest version is from 2023-11-28 and the previous from 2023-10-01. Idk how much is new features vs. polish and bug fixing.

                For the discussed NLVEs I think it doesn't matter though, as none of them implement everything there is in MLT.

                Also, remember I'm talking as someone who doesn't know a lot about the subject, but I fully believe all of them may and do use MLT functions in creative ways to eek out performance or different effects and etc., it isn't as simple as "they're just frontends for the same backend" I think. Also of course there are many omissions derived from the fact that MLT has much bigger coverage of broadcasting needs in addition to video editing.

                rmfx
                The project is based on MLT, no perf critical paths in python, I'm sure.

                Comment


                • #18
                  Originally posted by Eberhardt View Post
                  I'm still not as well informed about the topic as some forum members here.
                  At least you are right on this part 😉

                  Comment


                  • #19
                    Don't hold your breath for a GTK4 port. The GTK4 devs have decided not to make a proper gui editor for their toolkit.

                    Comment


                    • #20
                      Originally posted by Eberhardt View Post
                      blurry text rendering has a fix (AFAIK the workaround isn't necessary since quite some time now)
                      It does not. That workaround is only partial. The full solution requires that MR 3393 be resurrected and merged, which judging from the vibes requires Mattias Classen to repent and abandon his incorrect beliefs about the importance of static vs animated text. Unless and until GTK4+ has subpixel antialiasing, it is unfit for purpose at less than 200 PPI, which is basically only smartphones and $1000+ laptops (and only some of those; PPI trades off with battery life and other specs). Or, I suppose it's okay for single-purpose applications that you don't keep open or use regularly, like overclocking tools and CD burners.

                      Comment

                      Working...
                      X