ASF文件格式

ASF（Advanced Streaming Format）是微软公司针对real公司开发的新一代网上流式数字音频压缩技术，是Microsoft为Windows98所开发的串流多媒体文件格式，是包含音频、视频、图像以及控制命令脚本的数据格式。这种压缩技术的特点是同时兼顾了保真度和网络传输需求，可和WMA及WMV互换使用。

ASF - 概述

ASF是（AdvancedStreamingFormat高级串流格式）的缩写，是微软公司针对real公司开发的新一代网上流式数字音频压缩技术，是Microsoft为Windows98所开发的串流多媒体文件格式。ASF是微软公司WindowsMedia的核心。这是一种包含音频、视频、图像以及控制命令脚本的数据格式。可和WMA及WMV互换使用。ASF是一个可扩展的文件格式用来存储多媒体数据同步。它支持的数据传输了各种各样的网络和协议同时还证明适合当地播放。在明确目标的ASF是提供一个基础，全行业的多媒体互操作性。每个格式的文件是由一个或多个媒体流。该文件头指定的内容整个文件，连同流的具体内容。多媒体数据，储存后的文件头，特别提到媒体流编号，以表明其类型和目的。提供和介绍的所有媒体流数据同步到一个共同的时间线。

ASF是一个开放标准，它能依靠多种协议在多种网络环境下支持数据的传送。同JPG、MPG文件一样，ASF文件也是一种文件类型，但它是专为在IP网上传送有同步关系的多媒体数据而设计的，所以ASF格式的信息特别适合在IP网上传输。ASF文件的内容既可以是熟悉的普通文件，也可以是一个由编码设备实时生成的连续的数据流，所以ASF既可以传送人们事先录制好的节目，也可以传送实时产生的节目。
　　
ASF用于排列、组织、同步多媒体数据以利于通过网络传输。ASF是一种数据格式，它也可用于指定实况演示。ASF最适于通过网络发送多媒体流，也同样适于在本地播放。任何压缩/解压缩运算法则（编解码器）都可用来编码ASF流。
　　
Windows Media Service的核心是ASF。ASF是一种数据格式，音频、视频、图像以及控制命令脚本等多媒体信息通过这种格式，以网络数据包的形式传输，实现流式多媒体内容发布。其中，在网络上传输的内容就称为ASFStream。ASF支持任意的压缩/解压缩编码方式，并可以使用任何一种底层网络传输协议，具有很大的灵活性。
　　
Microsoft Mediaplayer是能播放几乎所有多媒体文件的播放器，支持ASF在Internet网上的流文件格式，可以一边下载一边实时播放，无需下载完再听。ASF文件本地或网络回放；可扩充的媒体类型；部件下载、可伸缩的媒体类型；流的优先级化；多语言支持、环境独立性；丰富的流间关系以及扩展性等。

ASF 文件和 WMV 或 WMA 文件之间的唯一区别是文件扩展名和 MIME 类型。为 WMV 文件的 MIME 类型是 视频/x-ms-wmv，而 WMA 它为 音频/x-ms-wma。视频/x-毫秒的 asf ASF 的 MIME 类型。该文件的基本的内部结构是相同的。

ASF - ASF文件功能

ASF流文件的数据速率可以在28.8Kbps到3Mbps之间变化。用户可以根据自己应用环境和网络条件选择一个合适的速率，实现VOD点播和直播。

1、点播（VideoOnDemand）
因为ASF技术支持任意的压缩/解压缩编码，可以使用任何一种底层网络传输协议，这使它既能在高速的局域网内使用，也可以在拨号方式连接的低带宽Internet环境下使用。点播服务方式下，用户之间互不干扰，可以对点播内容的播放进行控制。这种方式最为灵活，但是占用服务器、网络资源。
　　
ASF的点播内容均存放在VOD服务器上，建立VOD站点进行网页发布，在同一时间可多点同时点播相同或不同的节目，即多个计算机可在不同的地点、不同的时刻，实时、交互式地点播同一ASF流文件，用户可以通过上网查看和选择内容进行点播。播放过程中可实现播放、停止、暂停、快进、后退等功能，播放速率达到25帧/s,1小时的视频信息按照300Kb/s采集，只占108MB的空间，1张640MB的光盘可存放将近6小时的ASF文件。

