超越TCP:迎接下一代传输协议

从普通的老式传输控制协议(TCP)到新构思的协议, the variety of methods for delivering video across the internet is a key area of interest for the entire streaming media industry. 毕竟, what good is the best-quality capture and compression if the delivery method can't keep pace?

早在一月份，在一篇名为 “延迟糟透了!” that dealt with lowering the overall delivery time of interactive or streaming video, we touched on a few newer transmission protocol derivatives: web real-time communication (WebRTC), 可靠用户数据报协议, 和普通的老式实时协议(RTP). 较低的延迟通常等同于较低质量的压缩, based on the assumption that the longer the time given to processors to compress a video image, 质量越好. 在本文中, we will take a deeper look at the underlying protocols and discuss which ones make sense for particular applications. While the underpinnings of over-the-top (OTT) live linear delivery rely on a tried-and-true protocol, TCP, there are actually numerous technologies available to the streaming media professional.

着眼于降低延迟和提高可靠性, while playing nicely with the neighbors— neighboring packets and networking gear—let’s now explore alternate transmission protocols that expand on or replace TCP as the reigning streaming transmission champ.

亦WebRTC

作为1月份以来的快速回顾，以下是我们对WebRTC的了解. Promoted by Google and other major players in the open source and open standards community, WebRTC是为点对点通信设计的, 主要是小团体.

默认情况下，WebRTC被设计为使用UDP和RTP, 尽管如果检测到异常，可以将其设置为使用基于tcp的回退. 不足为奇的是, WebRTC的视频编解码器是VP8和VP9, which Google has continued to advance while also working on the Alliance for Open Media’s AV1 codec. AVC，更广为人知的是H.264, 也可以用, al虽然 the audio companion to AVC cannot: Audio is usually an open-source codec called Opus, 而不是更广泛使用的AAC.

WebRTC能够实现非常低的延迟, 但在典型的流媒体环境中通常不能正常运行, 即基于实时消息传递协议(RTMP)的协议, HLS, 或者AVC和AAC.

像Nanocosmos GmbH这样的公司, a Berlin-based company that focuses on solutions from the media server to the end user, 有没有提出创建可扩展的WebRTC实时场景的概念. 但该公司承认这一点, 在交货方面, 它缺少CDN和供应商支持, 包括苹果的任何支持.

修复TCP

许多不同的方法都试图“修复”TCP, including some that attempt to circumvent its inherent problems by narrowing the windowing size (the period of time in which, 如果TCP报文没有被终端用户设备接收到，则发送此报文, 该设备可以请求重传数据包。. 如果TCP窗口太短, 虽然, trouble ensues as packet transmissions get backed up or collisions between packets increase.

Using WebSockets is one approach that attempts to create a persistent state of transmission (essentially a tunnel) as a way to eliminate the buildup of TCP packet transmission errors inherent to very short TCP windowing times. Still other solutions work by lowering the segment size of an HTTP-delivered video (think HLS or MPEG-DASH) to a level that allows for faster startup times and lower overall latency.

“HLS and DASH both suffer from the restriction to require file-based segments which are pulled over HTTP requests,Oliver Lietz说, 的首席执行官 Nanocosmos. “由于HTTP和互联网连接的性质, the segment size cannot be reduced below 2 seconds easily without sacrificing performance and stability.”

These segments for HLS have traditionally been MPEG-2 transport stream (M2TS or just TS), which itself is based on a decades-old asynchronous transfer mode (ATM) protocol designed for sending video signals across satellite. 除了将视频分割成22到10秒的片段所花费的时间, the actual TS packaging has a relatively high number of header bits as well as interleaved audio.

These header bits were useful for reassembling content sent over a satellite in a direct 1:1 link from an earth station to a satellite to a receiving satellite dish, but they are unnecessary in a TCP environment where the network transmission protocol handles delivery sequencing.

2011年底，人们首次讨论了部分包装方面的进展, with Adobe and Microsoft making the joint case for the use of fragmented MP4 files that would allow delivery of multiple permutations of video streams (e.g.，相机角度)和音频流(e.g., alternate language or commentary tracks) without requiring interleaving that slowed down HLS based on its reliance on the M2TS packaging approach.

MPEG-DASH采用了碎片化的MP4 (fMP4)方法, 苹果在其最新版本的iOS移动平台上也是如此. One result of this move to fMP4 is an ability to avoid altogether the restrictions of file-based segments of HLS and DASH.

例如, Nanocosmos使用来自MP4直播流的基于帧的片段, 本质上允许fMP4作为“段”来实现超低延迟, 为标准的HLS玩家提供了低延迟的HLS.

恢复UDP

The sibling of TCP is called UDP, and it isn’t necessarily designed to play well with others.

很简单, 低级因特网协议, 至少与TCP相比是这样, UDP方法放弃了发送方和接收方之间特定的握手. 这有助于提高交付速度, but there is no guarantee of delivery as packets are not confirmed by the receiver.

“市场渴望开源, 免费提供, 低延迟, 类似udp的互联网流媒体方法,彼得·马格说, 首席营销官 Haivision, which has jointly developed a protocol called secure reliable transport (SRT) with Wowza to blend the strengths of both UDP and TCP.

SRT融合了TCP/IP传输的弹性和UDP的性能,马格说。, ，并增加了安全感, network-health监控, 并且简化了防火墙的遍历.”

SRT的市场策略不是从媒体服务器到最终用户, 但是从摄取点到媒体服务器. 以这种方式, SRT将自己定位为RTMP的可伸缩性有限的替代品, 这也是WebRTC支持者的目标.

“SRT目前是贡献和分配性能流的理想选择,马格说。, 并补充说, 以及其他开源的努力, 其目标是“扩展SRT以应对大规模OTT交付的挑战”.”

Lietz认为RTMP仍然是摄取的最佳方法, 鉴于市场上支持rtmp的编码器数量众多. He also feels that UDP “potentially reduces complexity and allows creating 低延迟 applications.但他补充说:“对于可靠的直播应用。, 需要在UDP之上添加几个应用层.”

一种方法是在UDP之上添加一个传输流, in much the same way that the M2TS format multiplexed MPEG-2 into segments decades ago.

“另外, 需要增加前向纠错(FEC),Lietz说, acknowledging that these additions take UDP close to the threshold of TCP in terms of latency added to the mix.

更令人担忧的是, 而UDP有时在多播应用中使用, 并且可以使用标准编解码器，如H.264和AAC, there is no generally available application standard available for UDP in terms of browser support.

海视科技的Maag表示，SRT解决了这些问题. 除了, 因为SRT已经存在很长一段时间了, 他说，它已经在某些利基市场找到了食用的吸引力.

“SRT can be used by any developer needing 低延迟 video streaming for hardware or software,马格说。, noting that SRT launched in 2013 and “is being used today by hundreds of top broadcasters and enterprises alike for performance streaming applications.”

下一个页面