ViPER API Specification
The ViPER API, which provides a Java interface to video metadata, is described here in detail, from the standpoint of our implementation. For information about what constraints we put on it, see the ViPER API requirements. If you wish to actually use the API, you should most likely look at the Scripting ViPER document, which is available from the documentation page.
Think of it as a DOM
for video metadata
. The system maps the heirarchical nature of the
ViPER metadata files, as described in the documentation, to a set of Java interfaces. (These
are roughly parallel to IDL.) This specification document defines what those
interfaces are and what they mean. The implementation of them is
also described further on, and is only of interest to the
developers of the implementation.
The Java Interfaces (& some supporting classes)
As described in the above introduction, the interfaces expose the ViPER API to the programmer. This includes the ability to parse, to create and to manipulate ViPER files. The interface also allows for things like Undo/Redo support. However, the API also defines a number of classes to support time encoded data, and define the location of the prototype implementation's parser.
Qualifying Data with Time and Frame Contexts
In order to keep the interfaces consistant and to provide a good
way to handle both frame based media and time based media, the
system abstracts time and frame into Instant objects.
This abstract class is implemented in the concrete Time
and Frame classes. There are also a number of related
classes, all defined as members of the
viper.api.time namespace.
The Instant classes are used to define time-coded lists, lists that
are arranged in order of time and have values that change over time. This
is represented by the TemporalRange interface, a child of the more generic
IntervalIndexList, which uses Comparable objects, not Instant objects, to
qualify list elements with 'intervals'. Not all moments of time have values,
and these return null. Setting a time to null is equivalent to
removing it. This may cause some problems, as it is somewhat inconsistent with
the java.util collections.