2、直播
直播服务下，用户只能观看播放的内容，无法进行控制。可以使用ASF文件作为媒体内容的来源，实时的多媒体内容最适合使用直播服务方式。通过视频捕捉卡把摄像机、麦克风记录的内容输入到计算机，进行编码生成ASF流，然后通过该机把信号传送到网络，用户通过网页收看直播内容。

计算机可同时接收相同或不同的节目频道，直播计算机可作为一个小电视台，连在网上的每一台计算机都可实时接收9个不同的节目频道。

3、远程教育
这种ASF文件远程教育系统由制作计算机、VOD服务器、用户机组成。
　　
制作ASF文件计算机安装视频采集卡、声卡及摄像机，用于制作流媒体文件；VOD服务器用于存储和发布流媒体信息；用户机是连在网上的普通多媒体计算机，通过网页进行学习。网页上有教员授课的视频文件、多媒体课件、学习内容提要、参考资料、复习/练习题、作业等信息。

ASF - ASF1.0介绍

高级流格式是由微软公司在1995年至1998年。其主要目的是作为一个普遍的形式存储和流媒体。有两个版本的ASF。一个版本是ASF2.0，另一个版本的ASF1.0。这里介绍ASF1.0：

ASF 对象定义
　 ASF文件基本的组织单元叫做ASF 对象，它是由一个128位的全球唯一的对象标识符（Object ID）,一个64位整数的对象大小（Object Size）和一个可变长的对象数据（Object Data）组成。对象大小域的值是由对象数据的大小加上24比特之和。

　                     ASF对象
　 这个文件组织单元有点类似于RIFF（Resource Interchange File Format）字节片。RIFF字节片时AVI和WAV文件的基本单位。ASF对象在两个方面改进了RIFF的设计。首先，无需一个权威机构来管理对象标识符系统，因为计算机网卡能够产生一个有效的唯一的GUID。其次，对象大小字段已定义得足够处理高带宽多媒体内容的大文件。

高层文件结构
　 ASF文件逻辑上是由三个高层对象组成：头对象（Header Object）、数据对象(Data Object)和索引对象(Index Object).。头对象是必需的并且必须放在每一个ASF文件的开头部分，数据对象也是必需的，且一般情况下紧跟在头对象之后。索引对象是可选的，但是一般推荐使用。

　       高层ASF文件结构

　 在具体实现过程中可能会出现一些文件包含无序的（Out-Of-Order）的对象，ASF也支持，但在特定情况下，将导致ASF 文件不能使用，如从特定的文件源如HTTP服务器读取该类ASF文件。同样地，额外的高层对象也可能被运用并加入到ASF文件中。一般推荐这些另加的对象跟在索引对象之后。

　 ASF数据对象能够被解释的一个前提条件是头对象已被客户机接收到。ASF没有声明头对象信息是如何到达客户端的，"到达机制"是一个"本地实现问题"，显然已超过了ASF 的定义范围。头对象先于数据对象到达有三种方式：
　 包含头对象的信息作为"会话声明"的一部分。
　 利用一个与数据对象不同的"通道"发送头对象。
　 在发送ASF 数据对象之前发送头对象。

ASF 头对象

　 在ASF的三个高层对象中，头对象是唯一包含其他ASF 对象的对象。头对象可能包含一下对象：
　 文件属性对象（File Properties Object）----全局文件属性。
　 流属性对象（Stream Properties Object）----定义一个媒体流和其属性。
　 内容描述对象（Content Description Object）----包含所有目录信息。
　 部件下载对象（Component Download Object）----提供播放部件信息。
　 流组织对象（Stream Groups Object）----逻辑上把多个媒体流组织在一起。
　 可伸缩对象（Scalable Object）----定义媒体流之间的可伸缩的关系。
　 优先级对象（Prioritization Object）----定义相关流的优先级。
　 相互排斥对象(Mutual Exclusion Object)----定义排斥关系如语言选择。
　 媒体相互依赖对象（Inter-Media Dependency Object）----定义混合媒体流之间的相互依赖关系。
级别对象（Rating Object）----根据W3C PICS定义文件的级别。
　 索引参数对象（Index Parameters Object）----提供必要的信息以重建ASF文件的索引。

                      ASF 头对象
