Lightworks in unsuited for my needs, where open source is used for security reasons
I have been using Kdenlive since 2007. I have to handle video from activist events where raw clips are very sensitive and must be stored under heavy-duty encryption. As a result, I cannot allow any closed-source binary that is in contact with the external network to be in any pathway traveled by these files, nor by the boot-time encryption password. I don't even use proprietary video drivers these days, though they could be tested by running Wireshark with and without them to verify that they do not go online with any hidden activity. A video editor that requires a connection to the Internet and is a closed binary (or just beyond my own understanding!) is not safe for this kind of specialized work. Just to test Lightworks I would have to put it on a dedicated drive with a dedicated copy of my OS and not encrypted. I would also have to create safe raw files for testing, and not with my AVCHD camera or Lightworks would lose the ability to read them after the 7 day "pro" trial period expired.
I see the issue with how Lightworks is distributed as a market segmentation issue. OK, CBS, CNN et all would fear they cannot get away with using open source ffmpeg/avconv to handle formats encumbered in the US and Japan by software patents. That means they CAN'T use Kdenlive, which is the video editor I am familiar with and for that reason compare all others against. On the other hand, doing unpaid video work, I would not consider using pay software when free and open source versions are available(no matter how buggy, I'd rather patch and workaround than pay), and certainly would not allow a program connected to the Internet to access my raw and unchecked video clips. The free version of Lightworks can't read AVCHD, which small 1080p cameras produce. which means I can't use it even if a later open source release strips out the activation requirement and security issue.
All this means Lightworks in inappropriate for non-monetized video made from security-sensitive clips, and Kdenlive is and will remain inappropriate for high-dollar commercial video in the few countries where MPEG-LA can play their patent games, at least until those patents expire and no new patented codecs arise. They are two different products, written by two different kinds of authors, for two different kinds of users. I was starting to sweat that if too many people abandoned Kdenlive, I would not be able to keep using it myself unless I was able to learn enough about the source code to mantain it myself, which would be a huge undertaking. I've already had to do that with the old Ubuntustudio GTK theme, and that is work enough when new versions of GTK break something.
My main worry was that Lightworks would pull people away from Kdenlive without really offering the same functionality in a free and offline version, but my guess is the separation between users of open-source ffmpeg/avconv and paid "legal" codecs will forcibly separate these userbases until H264 dies online and the last AVCHD camera dies of electromigration, or until the codec patents expire, whichever comes first. I would like to see Kdenlive pick up Shotcut's work in making openGL playback really work, and that direct shader language GPU compute, both of which are not in the MLT backend that Shotcut and Kdenlive both use. If that gets fully debugged, and Kdenlive gains the ability to play back a timeline full of night-camera color correction in full real time, that will be all I will ever need. GPU render would be nice, but some say only the Mercury engine, using the GPU for everything, can avoid giving back the gains in system ram/video ram memory transfers.
For that matter, I ran an experiment last year benchmarking an nvidia GTS450 with the blob (blacklisted against encryption password entries while X was running!) against AMD bulldozer FX-8150 overclocked to 4.5 GHX, using Blender from PPA on the "cycles" rendering engine. That uses openCL, and at that time would detect and use that GPU if asked. Only thing was, that FX-8150 beat the NvidiaGTS450 by a substantial margin, 20% at least, in identical openCL Cycles render tests of that huge auto dealer floor raytraced image. I now use an AMD HD6750 with Mesa (more trustworthy for my purpose), giving 60-70% of theoretical openGL performance.
On this kind of system, I wonder if Lightworks would be able to use the Mesa driver, and if so, would using it be enough to outrun the 8-core CPU for rendering anyway? If not, than Kdenlive needs only to get effects to play back in real time to be a "finished" video editor so far as I am concerned. Don't like the theme? Think it looks "unprofessional?" You can change it. I theme it to match my old-style "Ubuntustudio-legacy" GTK theme. I've got a screnshot of Lightworks running, I could probably make Kdenlive look like it if I had any reason to do so,.
I have been using Kdenlive since 2007. I have to handle video from activist events where raw clips are very sensitive and must be stored under heavy-duty encryption. As a result, I cannot allow any closed-source binary that is in contact with the external network to be in any pathway traveled by these files, nor by the boot-time encryption password. I don't even use proprietary video drivers these days, though they could be tested by running Wireshark with and without them to verify that they do not go online with any hidden activity. A video editor that requires a connection to the Internet and is a closed binary (or just beyond my own understanding!) is not safe for this kind of specialized work. Just to test Lightworks I would have to put it on a dedicated drive with a dedicated copy of my OS and not encrypted. I would also have to create safe raw files for testing, and not with my AVCHD camera or Lightworks would lose the ability to read them after the 7 day "pro" trial period expired.
I see the issue with how Lightworks is distributed as a market segmentation issue. OK, CBS, CNN et all would fear they cannot get away with using open source ffmpeg/avconv to handle formats encumbered in the US and Japan by software patents. That means they CAN'T use Kdenlive, which is the video editor I am familiar with and for that reason compare all others against. On the other hand, doing unpaid video work, I would not consider using pay software when free and open source versions are available(no matter how buggy, I'd rather patch and workaround than pay), and certainly would not allow a program connected to the Internet to access my raw and unchecked video clips. The free version of Lightworks can't read AVCHD, which small 1080p cameras produce. which means I can't use it even if a later open source release strips out the activation requirement and security issue.
All this means Lightworks in inappropriate for non-monetized video made from security-sensitive clips, and Kdenlive is and will remain inappropriate for high-dollar commercial video in the few countries where MPEG-LA can play their patent games, at least until those patents expire and no new patented codecs arise. They are two different products, written by two different kinds of authors, for two different kinds of users. I was starting to sweat that if too many people abandoned Kdenlive, I would not be able to keep using it myself unless I was able to learn enough about the source code to mantain it myself, which would be a huge undertaking. I've already had to do that with the old Ubuntustudio GTK theme, and that is work enough when new versions of GTK break something.
My main worry was that Lightworks would pull people away from Kdenlive without really offering the same functionality in a free and offline version, but my guess is the separation between users of open-source ffmpeg/avconv and paid "legal" codecs will forcibly separate these userbases until H264 dies online and the last AVCHD camera dies of electromigration, or until the codec patents expire, whichever comes first. I would like to see Kdenlive pick up Shotcut's work in making openGL playback really work, and that direct shader language GPU compute, both of which are not in the MLT backend that Shotcut and Kdenlive both use. If that gets fully debugged, and Kdenlive gains the ability to play back a timeline full of night-camera color correction in full real time, that will be all I will ever need. GPU render would be nice, but some say only the Mercury engine, using the GPU for everything, can avoid giving back the gains in system ram/video ram memory transfers.
For that matter, I ran an experiment last year benchmarking an nvidia GTS450 with the blob (blacklisted against encryption password entries while X was running!) against AMD bulldozer FX-8150 overclocked to 4.5 GHX, using Blender from PPA on the "cycles" rendering engine. That uses openCL, and at that time would detect and use that GPU if asked. Only thing was, that FX-8150 beat the NvidiaGTS450 by a substantial margin, 20% at least, in identical openCL Cycles render tests of that huge auto dealer floor raytraced image. I now use an AMD HD6750 with Mesa (more trustworthy for my purpose), giving 60-70% of theoretical openGL performance.
On this kind of system, I wonder if Lightworks would be able to use the Mesa driver, and if so, would using it be enough to outrun the 8-core CPU for rendering anyway? If not, than Kdenlive needs only to get effects to play back in real time to be a "finished" video editor so far as I am concerned. Don't like the theme? Think it looks "unprofessional?" You can change it. I theme it to match my old-style "Ubuntustudio-legacy" GTK theme. I've got a screnshot of Lightworks running, I could probably make Kdenlive look like it if I had any reason to do so,.
Comment