本文来自SF Video Tech,来自Mux的工程师Nick Chadwick带来了一场演讲,帮助我们快速深入的了解RTMP协议。
若干年前,RTMP的延迟很低,已接近成为事实上的标准。但目前,在HLS,DASH,SRT和RIST等协议之间,业界正在尽最大努力摆脱它。由于RTMP还没有消失,我们仍需花一些时间来了解它是如何工作的。
首先是RTMP的简史。Nick解释了Adobe创建此协议的历史,以帮助理解它为什么有用,以及Adobe发布的规范如何没有发挥应有的作用。RTMP协议由macromedia创建,并由Adobe采纳,为其Flash技术服务,并成为类似RTP等复杂机制的替代。但很长时间以来它都是闭源的,因此从2005年开始,人们前赴后继的逆向此协议并发布了若干开源版本。最终Adobe在2012年发布了RTMP标准,但仍保留了部分技术,如H264先经过一种加密的握手方式才能进行解码播放。Adobe还构建了专利和法律的保护,这些都使得其逐渐远离了潮流。
Nick从高低两个层次概述了该协议。它是一种基于TCP的协议,允许多个双向流,还支持RPC机制。RTMP可以在一个TCP连接上,多路传输更大的消息,比如视频、消息以及非常短的数据请求如RPC。包级的多路复用允许RTMP在发送长消息的同时向另一端询问问题。
具体来说,RTMP的层级可分为streams, messages和chunks。一个逻辑流可分为视频、音频和元信息流,在消息流中每个消息紧挨着发送,每个消息都被切分成一定大小的块,这些块在单个TCP连接中传输。他快速地介绍了块的头,解释不同类型的块是什么,以及如何压缩头以节省比特率。他还描述了RTMP时间戳的工作原理以及控制消息和命令消息机制。通过块的机制,不同的消息流可以交织。最后介绍了RTMP的消息流,包括文档和代码中规定的消息格式,控制消息,类似binary JSON的AMF消息,连接方式,创建流,发布等细节。
最后,他对RTMP协议的未来展开了设想。因为RTMP有一个硬编码的支持的编解码器列表,这在扩展到新的编解码器时产生了困难。他介绍了对协议的改进建议,包括可协商的编码器设置,灵活的编码器支持,动态码率,增加UDP支持,简化规范,支持WebRTC等。
值得注意的是,这个演讲是2017年的。虽然关于RTMP本身的一切仍然会是正确的,但是当下SRT、RIST和Zixi已经取代了很多RTMP工作流程。