RM/RMVB文件格式总结

RM文件格式是标准的标记符文件格式，RM文件格式把标记符块组合成头块，数据快，索引块，这些标记符块的组合方法如下：
.RMF头块
RealMedia File Header(RM 文件头)

PROP属性头
Properties（属性头）

MDPR媒体属性头
（可含多个）
Media Properties（媒体属性头1）


Media Properties（媒体属性头2）


------（其他媒体属性头3—n）

CONT内容描述头
Content Properties（内容描述头）

DATA数据段（可含多个）
Data Chunk Header（数据块头）


Data Packets（数据包）


------（其他数据包）


Data Chunk Header（数据块头）


Data Packets（数据包）


------（其他数据包）


---------（其他数据段）

INDX索引段（可含多个）
Index Section（索引段）


------（其他索引段）

    RM文件格式是标记符文件格式，所以块的先后次序并不确定，只有RM文件头必须是文件的第一个块。典型的RM格式文件的头段：RM文件头（必须是文件的第一块）、属性头、媒体属性头、内容描述头。在RM文件头后面，其他的头可以按任何次序出现，除了索引头以外，其他的头都必须要。

RM/RMVB 文件格式-.RMF(文件头)
每一个RM文件都以RM文件头开始，RM文件头标识文件是RMF类型，在RM文件中只有一种RM文件头,因为RM文件头的内容可能随着RMF的版本不同而改变，所以头结构里面有个版本域来指明有什么其他的额外域存在。下面的数据结构就是RM文件头的数据存储方式：
RealMedia_File_Header
{
       UINT32 object_id;
       UINT32 size;
       UINT16 object_version;
       if((object_version= =0)||(object_version= =1))
       {
              UINT32 file_version;
              UINT32 num_headers;
       }
}
结构中包含有如下成员：
object_id，RM文件的唯一标识(“.RMF”)，所有的RM文件都以这个标识开头，用32个二进制位表示；
size，RM头段的大小，用32个二进制位表示；//上述结构体中五个元素都含有时，为18字节
object_version，RM文件头的版本，决定结构中其他成员的取舍，用16个二进制位表示；
file_version，RM文件的版本，用32个二进制位表示；
num_headers，头段中RM文件头后面的包含的头的个数，用32个二进制位表示。注：num_headers具体指那些头的个数不明，有文件该值为7，但仅包含1个PROP，3个MPPR，1个CONT，如果算上.RMF共6个；另外有文件该值为7，包含有1个PROP，3个MPPR，1个CONT，如果算上.RMF共6个，如果算上INDX（3个）则总数是9个。
如图:

RM/RMVB 文件格式-PROP(属性头)
属性头  PROP
属性头描述了RM文件的一般媒体属性，RM系统的组件根据属性头进行适当的配置来处理RM文件或RM流中数据。在RM文件中只有一个属性头，下面的数据结构就是属性头的数据存储方式：
Properties
{
       UINT32 object_id; [0-3]
       UINT32 size;[4-7]
       UINT16 object_version;[8-9]
       if(object_version==0)
       {
              UINT32 max_bit_rate;[10 - 13]
              UINT32 avg_bit_rate;[14 - 17]
              UINT32 max_packet_size;[18 - 21]
              UINT32 avg_packet_size;[22 - 25]
              UINT32 num_packets;[26 - 29]
              UINT32 duration;[30 - 33]
              UINT32 preroll; [34 - 37]
              UINT32 index_offset; [38 - 41]
              UINT32 data_offset; [42 - 45]
              UINT16 num_streams; [46 - 47]
              UINT16 flags; [48 - 49]
       }
}
结构中包含有如下成员：
object_id，属性头唯一标识 （“PROP”）,用32个二进制位表示；
size,属性头大小,用32个二进制位表示；10+40字节
object_version，RM文件头版本，决定结构中其他成员的取舍，此结构中此值为零，用16个二进制位表示；
max_bit_rate，网络传输时要求的最大比特率，用32个二进制位表示；
avg_bit_rate，网络传输时要求的平均比特率，用32个二进制位表示；
max_packet_size，最大媒体数据包的大小（以字节计算），用32个二进制位表示；
avg_packet_size，平均媒体数据包的大小（以字节计算），用32个二进制位表示；
num_packets，媒体数据包个数，用32个二进制位表示；
duration，媒体文件应该播放的时间（以毫秒计算），用32个二进制位表示；
preroll，回放之前的预留毫秒数，用32个二进制位表示；
index_offset，索引头到文件开始的偏移，这个值可为零，表明没有索引段，用32个二进制位表示；
data_offset，数据段到文件开始的偏移，用32个二进制位表示（注:在RM文件中可以有不止一个数据块头，这个值只表示第一个数据块头到文件开始的偏移，其他数据块头的偏移可以从数据块头中next_data_header域得到）；
num_streams，在主头段中包含的全部媒体属性头（MDPR）的个数，用16个二进制位表示；
flags，包含文件信息的位掩码，用16个二进制位表示。具体信息如下表，其它位应设置为零。//flags，文件中flag出现过如下值：0009，000b 所以下述位掩码显然不完全。文件信息的位掩码表：
位
标志
描述
0
保存允许
如果是1，就允许保存此文件到磁盘
1
最佳播放
如果是1， 建议使用额外的缓存
2
实况
如果是1， 表明媒体流来自实况广播
图例:


