产品动态 | 腾讯云音视频直播多协议推流平台

随着新技术的不断发展与使用场景的不断拓展，主流的RTMP协议已经满足不了更丰富的场景。

腾讯云音视频在流媒体传输上不断深入优化，以适应不同场景的需求。除了支持常见的RTMP协议外，腾讯云音视频多协议推流平台(以下简称多协议平台)还支持WebRTC/SRT/QUIC等其他协议，下面重点介绍多协议推流平台支持的推流协议以及它们的应用场景。

RTMP/RTMPS：

RTMP，实时消息传输协议（RealTime Messaging Protocol），是目前主流的流媒体传输协议，广泛用于直播领域，可以说市面上绝大多数的直播产品都采用了这个协议。

RTMP的缺陷：

• 协议太老，不再更新。最近的一次更新是2012年。HEVC/AV1等视频格式都没有官方定义，都需要cdn自行定义。
•  rtmpover tcp连接过程太长。tcp需要三次握手，rtmp需要从c0/s0到c2/s2三次握手，此外还有connection，createstream，play/publich。
• rtmp拥塞控制完全依赖tcp传输层的拥塞算法来做拥塞管理。
• 无法实现自适应带宽编码。

RTMP的鉴权完全依赖url增加相关参数，rtmp server根据参数做验证，没有对传输的音视频数据包做加密，只要截取到rtmp包解析后就可以播放。RTMPS协议能够很好的解决RTMP安全问题。RTMPS协议是经过SSL加密的RMTP协议，增强了数据通信的安全性，允许通过加密编码器和CDN之间的流来安全地进行流传输。

使用SSL加密的RTMPS需要证书，RTMPS使用tcp443端口。这里存在一个常见的问题，用户如果想使用自己的证书，必须更换端口。腾讯视频云多协议平台的RTMPS协议优化了这一点，用户无需更换端口，就可以使用自己的证书，多协议平台会自动根据域名去做适配，匹配到对应的证书。

在腾讯云音视频上使用RTMPS非常简单，如果使用视频云通用证书，直接接入即可，如果想使用自己的证书，需向视频云提供用户自己的证书。

适用场景：

 RTMP适用于对直播没有特殊需要的场景；RTMPS适用于有加密需求的客户，尤其是有出海业务的客户，海外平台例如Facebook目前只支持RTMPS的数据传输协议。

接入指引：

https://cloud.tencent.com/document/product/267/56843

WebRTC：

WebRTC，名称源自网页即时通信（Web Real-Time Communication）的缩写，浏览器不需要服务器的中转，可以直接通信。

WebRTC优点：

• 提供低延迟、高质量的实时音视频通信；
• 一套端上的流媒体框架，音视频处理全套能力，并且具有跨平台特性；
• 提供了一套标准的API（被纳入W3C推荐标准），Web应用开发人员可以基于这套API实现丰富的实时音视频应用。
• WebRTC还有一个优势是其他音视频解决方案无法达到的，就是它已经集成到浏览器中，无安装、无插件。

多协议推流平台在原有直播架构基础上，对WebRTC进行改造能直接接收WebRTC推流。标准WebRTC由于不支持H.265音视频编码格式不支持B帧编码，已经无法满足国内直播行业需求，多协议推流平台对WebRTC进行了优化与升级改造，以达到高兼容、低成本、大容量的低延时直播要求。主要优化点如下：

• WebRTC是基于SDP进行能力协商的，为了更好的支持新功能新特性，同时兼容标准WebRTC，多协议推流平台对WebRTC扩展的SDP定义和协商进行了规范。
• 支持H265，腾讯云音视频支持添加H.265相关信息，并实现H.265的RTP拆包、解析、组帧和解码等功能模块。
• 支持B帧。通过终端SDK在offer sdp中添加B帧相关信息，实现B帧timestamp非单调递增的处理逻辑，后台实现相应B帧timestamp封装逻辑。
• 非加密传输。标准WebRTC原本的设计使用场景是音视频通信，所以加密是必选项。而在直播应用中很多场景是公开的，没有必要采用加密传输，去掉加密既可以省去开播时DTLS握手产生的延时，也可以减少后台和前端加解密的开销。

此外，多协议推流平台的WebRTC还针对场景做了可配置的容错特性，主要根据音视频编码的特点并结合业务场景，例如将传输的报文分了多个优先级，在需要主动丢包的情况下优先丢弃低优先级的数据(如B帧，音频等)。

适用场景：

