- 浏览: 4198457 次
最新评论
[流媒体]实例解析MMS流媒体协议,下载LiveMediaVideo[2][修正版本]
编写者 |
日期 |
关键词 |
郑昀@ultrapower |
2005-10-17 |
mms streaming protocol ethereal 协议分析 流媒体 |
为了改造mimms,我分析了SDP和流媒体服务器的来往包,看看我和他的实现到底存在哪些差异。如果你也开发流媒体下载应用,希望这个分析对你理解 “Microsoft Windows Media Services”协议有帮助。
下面是每一个数据包。我们对每一个“包头”和“包体”的每一个字节都做了尽可能详细的分析。
对了,编码格式是“Little Endian”,也就是0f 00 00 00的实际值是0x0f。
第三对包: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></space>”的ASCII码。4字节。
l “0c 00 00 00”,Length until end of packet in 8 byte boundary lengths,Including own data field。4字节。
l “02 00 00 00”,Sequence number。4字节。
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 field。4字节。
l “02 00 03 00”, 指的是“Comm 2 bytes | Dir 2 bytes”。02 00是Command数值。03 00是Direction数值,这里的0x03指明客户端发往服务器。4字节。
在“Comm 2 bytes | Dir 2 bytes”之后,就是这个包的Body了。
“包体”解释:
l “f1 f0 f0 f0”,MMS协议标志2。4字节。
l “ff ff ff ff 00 00 00 00”,不知道。8字节。
l “00 00 a0 00”,不知道。4字节。
l “02 00 00 00”,固定数值,反映了Header PacketIDType。4字节。
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 00是Command数值。04 00是Direction数值,这里的0x04指明服务器发往客户端。4字节。
在“02 00 04 00”之后,就是这个包的Body了。
“包体”解释:
l “00 00 00 00”,错误号。
l “f1 f0 f0 f0”,MMS协议标志2。4字节。
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”。不知道为什么偏偏是这个上帝的漏斗,我们不妨假设服务器是想告诉我们传输协议被接受了。
第四对包:client to server 告知媒体文件名
第四回合之第1个包:to server;Len=80: |
0030 01 00 00 00 ce fa 0b b0 40 00 ..............@. 0040 00 00 4d 4d 53 20 08 00 00 00 03 00 00 00 00 00 ..MMS .......... 0050 00 00 00 00 00 00 06 00 00 00 05 00 03 00 01 00 ................ 0060 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 63 00 ..............c. 0070 65 00 62 00 65 00 69 00 6a 00 69 00 6e 00 67 00 e.b.e.i.j.i.n.g. 0080 31 00 31 00 00 00 1.1...
|
“包头”解释:
l “01 00 00 00 ce fa 0b b0”是服务器端向客户端发包的“BOOB FACE”固定开头。以后你会看到每一个包都是如此开头的。8字节。
l 略
l “05 00 03 00”, 指的是“Comm 2 bytes | Dir 2 bytes”。05 00是Command数值。03 00是Direction数值,这里的0x03指明客户端发往服务器。4字节。
在“05 00 03 00”之后,就是这个包的Body了。
“包体”解释:
l “01 00 00 00”,Command Level。4字节。
l “ff ff ff ff”,MMS协议标志3。4字节。
l “00 00 00 00 00 00 00 00”,8个0。
l “63 00 65 00 62 00 65 00 69 00 6a 00 69 00 6e 00 67 00 31 00 31 00”,是“cebeijing11”的ASCII码。我们在告诉服务器要读取的文件路径以及文件名。不包括IP地址或者DNS信息,仅仅是文件路径和名字,比如“this/is/the/file/path/on/server/with/filename.ext”。
第四对包:server to client 告知流属性(广播标志/比特率)
第四回合之第2个包:to client;Len=152: |
0030 01 00 00 00 ce fa 0b b0 88 00 .........M...... 0040 00 00 4d 4d 53 20 11 00 00 00 05 00 00 00 00 00 ..MMS .......... 0050 00 00 00 00 00 00 0f 00 00 00 06 00 04 00 00 00 ................ 0060 00 00 01 00 00 00 01 00 00 00 00 00 00 00 00 00 ................ 0070 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 ................ 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0090 00 00 20 03 00 00 00 00 00 00 00 00 00 00 8e 10 .. ............. 00a0 01 00 16 09 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .............. |
“包头”解释:
l “01 00 00 00 ce fa 0b b0”是服务器端向客户端发包的“BOOB FACE”固定开头。以后你会看到每一个包都是如此开头的。8字节。
l 略
l “06 00 04 00”, 指的是“Comm 2 bytes | Dir 2 bytes”。06 00是Command数值。04 00是Direction数值,这里的0x04指明服务器发往客户端。4字节。
在“06 00 04 00”之后,就是这个包的Body了。
“包体”解释:
l “00 00 00 00”,错误号。
l “01 00 00 00”,后面跟随的都是本次结构数据了。
l “01 00 00 00”,结果标志,4字节。
l “00 00 00 00 00 00 00 00”;
l “00 00 00 02”,广播标志。
l “00 00 00 00 00 00 00 00”,双精度的文件时间点。8字节。
l “00 00 00 00”,代表total pre-recorded media length in seconds, live = 0。因为我们这个是一个实况录像,所以是00 00 00 00。
l “00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00”,16字节。
l “20 03 00 00”,用在media的包字节长度。4字节。0x0320也就是800个字节。
l “00 00 00 00”,代表total number of packets in media, live = 0xffffffff or 0x00。因为我们这个是一个实况录像,所以是00 00 00 00。
l “00 00 00 00”;
l “8e 10 01 00”,代表流比特率最高速度,0x0001108e就是Bitrate: 69774 bps。
l “16 09 00 00”,代表整个header的大小。0x0916代表2326字节。
l 之后是40字节的“00”。
前面第6个包中的“00 00 00 02”,广播标志,是什么意思呢?
对于“00 00”,指的是索引定位类型,有这么几个值:
n 0x00,没有索引可供定位。
n 0x80,有索引。
对于“00 02”,广播类型,有这么几个值:
n 0x01,指预录制的广播;
n 0x02,指实况广播,Live的。
n 0x42,包含了脚本命令的presentation。
第6个包中的“01 00 00 00”,结果标志,是什么意思呢?
l 0x01,媒体文件路径和名字被接受,没有身份验证。
l 0x02,BASIC验证媒体通过。
l 0x03,NTLM验证通过。
我们本次下载不需要验证,所以是0x01。
郑昀编写,随时更新。
第五对包:client to server 请求header
第五回合之第1个包:to server;Len=88: |
0030 01 00 00 00 ce fa 0b b0 48 00 ..j...........H. 0040 00 00 4d 4d 53 20 09 00 00 00 04 00 00 00 00 00 ..MMS .......... 0050 00 00 00 00 00 00 07 00 00 00 15 00 03 00 01 00 ................ 0060 00 00 00 00 00 00 00 00 00 00 00 80 00 00 ff ff ................ 0070 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0080 00 00 00 20 ac 40 02 00 00 00 00 00 00 00 ... .@........ |
“包头”解释:
l “01 00 00 00 ce fa 0b b0”是服务器端向客户端发包的“BOOB FACE”固定开头。以后你会看到每一个包都是如此开头的。8字节。
l 略
l “15 00 03 00”, 指的是“Comm 2 bytes | Dir 2 bytes”。15 00是Command数值,就是命令15。03 00是Direction数值,这里的0x03指明客户端发往服务器。4字节。
在“15 00 03 00”之后,就是这个包的Body了。
“包体”解释:
l “01 00 00 00”,Command Level。4字节。
l “00 00 00 00”,标志。4字节。之后就是数据结构了。
l “00 00 00 00”,4个0。
l “00 80 00 00”,说明连带自己共8个字段。
l “ff ff ff ff”,不知道。
l “00 00 00 00”,有可能是其他数值。
l “00 00 00 00 00 00 00 00”。
l “00 00 00 00 00 20 ac 40”,可能是媒体的什么毫秒数。
l “02 00 00 00”,Header Packet ID type,用在mms pre-headers。
第五对包:server to client 发送header
第五回合之第2个包:to client;Len=56: |
0030 01 00 00 00 ce fa 0b b0 28 00 .O:...........(. 0040 00 00 4d 4d 53 20 05 00 00 00 06 00 00 00 73 00 ..MMS ........s. 0050 70 00 3a 00 2f 00 03 00 00 00 11 00 04 00 00 00 p.:./........... 0060 00 00 02 00 00 00 00 00 00 00 46 00 75 00 ..........F.u. |
“包头”解释:
l “01 00 00 00 ce fa 0b b0”是服务器端向客户端发包的“BOOB FACE”固定开头。以后你会看到每一个包都是如此开头的。8字节。
l 略
l “11 00 04 00”, 指的是“Comm 2 bytes | Dir 2 bytes”。11 00是Command数值。04 00是Direction数值,这里的0x04指明服务器发往客户端。4字节。
在“11 00 04 00”之后,就是这个包的Body了。
“包体”解释:
l “00 00 00 00”,错误号。
l “02 00 00 00”,上一个包传过来的Header Packet ID Type。
l “00 00 00 00”。
l “46 00 75 00”,也许会是00 00 00 00,不知道何用。
第六回合包:server to client 发送asf真实数据
第六回合之第1个包:to client;Len=800: |
0030 00 00 00 00 02 04 20 03 30 26 .O'......... .0& 0040 b2 75 8e 66 cf 11 a6 d9 00 aa 00 62 ce 6c e4 08 .u.f.......b.l.. 0050 00 00 00 00 00 00 06 00 00 00 01 02 ce 75 f8 7b .............u.{ 0060 8d 46 d1 11 8d 82 00 60 97 c9 a2 b2 20 00 00 00 .F.....`.... ... 0070 00 00 00 00 01 00 01 00 8e 10 01 00 a1 dc ab 8c ................ 0080 47 a9 cf 11 8e e4 00 c0 0c 20 53 65 68 00 00 00 G........ Seh... 0090 00 00 00 00 1b 8c fa 8c 59 c8 16 4b 85 2f ac 87 ........Y..K./.. 00a0 f4 b8 59 bd 16 09 00 00 00 00 00 00 70 4f ab 48 ..Y.........pO.H 00b0 1e d0 c5 01 ff ff ff ff 00 00 00 00 00 00 00 00 ................ 00c0 00 00 00 00 00 00 00 00 00 00 00 00 88 13 00 00 ................ 00d0 00 00 00 00 09 00 00 00 20 03 00 00 20 03 00 00 ........ ... ... 00e0 8e 10 01 00 b5 03 bf 5f 2e a9 cf 11 8e e3 00 c0 ......._........ 00f0 0c 20 53 65 b1 06 00 00 00 00 00 00 11 d2 d3 ab . Se............ 0100 ba a9 cf 11 8e e6 00 c0 0c 20 53 65 06 00 83 06 ......... Se.... 0110 00 00 a9 46 43 7c e0 ef fc 4b b2 29 39 3e de 41 ...FC|...K.)9>.A 0120 5c 85 27 00 00 00 00 00 00 00 01 00 0c 7a 00 68 /.'..........z.h 0130 00 2d 00 63 00 6e 00 00 00 cb a5 e6 14 72 c6 32 .-.c.n.......r.2 0140 43 83 99 a9 69 52 06 5b 5a 58 00 00 00 00 00 00 C...iR.[ZX...... 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0160 00 00 fa 00 00 88 13 00 00 00 00 00 00 00 fa 00 ................ 0170 00 88 13 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0180 00 01 00 00 00 2a 2c 0a 00 00 00 00 00 00 00 00 .....*,......... 0190 00 5d 8b f1 26 84 45 ec 47 9f 5f 0e 65 1f 04 52 .]..&.E.G._.e..R 01a0 c9 1a 00 00 00 00 00 00 00 02 01 ea cb f8 c5 af ................ 01b0 5b 77 48 84 67 aa 8c 44 fa 4c ca 80 00 00 00 00 [wH.g..D.L...... 01c0 00 00 00 02 00 00 00 01 00 0c 00 02 00 02 00 00 ................ 01d0 00 49 00 73 00 56 00 42 00 52 00 00 00 00 00 00 .I.s.V.B.R...... 01e0 00 01 00 34 00 00 00 0c 00 00 00 44 00 65 00 76 ...4.......D.e.v 01f0 00 69 00 63 00 65 00 43 00 6f 00 6e 00 66 00 6f .i.c.e.C.o.n.f.o 0200 00 72 00 6d 00 61 00 6e 00 63 00 65 00 54 00 65 .r.m.a.n.c.e.T.e 0210 00 6d 00 70 00 6c 00 61 00 74 00 65 00 00 00 4d .m.p.l.a.t.e...M 0220 00 50 00 40 00 4c 00 4c 00 00 00 74 d4 06 18 df .P.@.L.L...t.... 0230 ca 09 45 a4 ba 9a ab cb 96 aa e8 6a 05 00 00 00 ..E........j.... 0240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
“包头”解释:
l “01 00 00 00 ce fa 0b b0”是服务器端向客户端发包的“BOOB FACE”固定开头。以后你会看到每一个包都是如此开头的。8字节。
l “30 26 b2 75 8e 66 cf 11 a6 d9 00 aa 00 62 ce 6c”,不管什么时候,我们在ASF数据流中看到这样的GUID,就知道后面跟的是一个header了。你打开一个本地的asf文件,也会看到这样的GUID。我们称之为“header chunk object”。他很像是一种header标记,表明某类型的数据。
l 略
l “a1 dc ab 8c 47 a9 cf 11 8e e4 00 c0 0c 20 53 65”, 指的是“File Header Object”,这个重要的object包含了文件属性和包。
.
相关推荐
对报文进行解析及分析,对每一包发送内容进行详细分析,server to client 告知流属性等。
C语言高级实例解析C语言高级实例解析C语言高级实例解析C语言高级实例解析
META分析软件应用与实例解析,有实例解析,通俗易懂
内容由流媒体协议等基本知识,视频媒体基本知识,流媒体服务器搭建实战,流媒体工具使用实战等内容组成。由本人“天地会珠海分舵”(http://blog.csdn.net/zhubaitian)耗时一个月整理而成,现分享给大家。 章节内容...
开关电源设计入门与实例解析 张占松.pdf,开关电源相关的工具书
关于汽车总线数据14229协议,UDS协议实车实例解析及详细说明。
LINUX编程典型实例解析涉及到Linux的基础知识,c c++ qt开发等。适合Linux开发人员使用。 第一部分: LINUX编程典型实例解析.part1.rar http://download.csdn.net/detail/lu_2012_01kk/9378452
通过串口调试助手写入30 30 30 32 31 59 30等数据实现对PLC地址的读写操作。文档包含目录共计18页,可以根据配置直接...包含单个/多个读写输入输出点、单个/多个读写寄存器、改变PLC状态,可以大大缩短协议的熟悉周期。
本文对于DLMS协议的IEC62056协议族,即DLMS协议族的中文说明手册。本文并没有包含DLMS协议族的全部,但解释了在应用中可能出现的大多数情况。本文的目的是为电能量数据采集终端提供与使用DLMS协议族的电能表通讯的...
《C语言高级实例解析》本书特点: ·以实例为主。本书采用实例讲解的方式,先介绍必要背景知识,之后是加注释的源码,再给出分析和改进方向。 ·涉及的知识面广。从内存分配,到串行、并行口编程,再到...
流媒体有多种形式,例如rtmp,rtsp,mms等。但是rtmp是不支持高清的饿,只有rtsp才是支持播放高清视频的。。
实例解析mms协议,网上找到的,可以参考一下
海康流媒体SDK开发实例,支持VS2010,这个版本使用了负载均衡ACE模块开发.
考虑到更多层次读者的需求,全书内容力求语言通俗易懂,知识系统,内容实例充足,不仅适合初中级用户,同时作为高级用户的流媒体参考书籍,也可作为研究网络多媒体技术、数字媒体技术、流媒体技术等学科的工作者,...
Java使用SOAP获取webservice实例解析 具体实例分析说明。
104协议分析的防守打法 协议分析104协议分析104协议分析104协议分析
介绍p2p流媒体原理,提供初学者的开发实例。
ARP协议深入解析实例笔记,搞网络的必看
VC 6 RTP流媒体传输协议编程实例(jrtplib),在网上找的,很好,介绍给各位.
ANSYS 8.0热分析教程与实例解析PDF版