Errata *

1 Introduction *

2 ASF Features *

3 File Format Organization *

4 Additional Considerations *

5 ASF Header Object *

6 Data Object *

7 Index Object *

8 Standard ASF Media Types *

9 Bibliography *

Appendix A: ASF GUIDs *

Appendix B: Bit Stream Types *

Appendix C: GUIDs and UUIDs *

2. Introduction
1. Disclaimer

This document presumes a basic level of multimedia and networking knowledge on the part of the reader. Anyone not familiar with basic multimedia concepts such as audio and video compression, multimedia synchronization, and so on. may misunderstand some of the terminology or arguments presented in this document.

2. What is ASF?

Advanced Streaming Format (ASF) is an extensible file format designed to store synchronized multimedia data. It supports data delivery over a wide variety of networks and protocols while still proving suitable for local playback. The explicit goal of ASF is to provide a basis for industry-wide multimedia interoperability, with ASF being adopted by all major streaming solution providers and multimedia authoring tool vendors.

Each ASF file is composed of one or more media streams. The file header specifies the properties of the entire file, along with stream-specific properties. Multimedia data, stored after the file header, references a particular media stream number to indicate its type and purpose. The delivery and presentation of all media stream data is synchronized to a common timeline.

The ASF file definition includes the specification of some commonly used media types (see Section 8). The explicit intention is that if an implementation supports media types from within this set of standard media types (in other words, audio, video, image, timecode, text, MIDI, command, or media object), then that media type must be supported in the manner described in Section 8 if the resulting content is to be considered to be “content compliant” with the ASF specification. Implementations are free to support other media types (in addition to the currently defined standard media types) in any way they see fit.

Finally, ASF is said to support the transmission of “live content” over a network. This refers to multimedia content which may or may not ever become recorded upon a persistent media source (for example, a disk, CD-ROM, DVD, etc). This use explicitly and solely means that information describing the multimedia content must have been received before the multimedia data itself is received (in order to interpret the multimedia data), and that this information must convey the semantics of the ASF Header Object. Similarly, the received data must conform to the format of the ASF data units. No additional information should be conveyed by this term. Specifically, this use explicitly does not refer to (or contain) any information about network control protocols or network transmission protocols. It refers solely to the order of information arrival (header semantics before data) and the data format .

3. Design Goals

1. Scope

1. ASF Features
1. Extensible Media Types

ASF files permit authors to easily define new media types. The ASF format provides sufficient flexibility to allow the definition of new media stream types that conform to the file format definition. Each stored media stream is logically independent from all others unless a relationship to another media stream has been explicitly established in the file header.

2. Component Download

Stream-specific information about playback components (for example, decompressors and renderers) can be stored in the file header. This information enables each client implementation to retrieve the appropriate version of the required playback component if it is not already present on the client machine.

3. Scalable Media Types

ASF is designed to express the dependency relationships between logical “bands” of scalable media types. It stores each band as a distinct media stream. Dependency information among these media streams is stored in the file header, providing sufficient information for clients to interpret scalability options (such as spatial, temporal, or quality scaling for video) in a compression-independent manner.

4. Author-specified Stream Prioritization

Modern multimedia delivery systems can dynamically adjust to changing constraints (for example, available bandwidth). Authors of multimedia content must be able to express their preferences in terms of relative stream priorities as well as a minimum set of streams to deliver. Stream prioritization is complicated by the presence of scalable media types, since it is not always possible to determine the order of stream application at authoring time. ASF allows content authors to effectively communicate their preferences, even when scalable media streams are present.

5. Multiple Languages

ASF is designed to support multiple languages. Media streams can optionally indicate the language of the contained media. This feature is typically used for audio or text streams. A multilingual ASF file indicates that a set of media streams contains different language versions of the same content, allowing an implementation to choose the most appropriate version for a given client.

6. Bibliographic Information

ASF provides the capability to maintain extensive bibliographic information in a manner that is highly flexible and very extensible. All bibliographic information is stored in the file header in Unicode and is designed for multiple language support, if needed. Bibliographic fields can either be predefined (for example, author and title) or author-defined (for example, search terms). Bibliographic entries can apply to either the whole file or a single media stream.

2. File Format Organization
1. ASF Object definition

