Specification of the ANNODEX(TM) annotation format for time-continuous bitstreams, Version 1.0Commonwealth Scientific and
Industrial Research Organisation CSIRO,
AustraliaLocked Bag 17North RydeNSW2113Australia+61 2 9325 3141Silvia.Pfeiffer@csiro.auhttp://www.cmis.csiro.au/Silvia.Pfeiffer/Commonwealth Scientific and
Industrial Research Organisation CSIRO,
AustraliaLocked Bag 17North RydeNSW2113Australia+61 2 9325 3133Conrad.Parker@csiro.auhttp://www.cmis.csiro.au/Conrad.Parker/This specification defines a file format for annotating and
indexing time-continuous bitstreams for the World Wide Web. The
format has been named ANNODEX(TM) for annotating and
indexing. The ANNODEX(TM) format enables the specification of
named anchor points in time-continuous bitstreams together with
textual annotations and hyperlinks in URI format. These anchor points are merged
time-synchronously with the time-continuous bitstreams on
authoring a file in ANNODEX(TM) format. The ultimate aim of the
ANNODEX(TM) format is to enable an integration of time-continous
bitstreams into the browsing and searching functionality of the
World Wide Web.
At this point in time, the right to produce derivative works
is not granted to the IETF as the authors are uncertain about
the necessity to create a working group. The specification is
not encumbered by patents. The ANNODEX(TM) format is protected
by a trademark to prevent the use of the term "annodex" for any
related but non-conformant and therefore non-interoperable
technology.
When searching the World Wide Web, continuous media files
such as audio and video files are still treated as "dark
matter". It is not possible to look inside such files, search
for their content through common text-based search engines, and
actually directly access points of interest inside them. The
file can only be consumed in its entirety until the point of
interest is reached. In addition, such files are "dead ends" in
that by consuming their content the hyperlinking functionality
of the Web is left behind.
This document specifies a file format for interleaving of
XML markup with time-continuous data giving ANNODEX(TM) format
media. The ANNODEX(TM) format together with the Continuous Media Markup Language (CMML) and
the URI standard, extended by temporal URI references build the basis
technology to enable searching and surfing of time-continuous
data via existing Web infrastructure. The ANNODEX(TM) format
enables encapsulation of any type of streamable time-continuous
bitstream format thus being independent of current or future
compression formats. The XML tags were chosen to be very similar
to XHTML to enable a simple transfer of knowledge for HTML
authors.
The file extension of ANNODEX(TM) files is ".anx". This
document also applies for registration of the mime-type
"application/annodex" for ANNODEX(TM) format bitstreams.
The structure of this document is as follows: the
introduction describes the architecture of a Continuous Media
Web based on ANNODEX(TM) format media files and give an overview
of the ANNODEX(TM) media file format. The XML tags required to
create ANNODEX(TM) format media consist of two types of frames:
header and anchor frames. They form the annotation bitstream and
are described in section 4. The section on media encapsulation
then describes the mutiplexing format. The handling of the
different time constructs in ANNODEX(TM) format media is quite
complex and gets discussed in detail in section 6. The MIME type
application and security considerations build the final
sections. Last but not least the appendices give the actual
specifications of the "head" and "a" DTDs and definitions and
acronyms.
Please note that this document assumes that the reader has a
fluent working knowledge of XML, HTML, XHTML and
the World Wide Web. Deep knowledge of the Ogg
encapsulation format version 0 is also a prerequisite to
understanding of this specification. It is also a sister
document to the specification of the Continous Media Markup Language (CMML Version
1.0) for authoring ANNODEX(TM) format bitstreams.
As with Webpages, ANNODEX(TM) format bitstreams first have to
be authored and then published on a Server. Authoring includes
the creation of the media bitstream plus the creation of
annotations (i.e. textual data descriptions), indexes
(i.e. anchor points) and hyperlinks (i.e. URIs) for fragments of the media
data. Annotations, indexes and hyperlinks are encoded in XML according to the DTDs given in the
appendix and interleaved into the media document to create
ANNODEX(TM) format bitstreams in a time-synchronous
fashion. This procedure can be performed both on files and live
streams. The collection of ANNODEX(TM) format bitstreams on the
Internet is called the Continuous Media Web as it builds a Web
of time-continuous resources.
Distribution of ANNODEX(TM) format bitstreams happens via a
network protocol such as HTTP or
RTP/RTSP. The basic process is the
following: The client dispatches a download or streaming request
to the server with a certain URI. The server resolves the URI
and starts packetising ANNODEX(TM) format bitstreams, taking
into account temporal URI fragment specifications.
In case of packet loss due to an unreliable transport, media
data or anchor data may get lost; this may be important to the
application or not. Both media and mark-up data are treated with
the same importance. If a user doesn't care whether the media
data is completely received, then the mark-ups will be regarded
the same way. Anchors are typically treated as state changes; if
an anchor tag gets lost, the next anchor tag will restore the
proper state. We envisage, however, that a client may require
the current state information, so there should be a protocol
request for sending the current state again. This will be
delivered by the server by inserting another copy of the
currently active anchor into the ANNODEX(TM) bitstream.
To access the Continuous Media Web, a client such as a
conformant Web browser is required. A client can link to an
ANNODEX(TM) bitstream via a URI. A URI can point to a temporal
offset in the ANNODEX(TM) bitstream using temporal URI fragment identifiers or to
a named offset by using the id tag of an anchor frame as a URI
fragment identifier. In this way, direct access to points of
interest in the media document is enabled. While playing back
ANNODEX(TM) format bitstreams, a user is being offered
hyperlinks (URIs) to other Web resources which (in the author's
eye) are related to the currently displayed media content.
A client may be a special player or a browser plugin. This
application must split an ANNODEX(TM) format bitstream into its
constituent header and anchor frames, and the media document. A
decoder is required to display the encapsulated media document
after decoding it with the appropriate media decoder. While
playing back the media document, the application displays the
hyperlinks and the annotations for the active anchor frames.
Search engines can include published ANNODEX(TM) format files
into their search repertoire by finding annotations in the
anchor frames in a standard way independent of the encoding and
packetising format of the media document. This allows any media
format to be spidered. In addition, the protocol should allow to
download only the CMML mark-up from a published ANNODEX(TM)
format file. This will stop spiders from creating extensive
network loads as they do not need to download the media
bitstream to gain the necessary information. It also reduces the
size of search archives, even for large amounts of published
ANNODEX(TM) format files, because a CMML file contains all
searchable annotations for the media fragments of its
ANNODEX(TM) format file.
The format of ANNODEX(TM) bitstreams consists of a bitstream
of time-continuous data interspersed with structured XML mark-up
of an annotation bitstream. It is designed to be used both as a
persistent file format and as a streaming format. Any encoding
format for time-continuous data can be encapsulated in the
ANNODEX(TM) format as long as it is streamable and is based on a
regular data sampling rate (called granulerate). XML mark-up is
inserted between media packets at the synchronised point in
time.
There are two types of XML mark-up that are inserted: a
header frame ("head"), and an arbitrary number of anchor frames
("a"). There is only one head at the start of an annotation
bitstream. It contains structured and unstructured meta data
describing the complete time-continuous data bistream. In the
simple case, an anchor frame contains information on the
fragment of media between the current anchor and the next one
(or the end of the document if none follows).
The following figure gives an example of such an ANNODEX(TM)
format bitstream and the temporal regions during which the
"head" and "a" frames are valid. It describes the simple case
where anchor frames don't overlap in time and there is only one
media bitstream.
Annodexed media file (default annotation track only)
_______________________________________________________________________
| | | | | | | | | | |
|head| |a| |a| |a| |a| |
| | | | | | | | | | |
_______________________________________________________________________
|-------------|
|---------------|
|--------------------|
|----------|
|----------------------------------------------------------------------|
There is also a more complex scheme of authoring anchors for
ANNODEX(TM) format bitstreams. In it, anchors are grouped
together by giving them a type. Anchors of one type are not
allowed to overlap in time, but anchors of different type may
overlap. This enables the creation of different tracks of
annotation. The advantage is that it gives the author the choice
to describe a specific media file from different aspects,
e.g. by giving different language tracks. The client application
then has the choice to display only the default track or offer
all existing tracks to the user.
The annotation bitstream consists of a "head" frame and and
arbitrary number of "a" frames. These tags are briefly explained
in this section.
A "head" frame is an XML document that contains information
about the complete ANNODEX(TM) format bitstream. It is enclosed
in "head" tags. The DTD for the "head" frame can be found at
http://www.annodex.net/DTD/anxhead_1_0.dtd . It can be used for
validation of a "head" frame.
An example for a "head" frame is the following:
The Matrix
]]>The xml declaration and the reference to the DTD make the
"head" frame a proper xml document. The DTD of the "head" frame
is given in the appendix and technically fully specifies the
"head" frame. The semantic meaning of each of the tags and
attributes is the same as in the CMML. Please refer to the CMML
specification document for details.
An anchor frame is an XML document that contains information
about a fragment of the encapsulated time-continuous
bitstream. It is active from the time instant in the
time-continuous bitstream at which it is inserted until the time
instant at which it is deactivated either through another anchor
frame (on the same annotation track) or through the end of the
file. It is enclosed in "a" tags. The DTD for the "a" frame can
be found at http://www.annodex.net/DTD/anxa_1_0.dtd . It can be
used for validation of an "a" frame.
An example for an "a" frame is the following:
There is no spoon: Neo is waiting to see the Oracle in a room
full of children doing seemingly impossible things. One is making
spoons bend through telekinesis. Neo tries to do it himself, but
fails. Spoon boy: "Do not try and bend the spoon that's impossible,
instead only try to realize the truth." Neo: "What truth?" Spoon
boy: "There is no spoon." Neo: "There is no spoon?" Spoon boy: "Then
you'll see that it is not the spoon that bends, it is only
yourself." Neo tries again...
Den Löffel gibt es nicht: Neo entdeckt beim Besuch
des Orakels wie unwirklich seine Welt ist. Beim Versuch, einen
Löffel durch Telekinese zu verbiegen, bekommt er von dem Kind den
Rat: "Den Löffel gibt es nicht."
]]>Unlike the "head" frame, the anchor frame contained within
an ANNODEX(TM) format media file does not contain an xml
declaration and a reference to the DTD. This information can
be extrapolated from the information stored in the "head"
frame and would create an unnecessary overhead if included in
every anchor frame. It is however necessary when extracting
the anchor frame into a proper XML document. The used version
of xml can be extracted from the related head frame, the dtd
reference is the same as the one for the head frame with
replacing every occurance of "head" by "a". For example:
]]>Although the "a" element can be considered as the root
element of an anchor frame described as an XML document, it
also does not contain a xmlns attribute. The reason is that
the same namespace as in the associated "head" frame is valid
for all "a" frames in an ANNODEX(TM) format bitstream and a
repetition would only spend bandwidth unnecessarily and be a
cause for error. Similarly the default language and
directionality specified in the "head" frame are also valid
for the anchor frames.
The DTD of the anchor frame is given in the appendix and
technically fully specifies the frame format. The semantic
meaning of each of the tags and attributes is the same as in
the CMML. Please refer to the CMML
specification document for details.
An ANNODEX(TM) format bitstream consists of XML markup in the
annotation bitstream interleaved with the related media frames
of the media bitstreams into a single bitstream.
It is not possible to use straight XML as encapsulation
because XML cannot enclose binary data except encoded as
Unicode. The use of Unicode would introduce too much overhead.
Therefore, an encapsulation format that could handle binary
bitstreams and textual frames was required.
The following list gives a summary of the requirements for
the ANNODEX(TM) format bitstream:
framing for binary time-continuous data and XML.temporal synchronisation between time-continuous
media bitstreams and XML on interleaving.temporal resynchronisation after parsing error.detection of corruption.seeking landmarks for direct random access.streaming capability (i.e. the information required
to parse and decode a bitstream part is available
at the time at which the bitstream part is reached and
does not come e.g. at the end of the stream).small overhead.simple interleaving format with a track paradigm.The Ogg encapsulation format version
0 was chosen as the encapsulation format for ANNODEX(TM)
format bitstreams as it provides for all the requirements and
has proven reliable and stable.
This section specifies the way the Ogg media encapsulation
framework is used for creating ANNODEX(TM) format
bitstreams. As such, knowledge of the Ogg bitstream format as
specified in the Ogg RFC is
presumed. Please also refer to that document for descriptions
of the terms used in this document. This section describes the
specific media mapping that is used for ANNODEX(TM) format
bitstreams.
ANNODEX(TM) format bitstreams consist of one or more
time-continuous media bitstreams and an XML annotation
bitstream concurrently interleaved (in Ogg terms: multiplexed)
into an Ogg bitstream. Sequential multiplexing is allowed, but
can only happen with complete ANNODEX(TM) format bitstreams.
Every ANNODEX(TM) format bitstream consists of at least two
logical bitstreams: the ANNODEX(TM) media mapping bitstream
and the annotation bitstream that contains the "head" and the
"a" tags. The bos pages of these two (in order) are followed
by the bos pages of any number of media bitstreams. Then all
the secondary header pages of all the media bitstreams follow,
including a packet of the annotation bitstream containing the
"head" tag as secondary header for the annotation
bitstream. Then, the bitstream data is multiplexed in
time-synchronous fashion.
The ANNODEX(TM) media mapping bitstream consists only of
one bos page which contains information for the complete
physical bitstream. The bos page has the following format:
The LSb (least significant bit) comes first in the Bytes.
Fields with more than one byte length are encoded LSB (least
significant byte) first.
The fields in the ANNODEX(TM) bos page have the following
meaning:
Identifier: a 8 Byte field that identifies this file to
be of ANNODEX(TM) format. It contains the magic numbers:
0x41 'A'0x6e 'n'0x6e 'n'0x6f 'o'0x64 'd'0x65 'e'0x78 'x'0x00 '\0'Version major: 2 Byte short integer number signifying the
major version number of the ANNODEX(TM) format
bitstream. This document specifies the major version 1.
Version minor: 2 Byte short integer number signifying the
minor version number of the ANNODEX(TM) format
bitstream. This document specifies the minor version 0.
Timebase numerator & denominator: 8 Byte integer
number each. They represent together the timebase of the
ANNODEX(TM) format bitstream given as a rational number. The
denominator represents the temporal resolution at which the
timebase is given. E.g. 5 on 1000 results in a timebase of
0.005 sec. This enables a very high temporal resolution
without having to store floating point numbers.
UTC: a 20 Byte string containing a UTC time in the form
of YYYYMMDDTHHMMSS.sssZ. It associates a calendar date and a
wall-clock time with the timebase. It is a zero length
string if not in use.
Please note: The possible temporal resolution of the
timebase is on the order of 2^-64. However the time formats in
use for media that are described in this document range from
1/24 to 1/60 for the different smpte formats and to 1/1000 for
npt. Thus, this resolution is enough for anyone of
them. What's more, this resolution is expected to accommodate
any future needs of time resolution for any other time format
(and time-continuous sampled data).
The media and annotation bitstreams start each with one bos
page containing information required for the decoding of the
bitstream. After that, secondary header pages follow that
contain information to set up the decoder for the bitstream
and other stream-specific information. Then, the pages that
contain the actual data follow. For the annotation bitstream,
the "head" frame is encapsulated into one (or more) secondary
header pages. The anchor frames represent the actual data of
the annotation bitstream.
The bos page of a media or annotation bitstream has the
following format:
The LSb (least significant bit) comes first in the Bytes.
Fields with more than one byte length are encoded LSB
(least significant byte) first.
The fields in the ANNODEX(TM) bos page have the following
meaning:
Identifier: a 8 Byte field that identifies this file to
be of a logical input bitstream with encoded information. It
contains the magic numbers:
0x41 'A'0x6e 'n'0x78 'x'0x44 'D'0x61 'a'0x74 't'0x61 'a'0x00 '\0'Granule rate numerator & denominater: 8 Byte integer
number each. They represent the temporal resolution of the
logical bitstream in Hz given as a rational number in the
same way as the timebase attribute above.
Number of secondary header pages: a 4 Byte integer number
that contains the number of secondary header pages of that
particular logical bitstream following after this bos page.
Number of bytes used for mime type string: a 4 Byte
integer number giving the length of the Mime type field
following directly after this field and including the final
NUL character.
Mime type string: a character sequence containing the
mime type of the data encoded in
this logical bitstream. E.g. for the annotation bitstream it
will be "text/cmml" as upon extraction of the annotation
bitstream from the ANNODEX(TM) format bitstream a CMML document results.
Number of bytes used for identifier string: a 4 Byte
integer number giving the length of the identifier string
following directly after this field, including the final NUL
character.
Identifier string: a character sequence containing an XML
ID identifier text for this logical bitstream.
ANNODEX(TM) format bitstreams inherently represent one
timeline only, where the different media and the annotation
bitstream can be thought of as content tracks on that
timeline. All of these tracks relate to the same timeline which
starts at a certain time point and ends when the last bitstream
ends. An example bitstream can be seen in the following
figure. It consists of an ANNODEX(TM) format bitstream that
contains 4 media bitstreams and the annotation bitstream. In the
flat representation these will be multiplexed such that the data
frames of each of these bitstreams occurs at the correct time.
The following bitstream is a conceptual representation of the
time intervals covered by the different logical bitstreams:
|
----------------------------------------------------------------------
| a1 | a2 | a3 | a4 |
----------------------------------------------------------------------
annotation bitstream
---------------------------------------------
| audio bitstream 1 |
---------------------------------------------
--------------------------------------------------------------
| video bitstream 1 |
--------------------------------------------------------------
-----------------------------------------------------
| audio bitstream 2 |
-----------------------------------------------------
------------------------------
| video bitstream 2 |
------------------------------
]]>The time point at which the ANNODEX(TM) format bitstream
starts (t0 in the above example) is called the "timebase" and
represents the playback time in seconds associated with the
beginning of the ANNODEX(TM) format bitstream. This start time
may but does not have to be 0 - it can be any positive time
offset. This time offset is stored in the ANNODEX(TM) bitstream
bos page.
Each one of the encapsulated media bitstreams and the
annotation bitstream have their own temporal resolution at which
they can provide data to cover the given timeline. This temporal
resolution is usually given through the sampling rate of the
particular bitstream. For example, a raw audio bitstream at CD
quality is sampled with a sampling rate of 44100 Hz. A video
bitstream may be sampled with a frame rate of 25 frames per
second. This temporal resolution is stored in the "granulerate"
field of the bos page of the bitstream.
The "granulerate" is used for the calculation of the time
position for which a data packet of the media bitstreams
contains data. The "granulepos" field in an Ogg page when
divided by the "granulerate" of that page's logical bitstream
provides the time position that is reached in that bitstream
after decoding all data packets finished on this page. E.g. if
an audio bitstream has a granulerate of 44100 and starts at 0,
then a granulepos of 88200 signifies that the bitstream has
reached the second sec after the end of decoding this page's
packets.
The annotation bitstream's "granulerate" can be chosen
arbitrarily by the bitstream multiplexer. One option is to choose
the least common multiple of the granulerates of all the media
bitstreams to gain at least the resolution of the
bitstreams. However, that resultion may not be enough compared to
the one that the author of anchors is asking for on insertion
time. One solution is to accommodate for all possible time
schemes of the anchors. Thus, a time resolution of the least
common multiple of the resolution of all the npt and smpte time
schemes is another option.
The possible time schemes with their respecitve resolutions are:
npt: 1000smpte-24: 24smpte-24-drop: 24/1.001 = 23.976 (approx. as per SMPTE)smpte-25: 25smpte-30: 30smpte-30-drop: 30/1.001 = 29.970 (approx. as per SMPTE)smpte-50: 50smpte-60: 60smpte-60-drop: 60/1.001 = 59.940 (approx. as per SMPTE)
To get to integer values, it is necessary to multiply all
resolutions by 1000 and then take the least common multiple:
lcm(1000000, 24000, 23976, 25000, 30000, 29970, 50000, 60000,
59940) = 2997000000. The "granulerate" would therefore be
2997000. This provides for a temporal resolution on the order
of 10^-6, accommodating for a mixed use of all the above given
time schemes.
The "granulepos" of the (set of) page(s) holding an anchor
frame of the annotation stream has to signify the start time of
that anchor frame. E.g. if the "granulerate" of the annotation
bitstream is 1000, the "timebase" is 0, and an anchor is to be
inserted at npt=12.020, its "granulepos" will be 12020. Anchors
can be repeated in the ANNODEX(TM) format bitstream, which will
be signified by having the same "track" attribute and the same
page_sequence_number as the previous anchor frame.
This section contains the registration information for the
'application/annodex' media type. While this media type is not
approved by the IANA, 'application/x-annodex' may be used.
To: ietf-types@iana.org
Subject: Registration of MIME media type application/annodex
MIME media type name: application
MIME subtype name: annodex
Required parameters: none
Optional parameters: none
Encoding Considerations: the ANNODEX(TM) enables
encapsulation of any type of encoding format. The authoring
software has to provide for the encoders, while the client
software has to look out for the browsers.
Security considerations: see next section.
Interoperability considerations: the ANNODEX(TM) bitstream
format is a free specification that is independent of any media
encoding format. It is designed to provide interoperability with
the existing World Wide Web. Its specification is not patented
and can be implemented by third parties without patent
considerations.
Additional information:Magic numbers: "OggS" identifies an Ogg page, "Annodex"
identifies an Ogg page with an ANNODEX(TM) format bitstreams,
and "AnxData" signifies an Ogg page with media or annotation
bitstreamFile extension: .anxMacintosh File Type Code: "ANDX"Intended usage: COMMONFragment identifiers: Any named element, i.e. element that
contains an "id" attribute, may be referenced through a fragment
identifier of a URI. However, the values of the id attribute of
the anchor tags are the most important ones used for addressing
the identified "a" tags in the ANNODEX(TM) format bitstream.
Also, the generic temporal URI fragment
addressing scheme can be used as a fragment identifier on
ANNODEX(TM) format bitstreams and then relates to that specific
time offset in the ANNODEX(TM) format bitstream, calculated with
respect to the "timebase" of the ANNODEX(TM) bos page.
An example for a URI to a named media fragment is the
following:
Examples for URIs to temporal fragments are the
following:
ANNODEX(TM) format bitstreams contain several multiplexed
binary media and one XML annotation bitstream. There is no
generic encryption or signing mechanism provided for the
complete bitstream or anyone of its parts. As the format of the
encapsulated media bitstreams is not prescribed and is
identified through the "mimetype" field in that bitstream's bos
page, it is possible to encrypt or sign that media bitstream and
then mark it accordingly with a mime type that signifies the
encryption. It is up to the applications that use this bitstream
to provide an appropriate codec to handle such bitstreams.
As ANNODEX(TM) format bitstreams contain binary media
bitstreams, it is possible to include executable content in
them. This can be an issue with applications that decode these
bitstreams, especially when they are used in a network
scenario. Such applications have to ensure correct handling of
manipulated bitstreams, of buffer overflow and the like.
Extensible Markup Language (XML) 1.0World Wide Web ConsortiumMIT Laboratory for Computer Science545 Technology SquareCambridgeMA02139US+ 1 617 253 2613+ 1 617 258 5999timbl@w3.orghttp://www.w3c.orgHTML 4.01 SpecificationWorld Wide Web ConsortiumMIT Laboratory for Computer Science545 Technology SquareCambridgeMA02139US+ 1 617 253 2613+ 1 617 258 5999timbl@w3.orghttp://www.w3c.orgXHTML(TM) 1.0 The Extensible Hyper Text Markup LanguageWorld Wide Web ConsortiumMIT Laboratory for Computer Science545 Technology SquareCambridgeMA02139US+ 1 617 253 2613+ 1 617 258 5999timbl@w3.orghttp://www.w3c.orgUniform Resource Identifiers (URI): Generic SyntaxWorld Wide Web ConsortiumMIT Laboratory for Computer Science545 Technology SquareCambridgeMA02139US+1 617 253 5702+1 617 258 8682timbl@w3.orgUniversity of California, IrvineDepartment of Information and Computer ScienceUniversity of California, IrvineIrvineCA92697-3425US+1 949 824 7403+1 949 824 1715fielding@ics.uci.eduXerox PARC3333 Coyote Hill RoadPalo AltoCA94304US+1 650 812 4365+1 650 812 4333masinter@parc.xerox.comHypertext Transfer Protocol -- HTTP/1.1University of California, IrvineDepartment of Information and Computer ScienceUniversity of California, IrvineIrvineCA92697-3425US+1 949 824 7403+1 949 824 1715fielding@ics.uci.eduWolrd Wide Web ConsotiumMIT Laboratory for Computer Science545 Technology SquareCambridgeMA02139US+1 617 258 8682jg@w3.orgWestern Research LaboratoryCompaq Computer Corporation250 University AvenuePalo AltoCA94305USmogul@wrl.dec.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science545 Technology SquareCambridgeMA02139US+1 617 258 8682frystyk@w3.orgXerox Corporation3333 Coyote Hill RoadPalo AltoCA94034US+1 650 812 4365+1 650 812 4333masinter@parc.xerox.comMicrosoft Corporation1 Microsoft WayRedmondWA98052USpaulle@microsoft.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science545 Technology SquareCambridgeMA02139US+1 617 253 5702+1 617 258 8682timbl@w3.orgReal Time Streaming Protocol (RTSP)Columbia UniversityDept. of Computer Science1214 Amsterdam AvenueNew YorkNY10027USschulzrinne@cs.columbia.eduNetscape Communications Corp.501 E. Middlefield RoadMountain ViewCA94043USanup@netscape.comRealNetworks1111 Third Avenue Suite 2900SeattleWA98101USrobla@real.comTags for the Identification of LanguagesUNINETTPb. 6883 ElgeseterTrondheim7002NorwayHarald.T.Alvestrand@uninett.noMultipurpose Internet Mail Extensions (MIME) Part Two: Media TypesInnosoft Internationl, Inc.1050 East Garvey Avenue SouthWest CovinaCA91790USAned@innosoft.comFirst Virtual Holdings25 Washington AvenueMorristownNJ07960USAnsb@nsb.fv.comXML Media TypesUniversity of California, IrvineDepartment of Information and Computer ScienceIrvineCA92697-3425USAejw@ics.uci.eduFuji Xerox Information SystemsKSP 9A7, 2-1, Sakado 3-chome, Takatsu-kuKawasaki-shiKanagawa-ken213Japanmurata@fxis.fujixerox.co.jpThe Ogg encapsulation format version 0Commonwealth Scientific and Industrial Research OrganisationLocked Bag 17North RydeNSW2113Australia+ 61 2 9325 3100+ 61 2 9325 3200Silvia.Pfeiffer@csiro.auhttp://www.annodex.net/SMPTE STANDARD for Television, Audio and Film - Time and Control Code The Society of Motion Picture and Television Engineers595 W. Hartsdale Ave.White PlainsNY10607USAsmpte@smpte.orgData elements and interchange formats -- Information interchange -- Representation of dates and times International Organization for Standardization1 rue de VarembreCase Postale 56Geneva201211CHcentral@iso.orgSyntax of temporal URI fragment specifications (work in progress)Commonwealth Scientific and Industrial Research OrganisationLocked Bag 17North RydeNSW2113Australia+ 61 2 9325 3100+ 61 2 9325 3200Silvia.Pfeiffer@csiro.auhttp://www.annodex.net/Commonwealth Scientific and Industrial Research OrganisationLocked Bag 17North RydeNSW2113Australia+ 61 2 9325 3100+ 61 2 9325 3200Conrad.Parker@csiro.auhttp://www.annodex.net/Specification of the Continuous Media Markup Language (CMML), Version 1.0 (work in progress)Commonwealth Scientific and Industrial Research OrganisationLocked Bag 17North RydeNSW2113Australia+ 61 2 9325 3100+ 61 2 9325 3200Silvia.Pfeiffer@csiro.auhttp://www.annodex.net/Commonwealth Scientific and Industrial Research OrganisationLocked Bag 17North RydeNSW2113Australia+ 61 2 9325 3100+ 61 2 9325 3200Conrad.Parker@csiro.auhttp://www.annodex.net/
]]>
]]>XML data containing information
on a fragment of a time-continuous bitstream.a subpart of a media document
covering some temporal interval.XML tags and their content used to
describe a media document.encapsulated
time-continuous bitstream with Head and Anchor frames.the task of giving textual
descriptions to fragments of media documents.the task of identifying index points
for media documents or fragments thereof.the task of linking from one Web
resource to another. If a link has an offset into the
resource, this is sometimes called deep hyperlinking.XML data containing information on
an ANNODEX(TM)ed media file.a block of digital data that
represents a temporal subpart of a stream of continuous
media. Media packets of one continuous media file do not
overlap in time.a sequence of time-continuous data.Continuous Media Markup Language.Document Type Declaration.eXtensible Markup Language.Continuous Media Web.World Wide Web.Unified Resource Identifier.The authors greatly acknowledge the contributions of: Andre
Pang, Andrew Nesbit, and Simon Lai in developing this standard..