SRT协议简介
协程是现代服务器的核心技术，能极大简化逻辑和提升维护性；SRT是逐渐在取代RTMP推流的新协议，但它有自己的IO框架；只有实现了SRT的协程化，才能成为SRS的核心的成熟的协议，这是SRS 5.0迈出的第一步，也是至关重要的一步。SRS 5.0从2022年初启动以来，经过摸索和探讨，确定了以媒体网关作为核心方向，详细请看SRS 5.0核心问题定义和解法。SRT作为主播/广播推流领域广泛采用的协议，而Web浏览器却不支持播放SRT流，这恰恰是媒体网关的核心价值，可以将SRT转成RTMP/HLS/WebRTC后，实现广播领域的Web超低延迟方案，还可以把SRT强大的跨国传输能力用起来。而这些美好愿景的基础，就是这次要介绍的：改造SRT支持协程化(Coroutine Native SRT)。这是SRS 5.0至关重要的一步，也是具备深远影响的一步，详细代码请参考PR#3010。我们先了解下详细的背景介绍。在直播推流领域，RTMP是事实上的工业标准，广泛使用，也是直播源站之间兼容性最好的协议。随着场景的丰富和直播的发展， 几个比较严重的问题逐渐暴露出来：[*]TCP推流在长距离传输下，受丢包以及RTT抖动影响非常大，效果很差。
[*]RTMP协议不支持多音轨，以及H265、AV1等一系列新的编解码。
[*]Adobe已经放弃RTMP协议，很多年没有更新了，未来也不会更新。
为了解决这些问题，2018年左右，广播电视领域开始广泛应用SRT协议推流，越来越多的推流设备和平台都支持了SRT协议。SRS在2019年底，SRS 4.0支持了SRT推流，目前存在以下的问题：
[*]SRT在SRS上使用多线程+异步实现，某些异常导致的程序Crash，难以排查。
[*]SRT在SRS实现是异步方式，代码复杂，维护难度高。
[*]HTTP回调，SRT播放不生效；SRT推流依赖转RTMP后，RTMP触发的回调。
[*]SRT无法直接转WebRTC，而是先转RTMP再转WebRTC，导致延迟高。
这些问题的核心原因，是由于SRT使用了独立的异步IO和多线程，无法和SRS已有的ST协程结合起来。要彻底解决这个问题，必须将SRT协程化，和SRS使用同一套ST协程框架。SRS 5.0已经完成，详细代码请参考PR#3010，这是非常重要的一个功能。在介绍SRT协程化之前，先介绍下什么是协程化，我们看下ST的TCP协程化(Coroutine Native)，这是最好的例子。
页:
[1]