The base unit of organization for ASF files is called the ASF Object. It consists of a 128-bit globally unique identifier (GUID) for the object, a 64-bit integer object size, and variable length object data. The value of the object size field is the sum of 24 bytes plus the size of the object data in bytes.



Figure 1 ASF Object

This unit of file organization is similar to the Resource Interchange File Format (RIFF) chunk, which is the basis for AVI and WAV files. The ASF object enhances the design of the RIFF chunk in two ways. First, there is no need for a central authority to manage the object identifier system, since any computer with a network card can generate valid, unique GUIDs (see Appendix C). Second, the object size has been chosen to be large enough to handle the very large files needed for high-bandwidth multimedia content.

All ASF objects and structures (including data unit headers) are stored in little-endian byte order (the inverse of network byte order). However, ASF files can contain media stream data in either byte order within the data unit.

2. High-level File Structure

ASF files are logically composed of three top-level objects: the Header Object, the Data Object, and the Index Object. The Header Object is mandatory and must be placed at the very beginning of every ASF file. The Data Object is also mandatory, and should normally follow the Header Object. The Index Object is optional, but it is strongly recommended that it be used.

Implementations will support files containing out-of-order objects, but in certain cases the resulting ASF files will not be usable from certain sources such as HTTP servers. Also, additional top-level objects may be defined by implementations and inserted into ASF files. It is recommended that they follow the Index Object (in object placement order).

A requirement of ASF is that the Header Object must have been received for the contents of the Data Object to be interpreted. ASF does not address how this information arrives at the client. Rather, “arrival mechanisms” are deemed to be a “local implementation issue,” which is explicitly out of the scope of the file specification. It is similarly a local implementation issue whether or not the Header Object is transferred “in band” or “out of band” (vis-a-vis the Data Object’s data units) or whether the Header Object is sent once or is repeatedly sent. Implementations may choose to meet this order requirement (in other words, the Header Object must arrive before ASF data units can be interpreted) in many possible ways including: (A) include the Header Object information as part of the “session announcement”; (B) send the Header Object in a different “channel” (for example, link) than the data object; (C) send the Header Object immediately before the ASF data units; and so on.

 



Figure 2. High-level ASF File Structure

3. ASF Header Object

1. ASF Data Object

The Data Object contains all the multimedia data of an ASF file. This data is stored in the form of ASF data units. Each ASF Data Unit is of variable length, and contains data for only one media stream. Data units are sorted within the Data Object based on the time at which they should be delivered (send time). This sorting results in an interleaved data format.

2. ASF Index Object

The Index Object contains a time-based index into the multimedia data of an ASF file. The time interval that each index entry represents is set at authoring time and stored in the Index Object. Since it is not required to index into every media stream in a file, a list of the media streams that are indexed follows the time interval value.

Each index entry consists of one data unit offset per media stream being indexed. This information allows stream-specific index operations to occur.

3. Minimal Implementation

1. Additional Considerations
1. Time Units

All time fields in ASF objects and ASF data units use the same timeline, which begins at time zero. Send Times (see Section 4.2) are expressed in granularities of milliseconds. Presentation Times (see Section 4.2) are expressed in Rational Time units. Other timecode systems (such as SMPTE) are supported through the use of a timecode media stream that binds alternate timecode values to each data unit (see Section 8.4). This stream binding is achieved using the Inter-Media Dependency Object. This allows authoring and editing tools to keep alternate timestamps while permitting client/server implementations to ignore them. In all cases, all time references are to the same timeline.

2. Send Time vs. Presentation Time

ASF Data Units all contain a millisecond timestamp, which is called the data unit’s send time. This is the time on the ASF timeline at which this data unit should be delivered to the client. Sometimes, the media stream can explicitly store the fixed delta between send time and presentation time in the Stream Properties Object. If so, every data unit for that stream is presented at exactly the same amount of time after being sent. If this delta is zero, then the send time is equivalent to the presentation time. Otherwise, the data unit stores the presentation time in the data unit itself as either a delta value from the send time or as an explicit presentation timestamp. Using data unit-specific presentation times provides increased flexibility to authoring tools to reduce a stream’s maximum bandwidth requirement by sending data before it is needed.

Unlike Send Time, Presentation Time is specified in Rational Time units, thereby permitting finer time granularities than is possible for millisecond units. The numerator and denominator values by which the specific Rational Time units are computed for each media stream are established in that media stream’s Stream Properties Object.

