通过 mms://220.194.63.17/cebeijing8，我们可以看到交通部门设置在北京西直门
上的摄像头的实时录像，从而了解西直门的交通状况。
但是，要是想下载这个流媒体到本地的话，我试验了 asfr+、ASF Recorder
以及 StreamBox vcr，均无法下载。又找了一个 mimms-0.0.9 的 linux 版本，也
就是以前的 mmsclient，将其依赖于 Linux 的某些函数库换成 Windows 版本的
对应包，编译之后，可以下载 mms://220.194.63.17/cebeijing8 的数据，但是用
WindowsMediaPlayer9 播放的时候，却报告错误“无法播放，因为此文件已损
坏”。
只有 SDP2.0(Streaming Download Project)可以正常下载并播放它。
为了改造 mimms，我分析了 SDP 和流媒体服务器的来往包，看看我和他的
实现到底存在哪些差异。如果你也开发流媒体下载应用，希望这个分析对你理解
“Microsoft Windows Media Services”协议有帮助。
下面是从第 3 到第 6 个数据包。我们对每一个“包头”和“包体”的每一个
字节都做了尽可能详细的分析。
对了，编码格式是“Little Endian”，也就是 0f 00 00 00 的实际值是 0x0f。
第 3 个包：client to server
第 3 个包：to server;Len=112：
0030 01 00 00 00 ce fa 0b b0 60 00 ..............`.
0040 00 00 4d 4d 53 20 0c 00 00 00 02 00 00 00 00 00 ..MMS ..........
0050 00 00 00 00 00 00 0a 00 00 00 02 00 03 00 f1 f0 ................
0060 f0 f0 ff ff ff ff 00 00 00 00 00 00 a0 00 02 00 ................
0070 00 00 5c 00 5c 00 31 00 39 00 32 00 2e 00 31 00 ..\.\.1.9.2...1.
0080 36 00 38 00 2e 00 31 00 2e 00 38 00 35 00 5c 00 6.8...1...8.5.\.
0090 54 00 43 00 50 00 5c 00 32 00 35 00 31 00 36 00 T.C.P.\.2.5.1.6.
00a0 00 00 00 00 00 00
“包头”解释：
“01 00 00 00 ce fa 0b b0”是服务器端向客户端发包的“BOOB
FACE”固定开头。以后你会看到每一个包都是如此开头的。8 字节。
“60 00 00 00”，表明在“协议类型(也就是接下来的 4d 4d 53 20)”
后面的所有数据的长度。4 字节。
“4d 4d 53 20”，表明协议类型，就是“MMS<space>”的 ASCII
码。4 字节。
“0c 00 00 00”，Length until end of packet in 8 byte boundary
lengths，Including own data field。4 字节。
“02 00 00 00”，Sequence number。4 字节。
