rtmp_specification_1.0.pdf 这协议分为两层: 下层是传输层, 即所谓的Chunk协议,定义了复用和解复用的方法。上层上应用层,即Message的协议,定义了各种消息的格式。主要的消息有Command, MetaData, VideoData, Audio Data这几种。具体就不多说了,我主要解释该文档的错误之处、难点和遗漏的地方,读者应该自己熟读官方文档。 首先,相对于ISO, IEEE, RFC这些标准文档来说,RTMP的这篇文档只能算是二流的协议,其文档的编排也是二流的。总体上是一篇缺少维护、很乱的文档,读者容易被误导。这篇pdf文档由3个draft构成,adobe竟然把draft来当作标准发布,我只能说服了他。而且一定要注意的是,这里面有错误和自相矛盾的地方。现在我对它进行勘误: (1) draft 2和draft 1基本是重复的,且主要以draft 1为准。 (2) draft 2说是Message Stream Id是Big-Endian的,draft 1说是Little-Endian的,自相矛盾,实际上是Little-Endian的。 (3) 关于Protocal Control Message (CSID=2的消息) ,以draft 2的Chapter 5为准。 (4) 关于Chunk Size,指的是除去Chunk头部后面的Chunk Data的长度。即,不论头部是11字节,还是7,3,1字节,数据部分的最大长度是一致的。 (5) Max Chunk Size,默认值是128字节。文档里竟然没有提到。 为什么说它是二流的协议呢?我相信读者自己看完之后,也会同意这个观点,因为文档实在是太乱了。举二例。一者,所有的字段都是大端,惟独Message Stream Id竟然是小端。二者,没有提示用户该参考的文档,例如关于VideoData倒底是什么格式,应该提示用户去哪里查询的。 不管怎样,Adobe的这个东西在结合Flash之后应用还是广泛的,国内的这些视频网站如youku, ku6, 土豆都应该用到了。主要是应用模式是在flash里去连接一个视频服务器,服务器上存放者adobe格式的媒体,即*.flv格式。
不关我事, 老衲曾经在N个群喊人了,没人认领。
|