Tracking: Difference between revisions

From XiphWiki
Jump to navigation Jump to search
 
Line 95: Line 95:
The media mapping for Tracking into Ogg is as follows:
The media mapping for Tracking into Ogg is as follows:
* The bos page contains a Tracking ident packet.
* The bos page contains a Tracking ident packet.
* The next page contains all metadata each encoded in their own packet.
* The content or data packets contain the "data" tags each encoded in their own packet and inserted at the accurate time.
* The content or data packets contain the "data" tags each encoded in their own packet and inserted at the accurate time.
* The eos page contains a packet with an empty data tag.
* The eos page contains a packet with an empty data tag.
Line 114: Line 115:
  | ...
  | ...


The Tracking<i>version</i> as described here is major=0 minor=1.
The Tracking<i>version</i> as described here is major=0 minor=1.


=== The Tracking data packets ===
=== The Tracking data packets ===
Line 131: Line 132:
  | </data>                                                      |
  | </data>                                                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


== Development ==
== Development ==

Latest revision as of 04:03, 9 August 2011

Tracking is a timed text codec. It allows to localize a time-continuously sampled data file by providing geolocalisation from a GPS device. This geolocalisation is NMEA sentences and multimedia players have to parse them to extract informations (position, speed, orientation, satellites informations, ...).

Tracking is appropriate for use with all Ogg media formats. This description explains how to map Tracking into Ogg.


Tracking specification

Before describing the actual data that goes into a logical Ogg bitstream, we need to understand what the stand-alone "codec" packets contains.

Tracking basically consists of data elements which contains NMEA sentences

An example Tracking file looks like this:

<?xml version="1.0"?>
<track xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="track.xsd">
	<metadata key="key1">value1</metadata>
	<metadata key="key2"><![CDATA[value2]]></metadata>
	<data position="0">
		$GPRMC,162254.00,A,3723.02837,N,12159.39853,W,0.820,188.36,110706,,,A*74
		$GPVTG,188.36,T,,M,0.820,N,1.519,K,A*3F
		$GPGGA,162254.00,3723.02837,N,12159.39853,W,1,03,2.36,525.6,M,-25.6,M,,*65
		$GPGSA,A,2,25,01,22,,,,,,,,,,2.56,2.36,1.00*02
		$GPGSV,4,1,14,25,15,175,30,14,80,041,,19,38,259,14,01,52,223,18*76
		$GPGSV,4,2,14,18,16,079,,11,19,312,,14,80,041,,21,04,135,25*7D
		$GPGSV,4,3,14,15,27,134,18,03,25,222,,22,51,057,16,09,07,036,*79
		$GPGSV,4,4,14,07,01,181,,15,25,135,*76
		$GPGLL,3723.02837,N,12159.39853,W,162254.00,A,A*7C
		$GPZDA,162254.00,11,07,2006,00,00*63
	</data>
	<data position="1">
		$GPRMC,162254.00,A,3723.02837,N,12159.39853,W,0.820,188.36,110706,,,A*74
		$GPVTG,188.36,T,,M,0.820,N,1.519,K,A*3F
		$GPGGA,162254.00,3723.02837,N,12159.39853,W,1,03,2.36,525.6,M,-25.6,M,,*65
		$GPGSA,A,2,25,01,22,,,,,,,,,,2.56,2.36,1.00*02
		$GPGSV,4,1,14,25,15,175,30,14,80,041,,19,38,259,14,01,52,223,18*76
		$GPGSV,4,2,14,18,16,079,,11,19,312,,14,80,041,,21,04,135,25*7D
		$GPGSV,4,3,14,15,27,134,18,03,25,222,,22,51,057,16,09,07,036,*79
		$GPGSV,4,4,14,07,01,181,,15,25,135,*76
		$GPGLL,3723.02837,N,12159.39853,W,162254.00,A,A*7C
		$GPZDA,162254.00,11,07,2006,00,00*63
	</data>
</track>

The track element (root element) have no required property: This root element contains metadata and data elements.

The metadata elements have one required property:

  • key: the key name

Metadata gives informations about the track: device, weather, date, links, email address, ...

The data elements have one required property:

  • position: the position of the data in the video (in seconds)

A Tracking file must be valid. Here is the XML Schema "track.xsd":

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<xsd:element name="metadata" type="typeMetadata" />
	<xsd:element name="data" type="typeData" />
	<xsd:element name="track" type="typeTrack" />

	<xsd:complexType name="typeMetadata">
		<xsd:simpleContent>
			<xsd:extension base="xsd:string">
				<xsd:attribute name="key" type="xsd:string" use="required" />
			</xsd:extension>
		</xsd:simpleContent>
	</xsd:complexType>

	<xsd:complexType name="typeData">
		<xsd:simpleContent>
			<xsd:extension base="xsd:string">
				<xsd:attribute name="position" type="xsd:string" use="required" />
			</xsd:extension>
		</xsd:simpleContent>
	</xsd:complexType>

	<xsd:complexType name="typeTrack">
		<xsd:sequence>
			<xsd:element ref="metadata" minOccurs="0" maxOccurs="unbounded" />
			<xsd:element ref="data" minOccurs="1" maxOccurs="unbounded" />
		</xsd:sequence>
	</xsd:complexType>
</xsd:schema>

Tracking mapping into Ogg

When Tracking is mapped into an Ogg logical bitstream it needs to be serialised first. XML is a hierarchical file format, so is not generally serialisable. However, Tracking has been designed to be serialised easily.

All of the Tracking bitstream information is text. As it gets encoded into a binary bitstream, an encoding format has to be specified. To simplify things, UTF-8 is defined as the mandatory encoding format for all data in a Tracking binary bitstream.

The media mapping for Tracking into Ogg is as follows:

  • The bos page contains a Tracking ident packet.
  • The next page contains all metadata each encoded in their own packet.
  • The content or data packets contain the "data" tags each encoded in their own packet and inserted at the accurate time.
  • The eos page contains a packet with an empty data tag.


The Tracking ident header packet

The Tracking logical bitstream starts with an ident header which is encapsulated into the Tracking bos page. The ident header contains all information required to identify the Tracking bitstream and to set up a Tracking decoder. It has the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier 'TRCK\0\0\0\0'                                     | 0-3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               | 4-7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version major                 | Version minor                 | 8-11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...

The Trackingversion as described here is major=0 minor=1.

The Tracking data packets

The data packets of the Tracking bitstream contain the Tracking data elements. Their position attributes however only exist for authoring purposes and are not copied into the bitstream (to avoid contradictory information), but are rather represented through the time mapping of the encapsulation format that interleaves Tracking data with data from other time-continuous bitstreams. Generally the time mapping is done through some timestamp representation and through the position in the stream.

A data tag is encoded with all tags (except for the position attribute) as a string printed into a clip packet. The data tag's position attribute tells the encapsulator at what time to insert the clip packet into the bitstream. It duration is one second.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <data ...                                                     | 0-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...                                                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Development

External links

  • NMEA sentences: [1]