LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
Leading itemsTen-year timeline part 3: The Tucows yearsThis is the third installment in a ten-year retrospective inspired by LWN's tenth anniversary; those who have not yet seen them may want to have a look at Part 1 and Part 2. At the end of the second part, LWN had just emerged from the peak of the dotcom bubble having made a deal with Tucows. For almost two years we operated as a part of that company; here's some highlights from that time.
Needless to say, by this time we were happy to have found a relatively stable place to be - times were starting to look a little tough. Between the end of the Linuxcare IPO - once supposed to be the biggest and best of them all - and the fact that other Linux companies had fallen below their initial prices, it seemed that the honeymoon was pretty well over. By this time, LWN's revenue stream from advertising had pretty well dried up too. Red Hat's embedded business is a classic case of a lost opportunity. The acquisition of Cygnus should have placed Red Hat in a strong position in this sector, but, somehow, it all slipped away.
One might think it cynical and mean-spirited to point out that we're still waiting for Wine 1.0. But we'll do it anyway. The memory management issues with 2.4 were to be with us for some time, as it turned out.
Given that the 2.4.0 release was far overdue, one would think that arguments over whether a completely new filesystem should be added would be considered out of place. But they did happen, with Hans Reiser showing a level of anger and paranoia that put much of the community off of dealing with him for years. It is rare that kernel developers are accused of putting corporate interests above those of the kernel as a whole, but that happened here. It is actually worth reflecting on this a bit: kernel developers work for roughly 200 companies, many of which are direct competitors. But that competition has remained almost entirely absent from the development process. We are very good at developing common resources in a highly collaborative way while competing at different levels.
Something which was widely understood, but little talked about, during this time was the great amount of effort VA Linux put into recruiting projects to SourceForge. It was a clear effort to become the home for as much software as possible. Quite a few prominent projects moved over with great fanfare, only to drift away more quietly later on. SourceForge still hosts a great many projects, but it is seen by many now as a home of last resort.
Lest anybody think that the dotcom silliness was truly over by this point, the CueCat story should convince them otherwise. Digital Convergence spent many millions of dollars sending around free barcode scanners on the idea that people would want to swipe codes from advertisements and be taken to the associated web site. This company considered using the scanner for any other purpose to be a violation of the DMCA, and made loud threats at people distributing drivers which enabled such uses. The company's threats came to nothing, but they foreshadowed the DMCA follies to come.
The Red Hat Network was the core of what was to become the subscription services which support the company so nicely now. Back then, though, that outcome still was not clear, and Red Hat continued to experiment with a number of business ideas.
Many people had begun to worry that 2.4.0 would never come. The story of the development of this kernel, though, was not done yet.
By this point, things were looking downright scary. During the bubble days, almost anybody who wanted to work in free software development could get a job somewhere. By this point, though, quite a few people were without jobs and some of them were leaving the community altogether. The Stanford Checker was a GCC derivative which could do static analysis; for many, it was the first real demonstration of what that kind of tool could do. Despite some early reassurances, this code was never released; instead, it was used to found Coverity. The community has benefited strongly from Coverity's work, but imagine what we could have done with the source to the Checker. It is a little sad that we have been unable to develop similar capabilities in free software.
The threats against Ed Felten - who had participated on a contest put on by SDMI proponents - were a strong signal that, in the U.S., the DMCA could bite developers hard. Worse was to come, though. Meanwhile, Eric Raymond's attempts to "hack" a rather unimpressed kernel community provided a steady stream of comic relief.
Your editor has said previously that Eazel's plan never seemed (to him) to make sense; the investors finally came to the same conclusion and pulled the plug. Another plan which did not make sense was what had happened to MandrakeSoft: outside managers placed in the company by its venture capitalists had decide that Mandrake should be an e-learning company - not exactly its area of core expertise. That strategy just about destroyed MandrakeSoft before the decision to go back to its distributor roots was made. The company has taken many years to recover from that mistake.
In these difficult days, the fact that Red Hat could produce a profit - even a tiny one - offered a ray of hope. The failure of VA Linux to make it in the hardware business was a sobering counterexample, though, given that VA was once the most prominent company selling Linux-installed systems.
More than anything else, the arrest of Dmitry was a wakeup call for the community. It seemed that, in the U.S., any developer could be arrested for interfering with the business plans of large companies. As a result of this action, some developers still refuse to travel to the U.S.
We still miss Liz - but she remains a good friend.
Few people remember September, 2001, as one of their favorite months. Beyond the terrible events occurring in the wider world, the problems in the commercial Linux sector just seemed to get steadily worse. The 2.4.10 kernel release is an important point as well. Here is where the longstanding memory-management problems came to a crux; Linus responded by ripping out the 2.4.9 VM code and replacing it with a completely different implementation. What followed may be the closest we ever came to a fork in the Linux development process. Some distributors stayed with 2.4.9 for a long time - RHEL 2 systems (still supported by Red Hat) are still running a kernel which, at least, claims to be 2.4.9. The worst passed, however, and this is the point at which 2.4 started toward something resembling stability.
Tucows, which had not been helped by having launched a major new offering on September 11, laid off a number of people, including Michael. His desktop columns had been a welcome addition to LWN, and his departure was a big loss.
Initially the Mandrake Club was meant to function as a sort of tip jar. As financial problems at MandrakeSoft got worse, though, it became the storefront through which the Mandrake distribution was sold. Not everybody liked how the Club was run, but it doubtless helped MandrakeSoft to survive into the present.
The indictment of Mr. Johansen made it clear that DMCA-like problems were not limited to the USA. Meanwhile, by this time, Tucows had come to terms with the fact that its acquisition (and ongoing operation) of LWN was not helping it, given the directions its business was taking. So, after some discussion, LWN was unacquired - it was given back to its creators, with Tucows holding on to a small piece just in case. The parting was on the best of terms; it revalidated our decision to go with Tucows in the first place. But, after almost two years, it was time for LWN to venture back out into a scary world as an independent business. That was the beginning of a new phase, with its own ups and downs, which will be discussed in the next installment.
The Grumpy Editor's video journey part 2: Video editorsIn the first installment in this series, your editor took on the task of getting video data onto his system in digital form. Part 3 talked about authoring DVDs with the nicely edited versions of those video clips. Now it's time to fill in the missing second part, wherein your editor turns raw captured video into something suitable for DVD creation.The task to be accomplished is relatively simple: for each video clip, trim off the extra junk at the beginning and the end. Some of them also require internal editing; there were signs of operator error in the form of, say, extended sequences where the sole subject matter was the floor and, perhaps, the cinematographer's shoe. Nice transitions between the clips were desired - a basic fade to black at the end, if nothing else. The addition of titles is useful. And, as an added bonus, the video clips needed to be deinterlaced before being written in a form suitable for passing to the dvdauthor utility. In the process, your editor encountered several tools in varying states of readiness. He has become better acquainted than ever with the notion of "build hell." A rather more than passing acquaintance with the behavior of the out-of-memory killer in 2.6.24-rc kernels has also been achieved. And, at the end, your editor believes he has a reasonable sense of the state of the art in Linux video editing.
Avidemux
For example, Avidemux handles DVD-style MPEG2 files without trouble. But a reader who digs far enough into the documentation (which is extensive and useful, incidentally) finds a warning that one must exercise the "build VBR time map" option, or audio and video will become unsynchronized in the final product. This operation is nearly instantaneous on a five-minute clip; given the problems which can result from not doing it, why does Avidemux not just build this "time map" when the file is loaded? Why set a trap like that for your users? The actual video editing operations are quite simple. Avidemux can only handle a single video clip, and that clip has a single set of begin/end points. It is possible to delete from the middle of a clip using those endpoints; deletion is instantaneous and leaves no sign on the timeline. There is no "undo" operation, but there is an option to dump all changes made to the file. There is a scrollbar which enables quick movement through the clip; the arrow keys move by single frames. In general, the interface is responsive on your editor's machine.
A fade-to-black ending was achieved with another filter. It works beautifully, if one does not mind that (1) there is no choice of what to fade to beyond a "fade to black" toggle, (2) the portion of the clip to be affected must be identified by typing in frame numbers, and (3) those frame numbers are not adjusted should somebody, say, delete some video from an earlier part in the clip. The capability is there, but the interface needs some work. Other filters allow cropping, mirroring, color modifications, noise removal, sharpening, blurring, addition of subtitles, the addition of logos from image files, the creation of animated DVD menus, etc. Should all of those be inadequate, the "swiss army knife" filter is there for more general low-level processing. There is also a scripting interface for Avidemux, though your editor did not attempt to make use of it. The interface allows the user to view the video either before or after the filters have been applied - or both together. The latter mode, though, tends to run slowly, though the post-filter output, by itself, worked just fine. In the end, saving the file out as a DVD "video object" does the job - though one has to assume that the rather spartan "save" dialog will do that. Like most (but not all) video editors, Avidemux does not actually change the video data until told to render a new file. The list of edits, filters, etc. can be saved as a "project" file (an Avidemux script, really) so an editing session can be resumed at a future point using the original material. The bottom line is that Avidemux is a capable and reasonably solid tool - your editor was not able to make it crash. Its long list of filters will be appealing to some users. Its inability to work with more than one clip at a time will rule it out for many others, though. Like so many other tools in this category, it's almost there.
Cinelerra
There are some good documents for Cinelerra, but, reading them, one starts to encounter certain themes. For example:
Cinelerra is not perfect. Before long you will be familiar with
the tendency it has to crash
Or this one:
Quicktime is not the standard for UNIX but we use it because it's
well documented. All of the Quicktime movies on the internet are
compressed. Cinelerra doesn't support most compressed Quicktime
movies but does support some. If it crashes when loading a
Quicktime movie, that means the format probably wasn't supported.
Cinelerra is by far the most complex - and capable - of the tools available for Linux. If you are looking for an editor designed for the creation of complicated video with lots of effects, Cinelerra is the tool for you. Unfortunately, Cinelerra does not appear to have a development community which is up to the maintenance of a tool of this size. So it is difficult to work with and not particularly robust. At startup, Cinelerra puts up four individual windows. The "timeline" shows all of the tracks being edited, and is the place where much work actually gets done. There are two video windows; one displays the current state of the timeline, while the other can be used to look at individual clips outside of the timeline. Then the "resources" window holds everything else. The timeline display is quite nice. Video thumbnails along the line give a rough sense of what is happening in each clip. The display of audio levels is also highly useful when one is trying to find specific events; it would be nice if other tools picked up this idea. A number of editing operations can be performed directly on the timeline; each track, for example, has a horizontal line which can be manipulated to adjust the (audio or video) levels at any given point. So a fade-to-black, for example, is a simple matter of ramping the video level down at the right place. For more complex operations, there is a large list of effects which can be applied. These effects show up on the timeline next to the tracks they operate on; their end points can easily be dragged around. Cinelerra will attempt to render effects when the timeline is being played, but that tends to slow the program (not the fastest tool to begin with) to a point where it cannot keep up with normal video rates. Cinelerra does not modify any data until told to render the project. It cannot create DVD video objects directly; one must render audio and video separately, then multiplex them outside of the program. The edit list can be saved separately. There is a whole host of features in Cinelerra not found anywhere else. For example, it can be used to drive a rendering farm for those big production jobs. There is a motion tracking subsystem built into it ("The intricacies of motion tracking are enough to sustain entire companies and build careers around"). There's a set of options for audio and video capture. And so on. But your editor could never get all that far with Cinelerra before it ran the system out of memory. One does, indeed, become familiar with its tendency to crash, but it's especially annoying when it takes the rest of the system down with it. Cinelerra should really be one of the star applications in the free software world. It has a great deal of power and can do amazing things; it could be a professional-quality tool. What it needs is for the community to truly take charge of the "community version" and turn it into a system which is fast, robust, and easier to use. To that end, it would help if the two people on the planet who can succeed in actually building this system would clean up that process and, in general, make Cinelerra more welcoming to new developers. The foundation for a great video editor is here, but there is a lot of finishing work to be done.
Kdenlive
Of course, even after solving that problem, your editor was not able to build this tool. Fortunately, Ubuntu ships it, so that is the version which was used here. The initial Kdenlive experience is a little rough; it asks for a set of default parameters. How is one to choose between, say, "CIF NTSC" or "DV NTSC" or "DV NTSC Widescreen"? There is no help on offer to guide the user toward the right choice. Once past that, the user sees a window with three major panes which offer functionality similar to that available from Cinelerra. The first step is to bring one or more video clips into the "project tree," which is (usually) visible in the upper left pane. These clips can be viewed in the "clip monitor" on the right. A clip of interest can then be dragged down to the timeline area, where it can be easily positioned relative to any others which are already there. Kdenlive uses the "divide and conquer" editing method. To remove a section of a clip, the user positions to one end of that section, then selects "razor" to split the clip in two at that point. Another split at the other end isolates the section to be removed, which can then be deleted with a separate operation. There is (with the exception of transitions) no way to apply an operation to a part of a clip - the area of interest must always be razored out first. As a result, the fade-to-black effect is not quite as easily achieved in Kdenlive as with some other tools. There is a "brightness" effect, but it changes the brightness to a constant value through the entire clip. The way to fade out a scene is to add a new clip with a solid color (easily done in Kdenlive), then use a crossfade transition to join the two clips together. Transitions are added by selecting the first track and, via the right-button menu, selecting the desired transition. Various parameters (such as the time required for the transition) can then be tweaked. It all works easily; Kdenlive is a fun tool for quickly piecing together different bits of video into a coherent whole. There are separate video windows for displaying individual clips and the timeline as a whole; by default, they cannot both be viewed at the same time. Playback is responsive. It's a little more awkward than with some tools, though: the position cursor is small and hard to grab, and there is a shortage of keyboard shortcuts for moving around. The timeline is less informative and less functional than Cinelerra's, but the information one really needs is there. When the project is done, there is a nice "export to DVD" option there to do the rest of the work. Kdenlive can create the video object files and fire up Qdvdauthor to do the rest, or it can create a basic, single-title DVD internally and (using k3b) burn it to a disc. Your editor, thus, should have mentioned Kdenlive in the DVD authoring article, but he was unaware of this feature at that time. It all works easily; your editor was able to make a playable DVD with minimal trouble. It was not the most beautiful DVD, though, because Kdenlive has no deinterlacing capability. Those of us unlucky enough to be starting with interlaced video must handle that operation separately, before or after the editing process. While any of the editors discussed here could conceivably work with high-definition video, Kdenlive is the only one which appears to have been written with that in mind. Projects can be set up in HD formats without undue tweaking. Your editor was not in a position to test this capability, though. All told, Kdenlive comes across as one of the most finished of the free editing tools. It is relatively straightforward to use and it has all of the features that most people are likely to need. For many applications, this could well be the first tool to reach for.
Kino
Kino only works with a single video format - the digital video (DV) format associated with contemporary camcorders. When started with something else (say, your editor's MPEG files from the capture card), it will offer to convert the file into DV. This process works, but the result is a significant (5-10x) increase in the size of the file. There is no timeline in Kino; instead, it has a "storyboard" in the leftmost pane. Each video clip becomes a separate scene in the storyboard, with each being played strictly before the one after it. Like Kdenlive, Kino works by dividing clips and applying operations to the pieces. So trimming video is done by "splitting" the scene into wanted and unwanted parts, then deleting the latter. The documents make much of the "powerful" three-point trim feature, but your editor doesn't get it; it just seems like a way to set the beginning and ending split points on the same screen, but the amount of work remains the same. Moving within clips is quick and easy in Kino. There is also a scrollbar-based "jog wheel" for variable-speed motion in either direction. What your editor really likes, though, are the keyboard shortcuts, including vi-style bindings for moving, frame-by-frame, through the material. It makes finding the exact spot to make a cut a quick affair. Kino offers a reasonable set of effects, though the interface and implementation are awkward. Most effects apply to a full scene, so the normal mode of operation is to split scenes where an effect is to be placed. There is an option to "limit" an effect to a period of time at the beginning or end of a scene, though, so something like fade-to-black or a crossfade can be done without making new scenes. Or so one would think. Unlike most other editors, Kino does not apply effects at playback time; instead, an effect must be rendered when it is applied to the scene. The result is a new scene (even if the limit option described above is used) which contains the result of a new DV file created by the effect renderer. For good measure, the rendering code places the rendered file (with a name like 001.kinofx.dv) in the user's home directory, which can quickly become cluttered with them. This approach lets Kino display effects without performance problems, but it is a bit messy and inelegant.
By default, the DVD exporter creates the necessary video object file and a simple dvdauthor script for a minimal DVD. There are options, though, to burn the DVD immediately or to go into Qdvdauthor for further work. One might mention here that, like most of the other tools discussed here, Kino does not play nicely with others when it comes to the audio subsystem. Each tool has its own way of responding to contention, though. In this case, if Kino is unable to get exclusive access to the audio device, it shows its displeasure by playing video (silently, of course) at ten times the normal speed. After a while one learns to recognize this particular tantrum, but it still would be nicer if the application would say something like "I'm not willing to share the audio device, can you please stop your music player if you want to play back your video?" Bottom line: Kino is a reasonably capable editor which, after a very short learning period, is quick and fun to use. It may well be the best option for people with relatively simple needs. Those wanting more sophisticated capabilities, though, are likely to see it as an underpowered toy.
LiVES
LiVES is good enough to be used as a VJ tool for professional
performances, and as a video editor is capable of creating dazzling
clips in a wide variety of formats.
Your editor, however, is not a VJ. So his experience with this tool was not the best. The process of importing a video clip into LiVES is slow and disk-intensive. After some investigation, your editor figured out why: LiVES works by converting every video frame into a separate JPEG image file. The end result is a directory containing tens of thousands of images and a massive expansion in the size of the clip. It also cannot be good for system performance in general; your editor can only suggest that using a filesystem with indexed directories would be a good idea. LiVES is one of those applications with such a sense of its own importance that it comes up maximized from the outset. The interface reconfigures itself on the fly depending on what operations are selected - in particular, video display windows come and go in a frequent and distracting manner. The default directory for video files in /usr/local. Cross-fading one clip into another works, but it loses the synchronization with the audio. Many tasks are done by running external programs; should that program fail, LiVES will tell the user, but it does not pass on the information provided by that program. So figuring out why things fail is a matter of digging through debug and strace output. Somewhere in this process, your editor decided that, while LiVES may indeed make VJs happy, it is not a serious editing tool for the rest of us. There is the potential for some nice features there, but this application needs a lot of work before it will be ready for general use.
PiTiVi
This application, too, was a bit of a challenge to get going. It has various dependencies not accounted for in its configure script, including some strange ones: why does a video editor need to import Zope modules? Still, your editor had better luck here than with some of the alternatives. The good news is that, despite its Python implementation, PiTiVi is responsive when moving around in video clips. On the other hand, moving around in clips is really about all that PiTiVi can do at this point. There is a rudimentary timeline display which does not do anything, and no editing options are available. So PiTiVi, while being a promising start, is not really an editor at this time.
ConclusionWorth mentioning in passing: the Open Movie Editor looks like a tool with some promise. It disliked your editor's video files, though, claiming that it only supports files with a 25 frames/second rate. Your editor, deep in NTSC country, has no such files. Hopefully, as this project matures, it will achieve the generality this kind of tool must have. The free software community can be aggravating sometimes. We clearly have the ability and the desire to create top-quality tools for tasks like video editing. But what we get is a half dozen tools, none of which is a complete solution to the problem. Your editor would be the first to say that competition between projects can be a good thing, inspiring everybody involved to push harder and achieve more. But, still, maybe having fewer competing tools might just help people to work together and make tools which are truly great. That said, the state of the art in Linux video editing is not as bad as one might think. The tools are there to put together a decent video without a great deal of trouble. As mentioned above, Kdenlive is arguably the most polished of these tools, with Kino also being a good candidate for simpler applications. And Cinelerra remains in its position as the application that is going to be truly spectacular, once all of those loose ends finally get tied up. Your editor once heard Lawrence Lessig say that text is like Latin for younger people today, and that video is the preferred way to communicate. If that is true, then we want to make it possible to communicate as richly as possible while using free tools. We have a good base to build on, and many smart people have solved many of the hardest problems. Finishing the job is well within our capabilities.
linux.conf.au starts January 28LWN editor Jonathan Corbet is pleased to be heading back to Australia for his fourth visit to linux.conf.au. Beyond the pleasure of attending one of the best free software events on the planet and meeting LWN readers, there will be the simple joy of going somewhere where the temperature is above freezing. But most pleasing is the opportunity to speak at linux.conf.au on January 30 - they day we have designated as the tenth anniversary of LWN. It will be a celebration for sure.
Stay tuned to LWN for reports from the event as it unfolds.
Page editor: Jonathan Corbet |
|||||||||||||
![[Avidemux]](/images/ns/grumpy/vedit/avidemux-sm.png)
![[after]](/images/ns/grumpy/vedit/avidemux-int-after.png)
![[Cinelerra]](/images/ns/grumpy/vedit/cinelerra-sm.png)
![[Kdenlive]](/images/ns/grumpy/vedit/kdenlive-sm.png)
![[Kino]](/images/ns/grumpy/vedit/kino-edit-sm.png)
![[LiVES]](/images/ns/grumpy/vedit/lives-sm.png)
![[PiTiVi]](/images/ns/grumpy/vedit/pitivi-sm.png)