3. Scalable Media Types

Information about each scalable media source (for example, audio or video) is stored in a Scalable Object in the header. If multiple types of scalable media are present in one ASF file, the header will contain multiple Scalable Objects.

Each Scalable Object contains the dependency information for all media streams that comprise bands of the same media source. Also included within the Scalable Object is an author-specified default sequence in which the media stream bands should be applied. This information is useful if a client is unable or unwilling to resolve the user’s scalability preferences. The sequence also specifies the enhancement type of each media stream band. For scalable video, there are three common enhancement types: spatial (increasing frame size), temporal (increasing frame rate), and quality (increasing image quality without resizing). Similarly, scalable audio has number of channels (for example, stereo), frequency response, and quality. Additional user-defined enhancement types may also be defined.

4. Multimedia Composition

One of ASF’s design goals is to be independent of any particular multimedia composition system. No information is provided in the ASF format concerning three-dimensional positions of streams or relative positioning information between streams. Using the Stream Group Object, ASF provides a general mechanism to group logically related media streams. Implementations will then determine how to render these streams (for example, the relative positioning of the grouped streams, stream mixing, Z-ordering and all other compositional issues, etc) by a mechanism that is outside scope of this file specification. This determination may be based on “out-of-band” techniques such as end user input, the client environment itself, or information contained within the media streams themselves (for example, MPEG-4, streaming Dynamic HTML content, and so on.).

It is anticipated that several different composition approaches can coexist and leverage the same piece of ASF content. An example is a TV scenario in which two video streams are grouped separately. One contains a large image of the anchorperson against a backdrop, and the other contains smaller footage of a news story. While the size of each rendering site could be calculated based on the natural size of each video stream in the group, the fact that the news story should be overlaid on the top right corner of the anchorperson video can not be determined without external composition information.

2. ASF Header Object

This section defines the various objects that comprise the ASF Header Object.

---

1. Header Object

Mandatory: Yes

Quantity: 1 only

Field Name	Field Type	Size (bits)
Object ID	GUID	128
Object Size	UINT	64

Notes:

The Header Object is a container that can hold any combination of the following standard objects. Only the File Properties Object and the Stream Properties Object are required to be present. In addition, (non-standard) header objects that conform to the ASF Object Structure (see Section 3.1) may also be optionally defined and used as extension mechanisms for local implementations. Unlike the standard header objects defined below, there is no guarantee that the non-standard objects will be interpretable across vendor implementations. Implementations should ignore any non-standard object that they do not understand.

---

2. File Properties Object

1. Stream Properties Object

1. Data Unit Extension Object

Extension System is a GUID identifier of the type of information being stored within the Extension Data field of the ASF Data Unit (see Section 6.1).

1. Content Description Object

1. Script Command Object

Mandatory: No

Quantity: 0 or 1

This object provides a list of Type/Parameter pairs of Unicode strings that are synchronized to the ASF file’s timeline. Types can include “URL” or “FILENAME.” These semantics and use of types are identical to the Command Media Type (see Section 8.7). Other Type values may also be freely defined and used. The semantics and treatment of this latter set of Types are defined by the local implementations. The Parameter value (referred to as “Commands” below) is specific to the type field. This Type/Parameter pairing can be used for many purposes, including sending URLs to be "launched" by a client into an HTML frame (in other words, the “URL” type) or launching another ASF file for chained “continuous play” audio or video presentations (in other words, the “FILENAME” type). This object can also be used as an alternative method to stream text (in addition to the Text Media Type) as well as to provide “script commands” that can be used to control elements within the client environment.

Object Structure:

Field Name	Field Type	Size (bits)
Object ID	GUID	128
Object Size	UINT	64
Type Count	UINT	16
Command Count	UINT	16
Types	See below	?
Commands	See below	?

Type:

Field Name	Field Type	Size (bits)
Type Name Length	UINT	16
Type Name	Unicode (UINT16)	?

Command:

Field Name	Field Type	Size (bits)
Presentation Time	UINT	32
Type Index	UINT	16
Command Name Length	UINT	16
Command Name	Unicode (UINT16)	?

Notes:

Presentation Time is given in millisecond granularities.

Types are stored as an array of Unicode strings, since they will typically be reused. Commands specify their type using a zero-based index into the array of Types.

