[流媒体]实例解析MMS流媒体协议,下载LiveMediaVideo[2]

[流媒体]按照MMS协议和MS Media Server交互

下载实时交通录像的包分析[2]

 

编写者

日期

关键词

郑昀@ultrapower

2005-10-17

mms streaming protocol 
ethereal 
协议分析 流媒体

 

       通过mms://220.194.63.17/cebeijing8,我们可以看到交通部门设置在北京西直门上的摄像头的实时录像,从而了解西直门的交通状况。

       但是,要是想下载这个流媒体到本地的话,我试验了asfr+ASF Recorder以及StreamBox vcr,均无法下载。又找了一个mimms-0.0.9linux版本,也就是以前的mmsclient,将其依赖于Linux的某些函数库换成Windows版本的对应包,编译之后,可以下载mms://220.194.63.17/cebeijing8的数据,但是用WindowsMediaPlayer9播放的时候,却报告错误无法播放,因为此文件已损坏

       只有SDP2.0(Streaming Download Project)可以正常下载并播放它。

为了改造mimms,我分析了SDP和流媒体服务器的来往包,看看我和他的实现到底存在哪些差异。如果你也开发流媒体下载应用,希望这个分析对你理解 Microsoft Windows Media Services”协议有帮助。

 

下面是第三个回合的数据包。我们对每一个“包头”和“包体”的每一个字节都做了尽可能详细的分析。

      

第三对包client to server 告知传输协议/IP地址/端口号

 第三回合之第1个包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

 

包头”解释:

l         01 00 00 00 ce fa 0b b0”是服务器端向客户端发包的“BOOB FACE”固定开头。以后你会看到每一个包都是如此开头的。8字节。

l         60 00 00 00”,表明在“协议类型(也就是接下来的4d 4d 53 20)”后面的所有数据的长度。4字节。

l         4d 4d 53 20”,表明协议类型,就是“MMS<space>”的ASCII码。4字节。

l         0c 00 00 00”,Length until end of packet in 8 byte boundary lengthsIncluding own data field4字节。

l         02 00 00 00”,Sequence number4字节。

l         00 00 00 00 00 00 00 00”,8字节。Double precision time stamp (see notes) used for network timing

l         0a 00 00 00”,Length until end of packet in 8 byte boundary lengths. Including own data field4字节。

l         02 00 03 00”, 指的是“Comm 2 bytes | Dir 2 bytes”。02 00Command数值。03 00Direction数值,这里的0x03指明客户端发往服务器。4字节。

 

在“Comm 2 bytes | Dir 2 bytes”之后,就是这个包的Body了。

“包体”解释:

l         f1 f0 f0 f0”,MMS协议标志24字节。

l         ff ff ff ff 00 00 00 00”,不知道。8字节。

l         00 00 a0 00”,不知道。4字节。

l         02 00 00 00”,固定数值,反映了Header PacketIDType4字节。

l         01 00 00 00 01 00 00 00 00 80 00 00”,固定数值,不知道含义。12字节。

l         5c 00 5c 00 31 00 39 00 32 00 2e 00 31 00 36 00 38 00 2e 00 31 00 2e 00 38 00 35 00 5c 00 54 00 43 00 50 00 5c 00 32 00 35 00 31 00 36 00”,其实就是“\\192.168.1.85\TCP\2516”的ASCII码。这是向服务器说明传输层协议类型TCP,客户端的IP地址192.168.1.85以及socket端口号2516

第三对包server to client 表示接受传输协议

 第三回合之第2个包to client;Len=96

0030                          01 00 00 00 ce fa 0b b0 50 00  ..@0..........P.

0040   00 00 4d 4d 53 20 0a 00 00 00 04 00 00 00 73 00  ..MMS ........s.

0050   70 00 3a 00 2f 00 08 00 00 00 02 00 04 00 00 00  p.:./...........

0060   00 00 f1 f0 f0 f0 08 00 00 00 46 00 75 00 6e 00  ..........F.u.n.

0070   6e 00 65 00 6c 00 20 00 4f 00 66 00 20 00 54 00  n.e.l. .O.f. .T.

0080   68 00 65 00 20 00 47 00 6f 00 64 00 73 00 00 00  h.e. .G.o.d.s...

0090   8a 94 b9 30 c2 c1                                ...0..

 

包头”解释:

l         01 00 00 00 ce fa 0b b0”是服务器端向客户端发包的“BOOB FACE”固定开头。以后你会看到每一个包都是如此开头的。8字节。

l         

l         02 00 04 00”, 指的是“Comm 2 bytes | Dir 2 bytes”。02 00Command数值。04 00Direction数值,这里的0x04指明服务器发往客户端。4字节。

 

在“02 00 04 00”之后,就是这个包的Body了。

“包体”解释:

l         00 00 00 00”,错误号。

l         f1 f0 f0 f0”,MMS协议标志24字节。

l         08 00 00 00”,4字节。数据的长度,有可能是假的。

l         46 00 75 00 6e 00 6e 00 65 00 6c 00 20 00 4f 00 66 00 20 00 54 00 68 00 65 00 20 00 47 00 6f 00 64 00 73 00”,其实就是“Funnel Of The Gods”的ASCII码。有时候也会是“Funnel Of The”。不知道为什么偏偏是这个上帝的漏斗,我们不妨假设服务器是想告诉我们传输协议被接受了。

郑昀编写,随时更新。

上一篇:多轮问答引擎


下一篇:C++设计模式3-适配器模式Adapter-不兼容结构的接口协调