WebRTC是一个基于HTML5的协议，它非常适用于基于网页且无flash的应用场景。包括远程应急通信，会议等。

接入指引：

https://cloud.tencent.com/document/product/267/56505

RTMP OVER QUIC：

QUIC

（Quick UDPInternet Connection）是谷歌制定的一种基于UDP的低时延的互联网传输层协议。

众所周知，TCP可靠、稳定，但是建连需要经过3次握手，相对繁琐、效率低且占用系统资源高；UDP效率高、快、轻量，占用系统资源较少，但是存在不可靠、无序等缺点。QUIC协议既吸收TCP和UDP的优点，又对当前网络环境有优良的适应性，尤其是在弱网环境下能保证数据传输的可靠、稳定和高效。

关于QUIC的原理，相关介绍的文章很多，这里再列举一下QUIC的重要特性。这些特性是QUIC得以被广泛应用的关键。不同业务也可以根据业务特点利用QUIC的特性去做一些优化：

• 低连接延时：QUIC由于基于UDP，无需TCP连接，在最好情况，短连接下QUIC可以做到0RTT开启数据传输。基于TCP的HTTPS，即使在最好的TLS1.3的early data下仍然需要1RTT开启数据传输。而对于目前线上常见的TLS1.2完全握手的情况，则需要3RTT开启数据传输。对于RTT敏感的业务，QUIC可以有效的降低连接建立延迟。
• 可自定义的拥塞控制：QUIC的传输控制不再依赖内核的拥塞控制算法，而是实现在应用层上，这意味着我们根据不同的业务场景，实现和配置不同的拥塞控制算法以及参数。GOOGLE提出的BBR拥塞控制算法与CUBIC是思路完全不一样的算法，在弱网和一定丢包场景，BBR比CUBIC更不敏感，性能也更好。在QUIC下我们可以根据业务随意指定拥塞控制算法和参数，甚至同一个业务的不同连接也可以使用不同的拥塞控制算法。
• 无队头阻塞：虽然HTTP2实现了多路复用，但是因为其基于面向字节流的TCP，因此一旦丢包，将会影响多路复用下的所有请求流。QUIC基于UDP，在设计上就解决了队头阻塞问题。同时，IETF设计了QPACK编码替换HPACK编码，在一定程度上也减轻了HTTP请求头的队头阻塞问题。无队头阻塞使得QUIC相比TCP在弱网和一定丢包环境上有更强大的性能。
• 连接迁移：当用户的地址发生变化时，如WIFI切换到4G场景，基于TCP的HTTP协议无法保持连接的存活。QUIC基于连接ID唯一识别连接。当源地址发生改变时，QUIC仍然可以保证连接存活和数据正常收发。

多协议推流平台结合业务场景也对RTMP OVERQUIC做了一些优化：

• 多协议推流平台将QUIC协议栈与高性能网络框架做了深度融合，并支持QUIC WEB协议，QUIC私有协议，带外拥塞控制配置等大部分QUIC功能和特性。满足QUIC大规模部署与运营。
• 多协议推流平台对QUIC协议栈0RTT，1RTT，小包，高带宽等多场景做了大量的性能优化，解决了QUIC严重消耗CPU资源的几个瓶颈。在小包请求上性能基本可以达到HTTPS的90%。
• 多协议推流平台提供了定制化的RTMP OVER QUIC SDK，以用于客户端满足定制化QUIC的各种特性。

适用场景：

基于以上优点，QUIC更适合运用在网络丢包率较高的环境，因为QUIC具有0RTT快速连接能力、丢包重传中ACK回复的block较大并且在拥塞控制方面表现非常优秀。除此之外QUIC也适合用于长距离传输当中，因为网络传输RTT较高，QUIC在连接断开后重连是0RTT，传输数据更加高效。

接入指引：

https://cloud.tencent.com/document/product/267/52522

TS/RTMP OVER SRT：

安全可靠传输协议(Secure Reliable Transport)简称SRT，Haivision联手Wowza在UDT的基础上针对音视频实时性提出了SRT协议。SRT是基于UDT的协议。

SRT是时下非常受欢迎的开源低延迟视频传输协议，SRT解决了复杂的传输时序问题，SRT可以减少延迟，消除中心瓶颈，并降低网络成本。SRT采用的是ACK + NACK的解决方案。每隔10ms，SRT接收方会发送一个"正常"ACK包，将当前接收buffer中连续的最大包序号告诉发送方，发送方收到"正常'ACK包后，会确认数据，将发送窗口前移，同时发送ACKACK，接收方依据T(ackack) - T(ack)来计算链路rtt。对于高码率的链路，每10ms确认一次可能会不及时，为此，SRT每收到64个包，便会额外回复一个LITEACK，用来快速确认数据，尽可能快的让发送窗口移动。

