[流媒体]实例解析MMS流媒体协议,下载LiveMediaVideo[1][修正版,增加了带宽测试包]

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



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



 


编写者


日期


关键词


郑昀@ultrapower


2005-10-17


mms streaming protocol ethereal 协议分析 流媒体

 

       通过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”协议有帮助。

 对了,编码格式是“Little Endian”,也就是0f 00 00 00的实际值是0x0f。

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

第一对包:client to server 告知Player版本号


 第一回合之第一个包:to server;Len=104:


0030                           01 00 00 00 ce fa 0b b0 58 00  ...a..........X.

0040   00 00 4d 4d 53 20 0b 00 00 00 00 00 00 00 00 00  ..MMS ..........

0050   00 00 00 00 00 00 09 00 00 00 01 00 03 00 f0 f0   ................

0060   f0 f0 0b 00 04 00 1c 00 03 00 4e 00 53 00 50 00   ..........N.S.P.

0070   6c 00 61 00 79 00 65 00 72 00 2f 00 37 00 2e 00   l.a.y.e.r./.7...

0080   31 00 2e 00 30 00 2e 00 31 00 39 00 35 00 36 00  1...0...1.9.5.6.

0090   3b 00 20 00 00 00 00 00 00 00 00 00 00 00        ;. ...........

 

 

包头”解释:

l         “01 00 00 00”是客户端向服务器端发包的固定开头。以后你会看到每一个包都是如此开头的。4字节。

l         “ce fa 0b b0”,这也是固定不变的。通常被人称为“BOOB FACE”。他可能是一个版本号或者序列号。以后你会看到客户端和服务器端发出的每一个包都是如此开头的。4字节。

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

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

l         “0b 00 00 00”,Length until end of packet in 8 byte boundary lengths,Including own data field。4字节。

l         “00 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         09 00 00 00”,Length until end of packet in 8 byte boundary lengths. Including own data field。4字节。

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

 

按照我的理解,上面的可以算作包头,每个客户端发出的数据包差不多都有类似的头。



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



“包体”解释:

l         “f0 f0 f0 f0”,MMS协议标志1。

l         “0b 00 04 00”,不知道。

l         “1c 00 03 00”,不知道。

l         “4e 00 53 00 50 00 6c 00 61 00 79 00 65 00 72 00 2f 00 37 00 2e 00 31 00 2e 00 30 00 2e 00 31 00 39 00 35 00 36 00 3b 00 20 00”,其实就是“NSPlayer/7.1.0.1956;<space>”的ASCII码。这是向服务器说明客户端的播放器的版本名。值得注意的是,这个版本名字必须以“NSPlayer”开头,否则MMS服务器将不管你的请求是什么,强制返回给客户端一个15秒的电影文件“Upgrade Your Player”,用来展示如何升级你的播放器。“NSPlayer”后面跟随的版本号无所谓是什么,比如mimms的是“9.0.0.2800”。

l         “00 00 00 00 00 00 00 00 00 00”,补零的部分。

 

       实际上,上面第一个包体应该是类似于这样的格式:

       NSPlayer/版本号;<space>{128位的客户端GUID};<space>Host:<space>服务器的IP地址

       举一个实际的例子:

NSPlayer/9.0.0.2800; {f5cec3a0-3e2c-11da-b2a2-00055d1a21bd}; Host: 220.194.63.17

       但是,抓SDP2.0得到的包有点不一样。

 

郑昀编写,随时更新。

第一对包:server to client 告知服务器版本号以及加密协议


 第一回合之第2个包:to client;Len=144:


0030                           01 00 00 00 ce fa 0b b0 80 00  ..p.............

0040   00 00 4d 4d 53 20 10 00 00 00 00 00 00 00 73 00  ..MMS ........s.

0050   70 00 3a 00 2f 00 0e 00 00 00 01 00 04 00 00 00   p.:./...........

0060   00 00 f0 f0 f0 f0 0b 00 04 00 1c 00 03 00 00 00   ................

