最简单的PC流媒体应用，可以使用Flash采集摄像头和麦克风后，以RTMP协议推送给流媒体服务器，然后在浏览器中用Flash播放器播放这个RTMP流。总共需要多少行代码？可以100行as代码就可以实现，脏累烦的事情都是flash搞定了。

视频点播，从来就不是RTMP的事情，那是HTTP文件的世界，一个HTTP-MP4文件，可以在所有平台观看。直播呢也不仅仅是PC了，移动互联网、h.265和mpeg-dash，这些视频的新技术，发展的速度非常快。而HLS这个和RTMP一样古老的Apple的流媒体技术，在Android3支持了HLS后，HLS成了移动互联网应用最广泛的技术。

RTMP还是那个RTMP，从视频的编码采集到服务器，还是RTMP；分发到PC，可以RTMP，也可以HLS了；分发到移动互联网，自己的app可以RTMP，浏览器只能HLS了。

而流媒体服务器的角色，也从分发RTMP直播流，变成了分发RTMP和HLS流。RTMP对于直播流媒体服务器，还是扰不过去的大坑。让我们一起数一数RTMP这个坑里有多少个球吧。

第一个球，变更过的加密握手协议。RTMP协议Adobe公开了吗？是的，可以在Adobe官网上下载。按照协议实现一个RTMP服务器时，发现里面的握手是变更过了的；这就是为何SRS需要编译openssl库，需要从客户端的握手信息中获取客户端的公钥，然后按照指定算法交换密钥。如果按照RTMP标准文档握手会怎样？Flash播放器只能播放vp6编码的流，无法播放h.264的流，呵呵。

第二个球，变更过的扩展时间戳传输方法。RTMP的时间戳是24位的，如果超过这个4.5小时连续推流，就需要用到高8位的扩展时间戳。标准中说，chunked的X3包，是不能包含扩展时间戳的；可惜Adobe的所有产品都用了，从flash到FMLE到FMS。而ffmpeg中也有注释抱怨说Adobe太坑爹了，没事改它干啥。而SRS中对于这种处理，是采用猜测，即X3的chunked包先读4字节出来，如果和消息的时间戳吻合那么就是Adobe系统，也有些开源的产品遵守规范的，SRS会自动适配。

第三个球，RTMP的时间戳是32位还是31位？在flv标准中，明确讲了是31位(SI32)即24.8天左，而按照RTMP的49.7天回绕的说法应该是32位。一般没有问题，谁会看一个直播24.8天呢？额，这个不是很严谨的做法，对于服务器来讲。SRS使用31位。

第四个球，不能变更ChunkSize。有些服务器不能变更ChunkSize，所以SRS在Edge模式时，回源某些服务器会有问题。这个球只能配置SRS的默认ChunkSize，配置为128即原始值。

第五个球，溢出的ChunkSize。RTMP标准说ChunkSize最大不超过65535，有个什么球服务器，就喜欢设置一个比这个大得多的ChunkSize，泥马！这个该怎么处理？忽略标准就好，实际上没有这个上限。

RTMP的扩展时间戳传输，请参考：http://blog.csdn.net/win_lin/article/details/13363699

RTMP的复杂握手协议，请参考：https://github.com/winlinvip/simple-rtmp-server/wiki/v1_CN_RTMPHandshake

RTMP的更多信息，请参考：https://github.com/winlinvip/simple-rtmp-server/wiki/v1_CN_DeliveryRTMP