Kino Video Editor
 
  Kino / dvgrab
Latest News
Download
Features
Requirements
Screen Shots
  Support
User Guide
HOWTOs
FAQ
Mailing Lists
Contributed Code
  Development
Project Vision
Developer Guide
Source Code
Current Developers
Report a Bug
  Community
Success Stories
Discussion
 

Summary
Download Kino 1.0.0



Release Notes

  • New http://blip.tv/ uploading feature for movies and still frames! Watch a screencast for more information.
  • Fixed audio handling on big endian CPU architectures (thanks, Pavel Fedin)
  • Improved generic video import script when using mencoder: faster, no bulky intermediate file, less compatibility problem between mencoder and ffmpeg, and retains interlacing in ITU-R 601 sources
  • Added support for X-Keys Editor USB Jog/Shuttle (thanks, Shawn Rutledge)
  • Added support for Jog/Shuttle to FX (jog wheel and button actions that scrub only--no shuttle ring support)
  • The USB Jog/Shuttle hotplug integration was changed to use udev. The new configure option is --enable-udev-rules-dir, which defaults to $sysconfdir/udev/rules.d/ The following configure options were removed: --enable-hotplug-script-dir, --enable-hotplug-usermap-dir
  • Added private copy of ffmpeg source code for static linking with new configure options: --enable-local-ffmpeg(=yes by default), or --disable-local-ffmpeg NOTE: This option builds a statically linked, kino-specific version of the ffmpeg transcode utility named 'ffmpeg-kino' that is invoked by the Kino import script. ffmpeg-kino contains a bugfix for reading the audio on imported files. However, when --enable-local-ffmpeg=no, then the import script uses the normal ffmpeg found in the PATH.
  • Updated Italian translation
  • bugfixes, of course
NOTE: versions 0.9.4 and 0.9.5 contained a bad configure option to enable a build without the ffmpeg DV video codec. This has been corrected so that --with-libdv-only works correctly.

What is in a release name?

This is the first time Kino has named a release. For those not familiar with
the expression, see what Urban Dictionary has to say.

Well now, you ask, "what is that supposed to mean for Kino?" Basically, it
means that 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.

To some, a 1.0 software release implies a level of interface stability, mainly
in the context of a library. This is more of the situation. Kino 1.0 is
something to build upon in terms of documentation, language translations, and
screencast tutorials. Also, I will still work on critical bug fixes or try to
keep it current with dependencies. I have setup a nice online collaborative site for those willing to
help. It supports different Latin1 languages for those wanting to translate
the user guide.

So, the tongue-in-cheek release name also means if you want to see Kino forge
ahead or in a different direction, then you must fork it. Yes, that's right,
I invite you to fork this code! But, I don't recommend it; it's not the
most beautiful code or architecture. You see, I get feedback that Kino is
not good enough or needs a multitrack timeline with editable effects. Well,
I agree those things are desirable, but Kino was never designed to do that.
In fact, there was very litte thought put into design and architecture, which
limited its capacity. All I have tried to do over the past couple of years was
to turn it into a good basic-level editor. I am confident a useful
intermediate-level Free Software editor is just around the corner.

Am I defeated, as the Urban Dictionary definition #2 describes? Well, yes and
no. I am still happy to work on Kino in its current form, but I want to be
a part of the effort for an intermediate-level editor. I do feel defeated
trying to tackle that alone. There is no good reason Kino has to raise to that
level when there are plenty of other efforts already in progress.

In 2004, Kino co-developer, Charlie Yates, and I created the MLT and Miracle
projects under contract. We were excited with the results in only 6 short
months, and we believed it could be the subsystem for a Kino 2. Charlie went
on to develop two editing GUIs atop it that, at least, proved the concept. In
2006, kdenlive abandoned the piave engine and adopted MLT. I am returning to
work on MLT to support kdenlive since its latest version shows much promise.

Yours truly, Dan Dennedy, lead developer of Kino




| Printer-friendly page |