0070   00 00 00 00 f0 3f 01 00 00 00 01 00 00 00 00 80   .....?..........

0080   00 00 80 96 98 00 0d 00 00 00 00 00 00 00 00 00  ................

0090   00 00 05 00 00 00 39 00 2e 00 30 00 31 00 2e 00  ......9...0.1...

00a0   30 00 31 00 2e 00 33 00 38 00 31 00 34 00 00 00  0.1...3.8.1.4...

00b0   4e 00 54 00 4c 00 4d 00 00 00 00 00 00 00 00 00  N.T.L.M.........

00c0   00 00 00 00 00 00                                ......

 

 

包头”解释:

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

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

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

l         “10 00 00 00”,Length until end of packet in 8 byte boundary lengths,Including own data field。4字节。

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

l         73 00 70 00 3a 00 2f 00”,8字节。Double precision time stamp (see notes) used for network timing。

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

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

 

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



“包体”解释:

l         “f0 f0 f0 f0”,MMS协议标志1。4字节。

l         “0b 00 04 00”,不知道。4字节。

l         “1c 00 03 00”,不知道。4字节。

l         “00 00 00 00 00 00 f0 3f”,固定数值,不知道含义。8字节。

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

l         “80 96 98 00”,有时候也会是“00 00 a0 00”, 8字节。

l         “39 00 2e 00 30 00 31 00 2e 00 30 00 31 00 2e 00 33 00 38 00 31 00 34 00”,其实就是“9.01.01.3814”的ASCII码。这是向客户端说明服务器端的版本号,“9.01.01.3814”看来是很新的Media Server版本。

l         “4e 00 54 00 4c 00 4d 00”,是“NTLM”的ASCII码。代表服务器的加密类型,诸如BASIC, DIGEST或者NTLM。

 

这个包中,在服务器版本号之后,加密类型之前,也可能有以下两种数据:

l         工具版本号,如5.1.0.0;

l         更新播放器的链接,如http://www.theupdatesite.com/updateplayer.html,微软有时候通过这个URL让你的客户端Windows Media Player更新最新的版本。

这两个数据不一定会有,但是服务器版本号必须要有。

 

郑昀编写,随时更新。

 

第二对包:client to server 请求“the timing test data method”


 第二回合之第1个包:to server;Len=48:


0030                         01 00 00 00 ce fa 0b b0 20 00  .o.6.......... .

0040   00 00 4d 4d 53 20 04 00 00 00 01 00 00 00 00 00  ..MMS ..........

0050   00 00 00 00 00 00 02 00 00 00 18 00 03 00 f1 f0  ................

0060   f0 f0 0b 00 04 00                                ......

 

包头”解释:

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

l         略

l         18 00 03 00”, 指的是“Comm 2 bytes | Dir 2 bytes”。18 00是Command数值。03 00是Direction数值,这里的0x03指明客户端发往服务器。4字节。是不是奇怪,怎么突然跳到了命令18。看来并不是按照命令顺序发送命令的。这个命令代表:“what timing tests to do, if any”。

 

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



“包体”解释:

l         “f1 f0 f0 f0”,表明“the TCP timing method is required”。4字节。

l         “0b 00 04 00”,不知道,4字节。

第二对包:server to client 网络带宽和数据速率测试包


 第二回合之第2个包:to client;Len=512:


0030                          01 00 00 00 ce fa 0b b0 f0 01  .g..............

0040   00 00 4d 4d 53 20 3e 00 00 00 01 00 00 00 73 00  ..MMS >.......s.

0050   70 00 3a 00 2f 00 3c 00 00 00 15 00 04 00 00 00  p.:./.<.........

0060   00 00 f1 f0 f0 f0 08 00 00 00 01 00 00 00 00 00  ................

0070   01 00 d4 b9 42 f1 00 00 00 00 01 00 00 00 00 00  ....B...........

0080   00 00 00 00 00 00 2d eb 9b 2d d2 fa e6 1c 09 12  ......-..-......

