超越TCP:迎接下一代传输协议
从普通的老式传输控制协议(TCP)到新构思的协议, 通过互联网传输视频的各种方法是整个流媒体行业感兴趣的关键领域. 毕竟, 如果交付方式跟不上，那么最好质量的捕获和压缩又有什么用呢?
早在一月份，在一篇名为 “延迟糟透了!” 这是为了降低交互式或流媒体视频的整体传输时间, 我们谈到了一些较新的传输协议衍生品:web实时通信(WebRTC)。, 可靠用户数据报协议, 和普通的老式实时协议(RTP). 较低的延迟通常等同于较低质量的压缩, 假设给处理器压缩视频图像的时间越长, 质量越好. 在本文中, 我们将更深入地研究底层协议，并讨论哪些协议对特定的应用程序有意义. 而OTT (over-the-top)实时线性传输的基础依赖于可靠的协议, TCP, 实际上，流媒体专业人员可以使用许多技术.
着眼于降低延迟和提高可靠性, 在很好地处理邻居(相邻的数据包和网络设备)的同时，现在让我们探索在TCP的基础上扩展或取代TCP作为流传输霸主的替代传输协议.
亦WebRTC
作为1月份以来的快速回顾，以下是我们对WebRTC的了解. 由Google和其他开源和开放标准社区的主要参与者推动, WebRTC是为点对点通信设计的, 主要是小团体.
默认情况下，WebRTC被设计为使用UDP和RTP, 尽管如果检测到异常，可以将其设置为使用基于tcp的回退. 不足为奇的是, WebRTC的视频编解码器是VP8和VP9, 谷歌在致力于开放媒体联盟AV1编解码器的同时，还在继续推进这一技术. AVC，更广为人知的是H.264, 也可以用, 尽管AVC的音频同伴不能:音频通常是一个叫做Opus的开源编解码器, 而不是更广泛使用的AAC.
WebRTC能够实现非常低的延迟, 但在典型的流媒体环境中通常不能正常运行, 即基于实时消息传递协议(RTMP)的协议, HLS, 或者AVC和AAC.
像Nanocosmos GmbH这样的公司, 这家总部位于柏林的公司专注于从媒体服务器到最终用户的解决方案, 有没有提出创建可扩展的WebRTC实时场景的概念. 但该公司承认这一点, 在交货方面, 它缺少CDN和供应商支持, 包括苹果的任何支持.
修复TCP
许多不同的方法都试图“修复”TCP, 包括一些试图通过缩小窗口大小来规避其固有问题的方法, 如果TCP报文没有被终端用户设备接收到，则发送此报文, 该设备可以请求重传数据包。. 如果TCP窗口太短, 虽然, 当分组传输被备份或分组之间的冲突增加时，问题就随之而来了.
使用WebSockets是一种尝试创建持久传输状态(本质上是一个隧道)的方法，它可以消除由于TCP窗口时间过短而导致的TCP数据包传输错误的累积. 还有一些解决方案通过降低http传输视频(如HLS或MPEG-DASH)的段大小来实现，从而允许更快的启动时间和更低的总体延迟.
HLS和DASH都受到限制，需要基于文件的段，这些段是通过HTTP请求提取的,Oliver Lietz说, 的首席执行官 Nanocosmos. “由于HTTP和互联网连接的性质, 在不牺牲性能和稳定性的情况下，不能轻易地将段大小减小到2秒以下.”
HLS的这些段传统上是MPEG-2传输流(M2TS或TS), 它本身是基于几十年前的异步传输模式(ATM)协议，该协议旨在通过卫星发送视频信号. 除了将视频分割成22到10秒的片段所花费的时间, 实际的TS封装具有相对较多的报头位以及交错音频.
这些报头位对于以直接1:1的链路从地面站到卫星再到接收卫星碟形天线的方式重组通过卫星发送的内容非常有用, 但在网络传输协议处理传输顺序的TCP环境中，它们是不必要的.
2011年底，人们首次讨论了部分包装方面的进展, Adobe和微软联合提出了使用碎片化MP4文件的案例，这将允许传输多种视频流排列.g.，相机角度)和音频流(e.g., 替代语言或评论轨道)，而不需要基于对M2TS封装方法的依赖而减慢HLS的交错.
MPEG-DASH采用了碎片化的MP4 (fMP4)方法, 苹果在其最新版本的iOS移动平台上也是如此. 迁移到fMP4的一个结果是能够完全避免HLS和DASH基于文件段的限制.
例如, Nanocosmos使用来自MP4直播流的基于帧的片段, 本质上允许fMP4作为“段”来实现超低延迟, 为标准的HLS玩家提供了低延迟的HLS.
恢复UDP
TCP的兄弟被称为UDP，它的设计不一定是为了与其他协议很好地配合.
很简单, 低级因特网协议, 至少与TCP相比是这样, UDP方法放弃了发送方和接收方之间特定的握手. 这有助于提高交付速度, 但是，由于数据包没有得到接收方的确认，因此无法保证交付.
“市场渴望开源, 免费提供, 低延迟, 类似udp的互联网流媒体方法,彼得·马格说, 首席营销官 Haivision, 该公司与Wowza共同开发了一种名为安全可靠传输(SRT)的协议，以融合UDP和TCP的优势.
SRT融合了TCP/IP传输的弹性和UDP的性能,马格说。, ，并增加了安全感, network-health监控, 并且简化了防火墙的遍历.”
SRT的市场策略不是从媒体服务器到最终用户, 但是从摄取点到媒体服务器. 以这种方式, SRT将自己定位为RTMP的可伸缩性有限的替代品, 这也是WebRTC支持者的目标.
“SRT目前是贡献和分配性能流的理想选择,马格说。, 并补充说, 以及其他开源的努力, 其目标是“扩展SRT以应对大规模OTT交付的挑战”.”
Lietz认为RTMP仍然是摄取的最佳方法, 鉴于市场上支持rtmp的编码器数量众多. 他还认为UDP“潜在地降低了复杂性，并允许创建低延迟的应用程序.但他补充说:“对于可靠的直播应用。, 需要在UDP之上添加几个应用层.”
一种方法是在UDP之上添加一个传输流, 就像几十年前M2TS格式将MPEG-2多路复用成段一样.
“另外, 需要增加前向纠错(FEC),Lietz说, 承认这些添加使UDP在延迟方面接近TCP的阈值.
更令人担忧的是, 而UDP有时在多播应用中使用, 并且可以使用标准编解码器，如H.264和AAC, 就浏览器支持而言，UDP没有普遍可用的应用程序标准.
海视科技的Maag表示，SRT解决了这些问题. 除了, 因为SRT已经存在很长一段时间了, 他说，它已经在某些利基市场找到了食用的吸引力.
“SRT可以被任何需要低延迟视频流硬件或软件的开发人员使用,马格说。, 他指出，SRT于2013年推出，“目前已被数百家顶级广播公司和企业用于性能流媒体应用.”
相关文章
这份报告, “创造用户想要的流媒体体验,“重点关注五个市场的首帧时间和端到端延迟:用户生成内容, 网络游戏, 体育, 新闻, 和广播.
2017年7月6日
这是当今视频直播面临的最大挑战之一, 它仍然顽固得令人沮丧. 探索能够最终将延迟降低到1秒的技术解决方案.
1月12日
确保观众的广播质量不仅仅是减少缓冲. 出版商还需要提高后端操作的效率.
2016年10月03日
提及的公司及供应商