The Type Name Length field indicates the number of Unicode “characters” that are found within the Type Name field. The Command Name Length field indicates the number of Unicode “characters” that are found within the Command Name field.

---

2. Marker Object

Mandatory: No

Quantity: 0 or 1

This object contains a small, specialized index which is used to provide named “jump points” within a file. This allows a content author to divide a piece of content into logical sections such as song boundaries in an entire CD or topic changes during a long presentation, and to assign a human-readable name to each section of a file. This index information is then available to the client to permit the user to “jump” directly to those points within the presentation.

Object Structure:

Field Name	Field Type	Size (bits)
Object ID	GUID	128
Object Size	UINT	64
Index Specifier Count	UINT	16
Marker Count	UINT	16
Index Specifiers	See Section 5.14	?
Markers	See below	?

Marker:

Field Name	Field Type	Size (bits)
Presentation Time	UINT	32
Offsets	UINT64	?
Marker Name Count	UINT	16
Marker Names	See below	?

Marker Name:

Field Name	Field Type	Size (bits)
Language ID Index	UINT	16
Marker Name Length	UINT	16
Marker Name	Unicode (UINT16)	?

Notes:

The Index Specifiers are defined within the Index Parameters Object (Section 5.14).

The Presentation Time is in millisecond granularities. This value does not wrap around, which means that markers can only refer to the first 49.7 days of information contained within an ASF file.

Potentially multiple Offsets entries are listed within the Marker structure. The number is determined by the requirement that there must be one Offsets entry in each Marker structure for each Index Specifier entry. Thus, the total size in bits of the Marker’s Offsets field is 64 bits times the value of the Index Specifier Count field. An offset value of 0xFFFFFFFFFFFFFFFF signifies that the entry contains an invalid offset value.

As a space optimization, a 16-bit Language ID Index field has been used. See the Language List Object (Section 5.16) for more details.

The Marker Name Length field indicates the number of Unicode “characters” which are found within Marker Name field.

---

3. Component Download Object

1. Stream Group Object

1. Scalable Object

1. Prioritization Object

1. Mutual Exclusion Object

Mandatory: No

Quantity: 0 - n

This object identifies streams that have a mutual exclusion relationship to each other (in other words, only one of the streams within such a relationship can be streamed – the rest are ignored). There should be one instance of this object for each set of objects that contain a mutual exclusion relationship. The exclusion type is used so that implementations can allow user selection of common choices, such as language.

Object Structure:

Field Name	Field Type	Size (bits)
Object ID	GUID	128
Object Size	UINT	64
Exclusion Type	GUID	128
Stream Number Count	UINT	16
Stream Numbers	UINT16	?

Notes:

The Exclusion Type identifies the nature of that mutual exclusion relationship (for example, language).

The Stream Number Count indicates how many Stream Numbers are in the Stream Numbers list. Each of the media streams in this list is in a mutual exclusion relationship with the others.

---

2. Inter-Media Dependency Object

Mandatory: No

Quantity: 0 or 1

This object provides the capability for an author to identify dependencies between different media types. An example of such a relationship would be to specify that a video effects stream will be presented only if a certain enhancement layer of a video codec is also currently being presented. Another example is binding a timecode media stream to another media stream to provide alternate timecodes for that other stream’s data.

Object Structure:

List of Dependency Info “structures” for any stream involved in an inter-media dependency relationship.

Field Name	Field Type	Size (bits)
Object ID	GUID	128
Object Size	UINT	64
Dependency Record Count	UINT	16
Dependency Records	See Section 5.9	?

Notes:

The Dependency Record structure is given in Section 5.9.

The Dependency Record Count indicates the number of Dependency Records present.

Should multiple dependencies be listed within the Dependent Stream Numbers fields of a single Dependency Record, these dependencies are in a Boolean AND relationship to each other (in other words, the stream number is dependent upon x AND y). Boolean OR relationships (in other words, the stream number is dependent upon x OR y) are indicated by having multiple Dependency Record entries, each having the same Stream Number value in the Stream Number field of the Dependency Record. Streams that are dependent upon either one stream or another, or optionally both, are said to be in an OR dependency relationship.

---

3. Rating Object

Mandatory: No

Quantity: 0 or 1