0090   b7 df ab 5e 07 71 a7 a0 a2 77 fe d1 ea db 9d 07  ...^.q...w......

00a0   ce 15 9c 80 bc d4 ae af 29 56 0e 44 77 b9 a8 c3  ........)V.Dw...

00b0   c1 1c 4d 4f 80 00 6c fd 06 6e b1 a8 0b 2e e1 25  ..MO..l..n.....%

00c0   21 15 2a fc e0 8e be 0f ae c4 8d c0 fb a7 df 5b  !.*............[

00d0   ca 77 58 7b 88 14 14 de 7d 68 13 d7 f9 ea 1b a8  .wX{....}h......

00e0   26 ea 3f 17 09 8f c9 26 01 0b 83 39 70 d3 e7 d0  &.?....&...9p...

00f0   6e e8 d5 75 76 e8 09 00 c1 91 2c 04 18 e1 6b a3  n..uv.....,...k.

0100   77 f3 1e 38 a0 39 fe 4a 7b e0 96 62 3d fa 33 e6  w..8.9.J{..b=.3.

0110   69 b3 89 90 06 71 eb 50 50 88 03 fb 2d b8 89 78  i....q.PP...-..x

0120   0b 7e 3f be fe 5f 7a da 88 de 9e 66 3e a6 a2 84  .~?.._z....f>...

0130   5f b9 6b 9a 5c 9b f2 eb ef 64 16 73 3b 6a ac a7  _.k.\....d.s;j..

0140   14 6f d2 20 17 5e 75 18 24 cd 49 22 69 c2 c9 b4  .o. .^u.$.I"i...

0150   50 25 76 32 ec 24 18 c9 9c bd 89 09 84 4a 28 c5  P%v2.$.......J(.

0160   d7 20 57 97 c7 ab 69 ee 89 7c e9 4c f3 ae 57 9d  . W...i..|.L..W.

0170   c1 22 bf 45 83 38 f0 eb 81 94 f8 ff ad 3f d7 fe  .".E.8.......?..

这个回应命令18的包属于命令15,可能有好几个,一般是两个512的包和一个1056的包,一般发送的假数据总字节数为1840字节。他是用来测试网络带宽,以及数据发送速率的。



这些包中的数据可能是随机数据,而且可能不做压缩。这样可以测出在一个非压缩的连接上所能达到的带宽。



 

包头”解释:

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

l         略

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

 

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



“包体”解释:

l         “00 00 00 00”,错误号。

l         “f1 f0 f0 f0”,标志,后面跟随的都是本次结构数据了。

l         “08 00 00 00”,表明本结构共8个字段,包括自己。

l         “01 00 00 00”;

l         “00 00 01 00”;

l         “d4 b9 42 f1”,分配你一个客户端ID。每登录一个客户端,这个ID自增加一,以方便服务器的UDP回复包知道向哪一个client发送。

l         “00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00”,接下来就是随机数据了。

l         随机数据。。。。

郑昀编写,随时更新。

时间: 2016-04-25

[流媒体]实例解析MMS流媒体协议,下载LiveMediaVideo[1][修正版,增加了带宽测试包]的相关文章

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

[流媒体]按照MMS协议和MS Media Server交互 下载实时交通录像的包分析[3]   编写者 日期 关键词 郑昀@ultrapower 2005-10-17 mms streaming protocol ethereal 协议分析 流媒体          通过mms://220.194.63.17/cebeijing8,我们可以看到交通部门设置在北京西直门上的摄像头的实时录像,从而了解西直门的交通状况.        但是,要是想下载这个流媒体到本地的话,我试验了asfr+.ASF

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

为了改造mimms,我分析了SDP和流媒体服务器的来往包,看看我和他的实现到底存在哪些差异.如果你也开发流媒体下载应用,希望这个分析对你理解 "Microsoft Windows Media Services"协议有帮助.   第五对包:client to server 请求header  第五回合之第1个包:to server;Len=88: 0030                      01 00 00 00 ce fa 0b b0 48 00  ..j...........

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

[流媒体]按照MMS协议和MS Media Server交互 下载实时交通录像的包分析[2]   编写者 日期 关键词 郑昀@ultrapower 2005-10-17 mms streaming protocol  ethereal 协议分析 流媒体          通过mms://220.194.63.17/cebeijing8,我们可以看到交通部门设置在北京西直门上的摄像头的实时录像,从而了解西直门的交通状况.        但是,要是想下载这个流媒体到本地的话,我试验了asfr+.AS

Rcmd.vbs 1.01修正版 增加了下载功能_vbs

这个down.vbs的用法看这里http://www.jb51.net/article/15506.htm 代码: 复制代码 代码如下: On Error Resume Next Set outstreem=Wscript.stdout If (LCase(Right(Wscript.fullname,11))="Wscript.exe") Then Wscript.Quit End If If Wscript.arguments.Count<4 Then Wscript.ech

求救 网站播放器 播放 mms://流媒体 的问题

问题描述 为什么系统安装了wmp11播放器!就不能播放mms://流媒体的文件了 解决方案 解决方案二:安个影音风暴的插件解决方案三:看看...解决方案四:MediaPlayer11已经放弃MMS流,微软的网站有说,如果你用VISTA那就看不了WAV格式的电视剧,我原来也查过这个问题,至今无法解决.解决方案五:现在我要做网站要播放的视频都是mms地址的这个问题必须解决呀要不然无法交差!各位大哥大姐救救小第呀解决方案六:限制版本必须装MediaPlayer11以下版本贝或者用其它播放器解决方案七:

实例解析IPv6环境下的网络编程

自IPv4诞生至今已有20多年了,目前它虽仍因互联网的成功而风光无限,但是如同"Internet正在成为其自身巨大成功的受害者"一样,目前IPv4地址的极度匮乏注定它将被历史所淘汰.而IPv6-IPv4的继承人,具有地址空间巨大,支持QOS等许多优良特性,在不久的将来会迅速的普及,但IPv6的出现将对目前网络编程方式产生一定的影响. 本文将就IPv6环境下的网络编程方式进行实例解析. 最终效果: 实例解析IPv6环境下的网络编程-配置篇 目前我们所用的IP协议是v4版本的, 比如192

Java Web开发入门书籍实例解析(总结一)_java

一.基本概念 1.1.WEB开发的相关知识 WEB,在英语中web即表示网页的意思,它用于表示Internet主机上供外界访问的资源. Internet上供外界访问的Web资源分为: 1.静态web资源(如html 页面):指web页面中供人们浏览的数据始终是不变. 2.动态web资源:指web页面中供人们浏览的数据是由程序产生的,不同时间点访问web页面看到的内容各不相同. 静态web资源开发技术:Html 常用动态web资源开发技术:JSP/Servlet.ASP.PHP等 在Java中,动

续实例解析SOCKET编程模型之异步通信篇(上)

编程|异步 .NET 框架的 Socket 类实际上是 Winsock32 API 提供的套接字服务的托管代码版本.其中Socket 类为网络通信提供了一套丰富的方法和属性,大多数情况下,Socket 类方法只是将数据封送到它们的本机Win32 副本中并处理任何必要的安全检查.Socket 类允许使用 ProtocolType 枚举中所列出的任何一种协议执行异步和同步数据传输.Socket 类遵循异步方法的 .NET Framework 命名模式:例如,同步 Receive 方法对应于异步 Be

springMVC4(10)强大类型转换器实例解析

在<springMVC4(9)属性编辑器剖析入参类型转换原理 >一文中,我们通过分析Sping内置的属性编辑器来理解springMVC是如何完成请求参数到入参的类型的转换的.而在新版本中,SpringMVC使用了新的架构来完成类型转换的工作,而且它的工作更加强大,支持格式化参数输入输出,它的另一个实例可见我的另一篇文章<springMVC4(4)json与对象互转实例解析请求响应数据转换器>.在文中,我们使用了Spring内置的格式转换器完成了服务端输入输出过程中json字符串与j