[cvs-annodex] commit (/annodex):
standards/draft-pfeiffer-cmml-current.xml
silvia
nobody at lists.annodex.net
Sun Feb 13 22:17:16 EST 2005
Update of /annodex (new revision 889)
Modified files:
standards/draft-pfeiffer-cmml-current.xml
Log Message:
Changed pages to packets where appropriate.
Changed the structure a little to make CMML serialized, then put in ogg, then add skeleton.
Still needs heaps of work and *deletions*.
Modified: standards/draft-pfeiffer-cmml-current.xml
===================================================================
--- standards/draft-pfeiffer-cmml-current.xml 2005-02-13 09:26:04 UTC (rev 888)
+++ standards/draft-pfeiffer-cmml-current.xml 2005-02-13 11:17:14 UTC (rev 889)
@@ -1285,15 +1285,29 @@
</section>
- <!--**************************-->
- <!-- Mapping CMML <-> ANNODEX -->
- <!--**************************-->
- <section title="Mapping between CMML and Annodex format bitstreams">
+ <!--******************-->
+ <!-- Serialising CMML -->
+ <!--******************-->
+ <section title="Serialising CMML">
- <section title="The format of the CMML media mapping bos">
+ <t>CMML is an annotation language that is meant to markup any
+ time-continuous data and be interleaved in a time-synchronous
+ fashion with other time-continuous bitstreams. Therefore, CMML
+ must be able to be serialised into a time-continuous bitstream
+ of data packets. This is described in this section.
+ </t>
- <t>The bos page of a CMML logical bitstream when mappend into
- an Ogg bitstream has the following format:
+ <t>CMML is serialised by having some initial header pages that
+ set up the CMML decoding environment, and contain header type
+ information. The content of a CMML bitstream then consists of
+ "clip" tags.
+ </t>
+
+ <section title="The format of the CMML ident header packet">
+
+ <t>The ident header packet of a logical bitstream contains all
+ information required to set up a CMML decoder. It has the
+ following format:
</t>
<figure>
@@ -1325,7 +1339,7 @@
(least significant byte) first.
</t>
- <t>The fields in an CMML bos page have the following
+ <t>The fields in an CMML ident header packet have the following
meaning:
</t>
<list style="numbers">
@@ -1356,19 +1370,30 @@
logical bitstream in Hz given as a rational number in the
same way as the fishead basetime field above.
</t>
+ <t>Granuleshift: a 1 Byte integer number describing whether to
+ partition the granule_position into two for that logical
+ bitstream, and how many of the lower bits to use for the
+ partitioning. The upper bits then still signify a
+ time-continuous granule positions for a directly decodable
+ and presentable data granule. The lower bits allow for
+ specification of a finer resolution such that for example
+ predicted frames of a video can be addressed as well, though
+ not decoded without tracing back to the last fully decodable
+ data granule. This is e.g. the case with Ogg theora.</t>
</list>
</section>
<section title="The format of the CMML secondary headers">
- <t>The CMML secondary headers are a sequence of (at least)
- two Ogg pages that contain the CMML "setup" information:
+ <t>The CMML secondary headers are a sequence of
+ two packets that contain the CMML "setup" information and
+ are getting mapped into (at least) two Ogg pages:
<list typs="symbols">
- <t>one page with the CMML xml preamble.</t>
- <t>one (or more) page(s) with the CMML "head" tag.</t>
+ <t>one packet with the CMML xml preamble.</t>
+ <t>one packet with the CMML "head" tag.</t>
</list>
- These pages contain textual, not binary information. All
+ These packets contain textual, not binary information. All
characters MUST be encoded in UTF-8 as transport format.
</t>
@@ -1383,8 +1408,7 @@
the "cmml" end tag is deleted.
</t>
- <t>The first CMML secondary header page has the following
- format:
+ <t>The first CMML secondary header packet has the following format:
</t>
<figure>
@@ -1406,9 +1430,8 @@
]]></artwork>
</figure>
- <t>The second CMML secondary header page has the following
- format. If the "head" tag is larger than 64 kBytes in size,
- it needs to be distributed over more than one Ogg page.
+ <t>The second CMML secondary header packet has the following
+ format.
</t>
<figure>
@@ -1428,12 +1451,16 @@
</section>
+ </section>
- <!--**************************-->
- <!-- Encoding CMML to ANNODEX -->
- <!--**************************-->
- <section title="Serializing CMML in Annodex format bitstreams">
+ <!--**************************-->
+ <!-- Encoding CMML to Annodex -->
+ <!--**************************-->
+ <section title="Mapping CMML into Ogg and Annodex">
+
+ <section title="Media mapping for a CMML logical bitstream inside Ogg">
+
<t>As CMML is an authoring format for Annodex bitstreams, there
is a simple way to map the annotations and meta information
contained in a CMML instance document to the annotation
@@ -1481,12 +1508,10 @@
<t>The "stream" tag itself finds no representation in the
Annodex bitstream. Rather, it contains both, information on
the complete Annodex bitstream, and information on the
- different input documents. The first is information that finds
- a representation in the Annodex bos page, which is the very
- first bos page in an Annodex bitstream. The second is
- information used during the encoding process of each media
- bitstream and may find entry into the AnxData bos page of the
- respective media bitstream.
+ different input documents. This is information that finds
+ a representation in the Skeleton logical bitstream of an
+ Annodex bitstream. The second information is also used
+ during the encoding process of each media bitstream.
</t>
<t>Here is a list of the attribute values of the
@@ -1498,21 +1523,21 @@
therefore be lost on encoding.
</t>
- <t>basetime: this attribute MUST be represented in the Annodex
- bos page in the fields "Basetime numerator" and "Basetime
+ <t>basetime: this attribute MUST be represented in the Skeleton
+ ident header in the fields "Basetime numerator" and "Basetime
denominator".
</t>
- <t>utc: this attribute MUST be represented in the Annodex bos
- page in the field "utc".</t>
+ <t>utc: this attribute MUST be represented in the Skeleton ident
+ header in the field "utc".</t>
</list>
</t>
<t>Here is a list of the attribute values of the
"import" tag and how they are being used:
<list>
- <t>id: this attribute SHOULD be represented in the media
- bos page of the respecitve media bitstream as a message
+ <t>id: this attribute SHOULD be represented in the Skeleton
+ secondary header for the respecitve media bitstream as a message
header field with name "ID", as it signifies a short identifying
machine-readable string for the import media bitstream.
</t>
@@ -1521,17 +1546,19 @@
and directionality of the human readable texts in the stream tag
which are not acquired into the Annodex bitstream.</t>
- <t>granulerate: this attribute MUST be represented in the media
- bos page in the fields "Granule rate numerator" and "Granule
+ <t>granulerate: this attribute MUST be represented in the Skeleton
+ secondary header for the respective media bitstream in the
+ fields "Granule rate numerator" and "Granule
rate denominator". The encoder MUST however ascertain that
the values are corrected with the exact granule rate that was
used during creation of the Annodex bitstream.
</t>
<t>contenttype: this attribute MUST be represented in the
- media bos page as a message header field with name "Content-type",
- as it signifies the MIME type of the media bitstream, providing
- for a decoding hint.</t>
+ respective Skeleton secondary header packet as a message header
+ field with name "Content-type", as it signifies the MIME type
+ of the media bitstream, providing for a decoding hint.
+ </t>
<t>src: not used, as this attribute only points to the location
of the import media bitstream and is thus pure authoring
@@ -1555,16 +1582,16 @@
therefore be lost on encoding.
</t>
- <t>name, value: these attributes MAY be represented in the media
- bos page of the respecitve media bitstream as a message
- header field with the given name-value pair. These are highly
- dependent on the type of media bitstream handled and it therefore
- depends on the encoding tool to make a selection of the parameters
- acquired. E.g. lets regard an audio bitstream containing speech in
- a specific language. This language MAY be identified during CMML
- authoring as a param element with "Content-Language" name, and
- acquired into the media bitstream message header field of the
- same name.
+ <t>name, value: these attributes MAY be represented in the
+ Skeleton secondary header packet of the respective media bitstream
+ as a message header field with the given name-value pair.
+ These are highly dependent on the type of media bitstream
+ handled and it therefore depends on the encoding tool to make
+ a selection of the parameters acquired. E.g. lets regard an
+ audio bitstream containing speech in a specific language.
+ This language MAY be identified during CMML authoring as a
+ param element with "Content-Language" name, and acquired into
+ the media bitstream message header field of the same name.
</t>
</list>
</t>
@@ -1575,7 +1602,7 @@
<t>While the "stream" tag contained meta data on the different
input media bitstreams, the preamble and the "cmml" tag contain
meta data on the annotation bitstream and therefore end up in the
- AnxData bos page of the annotation bitstream.</t>
+ Skeleton secondary header packet of the cmml bitstream.</t>
<t>Here is a list of the attribute values of the preamble and
how they are being acquired:
@@ -1588,7 +1615,7 @@
Annodex bitstream.</t>
<t>xml encoding: this attribute MUST be represented in the
- annotation bos page as a message header field with name
+ CMML fisbone packet as a message header field with name
"Content-type" and the encoding format being the charset
value following "text/x-cmml;" (or "text/cmml;" after IANA
registration of the MIME type).</t>
@@ -1611,7 +1638,7 @@
<t>Here is a list of the attribute values of the "cmml" tag and
how they are being acquired:
<list>
- <t>id: this attribute SHOULD be represented in the bos page
+ <t>id: this attribute SHOULD be represented in the fisbone packet
of the annotation bitstream as a message header field with
name "ID", as it signifies a short identifying
machine-readable string for the annotation bitstream (in
@@ -1619,7 +1646,7 @@
</t>
<t>lang, dir: these attributes MUST be represented in the
- bos page of the annotation bitstream as message header
+ fishbone packet of the annotation bitstream as message header
fields with name "Content-Language" and "Content-Dir".
</t>
@@ -1633,9 +1660,9 @@
<section title="Encoding the 'head' tag">
<t>The CMML "head" tag is printed as a string into the first
- secondary header page of the annotation bitstream. Thus,
- the value of the field named "number of secondary header pages"
- in the bos page of the annotation bitstream will be 1, unless
+ secondary header packet of the annotation bitstream. Thus,
+ the value of the field named "number of header packets"
+ in the fisbone page for the annotation bitstream will be 1, unless
the "head" tag turns out to be too big for one Ogg page (i.e.
larger than about 64K).
</t>
@@ -1658,13 +1685,13 @@
<t>A "clip" tag is encoded with all tags (except for the
"start" and "end" attributes) as a string printed into a
- clip page in the annotation bitstream. The "clip"
+ clip packet in the annotation bitstream. The "clip"
tag's "start" attribute tells the Annodex encoder at what
- time to insert the clip page into the bitstream. Its "end"
+ time to insert the clip packet into the bitstream. Its "end"
attribute (if present) leads to the creation of another
- clip page at the given end time in the Annodex bitstream,
- unless another clip page starts on the same track beforehand.
- This clip page contains an empty "clip" tag, i.e. a "clip"
+ clip packet at the given end time in the Annodex bitstream,
+ unless another clip packet starts on the same track beforehand.
+ This clip packet contains an empty "clip" tag, i.e. a "clip"
tag without "meta", "a", "img" or "desc" elements and no
attribute values except for a copy of the "track" attribute
from the original "clip" tag.
@@ -1689,17 +1716,17 @@
</t>
<t>The core of a CMML file can be created from the "head" tag taken
- from the secondary header page of the annotation bitstream, and
+ from the secondary header packet of the annotation bitstream, and
from the sequence of "clip" tags extracted from the content of
the annotation bitstream. A decoder MUST take care to reinsert
the start time of each "clip" element into the "start" attribute of
the respective CMML "clip" tag. The start time will be calculated
- from the Granule rate in the annotation bos page and the Granule pos
- given in the respective "clip" Ogg page.
+ from the Granule rate in the annotation fisbone packet and the
+ Granule pos given in the respective "clip" Ogg packet.
</t>
<t>If the Annodex bitstream has a non-zero basetime or a non-null
- utc time in the Annodex bos page, a "stream" tag MUST be
+ utc time in the Skeleton ident header, a "stream" tag MUST be
created with these attribute values. That "stream" tag is empty
by default. A ripping application MAY however extract all the data
bitstreams out of the Annodex bitstream into files, and then reference
@@ -1710,14 +1737,15 @@
the logical bitstreams:
<list style="symbols">
<t>the "contenttype" attribute from the "Content-type" Message
- header field of the respecitve bos,</t>
+ header field of the respecitve Skeleton secondary header packet,</t>
<t>the "granulerate" attribute from the Granulerate fields of
- the respecitive bos,</t>
+ the respecitive Skeleton secondary header packet,</t>
<t>the "id" attribute from a Message header field called "ID"
if available,</t>
<t>and "param" elements from all the remaining Message header fields
- of the respective bos, where the field name gets stored in the
- "name" attribute and the value in the "value" attribute.</t>
+ of the respective Skeleton secondary header packet, where the field
+ name gets stored in the "name" attribute and the value in the
+ "value" attribute.</t>
</list>
</t>
--
silvia
More information about the cvs-annodex
mailing list