This object contains W3C-defined Platform for Internet Content Selection (PICS) information (see references [1] and [2]). PICS establishes Internet conventions for label formats. It thus provides a basis for specifying the rating of the multimedia content within an ASF file. This object does not specify the specific rating service that is to be used. The content creator is consequently able to use the rating service of their choice, as long as it is specified according to the PICS conventions.

Object Structure:

Field Name	Field Type	Size (bits)
Object ID	GUID	128
Object Size	UINT	64
PICS Data	UINT8	?

Note:

PICS information is stored as opaque data in an RFC 822-conformant format (see reference [3]).

---

4. Index Parameters Object

Mandatory: Yes if index is present in file; Otherwise no.

Quantity: 0 or 1

This object supplies a sufficient amount of information to regenerate the index for an ASF file should the original index have been omitted or deleted. It includes only information about those streams that are actually indexed (there must be at least one stream in an index).

Object Structure:

Field Name	Field Type	Size (bits)
Object ID	GUID	128
Object Size	UINT	64
Index Entry Time Interval	UINT	32
Index Specifier Count	UINT	16
Index Specifiers	See below	?

Index Specifier:

Field Name	Field Type	Size (bits)
Stream Number	UINT	16
Index Type	UINT	16

Notes:

The Index Entry Time Interval is in milliseconds.

The Index Specifier Count field identifies how many Index Specifier entries exist within the Index Specifiers field.

Every Index Type requires all index entry offsets to be to a data unit boundary of an ASF Data Unit containing data for the specified Stream Number. Also, the send time of that data unit must not exceed the time of the index entry, which is a presentation time.

Index Type values are as follows: 1 = Nearest Data Unit, 2 = Nearest Object, and 3 = Nearest Clean Point. The Nearest Data Unit indexes point to the data unit whose presentation time is closest to the index entry time. The Nearest Object indexes point to the closest data unit containing an entire object or first fragment of an object. The Nearest Clean Point indexes point to the closest data unit containing an entire object (or first fragment of an object) that has the Clean Point Flag set.



---

5. Color Table Object

Mandatory: No

Quantity: 0 to n

This object contains a color table that is used by one or more media streams. For purposes of reference, each color table is given a unique identifier for reference purposes.

Object Structure:

Field Name	Field Type	Size (bits)
Object ID	GUID	128
Object Size	UINT	64
Color Table ID	GUID	128
Color Table Record Count	UINT	16
Color Table Record	See below	?

Color Table Record:

Field Name	Field Type	Size (bits)
Red	UINT	8
Green	UINT	8
Blue	UINT	8

Note:

The structure consists of a list of Color Table Records, which contain RGB triplets.

---

0. Language List Object

1. Data Object

Mandatory: Yes

Quantity: 1

This object contains all of the ASF Data Units for a file. These data units are organized in terms of increasing send times. An ASF Data Unit contains data from only one media stream. This data may consist of an entire object from that stream. Alternatively, it can consist of a partial object of that stream (fragmentation) or several concatenated objects from that stream (grouping).

The structure of the data object contains the following two fields, which are immediately followed by one or more instances of ASF Data Units.

Field Name	Field Type	Size (bits)
Object ID	GUID	128
Object Size	UINT	64

 

1. ASF Data Unit Definition

1. ASF Data Unit Examples

The following examples are provided to help explain how the data unit format may appear in various usage scenarios. In each case excerpts from the example Stream Properties Object must be included, since they determine the actual data unit composition. Also, it is assumed in all examples that the Huge Data Units Flag within the File Properties Object has been cleared.

 

1. Complete Key Frame Example:

The Presentation Time Flags in the Stream Properties Object specify that the Presentation Delta is in the data units (in other words, value “10”). The Extension Data Size value (of the Data Unit Extension Object) is 2.

The following is an example data unit for the case where the Object Number is 5, the Send Time is 5000, and the Presentation Time is 5750:

Field Name	Field Size (bytes)	Field Value
Data Unit Length	2	1014
Stream Number	2	1
Send Time	4	5000
Data Unit Flags	1	0x02
Object Number	1	5
Presentation Time	2	750
Extension Data	2	Opaque
Data Unit Data	1000	Opaque

 

2. Partial JPEG Example:

The Presentation Time Flags in the Stream Properties Object specify that presentation times are not used (value “00”). The Extension Data Size value (of the Data Unit Extension Object) is 0.

