Lightworks – Now, A Professional Video Editor For GNU/Linux

Responding to some dolt grumbling about the lack of a “professional” video editor in GNU/Linux, I checked Lightworks out on a machine on my LAN with an Nvidia chipset and 64bit VGA. Believe it or not, I have two of these and one is actually working. The installation was flawless on Debian Wheezy. Debian had all the dependencies in house. I write this blog from Beast which uses ATI graphics so these screenshots are via SSH from Beast over the LAN… Lightworks did not like to be installed in a virtual machine but I can work around that thanks to X window system. Cool, eh? Now, all I need is some video… 😉

See Lightworks Downloads.

See also, Thelma Schoonmaker, on Wikipedia.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , , . Bookmark the permalink.

25 Responses to Lightworks – Now, A Professional Video Editor For GNU/Linux

  1. oiaohm says:

    By the way the Avid solution on IRIX to the X11 problem was just lock full screen and use OpenGL Direct Rendering to basically bi-pass X11 and write a texture straight to screen. So it was not a user friendly solution. Also IRIX scheduler could bias cpu time to the dominate application the advantage of only shipping on hardware that video card drivers were not black boxes. So your example DrLoser of Avid or IRIX is someone using Google who had no clue that IRIX number one was not sysvinit as such and also really was bypassing X11 not working with X11.

    The reality here for desktop usage we really don’t want a complete fair scheduler. The scheduler need to be able to find out what applications have active windows and what applications have active audio connections and bias cpu time in to those applications for desktop usage. Tranditional X11 does not help. DRI3 helps a little dma-buf entries in kernel space you can work out what applications have an active rendering window.

    KDBUS idea also plays into allowing the scheduler to have better information to make selections over cpu time.

    There are a lot of things with Linux where the scheduler just cannot get enough information to make the right selections for desktop usage.

  2. oiaohm says:

    DrLoser I already answered what SGI IRIX was using instead of cgroups.

    Instead of cgroups as systemd and linux sheduler uses the SGI IRIX init and scheduler uses console connections to group processes
    Its the next sentence you did not read. So IRIX was doing something like what cgroups does now for Linux. Two different methods to skin the cat leading to the same kind of result. cgroups are control groups and console groups both are ways to group processes into manageable blocks.

    SGI IRIX 4D1-4.0 manual from 1991 covers how the init system works it is in google books by the way. This release is not pure sysvinit it always used a variation that was console grouped. The standard sysvinit starting script is missing replaced with a binary.

    Until you have something properly grouping processes you are in trouble scheduling.

    Sorry DrLoser you brought in a OS that an example of sysvinit compadible init system but not a sysvinit init system.

  3. DrLoser says:

    I’m going to make this really, really, really simple for you, oiaohm.

    SGI IRIX DrLoser was on of the first to stop using pure sysvinit.

    1) When? Give us a cite.
    2) Did it involve anything like Systemd? Or cgroups?
    3) Does your tin-foil hat need an MOT?

    Oh, and as a bonus, you missed out that X-Windows stuff that any normal, sane human being with even the faintest knowledge of the last twenty years of *nix development would assume was a part of the SGI/IRIX/Avid toolkit.

    I repeat.

    It was obviously possible to produce a professional standard video editing suite on a POSIX platform in 1995.

    Apparently, in 2014, there are certain little local difficulties, possibly to do with cgroups, possibly to do with the deficiencies of the Linux kernel (which, I hardly need to point out, is not the same as the Irix kernel).

    Alternatively? These so-called free video editing suites just aren’t worth spit.

    Your choice, oiaohm. You will never, in your entire life, need to use one of them, any more than I will.

    But do blather on. It’s no doubt educational, from the point of view of somebody who studies aberrant psychology.

  4. oiaohm says:

    The reason why lightworks free is crippled is known. kurkosdr last year they were open up all the import options at a cost export options. Now its working threw what export options they can re enable. Please note 720p Mpeg4 was not possible back in 2013 in the free version.

    Lightworks free is currently crippled by the legal process. Part of the legal process for releasing the source code.

    kurkosdr its not easy to open source a program like Lightworks and it takes lots of time with lots is of upset users and lots legal arguments.

  5. oiaohm says:

    SGI IRIX DrLoser was on of the first to stop using pure sysvinit. Instead of cgroups as systemd and linux sheduler uses the SGI IRIX init and scheduler uses console connections to group processes. So a lot of /dev/console 2>&1 stuff in SGI IRIX init system that triggers a new console group. This allowed SGI IRIX scheduler to pull of the same kind of balancing that systemd with cgroups allows today. SGI IRIX course that method has weaknesses that processes to disconnect self from console and become lost. Yes that change was done to SGI IRIX before 1995. SGI IRIX was the first to implement the bypasses on X11 as well. Yes the high performing graphical workstations Unix based that existed before Linux were not using pure sysvinit.

    Solaris SMF uses zones instead of cgroups in their scheduler or basically the same as systemd.

    BSD implements improved process tracking and a different init system. The difference is the BSD init system binary individually starts each service based on /etc/rc.conf so now each service is a nice independent manageable entity information for the scheduler.

    Launchd OS X again very like the BSD init system where where each service is started directly from the init process so making the schedulers job simple.

    Now what does sysvinit do that is so wrong. shell start script that then shell starts other scripts and merges other scripts leading to a huge confusing mess for the poor scheduler to deal with particularly when you get initscript starting other services directly.

    Linux distributions have been the last poor suckers using sysvinit. Most Unix/Posix related OS’s had stopped using pure sysvinit by 1992 or never had used it. Yes prior to 1992 SGI IRIX had stopped using pure sysvinit.

    Solaris/Sun OS for example used BSD init followed by SMF never used sysvinit so never got infected with its issues.

    DrLoser why I was not exact about cgroup is I was not biasing things. Upstart did result in Ubuntu performing a little better than pure sysvinit but lots of old issues remained.

    Yes DrLoser there are other ways to implement giving the kernel scheduler more information to make more correct selections without using cgroups. Implementing those methods properly equals killing off sysvinit. No matter what the kernel scheduler has to be given clean usable information of some form. Cgroups, Zones, Sane starting of services none of these exist in sysvinit. So I will be really happy to be able to look back at sysvinit as nothing more than a horible memory.

  6. kurkosdr wrote, ” the whole “we ‘ll open source it” promise was a publicity stunt for their linux version.”

    You have no basis for that. The latest pronouncement:“The current position can be found in FAQ:
    “Once the Linux and Mac versions are released the source code of Lightworks will become available. We cannot give a date when this will happen, but announcements and updates will be regularly posted on the Lightworks Forum.””

    GNU/Linux and MacOS versions are still in beta-testing but the GNU/Linux version is getting there, because the betas for that other OS and GNU/Linux are being released together finally. Version 12 is in the pipes.

  7. kurkosdr says:


    They could have released a Student version or whatever which would fall between the free and premium version in terms of capabilites, which would have all the export options PowerDirector 12 offers and wouldn’t have the premium-only features, and sell that student version at a significantly lower price than 99$. Essentially, a version that is the same as Free but with DVD (unencrypted), AVCHD and Bluray export options (and maybe Mpeg4 1080p).

    That is, IF they wanted Lightworks to be usable in it’s non-Premium version.

    The truth is, the Free version is crippleware so you ‘ll pay up for the premium version.

    Oh, and where did I say Lightworks won’t have a Linux version? My dear lying friend? I clearly remember saying Lightworks will have a closed-source Linux version, and the whole “we ‘ll open source it” promise was a publicity stunt for their linux version.

  8. DrLoser says:

    Incidentally, Avid shipped their professional-standard video editing software on SGI IRIX as early as 1995. At which point, I presume, they had already worked out a way around these awful X-Server and Sysvinit problems.

    Or could it just be that the current selection of free video editors on Linux … just aren’t very good at their job?

  9. DrLoser says:

    This “systemd vs sysvinit” throwaway comment, oiaohm. I presume you are referring to cgroups, which is one of your select group of pet projects. (Naturally, you failed to make your “reasoning” specific enough to tell.)

    If not, then what? What is this magic “kernel information” that is exposed via systemd but not through sysvinit?

  10. oiaohm says:

    kurkosdr lightworks pro includes regional coding on dvd and blu-ray copy-protection options. This is a different level to Cyberlink PowerDirector. You are not comparing like with like. 1080p for Mpeg4 does use a item that is patented disputed. Encoding upto 720p is supported by Mpegla as being patent free they Mpegla the patent pool will not give a clearance for 1080p. So kurkosdr take it up with Mpegla the patent pool group of mpeg.

    kurkosdr Please go read lightworks techspecs you will notice it also has a lot more export formats than power-director as well.

    Why no option to install own codecs. Have you not notices most of the other free and paid programs don’t either. Its part of an annoying patent agreement you get to decode particular formats for free as long as you agree not to allow third party encoding for free. About the only way lightworks will be able to allow this would be disable a few import options.

    Sorry you arguement against lightworks is flawed. At first you said their would be no Linux version kurkosdr. There is now an official Linux version. If you note by the road map 2012 order and that is still current

    We are currently in stage 3 of the Lightworks migration process. OS X version is almost baked. Once that is done they then can focus on legal audit of source code base for release.

  11. That Exploit Guy says:

    @ That lying little scumbag called “Ohio Ham” or something
    You sure have the galls still showing up here, even after you have been thoroughly exposed as being full of it:

  12. kurkosdr says:

    When I said “there is no reason for LightWorks to not do DVD, AVCHD and Mpeg4 1080p”, I meant for the cost of just the cost of patents, which is not as much as you think.

  13. kurkosdr says:

    “Editshare makes nothing out of the 99 dollar license sorry they don’t make premuim versions of the codecs some are in fact just ffmpeg. Why so expensive its the patent licensing.”

    Yeah riiiight… 99 dollars for patents. Never mind that Cyberlink will sell you a copy of PowerDirector 12 Ultra which exports to DVD (Mpeg2) AVCHD and Bluray (mpeg 4 avc) for 65 bucks. This includes the whole software. Guess they make a 34 dollar loss on every copy sold…

    So, there is no reason for the free version of LightWorks to not do DVD, AVCHD and Mpeg4 1080p. Also, they do Youtube 720p but not Youtube 1080p.

    Oh, and why they won’t offer you the ability to install your own codecs as plug-ins for the free version? So you can load up ffmpeg, x264 or whatever. If they are using ffmpeg, it should be easy. I am sure you can dream up an excuse for that too. Unfortunately all the fun will be spoiled by the fact it will be a wall of text of incomprehensible english.

    You guys just want to believe, right? As I ‘ve said before, forget about an open-source lightworks, better look out for openshot, which is a real open-source project and not a PR stunt.

  14. oiaohm says:

    Robert Pogson X11 on video syncing is mostly working by bipasses. Not working because X11 of it but in spite of it

    sysvinit has to die due to lack of proper tracking information to the scheduler.

    Yes there have been distributions designed for audio that have managed to make sysvinit work but add a extra service or two and audio issues can start happening.

    scheduler in the Linux kernel is good enough but is lack of information from sysvinit has been getting in way for the scheduler to make correct selections on what can be delayed and what needs the cpu now.

    A lot of those custom audio distributions different to a generic distribution should be able to die out replacement with systemd tuning on generic distributions.

    Robert Pogson the fact we have required custom distributions for audio and video is the bug caused by sysvinit. So working audio everywhere in Linux is sysvinit and upstart dead.

    X11 results in some horible backend code yes lightworks has worked around this so has everyone else doing video applications using X11. Wayland results in cleaner code. Cleaner code simpler to debug less causes for strange errors.

  15. oiaohm wrote, “Both X11 and sysvinit have to die to allow proper audio/video syncing.”

    I disagree. X11 is no problem for syncing if latency is small. With the fast CPUs/busses/RAM and video interfaces of today, that’s not a problem. In my home I have CPUs from 1.6gHz to 2.5gHz and only the 1.6gHz Atom system has any problems with sync. The fact that Lightworks is now ported to GNU/Linux confirms that. Those guys never would have gone to GNU/Linux if X11 was a huge problem. Sysvinit hasn’t much to do with it either. The Linux shedulers have all the flexibility needed to keep things synched. I agree that systemd is more intelligent in that front but the raw power of Linux is good enough for most consumers. There are distros designed for great audio and they’ve used X11 and sysvinit with no problems. e.g.

  16. oiaohm says:

    kurkosdr you idea 1 is bogus. Editshare makes nothing out of the 99 dollar license sorry they don’t make premuim versions of the codecs some are in fact just ffmpeg. Why so expensive its the patent licensing. You use all open source and the patent holders can still come over your shoulder and ask for the money anyhow.

    Your idea 2 is so far wrong its not funny kurkosdr.

    Lightworks has always had SDK for building your own controller interface. Competing peripherals has always been possible with Lightworks. If you have every used the Lightworks console its a little hard to make a Competing version not when you consider two points.
    Point 1) Lightworks console comes with 10 years replacement/repair on any switch failure caused by normal usage. Key word normal usage they don’t cover hitting it with hammer or poring coffee over it but otherwise its covered. Yes it is a high grade mechanical device.

    Point 2: The link above is someone working on a competing device out of generic off the shelf parts yes looks like crap and it costs about 500 dollars in parts and is lower grade quality with lower result-ion than the true lightworks one.

    Ok what is the advantage of using the true lightworks controller lot higher resultion controller so faster to get editing done and absolutely no dead spots in the controller. QA costs money. Yes 500 dollar for the parts add on a few rejects due to quality control issues and you very quickly get up to the 3000 dollar mark and still have a poorer quality device.

    Editshare when they took over lightworks had the idea they might be able to use their mass production to reduce the controllers cost. Editshare has managed to remove 200 dollars from the Lightwork controllers cost by improved production methods. The main reason Lightworks controllers so expensive every part before assemble are human and machine QA and after assembly is QA again. Parts fail testing before assembly.

    What is the reason why someone will make their own controller instead of using the lightworks one is to use the 1 controller with many products. Yes this is funny the only reason why editshare will hide the lightworks controller interface code is so that competing software cannot use the controller. Basically you have it backwards kurkosdr on the controller its not cloning its preventing competitors from using it. Lot of ways if editshare allowed others to use the controller they could make more money.

    Come on Linux Audio Mess. Before Linux we had the Unix Audio Mess. You say Linux Distributions have not done anything about it but this is completely not true.

    It was agreement between Linux Distributions that have reduced the number of sound servers. Yes they have funded developers to get this far.

    Pulseaudio was build by full time distribution funded development to nuke esound and artsd and many other sound servers out of existence so simplifying the Linux Audio stack compared to the historic Unix Audio stack.

    Sorry your never happened did happen. Do we wish the project had done more yes. In fact companies like redhat, Suse and Canonical are still funding developers to keep on working fixing the audio mess.

    Its a bit like X11 Linux has got horible messes from the Unix and Posix world prior to it.

    Funny as it sounds part of fixing up some of the current audio issues on Linux is fixing up the background services so cpu time can be allocated better. Yes systemd is part about fixing audio issues. The number of things that have to behave to get synced audio and video is quite a lot. Both X11 and sysvinit have to die to allow proper audio/video syncing.

    kurkosdr size of the audio problem on Linux is most likely a lot larger than you dreamed evolving many more parts. I guess you would not have included X11 and sysvinit as related to the audio problems.

  17. dougman says:

    With Bitcoins now, donations are far easier!

    Linux Mint takes in some decent change:

  18. kurkosdr says:

    “That doesn’t make sense for me if they are going to open the code.”

    Bahahaha *cough* *cough*… If they open the source they

    1) will not be able to sell a premium version with the codecs (encoders) users want, because anyone could take the open-source version and bundle it with ffmpeg, xvid, x264, vpxenc etcetera

    2) will not be able to sell their expensive “console” or other peripherals, because everyone could take the open-source version and make a version that works with competing peripherals.

    So, if they do open source lightworks, they are left to selling support and training, which is the business model that allowed linux distros to raise money and fund developers to fix the linux audio mess… oh yeah, that never happened.

  19. oiaohm says:

    Robert Pogson authentication of lightworks will not complete if you don’t have a passable video card. I had fun running lightworks outside a virtual machine because I had cuda for Nvidia parts on debian not installed Same thing authentication failure. Even the open source version will still require to keep a hardware check but it really needs to be a different message.

    Robert Pogson they really need to split the message. Authentication failure message is kinda Lightworks I have failed for some reason and I don’t have a clue.

    I hope as Lightworks get more open source its messages get better.

  20. oiaohm wrote, “You can run it in a virtual machine but you have to have at this stage like a duel video card system and pass one to the virtual machine a decanted”.

    The issue I had was that authentication won’t work in a virtual machine. Lightworks tries to identify the machine upon which it runs. That doesn’t make sense for me if they are going to open the code. Now that I’ve found it runs on my Atomic systems I will be able to play around with it some more. Perhaps I will crank out another video. It has been awhile.

  21. oiaohm says:

    Is there any particular reason for a VM not to treat a GPU in exactly the way it treats any other device?

    DrLoser this is exact evidence you are lacking in knowledge. Because decanted is a valid way for a virtual machine to treat a device.

    Options for handling devices in virtual machines.

    VTd or dedicated option passes full control of the device to the virtual machine. No sharing but it means the OS in the virtual machine can use its native drivers with all the functionally like being the host OS.

    VT-s or the software solution. Depending on how good this is depend on how much functionality is provided. Like in the case of GPU you come up short with no CUDA or OpenCL.

    Finally the new one VT-g multiplexing as good as VT-d on functionality support if you video card supports it but performance and lack of vendor support for advanced features in the video card can be a issue.

    Lightworks does not support intel so VT-g is out. Lightworks depends on Opengl and [CUDA or OpenCL]. The last bit is to make it really clear. No virtual machine software gpu solution supports CUDA or OpenCL. So only current way to run Lightworks in a virtualmachine is VT-d or decanted as I stated in my prior post. Of course this could change if we get better vendor software implementations or better VT-g tech.

    Virtual machines have functionality limits. If Virtual machines did not have functionality limits Linux people would not duel boot to run Windows at times.

  22. DrLoser says:

    Robert Pogson lightworks is very GPU bound. You can run it in a virtual machine but you have to have at this stage like a duel video card system and pass one to the virtual machine a decanted.

    Does anybody have a clue what this means?

    Is there any particular reason for a VM not to treat a GPU in exactly the way it treats any other device?

  23. oiaohm says:

    Robert Pogson lightworks is very GPU bound. You can run it in a virtual machine but you have to have at this stage like a duel video card system and pass one to the virtual machine a decanted.

  24. There’s no doubt that Openshot and several other FLOSS video-editors are easy to use but they lack features/formats/codecs that pros want. Lightworks scales to huge complex projects with multiple cameras. For me, who only occasionally produces a video, Openshot would do fine. The key here is that a pro can use GNU/Linux to do the job and that other OS is non-essential.

  25. Agent_Smith says:

    I don’t know how it works, but my favorite is Openshot. The easiest video editor, for any OS, ever.

Leave a Reply