idnits 2.17.1 draft-fleischman-asf-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 44) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 75 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 39 instances of too long lines in the document, the longest one being 43 characters in excess of 72. ** There are 67 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 3378: '...he initial value MUST NOT be correlate...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 3576 has weird spacing: '...size of user ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 1998) is 9549 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '5' on line 2959 looks like a reference -- Missing reference section? '6' on line 3613 looks like a reference -- Missing reference section? '7' on line 2966 looks like a reference -- Missing reference section? '1' on line 3641 looks like a reference -- Missing reference section? '2' on line 3643 looks like a reference -- Missing reference section? '3' on line 3644 looks like a reference -- Missing reference section? '4' on line 3646 looks like a reference -- Missing reference section? 'HASHLEN' on line 3616 looks like a reference -- Missing reference section? '0' on line 3629 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Eric Fleischman 2 draft-fleischman-asf-01 Microsoft Corporation 3 February 26, 1998 4 Expires: August 26, 1998 6 Advanced Streaming Format (ASF) Specification 8 Status of This Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Distribution of this document is unlimited. 28 Abstract 30 The Advanced Streaming Format (ASF) is an extensible file format 31 designed to store synchronized multimedia data. It supports data 32 delivery over a wide variety of networks and protocols while still 33 proving suitable for local playback. ASF supports advanced multimedia 34 capabilities including extensible media types, component download, 35 scaleable media types, author-specified stream prioritization, multiple 36 language support, and extensive bibliographic capabilities, including 37 document and content management. 39 Table of Contents 41 1 INTRODUCTION 4 42 1.1 WHAT IS ASF? 4 43 1.2 DESIGN GOALS 4 44 1.3 SCOPE 5 46 Internet-draft February 26, 1998 48 2 ASF FEATURES 5 49 2.1 EXTENSIBLE MEDIA TYPES 5 50 2.2 COMPONENT DOWNLOAD 5 51 2.3 SCALABLE MEDIA TYPES 6 52 2.4 AUTHOR-SPECIFIED STREAM PRIORITIZATION 6 53 2.5 MULTIPLE LANGUAGES 6 54 2.6 BIBLIOGRAPHIC INFORMATION 6 55 3 FILE FORMAT ORGANIZATION 6 56 3.1 ASF OBJECT DEFINITION 6 57 3.2 HIGH-LEVEL FILE STRUCTURE 7 58 3.3 ASF HEADER OBJECT 9 59 3.4 ASF DATA OBJECT 9 60 3.5 ASF INDEX OBJECT 9 61 3.6 MINIMAL IMPLEMENTATION 10 62 4 ADDITIONAL CONSIDERATIONS 10 63 4.1 TIME UNITS 10 64 4.2 SEND TIME VS. PRESENTATION TIME 10 65 4.3 SCALABLE MEDIA TYPES 11 66 4.4 MULTIMEDIA COMPOSITION 11 67 5 ASF HEADER OBJECT 12 68 5.1 HEADER OBJECT 12 69 5.2 FILE PROPERTIES OBJECT 12 70 5.3 STREAM PROPERTIES OBJECT 14 71 5.3.1 Data Unit Extension Object 19 72 5.4 CONTENT DESCRIPTION OBJECT 20 73 5.5 SCRIPT COMMAND OBJECT 23 74 5.6 MARKER OBJECT 24 75 5.7 COMPONENT DOWNLOAD OBJECT 26 76 5.8 STREAM GROUP OBJECT 27 77 5.9 SCALABLE OBJECT 29 78 5.10 PRIORITIZATION OBJECT 31 79 5.11 MUTUAL EXCLUSION OBJECT 32 80 5.12 INTER-MEDIA DEPENDENCY OBJECT 33 81 5.13 RATING OBJECT 34 82 5.14 INDEX PARAMETERS OBJECT 34 83 5.15 COLOR TABLE OBJECT 36 84 5.16 LANGUAGE LIST OBJECT 36 85 6 DATA OBJECT 37 86 6.1 ASF DATA UNIT DEFINITION 38 87 6.2 ASF DATA UNIT EXAMPLES 41 88 6.2.1 Complete Key Frame Example: 41 89 6.2.2 Partial JPEG Example: 42 91 Internet-draft February 26, 1998 93 6.2.3 Three Delta Frames Example 42 94 7 INDEX OBJECT 43 95 8 STANDARD ASF MEDIA TYPES 44 96 8.1 AUDIO MEDIA TYPE 45 97 8.1.1 Scrambled Audio 46 98 8.2 VIDEO MEDIA TYPE 47 99 8.3 IMAGE MEDIA TYPE 48 100 8.4 TIMECODE MEDIA TYPE 49 101 8.5 TEXT MEDIA TYPE 49 102 8.6 MIDI MEDIA TYPE 50 103 8.7 COMMAND MEDIA TYPE 53 104 8.8 MEDIA-OBJECTS (HOTSPOT) MEDIA TYPE 53 105 ACKNOWLEDGEMENTS 60 106 SUBMITTER'S ADDRESS 61 107 BIBLIOGRAPHY 61 108 APPENDIX A: ASF GUIDS 61 109 APPENDIX B: BIT STREAM TYPES 64 110 ASCII 64 111 FILETIME 64 112 GUID 65 113 UINT 66 114 UNICODE 66 115 APPENDIX C: GUIDS AND UUIDS 66 116 INTRODUCTION 66 117 MOTIVATION 66 118 SPECIFICATION 67 119 C.1 Format 67 120 C.2 Algorithms for Creating a GUID 69 121 C.3 String Representation of GUIDs 72 122 C.4 Comparing GUIDs 73 123 C.5 Node IDs when no IEEE 802 network card is available 73 124 C.6 Appendix C's References 75 126 Internet-draft February 26, 1998 128 1 Introduction 130 1.1 What is ASF? 132 The Advanced Streaming Format (ASF) is an extensible file format 133 designed to store synchronized multimedia data. It supports data 134 delivery over a wide variety of networks and protocols while still 135 proving suitable for local playback. The explicit goal of ASF is to 136 provide a basis for industry-wide multimedia interoperability, with ASF 137 being adopted by all major streaming solution providers and multimedia 138 authoring tool vendors. 140 Each ASF file is composed of one or more media streams. The file 141 header specifies the properties of the entire file, along with stream- 142 specific properties. Multimedia data, stored after the file header, 143 references a particular media stream number to indicate its type and 144 purpose. The delivery and presentation of all media stream data is 145 synchronized to a common timeline. 147 The ASF file definition includes the specification of some commonly 148 used media types (see Section 8). The explicit intention is that if an 149 implementation supports media types from within this set of standard 150 media types (in other words, audio, video, image, timecode, text, MIDI, 151 command, or media object), then that media type must be supported in 152 the manner described in Section 8 if the resulting content is to be 153 considered to be "content compliant" with the ASF specification. 154 Implementations are free to support other media types (in addition to 155 the currently defined standard media types) in any way they see fit. 157 Finally, ASF is said to support the transmission of "live content" over 158 a network. This refers to multimedia content that may or may not ever 159 become recorded upon a persistent media source (for example, a disk, 160 CD-ROM, DVD, etc). This use explicitly and solely means that 161 information describing the multimedia content must have been received 162 before the multimedia data itself is received (in order to interpret 163 the multimedia data), and that this information must convey the 164 semantics of the ASF Header Object. Similarly, the received data must 165 correspond to the format of the ASF data units. No additional information 166 should be conveyed by this term. Specifically, this use explicitly does 167 not refer to (or contain) any information about network control 168 protocols or network transmission protocols. It refers solely to the 169 order of information arrival (header semantics before data) and the 170 data format. 172 1.2 Design Goals 174 ASF was designed with the following goals: 176 Internet-draft February 26, 1998 178 * To support efficient playback from media servers, HTTP servers, and 179 local storage devices. 180 * To support scalable media types such as audio and video. 181 * To permit a single multimedia composition to be presented over a 182 wide range of bandwidths. 183 * To allow authoring control over media stream relationships, 184 especially in constrained-bandwidth scenarios. 185 * To be independent of any particular multimedia composition system, 186 computer operating system, or data communications protocol. 188 1.3 Scope 190 ASF is a multimedia presentation file format. It supports live and on- 191 demand multimedia content. It can be used as a vehicle to record or 192 play back H.32X (for example, H.323 and H.324) or MBONE conferences. 193 ASF files may be edited. ASF data is specifically designed for 194 streaming and/or local playback. 196 ASF is not: 197 * ASF is not a wire format. Rather, ASF is data communications 198 "agnostic." Theoretically, ASF data units may be carried by any 199 conceivable underlying data communications transport. ASF is 200 similarly agnostic about how the data is packetized by network 201 protocols (for example, whether the multimedia data is sent in an 202 interleaved or non-interleaved fashion). 203 * ASF is not a network control protocol. However, ASF files contain 204 information that should prove useful to control protocols. 205 * ASF is not a replacement for MPEG. Rather, MPEG content can be 206 contained within ASF files and optionally synchronized with other 207 media. 209 2 ASF Features 211 2.1 Extensible Media Types 213 ASF files permit authors to easily define new media types. The ASF 214 format provides sufficient flexibility to allow the definition of new 215 media stream types that conform to the file format definition. Each 216 stored media stream is logically independent from all others unless a 217 relationship to another media stream has been explicitly established in 218 the file header. 220 2.2 Component Download 222 Stream-specific information about playback components (for example, 223 decompressors and renderers) can be stored in the file header. This 224 information enables each client implementation to retrieve the 226 Internet-draft February 26, 1998 228 appropriate version of the required playback component if it is not 229 already present on the client machine. 231 2.3 Scalable Media Types 233 ASF is designed to express the dependency relationships between logical 234 "bands" of scalable media types. It stores each band as a distinct 235 media stream. Dependency information among these media streams is 236 stored in the file header, providing sufficient information for clients 237 to interpret scalability options (such as spatial, temporal, or quality 238 scaling for video) in a compression-independent manner. 240 2.4 Author-specified Stream Prioritization 242 Modern multimedia delivery systems can dynamically adjust to changing 243 constraints (for example, available bandwidth). Authors of multimedia 244 content must be able to express their preferences in terms of relative 245 stream priorities as well as a minimum set of streams to deliver. 246 Stream prioritization is complicated by the presence of scalable media 247 types, since it is not always possible to determine the order of stream 248 application at authoring time. ASF allows content authors to 249 effectively communicate their preferences, even when scalable media 250 streams are present. 252 2.5 Multiple Languages 254 ASF is designed to support multiple languages. Media streams can 255 optionally indicate the language of the contained media. This feature 256 is typically used for audio or text streams. A multilingual ASF file 257 indicates that a set of media streams contains different language 258 versions of the same content, allowing an implementation to choose the 259 most appropriate version for a given client. 261 2.6 Bibliographic Information 263 ASF provides the capability to maintain extensive bibliographic 264 information in a manner that is highly flexible and very extensible. 265 All bibliographic information is stored in the file header in Unicode 266 and is designed for multiple language support, if needed. Bibliographic 267 fields can either be predefined (for example, author and title) or 268 author-defined (for example, search terms). Bibliographic entries can 269 apply to either the whole file or a single media stream. 271 3 File Format Organization. 273 3.1 ASF Object definition 275 The base unit of organization for ASF files is called the ASF Object. 276 It consists of a 128-bit globally unique identifier (GUID) for the 278 Internet-draft February 26, 1998 280 object, a 64-bit integer object size, and variable length object data. 281 The value of the object size field is the sum of 24 bytes plus the size 282 of the object data in bytes. 283 +------------------+ 284 | | 285 16 bytes | Object ID | 286 | | 287 +------------------+ 288 | | 289 8 bytes | Object Size | 290 | | 291 +------------------+ 292 | | 293 | | 294 ?? bytes | Object Data | 295 | | 296 | | 297 | | 298 | | 299 +------------------+ 300 Figure 1: ASF Object 302 This unit of file organization is similar to the Resource Interchange 303 File Format (RIFF) chunk, which is the basis for AVI and WAV files. 304 The ASF object enhances the design of the RIFF chunk in two ways. 305 First, there is no need for a central authority to manage the object 306 identifier system, since any computer with a network card can generate 307 valid, unique GUIDs (see Appendix C). Second, the object size has been 308 chosen to be large enough to handle the very large files needed for 309 high-bandwidth multimedia content. 311 All ASF objects and structures (including data unit headers) are stored 312 in little-endian byte order (the inverse of network byte order). 313 However, ASF files can contain media stream data in either byte order 314 within the data unit. 316 3.2 High-level File Structure 318 ASF files are logically composed of three top-level objects: the Header 319 Object, the Data Object, and the Index Object. The Header Object is 320 mandatory and must be placed at the very beginning of every ASF file. 321 The Data Object is also mandatory, and should normally follow the Header 322 Object. The Index Object is optional, but it is strongly recommended that 323 it be used. 325 Internet-draft February 26, 1998 327 Implementations will support files containing out-of-order objects, but 328 in certain cases the resulting ASF files will not be usable from 329 certain sources such as HTTP servers. Also, additional top-level 330 objects may be defined by implementations and inserted into ASF files. 331 It is recommended that they follow the Index Object (in object 332 placement order). 334 A requirement of ASF is that the Header Object must have been received 335 for the contents of the Data Object to be interpreted. ASF does not 336 address how this information arrives at the client. Rather, "arrival 337 mechanisms" are deemed to be a "local implementation issue," which is 338 explicitly out of the scope of the file specification. It is similarly 339 a local implementation issue whether or not the Header Object is 340 transferred "in band" or "out of band" (vis-a-vis the Data Object's 341 data units) or whether the Header Object is sent once or is repeatedly 342 sent. Implementations may choose to meet this order requirement (in 343 other words, the Header Object must arrive before ASF data units can be 344 interpreted) in many possible ways including: (A) include the Header 345 Object information as part of the "session announcement"; (B) send the 346 Header Object in a different "channel" (e.g., link) than the data 347 object; (C) send the Header Object immediately before the ASF data 348 units; and so on. 350 +----------------------------------+ 351 | Header Object | 352 | +----------------------------+ | 353 | | File Properties Object | | 354 | +----------------------------+ | 355 | | Stream Properties Object 1 | | 356 | +----------------------------+ | 357 | | Stream Properties Object N | | 358 | +----------------------------+ | 359 | | Other Header Objects | | 360 | +----------------------------+ | 361 +----------------------------------+ 362 | Data Object | 363 | +--------------------+ | 364 | | Data Unit | | 365 | +--------------------+ | 366 | | Data Unit | | 367 | +--------------------+ | 368 | | Data Unit | | 369 | +--------------------+ | 370 +----------------------------------+ 371 | Index Object | 372 +----------------------------------+ 373 | Other Objects | 374 +----------------------------------+ 376 Figure 2. High-level ASF File Structure 378 Internet-draft February 26, 1998 380 3.3 ASF Header Object 382 Of the three top-level ASF objects, the Header Object is the only one 383 that contains other ASF objects. The header object may include many 384 objects including the following: 385 * File Properties Object - global file attributes 386 * Stream Properties Object - defines a media stream and its 387 characteristics 388 * Content Description Object - contains all bibliographic information 389 * Component Download Object - provides playback component information 390 * Stream Groups Object - logically groups media streams together 391 * Scalable Object - defines scalability relationships among media 392 streams containing bands 393 * Prioritization Object - defines relative stream prioritization 394 * Mutual Exclusion Object - defines exclusion relationships such as 395 language selection 396 * Inter-Media Dependency Object - defines dependency relationships 397 among mixed media streams 398 * Rating Object - defines the Rating of the file in terms of W3C PICS 399 * Index Parameters Object - supplies the information necessary to 400 regenerate the index of an ASF file 402 The role of the Header Object is to provide a well-known byte sequence 403 at the beginning of ASF files (its GUID) and to contain all other 404 header information. This information provides global information about 405 the file as a whole as well as specific information about the 406 multimedia data stored within the Data Object. 408 3.4 ASF Data Object 410 The Data Object contains all the multimedia data of an ASF file. This 411 data is stored in the form of ASF data units. Each ASF Data Unit is of 412 variable length, and contains data for only one media stream. Data 413 units are sorted within the Data Object based on the time at which they 414 should be delivered (send time). This sorting results in an 415 interleaved data format. 417 3.5 ASF Index Object 419 The Index Object contains a time-based index into the multimedia data 420 of an ASF file. The time interval that each index entry represents is 421 set at authoring time and stored in the Index Object. Since it is not 423 Internet-draft February 26, 1998 425 required to index into every media stream in a file, a list of the 426 media streams that are indexed follows the time interval value. 428 Each index entry consists of one data unit offset per media stream being indexed. This information allows 429 stream-specific index operations to occur. 431 3.6 Minimal Implementation 433 A minimal ASF implementation consists of a Header Object containing 434 only a File Properties Object, one Stream Properties object, and one 435 Language List Object, as well as a Data Object containing only a single 436 ASF data unit. 438 4 Additional Considerations 440 4.1 Time Units 442 All time fields in ASF objects and ASF data units use the same 443 timeline, which begins at time zero. Send Times (see Section 4.2) are 444 expressed in granularities of milliseconds. Presentation Times (see 445 Section 4.2) are expressed in Rational Time units. Other timecode 446 systems (such as SMPTE) are supported through the use of a timecode 447 media stream that binds alternate timecode values to each data unit 448 (see Section 8.4). This stream binding is achieved using the Inter- 449 Media Dependency Object. This allows authoring and editing tools to 450 keep alternate timestamps while permitting client/server 451 implementations to ignore them. In all cases, all time references are 452 to the same timeline. 454 4.2 Send Time vs. Presentation Time 456 ASF Data Units all contain a millisecond timestamp, which is called the 457 data unit's send time. This is the time on the ASF timeline at which 458 this data unit should be delivered to the client. Sometimes, the media 459 stream can explicitly store the fixed delta between send time and 460 presentation time in the Stream Properties Object. If so, every data 461 unit for that stream is presented at exactly the same amount of time 462 after being sent. If this delta is zero, then the send time is 463 equivalent to the presentation time. Otherwise, the data unit stores 464 the presentation time in the data unit itself as either a delta value 465 from the send time or as an explicit presentation timestamp. Using data 466 unit-specific presentation times provides increased flexibility to 467 authoring tools to reduce a stream's maximum bandwidth requirement by 468 sending data before it is needed. 470 Unlike Send Time, Presentation Time is specified in Rational Time 471 units, thereby permitting finer time granularities than is possible for 473 Internet-draft February 26, 1998 475 millisecond units. The numerator and denominator values by which the 476 specific Rational Time units are computed for each media stream are 477 established in that media stream's Stream Properties Object. 479 4.3 Scalable Media Types 481 Information about each scalable media source (for example, audio or 482 video) is stored in a Scalable Object in the header. If multiple types 483 of scalable media are present in one ASF file, the header will contain 484 multiple Scalable Objects. 486 Each Scalable Object contains the dependency information for all media 487 streams that comprise bands of the same media source. Also included 488 within the Scalable Object is an author-specified default sequence in 489 which the media stream bands should be applied. This information is 490 useful if a client is unable or unwilling to resolve the user's 491 scalability preferences. The sequence also specifies the enhancement 492 type of each media stream band. For scalable video, there are three 493 common enhancement types: spatial (increasing frame size), temporal 494 (increasing frame rate), and quality (increasing image quality without 495 resizing). Similarly, scalable audio has number of channels (for 496 example, stereo), frequency response, and quality. Additional user- 497 defined enhancement types may also be defined. 499 4.4 Multimedia Composition 501 One of ASF's design goals is to be independent of any particular 502 multimedia composition system. No information is provided in the ASF 503 format concerning three-dimensional positions of streams or relative 504 positioning information between streams. Using the Stream Group Object, 505 ASF provides a general mechanism to group logically related media 506 streams. Implementations will then determine how to render these 507 streams (for example, the relative positioning of the grouped streams, 508 stream mixing, Z-ordering and all other compositional issues, etc) by a 509 mechanism that is outside scope of this file specification. This 510 determination may be based on "out-of-band" techniques such as end user 511 input, the client environment itself, or information contained within 512 the media streams themselves (for example, MPEG-4, streaming Dynamic 513 HTML content, and so on.). 515 It is anticipated that several different composition approaches can 516 coexist and leverage the same piece of ASF content. An example is a TV 517 scenario in which two video streams are grouped separately. One 518 contains a large image of the anchorperson against a backdrop, and the 519 other contains smaller footage of a news story. While the size of each 520 rendering site could be calculated based on the natural size of each 521 video stream in the group, the fact that the news story should be 522 overlaid on the top right corner of the anchorperson video can not be 523 determined without external composition information. 525 Internet-draft February 26, 1998 527 5 ASF Header Object 529 This section defines the various objects that comprise the ASF Header 530 Object. 532 5.1 Header Object 534 Mandatory: Yes 535 Quantity: 1 only 537 +-------------------+------------------+---------------+ 538 | Field Name | Field Type | Size (bits) | 539 +-------------------+------------------+---------------+ 540 | Object ID | GUID | 128 | 541 | Object Size | UINT | 64 | 542 +-------------------+------------------+---------------+ 544 Notes: 545 The Header Object is a container that can hold any combination of the 546 following standard objects. Only the File Properties Object and the 547 Stream Properties Object are required to be present. In addition, (non- 548 standard) header objects that conform to the ASF Object Structure (see 549 Section 3.1) may also be optionally defined and used as extension 550 mechanisms for local implementations. Unlike the standard header 551 objects defined below, there is no guarantee that the non-standard 552 objects will be interpretable across vendor implementations. 553 Implementations should ignore any non-standard object that they do not 554 understand. 556 5.2 File Properties Object 558 Mandatory: Yes 559 Quantity: 1 only 561 This object defines the global characteristics of the combined media 562 streams found within the Data Object. 564 Object Structure: 565 +-------------------------+------------------+---------------+ 566 | Field Name | Field Type | Size (bits) | 567 +-------------------------+------------------+---------------+ 568 | Object ID | GUID | 128 | 569 | Object Size | UINT | 64 | 570 | File ID | GUID | 128 | 571 | Creation Date | FILETIME | 64 | 572 | Content Expiration Date | FILETIME | 64 | 573 | Last Send Time | UINT | 64 | 575 Internet-draft February 26, 1998 577 | Play Duration | UINT | 64 | 578 | Flags | UINT | 32 | 579 -----+ +------------------+---------------+ 580 | Live Flag | | 1 (LSB) | 581 |Huge Data Units Flag| | 1 | 582 | Reserved | | 30 | 583 +----+--------------------+------------------+---------------+ 584 | Minimum Bitrate | UINT | 32 | 585 | Maximum Bitrate | UINT | 32 | 586 | Average Data Unit Size | UINT | 32 | 587 | Maximum Data Unit Size | UINT | 32 | 588 | Total Data Units | UINT | 32 | 589 | Stream Count | UINT | 16 | 590 +-------------------------+------------------+---------------+ 592 Notes: 593 The Object ID field is the GUID for the File Properties Object (see 594 Appendix A). The Object Size field is the size (in bytes) of the File 595 Properties Object. 597 The value of the File ID field should be regenerated every time the 598 file is edited. It provides a unique identification for this ASF file. 600 The Creation Date contains the date and time of the initial creation of 601 the file. 603 Content Expiration Date indicates the date after which the author 604 doesn't want the file to be used. This time can be "never" (value of 605 zero). 607 Both the Last Send Time and the Play Duration fields have millisecond 608 granularities. Both of these fields are invalid if the live Flag bit is 609 set. Last Send Time is the send time of the last data unit within the 610 file. Play Duration is the maximum End Time (of any of the SPOs) minus the minimum Start Time (of any of the SPOs). 612 The following are the meanings of the Flags: 613 * The Live Flag, if set, indicates that a file is in the process of 614 being written (for example, for recording applications), and 615 therefore various values stored in the header objects are invalid. 616 It is highly recommended that post-processing be performed to remove 617 this condition at the earliest opportunity. 618 * The Huge Data Units Flag determines whether the Data Unit Length 619 field in the ASF Data Unit (Section 6.1) is 16 or 32 bits long (in 620 other words, 0 signifies 16 bits, and 1 signifies 32 bits). The 32- 621 bit Data Unit Length field should be used exclusively for local 623 Internet-draft February 26, 1998 625 recording/editing at extremely high data rates. Any other use is 626 strongly discouraged, since most networks will not be able to 627 support such huge data units. Therefore, it is strongly recommended 628 that the 16-bit Data Unit Length field alternative be used in the 629 general case. 631 Minimum Bit Rate is in bits per second and indicates the total of the 632 average bandwidth of all the mandatory streams. 634 Maximum Bit Rate is in bits per second and indicates the total of the 635 maximum bandwidth of all of the non-excluded streams. 637 The Average Data Unit Size is in bytes. This field is invalid if the 638 Live Flag is set. 640 The Maximum Data Unit Size is in bytes. This indicates the longest ASF 641 Data Unit within the Data Object. This field is invalid if the Live 642 Flag is set. 644 The Total Data Units field contains the number of ASF Data Unit entries 645 that exist within the Data Object. This field is invalid if the Live 646 Flag is set. 648 Stream Count field indicates the number of Stream Properties Objects 649 (SPOs) that exist in this file. Each media stream is required to have 650 its own SPO. 652 Invalid fields should have a value of zero for writing and should be 653 ignored when reading. 655 5.3 Stream Properties Object 657 Mandatory: Yes 658 Quantity: 1 per media stream 660 This object defines the specific properties and characteristics of a 661 media stream. It defines how a multimedia stream within the Data Object 662 is to be interpreted as well as the specific format (of elements) of 663 the ASF Data Unit itself (see Section 6.1) for that media stream. One 664 instance of this object is required for each media stream in the file, 665 including each of the separate streams formed by a scalable media type. 667 Unlike most other ASF objects, the Stream Properties Object (SPO) is a 668 "container object": it can optionally include additional ASF Objects 669 (see Section 3.1) within itself in a manner similar to the Header 670 Object. The size of these objects is included within the Object Size 671 field and contained objects, if any, are appended after the Type- 673 Internet-draft February 26, 1998 675 Specific Data field within the object structure below. This provision 676 dramatically enhances the scalability and expandability capabilities of 677 ASF, since it permits the rapid introduction of innovations and support 678 for technology evolution. Currently, only one ASF Object targeted to be 679 optionally contained within the SPO has been defined within this 680 specification: the Data Unit Extension Object (See Section 5.3.1). 681 Other ASF objects (for example, alternative approaches to scalable 682 media, a QoS (RSVP) information object, extra RTP information, or MPEG- 683 4 enhancements) may subsequently be defined and included within the SPO 684 as needed. In this way the SPO can be enhanced over time to embrace new 685 technologies and innovations. 687 Object Structure: 688 +-----------------------------+------------------+---------------+ 689 | Field Name | Field Type | Size (bits) | 690 +-----------------------------+------------------+---------------+ 691 | Object ID | GUID | 128 | 692 | Object Size | UINT | 64 | 693 | Stream Type | GUID | 128 | 694 | Start Time | UINT | 64 | 695 | End Time | UINT | 64 | 696 | Average Bitrate | UINT | 32 | 697 | Maximum Bitrate | UINT | 32 | 698 | Average Data Unit Size | UINT | 32 | 699 | Maximum Data Unit Size | UINT | 32 | 700 | Preroll | UINT | 32 | 701 | Flags | UINT | 32 | 702 -----+ +------------------+---------------+ 703 | Reliable Flag | | 1 (LSB) | 704 | Recordable Flag | | 1 | 705 | Seekable Flag | | 1 | 706 | Presentation Time Flags| | 2 | 707 | Reserved | | 27 | 708 +----+------------------------+------------------+---------------+ 709 | Presentation Time Delta | UINT | 0 or 32 | 710 | Presentation Time Numerator | UINT | 0 or 32 | 711 |Presentation Time Denominator| UINT | 0 or 32 | 712 | Stream Number | UINT | 16 | 713 | Stream Language ID Index | UINT | 16 | 714 | Stream Name Count | UINT | 16 | 715 | Stream Names | See below | ? | 716 | MIME Type Length | UINT | 8 | 717 | MIME Type | ASCII (UINT8) | ? | 718 | Type-Specific Data Length | UINT | 16 | 719 | Type-Specific Data | UINT8 | ? | 720 +-----------------------------+------------------+---------------+ 722 Internet-draft February 26, 1998 724 Stream Name: 725 +-----------------------------+------------------+---------------+ 726 | Field Name | Field Type | Size (bits) | 727 +-----------------------------+------------------+---------------+ 728 | Language ID Index | UINT | 16 | 729 | Stream Name Length | UINT | 16 | 730 | Stream Name | Unicode (UINT16) | ? | 731 +-----------------------------+------------------+---------------+ 733 Notes: 734 The Object ID field is the GUID for the Stream Properties Object (see 735 Appendix A). The Object Size field is the size (in bytes) of this Stream 736 Properties Object instance (including the sizes of all contained objects). 738 Start Time and End Time are presentation times in millisecond granularities. 739 Both fields are invalid if the Live Flag of the File Properties Object has 740 been set. The Start Time is the presentation time of the first object. The 741 End Time is the presentation time of the last object plus the duration of 742 play. The time reference in both cases is relative to the the ASF file's 743 timeline. These fields exist, therefore, to indicate where this media stream 744 is located within the context of the timeline of the file as a whole. 746 Invalid fields should have a value of 0 (zero) for writing and should be 747 ignored when reading. 749 The Average Bit Rate and the Maximum Bit Rates are in bits per second. Both 750 fields solely refer to this media stream's Bit Rates. The Maximum Bit Rate 751 is computed by identifying the maximum rate in any one-second period. The 752 Maximum Bit Rate means that the Bit Rate for this stream must not ever exceed 753 this value. This may be thought of as running a one second "sliding window" 754 over this media stream's contents and noting the specific one second interval 755 in which the greatest number of bits-per-second occurred. This value must be 756 non-zero. The Average Bit Rate is the approximation one would obtain by 757 dividing the total bits sent within this media stream by the time (in 758 seconds) during which those bits are being sent (i.e., one plus the send 759 time of the last Data Unit of that stream minus the send time of first data 760 unit of that stream). 762 The Average Data Unit Size and the Maximum Data Unit Size are in bytes and 763 refer to the ASF Data Units for this media's data types within the Data 764 Object. The Average Data Unit Size is computed by dividing the total size 765 of all of the ASF Data Units of that stream by the number of ASF Data Units 766 of that stream. The Maximum Data Unit Size is the size in bytes of the largest 768 Internet-draft February 26, 1998 770 ASF-DU for this media stream. A value of zero means "unknown". These values 771 are aids to the server for making network fragmentation and packetization 772 decisions. 774 Preroll is the minimum delay factor in milliseconds that a client should 775 use between starting a particular stream and starting the clock for the 776 client's timeline. It is used to compute the buffering requirements at 777 the client in order to mitigate against network jitter. Specifically, 778 when a data unit is received whose send time value is greater than the 779 preroll value for that stream, the client's timeline clock is started. 780 Rendering is subsequently determined by the Data Unit's presentation time 781 for that (i.e., the client's) timeline. The default preroll value is zero. 783 The following is the significance of the various flags in the Flags 784 field: 785 * Setting the Reliable Flag signifies that this media stream, if sent 786 over a network, must be carried over a reliable data communications 787 transport mechanism. 788 * Setting the Recordable Flag signifies that the content author has 789 given permission for this media stream to be recorded. "Recorded," 790 in this context, means that the client system can preserve the 791 content for later end-user use by writing that content to a place 792 (for example, a disk, CD-ROM, and DVD) where the end user can later 793 access it. The Recordable Flag should be set unless the author 794 explicitly does not want the material to be recorded. 795 * Setting the Seekable Flag means that this media stream may be 796 presented starting at a non-zero time offset. This implies that 797 this stream is a potential candidate to be included within an index 798 since the media stream may be correctly understood - and potentially 799 played -- from additional locations other than only the stream's 800 beginning. 801 * The Presentation Time Flags are 2 bits long, signifying the 802 following: 803 +-------+----------+---------------------------------------------+ 804 | Value:| Meaning: | Explanation: | 805 +-------+----------+---------------------------------------------+ 806 | 00 | Not Used | The Presentation Time field is not used | 807 | | | within the ASF Data Unit (see Section 6.1) | 808 | | | for this media stream. The Presentation | 809 | | | Time Delta, Presentation Time Numerator, | 810 | | | and the Presentation Time Denominator | 811 | | | fields are also not used within this object.| 812 +-------+----------+---------------------------------------------+ 813 | 01 | Fixed | The Presentation Time field is not used | 814 | | Delta | within the ASF Data Unit (see Section | 815 | | | 6.1) for this media stream. However, | 816 | | | the presentation time is known to be | 818 Internet-draft February 26, 1998 820 | | | a fixed delta (in Rational Units) off of | 821 | | | the send time. This delta is established | 822 | | | by the Presentation Time Delta field | 823 | | | within this object (in other words, this | 824 | | | is the only case in which the Presentation | 825 | | | time Delta field is used within this object)| 826 +-------+----------+---------------------------------------------+ 827 | 10 | Delta in | A 16-bit Presentation Time field (in | 828 | |Data Units| Rational Units) is used within the ASF | 829 | | | Data Unit (see Section 6.1) for this | 830 | | | media stream. That field identifies | 831 | | | the presentation time as a delta off of | 832 | | | the send time. The Presentation Time | 833 | | | Delta field is not used within this object. | 834 +-------+----------+---------------------------------------------+ 835 | 11 | Full Data| A 32-bit Presentation Time field (in | 836 | | Unit Pre-| Rational Units) is used within the ASF Data | 837 | | sentation| Unit (see Section 6.1)for this media stream.| 838 | | Time | That field identifies the actual | 839 | | | presentation time for that data unit. The | 840 | | | Presentation Time Delta field is not used | 841 | | | within this object. | 842 +-------+----------+---------------------------------------------+ 844 The Presentation Time Delta, Presentation Time Numerator, and 845 Presentation Time Denominator fields do not exist if the Presentation 846 Time Flags have a zero value. The Presentation Time Delta field also 847 does not exist if the Presentation Time Flags have 10 or 11 values (in 848 other words, it only exists if the flags have an 01 value; see above). 849 Otherwise these fields are 32 bits long. 851 Presentation Time Delta is in Rational Time Units. It indicates that a 852 fixed time delta (in Rational Units) between the presentation time and 853 the send time should be applied to the entirety of this stream's data 854 units (see the ASF Data Unit definition in Section 6.1). The 855 Presentation Time flags determine whether or not this field is used. 857 Rational Time Units signify a media-stream specific time unit within 858 the ASF file's intrinsic timeline. Rational Time Units are for 859 Presentation Times only. They are determined by dividing the 860 Presentation Time Numerator by the Presentation Time Denominator. The 861 default Presentation Time Numerator value is 1 and the default 862 Presentation Time Denominator value is 1000. Therefore, the default 863 Rational Time Units are in milliseconds. 865 The Stream Number provides a reference to identify which media streams 866 (in the ASF Data Unit's Stream Number field) are defined by a given 867 Stream Properties Object instance. Zero is an invalid stream number 869 Internet-draft February 26, 1998 871 (i.e., other Header Objects use stream number zero to refer to the 872 entire file as a whole rather than to a specific media stream within 873 the file). 875 The Stream Language ID Index field refers to the contents of the stream 876 itself (in other words, the language, if any, which the stream 877 uses/assumes). 879 Please see the Language List Object (Section 5.16) for the details 880 concerning how the Stream Language ID Index and Language ID Index 881 fields should be used. 883 The Stream Name Count field tells how many Stream Names are present. 884 Each stream name instance is potentially a localization into a specific 885 language. The Language ID Index field indicates the language in which 886 the Stream Name has been written in Unicode values. 888 The Stream Name Length field indicates the number of Unicode 889 "characters" that are found within the Stream Name field. The MIME Type 890 Length field indicates the number of bytes found within the MIME Type 891 field. 893 The Stream Name, MIME Type, and Stream Type are each mechanisms to 894 identify the Media Stream (in Unicode, MIME type, and GUID, 895 respectively). 897 The structure for the Type Specific Data field varies by media type. 898 The structure for this field for the Standard ASF Media Types is 899 detailed in Section 8. 901 5.3.1 Data Unit Extension Object 903 Mandatory: No 904 Quantity: 0 - n 906 The Data Unit Extension Object is an optional provision to include 907 application (or implementation)-specific data within each ASF Data Unit 908 (see Section 6.1) instance of this media stream. 910 Object Structure: 911 +-----------------------------+------------------+---------------+ 912 | Field Name | Field Type | Size (bits) | 913 +-----------------------------+------------------+---------------+ 914 | Object ID | GUID | 128 | 915 | Object Size | UINT | 64 | 916 | Extension System | GUID | 128 | 917 | Data Unit Extension Size | UINT | 16 | 918 | Extension System Info Size | UINT | 32 | 919 | Extension System Info | UINT8 | ? | 920 +-----------------------------+------------------+---------------+ 922 Internet-draft February 26, 1998 924 Notes: 925 Extension System is a GUID identifier of the type of information being 926 stored within the Extension Data field of the ASF Data Unit (see 927 Section 6.1). 929 The Data Unit Extension Size field indicates the number of bytes of 930 extension information that are present within the Extension Data field 931 of the ASF Data Unit (see Section 6.1) for this media stream. If the 932 Data Unit Extension Size field has a value of 0xFFFF (65535 decimal), 933 then the Extension Data field is variable length and the first byte of 934 the Extension Data field gives the length of the (following) extension 935 data for that particular ASF Data Unit instance. For example, if the 936 first byte of a variable sized entry has the value of "2," then two 937 additional extension data bytes will be present in that instance of the 938 Extension Data field. 940 The number, order, and size of the data elements within the ASF Data 941 Unit's Extension Data field directly correspond to the order in which 942 the Data Unit Extension Objects occur within the SPO for this media 943 stream. For example, assume that three Data Unit Extension Objects are 944 included within a stream's SPO. Assume that the first specifies a fixed 945 length of 4 bytes, the second specifies a variable length field, and 946 the third specifies a fixed length of 2 bytes. Therefore, the 947 Extension Data field of each ASF Data Unit for this stream will consist 948 of 4 bytes (extension #1), followed by 1 length byte plus up to 255 949 data bytes (extension #2), and finally 2 bytes (extension #3). 951 The Extension System Information field is an optional field providing 952 additional definitions or parameters (if any) of the Extension System. 954 5.4 Content Description Object 956 Mandatory: No 957 Quantity: 0 or 1 959 This object permits authors to record human-readable, pertinent data 960 about the file and its contents. This content is readily expandable to 961 satisfy varying bibliographic needs. Authors can supplement (or ignore) 962 the "standard" bibliographic information (for example, title, author, 963 copyright, and description) with content designations of their own 964 choosing. Each individual field name and value can be stored in as 965 many different languages as are preferred by the author, and can be 966 stream-specific or pertinent to the whole file. 968 Internet-draft February 26, 1998 970 Object Structure: 971 +-------------------------+--------------+---------------+ 972 | Field Name: | Field Type: | Size (bits): | 973 +-------------------------+--------------+---------------+ 974 | Object ID | GUID | 128 | 975 | Object Size | UINT | 64 | 976 | Description Record Count| UINT | 16 | 977 | Description Record | See below | ? | 978 +-------------------------+--------------+---------------+ 980 Description Record: 981 +-----------------------+----------------+-------------+ 982 | Field Name: | Field Type: | Size (bits):| 983 +-----------------------+----------------+-------------+ 984 | Field Type | UINT | 8 | 985 | Language ID Index |UINT (see S5.16)| 16 | 986 | Stream Number | UINT | 16 | 987 | Name Length | UINT | 16 | 988 | Value Length | UINT | 16 | 989 | Name |Unicode (UINT16)| ? | 990 | Value |Unicode (UINT16)| ? | 991 +-----------------------+----------------+-------------+ 993 Notes: 994 The Object ID field contains the GUID for the Stream Properties Object 995 (see Appendix A). The Object Size is the length in bytes of this 996 object. 998 Description Record Count indicates the number of Description Records. 1000 The Field Type field contains unsigned integer values. 1001 * ISRC is the International Standard Recording Code as described in 1002 ISO 3901. 1003 * ISWC is the International Standard Work code. 1004 * UPC/EAN is the Universal Product Code/European Article Number (in 1005 other words, the "Bar code"). 1006 * Values 13 through 49 of the Field Types were derived from Reference 1007 [5]. The number in parentheses is the MARC tag value for that item. 1008 * Values 50 through 60 of the Field Types were derived from Reference 1009 [6] for those elements that were not already obviously included 1010 within 8 through 45. 1011 * Values 61 through 68 are RTCP SDES values and value 69 is the RTCP 1012 APP value. RTCP is defined within Reference [7]. Values 70 through 1013 73 are RTP header information that is also defined within Reference 1014 [7]. 1016 Internet-draft February 26, 1998 1018 Please consult references [5], [6], and [7] for an interpretation of 1019 the meanings of their field types. 1021 The values of the Field Type field are: 1022 1 = Author 2 = Title 1023 3 = Copyright 4 = Description 1024 5 = Tool Name 6 = Tool Version 1025 7 =Tool GUID 8 = Date of Last Modification 1026 9 = Original Date Created 10 = ISRC 1027 11 = ISWC 12 = UPC/EAN 1028 13 = LCCN (10) 14 = ISBN (20) 1029 15 = ISSN (22) 16 = Cataloging Source, Leader (40) 1030 17 = Main Entry -- Personal Name (100) 1031 18 = Main Entry - Corporate Name (110) 1032 19 = Edition Statement (250) 20 = Main Uniform Title (130) 1033 21 = Uniform Title (240) 22 = Title Statement (245) 1034 23 = Varying Form Title (246) 1035 24 = Publication, Distribution, and so on (260) 1036 25 = Physical Description (300) 26 = Added Entry Title (440) 1037 27 = Series Statement (490) 28 = General Note (500) 1038 29 = Bibliography Note (504) 30 = Contents Note (505) 1039 31 = Creation Credit (508) 32 = Citation (510) 1040 33 = Participant (511) 34 = Summary (520) 1041 35 = Target Audience (521) 36 = Added Form Available (530) 1042 37 = System Details (538) 38 = Awards (586) 1043 39 = Added Entry Personal Name (600) 40 = Added Entry Topical Term (650) 1044 41 = Added Entry Geographic (651) 42 = Index Term, Genre (655) 1045 43 = Tag Index Term, Curriculum (658) 44 = Added Entry Uniform Title (730) 1046 45 = Added Entry Related (740) 1047 46 = Series Statement Personal Name (800) 1048 47 = Series Statement Uniform Title (830) 1049 48 = Electronic Location and Access (856) 1050 49 = Added Entry - Personal Name (700) 50 = Coverage 1051 51 = Date 52 = Resource Type 1052 53 = Format 54 = Resource Identifier 1053 55 = Source 56 = Language 1054 57 = Relation 58 = Coverage 1055 59 = Subject 60 = Contributor 1056 61 = CNAME 62 = NAME 1057 63 = EMAIL 64 = PHONE 1059 Internet-draft February 26, 1998 1061 65 = LOC 66 = TOOL 1062 67 = NOTE 68 = PRIV 1063 69 = APP 70 = SSRC 1064 71 = Initial RTP Timestamp value 72 = Initial RTP Sequence Number 1065 73= RTP Version Number 1067 Values between 74 and 99 (inclusive) are reserved. 1068 Values >= 100 are user-defined. 1070 The Stream Number indicates whether the entry applies to a specific 1071 media stream or whether it applies to the whole file. A value of zero 1072 in this field indicates that it applies to the whole file; otherwise, 1073 the entry applies only to the indicated stream number. 1075 Name is in Unicode. This field may be blank if the Field Type value is 1076 less than 100, unless the author explicitly wants to localize the name 1077 of the field type. 1079 The Name Length field indicates the number of Unicode "characters" that 1080 are found within Name field. The Value Length field indicates the 1081 number of Unicode "characters" that are found within Value field. 1083 As a space optimization, a 16-bit Language ID Index field has been 1084 used. See the Language List Object (Section 5.16) for more details. 1086 5.5 Script Command Object 1088 Mandatory: No 1089 Quantity: 0 or 1 1091 This object provides a list of Type/Parameter pairs of Unicode strings 1092 that are synchronized to the ASF file's timeline. Types can include 1093 "URL" or "FILENAME." These semantics and use of types are identical to 1094 the Command Media Type (see Section 8.7). Other Type values may also be 1095 freely defined and used. The semantics and treatment of this latter set 1096 of Types are defined by the local implementations. The Parameter value 1097 (referred to as "Commands" below) is specific to the type field. This 1098 Type/Parameter pairing can be used for many purposes, including sending 1099 URLs to be "launched" by a client into an HTML frame (in other words, 1100 the "URL" type) or launching another ASF file for chained "continuous 1101 play" audio or video presentations (in other words, the "FILENAME" 1102 type). This object can also be used as an alternative method to stream 1103 text (in addition to the Text Media Type) as well as to provide "script 1104 commands" that can be used to control elements within the client 1105 environment. 1107 Internet-draft February 26, 1998 1109 Object Structure: 1110 +-------------------------+---------------+-------------+ 1111 | Field Name: | Field Type: | Size (bits):| 1112 +-------------------------+---------------+-------------+ 1113 | Object ID | GUID | 128 | 1114 | Object Size | UINT | 64 | 1115 | Type Count | UINT | 16 | 1116 | Command Count | UINT | 16 | 1117 | Types | See below | ? | 1118 | Commands | See below | ? | 1119 +-------------------------+---------------+-------------+ 1121 Types: 1122 +-----------------------+----------------+------------+ 1123 | Field Name: | Field Type: |Size (bits):| 1124 +-----------------------+----------------+------------+ 1125 | Type Name Length | UINT | 16 | 1126 | Type Name |Unicode (UINT16)| ? | 1127 +-----------------------+----------------+------------+ 1129 Commands: 1130 +-----------------------+----------------+------------+ 1131 | Field Name: | Field Type: |Size (bits):| 1132 +-----------------------+----------------+------------+ 1133 | Presentation Time | UINT | 32 | 1134 | Type Index | UINT | 16 | 1135 | Command Name Length | UINT | 16 | 1136 | Command Name |Unicode (UINT16)| ? | 1137 +-----------------------+----------------+------------+ 1139 Notes: 1140 Presentation Time is given in millisecond granularities. 1142 Types are stored as an array of Unicode strings, since they will 1143 typically be reused. Commands specify their type using a zero-based 1144 index into the array of Types. 1146 The Type Name Length field indicates the number of Unicode "characters" 1147 that are found within the Type Name field. The Command Name Length 1148 field indicates the number of Unicode "characters" that are found 1149 within the Command Name field. 1151 5.6 Marker Object 1153 Mandatory: No 1154 Quantity: 0 or 1 1156 Internet-draft February 26, 1998 1158 This object contains a small, specialized index that is used to 1159 provide named "jump points" within a file. This allows a content 1160 author to divide a piece of content into logical sections such as song 1161 boundaries in an entire CD or topic changes during a long presentation, 1162 and to assign a human-readable name to each section of a file. This 1163 index information is then available to the client to permit the user to 1164 "jump" directly to those points within the presentation. 1166 Object Structure: 1167 +-------------------------+----------------+-------------+ 1168 | Field Name: | Field Type: | Size (bits):| 1169 +-------------------------+----------------+-------------+ 1170 | Object ID | GUID | 128 | 1171 | Object Size | UINT | 64 | 1172 | Index Specifier Count | UINT | 16 | 1173 | Marker Count | UINT | 16 | 1174 | Index Specifiers |See Section 5.14| ? | 1175 | Markers | See below | ? | 1176 +-------------------------+----------------+-------------+ 1178 Markers: 1179 +-------------------------+----------------+-------------+ 1180 | Field Name: | Field Type: | Size (bits):| 1181 +-------------------------+----------------+-------------+ 1182 | Presentation Time | UINT | 32 | 1183 | Offsets | UINT64 | ? | 1184 | Marker Name Count | UINT | 16 | 1185 | Marker Names | See below | ? | 1186 +-------------------------+----------------+-------------+ 1188 Marker Name: 1189 +------------------------+-----------------+-------------+ 1190 | Field Name: | Field Type: | Size (bits):| 1191 +------------------------+-----------------+-------------+ 1192 | Language ID Index | UINT | 16 | 1193 | Marker Name Length | UINT | 16 | 1194 | Marker Name | Unicode (UINT16)| ? | 1195 +------------------------+-----------------+-------------+ 1197 Notes: 1198 The Index Specifiers are defined within the Index Parameters Object 1199 (Section 5.14). 1201 The Presentation Time is in millisecond granularities. This value does 1202 not wrap around, which means that markers can only refer to the first 1203 49.7 days of information contained within an ASF file. 1205 Internet-draft February 26, 1998 1207 Potentially multiple Offsets entries are listed within the Marker 1208 structure. The number is determined by the requirement that there must 1209 be one Offsets entry in each Marker structure for each Index Specifier 1210 entry. Thus, the total size in bits of the Marker's Offsets field is 1211 64 bits times the value of the Index Specifier Count field. An offset 1212 value of 0xFFFFFFFFFFFFFFFF signifies that the entry contains an invalid 1213 offset value. 1215 As a space optimization, a 16-bit Language ID Index field has been 1216 used. See the Language List Object (Section 5.16) for more details. 1218 The Marker Name Length field indicates the number of Unicode 1219 "characters" which are found within Marker Name field. 1221 5.7 Component Download Object 1223 Mandatory: No 1224 Quantity: 0 or 1 1226 This object provides a list of components (including version 1227 information) required for the proper rendering of each stream in the 1228 file. Each listed component has a human-readable name, a category 1229 identifying the component type (which is usually either "codec" or 1230 "renderer"), a component ID used to uniquely identify a specific 1231 component, and version information for that component. 1233 This object presupposes that the Component ID will be the primary 1234 mechanism used to find the proper component to download. This object 1235 purposefully does not use URLs to find these objects, for the following 1236 reasons: 1237 1. Embedded URLs become stale very quickly, and end up being just 1238 wasted header space. 1239 2. Legacy files and current components such as codecs have no knowledge 1240 of source URLs. Either authoring/conversion tools need to have 1241 elaborate lookup tables so that they can embed the proper source 1242 URLs, or else the source URLs quickly become optional and, 1243 therefore, frequently omitted. 1244 3. Embedded source URLs would quickly become implementation-specific. 1245 Product A's authoring tools would embed pointers to product A's 1246 playback components. When a Product B client got the source URL, it 1247 would have no way of knowing if it was talking to a general 1248 "component server" or a product-specific self-extracting download 1249 module. 1251 Internet-draft February 26, 1998 1253 Object Structure: 1254 +-------------------------+---------------+-------------+ 1255 | Field Name: | Field Type: | Size (bits):| 1256 +-------------------------+---------------+-------------+ 1257 | Object ID | GUID | 128 | 1258 | Object Size | UINT | 64 | 1259 | Component Count | UINT | 32 | 1260 | Component Records | See Below | ? | 1261 +-------------------------+---------------+-------------+ 1263 Component Record: 1264 +-------------------------+---------------+-------------+ 1265 | Field Name: | Field Type: | Size (bits):| 1266 +-------------------------+---------------+-------------+ 1267 | Category | GUID | 128 | 1268 | Component ID | GUID | 128 | 1269 | Version | UINT | 64 | 1270 | Stream Number | UINT | 16 | 1271 | Component Name Length | UINT | 16 | 1272 | Component Name |Unicode(UINT16)| ? | 1273 +-------------------------+---------------+-------------+ 1275 Notes: 1276 The Component ID is a GUID that can use mappings for ACM and VCM 1277 codecs, for example. 1279 The Version field stores a "dotted quad" version stamp using the 1280 highest 16 bits for the product version, the next 16 bits for the 1281 incremental version, the next 16 bits for the revision, and the lowest 1282 16 bits for the build number. The value 0.0.0.0 should be used for the 1283 versions of ACM and VCM codecs. This value means "any version" and is 1284 needed because there are no valid versioning numbers for ACM/VCM 1285 codecs, since the "versioning information" is actually contained within 1286 the Component ID's GUID value itself for these codec types. Other 1287 entities that do not have valid version numbers should also use 0.0.0.0 1288 in this field. 1290 Stream Number identifies the multimedia stream associated with this 1291 component. A 0 (zero) value means "all streams." 1293 The Component Name is a human-readable display name for this component. 1295 5.8 Stream Group Object 1297 Mandatory: No 1298 Quantity: 0 or 1 1300 This object provides lists of "associated" streams that are grouped 1301 into related presentation contexts. Each of these contexts contains a 1302 Group Name by which these contexts may be referenced. This permits the 1303 client to make implementation-specific composition and rendering 1305 Internet-draft February 26, 1998 1307 decisions affecting those streams. For associated image/video streams, 1308 these decisions can include the number, size, and location of 1309 image/video rendering windows, and their relative positions in three- 1310 dimensional space. For audio streams, these decisions will impact the 1311 potential mixing of associated audio streams that occur simultaneously 1312 (stream start & end time can be determined using the Stream Properties 1313 Object). 1315 The following are additional examples of potential uses of this object: 1316 1. A file containing two video streams (such as a TV newscast with a 1317 large image of the anchorperson and a smaller image of the news 1318 story) would have each video stream in a separate group. A client 1319 implementation could then use external compositional information to 1320 decide that the video stream containing the news story (whose 1321 natural size is known in the Stream Properties Object's type- 1322 specific data field) should be superimposed in the top-right corner 1323 of the larger anchorperson video stream. 1324 2. A file containing multi-track audio would group all of those audio 1325 streams together (perhaps along with associated video and lyrics for 1326 a karaoke effect). This might tell the client implementation that 1327 these streams should be mixed. 1328 3. A file containing two separate image streams (for example, JPEGs, 1329 and GIFs) could group the streams together. This might tell the 1330 client to "mix" them, by logically rendering them into the same 1331 window. Another approach would be to make two different groups, 1332 which would imply that images from the two streams could be visible 1333 at the same time. 1335 The default behavior if no Stream Group Object is present within the 1336 File Header (and therefore no stream groups are defined) is to assume 1337 that all streams are grouped together. 1339 Object Structure: 1341 List of stream groupings, each of which contains a list of stream 1342 numbers for that grouping. Each stream grouping is optionally assigned 1343 a Group Name that can serve as a "handle" by which the group as a whole 1344 may be referenced. This name may be localized into different languages. 1346 +-------------------------+---------------+-------------+ 1347 | Field Name: | Field Type: | Size (bits):| 1348 +-------------------------+---------------+-------------+ 1349 | Object ID | GUID | 128 | 1350 | Object Size | UINT | 64 | 1351 | Stream Group Count | UINT | 16 | 1352 | Stream Groups | See Below | ? | 1353 +-------------------------+---------------+-------------+ 1355 Internet-draft February 26, 1998 1357 Stream Group: 1358 +-------------------------+---------------+-------------+ 1359 | Field Name: | Field Type: | Size (bits):| 1360 +-------------------------+---------------+-------------+ 1361 | Group Name Count | UINT | 16 | 1362 | Group Names | See Below | ? | 1363 | Stream Count | UINT | 16 | 1364 | Stream Numbers | UINT16 | ? | 1365 +-------------------------+---------------+-------------+ 1367 Group Name: 1368 +-------------------------+---------------+-------------+ 1369 | Field Name: | Field Type: | Size (bits):| 1370 +-------------------------+---------------+-------------+ 1371 | Language ID Index | UINT | 16 | 1372 | Group Name Length | UINT | 16 | 1373 | Group Name |Unicode(UINT16)| ? | 1374 +-------------------------+---------------+-------------+ 1376 Notes: 1377 See the Language List Object (Section 5.16) for more details concerning 1378 how to use the Language ID Index field. 1380 Media streams, which have been grouped into Group Names-named logical 1381 units, are grouped by enumerating their stream numbers in the Stream 1382 Numbers field. The Stream Count field identifies how many media streams 1383 are enumerated within the Stream Numbers field. 1385 The Group Name Length field indicates the number of Unicode 1386 "characters" that are found within Group Name field. 1388 5.9 Scalable Object 1390 Mandatory: No 1391 Quantity: 0 - n 1393 This object stores the dependency relationships between all of the 1394 media streams that comprise logical bands of the same scalable media. 1395 It can be used for scalable audio and video, as well as other types of 1396 scalable streams. Along with the dependency relationships among the 1397 streams, this object stores a default sequence in which the streams 1398 should be used when implementations are doing dynamic bandwidth 1399 scaling. 1401 Object Structure: 1402 The object consists of a list of Dependency Info "structures" for each 1403 stream that comprises a logical band of the same scalable stream. 1405 Internet-draft February 26, 1998 1407 A Dependency Info "structure" (in other words, the Dependency Record) 1408 contains: 1409 1. Stream Number. 1410 2. List of stream numbers upon which this stream depends. 1412 The object also contains an author-determined default sequence (in 1413 other words, the Default Sequence Record) that indicates the 1414 preferential order in which the streams should be used (in other words, 1415 items listed first should, by default, be used first). Each entry in 1416 this list consists of the following two fields: 1417 1. Stream Number 1418 2. Enhancement GUID. 1420 +-------------------------+---------------+-------------+ 1421 | Field Name: | Field Type: | Size (bits):| 1422 +-------------------------+---------------+-------------+ 1423 | Object ID | GUID | 128 | 1424 | Object Size | UINT | 64 | 1425 | Record Count | UINT | 16 | 1426 | Default Sequence Records| See Below | ? | 1427 | Dependency Records | See Below | ? | 1428 +-------------------------+---------------+-------------+ 1430 Default Sequence Record: 1431 +-------------------------+---------------+-------------+ 1432 | Field Name: | Field Type: | Size (bits):| 1433 +-------------------------+---------------+-------------+ 1434 | Stream Number | UINT | 16 | 1435 | Enhancement Type | GUID | 128 | 1436 +-------------------------+---------------+-------------+ 1438 Dependency Record: 1439 +-------------------------+---------------+-------------+ 1440 | Field Name: | Field Type: | Size (bits):| 1441 +-------------------------+---------------+-------------+ 1442 | Stream Number | UINT | 16 | 1443 | Dependent Stream Count | UINT | 16 | 1444 | Dependent Stream Numbers| UINT16 | ? | 1445 +-------------------------+---------------+-------------+ 1447 Notes: 1448 The Record Count field stores both the number of Default Sequence 1449 Records and the number of Dependency Records (in other words, the same 1450 number of each). This number is equivalent to the number of streams 1451 involved in this scaleability relationship. 1453 Possible Enhancement GUID Values are None, Unknown, Temporal, Spatial, 1454 Quality, Stereo (Audio), and Frequency Response (Audio). 1456 Internet-draft February 26, 1998 1458 5.10 Prioritization Object 1460 Mandatory: No 1461 Quantity: 0 or 1 1463 This object indicates the author's intentions as to which streams 1464 should or should not be dropped in response to varying network 1465 congestion situations. There may be special cases where this 1466 preferential order may be ignored (for example, the user hits the 1467 "mute" button). However, generally it is expected that implementations 1468 will try to honor the author's preference. 1470 Priority determinations are made solely with reference to base streams 1471 (in other words, this includes non-scalable streams and the base layer 1472 only of scalable streams). The author can indicate their preference as 1473 to what should happen to enhancement layer streams by means of the 1474 bandwidth restriction field. 1476 The priority of each stream is indicated by how early in the list that 1477 stream's stream number is listed (in other words, the list is ordered 1478 in terms of decreasing priority). Two additional fields provide 1479 associated information: 1481 1) The "Mandatory/Optional" field identifies whether the author wants 1482 that stream kept "regardless" (in other words, the Mandatory bit is 1483 set) or whether they are willing to have that stream dropped (in 1484 other words, an optional stream that is indicated by the Mandatory 1485 bit being cleared). Optional streams must never be assigned a higher 1486 priority than mandatory streams. 1487 2) The Bandwidth Restriction field permits the author to indicate how 1488 much of the available bandwidth will be used. For example, if the 1489 stream is a base layer of a scalable codec, the bandwidth will 1490 determine how many enhancement layers may be selected. This number 1491 is determined by the dependency relationships and priority ordering 1492 information found within the Scalable Object combined with the 1493 bandwidth information contained within each stream's Stream 1494 Properties Object. 1496 Streams that are in a mutual exclusion relationship with each other (for 1497 example, languages) should all be listed in adjacent order (in other 1498 words, priority n, n+1, n+2, and so on), sorted in decreasing order of 1499 maximum stream bandwidth. When bandwidth calculations are made, only 1500 the bandwidth used by the selected stream in a mutual exclusion 1501 relationship will be computed; each non-selected stream in such a 1502 relationship will be ignored. This combination of prioritization and 1503 mutual exclusion can be used to create scalable content even though 1505 Internet-draft February 26, 1998 1507 scalable codecs have not been used by means of creating multiple 1508 distinct media stream instances of the "same content," each at 1509 different bandwidths. 1511 Object Structure: 1512 +-------------------------+---------------+-------------+ 1513 | Field Name: | Field Type: | Size (bits):| 1514 +-------------------------+---------------+-------------+ 1515 | Object ID | GUID | 128 | 1516 | Object Size | UINT | 64 | 1517 | Priority Record Count | UINT | 16 | 1518 | Priority Records | See Below | ? | 1519 +-------------------------+---------------+-------------+ 1521 Priority Record: 1522 +-------------------------+---------------+-------------+ 1523 | Field Name: | Field Type: | Size (bits):| 1524 +-------------------------+---------------+-------------+ 1525 | Stream Number | UINT | 16 | 1526 | Priority Flags | UINT | 16 | 1527 ----+ +---------------+-------------+ 1528 | Mandatory | | 1 (LSB) | 1529 | Reserved | | 15 | 1530 +----+--------------------+---------------+-------------+ 1531 | Bandwidth Restriction | UINT | 32 | 1532 +-------------------------+---------------+-------------+ 1534 Notes: 1535 Priority Records are listed in order of decreasing priority. 1537 The Stream Number should only specify the base stream (if it is 1538 scalable). 1540 Bandwidth Restriction is in bits per second. A value of 0 (zero) 1541 indicates "no restriction." 1543 5.11 Mutual Exclusion Object 1545 Mandatory: No 1546 Quantity: 0 - n 1548 This object identifies streams that have a mutual exclusion 1549 relationship to each other (in other words, only one of the streams 1550 within such a relationship can be streamed - the rest are ignored). 1551 There should be one instance of this object for each set of objects 1552 that contain a mutual exclusion relationship. The exclusion type is 1554 Internet-draft February 26, 1998 1556 used so that implementations can allow user selection of common 1557 choices, such as language. 1559 Object Structure: 1560 +-------------------------+---------------+-------------+ 1561 | Field Name: | Field Type: | Size (bits):| 1562 +-------------------------+---------------+-------------+ 1563 | Object ID | GUID | 128 | 1564 | Object Size | UINT | 64 | 1565 | Exclusion Type | GUID | 128 | 1566 | Stream Number Count | UINT | 16 | 1567 | Stream Numbers | UINT16 | ? | 1568 +-------------------------+---------------+-------------+ 1570 Notes: 1571 The Exclusion Type identifies the nature of that mutual exclusion 1572 relationship (for example, language). 1574 The Stream Number Count indicates how many Stream Numbers are in the 1575 Stream Numbers list. Each of the media streams in this list is in a 1576 mutual exclusion relationship with the others. 1578 5.12 Inter-Media Dependency Object 1580 Mandatory: No 1581 Quantity: 0 or 1 1583 This object provides the capability for an author to identify 1584 dependencies between different media types. An example of such a 1585 relationship would be to specify that a video effects stream will be 1586 presented only if a certain enhancement layer of a video codec is also 1587 currently being presented. Another example is binding a timecode media 1588 stream to another media stream to provide alternate timecodes for that 1589 other stream's data. 1591 Object Structure: 1593 List of Dependency Info "structures" for any stream involved in an 1594 inter-media dependency relationship. 1595 +-------------------------+---------------+-------------+ 1596 | Field Name: | Field Type: | Size (bits):| 1597 +-------------------------+---------------+-------------+ 1598 | Object ID | GUID | 128 | 1599 | Object Size | UINT | 64 | 1600 | Dependency Record Count | UINT | 16 | 1601 | Dependency Records |See Section 5.9| ? | 1602 +-------------------------+---------------+-------------+ 1604 Internet-draft February 26, 1998 1606 Notes: 1607 The Dependency Record structure is given in Section 5.9. 1609 The Dependency Record Count indicates the number of Dependency Records 1610 present. 1612 Should multiple dependencies be listed within the Dependent Stream 1613 Numbers fields of a single Dependency Record, these dependencies are in 1614 a Boolean AND relationship to each other (in other words, the stream 1615 number is dependent upon x AND y). Boolean OR relationships (in other 1616 words, the stream number is dependent upon x OR y) are indicated by 1617 having multiple Dependency Record entries, each having the same Stream 1618 Number value in the Stream Number field of the Dependency Record. 1619 Streams that are dependent upon either one stream or another, or 1620 optionally both, are said to be in an OR dependency relationship. 1622 5.13 Rating Object 1624 Mandatory: No 1625 Quantity: 0 or 1 1627 This object contains W3C-defined Platform for Internet Content 1628 Selection (PICS) information (see references [1] and [2]). PICS 1629 establishes Internet conventions for label formats. It thus provides a 1630 basis for specifying the rating of the multimedia content within an ASF 1631 file. This object does not specify the specific rating service that is 1632 to be used. The content creator is consequently able to use the rating 1633 service of their choice, as long as it is specified according to the 1634 PICS conventions. 1636 Object Structure: 1637 +-------------------------+---------------+-------------+ 1638 | Field Name: | Field Type: | Size (bits):| 1639 +-------------------------+---------------+-------------+ 1640 | Object ID | GUID | 128 | 1641 | Object Size | UINT | 64 | 1642 | PICS Data | UINT8 | ? | 1643 +-------------------------+---------------+-------------+ 1645 Note: 1646 PICS information is stored as opaque data in an RFC 822-conformant 1647 format (see reference [3]). 1649 5.14 Index Parameters Object 1651 Mandatory: Yes if index is present in file; Otherwise no. 1652 Quantity: 0 or 1 1654 Internet-draft February 26, 1998 1656 This object supplies a sufficient amount of information to regenerate 1657 the index for an ASF file should the original index have been omitted 1658 or deleted. It includes only information about those streams that are 1659 actually indexed (there must be at least one stream in an index). 1661 Object Structure: 1662 +-------------------------+---------------+-------------+ 1663 | Field Name: | Field Type: | Size (bits):| 1664 +-------------------------+---------------+-------------+ 1665 | Object ID | GUID | 128 | 1666 | Object Size | UINT | 64 | 1667 |Index Entry Time Interval| UINT | 32 | 1668 | Index Specifier Count | UINT | 16 | 1669 | Index Specifiers | See Below | ? | 1670 +-------------------------+---------------+-------------+ 1672 Index Specifier: 1673 +-------------------------+---------------+-------------+ 1674 | Field Name: | Field Type: | Size (bits):| 1675 +-------------------------+---------------+-------------+ 1676 | Stream Number | UINT | 16 | 1677 | Index Type | UINT | 16 | 1678 +-------------------------+---------------+-------------+ 1680 Notes: 1681 The Index Entry Time Interval is in milliseconds. 1683 The Index Specifier Count field identifies how many Index Specifier 1684 entries exist within the Index Specifiers field. 1686 Every Index Type requires all index entry offsets to be to a data unit 1687 boundary of an ASF Data Unit containing data for the specified Stream 1688 Number. Also, the send time of that data unit must not exceed the time 1689 of the index entry, which is a presentation time. 1691 Index Type values are as follows: 1 = Nearest Data Unit, 2 = Nearest 1692 Object, and 3 = Nearest Clean Point. The Nearest Data Unit indexes 1693 point to the data unit the send time of which is closest to the index 1694 entry time. The Nearest Object indexes point to the closest data unit 1695 containing an entire object or first fragment of an object. The Nearest 1696 Clean Point indexes point to the closest data unit containing an entire 1697 object (or first fragment of an object) that has the Clean Point Flag 1698 set. 1700 Internet-draft February 26, 1998 1702 +------+------+------+------+------+------+ 1703 Send Time: | 1000 | 2000 | 3000 | 4000 | 5000 | 6000 | 1704 Object ID: | 1 | 1 | 2 | 2 | 3 | 3 | 1705 Clean Point: | Yes | Yes | No | No | No | No | 1706 +------+------+------+------+------+------+ 1707 ^ ^ ^ ^ 1708 | / | \ 1709 | / | \ 1710 Nearest Clean Point Nearest Object Nearest Index Entry 1711 Data Unit Time 6750 1712 Figure 3: Explanation of Indexing Terms 1714 5.15 Color Table Object 1716 Mandatory: No 1717 Quantity: 0 to n 1719 This object contains a color table that is used by one or more media 1720 streams. For purposes of reference, each color table is given a unique 1721 identifier for reference purposes. 1723 Object Structure: 1724 +-------------------------+---------------+-------------+ 1725 | Field Name: | Field Type: | Size (bits):| 1726 +-------------------------+---------------+-------------+ 1727 | Object ID | GUID | 128 | 1728 | Object Size | UINT | 64 | 1729 | Color Table ID | GUID | 128 | 1730 | Color Table Record Count| UINT | 16 | 1731 | Color Table Record | See Below | ? | 1732 +-------------------------+---------------+-------------+ 1734 Color Table Record: 1735 +-------------------------+---------------+-------------+ 1736 | Field Name: | Field Type: | Size (bits):| 1737 +-------------------------+---------------+-------------+ 1738 | Red | UINT | 8 | 1739 | Green | UINT | 8 | 1740 | Blue | UINT | 8 | 1741 +-------------------------+---------------+-------------+ 1743 Note: 1744 The structure consists of a list of Color Table Records, which contain 1745 RGB triplets. 1747 5.16 Language List Object 1749 Mandatory: Yes 1750 Quantity: 1 1752 Internet-draft February 26, 1998 1754 This object contains an array of ASCII-based Language IDs. All other 1755 header objects refer to languages through zero-based positions into 1756 this array. 1758 Object Structure: 1759 +-------------------------+---------------+-------------+ 1760 | Field Name: | Field Type: | Size (bits):| 1761 +-------------------------+---------------+-------------+ 1762 | Object ID | GUID | 128 | 1763 | Object Size | UINT | 64 | 1764 | Language ID Count | UINT | 16 | 1765 | Language ID Records | See Below | ? | 1766 +-------------------------+---------------+-------------+ 1768 Language ID Record: 1769 +-------------------------+---------------+-------------+ 1770 | Field Name: | Field Type: | Size (bits):| 1771 +-------------------------+---------------+-------------+ 1772 | Language ID Length | UINT | 8 | 1773 | Language ID | ASCII (UNIT8) | ? | 1774 +-------------------------+---------------+-------------+ 1776 Notes: 1777 Other objects refer to the Language List Object by means of their own 1778 Language List ID Index fields. The value within the Language ID Index 1779 field explicitly provides an index into the Language ID Record 1780 structure in order to identify a specific language. The first entry 1781 into this structure has an index value of 0 (zero). Index values that 1782 are greater than the number of entries within the Language ID Record 1783 structure are interpreted as signifying "American English." 1785 The Language ID Length field indicates the size in bytes of the 1786 Language ID field. 1788 6 Data Object 1790 Mandatory: Yes 1791 Quantity: 1 1793 This object contains all of the ASF Data Units for a file. These data 1794 units are organized in terms of increasing send times. Each ASF Data Unit 1795 contains data from only a single media stream. This data may consist of 1796 an entire object from that stream. Alternatively, it can consist of a 1797 partial object of that stream (fragmentation) or several concatenated 1798 objects from that stream (grouping). 1800 Internet-draft February 26, 1998 1802 The structure of the data object contains the following two fields, 1803 which are immediately followed by one or more instances of ASF Data 1804 Units. 1806 +-------------------------+---------------+-------------+ 1807 | Field Name: | Field Type: | Size (bits):| 1808 +-------------------------+---------------+-------------+ 1809 | Object ID | GUID | 128 | 1810 | Object Size | UINT | 64 | 1811 +-------------------------+---------------+-------------+ 1813 6.1 ASF Data Unit Definition 1815 In general, ASF media types logically consist of sub-elements that are 1816 referred to as objects. What an object happens to be in a given media 1817 stream is entirely media stream-dependent (for example, it is a 1818 specific image within an image media stream, a frame within a (non- 1819 scalable) video stream, etc). It is efficient to try to fit a media 1820 stream's object into a single ASF Data Unit whenever possible. When 1821 that is not possible, we can fragment the object (if it is too big) or 1822 group the object (if it is too little) with other objects within that 1823 same media stream when forming a data unit. In any case, each ASF Data 1824 Unit is a conveniently sized grouping of data from a single media type. 1826 ASF data units have the following format: 1827 +-------------------------+---------------+-------------+ 1828 | Field Name: | Field Type: | Size (bits):| 1829 +-------------------------+---------------+-------------+ 1830 | Data Unit Length | UINT | 16 or 32 | 1831 | Stream Number | UINT | 16 | 1832 | Send Time | UINT | 32 | 1833 | Data Unit Flags | UINT | 8 or 32 | 1834 +----+ +---------------+-------------+ 1835 | Extended Flags | | 1 (LSB) | 1836 | Clean Point | | 1 | 1837 | Fragment | | 1 | 1838 | Fragment Size | | 1 | 1839 | Grouped Data | | 1 | 1840 | Reserved | | 3 | 1841 +----+--------------------+---------------+-------------+ 1842 | Object Number | UINT | 8 | 1843 | Presentation Time | UINT | 0, 16, or 32| 1844 | Offset Into Object | UINT | 0, 16, or 32| 1845 | Object Size | UINT | 0, 16, or 32| 1846 | Extension Data | UINT8 | ? | 1847 | Data Unit Data | UINT8 | ? | 1848 +-------------------------+---------------+-------------+ 1850 Internet-draft February 26, 1998 1852 Notes: 1853 The Data Unit Length Field specifies the length in bytes of that ASF 1854 Data Unit. The Huge Data Units Flag (in the Flags field of the File 1855 Properties Object) determines the size of the Data Unit Length field. 1856 In general, it is strongly recommended that the 16-bit size alternative 1857 of the Data Unit Length field should be used and that the maximum size 1858 value for this field should not exceed 65,000. All ASF Data Units must 1859 be smaller (in bytes) than the value indicated by the Maximum Data Unit 1860 Size field within the File Properties Object. Thus, the value of the 1861 Data Unit Length field can never exceed the Maximum Data Unit Size 1862 value. 1864 The Stream Number identifies the media stream data of which is 1865 contained within the Data Unit Data field of this ASF Data Unit. The 1866 value of the Stream Number field corresponds to the Stream Number value 1867 within this media stream's Stream Properties Object. 1869 The Send Time is in milliseconds and refers to the intrinsic timeline 1870 of the ASF file (which begins at value 0). The value of this field 1871 "wraps around" to zero every 2**32 milliseconds (which is roughly every 1872 49.7 days). 1874 The following give the significance of the Data Unit Flags: 1875 * The size of the Data Unit Flags field is determined by whether the 1876 Extended Flags flag is set or cleared. If it is cleared, then there 1877 are only 8 bits of flags present. If it is set, then there are 32 1878 bits of flags with the value of the highest order 3 bytes being 1879 reserved. 1880 * The Clean Point Flag identifies whether this data unit is a "clean 1881 point" (for example, video key frame) or not. 1882 * The Fragment Flag indicates whether this data unit contains a 1883 fragment of an object or not. If the Fragment Flag is set, then the 1884 Offset Into Object and Object Size fields exist within this ASF Data 1885 Unit instance. These fields are used to indicate the breakup of 1886 large object across data unit boundaries. If this flag is cleared, 1887 then these two fields do not exist within this ASF Data Unit 1888 instance. If the Fragment Flag is set, then the Grouped Data Flag 1889 must be cleared. If an object containing a clean point is 1890 fragmented, the Clean Point Flag is set for all of the fragments 1891 of that object. 1892 * The Fragment Size flag is valid only if the Fragment Flag has been 1893 set. If the Fragment Size Flag is cleared, then the Offset Into 1895 Internet-draft February 26, 1998 1897 Object and Object Size fields are 16 bits long. If it is set, then 1898 these fields are 32-bits long. 1899 * The Grouped Data Flag indicates whether or not multiple objects from 1900 the same stream are grouped together into a single data unit. The 1901 Grouped Data flag must be cleared (in other words, indicating no 1902 grouped data) if the Fragment Flag is set. Grouping consists of 1903 prefixing a 16-bit length field to the object data. A 16-bit delta 1904 time (in milliseconds) is inserted between each length-object 1905 pairing. For example: 1907 +-----------------+ 1908 | 16-bit Length | 1909 +-----------------+ 1910 | Data | 1911 +-----------------+ ---------- 1912 |16-bit Delta Time| 1913 +-----------------+ Repeat 1914 | 16-bit Length | 1 - N 1915 +-----------------+ Times 1916 | Data | 1917 +-----------------+ ---------- 1918 Figure 4: Grouping 1920 The 16-bit Delta Time field is always included within Grouped Data 1921 as shown above. This field indicates a presentation time for the 1922 following grouped object. If the Presentation Time flags within the 1923 Stream Properties Object are configured to state that presentation 1924 times are not used (value of 00), then the value of the 16-bit Delta 1925 Time field of the Grouped Data indicates the difference in send 1926 times between the two objects. In this case, the delta time 1927 effectively indicates a presentation time difference for the grouped 1928 objects only. 1930 Should an object containing a clean point be grouped, the object 1931 containing the clean point must be the first object in the grouping. 1932 All other objects in a grouping are interpreted as not being clean 1933 points. 1935 The Object Number field identifies which object within the data stream 1936 is being sent. (The first object is Object Number 0.) The value of this 1937 field "wraps" around to 0 every 2**8 objects. It should be explicitly 1938 noted that the term "object" within the context of ASF media types (and 1939 hence the Object Number field of the ASF Data Unit) is entirely 1940 unrelated to the ASF Object definition, which was given in Section 3.1. 1942 Internet-draft February 26, 1998 1944 The Presentation Time Flags within the Stream Properties Object 1945 determine whether the Presentation Time field exists or not. Those 1946 flags also determine whether the Presentation time is full presentation 1947 time (in other words, full 32-bit reference to the timeline) or whether 1948 the presentation time is a 16-bit delta off of the send time. All 1949 presentation times are in terms of the Rational Unit values established 1950 for that media stream within the Stream Properties Object. 1952 The Offset Into Object and Object Size fields are used exclusively for 1953 fragmentation. The former identifies the offset into the object 1954 (identified by the Object Number field) where the current fragment 1955 begins, and the Object Size identifies the total size of that object. 1956 These fields provide the information needed to reconstruct the object 1957 when it is received at the client. 1959 The Extension Data field is optional and its existence and size is 1960 determined by the optional presence of one or more Data Unit Extension 1961 Object(s) (see Section 5.3.1) within the Stream Properties Object (see 1962 Section 5.3). The Extension System (GUID) field within the Data Unit 1963 Extension Object(s) establishes the semantics of the Extension Data. 1965 6.2 ASF Data Unit Examples 1967 The following examples are provided to help explain how the data unit 1968 format may appear in various usage scenarios. In each case excerpts 1969 from the example Stream Properties Object must be included, since they 1970 determine the actual data unit composition. Also, it is assumed in all 1971 examples that the Huge Data Units Flag within the File Properties 1972 Object has been cleared. 1974 6.2.1 Complete Key Frame Example: 1976 The Presentation Time Flags in the Stream Properties Object specify 1977 that the Presentation Delta is in the data units (in other words, value 1978 "10"). The Extension Data Size value (of the Data Unit Extension 1979 Object) is 2. 1981 The following is an example data unit for the case where the Object 1982 Number is 5, the Send Time is 5000, and the Presentation Time is 5750: 1983 +-------------------------+---------------------+-------------+ 1984 | Field Name: | Field Size (bytes): | Field Value:| 1985 +-------------------------+---------------------+-------------+ 1986 | Data Unit Length | 2 | 1014 | 1987 | Stream Number | 2 | 1 | 1988 | Send Time | 4 | 5000 | 1989 | Data Unit Flags | 1 | 0x02 | 1990 | Object Number | 1 | 5 | 1991 | Presentation Time | 2 | 750 | 1992 | Extension Data | 2 | Opaque | 1993 | Data Unit Data | 1000 | Opaque | 1994 +-------------------------+---------------------+-------------+ 1996 Internet-draft February 26, 1998 1998 6.2.2 Partial JPEG Example: 2000 The Presentation Time Flags in the Stream Properties Object specify 2001 that presentation times are not used (value "00"). The Extension Data 2002 Size value (of the Data Unit Extension Object) is 0. 2004 The following is an example data unit for the case where bytes 1000 2005 through 1799 are being sent for a 4000-byte-long JPEG image at a Send 2006 Time of 7000. The Object Number of this JPEG image is 17. 2008 +-------------------------+---------------------+-------------+ 2009 | Field Name: | Field Size (bytes): | Field Value:| 2010 +-------------------------+---------------------+-------------+ 2011 | Data Unit Length | 2 | 814 | 2012 | Stream Number | 2 | 2 | 2013 | Send Time | 4 | 7000 | 2014 | Data Unit Flags | 1 | 0x06 | 2015 | Object Number | 1 | 17 | 2016 | Offset Into Object | 2 | 1000 | 2017 | Object Size | 2 | 4000 | 2018 | Data Unit Data | 800 | Opaque | 2019 +-------------------------+---------------------+-------------+ 2021 6.2.3 Three Delta Frames Example 2023 The Presentation Time Flags in the Stream Properties Object specifies 2024 that the Presentation Time Delta is carried in the data units (value 2025 "10"). The Extension Data Size value (of the Data Unit Extension 2026 Object) is 0. 2028 The following is an example of a data unit containing three delta video 2029 frames. The first is 20 bytes long, and presents at 8500, the second 2030 is 30 bytes long and presents at 8533, and the third is 40 bytes long 2031 and presents at 8575. 2033 +------------------------------------------+---------+-------------+ 2034 | Field Name: | Field | Field Value:| 2035 | | Size | | 2036 | | (Bytes):| | 2037 +------------------------------------------+---------+-------------+ 2038 | Data Unit Length | 2 | 112 | 2039 | Stream Number | 2 | 1 | 2040 | Send Time | 4 | 8000 | 2042 Internet-draft February 26, 1998 2044 | Data Unit Flags | 1 | 0x10 | 2045 | Object Number | 1 | 97 | 2046 | Presentation Time | 2 | 500 | 2047 | Data Unit Data | 100 | See Below | 2048 +-----| +------------------+---------+-------------+ 2049 | [Object ID #97] | Data Length | 2 | 20 | 2050 | | Data | 20 | Opaque | 2051 |-----------------+------------------+---------+-------------+ 2052 | [Object ID #98] | Pres. Time Delta | 2 | 33 | 2053 | | Data Length | 2 | 30 | 2054 | | Data | 30 | Opaque | 2055 |-----------------+------------------+---------+-------------+ 2056 | [Object ID #99] | Pres. Time Delta | 2 | 42 | 2057 | | Data Length | 2 | 40 | 2058 | | Data | 40 | Opaque | 2059 +------------------------------------------+---------+-------------+ 2061 [Note concerning the example above: 8533 minus 8500 forms the 2062 Presentation Time Delta value of 33 for Object ID #98. 8575 minus 8533 2063 forms the Presentation Time Delta value of 42 for Object ID #99.] 2065 7 Index Object 2067 Mandatory: No, but strongly recommended 2068 Quantity: 0 or 1 2070 This top-level ASF object supplies the necessary indexing information 2071 for an ASF file. It includes stream-specific indexing information 2072 based on an adjustable index entry time interval. The index is 2073 designed to be broken into blocks to facilitate storage that is more 2074 space-efficient by using 32-bit offsets relative to a 64-bit base. That 2075 is, each index block has a full 64-bit offset in the block header, 2076 which is added to the 32-bit offsets found in each index entry. If a 2077 file is larger than 2^32 bytes, then multiple index blocks can be used 2078 to fully index the entire large file while still keeping index entry 2079 offsets at 32 bits. 2081 Indices into the Index Object are in terms of Presentation Times. The 2082 corresponding Offset field values (of the Index Entry, see below) are 2083 byte offsets that, when combined with the Index Block's Block Position 2084 value, indicate the starting location of an ASF Data Unit. 2086 The Index Object is not recommended to be used for files where the Send 2087 Time of the first Data Unit within the Data Object has a Send Time value 2088 significantly greater than zero (otherwise the index itself will be sparse 2089 and inefficient). In such cases, an offset value of 0xFFFFFFFF is used to 2090 indicate an invalid offset value. Invalid offsets signify that this 2091 particular index entry does not identify a valid indexable point. 2092 Invalid offsets may occur for the initial index entries of a media 2093 stream whose first ASF Data Unit has a non-zero send time. 2095 Internet-draft February 26, 1998 2097 Object Structure: 2098 +-------------------------+----------------+-------------+ 2099 | Field Name: | Field Type: | Size (bits):| 2100 +-------------------------+----------------+-------------+ 2101 | Object ID | GUID | 128 | 2102 | Object Size | UINT | 64 | 2103 |Index Entry Time Interval| UINT | 32 | 2104 | Index Specifier Count | UINT | 16 | 2105 | Index Specifiers |See Section 5.14| ? | 2106 | Index Block Count | UINT | 32 | 2107 | Index Blocks | See Below | ? | 2108 +-------------------------+----------------+-------------+ 2110 Index Block: 2111 +-------------------------+----------------+-------------+ 2112 | Field Name: | Field Type: | Size (bits):| 2113 +-------------------------+----------------+-------------+ 2114 | Block Position | UINT | 64 | 2115 | Index Entry Count | UINT | 32 | 2116 | Index Entries | See Below | ? | 2117 +-------------------------+----------------+-------------+ 2119 Index Entry: 2120 +-------------------------+----------------+-------------+ 2121 | Field Name: | Field Type: | Size (bits):| 2122 +-------------------------+----------------+-------------+ 2123 | Offsets | UINT32 | ? | 2124 +-------------------------+----------------+-------------+ 2126 Notes: 2127 Block Position is the byte offset of the beginning of this block 2128 relative to the beginning of the first Data Unit (i.e., the 2129 beginning of the Data Object + 24 bytes). 2131 Index Entry Count is the number of Index Entries in the block. 2133 The size of the Offsets field within each Index Entry structure is 2134 (32 bits multiplied by the value of the Index Specifier Count 2135 field). For example, if the Index Specifier Count is 3, then there 2136 are three 32-bit offsets in each Index Entry. Index Entry offsets 2137 are ordered according to the ordering specified by the Index 2138 Parameters Object, thereby permitting the same stream to be 2139 potentially indexed by multiple Index Types (e.g., Nearest Clean 2140 Point, Nearest Object, Nearest Data Unit). 2142 The Index Entry Time Interval has a millisecond granularity. [Note: the 2143 problem with making index entries be based upon rational time units is 2144 that each stream can have its own choice of rational time units - which 2145 would make selecting the one to be used for index problematical.] 2147 8 Standard ASF Media Types 2149 ASF files store a wide variety of multimedia content. It is natural to 2150 expect implementations to make use of this content to produce rich 2151 multimedia experiences. It is anticipated that implementations will 2152 flexibly produce unique media types of their own creation. It is 2153 highly desirable, however, that a rich set of standard media types be 2154 commonly supported to permit content compatibility between diverse 2155 implementations. 2157 The purpose of this section is to define a set of Standard ASF Media 2158 Types. [Note: "Media types", as used in this document, is roughly 2159 equivalent to the IETF RFC 1590 term "content type."] The explicit 2161 Internet-draft February 26, 1998 2163 intention of this section is that if an implementation supports a media 2164 type defined within this section (in other words, audio, video, image, 2165 timecode, text, MIDI, command, Media Object), that media type must be 2166 supported in the manner described within this section if the 2167 implementation is to be considered to be "content-compliant" with the 2168 ASF specification. This commonality will hopefully define a minimum 2169 subset of media within which multi-vendor interoperability will be 2170 possible. This, in turn, will simplify media exchange between 2171 companies, developers, and individuals. No restrictions are placed upon 2172 how implementations support non-standard media types (in other words, 2173 media types other than those covered in this section). 2175 There are two elements to each Media Type definition: 2176 1. Identification of the information that will populate the Type- 2177 Specific Data field of the Stream Properties Object. This provides 2178 media-specific information needed to interpret the data in the media 2179 stream. 2180 2. Description of the media stream data itself. 2181 Each of the following sub-sections will define the core media types in 2182 terms of these two elements. 2184 8.1 Audio Media Type 2186 Type-Specific Data: 2187 +---------------------------+----------------+-------------+ 2188 | Field Name: | Field Type: | Size (bits):| 2189 +---------------------------+----------------+-------------+ 2190 | Codec ID | GUID | 128 | 2191 | Error Concealment Type | GUID | 128 | 2192 | Bits per Sample | UINT | 32 | 2193 | Samples per Second | UINT | 32 | 2194 | Average Frame Size | UINT | 32 | 2195 | Maximum Frame Size | UINT | 32 | 2196 | Samples per Frame | UINT | 32 | 2197 | Flags | UINT | 16 | 2198 | Reserved | | 16 | 2199 | Number of Channels | UINT | 16 | 2200 |Error Concealment Data Size| UINT | 16 | 2201 | Codec Specific Data Size | UINT | 16 | 2202 | Error Concealment Data | UINT8 | ? | 2203 | Codec Specific Data | UINT8 | ? | 2204 +---------------------------+----------------+-------------+ 2206 Media Stream Format: 2207 Output of a codec or sampling device. 2209 Internet-draft February 26, 1998 2211 Notes: 2212 The Bits per Sample field should have a value of 0 (zero) if a variable 2213 bit-rate compression scheme is used. 2215 The term "frame" in this context refers to the compressed chunk of data 2216 produced by an audio codec. 2218 8.1.1 Scrambled Audio 2220 One Error Concealment Type is so-called "scrambled audio." This refers 2221 to an error concealment approach that mitigates the impact of lost 2222 audio data units by rearranging the order in which audio data is sent. 2223 The Scrambled Audio concealment scheme stores audio data in a 2224 rearranged fashion on disk. This disk order is maintained as the data 2225 is streamed over a network. The client must correctly unscramble the 2226 audio data before submitting it to the codec to decompress. This 2227 approach works well for fixed bit-rate audio codecs that have no inter- 2228 frame dependencies. 2230 The Error Concealment Data field has the following structure for this 2231 approach: 2233 +---------------------------+----------------+-------------+ 2234 | Field Name: | Field Type: | Size (bits):| 2235 +---------------------------+----------------+-------------+ 2236 | Audio Object Size | UINT | 32 | 2237 | Rearranged Chunk Size | UINT | 32 | 2238 | Chunks per Data Unit | UINT | 32 | 2239 | Chunk Distance | UINT | 32 | 2240 +---------------------------+----------------+-------------+ 2242 Notes: 2243 The Audio Object Size refers to the size in bytes of all rearranged 2244 audio objects in this stream. Other object sizes are possible but will 2245 not use this concealment scheme. 2247 Rearranged Chunk Size refers to the size in bytes of audio blocks that 2248 are rearranged within each object. This value should be a multiple of 2249 the Average Frame Size. 2251 Chunks per Data Unit refers to the number of Rearranged Chunk Size 2252 audio blocks that are contained in each ASF data unit for this stream. 2254 Chunk Distance refers to the number of audio chunks to skip when 2255 filling data units. 2257 Internet-draft February 26, 1998 2259 Every data unit except for the one containing the "end" of each audio 2260 object will always contain (Chunks per Data Unit) * (Rearranged Chunk 2261 Size) bytes of audio. 2263 The following diagram illustrates how audio scrambling will be done. 2265 Original Audio Media "chunks" before scrambling: 2267 +-----+-----+-----+-----+-----+-----+-----+ 2268 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 2269 +-----+-----+-----+-----+-----+-----+-----+ 2271 Each rectangle represents the Rearranged Chunk Size. 2272 The size of all rectangles added together represents the Audio Object 2273 Size. 2274 If it is configured so that the Chunk Distance = 2 and the Chunks per 2275 Packet = 2, the following would be the resulting packet order as stored 2276 on the disk (and streamed across the network): 2278 +-----+ +-----+ +-----+ +-----+ 2279 | 1 | | 7 | | 5 | | 6 | 2280 | 4 | | 2 | | 3 | | | 2281 +-----+ +-----+ +-----+ +-----+ 2283 8.2 Video Media Type 2285 Type-Specific Data: 2286 +---------------------------+----------------+-------------+ 2287 | Field Name: | Field Type: | Size (bits):| 2288 +---------------------------+----------------+-------------+ 2289 | Codec ID | GUID | 128 | 2290 | Color Table ID | GUID | 128 | 2291 | Average Frame Rate | FLOAT | 64 | 2292 | Average Key Frame Rate | FLOAT | 64 | 2293 | Maximum Key Frame Rate | FLOAT | 64 | 2294 | Average Frame Size | UINT | 32 | 2295 | Maximum Frame Size | UINT | 32 | 2296 | Flags | UINT | 16 | 2297 | Reserved | | 16 | 2298 | Encoded Image Width | UINT | 16 | 2299 | Encoded Image Height | UINT | 16 | 2300 | Display Image Width | UINT | 16 | 2301 | Display Image Height | UINT | 16 | 2302 | Color Depth | UINT | 16 | 2303 | Codec Specific Data Size | UINT | 16 | 2304 | Codec Specific Data | UINT8 | ? | 2305 +---------------------------+----------------+-------------+ 2307 Internet-draft February 26, 1998 2309 Media Stream Format: 2310 Output of a codec or sampling device. 2312 Notes: 2313 The Encoded/Display Image Width/Height is in pixels. 2315 The Average Key Frame Rate and the Maximum Key Frame Rate are able to 2316 indicate very slow rates as a fractional value. For example, a frame 2317 rate of one frame every 8 seconds would be shown as 0.125. 2319 Key Frames are also known as Clean Points within the ASF Data Unit (see 2320 Section 6.1). Key Frames are known as I-Frames in MPEG terminology. 2322 8.3 Image Media Type 2324 Type-Specific Data: 2325 +---------------------------+----------------+-------------+ 2326 | Field Name: | Field Type: | Size (bits):| 2327 +---------------------------+----------------+-------------+ 2328 | Codec ID | GUID | 128 | 2329 | Color Table ID | GUID | 128 | 2330 | Maximum Image Size | UINT | 32 | 2331 | Encoded Image Width | UINT | 16 | 2332 | Encoded Image Height | UINT | 16 | 2333 | Display Image Width | UINT | 16 | 2334 | Display Image Height | UINT | 16 | 2335 | Flags | UINT | 16 | 2336 | Reserved | | 16 | 2337 | Color Depth | UINT | 16 | 2338 | Codec Specific Data Size | UINT | 16 | 2339 | Codec Specific Data | UINT8 | ? | 2340 +---------------------------+----------------+-------------+ 2342 Media Stream Format: 2343 The data contents of one or more logical Image files. 2345 Notes: 2346 The following Image Types must be supported on all ASF clients: Loss- 2347 Tolerant JPEG and JPEG. Other Image Types may also be optionally 2348 supported. [Note: Loss-Tolerant JPEG is a Microsoft-defined JPEG 2349 variant that will be described in a future version of this document.] 2351 Internet-draft February 26, 1998 2353 The Codec ID will include GUIDs for many image formats, including Loss- 2354 Tolerant JPEG, GIF, and JPEG. 2356 The Color Table ID is used to indicate the palette when Color Depth is 2357 8 bpp. 2359 The Encoded/Display Image Width/Height is in pixels. 2361 The Maximum Image Size is specified in bytes. 2363 The existence, content, and size of Codec Specific Data is keyed off of 2364 the Codec ID. 2366 8.4 Timecode Media Type 2368 Type-Specific Data: 2369 +---------------------------+----------------+-------------+ 2370 | Field Name: | Field Type: | Size (bits):| 2371 +---------------------------+----------------+-------------+ 2372 | Timecode ID | GUID | 128 | 2373 +---------------------------+----------------+-------------+ 2375 Media Stream Format: 2376 Timecodes of the type indicated by the Timecode ID. 2378 Notes: 2379 The Timecode ID will contain GUIDs for SMPTE. 2381 It is expected that a timecode media stream will be bound to specific 2382 other media streams by means of the Inter-Media Dependency object. This 2383 will provide a basis for establishing (non-mathematic) SMPTE timecode 2384 for that media stream (in other words, Rational Presentation Times 2385 solely are able to establish mathematically based timecodes). For 2386 example, if an SMPTE timecode is bound to a video stream, entries with 2387 the same send times in the two streams are paired, thereby permitting 2388 SMPTE timecodes to be given to that video stream. 2390 8.5 Text Media Type 2392 Type-Specific Data: 2393 +---------------------------+----------------+-------------+ 2394 | Field Name: | Field Type: | Size (bits):| 2395 +---------------------------+----------------+-------------+ 2396 | Text Encoding System | GUID | 128 | 2397 | Encoding Specific Data | ?? | ?? | 2398 +---------------------------+----------------+-------------+ 2400 Internet-draft February 26, 1998 2402 Media Stream Format: 2403 Text Media shall be streamed as NULL-terminated streams. 2405 Notes: 2406 The following Text Types must be supported on all ASF clients: ASCII, 2407 Unicode, and HTML. Other Text Types may also be optionally supported. 2409 The Encoding Specific Data field will have a different meaning 2410 depending on the Text type identified within the Text ID field: 2411 * If ASCII or Unicode is the Text Encoding System, then the 2412 Encoding Specific Data field will not exist. 2413 * If HTML, then this may optionally contain a Cascading Style Sheet 2414 (CSS) that will be in common across each of the HTML objects 2415 within this media stream. 2417 All ASF implementations are required to support ASCII and are strongly 2418 encouraged to support Unicode and HTML. 2420 As is the case with the other media types, all rendering and 2421 composition decisions for Text Media (for example, overlays, Z- 2422 ordering, positioning, marquis, and so on) are made by out-of-band 2423 techniques alluded to in Section 5.8. 2425 Should "text files" be streamed, each "file" is considered to be an 2426 object within this data stream (in other words, it will have a distinct 2427 Object ID value within the ASF Data Unit (see Section 6.1)). 2429 8.6 MIDI Media Type 2431 The goals for the definition of the MIDI media type were to incur 2432 minimal overhead for MIDI data while maintaining extensibility for 2433 future enhancements. Also, it was desirable to enable reasonable 2434 granularity seeking operations within MIDI streams. We believe that 2435 this proposal meets the stated objectives. 2437 Minimal overhead is present in the definition of the MIDI event 2438 structure (see the Media Stream Format section below). Usually, only 2439 two bytes more than MIDI's standard overhead is required, while 2440 maintaining a more accurate timing model. 2442 Extensibility is built in through an event class system, which permits 2443 the mapping and assignment of globally unique identifiers (GUIDs) to 2444 the integer-based event classes contained in a MIDI stream. 2446 Seeking operations are supported through an expanded use of the Clean 2447 Point concept. On some interval throughout a seekable MIDI stream, 2449 Internet-draft February 26, 1998 2451 objects will need to begin with what is termed "Clean Point Info" 2452 events. These events will serve to re-establish the state of patch 2453 changes and controllers at that point in the MIDI stream. Those 2454 objects that contain this Clean Point Info can then be marked using the 2455 Clean Point Flag in the ASF data unit definition, and indexed using the 2456 normal ASF Index. During the course of normal streaming playback, 2457 these redundant Clean Point Info events are ignored. When seeking, the 2458 client uses these events to re-establish the current state of patches 2459 and controllers. An exact list of which controllers' state should be 2460 preserved is TBD. 2462 Type-Specific Data: 2463 +---------------------------+----------------+-------------+ 2464 | Field Name: | Field Type: | Size (bits):| 2465 +---------------------------+----------------+-------------+ 2466 | Flags | UINT | 16 | 2467 | Extended Classes | | 1 (LSB) | 2468 | Extended Channels | | 1 | 2469 | Reserved | | 14 | 2470 | Event Class Count | UINT | 16 | 2471 | Event Classes | GUID | ? | 2472 +---------------------------+----------------+-------------+ 2474 Notes: 2475 The Extended Classes Flag means that every MIDI event in this stream 2476 uses the 8 bit Extended Event Class field (see below) to extend the 2477 number of possible event classes from 63 to 16383 (by extending the 2478 event class space from 6 bits to 14 bits). 2480 The Extended Channels Flag means that every MIDI event in this stream 2481 is followed by a byte that contains an additional 8 bits of MIDI 2482 channel information, permitting the use of 4096 channels instead of 2483 just the traditional 16 channels. 2485 The Event Classes list of GUIDs contains the mapping used for this 2486 particular stream from the GUID identifiers for MIDI event classes to 2487 the integers used in this stream. The first entry in this list is 2488 given the integer value 1 (one), since 0 (zero) is reserved to indicate 2489 a standard MIDI event. 2491 It is expected that MIDI streams will have the Reliable Flag set in 2492 their Stream Properties Object, as the loss of MIDI data generally 2493 leads to undesirable and unpredictable results. 2495 Media Stream Format: 2497 Internet-draft February 26, 1998 2499 Each object within a MIDI stream will contain an array of the following 2500 MIDI Event structures: 2501 +---------------------------+----------------+-------------+ 2502 | Field Name: | Field Type: | Size (bits):| 2503 +---------------------------+----------------+-------------+ 2504 | Presentation Time Delta | UINT | 16 | 2505 | | UINT | 8 | 2506 | Event Size Present | | 1 (LSB) | 2507 | Clean Point Event | | 1 | 2508 | Event Class | | 6 | 2509 | Extended Event Class | UINT | 0 or 8 | 2510 | Event Size | UINT | 0 or 32 | 2511 | MIDI Event | UINT8 | ? | 2512 | Extended Channel Info | UINT | 0 or 8 | 2513 +---------------------------+----------------+-------------+ 2515 Notes: 2516 The Presentation Time Delta field is stored in units of 100 2517 microseconds (tenths of milliseconds). The 16-bit size of the field, 2518 when combined with the chosen time units, permits ASF MIDI objects to 2519 contain up to 6.5535 seconds worth of MIDI data in a single object. 2520 The delta is based on the explicit or implicit Presentation Time value 2521 of the object in the ASF MIDI stream. Each event stores an individual 2522 time delta from the base presentation time of the object (for ease of 2523 manipulation), so the resulting presentation time for every single MIDI 2524 event in the same object can be computed as object presentation time + 2525 presentation time delta. All MIDI events in a single object must be 2526 stored in sorted order of increasing presentation time deltas. 2528 The Event Size Present field is used to indicate that an explicit 32- 2529 bit event size field is being used in this particular event. This will 2530 typically be useful for SYSEX events whose lengths can not be 2531 predicted. If not present, the size of the MIDI Event field must be 2532 implicitly determined based on the event's contents. In the case of a 2533 standard MIDI event (with Event Class == 0), a simple table can be used 2534 to map from MIDI status byte values to the overall size of the MIDI 2535 event data. Recall that if the stream's Extended Channels flag is set, 2536 then an Extended Channel Info byte follows the standard MIDI event. 2538 The Clean Point Event field indicates that this particular MIDI event 2539 should only be processed if received immediately following a seek 2540 operation. Otherwise, client implementations should skip this event. 2542 The Event Class field is used as a 1-based index into the Event Classes 2543 list of GUIDs stored in the stream header. Event Class 0 (zero) is 2544 reserved to indicate a Standard MIDI event. The Extended Event Class 2545 field is used to expand the number of simultaneously permissible event 2546 classes for a particular stream from 63 to 16383 by extending the 2547 number of event class bits from 6 to 14. It occurs only if the 2548 Extended Classes flag is set in the stream header. 2550 Internet-draft February 26, 1998 2552 The Event Size field is used only if the Event Size Present field is 2553 set, as was previously mentioned. 2555 MIDI running status can be used between the events contained within one 2556 individual ASF object (or buffer), but should not cross object 2557 boundaries. This recommendation is designed to simplify client 2558 playback resource requirements and implementations. 2560 8.7 Command Media Type 2562 Type-Specific Data: 2563 +---------------------------+----------------+-------------+ 2564 | Field Name | Field Type | Size (bits) | 2565 +---------------------------+----------------+-------------+ 2566 | Command Type | GUID | 128 | 2567 +---------------------------+----------------+-------------+ 2569 Media Stream Format: 2570 The data of URL Command Types complies with the URL format strings as 2571 defined in RFC 1738 and RFC 2017. These strings shall be NULL 2572 terminated ASCII strings. Frame values are indicated by a "&" delimiter 2573 according to the following syntax: "& frame & URL \0". 2575 The data of the FILENAME Command Type either complies with the URL 2576 Command Type format or else the format used on the local operating 2577 system to indicate ASCII filenames. 2579 Notes: 2580 There are two standard Command Type GUIDs: URL and FILENAME. The URL 2581 command indicates that the URL is to be "launched" by a client into an 2582 HTML window or frame. The FILENAME command indicates the ASF file 2583 indicated is to be played immediately (for example, for "continuous 2584 play" environments). 2586 It is required that all ASF implementations support fully specified 2587 URLs for both URL and FILENAME uses. Relative path URLs may be 2588 optionally supported. The use of Local URLs (in other words, those 2589 containing O/S dependent references such as drive letters) is 2590 discouraged but not prohibited. 2592 8.8 Media-Objects (Hotspot) Media Type 2594 The goal of the Media-Objects stream is to encode an object 2595 representation of a related visual media stream (for example, video, 2596 image, slideshow, animation, and so on) and the interactive features 2597 associated with these objects. This is accomplished by "binding" the 2599 Internet-draft February 26, 1998 2601 media object stream to the related visual media stream by means of the 2602 Inter-Media Dependency Object. 2604 Theoretically, the Media Object stream will enable elements within the 2605 visual media stream to be referred to in an object-oriented fashion (in 2606 addition to the traditional image-oriented fashion). This approach 2607 enhances the information level embedded in a visual media stream, 2608 providing both the developer and the viewer with a new, more natural 2609 method of referencing the logical objects in the media. For example, 2610 derived applications may include object-based interactivity, object- 2611 based storage and retrieval and object-based statistics. 2613 Type-Specific Data: 2614 +-----------------+-------------+------+------------------------------+ 2615 | Field Name: | Field Type: | Size | Description: | 2616 | | |(bits)| | 2617 +-----------------+-------------+------+------------------------------+ 2618 | Horizontal | UINT | 16 | The horizontal resolution of | 2619 | Resolution | | | the frame. This parameter is | 2620 | | | |used to interpret the object's| 2621 | | | | geometry parameters. | 2622 +-----------------+-------------+------+------------------------------+ 2623 | Vertical | UINT | 16 | The vertical resolution of | 2624 | Resolution | | | the frame. This parameter is | 2625 | | | |used to interpret the object's| 2626 | | | | geometry parameters. | 2627 +-----------------+-------------+------+------------------------------+ 2628 | Number of | UINT | 16 | Total number of Command | 2629 | Commands | | | Entries. | 2630 +-----------------+-------------+------+------------------------------+ 2631 | Command Entry | Command | ?? | | 2632 | Array | Entry | | | 2633 | | Structure | | | 2634 +-----------------+-------------+------+------------------------------+ 2636 Command Entry Structure: 2637 +-----------------+-------------+------+------------------------------+ 2638 | Field Name: | Field Type: | Size | Description: | 2639 | | |(bits)| | 2640 +-----------------+-------------+------+------------------------------+ 2641 | Link Type | OBLinkType | 8 | The command type which will | 2642 | | | | be activated when actuating | 2643 | | | | the object. | 2644 +-----------------+-------------+------+------------------------------+ 2645 | Link Command | See Below | | | 2646 +----+ +-------------+------+------------------------------+ 2647 For URL Command: 2648 +------------+-------------+------+------------------------------+ 2649 | URL | URL Format | ?? | The full URL address. | 2650 | | String | | Identical to the URL Command | 2651 | | | | type (see Section 8.7). | 2652 +------------+-------------+------+------------------------------+ 2654 Internet-draft February 26, 1998 2656 Seek to Time Command: 2657 +------------+-------------+------+------------------------------+ 2658 | Time | Timestamp | 32 | The point in time within the | 2659 | | | | stream to seek to. This value| 2660 | | | |has a millisecond granularity.| 2661 +------------+-------------+------+------------------------------+ 2662 Seek to Marker Command: 2663 +------------+-------------+------+------------------------------+ 2664 | Marker | UINT | 32 | The point in the stream to | 2665 | | | | seek to (in reference to | 2666 | | | | index locations indicated by | 2667 | | | | the Marker Object (Section | 2668 | | | | 5.6)). Values exceeding the | 2669 | | | | number of marker object | 2670 | | | | indexes will be ignored. | 2671 +------------+-------------+------+------------------------------+ 2672 For Filename Command: 2673 +------------+-------------+------+------------------------------+ 2674 | Filename | String | ?? | Identical to the Filename | 2675 | | | | Command (see Section 8.7). | 2676 +------------+-------------+------+------------------------------+ 2677 For Script Command: 2678 +------------+-------------+------+------------------------------+ 2679 | Type Field | UINT | 8 | Number of Unicode characters | 2680 | Size | | | in the Type Field. | 2681 +------------+-------------+------+------------------------------+ 2682 | Value Field| UINT | 16 | Number of Unicode characters | 2683 | Size | | | in the Value Field. | 2684 +------------+-------------+------+------------------------------+ 2685 | Type Field | Unicode | ?? | The Type field (e.g., Script | 2686 | | | | Name). | 2687 +------------+-------------+------+------------------------------+ 2688 | Value Field| Unicode | ?? | The Value field (e.g., | 2689 | | | | Script Contents). | 2690 +------------+-------------+------+------------------------------+ 2691 No Link Command field is present for Pause, Resume, Exit, and 2692 Same-Value commands. 2693 +-----------------+-------------+------+------------------------------+ 2695 Notes: 2696 The Horizontal and Vertical Resolution parameters determine the units 2697 by which the objects' geometry will be defined. These parameters 2698 describe the number of "logical units" in each frame width and height. 2700 Internet-draft February 26, 1998 2702 This relative representation provides easy interface for objects' re- 2703 sizing and media scaling. 2705 The Link Type defines the command that is linked to the object. This 2706 command is activated by a mouse-click upon the object. OBLinkType 2707 defines one of the following commands: 2708 0 = NO_LINK (nothing happens upon mouse click) 2709 1 = URL (flip a URL page) 2710 2 = SeekToTime 2711 3 = SeekToMarker 2712 4 = Filename (jump to another ASF file) 2713 5 = Script (Type/Value pair whose actual meaning (semantics) is locally 2714 defined. For example, the Type may indicate a script name and the Value 2715 may indicate the contents of the script body.) 2716 6 = Pause 2717 7 = Resume (ignore if pause had not previously been hit) 2718 8 = Exit 2719 9 = Same-Value: Continue to use the command which had been previously 2720 specified for this Object ID. [Note: if there was not a previously 2721 specified command for this Object ID, then the command for this Object 2722 ID will default to NO_LINK. This command type should not be used for 2723 instances in which the Command Entry Structure has been appended to the 2724 Object Structure of the Media Object Stream.] 2725 Values greater than 9 are Reserved 2727 The Marker Object mentioned for the Seek to Marker command is defined 2728 in Section 5.6. 2730 Media Stream Format: 2731 The following describes the structure of each object instance. Multiple 2732 object instances can optionally be directly concatenated together as an 2733 array of structures in one ASF Data Unit. Every instance encodes the 2734 object description and/or interactive features for a given duration. 2735 Each description is valid from its Start Time until its End Time. 2737 +-----------------+-------------+------+------------------------------+ 2738 | Field Name: | Field Type: | Size | Description: | 2739 | | |(bits)| | 2740 +-----------------+-------------+------+------------------------------+ 2741 | Object ID | UINT | 16 | A unique identifier of the | 2742 | | | | object | 2743 +-----------------+-------------+------+------------------------------+ 2744 | Start Time | UINT | 32 | The starting time of this | 2745 | | | | instance of the object | 2746 | | | | (presentation time value) | 2747 +-----------------+-------------+------+------------------------------+ 2748 | End Time | UINT | 32 | The ending time of this | 2749 | | | | instance of the object | 2750 | | | | (presentation time value) | 2752 Internet-draft February 26, 1998 2754 +-----------------+-------------+------+------------------------------+ 2755 | Object Shape | OBShape | 4 | The primitive shape of the | 2756 | | | | hotspot | 2757 +-----------------+-------------+------+------------------------------+ 2758 | Object Flags | OBFlags |4 -low| Different Flags assigned to | 2759 | | | order| the object (could be used by | 2760 | | |nibble| any external application) | 2761 +-----------------+-------------+------+------------------------------+ 2762 | Object Geometry | See Below |(4*16)| | 2763 | | |or (N*| | 2764 | | |2*16) | | 2765 +----+ +-------------+------+------------------------------+ 2767 Internet-draft February 26, 1998 2769 For primitive shape objects (Rectangle, Triangle, Ellipse, etc.): 2770 +------------+-------------+------+------------------------------+ 2771 | Left | UINT | 16 | X coordinate of the top-left | 2772 | | | | corner of the bounding | 2773 | | | | rectangle | 2774 +------------+-------------+------+------------------------------+ 2775 | Top | UINT | 16 | Y coordinate of the top-left | 2776 | | | | corner of the bounding | 2777 | | | | rectangle | 2778 +------------+-------------+------+------------------------------+ 2779 | Right | UINT | 16 | X coordinate of the bottom- | 2780 | | | | right corner of the bounding | 2781 | | | | rectangle | 2782 +------------+-------------+------+------------------------------+ 2783 | Bottom | UINT | 16 | Y coordinate of the bottom- | 2784 | | | | right corner of the bounding | 2785 | | | | rectangle | 2786 +------------+-------------+------+------------------------------+ 2787 For Polygon shape object: 2788 +------------+-------------+------+------------------------------+ 2789 | X1 | UINT | 16 | X coordinate of the first | 2790 | | | | vertex of the polygon | 2791 +------------+-------------+------+------------------------------+ 2792 | Y1 | UINT | 16 | Y coordinate of the first | 2793 | | | | vertex of the polygon | 2794 +------------+-------------+------+------------------------------+ 2795 | Xn ... | UINT | 16 | X coordinate of the n-th | 2796 | | | | vertex of the polygon | 2797 +------------+-------------+------+------------------------------+ 2798 | Yn ... | UINT | 16 | Y coordinate of the n-th | 2799 | | | | vertex of the polygon | 2800 +------------+-------------+------+------------------------------+ 2801 | XN | UINT | 16 | X coordinate of the last | 2802 | | | | vertex of the polygon | 2803 +------------+-------------+------+------------------------------+ 2804 | YN | UINT | 16 | Y coordinate of the last | 2805 | | | | vertex of the polygon | 2806 +------------+-------------+------+------------------------------+ 2808 Internet-draft February 26, 1998 2810 +-----------------+-------------+------+------------------------------+ 2811 | Effects Field | UINT | 8 | Cursor and visual effects | 2812 +----+ +-------------+------+------------------------------+ 2813 | Cursor Type| OBCursor | 4 | Cursor effects | 2814 +------------+-------------+------+------------------------------+ 2815 | Marking | OBMark |4 -low| Marking effects | 2816 | Type | |nibble| | 2817 +----+------------+-------------+------+------------------------------+ 2818 | Index | UINT | 16 | The command which will be | 2819 | | | | activated when actuating | 2820 | | | | this object | 2821 +-----------------+-------------+------+------------------------------+ 2823 Notes: 2824 Object ID is a unique identifier of the object, throughout its life 2825 span. 2827 The Start Time and End Time parameters are interpreted according the 2828 presentation time granularities of the visual media stream to which 2829 this particular Media Object stream was bound by means of the Inter- 2830 media Dependency Object. 2832 Object Shape selects one of the pre-defined shapes: 0 = Rectangle, 1 = 2833 Triangle, 2 = Ellipse, and 4 = Polygon. 2835 Object Flags field is defined in an implementation-specific manner. The 2836 default value of this field is zero. Clients may optionally ignore this 2837 field. 2839 The object geometry parameters are all represented in the 2840 Horizontal/Vertical Resolution units, which are defined in the stream 2841 header. 2843 For all primitive shapes (in other words Rectangle, Ellipse, Triangle), 2844 defining the bounding rectangle of the shape is sufficient to fully 2845 describe the shape. (That is also true, for an isosceles triangle with 2846 a horizontal base. For any other type of triangle, the polygon shape 2847 can be used.) 2849 The Cursor Type specifies the author's preference for cursor shape. 2850 OBCursor values are: 2851 0 = arrow 2852 1 = hand 2853 2 = hide cursor 2854 3 - 10 Implementation Specific 2855 11 - 15 Reserved 2857 Implementations may use the Implementation specific values in an 2858 implementation-specific manner. Clients may also optionally ignore 2859 interpreting the Cursor Type field altogether at their own discretion. 2861 The Marker Type visual effects associated with a hot spot. OBMark 2862 values are: 2863 0 = none 2864 1 = invert 2865 2 = darken 2866 3 = outline 2867 4 - 10 Implementation Specific 2868 11 - 15 Reserved 2870 Internet-draft February 26, 1998 2872 Implementations may use the Implementation specific values in an 2873 implementation-specific manner. Clients may also optionally ignore 2874 interpreting the Cursor Type field altogether at their own discretion. 2876 The Index value refers to which entry in the Command List Array (within 2877 the Stream Properties Object) is being activated. Index values 2878 exceeding the number of entries within the Command List Array will be 2879 ignored unless it is 0xFFFF (in other words, 65535 decimal). A value of 2880 0xFFFF signifies that a Command Entry Structure is appended to this 2881 object structure instance (for example, to support Real-Time Editing). 2883 Acknowledgements 2885 The Advanced Streaming Format (ASF) Specification was co-authored by 2886 Microsoft Corporation, RealNetworks, Intel Corporation, Adobe Systems 2887 Incorporated, and Vivo Software, Inc. Microsoft owns the copyright 2888 for the ASF Specification and is responsible for publishing the ASF 2889 Specification and any modifications thereto. 2891 In 1996, Microsoft developed a preliminary version of ASF and 2892 implemented it within its NetShow (tm) streaming server and client 2893 products. Microsoft Corporation, RealNetworks, Intel Corporation, 2894 Adobe Systems Incorporated, and Vivo Software, Inc then enhanced 2895 this preliminary version and authored an initial "straw man" draft 2896 of the ASF Specification. 2898 A first draft version of the ASF Specification was generated based upon 2899 the comments and feedback of an additional 45 companies. Following this, 2900 the ASF specification was made available for public comment, in which 2901 roughly 100 corporations and universities participated. On September 2902 30, 1997, Microsoft announced the free public availability of the 2903 completed specification. Several versions of the ASF Specification 2904 containing errata (e.g., clarifications) have subsequently been published 2905 at http://www.microsoft.com/asf/specs.htm. This document reflects the 2906 latest version of the ASF Specification (i.e., February 1998). 2908 Microsoft Intellectual Property Statement 2910 Copyright (c) 1997-1998 Microsoft Corporation. All rights reserved. 2912 Microsoft agrees to grant, and does grant to ISOC/IETF, a 2913 perpetual, nonexclusive, royalty-free, world-wide right and 2914 license under any Microsoft copyrights in this contribution to 2915 copy, publish and distribute the contribution, as well as a right 2916 and license of the same scope to any derivative works prepared by 2917 ISOC/IETF and based on, or incorporating all or part of the 2918 contribution. Microsoft further agrees that, upon adoption of 2919 this contribution as an RFC, any party will be able to obtain a 2920 royalty-free license under applicable Microsoft rights to implement 2921 and use the technology described in this contribution. One condition 2922 of this license shall be the party's agreement not to assert patent 2923 rights against Microsoft and other companies for their implementation 2924 of the contribution. Microsoft expressly reserves all other rights 2925 it may have in the material and subject matter of this contribution. 2926 Microsoft expressly disclaims any and all warranties regarding this 2927 contribution including any warranty that (a) this contribution does 2928 not violate the rights of others, (b) the owners, if any, of other 2929 rights in this contribution have been informed of the rights and 2930 permissions granted to ISOC herein or (c) any required authorizations 2931 from such owners have been obtained. 2933 Internet-draft February 26, 1998 2935 Submitter's Address 2937 Eric Fleischman 2938 Microsoft Corporation 2939 One Microsoft Way 2940 Redmond, WA 98052-6399 United States 2941 Electronic mail: ericfl@microsoft.com 2943 Bibliography 2945 [1] T. Krauskopf, J. Miller, P. Resnick, and G. W. Treese, "Label 2946 Syntax and Communication Protocols," World Wide Web Consortium 2947 http://www.w3.org/PICS/labels.html, May 5 1996. 2949 [2] J. Miller, P. Resnick, and D. Singer, "Rating Services and Rating 2950 Systems (and Their Machine Readable Descriptions)," World Wide Web 2951 Consortium http://www.w3.org/PICS/services.html, May 5 1996. 2953 [3] D. Crocker, "RFC 822: Standard for the Format of ARPA Internet 2954 Text Messages," ftp://ds.internic.net/rfc/rfc822.txt, August 1982. 2956 [4] H. Alvestrand, "RFC 1766: Tags for the Identification of 2957 Languages," ftp://ds.internic.net/rfc/rfc1766.txt, March 2, 1995. 2959 [5] "MARC Bibliographic Formats," 2960 http://www.fsc.follett.com/data/marctags/. 2962 [6] "Dublin Core Elements," ftp://ds.internic.net/internet- 2963 drafts/draft-kunze-dc-01.txt or 2964 http://purl.org/metadata/dublin_core_elements/. 2966 [7] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RFC 1889: 2967 RTP: A Transport Protocol for Real-Time Applications," January 1996; 2968 ftp://ds.internic.net/rfc/rfc1889.txt. 2970 Appendix A: ASF GUIDs 2972 Use of GUIDs within ASF 2973 GUIDs are used to uniquely identify all objects and entities within ASF 2974 files. This provides the foundation for the extensibility and 2975 flexibility that characterizes ASF. For example, versioning is 2976 transparently supported within ASF by this mechanism. That is, since 2977 each version of an ASF object has its own unique GUID, the ASF library 2978 knows how to interpret the semantics and syntax of any given version of 2979 that object based upon the GUID that is used. 2981 Similarly, each ASF multimedia object type is uniquely identified by a 2982 GUID. New media types can be created, identified by their own GUID, and 2983 inserted into ASF data streams. 2985 Internet-draft February 26, 1998 2987 Similarly, new codec types, new error correction approaches, and novel 2988 innovations of all types can be readily invented, identified by GUIDs 2989 and used within ASF. 2991 New ASF object types (for example, see Other Objects as is shown in 2992 Figure 2 of Section 3.2 as well as explicit text within Sections 5.1 2993 and 5.3) may be defined. This forms a chief "extensibility feature" of 2994 ASF to support new innovations and inventions as they arise. Each new 2995 ASF object type needs its own unique GUID identification. 2997 ASF GUIDs 2998 The following are standard GUIDs that have been defined for all ASF 2999 objects and GUID-based fields within this specification. This list is 3000 not exhaustive. Implementations may supplement this list with 3001 additional GUIDs when necessary to identify entities/elements/ideas 3002 that have not yet been enumerated by this appendix. 3004 Microsoft will endeavor to maintain a list of the additional GUID 3005 definitions (about which it has been informed) at a public Web site. 3006 The initial location of this web site will be 3007 http://www.microsoft.com/asf/ Companies desiring to register additional 3008 GUID definitions should send an email message to ASF@microsoft.com. 3010 Standard Base ASF Objects GUIDs 3011 ASF Header Object {D6E229D1-35DA-11d1-9034-00A0C90349BE} 3012 ASF Data Object {D6E229D2-35DA-11d1-9034-00A0C90349BE} 3013 ASF Index Object {D6E229D3-35DA-11d1-9034-00A0C90349BE} 3015 Standard ASF Header Object GUIDs 3016 File Properties Object {D6E229D0-35DA-11d1-9034-00A0C90349BE} 3017 Stream Properties Object {D6E229D4-35DA-11d1-9034-00A0C90349BE} 3018 Data Unit Extension Object {D6E22A0F-35DA-11d1-9034-00A0C90349BE} 3019 Content Description Object {D6E229D5-35DA-11d1-9034-00A0C90349BE} 3020 Script Command Object {D6E229D6-35DA-11d1-9034-00A0C90349BE} 3021 Marker Object {D6E229D7-35DA-11d1-9034-00A0C90349BE} 3022 Component Download Object {D6E229D8-35DA-11d1-9034-00A0C90349BE} 3023 Stream Group Object {D6E229D9-35DA-11d1-9034-00A0C90349BE} 3024 Scalable Object {D6E229DA-35DA-11d1-9034-00A0C90349BE} 3025 Prioritization Object {D6E229DB-35DA-11d1-9034-00A0C90349BE} 3026 Mutual Exclusion Object {D6E229DC-35DA-11d1-9034-00A0C90349BE} 3027 Inter-Media Dependency Object {D6E229DD-35DA-11d1-9034-00A0C90349BE} 3028 Rating Object {D6E229DE-35DA-11d1-9034-00A0C90349BE} 3029 Index Parameters Object {D6E229DF-35DA-11d1-9034-00A0C90349BE} 3030 Color Table Object {D6E229E0-35DA-11d1-9034-00A0C90349BE} 3031 Language List Object {D6E229E1-35DA-11d1-9034-00A0C90349BE} 3033 Other ASF Header Object GUIDs 3034 ASF Placeholder Object {D6E22A0E-35DA-11d1-9034-00A0C90349BE} 3036 Internet-draft February 26, 1998 3038 Standard GUIDs for the Stream Type Field of the Stream Properties 3039 Object 3040 Audio Media {D6E229E2-35DA-11d1-9034-00A0C90349BE} 3041 Video Media {D6E229E3-35DA-11d1-9034-00A0C90349BE} 3042 Image Media {D6E229E4-35DA-11d1-9034-00A0C90349BE} 3043 Timecode Media {D6E229E5-35DA-11d1-9034-00A0C90349BE} 3044 Text Media {D6E229E6-35DA-11d1-9034-00A0C90349BE} 3045 MIDI Media {D6E229E7-35DA-11d1-9034-00A0C90349BE} 3046 Command Media {D6E229E8-35DA-11d1-9034-00A0C90349BE} 3047 Media-Object (Hotspot) {D6E229FF-35DA-11d1-9034-00A0C90349BE} 3049 Codecs for Audio and Video Media Types 3050 A GUID is needed for each version of a codec implementation that 3051 produces dissimilar encodings of the same input. Microsoft will 3052 maintain a list of GUIDs according to their Codec/version number at a 3053 Microsoft Web site. The initial location of this site is 3054 http://www.microsoft.com/asf/ Companies that want to register the GUIDs 3055 of additional Codec/version numbers should send their registrations to 3056 ASF@microsoft.com. 3058 GUIDs for the Error Concealment Type Field of the Audio Media Type 3059 No Error Concealment {D6E229EA-35DA-11d1-9034-00A0C90349BE} 3060 Scrambled Audio (see Section 8.1.1) {D6E229EB-35DA-11d1-9034- 3061 00A0C90349BE} 3063 GUIDs for the Color Table ID field of the Video and Image Media Types 3064 No Color Table {D6E229EC-35DA-11d1-9034-00A0C90349BE} 3066 GUIDs for the Timecode ID of the Timecode Media Type 3067 SMPTE Time {D6E229ED-35DA-11d1-9034-00A0C90349BE} 3069 GUIDs for the Text Encoding System Field of the Text Media Type 3070 ASCII Text {D6E229EE-35DA-11d1-9034-00A0C90349BE} 3071 Unicode Text {D6E229EF-35DA-11d1-9034-00A0C90349BE} 3072 HTML Text {D6E229F0-35DA-11d1-9034-00A0C90349BE} 3074 GUIDs for the Extension System Field of the Data Unit Extension Object 3075 RTP Extension Data {96800c63-4c94-11d1-837b-0080c7a37f95} 3077 GUIDs for the Command Type Field of the Command Media Type 3078 URL Command {D6E229F1-35DA-11d1-9034-00A0C90349BE} 3079 Filename Command {D6E229F2-35DA-11d1-9034-00A0C90349BE} 3081 GUIDs for the Category Field of the Component Download Object 3082 ACM Codec {D6E229F3-35DA-11d1-9034-00A0C90349BE} 3084 Internet-draft February 26, 1998 3086 VCM Codec {D6E229F4-35DA-11d1-9034-00A0C90349BE} 3087 QuickTime Codec {D6E229F5-35DA-11d1-9034-00A0C90349BE} 3088 DirectShow Transform Filter {D6E229F6-35DA-11d1-9034-00A0C90349BE} 3089 DirectShow Rendering Filter {D6E229F7-35DA-11d1-9034-00A0C90349BE} 3091 Enhancement GUIDs for the Scalable Object 3092 No Enhancement {D6E229F8-35DA-11d1-9034-00A0C90349BE} 3093 Unknown Enhancement Type {D6E229F9-35DA-11d1-9034-00A0C90349BE} 3094 Temporal Enhancement {D6E229FA-35DA-11d1-9034-00A0C90349BE} 3095 Spatial Enhancement {D6E229FB-35DA-11d1-9034-00A0C90349BE} 3096 Quality Enhancement {D6E229FC-35DA-11d1-9034-00A0C90349BE} 3097 Number of Channels Enhancement (for example, Stereo) 3098 {D6E229FD-35DA-11d1-9034-00A0C90349BE} 3099 Frequency Response Enhancement {D6E229FE-35DA-11d1-9034-00A0C90349BE} 3101 GUIDs for the Exclusion Type Field of the Mutual Exclusion Object 3102 Language {D6E22A00-35DA-11d1-9034-00A0C90349BE} 3103 Same Content at Different Bit Rates 3104 {D6E22A01-35DA-11d1-9034-00A0C90349BE} 3105 Unknown Reason {D6E22A02-35DA-11d1-9034-00A0C90349BE} 3107 Appendix B: Bit Stream Types 3109 The bit stream type describes the target data type and the order of 3110 transmission of bits in the coded bit stream. The bit stream types are 3111 ASCII, GUID, FILETIME, UINT, and Unicode. 3113 ASCII: 3114 A UINT8 (see UINT below) value containing ASCII data. ASCII data is 3115 defined in RFC 1766. 3117 FILETIME: 3118 A 64-bit integer that contains a time stamp corresponding to the number 3119 of 100 nanosecond ticks since January 1, 1601. The following diagram 3120 demonstrates the filetime format: 3122 (MSB) (LSB) 3123 +--------+--------+--------+--------+--------+--------+--------+--------+ 3124 | byte 0 | byte 1 | byte 2 | byte 3 | byte 4 | byte 5 | byte 6 | byte 7 | 3125 +--------+--------+--------+--------+--------+--------+--------+--------+ 3126 <--------------------------------- 64 bits -----------------------------> 3128 The GMT time zone is used for all filetime entries. 3130 Internet-draft February 26, 1998 3132 GUID: 3133 The terms GUID (globally unique identifier) and UUID (universally 3134 unique identifier) are identical. GUIDs are a 128-bit (16 octet) data 3135 structure composed of a 32-bit unsigned integer, two 16-bit unsigned 3136 integers, and an array of eight octets. The constituent parts are shown 3137 in the following diagrams: 3139 (MSB) (LSB) 3140 +-------+-------+-------+-------+ 3141 |byte 0 |byte 1 |byte 2 |byte 3 | 3142 +-------+-------+-------+-------+ 3143 <------------32 bits------------> 3144 UNSIGNED INTEGER 3146 (MSB) (LSB) 3147 +-------+-------+ 3148 |byte 0 |byte 1 | 3149 +-------+-------+ 3150 <----16 bits----> 3151 UNSIGNED INTEGER 3153 (MSB) (LSB) 3154 +-------+-------+ 3155 |byte 0 |byte 1 | 3156 +-------+-------+ 3157 <----16 bits----> 3158 UNSIGNED INTEGER 3160 (MSB) (LSB) 3161 +-------+-------+...+-------+-------+ 3162 |byte 0 |byte 1 |...|byte 7 |byte 8 | 3163 +-------+-------+...+-------+-------+ 3164 <--------------64 bits------------->| 3165 FIXED-LENGTH ARRAY 3167 These components are concatenated to form the UUID: 3169 (MSB) (LSB) 3170 +-------+-------+-------+-------+-------+-------+...+-------+-------+ 3171 |byte 0 |byte 1 |byte 2 |byte 3 |byte 4 |byte 5 |...|byte 14|byte 15| 3172 +-------+-------+-------+-------+-------+-------+...+-------+-------+ 3173 <-------------------------------128 bits----------------------------> 3174 UNIVERSALLY UNIQUE IDENTIFIER (UUID) 3176 Internet-draft February 26, 1998 3178 UINT: 3179 Unsigned integer in Little-Endian byte and Little-Endian bit order. 3180 When a number is appended to UINT, the number refers to the number of 3181 bits contained within this unsigned integer value. For example: 3182 * UINT64 is an unsigned integer value that is 64 bits long 3183 * UINT32 is an unsigned integer value that is 32 bits long 3184 * UINT16 is an unsigned integer value that is 16 bits long 3185 * UINT8 is an unsigned integer value that is 8 bits long. 3187 UNICODE: 3188 A UINT16 (see UINT above) value containing Unicode data. 3190 Appendix C: GUIDs and UUIDs 3192 ABSTRACT 3194 This appendix describes the format of UUIDs (Universally Unique 3195 IDentifier), which are also known as GUIDs (Globally Unique 3196 IDentifier). A GUID is 128 bits long, and if generated according to the 3197 one of the mechanisms in this document, is either guaranteed to be 3198 different from all other UUIDs/GUIDs generated until 3400 A.D. or 3199 extremely likely to be different (depending on the mechanism chosen). 3200 GUIDs were originally used in the Network Computing System (NCS) [1] 3201 and later in the Open Software Foundation's (OSF) Distributed Computing 3202 Environment [2]. 3204 This specification is derived from the latter specification with the 3205 kind permission of the OSF. 3207 Introduction 3209 This specification defines the format of UUIDs (Universally Unique 3210 IDentifiers), also known as GUIDs (Globally Unique IDentifiers). A GUID 3211 is 128 bits long, and if generated according to the one of the 3212 mechanisms in this document, is either guaranteed to be different from 3213 all other UUIDs/GUIDs generated until 3400 A.D. or extremely likely to 3214 be different (depending on the mechanism chosen). 3216 Motivation 3218 One of the main reasons for using GUIDs is that no centralized 3219 authority is required to administer them (beyond the one that allocates 3220 IEEE 802.1 node identifiers). As a result, generation on demand can be 3221 completely automated, and they can be used for a wide variety of 3222 purposes. The GUID generation algorithm described here supports very 3224 Internet-draft February 26, 1998 3226 high allocation rates: 10 million per second per machine if you need 3227 it, so that they could even be used as transaction IDs. GUIDs are 3228 fixed-size (128 bits), which is reasonably small relative to other 3229 alternatives. This fixed, relatively small size lends itself well to 3230 sorting, ordering, hashing of all sorts, storing in databases, simple 3231 allocation, and ease of programming in general. 3232 Specification 3234 A GUID is an identifier that is unique across both space and time, with 3235 respect to the space of all GUIDs. To be precise, the GUID consists of 3236 a finite bit space. Thus the time value used for constructing a GUID is 3237 limited and will roll over in the future (at approximately A.D. 3400, 3238 based on the specified algorithm). A GUID can be used for multiple 3239 purposes, from tagging objects with an extremely short lifetime, to 3240 reliably identifying very persistent objects across a network. 3242 The generation of GUIDs does not require that a registration authority 3243 be contacted for each identifier. Instead, it requires a unique value 3244 over space for each GUID generator. This spatially unique value is 3245 specified as an IEEE 802 address, which is usually already available to 3246 network-connected systems. This 48-bit address can be assigned based on 3247 an address block obtained through the IEEE registration authority. This 3248 section of the GUID specification assumes the availability of an IEEE 3249 802 address to a system desiring to generate a GUID, but if one is not 3250 available, Section 4 specifies a way to generate a probabilistically 3251 unique one that can not conflict with any properly assigned IEEE 802 3252 address. 3254 C.1 Format 3256 The following table gives the format of a GUID. 3257 +-----------------------+---------+-------+---------------------------+ 3258 | Field: |Data Type|Octet #| Note: | 3259 +-----------------------+---------+-------+---------------------------+ 3260 | time_low | UINT32 | 0 - 3 | The low field of the | 3261 | | | | timestamp | 3262 | time_mid | UINT16 | 4 - 5 | The middle field of the | 3263 | | | | timestamp | 3264 | time_hi_and_version | UINT16 | 6 - 7 | The high field of the | 3265 | | | | timestamp multiplexed | 3266 | | | | with the version number | 3267 | clock_seq_hi_and_res- | UINT8 | 8 | The high field of the | 3268 | erved | | | clock sequence multiplexed| 3269 | | | | with the variant | 3270 | time_low | UINT8 | 9 | The low field of the | 3271 | | | | clock sequence | 3272 | node | UINT8 | 10-15 | The spatially unique | 3273 | | array | | node identifier | 3274 +-----------------------+---------+-------+---------------------------+ 3276 Internet-draft February 26, 1998 3278 The GUID consists of a record of 16 octets and must not contain padding 3279 between fields. The total size is 128 bits. 3281 To minimize confusion about bit assignments within octets, the GUID 3282 record definition is defined only in terms of fields that are integral 3283 numbers of octets. The version number is multiplexed with the timestamp 3284 (time_high), and the variant field is multiplexed with the clock 3285 sequence (clock_seq_high). 3287 The timestamp is a 60-bit value. For GUID version 1, this is 3288 represented by Coordinated Universal Time (UTC) as a count of 100- 3289 nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of 3290 Gregorian reform to the Christian calendar). 3292 The version number is multiplexed in the 4 most significant bits of the 3293 time_hi_and_version field. 3295 The following table lists currently defined versions of the GUID. 3296 +------+------+------+------+---------+-------------------------------+ 3297 | msb1 | msb2 | msb3 | msb4 | Version | Description | 3298 +------+------+------+------+---------+-------------------------------+ 3299 | 0 | 0 | 0 | 1 | 1 | DCE version | 3300 | 0 | 0 | 3 | 0 | 2 | DCE security version with | 3301 | | | | | | embedded POSIX UIDs | 3302 +------+------+------+------+---------+-------------------------------+ 3304 The variant field determines the layout of the GUID. The structure of 3305 DCE GUIDs is fixed across different versions. Other GUID variants may 3306 not interoperate with DCE GUIDs. Interoperability of GUIDs is defined 3307 as the applicability of operations such as string conversion, 3308 comparison, and lexical ordering across different systems. The variant 3309 field consists of a variable number of the MSBS of the 3310 clock_seq_hi_and_reserved field. 3312 The following table lists the contents of the DCE variant field. 3313 +------+------+------+-----------------------------------------------+ 3314 | msb1 | msb2 | msb3 |Description: | 3315 +------+------+------+-----------------------------------------------+ 3316 | 0 | - | - | Reserved, NCS backward compatibility | 3317 | 1 | 0 | - | DCE variant | 3318 | 1 | 1 | 0 | Reserved, Microsoft Corporation GUID | 3319 | 1 | 1 | 1 | Reserved for future definition | 3320 +------+------+------+-----------------------------------------------+ 3322 The clock sequence is required to detect potential losses of 3323 monotonicity of the clock. Thus, this value marks discontinuities and 3325 Internet-draft February 26, 1998 3327 prevents duplicates. An algorithm for generating this value is outlined 3328 in the "Clock Sequence" section below. 3330 The clock sequence is encoded in the 6 least significant bits of the 3331 clock_seq_hi_and_reserved field and in the clock_seq_low field. 3333 The node field consists of the IEEE address, which is usually the host 3334 address. For systems with multiple IEEE 802 nodes, any available node 3335 address can be used. The lowest addressed octet (octet number 10) 3336 contains the global/local bit and the unicast/multicast bit, and is the 3337 first octet of the address transmitted on an 802.3 LAN. 3339 Depending on the network data representation, the multi-octet unsigned 3340 integer fields are subject to byte swapping when communicated between 3341 different endian machines. 3343 The nil GUID is special form of GUID that is specified to have all 128 3344 bits set to 0 (zero). 3346 C.2 Algorithms for Creating a GUID 3348 Various aspects of the algorithm for creating a GUID are discussed in 3349 the following sections. GUID generation requires a guarantee of 3350 uniqueness within the node ID for a given variant and version. 3351 Interoperability is provided by complying with the specified data 3352 structure. To prevent possible GUID collisions, which could be caused 3353 by different implementations on the same node, compliance with the 3354 algorithms specified here is required. 3356 C.2.1 Clock Sequence 3358 The clock sequence value must be changed whenever: 3359 * The GUID generator detects that the local value of UTC has gone 3360 backward; this may be due to normal functioning of the DCE Time 3361 Service. 3362 * The GUID generator has lost its state of the last value of UTC used, 3363 indicating that time \f2 may have gone backward; this is typically 3364 the case on reboot. 3366 While a node is operational, the GUID service always saves the last UTC 3367 used to create a GUID. Each time a new GUID is created, the current UTC 3368 is compared to the saved value and if either the current value is less 3369 (the non-monotonic clock case) or the saved value was lost, then the 3370 clock sequence is incremented modulo 16,384, thus avoiding production 3371 of duplicate GUIDs. 3373 Internet-draft February 26, 1998 3375 The clock sequence must be initialized to a random number to minimize 3376 the correlation across systems. This provides maximum protection 3377 against node identifiers that may move or switch from system to system 3378 rapidly. The initial value MUST NOT be correlated to the node 3379 identifier. 3381 The rule of initializing the clock sequence to a random value is waived 3382 if, and only if, all of the following are true: 3383 * The clock sequence value is stored in a form of non-volatile 3384 storage. 3385 * The system is manufactured such that the IEEE address ROM is 3386 designed to be inseparable from the system by either the user or 3387 field service, so that it cannot be moved to another system. 3388 * The manufacturing process guarantees that only new IEEE address ROMs 3389 are used. 3390 * Any field service, remanufacturing or rebuilding process that could 3391 change the value of the clock sequence must reinitialise it to a 3392 random value. 3394 In other words, the system constraints prevent duplicates caused by 3395 possible migration of the IEEE address, while the operational system 3396 itself can protect against non-monotonic clocks, except in the case of 3397 field service intervention. At manufacturing time, such a system may 3398 initialise the clock sequence to any convenient value. 3400 C.2.2 System Reboot 3402 There are two possibilities when rebooting a system: 3403 * The GUID generator states that the last UTC, adjustment, and clock 3404 sequence of the GUID service has been restored from non-volatile 3405 store. 3406 * The state of the last UTC or adjustment has been lost. 3408 If the state variables have been restored, the GUID generator just 3409 continues as normal. Alternatively, if the state variables cannot be 3410 restored, they are reinitialized, and the clock sequence is changed. 3411 If the clock sequence is stored in non-volatile store, it is 3412 incremented; otherwise, it is reinitialized to a new random value. 3414 C.2.3 Clock Adjustment 3416 GUIDs may be created at a rate greater than the system clock 3417 resolution. Therefore, the system must also maintain an adjustment 3418 value to be added to the lower-order bits of the time. Logically, each 3419 time the system clock ticks, the adjustment value is cleared. Every 3420 time a GUID is generated, the current adjustment value is read and 3422 Internet-draft February 26, 1998 3424 incremented atomically, and then added to the UTC time field of the 3425 GUID. 3427 C.2.4 Clock Overrun 3429 The 100-nanosecond granularity of time should prove sufficient even for 3430 bursts of GUID creation in the next generation of high-performance 3431 multiprocessors. If a system overruns the clock adjustment by 3432 requesting too many GUIDs within a single system clock tick, the GUID 3433 service may raise an exception, handled in a system or process- 3434 dependent manner either by: 3435 * Terminating the requester. 3436 * Reissuing the request until it succeeds. 3437 * Stalling the GUID generator until the system clock catches up. 3439 If the processors overrun the GUID generation frequently, additional 3440 node identifiers and clocks may need to be added. 3442 C.2.5 GUID Generation 3444 GUIDs are generated according to the following algorithm: 3445 * Determine the values for the UTC-based timestamp and clock sequence 3446 to be used in the GUID. 3447 * Sections format and clock_seq define how to determine these values. 3448 For the purposes of this algorithm, consider the timestamp to be a 3449 60-bit unsigned integer and the clock sequence to be a 14-bit 3450 unsigned integer. Sequentially number the bits in a field, starting 3451 from 0 (zero) for the least significant bit. 3452 * Set the time_low field equal to the least significant 32 bits (bits 3453 numbered 0 to 31 inclusive) of the time stamp in the same order of 3454 significance. If a DCE Security version GUID is being created, then 3455 replace the time_low field with the local user security attribute as 3456 defined by the \*(ZB. 3457 * Set the time_mid field equal to the bits numbered 32 to 47 inclusive 3458 of the timestamp in the same order of significance. 3459 * Set the 12 least significant bits (bits numbered 0 to 11 inclusive) 3460 of the time_hi_and_version field equal to the bits numbered 48 to 59 3461 inclusive of the time stamp in the same order of significance. 3462 * Set the 4 most significant bits (bits numbered 12 to 15 inclusive) 3463 of the time_hi_and_version field to the 4-bit version number 3464 corresponding to the GUID version being created, as shown in the 3465 table above. 3466 * Set the clock_seq_low field to the 8 least significant bits (bits 3467 numbered 0 to 7 inclusive) of the clock sequence in the same order 3468 of significance. 3470 Internet-draft February 26, 1998 3472 * Set the 6 least significant bits (bits numbered 0 to 5 inclusive) of 3473 the clock_seq_hi_and_reserved field to the 6 most significant bits 3474 (bits numbered 8 to 13 inclusive) of the clock sequence in the same 3475 order of significance. 3476 * Set the 2 most significant bits (bits numbered 6 and 7) of the 3477 clock_seq_hi_and_reserved to 0 and 1, respectively. 3478 * Set the node field to the 48-bit IEEE address in the same order of 3479 significance as the address. 3481 C.3 String Representation of GUIDs 3483 For use in human-readable text, a GUID string representation is 3484 specified as a sequence of fields, some of which are separated by 3485 single dashes. 3487 Each field is treated as an integer and has its value printed as a 3488 zero-filled hexadecimal digit string with the most significant digit 3489 first. The hexadecimal values a to f inclusive are output as lowercase 3490 characters, and are case-insensitive on input. The sequence is the same 3491 as the GUID constructed type. 3493 The formal definition of the GUID string representation is provided by 3494 the following extended BNF: 3495 GUID = 3496 3497 3498 3499 time_low = 3500 time_mid = 3501 time_high_and_version = 3502 clock_seq_and_reserved = 3503 clock_seq_low = 3504 node = 3505 3506 hexOctet = 3507 hexDigit = | | | | | | 3508 digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" 3509 | 3510 "8" | "9" 3511 hyphen = "-" 3512 a = "a" | "A" 3513 b = "b" | "B" 3514 c = "c" | "C" 3515 d = "d" | "D" 3516 e = "e" | "E" 3517 f = "f" | "F" 3519 The following is an example of the string representation of a GUID: 3520 2fac1234-31f8-11b4-a222-08002b34c003 3522 Internet-draft February 26, 1998 3524 C.4 Comparing GUIDs 3526 The following table lists the GUID fields in order of significance, 3527 from most significant to least significant, for purposes of GUID 3528 comparison. The table also shows the data types applicable to the 3529 fields. 3531 +--------------------------------+------------------------------------+ 3532 | Field: | Type: | 3533 +--------------------------------+------------------------------------+ 3534 | time_low | Unsigned 32-bit integer | 3535 | time_mid | Unsigned 16-bit integer | 3536 | time_hi_and_version | Unsigned 16-bit integer | 3537 | clock_seq_hi_and_reserved | Unsigned 8-bit integer | 3538 | clock_seq_low | Unsigned 8-bit integer | 3539 | node | Unsigned 48-bit integer | 3540 +--------------------------------+------------------------------------+ 3542 Consider each field to be an unsigned integer as shown above. Then, to 3543 compare a pair of GUIDs, arithmetically compare the corresponding 3544 fields from each GUID in order of significance and according to their 3545 data type. Two GUIDs are equal if and only if all the corresponding 3546 fields are equal. The first of two GUIDs follows the second if the most 3547 significant field in which the GUIDs differ is greater for the first 3548 GUID. The first of a pair of GUIDs precedes the second if the most 3549 significant field in which the GUIDs differ is greater for the second 3550 GUID. 3552 C.5 Node IDs when no IEEE 802 network card is available 3554 If a system wants to generate GUIDs but has no IEE 802-compliant 3555 network card or other source of IEEE 802 addresses, then this section 3556 describes how to generate one. 3558 The ideal solution is to obtain a 47-bit cryptographic quality random 3559 number, and use it as the low 47 bits of the node ID, with the high- 3560 order bit of the node ID set to 1. (The high-order bit is the 3561 unicast/multicast bit, which will never be set in IEEE 802 addresses 3562 obtained from network cards.) 3564 If a system does not have a primitive to generate cryptographic quality 3565 random numbers, then in most systems there are usually a fairly large 3566 number of sources of randomness available from which one can be 3567 generated. Such sources are system-specific, but often include: 3568 * the percent of memory in use 3570 Internet-draft February 26, 1998 3572 * the size of main memory in bytes 3573 * the amount of free main memory in bytes 3574 * the size of the paging or swap file in bytes 3575 * free bytes of paging or swap file 3576 * the total size of user virtual address space in bytes 3577 * the total available user address space bytes 3578 * the size of boot disk drive in bytes 3579 * the free disk space on boot drive in bytes 3580 * the current time 3581 * the amount of time since the system booted 3582 * the individual sizes of files in various system directories 3583 * the creation, last read, and modification times of files in 3584 various system directories 3585 * the utilization factors of various system resources (heap, and so 3586 on.) 3587 * current mouse cursor position 3588 * current caret position 3589 * current number of running processes, threads 3590 * handles or IDs of the desktop window and the active window 3591 * the value of stack pointer of the caller 3592 * the process and thread ID of caller 3593 * various processor architecture specific performance counters 3594 (instructions executed, cache misses, TLB misses) 3596 In addition, items such as the computer's name and the name of the 3597 operating system, while not strictly speaking random, will 3598 differentiate the results from those obtained by other systems. 3600 The exact algorithm to generate a node ID using this data is system- 3601 specific, because both the data available and the functions to 3602 obtain them are often very system-specific. However, assuming that 3603 one can concatenate all the values from the randomness sources into 3604 a buffer, and that a cryptographic hash function such as MD5 [3] is 3605 available, the following code will compute a node ID: 3607 #include 3608 #define HASHLEN 16 3610 void GenNodeID( 3611 unsigned char * pDataBuf, // concatenated "randomness values" 3612 long cData, // size of randomness values 3613 unsigned char NodeID[6] // node ID 3614 ) { 3615 int i, j, k; 3616 unsigned char Hash[HASHLEN]; 3617 MD_CTX context; 3619 Internet-draft February 26, 1998 3621 MDInit (&context); 3622 MDUpdate (&context, pDataBuf, cData); 3623 MDFinal (Hash, &context); 3625 for (i,j = 0; i < HASHLEN; i++) { 3626 NodeID[j] ^= Hash[i]; 3627 if (j == 6) j = 0; 3628 }; 3629 NodeID[0] |= 0x80; // set the multicast bit 3630 }; 3632 Other hash functions, such as SHA-1 [4], can also be used (in which 3633 case HASHLEN will be 20). The only requirement is that the result be 3634 suitably random - in the sense that the outputs from a set uniformly 3635 distributed inputs are themselves uniformly distributed, and that a 3636 single bit change in the input can be expected to cause half of the 3637 output bits to change. 3639 C.6 Appendix C's References 3641 [1] Lisa Zahn, et.al. Network Computing Architecture. Englewood 3642 Cliffs, NJ: Prentice Hall, 1990 3643 [2] OSF DCE Spec 3644 [3] R. Rivest, RFC 1321, "The MD5 Message-Digest Algorithm," 3645 04/16/1992. 3646 [4] SHA Spec