　 头对象的作用是在ASF文件的开始部分提供一个众所周知的比特序列，并且包含所有其它头对象信息。头对象提供了存储在数据对象中的多媒体数据的全局的信息。
　 ASF数据对象
　 数据对象包含一个ASF 文件的所有多媒体数据。多媒体数据以ASF数据单元的形式存储，每一个ASF数据单元都是可变长的，且包含的数据必须是同一种媒体流。数据单元在当它们开始传输的时候在数据对象中自动地排序，这种排序来自于交叉存储的文件格式。
　 ASF索引对象
　 ASF索引对象包含一个嵌入ASF文件的多媒体数据的基于时间的索引。每以索引进入表现的时间间隔是在制作时设置的，并且存储在索引对象中。由于没有必要为一个文件的每一个媒体流建立一个索引，因此，通常利用一个时间间隔列表来索引一系列的媒体流。

数据类型

UINT8，UINT16，UINT32，UINT64-无符号整数的价值观，8，16，32或64位长。在GNUC编译器它们所代表的类型'unsigned char ’，'unsigned short ’，'unsigned long ’和'unsigned long long FILETIME-无符号的64位整数，100纳秒的倍数。
GUID的-128位的价值，可以产生在任何系统使用特殊的算法。该算法保证独特任何此类值（这意味着两个不同的计算机上，甚至在同一台计算机中不同时刻的时间不能产生相同的GUID）。

typedef struct tagBITMAPINFOHEADER
{
　DWORD biSize;
　LONG biWidth;
　LONG biHeight;
　WORD biPlanes;
　WORD biBitCount;
　DWORD biCompression;
　DWORD biSizeImage;
　LONG biXPelsPerMeter;
　LONG biYPelsPerMeter;
　DWORD biClrUsed;
　DWORD biClrImportant;
} BITMAPINFOHEADER;

biSize

指定结构体的大小，以字节为单位。

该大小不包含biClrUsed 成员中提到的颜色表或者屏蔽位的大小。

详细请参考Remarks 。

biWidth

指定位图的宽，以像素为单位。

biHeight

指定位图的高，以像素为单位。

如果biHeight 为正值，则该位图是一个自下而上的DIB，并且它从左下角开始。

如果biHeight 为负值，则该位图是一个自上而下的DIB，并且它从左上角开始。

如果biHeight 为负值，表明了一个自上而下的DIB，此时，biCompression 必须被设置为BI_RGB 或者 BI_BITFIELDS。自上而下的DIB不能被压缩。

biPlanes

指定目标设备平面层（plane）的个数。

该值必须被设置为1。

biBitCount

指定一个像素所占的位数。

BITMAPINFOHEADER 结构体的biBitCount 成员决定了一个像素占几个位，以及位图中包含的最大 的颜色数。

该成员只能包含一个如下的值：

Value	Description
1	说明该位图是一个黑白的，bmiColors 成 员包含两个条目。 在该位图中，每一位代表一个像素。 如果该位为0， 则该像素用bmiColors 表中的第一个条目中的颜色进行显示。 如果该位为1， 则该像素用bmiColors 表 中的第二个条目中的颜色进行显示。
2	位图可以有4种 颜色值。
4	位图最大可以有16种 颜色，bmiColors 成员包含16个条目。 位图中的每一个像素，由颜色表中的一个4位的索引进行表示。 例如，如果位图中的第一个字节为 0x1F，该字节表示两个像素。第一个像素 包含表中的第二个条目的颜色，第二个像素包含表中第16个条目的颜色。
8	位图最大可以有256种颜色，bmiColors 成 员包含256个条目。在这种情况下，数组中的每一个字节标示一个像素。
16	位图最大可以有2^16 种颜色。 如果BITMAPINFOHEADER 结构体的biCompression 成员为BI_RGB ，则bmiColors 成员NULL 。 该位图中，每一个字代表一个像素。红色，绿色和蓝色的相 对强度，由每个颜色组件的5个位 来表示。 对应蓝色的值，在最低的5个位，其后是分别对应绿色和红色的各5位。 最高的一位没有使用。bmiColors 颜色表用于优化基于调色板设备的颜色，并且必须包含BITMAPINFOHEADER 结 构体的biClrUsed 成员指定的条目的个数。
24	位图最大可以有2^24 种颜色，并且bmiColors 成 员为NULL。 位图数组中的每三个字节，表示一个像素中蓝色，绿色和红 色的相对强度。 bmiColors 颜色表用于优化基于调色板设备的颜色，并且必须包含BITMAPINFOHEADER结构体的biClrUsed 成员指定的条目的个数。
32	位图最大可以有2^32 种颜色。如果结构 体BITMAPINFOHEADER 的成员biCompression为BI_RGB ，则成员bmiColors 为NULL。位图数组中的一个DWORD 代表一个像素中蓝色，绿色和红色的相对强度。DWORD 中的最高一个字节没有使用。bmiColors 颜色表用于优化基于调色板设备的颜色，并且必须包含BITMAPINFOHEADER 结 构体的biClrUsed成员指定的条目的个数。 如果结构体BITMAPINFOHEADER 的成员biCompression 为 BI_BITFIELDS，成员bmiColors 包含三个DWORD 颜色掩码，分别用于指定一个像素中的红色，绿色和蓝色。 位图数组中的一个DWORD 代表一个像