The following is an example data unit for the case where bytes 1000 through 1799 are being sent for a 4000-byte-long JPEG image at a Send Time of 7000. The Object Number of this JPEG image is 17.

Field Name	Field Size (bytes)	Field Value
Data Unit Length	2	814
Stream Number	2	2
Send Time	4	7000
Data Unit Flags	1	0x06
Object Number	1	17
Offset Into Object	2	1000
Object Size	2	4000
Data Unit Data	800	Opaque

 

3. Three Delta Frames Example

1. Index Object

Mandatory: No, but strongly recommended

Quantity: 0 or 1

This top-level ASF object supplies the necessary indexing information for an ASF file. It includes stream-specific indexing information based on an adjustable index entry time interval. The index is designed to be broken into blocks to facilitate storage that is more space-efficient by using 32-bit offsets relative to a 64-bit base. That is, each index block has a full 64-bit offset in the block header, which is added to the 32-bit offsets found in each index entry. If a file is larger than 2^32 bytes, then multiple index blocks can be used to fully index the entire large file while still keeping index entry offsets at 32 bits.

Indices into the Index Object are in terms of Presentation Times. The corresponding Offset field values (of the Index Entry, see below) are byte offsets that, when combined with the Index Block's Block Position value, indicate the starting location of an ASF Data Unit.

The Index Object is not recommended to be used for files where the Send Time of the first Data Unit within the Data Object has a Send Time value significantly greater than zero (otherwise the index itself will be sparse and inefficient). In such cases, an offset value of 0xFFFFFFFF is used to indicate an invalid offset value. Invalid offsets signify that this particular index entry does not identify a valid indexable point. Invalid offsets may occur for the initial index entries of a media stream whose first ASF Data Unit has a non-zero send time.

Object Structure:

Field Name	Field Type	Size (bits)
Object ID	GUID	128
Object Size	UINT	64
Index Entry Time Interval	UINT	32
Index Specifier Count	UINT	16
Index Specifiers	See Section 5.14	?
Index Block Count	UINT	32
Index Blocks	See below	?

Index Block:

Field Name	Field Type	Size (bits)
Block Position	UINT	64
Index Entry Count	UINT	32
Index Entries	See below	?

Index Entry:

Field Name	Field Type	Size (bits)
Offsets	UINT32	?

Notes:

Block Position is the byte offset of the beginning of this block relative to the beginning of the first Data Unit (i.e., the beginning of the Data Object + 24 bytes).

Index Entry Count is the number of Index Entries in the block.

The size of the Offsets field within each Index Entry structure is 32 bits multiplied by the value of the Index Specifier Count field. For example, if the Index Specifier Count is 3, then there are three 32-bit offsets in each Index Entry. Index Entry offsets are ordered according to the ordering specified by the Index Parameters Object, thereby permitting the same stream to be potentially indexed by multiple Index Types (e.g., Nearest Clean Point, Nearest Object, Nearest Data Unit).

The Index Entry Time Interval has a millisecond granularity.

3. Standard ASF Media Types

1. Scrambled Audio

3. Video Media Type

Type-Specific Data:

Field Name		Field Type		Size (bits)
Codec ID		GUID		128
Color Table ID		GUID		128
Average Frame Rate		FLOAT		64
Average Key Frame Rate		FLOAT		64
Maximum Key Frame Rate		FLOAT		64
Average Frame Size		UINT		32
Maximum Frame Size		UINT		32
Flags		UINT		16
Reserved			16
Encoded Image Width		UINT		16
Encoded Image Height		UINT		16
Display Image Width		UINT		16
Display Image Height		UNIT		16
Color Depth		UINT		16
Codec Specific Data Size		UINT		16
Codec Specific Data		UINT8		?

Media Stream Format:

Output of a codec or sampling device.

Notes:

The Encoded/Display Image Width/Height is in pixels.

The Average Key Frame Rate and the Maximum Key Frame Rate are able to indicate very slow rates as a fractional value. For example, a frame rate of one frame every 8 seconds would be shown as 0.125.

Key Frames are also known as Clean Points within the ASF Data Unit (see Section 6.1). Key Frames are known as I-Frames in MPEG terminology.

4. Image Media Type

Type-Specific Data:

Field Name		Field Type		Size (bits)
Codec ID		GUID		128
Color Table ID		GUID		128
Maximum Image Size		UINT		32
Encoded Image Width		UINT		16
Encoded Image Height		UINT		16
Display Image Width		UINT		16
Display Image Height		UINT		16
Flags		UINT		16
Reserved			16
Color Depth		UINT		16
Codec Specific Data Size		UINT		16
Codec Specific Data		UINT8		?

 

Media Stream Format:

The data contents of one or more logical Image files.

Notes:

The following Image Types must be supported on all ASF clients: Loss-Tolerant JPEG and JPEG. Other Image Types may also be optionally supported. [Note: Loss-Tolerant JPEG is a Microsoft-defined JPEG variant that will be described in a future version of this document.]

The Codec ID will include GUIDs for many image formats, including Loss-Tolerant JPEG, GIF, and JPEG.

The Color Table ID is used to indicate the palette when Color Depth is 8 bpp.

The Encoded/Display Image Width/Height is in pixels.

The Maximum Image Size is specified in bytes.

The existence, content, and size of Codec Specific Data is keyed off of the Codec ID.

 

5. Timecode Media Type

Type-Specific Data:

Field Name	Field Type	Size (bits)
Timecode ID	GUID	128

Media Stream Format:

Timecodes of the type indicated by the Timecode ID.

Notes:

The Timecode ID will contain GUIDs for SMPTE.

It is expected that a timecode media stream will be bound to specific other media streams by means of the Inter-Media Dependency object. This will provide a basis for establishing (non-mathematic) SMPTE timecode for that media stream (in other words, Rational Presentation Times solely are able to establish mathematically based timecodes). For example, if an SMPTE timecode is bound to a video stream, entries with the same send times in the two streams are paired, thereby permitting SMPTE timecodes to be given to that video stream.

 

6. Text Media Type

Text Media shall be streamed as NULL-terminated streams.

1. MIDI Media Type

The goals for the definition of the MIDI media type were to incur minimal overhead for MIDI data while maintaining extensibility for future enhancements. Also, it was desirable to enable reasonable granularity seeking operations within MIDI streams. We believe that this proposal meets the stated objectives.

Minimal overhead is present in the definition of the MIDI event structure (see the Media Stream Format section below). Usually, only two bytes more than MIDI’s standard overhead is required, while maintaining a more accurate timing model.

Extensibility is built in through an event class system, which permits the mapping and assignment of globally unique identifiers (GUIDs) to the integer-based event classes contained in a MIDI stream.

Seeking operations are supported through an expanded use of the Clean Point concept. On some interval throughout a seekable MIDI stream, objects will need to begin with what is termed “Clean Point Info” events. These events will serve to re-establish the state of patch changes and controllers at that point in the MIDI stream. Those objects that contain this Clean Point Info can then be marked using the Clean Point Flag in the ASF data unit definition, and indexed using the normal ASF Index. During the course of normal streaming playback, these redundant Clean Point Info events are ignored. When seeking, the client uses these events to re-establish the current state of patches and controllers. An exact list of which controllers’ state should be preserved is TBD.

Type-Specific Data:

Field Name		Field Type		Size (bits)
Flags		UINT		16
Extended Classes			1 (LSB)
Extended Channels			1
Reserved			14
Event Class Count		UINT		16
Event Classes		GUID		?

Notes:

The Extended Classes Flag means that every MIDI event in this stream uses the 8 bit Extended Event Class field (see below) to extend the number of possible event classes from 63 to 16383 (by extending the event class space from 6 bits to 14 bits).

The Extended Channels Flag means that every MIDI event in this stream is followed by a byte that contains an additional 8 bits of MIDI channel information, permitting the use of 4096 channels instead of just the traditional 16 channels.

The Event Classes list of GUIDs contains the mapping used for this particular stream from the GUID identifiers for MIDI event classes to the integers used in this stream. The first entry in this list is given the integer value 1 (one), since 0 (zero) is reserved to indicate a standard MIDI event.

It is expected that MIDI streams will have the Reliable Flag set in their Stream Properties Object, as the loss of MIDI data generally leads to undesirable and unpredictable results.

 

Media Stream Format:

Each object within a MIDI stream will contain an array of the following MIDI Event structures:

Field Name		Field Type		Size (bits)
Presentation Time Delta		UINT		16
		UINT		8
