Introducing Shotcut, a new free video editor

Dan Dennedy is returning to development of a Kino-like video editor after several years of hiatus. The new project is called Shotcut.

Shotcut is currently at a very early stage of development. It is based on the MLT framework, created by Dan in 2004 in collaboration with Charlie Yates, another former Kino developer.

Until few days ago the application didn’t do much beyond simple playback with trimming controls, but now Shotcut has capturing, encoding and streaming.

Since Shotcut relies on MLT, it can use several capture sources, available via File / Open other… menu command:

• Blackmagic DeckLink SDI / Intensity HDMI devices;
• Video4Linux devices;
• network video stream;
• various generators (noise, plasma etc.).

You can encode the data to a video file, using presets or custom preferences. There’s also batch encoding in place with pretty much all job controls: pausing, stopping etc.

You can also stream the data over UDP. That is, in the future you’d be able to fetch network video stream, process it and stream it yourself:

That really isn’t all that’s in the works. Two major features currently being worked on are a GLSL-based processing framework (under branch review) and generic property animation (in design).

The list of planned features also includes transport control, frei0r plug-ins support, JACK transport sync etc.

How did that happen in the world of Kdenlive, OpenShot, Novacut and yet-to-be-delivered Lightworks? Let’s go back in history first.

What happened to Kino

For a long, long time Kino used to be the only viable free option on Linux for dealing with DV files and quite possibly the first video editor on Linux to feature support for jog/shuttle controllers.

In 2007 however, Dan Dennedy announced that he was stopping its active development:

I am done working on it. Well, mostly. I am done working on the functionality. To some, a 1.0 release is the dawn of a new era — where work towards the next major release begins that often involves re-design, re-engineering, and re-factoring.

I am not saying that work towards another major release will not ever happen with myself as the lead developer and maintainer. However, I do not plan to for at least a year.

Nevertheless, Dan released Kino 1.1.0 and 1.2.0 later same year, then 1.3.0 in 2008 and eventually stopped at v1.3.4 in September 2009.

Instead of Kino he got heavily involved with Kdenlive development where he wrote quite a lot of code including production critical features such as support for Blackmagic Design SDI and HDMI devices. He also helped maintaining frei0r effects, as well as various other bits of the video stack in Linux.

So why Shotcut and what’s the appeal?

LGW asked Dan about the reasons to start yet another video editor and his future plans for the project.

Dan, in terms of look and feel Shotcut strongly resembles Kino. Why did you return to this kind of a project after all these years?

Basically, I missed the type of work I did with Kino (GUI app, not just libs), and I want to give the world an open-source, cross-platform video editor. Over the years of working on MLT, a number of people interested in Kdenlive and OpenShot have asked for ports to Windows, but I was unwilling to help for a while.

Then, I helped port Kdenlive to OS X because I had started using OS X regularly through my day job, and I was eager to see it work. However, I became rather disappointed in the results, the effort required for users, and the amount of support (or potential support) it requires.

Then, someone interested in running MLT (or OpenShot?) on Windows submitted a patch to get it somewhat working. I try to welcome all patches because the project does not get a lot of contributions. Plus, my daughters were increasingly using Windows to run software specialized for their interest in the vocaloid scene. Upon evaluating with the patch, I realized MLT on Windows may not be so difficult.

On both a personal level and at work — on Windows, OS X, and Linux — I had been using Qt Creator since its launch, and I really like the cross-platform solution it provides. Initially, I created a very simple Qt project (BuildOnMe) showing how to use MLT to make a player as a template or starter project. Next, I suggested to Kdenlive and OpenShot developers that we should all collaborate around a new, cross-platform project, but no one expressed an interest in that.

Meanwhile, some customers and partners using MLT as a server solution (melted broadcast video server or simply melt on a web server) expressed a desire for a cross-platform client. Finally, I realized I could make something pretty amazing without a huge amount of effort because all of the pieces seemed to be in place, and I could see how they fit together.

What kind of users and workflows you are targeting?

The first goal is that users on just about any (desktop) platform can play MLT XML. One can be authoring XML for a server-side processing solution and needs a way to prototype and preview the results without having to continually submit and encoding job to a server and check the result with a media player.

Then, this needs to be extended to include prototyping and previewing encoding parameters as well, and this is nearly ready. I have a goal to provide a MLT cloud-rending/-encoding service named meltymedia.net, but users need a way to preview and prototype that does not require them to be running a Linux desktop.

Next, I will extend it to support melted video server users. Not only will it be a traditional MVCP client for server transport control, but it will be a more efficient way to generate playlists and to monitor the audio/video output of the server because it supports audio/video playback directly within the app.

Lastly, the meltymedia.net users will need a way to learn how to author advanced XML templates that include filters, multiple tracks, and transitions. So, it will expand to be a non-linear editor to help author ready-to-use XML templates much like some web development workflows use a WYSIWYG design tool to hand-off markup to a web app developer.

And the desktop users?

Along the way, the average home user can take advantage of a simple, reliable video tool regardless of which desktop OS they may be using at the time.

Another workflow I am targeting is the developer-user relationship. I want users to be able to report a problem and receive and confirm a fix in a short amount of time and without a huge effort. MLT, OpenShot, and Kdenlive have been fortunate that many of its users are able to build the code themselves to verify a problem on the latest version, test a fix, and get a solution to an immediate hurdle.

However, I know a large number of their users are not capable or simply do not want to bother, and this will only increase as the MLT and Shotcut user base extends to other platforms. On a Linux distribution, packaged versions lag too far behind the head of development. So, I want to provide new versions frequently, and make it easy for people to try the new version to see if it solved a problem.

Why did you go for GLSL instead of the (arguably) more trendy OpenCL?

I asked the contributor (a Kaffeine developer) to look into OpenCL before delving into the work on GPU processing. He did and reported that he gets better performance and compatibility through GLSL! Nevertheless, this work will provide a pattern that could be repeated for future OpenCL support.

How working on the project is likely to affect your participation in Kdenlive’s development?

I have effectively pulled completely out of Kdenlive development, but I still admire the project and support it at the MLT level. I chose not to try to port it to Windows because I do not like the number of dependencies KDE adds. I already feel a sting from the MacPorts experience, and when I think about trying to offer a downloadable app bundle of Kdenlive for OS X… well, I just shudder at the thought of it! Just look at the post-install instructions on kdenlive.org. Why is that necessary just to run an app?

Also, I think most GTK+ users on Linux prefer a non-KDE solution, and OpenShot has been filling that void. However, when considering to port OpenShot, I also shudder at the thought of integrating and maintaining MLT into Python into GTK+ across platforms, and I personally dislike the look and feel of GTK+ apps on OS X and Windows.

I am the one doing the majority of the cross-platform work, Qt provides just the right amount of platform abstraction without adding too much bloat, Qt looks and feels decent enough on just about any desktop environment, and Qt Creator is my preferred tool that works the same regardless which OS I happen to be working on at the moment. I can only hope people will start to say the same things about Shotcut.

Getting Shotcut

Currently Dan provides nightly builds for 32-bit and 64-bit Linux (Fedora 16/17, Ubuntu 11.10/12.04), OS X (requires at least OS X 10.5) and a build for 32-bit Windows.

Source code is available at Github.