你可以将上表中的任何一个值与BI_SRCPREROTATE 进行或，以指定源DIB部分与目标部分有相同的转角。

biCompression

指定一个压缩的自下而上的位图（自上而下的DIB不能被压缩）的压缩类型。该成员可以包 含一个如下的值：

Value	Description
BI_RGB	一个未压缩的格式。
BI_BITFIELDS	指定该位图没有被压缩，并且颜色表中包含三 个DWORD 颜色掩码，分别用于指定一个像素中的红色，绿色和蓝色。 该值对16- 和 32-bpp 位 图有效。 该值对WinCE 2.0及以后版本有效。
BI_ALPHABITFIELDS	指定该位图没有被压缩，并且颜色表中包含三 个DWORD 颜色掩码，分别用于指定一个像素中的红色，绿色，蓝色和alpha组件。 该值对16- 和 32-bpp 位 图有效。 该值对WinCE 4.0及以后版本有效。

。

biSizeImage

指定image的大小，以size为单位。

对于BI_RGB 位图，该值可以设置为0。

biXPelsPerMeter

以每米中包含的像素的个数为单位，指定目标设备中对于位图的水 平分辨率。

应用程序可以使用该值，从源组中 选择一个最佳匹配当前设备特性的位图。

biYPelsPerMeter

以每米中包含的像素的个数为单位，指定目标设备中对于位图的 垂直分辨率。

biClrUsed

指定颜色表中，位图真正使用的颜色索引的个数。

如果该值为0， 位图使用成员biCompression 指定的压缩模式需要的，与成员biBitCount 相应的最大的颜色数。

如果该值为非0， 并且成员biBitCount 小 于16， 成员biClrUsed 指定图像引擎或者设备驱动真正使用的颜色数。

如果成员biBitCount 大于16， 成员biClrUsed 指定用于优化系统调色板性能的颜色表的大小。

typedef struct
{
　WORD wFormatTag; //编码格式，包括WAVE_FORMAT_PCM，WAVEFORMAT_ADPCM等;
　WORD nChannels; //声道数，单声道为1，双声道为2;
　DWORD nSamplesPerSec; //采样频率；
　DWORD nAvgBytesPerSec; //每秒的数据量
　WORD nBlockAlign; //块对齐标志
　WORD  wBitsPerSample; //WAVE文件的采样大小
　WORD cbSize; //附加数据的大小,PCM中忽略此值
} WAVEFORMATEX;

wFormatTag

音频数据的编码方式。1表示是PCM 编码。

nChannels

声道数，单声道为1，双声道为2。

nSamplesPerSec

采样率(每秒样本数), 比如44100等。

nAvgBytesPerSec

音频数据传送速率, 单位是字节。其值为采样率×每次采样大小。播放软件利用此值可以估计缓冲区的大小。

nBlockAlign

每次采样的大小 = 采样精度*声道数/8(单位是字节); 这也是字节对齐的最小单位, 譬如 16bit 立体声在这里的值是 4 字节。播放软件需要一次处理多个该值大小的字节数据，以便将其值用于缓冲区的调整。