SRT协议的三大特点：安全，可靠，低延迟。

• 安全方面，SRT支持AES加密，保障端到端的视频传输安全。
• 可靠性方面，SRT通过前向纠正技术(FEC)保证传输的稳定性。
• 低延迟方面，由于SRT建立在UDT协议之上，解决了UDT协议传输延迟高的问题。UDT协议是基于UDP网络通信协议的。

SRT解决了复杂的传输时序问题，可以做到支持高吞吐量文件和超清视频的实时传输。

腾讯云音视频SRT上行推流支持两种方式：

• ts over SRT推流。通过SRT直接传输包含音视频数据的ts流，下行复用现有直播系统。TS over SRT已作为Haivision硬件及OBS的推流格式标准。
• rtmp over SRT推流。腾讯云音视频将SRT作为传输层之上的协议，可以将任何基于tcp的应用层协议改造为基于SRT的应用层协议。目前在云直播LVB中支持该方式的推流。

此外腾讯云音视频基于SRT做了很多改进：

• 重传率优化。原版重传间隔控制的不够精细，此处改为基于rtt来控制重传间隔。重传率相对原版降低了30%左右。
• 支持超时重传。此问题基于rtmp over srt的连接bug，由于仅依靠NAK快速重传，会导致最后一个包丢失无法重传的问题，该bug已提交issue和解决办法给官方。
• 性能的大幅提高。腾讯云音视频针对开源项目做了性能上的提升，并利用了CPU的多核特性。
• 连接效率的优化。原版的握手考虑安全特性需要2个rtt。改进点主要是支持1rtt、0rtt握手等特性。

适用场景：

基于以上特点， SRT适合点到点流媒体传输，大主播质量保证，移动直播。目前很多大客户已经在不同规模的应用SRT。从上行卡顿率数据看到，卡顿率有明显的改善。腾讯云音视频也在一些重大的电竞赛事中使用SRT作为上行推流。

接入指引：

https://cloud.tencent.com/document/product/267/53955

GB28181/RTSP：

国标GB28181由公安部科技信息化局提出，该标准规定了城市监控报警联网系统中信息传输、交换、控制等技术要求。

RTSP

（Real TimeStreaming Protocol），RFC2326，实时流传输协议，是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。

GB28181/ RTSP是视频监控中常用的协议。

近年来，在平安城市、智安小区等政策的扶持下，安防监控逐渐成为市场的新增长点。此外随着AI、5G技术的快速应用，视频监控跟各行各业结合起来。这些场景的应用只依靠安防原有的局域网是无法解决的。

腾讯云音视频能够很好的满足上面的需求，直接对接GB28181/RSTP协议。客户只要注册腾讯云音视频直播账号，就能直接推流到腾讯云音视频直播。

适用场景：

适用于通过RTSP或者GB28181等局域网监控其他IP视频需要转公网直播(rtmp/hls/ts)。

接入指引：

    如果需要接入，可以提工单处理。

RIST

可靠的互联网流传输(Reliable Internet Stream Transport)是一种开源、开放规范的传输协议，旨在通过有损网络（包括互联网）以低延迟和高质量可靠传输视频。

从技术上讲，RIST通过在传输层使用RTP/UDP来提供可靠、高性能的媒体传输，以避免TCP的限制。可靠性是通过使用基于NACK的重传(ARQ)来实现的。

RIST有Simple Profile和Main Profile两种版本。其中Simple Profile于2018年10月发布，包括以下功能：

• 使用ARQ的可靠传输(包丢失恢复)。
• 重传控制，以停止带宽使用失控。
• 链路聚合。
• 路径冗余。

多协议平台支持Simple Profile的RIST。

适用场景：

RIST越来越被视为流媒体工作流程中可靠、低延迟的一部分，它的主要应用场景是让传统媒体公司在自己的工作流程中移动视频和将视频移动到云上。

接入指引：

    如果需要接入，可以提工单处理。

各协议特点：

腾讯云音视频在音视频领域已有超过21年的技术积累，持续支持国内90%的音视频客户实现云上创新，独家具备 RT-ONETM 全球网络，在此基础上，构建了业界最完整的 PaaS 产品家族，并以 All in One SDK 的创新方式为客户服务。腾讯云音视频为全真互联网时代，提供坚实的数字化助力。