Announcement

Collapse
No announcement yet.

Lightworks Is Not As Open As Some Would Like

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

  • #31
    Originally posted by numasan View Post
    I will be very interested to see how EditShare will handle the open source aspect of Lightworks, compared to their commercial version. I'm specifically thinking about formats/codecs here. For example DPX is a format I and companies I work for use a lot, and that is only available in the "Pro" version. What will happen if community implements support for DPX (and other formats) currently only offered in the paid version? I understand that formats like R3D requires a commercial license for redistribution, and therefore only available in the paid version, but I think it is silly that DPX - which is an open standard - is excluded from the free/open source version, as well as codecs that can potentially be covered by ffmpeg.

    So again, will be interesting to see how "open source" EditShare allows it to be...
    Good question, with the likely answer being "no, we like our open core", a short-lived fork with the added codecs, which then gets dropped when it takes too much time to update it to latest LW.

    Comment


    • #32
      Originally posted by vanag View Post
      Why don't they make a release for mingw then for the community to help?
      well i guess they want an entire independent platform core source code. kinda like Nvidia blob, they have a huge pool of the driver source code that is usable for all platform. thinking like that it's way easier to maintain and improve then rewriting all.

      Comment


      • #33
        I haven't had sync issues since 2008

        Originally posted by Mr_Alien_Overlord View Post
        When Kdenlive works, it's beautiful. Not perfect, but an interface and workflow that I love (far more than that of Lightworks). That said, for many video formats, they look fine when you're editing, but lose more and more sync between audio and video as you get past about a minute of rendering. I've tried for literally *weeks* to fix problems with this, more than once over many years (including just a couple of months ago). The problem is that it doesn't just shift the audio earlier or later, but also speeds it up or slows it down. It makes it into an absolute nightmare to try and fix, and of course you often don't even discover the problem until you're just about finished a project, have invested a lot of time into it and now don't have the time to migrate elsewhere.
        I haven't had THAT issue since the KDE 3.5 versions in Ubunty Gutsy and Hardy! Since then, in OS's ranging from Ubuntu Jaunty all the way to Cinnamon over Ubuntu Trusty (14.04), and on machines from Intel Atom to AMD Athlon 64 all the way to AMD FX 8120, I've never had this problem again. Source files have been motion jpegs, AVCHD with H264 streams, even downloaded flv files. The only time I had sync/speed issues were with some H264 streams transferred out of .MTS containers into MP4 containers about a year ago, when doing this from the ffmpeg command line made files something in Kdenlive or MLT didn't like. These had severe speed issues, switching to .flv containers fixed that. Finally, sometime last summer the orignal MTS files from my camera because usable without seek issues getting to a starting point on playback of the timeline, so now I use them directly.

        The old KDE3.5 versions had to very bad bugs: the sync issues, (which could be worked around by using a 25fps project rate and setting the camera for 25fps) and an ugly tendecy to narrow and pillerbox the files I was importing at that time. In 2008 I didn't know enough about video editing to find a fix for that, but the KDE4 versions of Kdenlive never had that problem anyway. If you haven't used Kdenlive since KDE3.5, try it again, you will be amazed at how far this wonderful program has come.

        Comment

        Working...
        X