wBitsPerSample

每个声道的采样精度; 譬如16bit在这里的值就是16。如果有多个声道，则每个声道的采样精度大小都一样的。

cbSize

附加数据的大小。

所有的时间间隔不是衡量100纳秒和代表64位类型，或以毫秒为单位衡量和代表与32位或16-位类型（每个65.5秒）。

  
基本信息
ASF1.0文件格式由'块’。他们是块类似的AVI格式，而且大小各自领域的增加。
块：

Field	Type	Size (bytes)
Chunk type	GUID	16
Chunk length	UINT64	8
Data	-	Variable

块型描述的内容类型中的块。见下面的名单称为块类型的GUID。块长度相当于整个块（即长度的数据仅是一块长度减去24）。其他重要的概念是'包’。由于格式应该是流，所有的实际数据，如压缩音频或视频，是储存在'包’。不像的ASF2.0，所有的数据包有固定的大小。每一个有效的文件应至少包含两个块。它们是文件头块和数据块。文件头块包含了所有必要的资料，开始处理实际数据，而数据块包含的数据包。
头
1、头对象：

Field	Type	Size (bytes)
Chunk type	GUID	16
Chunk length	UINT64	8
Number of subchunks	UINT32	4
Unknown	-	2
Chunks	-	Variable

这一块是特殊的，因为它包含其他块中的数据字段。可能有任意数量的这种大块，但我们需要了解两种特殊类型。

2、文件对象：

Field	Type	Size (bytes)
Chunk type	GUID	16
Chunk length	UINT64	8
Client GUID	GUID	16
File size	UINT64	8
File creation time	FILETIME	8
Number of packets	UINT64	8
Timestamp of the end position	UINT64	8
Duration of the playback	UINT64	8
Timestamp of the start position	UINT32	4
Unknown, maybe reserved ( usually contains 0 )	UINT32	4
Flags ( usually contains 2 )	UINT32	4
Minimum size of packet, in bytes	UINT32	4
Maximum size of packet	UINT32	4
Size of uncompressed video frame	UINT32	4

0x02的flags意味着该文件可seek。最低与最高规模的数据包通常是一样的。这在不准确知道如何处理的ASF文件，假设它的值不是真的。

3、流对象：

Field	Type	Size (bytes)
Chunk type	GUID	16
Chunk length	UINT64	8
Stream type (audio/video)	GUID	16
Audio error concealment type	GUID	16
Unknown, maybe reserved ( usually contains 0 )	UINT64	8
Total size of type-specific data	UINT32	4
Size of stream-specific data	UINT32	4
Stream number	UINT16	2
Unknown	UINT32	4
Type-specific	-	Variable
Stream-specific	-	Variable

特定类型的具体数据只能从流类型得出含义。可随后领域，也取决于值的音频错误隐藏的类型。
第二个未知的值，这个目标似乎是绝对随机的，但如果有多个流在该文件中，他们都持有同样的值在这里。

4、视频流类型数据：

Field	Type	Size (bytes)
Picture width	UINT32	4
Picture height	UINT32	4
Unknown	UINT8	1
BITMAPINFOHEADER size	UINT32	4
Picture format	BITMAPINFOHEADER	Variable

对外输入ASF的图片格式，通常包含BITMAPINFOHEADER结构，它有40字节，但这并不是一个好方法，因为它可能含有一些较大的规模。

5、音频流类型数据：

Field	Type	Size (bytes)
Sound format	WAVEFORMATEX	14
Sound format extension	-	Variable

'Sound format extension'的大小等于WAVEFORMATEX结构中的cbSize。

6、音频流特定流数据：

Field	Type	Size (bytes)
H, Total number of audio blocks in each scramble group	UINT8	1
W, Byte size of each scrambling chunk	UINT16	2
Block_align_1, usually = nBlockAlign	UINT16	2
Block_align_2, usually = nBlockAlign	UINT16	2
Unknown	UINT8	1

这个数据是，如果目前只有'Audio error concealment type'领域中的主要结构包含相应的GUID。见节'Audio error concealment type'域的细节。
所有有效的ASF文件头包含一个头对象，以及每个流一个流对象。

数据块：