RM/RMVB 文件格式-MDPR(媒体属性头)
媒体属性头描述了RM文件中每个媒体流的特定属性，RM系统的组件根据媒体属性头进行适当的配置来处理RM流中的媒体数据，RM文件中每一个媒体流有一个媒体属性头。
媒体属性头的整体组成
下面的数据结构就是媒体属性头的数据存储方式：
Media_Properties
{
       UINT32 object_id;[0 - 3]
       UINT32 size;[4 - 7]
       UINT16 object_version;[8 - 9]
       if(object_version==0)
       {
              UINT16 stream_number; [10 - 11]
              UINT32 max_bit_rate; [12 - 15]
              UINT32 avg_bit_rate; [16 - 19]
              UINT32 max_packet_size;[20 - 23]
              UINT32 avg_packet_size;[24 - 27]
              UINT32 start_time;[28 - 31]
              UINT32 preroll; [32 - 35]
              UINT32 duration; [36 -39]
              UINT8  stream_name_size;[40 - 40]
              UINT8[stream_name_size]  stream_name;[41 - 41]
              UINT8 mime_type_size;[42 - 42]
              UINT8[mime_type_size]   mime_type;[43 - 43]
//决定Type_Specific_Data
              UINT32 type_specific_len;[44 - 47]
              UINT8[type_specific_len]   Type_Specific_Data;[48 - 51]
//详细说明见后文
       }
}
媒体属性头结构中包含有如下这些成员：
object_id:媒体属性头唯一标识，为“MDPR”；
size，表明媒体属性头的大小；
object_version，媒体属性头版本号；
stream_number，流的标识，表明RM媒体文件中此媒体属性头代表的是哪个数据流（视频数据流或音频数据流），在数据段中的每个数据包中都包含有类似的标识以表明数据是属于哪个媒体流。当版本号为零时此成员才存在；
max_bit_rate，网络上传输此媒体流所要求的最大比特率，当版本号为零时此成员才存在；
avg_bit_rate，网络上传输此媒体流所要求的平均比特率，当版本号为零时此成员才存在；
max_packet_size，媒体流数据包的最大容量（以字节计算），当版本号为零时此成员才存在；
avg_packet_size，媒体流数据包的平均容量（以字节计算），当版本号为零时此成员才存在；
start_time，开始时间（毫秒表示），用于加到数据包时间标志上，当版本号为零时此成员才存在；
preroll，和start_time相反的时间尺度（毫秒表示），用于从数据包时间标志中减去的值，当版本号为零时此成员才存在；
duration，流的持续时间，当版本号为零时此成员才存在；
stream_name_size，流名称所占字节数，当版本号为零时此成员才存在，用8个二进制位表示；
stream_name，流的名称，版本号为零时此成员才存在，大小不定；
mime_type_size，表明下个成员（mime_type）所占的存储空间，版本号为零时此成员才存在，用8个二进制位表示；
mime_type，和流相关的MIME形式的类型或子类型字符串，版本号为零时此成员才存在，大小不定；mime_type：1、audio/x-pn-realaudio；2、video/x-pn-realvideo；3、logical-fileinfo
type_specific_len，表明下个成员(pe_specific_data）所占的存储空间，版本号为零时此成员才存在，；
Type_Specific_Data，一般用来保存对流进行处理的特殊数据，版本号为零时此成员才存在，大小不定。
图示1:


RealMedia-rmff
    Multimedia container format developed by Real and used almost exclusively for codecs developed by Real. The old .ra files are just for audio. The newer RealMedia (.rm) files are for audio and video.
RA Format
    This is the old audio-only RealAudio file format. A very similar structure is also used to describe audio streams in RM files. The audio data part is just a stream of bytes with no structure. There is no index in .ra files, but seeking is possible because the codecs are CBR.
RealAudio 1.0 file (.ra version 3)
    This is from the very first version of RealAudio (1995). These files can only contain 8kbps VSELP audio data. A FourCC (lpcJ) may be present, but it is ignored. Byte order is big-endian.
byte[4]  Header signature ('.', 'r', 'a', 0xfd)
word     Version (always 3)
word     Header size, not including first 8 bytes
byte[10] Unknown
dword    Data size
byte     Title string length
byte[]   Title string
byte     Author string length
byte[]   Author string
byte     Copyright string length
byte[]   Copyright string
byte     Comment string length
byte[]   Comment string
byte     Unknown *
byte     Fourcc string length (always 4) *
byte[]   Fourcc string (always "lpcJ") *
 Audio data
Notes:
Fields marked with * may be missing. Based on the only known sample with no FourCC, it's assumed that all these fields are either present or missing. To determine if they are missing, check the header size (bytes 6-7).
The informative fields (title, author, copyright and comment) can have zero length.
RealAudio 2.0 file (.ra version 4)
    This is second version of the RealAudio file format. It is distinguished from the above by the value in byte 5 (=0x04). This type of file must contain a valid FourCC to identify the audio codec.
Possible FourCC values are 28_8, dnet and sipr.
byte[4]  Header signature ('.', 'r', 'a', 0xfd)
word     Version (always 4)
word     Unused (always 0)
byte[4]  ra4 signature (always ".ra4")
dword    Data size - 0x27
word     Version2 (always equal to version)
dword    Header size - 16
word     Codec flavor
dword    Coded frame size
byte[12] Unknown
word     Sub packet h
word     Frame size
word     Subpacket size
word     Unknown
word     Samplerate
word     Unknown
word     Sample size
word     Channels
byte     Interleaver ID string length (always 4)
byte[]   Interleaver ID string
byte     FourCC string length (always 4)
byte[]   FourCC string
byte[3]  Unknown
byte     Title string length
byte[]   Title string
byte     Author string length
byte[]   Author string
byte     Copyright string length
byte[]   Copyright string
byte     Comment string length
byte[]   Comment string
 Audio Data
Notes:
The 0x27 in data size is the size of the fixed-length part of the header (up to channels).
The informative fields (title, author, copyright and comment) can have zero length.
.ra version 5
    While the .ra header can contain version 5, there are no known RealAudio files with this format, and it's not known if they really exist.
RealMedia Format
    This is the newer format which stores both audio and video. All multi-byte numbers are stored in big-endian format. A RealMedia file consists of a series of chunks. Each chunk has the following format:
dword  chunk type (FOURCC)
dword  chunk size, including 8-byte preamble
word   chunk version
byte[] chunk payload
Real chunk types:
.RMF: RealMedia file header (only one per file, must be the first chunk)
PROP: File properties (only one per file)
MDPR: Stream properties (one for each stream)
CONT: Content description/metadata (typically one per file)
DATA: File data
INDX: File index (typically one per stream)
RealMedia file header (.RMF)
    This must be the first chunk in a RealMedia file. Only one .RMF can be present in a file. The only useful information carried by .RMF is the number of headers. A .RMF chunk has the following format
dword chunk type ('.RMF')
dword chunk size (typically 0x12)
word  chunk version (always 0, for every known file)
dword file version
dword number of headers
Notes:
All known sample files have version equal to 0.
There is a sample with chunk size = 0x10, in that case file version is a word. Note that the sample has chunk version = 0 like all other files.
File properties header (PROP)
    This chunk contains some information about the general properties of a RealMedia file. Only one PROP chunk can be present in a file. A PROP chunk has the following format
dword  Chunk type ('PROP')
dword  Chunk size (typically 0x32)
word   Chunk version (always 0, for every known file)
dword  Maximum bit rate
dword  Average bit rate
dword  Size of largest data packet
dword  Average size of data packet
dword  Number of data packets in the file