Wednesday, April 25, 2012

server reorganization


Turnkey Linux Hub

The MLT web/wiki and git server has moved out of the garage and into the cloud to offer better uptime, responsiveness, and collaboration. Turnkey Linux has a TWiki appliance, so we moved the web site to its hub service, which provides cloud-computing for its appliance images. This greatly simplifies management partly because it has many things related to security and backup already setup.

github - social coding
Then, we had to decide what to do about the git daemon and gitweb service - whether to migrate that to the hub instance as well or whether to use a popular git hosting service. GitHub has really become a great collaboration service with code reviewing, pull requests, and issue tracking, giving it an edge over others. Not to mention, so many developers are already registered and ready to fork. So, effective immediately the authoritative git repositories are now at https://github.com/mltframework/.

TeamCity
Not done yet. A new contributor has setup an automated build server that uses the build scripts, which are now being maintained in git instead of the wiki. The build server is primarily for quality assurance purposes at this point, but there are plans to offer nightly builds of popular MLT applications from this service. We have a little more work to expose that properly.

Monday, April 2, 2012

time properties

Support for time values in properties just landed in git. This means properties like in, out, and length that used to take and provide frame counts now also support timecode and clock values. This makes manual authoring and reading XML easier. For example,


$ melt color: out=:5.0 -consumer xml no_meta=1 time_format=smpte
returns the following XML that can also be parsed:
<mlt LC_NUMERIC="en_US.UTF-8" version="0.7.9" title="color:">
  <profile description="DV/DVD PAL" width="720" height="576" progressive="0" sample_aspect_num="16" sample_aspect_den="15" display_aspect_num="4" display_aspect_den="3" frame_rate_num="25" frame_rate_den="1" colorspace="601"/>
  <producer id="producer0" in="00:00:00:00" out="00:00:05:00">
    <property name="mlt_type">producer</property>
    <property name="length">00:10:00:00</property>
    <property name="eof">pause</property>
    <property name="resource"></property>
    <property name="aspect_ratio">1.066667</property>
    <property name="mlt_service">color</property>
  </producer>
  <playlist id="playlist0">
    <entry producer="producer0" in="00:00:00:00" out="00:00:05:00"/>
  </playlist>
  <tractor id="tractor0" title="color:" global_feed="1" in="00:00:00:00" out="00:00:05:00">
    <track producer="playlist0"/>
  </tractor>
</mlt>


Hour, minute, and second components are optional, but there must be at least one colon for a string value to be interpreted as time. If the last component contains a radix, then it is interpreted as a clock value instead of a SMPTE timecode. That means, in the above, ":5.0" means 5 seconds, which for 25 frames per seconds, yields a timecode of 00:00:05:00, which could be abbreviated as 5:00 or even 5:. Of course, the numeric locale is supported for period or comma as radix, as needed.

This is exposed through the Mlt::Properties API as well for applications. Variants of other functions that deal with time are slowly being added, but Mlt::Producer::get_length_time() was already added. User interfaces often need to show and accept time values, and this makes it easier to support that in your MLT application.

Lastly, another benefit, is that one can use the clock values in XML, and they will automatically adapt to changes in the profile framerate. Of course, you may lose frame accuracy if you do change the framerate, but that may not matter for some use cases.