Field	Type	Size (bytes)
Chunk type	GUID	16
Chunk length	UINT64	8
Unknown	GUID	16
Number of packets	UINT64	8
Unknown	UINT8	1
Unknown	UINT8	1
Packets	-	variable

包
压缩视频和音频数据通常组织成'帧’或'对象’的一个任意大小。当一个人需要传输这种固定大小的一个数据包，这可能有三种情况：

一）帧的大小接近数据包的大小。这将是可以接受的，帧存放在一个包内。
二）帧大于该数据包的大小。然后，它需要分解成几个片段，并发出不同的数据包。
三）帧大大低于该数据包。在这种情况下，发送多帧在同一包内将是一个好主意。这就是所谓'组’。

可能有多种头格式，但大多数包以V82_Header起始：

Field	Type	Size (bytes)
0x82	UINT8	1
Always 0x0 (?)	UINT16	2
Flags	UINT8	1
Flags are bitwise OR of: 0x40 Explicit packet size specified 0x10 16-bit padding size specified 0x08 8-bit padding size specified 0x01 More than one segment
Segment type ID	UINT8	1
Packet size	UINT16	0 or 2 ( present if bit 0x40 is set in flags )
Padding size	Variable	0, 1 or 2 ( depends on flags )
Send time, milliseconds	UINT32	4
Duration, milliseconds	UINT16	2
Number of segments & segment properties	UINT8	0 or 1 ( depends on flags )

不知道‘Packet size’确切含义。它很少出现在ASF流中，当它出现，它会在这个数据包显示完整的数据长度（从一开始分组头的最后部分）。有时候是0x10与0x8的'或'，但我从来没有见过包指定非零填充数据与设定为0x40的flags。

段：

Field	Type	Size (bytes)
Stream ID	UINT8	1
Sequence number	UINT8	1
Segment-specific fields	-	Variable

最重要的位（0x80）是在流编号，如果部分包含一个关键帧。这里的东西成为一个稍微有点复杂。分段的具体领域取决于是否这一部分是分组（即包含一个以上的范围内），或没有。这可以推导出flags的价值，这是在部分特定的领域本身。

没有分组的特定段：

Field	Type	Size (bytes)
Fragment offset	UINT8, UINT16 or UINT32	Variable
Flags	UINT8	1
Object length	UINT32	4
Object start time, milliseconds	UINT32	4
Data length	UINT8 or UINT16	0, 1 or 2
Data	-	Variable

'Fragment offset'是指这一段中的对象（如视频帧）的偏移量。对于包中的完整的帧，'Fragment offset'为0且数据长度等于对象的长度。

“flags”可以是0x01或0x08。0x01的意思是“组（多个对象的段）”，以及0x08的意思是“没有分组（单个对象或段）”。

如果段是唯一的数据包，‘Data length’栏位是没有必要的，因为在这种情况下，数据需要所有剩余包（当然，考虑到填充）的空间。由包flags设置为0x01bit来指定。

'Fragment offset'字段大小是由包头值中'Segment Type ID'确定的。值0x55，0x59和0x5D，对应于1，2和4字节大小。

‘Data length’字段大小是由包头值中'Number of segments'确定的。'Number of segments'其较低的比特（大概是6）含有段的数目，设置位0x40意味着‘Data length’字段是1字节宽，并设置位0x80意味着‘Data length’字段是2字节宽。否则，‘Data length’字段的大小默认为2字节。

分组的特定段：

Field	Type	Size (bytes)
Object start time, milliseconds	UINT8, UINT16 or UINT32	Variable
Flags	UINT8	1
Unknown	UINT8	1
Data length	UINT16	0 or 2
Repeat until we run out of data length:
Object length	UINT8	1
Data	-	Variable
...

此结构类似于一个不分组段，但它不具备'Fragment offset'字段，因为复合和分组不能同时进行。

每一段有一个所谓'序列号’的字段。它可用于重装'分解'的对象。随后的对象序列号码相差1（会有较大的跳跃在'序列号’字段分组时发生）。不同段的同一个对象具有相同的序列号和同一个对象的开始时间。包通常是有组织的，以增加时间戳。目前尚不清楚，如果它总是如此。包可能丢失，这种情况应妥善处理。

原文是机器翻译：（

ASF1.0
ASF2.0