Event Size Present			1 (LSB)
Clean Point Event			1
Event Class			6
Extended Event Class		UINT		0 or 8
Event Size		UINT		0 or 32
MIDI Event		UINT8		?
Extended Channel Info		UINT		0 or 8

Notes:

The Presentation Time Delta field is stored in units of 100 microseconds (tenths of milliseconds). The 16-bit size of the field, when combined with the chosen time units, permits ASF MIDI objects to contain up to 6.5535 seconds worth of MIDI data in a single object. The delta is based on the explicit or implicit Presentation Time value of the object in the ASF MIDI stream. Each event stores an individual time delta from the base presentation time of the object (for ease of manipulation), so the resulting presentation time for every single MIDI event in the same object can be computed as object presentation time + presentation time delta. All MIDI events in a single object must be stored in sorted order of increasing presentation time deltas.

The Event Size Present field is used to indicate that an explicit 32-bit event size field is being used in this particular event. This will typically be useful for SYSEX events whose lengths can not be predicted. If not present, the size of the MIDI Event field must be implicitly determined based on the event’s contents. In the case of a standard MIDI event (with Event Class == 0), a simple table can be used to map from MIDI status byte values to the overall size of the MIDI event data. Recall that if the stream’s Extended Channels flag is set, then an Extended Channel Info byte follows the standard MIDI event.

The Clean Point Event field indicates that this particular MIDI event should only be processed if received immediately following a seek operation. Otherwise, client implementations should skip this event.

The Event Class field is used as a 1-based index into the Event Classes list of GUIDs stored in the stream header. Event Class 0 (zero) is reserved to indicate a Standard MIDI event. The Extended Event Class field is used to expand the number of simultaneously permissible event classes for a particular stream from 63 to 16383 by extending the number of event class bits from 6 to 14. It occurs only if the Extended Classes flag is set in the stream header.

The Event Size field is used only if the Event Size Present field is set, as was previously mentioned.

MIDI running status can be used between the events contained within one individual ASF object (or buffer), but should not cross object boundaries. This recommendation is designed to simplify client playback resource requirements and implementations.

 

2. Command Media Type

Type-Specific Data:

Field Name	Field Type	Size (bits)
Command Type	GUID	128

Media Stream Format:

The data of URL Command Types complies with the URL format strings as defined in RFC 1738 and RFC 2017. These strings shall be NULL terminated ASCII strings. Frame values are indicated by a “&” delimiter according to the following syntax: “& frame & URL \0”.

The data of the FILENAME Command Type either complies with the URL Command Type format or else the format used on the local operating system to indicate ASCII filenames.

Notes:

There are two standard Command Type GUIDs: URL and FILENAME. The URL command indicates that the URL is to be “launched” by a client into an HTML window or frame. The FILENAME command indicates the ASF file indicated is to be played immediately (for example, for “continuous play” environments).

It is required that all ASF implementations support fully specified URLs for both URL and FILENAME uses. Relative path URLs may be optionally supported. The use of Local URLs (in other words, those containing O/S dependent references such as drive letters) is discouraged but not prohibited.

3. Media-Objects (Hotspot) Media Type

1. Bibliography

[1] T. Krauskopf, J. Miller, P. Resnick, and G. W. Treese, “Label Syntax and Communication Protocols,” World Wide Web Consortium http://www.w3.org/PICS/labels.html, May 5 1996.

[2] J. Miller, P. Resnick, and D. Singer, “Rating Services and Rating Systems (and Their Machine Readable Descriptions),” World Wide Web Consortium http://www.w3.org/PICS/services.html, May 5 1996.

[3] D. Crocker, “RFC 822: Standard for the Format of ARPA Internet Text Messages,” ftp://ds.internic.net/rfc/rfc822.txt, August 1982.

[4] H. Alvestrand, “RFC 1766: Tags for the Identification of Languages,” ftp://ds.internic.net/rfc/rfc1766.txt, March 2, 1995.

[5] “MARC Bibliographic Formats,” http://www.fsc.follett.com/data/marctags/.

[6] “Dublin Core Elements,” ftp://ds.internic.net/internet-drafts/draft-kunze-dc-01.txt or http://purl.org/metadata/dublin_core_elements/.

[7] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, “RFC 1889: RTP: A Transport Protocol for Real-Time Applications,” January 1996; ftp://ds.internic.net/rfc/rfc1889.txt.