|
现在网上有很多可以点播的视频节目，大部分是MMS流媒体格式的，文件后缀一般 是 WMV 或者ASF。虽然可以直接用 Windows Media Player 9 播放，但是经常会被一次又一次的“正在缓冲”打断，再好的影片也没耐心了。如果能像其他类型的资源，下载到硬盘上观看就方便多了。下面详细介绍具体原理和 实现步骤。这里以WMV格式为例，其实ASF也是一样的，只不过它的图像品质更高些。 第一步，客户端发送0x01命令包，发动连接请求。服务器经检查无误后，返回一个新的0x01命令包作为应答； 第二步，客户端发送0x18命令包，请求测试网络带宽情况。服务器收到后，发送3个随机数据包作为应答，总长度一般为2080字节； 第三步，客户端发送0x02命令包，告知自己的IP地址和端口号。服务器确认后，返回新的0x02命令包作为应答，其中包含了一串英文来表示接受，翻译过来就是“上帝的漏斗”； 第四步，客户端发送0x05命令包，请求所需文件的名字和路径。服务器收到后，返回0x06命令包作为应答，告知一些流媒体的属性，比如：录制类型，最高比特率等； 第五步，客户端发送0x15命令包，请求文件头。服务器会返回0x11命令包，其中包含了文件头的内容，可以从中解析出头部长度，总包数，包长度等 信息，这一步最复杂，数据可能会被拆分成多个部分发送过来。现在双方的联系就算正式建立了，可以开始下载真实数据。这时客户端发送0x07命令包请求数 据，可以全部下载，也可以指定从哪个数据包开始下载，为将来设计断点续传提供了方便。服务器收到后，返回0x21和0x05命令包作为应答，然后把数据流 打碎，一截一截地发送过来，每隔一段时间还会发送0x1B命令包作为同步消息，客户端也回送0x1B命令包作为应答。因为每次传过来的数据量长度是不确定 的，所以要通过判断报头标记，组装成完整的数据包后，再写入文件就可以了。 0－3 字节：固定为1 4－7 字节：固定为0xB00BFACE，就是英文单词 bOOb face（鲍勃的脸） 8－11 字节：协议类型后面数据的长度 12－15 字节：协议类型，就是MMS和空格的ASCII码 16－19 字节：对齐边界 20－23 字节：命令包计数 24－31 字节：双精度时间 32－35 字节：对齐边界 36－39 字节：本命令代号，固定为0x00030001，后两个字节的3表示传输方向是从客户端到服务器。 到这里包头的定义就结束了，以后其他命令包的包头也是基本相同的，不同的只是包体和附加数据。下面来看0x01命令包的包体数据： 40－43 字节：MMS协议标志，此处为0xF0F0F0F0 44－47 字节：固定为0x0004000B，意义未知 48－结束：以 UNICODE 格式编码的播放器版本 第二步发送0x18命令包很简单，没有附加数据，包体是两个双字，固定为 0xF0F0F0F1 值和 0x0004000B 值，可参考所附例程。 第三步发送0x02命令包，需要构造一个由IP地址与端口号组成的字符串，一般使用 getsockname 得到所需的内容。另外还要在末尾补零以达到边界对齐。若嫌麻烦，这里也可以随便写，比如IP地址定义为：192.168.66.88 ，端口号定义为：7799。笔者试验过，对后面的通信过程没有影响。 第四步发送0x05命令包，附加数据是UNICODE编码的文件全路径名，其中包含要下载的媒体文件名。包体是四个固定值，分别为：1，0xFFFFFFFF，0，0。 第五步发送0x15命令包，包体是12个固定的双字值，具体可参考所附代码。发送过程还和往常一样，这里主要强调一下接收过程，如何从这些二进制数 据里提取需要的信息。首先注意到任何一个流媒体文件头的结尾，都是一个UINT64值，即 0x0101000000000000，可以利用这个特征先得到整个文件头。 第六步发送0x07命令包，这里有一点需要解释。包体的第六个双字，用它来指定本次下载的位置。如果是从头开始，可以定义为0或0xFFFFFFFF。如果是断点续传，指定包编号即可。 ps:http://nchc.dl.sourceforge.net/project/libmms/libmms/0.6/libmms-0.6.tar.gz 这个库就可以满足一切需求。当然windows和wince需要自己修改。经过测试，修改成select模式，下载非常稳定。如果需要，可以廉价出售。穷人嘛。 (cr0_3) |