Dan Dennedy: Kino and MLT Developer
Tuesday, 21 May 2019
Home arrow Categories arrow Kino arrow Kino and tagesschau.de
Main Menu

cross-platform video editor
Media processing framework
Kino and dvgrab
Non-linear DV video editor for Linux
Linux 1394
Firewire drivers for Linux

Syndication Feeds
RSS 2.0 Feed

Dan Dennedy's Facebook profile

Kino and tagesschau.de  
Tuesday, 05 July 2005

About 1.5 years ago, a television(+web) news channel in Germany named tagesschau.de contracted me for Kino enhancements specific to their needs. I did not want to create a branch of Kino to maintain for them, so I made them a bit generic and configurable when they were not already universal in nature. For example, I greatly enhanced Trim page for them, adding the Insert mode and file mode with history, etc. That was universally useful, obviously. Also in that line, I enhanced Capture and overall stability and usability.

Less universal requirements were Project ID, Metadata, and Publish. They wanted to integrate Kino with a CMS (Content Mangement System, something custom based upon Vignette StoryServer), which drives their web site.First, I will describe the use case, and then how it is is implemented.

Functional Requirements 

Project ID

When Kino launches, or you click File/New, it prompts you for a Project Name. The user enters a value, and it queries the CMS, which returns data about the project to feed into the next topic.


In Kino, the user can enter information (metadata) about each scene like title, description, category, location, whatever. Some of these metadata are not free text entry, but use lists of possible values, from which you choose one. These lists of values come from the project data retrieved when Kino prompted you for the Project ID.


Instead of just saving a file, send the contents of the Kino XML project to a server. Without detail, this server transcodes the video into web delivery formats, manages the files, and interacts with the CMS to "attach" the multimedia objects to articles, etc. for automation of content preparation. Also, another type of publish action is to send a still frame of the current frame in the Edit or Trim pages to the CMS.

If it seems a little vague on details, it is due to the generic implementation so I could quickly complete the project without understanding their business and processes :-).


Project ID

If you define a value for the config key newProjectURI in ~/.gnome2/kino, then Kino displays the "Project Name" prompt; otherwise, it does not. If the config value (URL), contains a '%s' then it is substituted by the config value. Then, Kino queries the server with the URL using the HTTP client within libxml2, and it expects an XML document in response. Example:

causes Kino to prompt the user for a project name. When the user clicks OK, the server returns the following XML:

<storylist id="1234">
<story id="56789">
    <title>Kino 0.7.1 is Released<title>

In order to facilitate the Publish process, a project ID can be extracted from the XML by defining config key newProjectXPath where the value corresponds to the value of the node pointed to by an XPath expression as the config value. Using the above example:

causes Kino to locate the actual story ID and associate it with this project.


Kino displays editable metadata items as child nodes in the treeview control used in the Storyboard. There is a default set of metadata items based upon the SMIL specification. One can define their own list of items using config key metaNames. This is a comma-delimited list of words. These words become XML attributes, so they must obey XML rules for naming of attributes (no spaces or funky characters). If the first character of a name is '*' then the field for the metadata items is always added to a scene and displayed begging the user for a value :-). It becomes part of the Kino project XML even if one does not enter a value, but it does not perform strict data validation.

The config key metaValues_ creates value enumerations (selection lists). Basically, this key is a stem of a real key that exists dynamically based upon the list in metaNames. For each item in metaNames, there is a config key metaValues_item. The value of this dynamic config item is a
list of words or label/value pairs. If '*' is a value, then the user may also enter a value not in the list.

The list may contain a label=value pair. The 'label' is displayed to the user while a 'value' is hidden and used in the XML attribute value. If a pair value begins with "xpath:" then the metaValues are expanded using the XML response from newProjectURI. Remember, a XPath query can return a collection of nodes. The text/value of these nodes is used to build the replacement list of label/values. Example:

causes Kino to automatically add and show only one metadata item.
causes Kino to show the stories as the list of metadata values to choose
from. The titles are displayed to the user, but the corresponding story id is stored in the XML! Furthermore, the user can only choose from the values in the list since there is no '*,'. Also, the story ID is stored in the XML project document as opposed to the story title.

As a result, there is a micro data dictionary and forms implementation that I simply call "metadata editing" as a Kino feature :-). The metadata is stored in and loaded from the XML project file. However, a limitation, this approach is dependent upon a fixed configuration. One can not have different configuration per project.


If one adds "enablePublish=true" to the Kino config file, then Kino displays two new menu and toolbar items: File/Publish SMIL and File/Publish Still Frame. These functions call a shell script and pass it the name of the project file and the project id retrieved by the newProjectXPath. Scripts are installed at $prefix/share/kino/scripts/publish/, and Kino comes with an example that does nothing really. $prefix is typically "/usr" or "/usr/local." There is a frame.sh and a project.sh script to correspond to each function. The Publish Still Frame function sends the name of the picture file in place of the project file name. If the user has not saved the Kino project yet, Kino creates a temporary file, calls the script, and deletes the temporary file when the script returns. The scripting makes this feature wide open and extensible!

Yeah, there is some quarkiness to the controls. It was difficult to make it stable and usable. There is an item in Preferences/Other to keep the scenes expanded for convenient metadata usage that the tagesschau folk use. There was some nice subtley added for no charge like as Kino detects a scene change in the DV stream in Capture, it adds the previous scene to the Storyboard so you can start adding the metadata.

Whew! Pretty neato, eh? Will you integrate this with your website? Could it be used to create a logging or video blogging tool perhaps?