Comments on Novacut

Been some discussion recently about Novacut, a open source non-linear video editor project which is trying to raise some money through kickstarter, a crowd sourcing system.

Personally I think that some of the criticism against Novacut and their effort is fair. It does seem extremely ambitious and it hard to reconcile the money requested and the ambitions of the project. That said I am not as sceptical to the endeavour as some, I even pledged some money to it in fact.

The thing is, a lot of open source projects starts out a bit naive about the challenges ahead of them, and frankly if they had known all the problems facing them when starting out, they would never had succeeded. For instance, if we had known up front it would take us 10 years to get GStreamer to where it is today I don’t think we would have ever started.

The other factor that plays on my mind is that even if they ‘fail’, they might be a great success. The thing is they plan on building Novacut on top of GStreamer and GNonlin, the same foundation as PiTiVi. As part of this process I am sure they will find and fix bugs in GStreamer and GNonlin and they will add new features to GStreamer and GNonlin. So even if ‘Novacut’ itself fails to take off, a lot of the work they will be doing will directly benefit GStreamer applications in general and probably PiTiVi especially. And who knows, even if ‘Novacut the application’ fails to ever reach a useable state, maybe ‘Novacut the idea’ will be alive and kicking inside PiTiVi in a year or two.

One could argue that Novacut should be done as a PiTiVi extension from the beginning, and I might agree, but to me, saying no to Novacut for not being a PiTiVi patch or extension is saying no to something good because you want to wait for something utopian.

Weekend hacking

Spent some time this weekend hacking on Transmageddon. Fixed various small bugs and UI issues that I had punted up until now for the UI. For instance with latest git when you create a pure audio file it doesn’t automatically get the suffix .mp3, which is nice in the cases when you are not creating a mp3 file :) And if you put aac into a quicktime container the file gets named .m4a instead of .mov.

Also started looking into the issue of how to handle multiple audio streams in the file being transcoded. Currently all streams gets transcoded to the same chosen format if the container format support its, if the container only supports 1 audio stream you get one by random. This is not ideal :)

Ended up filing this bug with a request for how we can improve the GStreamer API to make handling such things easier for application developers. Discoverer, uridecodebin and encodebin makes a lot of things a lot easier, but for handling files with multiple streams of the same type I think we still need some improvements.