精华内容
下载资源
问答
  • srt协议开发资料

    2018-12-21 12:19:15
    号称基于UDP低延时传输高清视频的协议,大家可以一起研究下。SRT_Protocol_TechnicalOverview_DRAFT_2018-10-17; Haivision_SRT_Open_Source_White_Paper; SRT_Alliance_Deployment_Guide;
  • 适合开发SRT协议的软件工程师,源码是srt协议的caller即client端,主动连接srt的server端,连上后发送数据
  • SRT协议技术概述草案

    2019-01-08 19:55:50
    SRT协议技术概述草案文件,介绍SRT协议内容及实现原理
  • SRT协议

    千次阅读 2018-08-02 10:59:15
    https://en.wikipedia.org/wiki/Secure_Reliable_Transport https://github.com/Haivision/srt
    展开全文
  • SRT协议翻译

    千次阅读 2020-04-19 21:40:07
    SRT协议 srt是基于UDT传输协议,是用户级别的协议,其保留UDT的核心思想和机制,但是做了多项改进,包括控制报文的修改,针对直播流改进了流控,改进了拥塞算法,报文加密算法。本文介绍srt协议本身。更多的相关实现...

    SRT协议

    srt是基于UDT传输协议,是用户级别的协议,其保留UDT的核心思想和机制,但是做了多项改进,包括控制报文的修改,针对直播流改进了流控,改进了拥塞算法,报文加密算法。本文介绍srt协议本身。更多的相关实现在:https://github.com/Haivision/srt

    简介

    srt传输协议为不可靠网络提供安全,可靠的数据传输,如因特网。任何数据都可以在srt协议上传输,特别是对音视频流数据优化最为明显。

    在任何时候,srt都能用于视频流的汇聚/分发节点,提供几乎最好的质量和最低延时的视频。

    当报文作为流在源与目的之间传输,srt对网络进行检测和适应。srt帮助补偿jitter和带宽抖动,针对噪声网络中的拥塞。其错误恢复机制对因特网的丢包影响最小化。srt也支持aes加密来保证端到端的安全。

    SRT是基于UDT协议的(UDP-based data transfer)。虽然UDT是设计用来在公网中高吞吐的报文传输,UDT对视频直播并没有优势。SRT是一个大的改进UDT版本,其对视频直播有大的提升。

    SRT在IP网络中的低延时视频传输,是以mpeg-ts格式作为UDP的单播/多播。其方案对网络提供可靠性,通过使能FEC来减轻任何丢包。在城市间,国家间设置跨洋间的低延时通信都带有更多的挑战。虽然用卫星通信,或MPLS专网来实现,但是价格太贵。公用因特网的连接,虽然便宜很多,但是需要大量的带宽来实现丢包恢复。

    即使UDT并不是为直播流而设计,但是其丢包恢复机制能提供基本的丢包恢复功能。SRT的最早版本包括新报文的重传功能,能对直播流的丢包做快速响应。

    为了达到低延时,SRT不得不引入分时机制。一个流在因特网中传输,很多特效会被完全影响,包括延时/jitter/丢包。进而导致解码问题,音视频解码器不能解码对应时间戳上的未收到的报文。如果应用buffer缓存来避免,但是却会带来延时。

    在这里插入图片描述

    SRT的机制在接收方新创建了重要的特性,极大的降低buffer的需要。这些机制是SRT协议自身的一部分,所以一旦报文从SRT的一端发到接收端,流自身状态已经被恢复成流本身的状态。

    在这里插入图片描述
    最初SRT协议又Haivision Systems公司开发,在2017年4月Wowza Media Systems将其开源。开源的SRT遵守MPL-2.0开源协议。选用MPL-2.0协议,因为想在对开源SRT的兼容性,和估计开源社区去改进SRT协议之间做好平衡。任何第三方开发者都能自由的使用SRT开源代码。但是如果他们修改和优化代码,就必须把这些优化代码提交到开源社区。

    在2017年4月,Haivision和Wowza公司成立了SRT联盟www.srtalliance.org,致力于持续发展该协议。

    SRT的UDT4适配

    UDT是一种ARQ(自动重传请求)协议。其应用的是ARQ的第三种演进方案(选择性重传)。 UDT4的应用在ietf中提出,在draft-gg-udt-03中。

    UDT致力于容量的最大使用,也就是当发送数据的时候,应用必须保证输入buffer是足够的。当以确定的比特率发送实时视频,包的发送速度对比读取文件的速度是非常慢的。buffer耗尽会导致一些UDT算法的复位。也就是说,当拥塞发生,发送方的算法会挂住UDP API,也会把报文放入丢弃队列,这样新的报文就不能被处理。实时的视频不能被挂住的,所以报文可能被应用丢弃(因为发送API会被block住)。不像UDT,SRT对实时报文,重传报文,丢失或要丢弃的旧豹纹都共享当前的带宽。

    SRT的早期开发就引入了大量针对UDT version4的改进:

    • 基于字节统计
    • 基于毫秒单位来做延时控制(测量buffer的时间单位,更好的适配延时,使其不受流比特率的影响)
    • ACK消息的统计信息(接受速率和估计连接容量)
    • 控制报文时间戳(这个在UDT的draft中有,但是不在UDT4的应用中)
    • 时间戳漂移更正算法
    • 周期的NAK报告(UDT4去使能这个特性,用于unACKed报文的超时重传,其对实时流应用会消耗过多的带宽)
    • 基于时间戳的报文发送(可配置的延时)
    • SRT的握手是基于UDT自定义的控制报文,用于交换点到点间的配置和应用信息,以确保无缝升级,当升级协议和保证向后兼容
    • 基于配置和输入速率的最大输出速率
    • 加密优化


      早期SRT的开发,是在内网用Haivison的Makito X系列的编解码器,其能模拟包的丢弃。

      当中间报文的丢失,会导致解码器的接收buffer耗尽(没有报文送去解码)。丢失的报文不能及时的重传。解决方法是更早的触发未确认收到报文的重传(ARQ的自动重传)。然而,这会导致带宽使用的迸发。基于超时重传的发生是当报文没有很快的得到ack确认。在UDT4中,重传发生只是当丢失表空的时候。

      重传所有ack超时的报文,能解决这样的实验场景,当无网络拥塞,有随机丢包影响报文传输。在多次重传后,所有的报文都应该能被发送,接收者的队列不会被挂住。但这会消耗大量的带宽,因为没有加入速率控制。

    包结构

    SRT保有UDT的UDP报文结构,但是有很多改进。基于UDT IETF internet Draft(draft-gg-udt-03.txt)的细节。

    数据和控制报文

    每个承载SRT的UDP报文都带有SRT头(其紧跟在UDP头后面)。在所有的协议版本中,SRT头包含4个32bits字段:

    • PH_SEQNO

    • PH_MSGNO

    • PH_TIMESTAMP

    • PH_ID
      SRT有两类报文,PH_SEQNO字段的第一个bit用来标识报文类型,0是数据报文,1是控制报文。如下的例子中,就是数据报文的例子,其’packet type’ bit=0:

      注意:在SRT version 1.3中的报文结构变化。为了提高早期版本的适应能力,新旧报文格式都在下面列出(大字节序)。

      在这里插入图片描述

    • FF=(2bits) 如报文中的位置

      1. 10b = 1st
      2. 00b = middle
      3. 01b = last
      4. 11b = single
    • O = (1bit) 表示消息是否按序发送,按序1,不按序0。在文件/消息模式下(传统的UDT),当该bit为0,那么后面的消息是可以立刻发送而不用等待前面消息的发送完成。但是这在直播业务中是没有用的,因为当TSBPD模式开启时,为数据抽取而服务器的功能完全不同。

    • KK=(2bits)表示是否数据已经被加密:

      1. 00b: 不加密
      2. 01b: 加密,偶数key
      3. 10b: 加密,奇数key
    • R=(1bit)重传报文。如果是0,表示该报文是第一次发送;如果是1,就是重传报文。
      在数据报文中,第3,4字段如下的定义:

    • Timestamp: 报文时间戳

    • ID: 报文分发的目的socket id,如果是connect的发起报文,该字段就是0

    更多数据报文的细节在本文后面介绍。

    SRT协议控制报文头(“packet type” bit=1),其结构如下(未包含udp头):
    对于控制报文,头两个字段分别解释如下:

    • 头32bit:
      1. bit0: 类型,1就是控制报文
      2. bits1-15: 消息类型
      3. bits16-31: 消息扩展类型
    -----------------------------------------------------------------------
      | type | Extended Type | description                                  |
      -----------------------------------------------------------------------
      |  0   |        0      | handshake                                    |
      -----------------------------------------------------------------------
      |  1   |        0      | keepalive                                    |
      -----------------------------------------------------------------------
      |  2   |        0      | ack                                          |
      -----------------------------------------------------------------------
      |  3   |        0      | nak(loss report)                             |
      -----------------------------------------------------------------------
      |  4   |        0      | congestion warning                           |
      -----------------------------------------------------------------------
      |  5   |        0      | shutdown                                     |
      -----------------------------------------------------------------------
      |  6   |        0      | ackack                                       |
      -----------------------------------------------------------------------
      |  7   |        0      | drop request                                 | 
      -----------------------------------------------------------------------
      |  8   |        0      | Peer Error                                   |
      -----------------------------------------------------------------------
      |0x7fff|        -      | Message Extension                            |
      -----------------------------------------------------------------------
      |0x7fff|        1      | SRT_HSREQ:SRT handleshake request            |
      -----------------------------------------------------------------------
      |0x7fff|        2      | SRT_HSRSP:SRT handleshake response           |
      -----------------------------------------------------------------------
      |0x7fff|        3      | SRT_KMREQ:Encryption Keying Material Request |
      -----------------------------------------------------------------------
      |0x7fff|        4      | SRT_KMRSP:Encryption Keying Material response|
      -----------------------------------------------------------------------
    
    

    扩展消息机制是为未来的扩展,SRT可能因为某些原因今后会用到。后面的SRT扩展握手中会提及。

    • 第二个32bits:
      1. Additional info – 其在控制消息中被用作扩展空间字段。它的解析依赖于特殊消息类型,握手消息不使用它。

    Handshake报文

    Handshake控制报文(‘packet type’ bit=1) 是用来在两点之间建立连接的。早期的SRT用handshake来交换参数,在连接建立之后,但是1.3版本吧交换参数作为handshake的自身的一部分。后面的Handshake一节专门用来解释。
    在这里插入图片描述

    KM 错误反馈报文

    Key Messge Error Response控制报文(‘packet type’ bit=1)是用来交换错误状态消息。在加密一节中详细介绍。
    在这里插入图片描述

    ACK报文

    ACK控制报文(‘packet type’ bit=1) 是用来提供报文发送状态和RTT信息的。在SRT数据传输和控制一节中详细介绍。

    在这里插入图片描述

    Keep-alive报文

    Keep-alive报文(‘packet type’ bit=1) 是用来每10ms交换信息,来保证SRT流在连接断开后字段重连的。
    在这里插入图片描述

    NAK控制报文

    NAK控制报文(‘packet type’ bit=1) 是用来报告失败的报文传输。在SRT数据传输和控制一节中详细介绍。
    在这里插入图片描述

    SHUTDOWN控制报文

    shutdown控制报文(‘packet type’ bit=1) 用来发器关闭SRT连接。
    在这里插入图片描述

    ACKACK控制报文

    ACKACK控制报文(‘packet type’ bit=1) 用来回复收到ACK报文,并且可以用来计算RTT。在SRT数据传输和控制一节中介绍。
    在这里插入图片描述

    扩展控制报文

    扩展控制报文(‘packet type’ bit=1) 用来为原始UDT用户控制消息。它们被用在SRT扩展握手报文中,可以通过独立的消息,或内嵌在HANDSHAKE中。

    在这里插入图片描述

    SRT数据交互

    下表描述数据交互(包括控制数据)。注意,两点间角色的变换。举例,在会话过程中节点可以作为发起者,和监听者,然后也能成为发送和接受者在数据传输过程中。
    在这里插入图片描述

    SRT数据传输和控制

    本节介绍直播的音视频中,如何处理控制/数据报文的关键思想。

    Buffers

    当应用(编码器)提供数据给srt来发送,它们被放入一个环状的发送buffer中。它们用seqid来编号。报文放在buffer中,直到收到对端的ack,万一它们会需要被重传。每个报文都有一个时间戳,其基于连接时间(其在handshake中定义,在第一个报文发送之前)。
    StartTime是应用创建SRT socket的时刻。报文时间戳是介于StartTime和报文被加到send buffer之间。
    在这里插入图片描述注意:这里的时间是从左到右的,最新的报文在右边。

    接收者也有个一样的buffer。报文都放在buffer的队列中,直到旧的报文被上层应用获取。当配置的延时刚好到packet 2,那么packet 1就应该送个上次应用而出队了。

    在这里插入图片描述
    时间戳是和连接关联的。传输并不是基于绝对时间。调度执行时间应该是基于实际时钟时间。时间的基准应该转换每个报文的时间戳到本地时钟时间。报文都是从发生方StartTime的便宜。任何时间相关参数都是基于本地StartTime来维护的,用来计算RTT,时间区和偏移,通过nanoseconds和其他。

    Send Buffer Management

    发送队列(SndQ)是动态长度大小的,其包含了发送者buffer的内容相关多个引用。当发送队列有内容发送,相关引用信息就被加入到SndQ中。SndQ有多个buffers使用一个相同的channel(UDP socket)。

    下表显示出send buffer与SRT socket(CUDT)相关。SndQ包含socket引用,时间戳引用,本地索引信息(其是在SndQ中位置)。相关引用对象也是SndQ的对象的一部分。
    在这里插入图片描述
    SndQ是双向链表,其有send buffer的CSnode的入口点。CSnode是SndQ类的一个对象(SndQ是哥队列,但是也有其他的类成员)。CSnode并不与buffer内容相关。它有指针指向它的socket,timestamp 和buffer中的位置(其被插入到SndQ的位置)。

    SndQ有个发送线程,其用来检查是否有报文要发送。基于在入口中包含的数据,它什么socket有报文ready可以被发送了。它检查时间戳引用,判断是否packet真的需要发送。如果没有,还把它放入list中。如果ready,线程就把他从list中移除掉。

    每次发送线程发送报文,发送线程会把报文重新插入list。它然后去查看send buffer中的下一个packet。packet的时间戳决定SndQ中插入的位置,其是按照timestamps排序的。

    控制报文是直接发送的。它们病不通过SndQ或发送队列。这个SndQ更新变量,为了追踪packet插入的位置,和那个packet是最后被对端ack的。

    SRT Buffer延时

    发生者和接受者有大量的buffer,其在SRT程序代码中定义。在发送方,延时是时间,其是根据发送速率,SRT保存报文,直到给他时机发送,延时的影响对发送方比较小,如果ack晚到或没到,发送方只是按照上下文规定来丢弃。但是接收方的延时影响就明显很多。

    延时是用毫秒来定义的值,其可以用来计算成百上千的高速率。延时能被认为是一个窗口,窗口滑移是基于时间,基于一个时间来进行窗口的滑移。

    举例,在下表中,packet #2是最旧的报文,也是接受者队列的对头(packet #1已经被上层应用取走)。

    延时窗口在队列中从左向右滑动。当packet #2移除窗口外,它就需要被上次应用取走(如去用作解码)。

    考虑到接收buffer存储一系列的packets。我们也就说我们定义延时,其是一个有6个报文长度的周期。延时能被认为是6个报文窗口长度。

    在延时窗口中恢复报文的能力,依赖与传输的时间。延时窗口高效通过RTT决定什么报文能恢复,多少次被恢复。

    在这里插入图片描述
    在准确的时刻,接受者buffer释放第一个报文给上层应用。当延时窗口滑向下一个报文间隔,接受者释放第二个报文给上层应用,以此类推。

    现在我们看一下如果packet没有收到(packet#4)会发生什么。当延时窗口滑动,packet就应该可以上送给上层应用,但是该packet不存在。这就会导致跳到下个packet。其不会被恢复,那么它也将被移出丢弃list,并且永不会在要求重传。
    在这里插入图片描述
    滑移延时窗口可以被认为是一个区间,SRT能在区间内恢复大部分的packet。

    另外一方面,发送者的buffer也有一个延时窗口。当时间流逝,最旧的报文就会移出延时窗口,永不会被恢复。因为即使它们再次被发送,它们将到达接收方太晚,而不能成功被接受者处理。

    如果延时滑动窗口移除过期报文,其还没有被成功发送的(接收方没有ack成功),太晚而不用再去发送它们了。因为它们会在接受者的发送窗口之外–即使它们后面到达,它们也会被丢弃。所以这些报文应该被移除到发送buffer外。

    接收方和发送方应该有相同的延时值是非常重要的,以便协调packet的及时到达和丢弃。在早期SRT版本中,发送方把延时参数放在发送给接受者的handshake中。如果接受者上配置的延时参数较大,它会把这个延时参数放在packet中,发送response给发送方。在SRT 1.3版本后,双方都能在handshake的中立刻配置(不需要进一步的resoponse)。

    当一个packet已经发送但是没有收到ack并且超时,这个packet就被移出发生方的延时窗口。它曾是发送者buffer的延时窗口,但是ackpos不会前移(在最后一个packet被ack确认其被收到,ACKPOS节点会指向下个packet)。当延时窗口前移并最旧的packet移出窗口,这个packet就可以被移除。SndQ的清理是手动的移动ACKPOS到延时窗口的下个packet。

    所有再发送buffer的packets有保留的位置,其带有配置的长度(7个188字节,也就是1316,在加上udt头)。有很多发送buffer,每个都包含连续按顺序排列的packet。一个发送buffer是一个环形队列,开始和结束节点可以在任何节点,但是不会重合。协议保留sequence信息(基于ACK)。在传送过程中,所有packet的seq number能达到更高的数字,实际buffer位置不能达到的。发送者的buffer使用位置来计算。一个在buffer中的item都有一个开始节点start position(STARTPOS)。发送buffer中的positon和packet中的sequence是可以互相转化的,因为两者都是同时增长。

    SRT Sockets, Send List & Channel

    考虑到socket 1 和 2, 每个都有自己的发送buffer。SndQ包含一个packets的列表来发送。有一个线程来持续检查这个发送buffer。当一个报文可以被发送,一个CSnode被创建,其确认一个报文的socket,和在SndQ中一个相关的对象,SndQ讲指向发送队列尾部。

    在这里插入图片描述
    每个packet都有timestamp,依赖timestamp来确定何时发送。SndQ列表是用timestamp来排列的。如果发送线程决定socket 1发送bufer有报文ready,它就把packet放入SndQ的队列中。如果SndQ队列是空,packet就被放在队列头,并带上自己的时间戳,其决定报文什么时候该被处理。

    socket 2的发送buffer也能被加到SndQ中。发送线程将向buffer中要packet发送,线程会根据速率来计算packet的发送间隔。

    在这里插入图片描述
    带有包间隔的时间戳决定packet重新插入SndQ的位置(在从socket1 buffer的packet之前,或之后)。

    SndQ决定从哪个SRT socket去取下一个packet来发送。send buffer和socket绑定,而SndQ却是跟channle更加相关。几个socket都发送到同一目的地,所以它们是多路复用的。

    当packet被加到socket,SndQ也会被更新。当一个packet已经可以被发送,其也被基于时间戳重新插入到SndQ中的正确位置。

    这个处理过程在SndQ中发生。对每个packet报文,有一个线程去检查是否该发送。如果没有,就什么也不错。否则,线程要求SRT socket把这个packet发送到channel。在SndQ的条目有SRT socket的引用。

    当一个packet被写到send buffer,它也被加入到SndQ中,其也通过CSnode来确保其不会产生重复的条目项。SndQ重复的移除条目项,并同时插入新的packet到正确的位置上。

    在不同SRT socket的packet的时间戳是本地的,其定义的时间是发送时对比当前时间。在packet加入到SndQ的时刻,他的时间戳对比当前的时间决定其在SndQ中的位置。

    Send buffer的操作和SndQ的操作是分离的。packet被加入到buffer,且然后SndQ被通知有packet需要发送。它们各自有自己的行为。

    send buffer的内容会被加入到应用线程中(sender线程)。然后有另外一个线程和SndQ互动,其通过输入buffer的速率负责控制packet间隔。输出是通过buffer中的packet间隔来调整控制。

    Packet Acknowledgement(ACKs)

    在确定的间隔(与ACKs, ACKACKs 和 Round Trip Time相关),接收方发送ACK给发送方,使得发送方把收到ack的packet从sender buffer中移除,其在buffer中的空间点将被回收。ACK包含了packet的sequence number,其是刚最新收到报文的seq+1。当没有报文丢失的情况下,ack返回的seq应该是n+1(n是接收到的packet的seq number)。

    举例,如果接受者发送packet 6的ACK(如下),意味着比这个sequence数小的报文都收到了,能从发送者的buffer中移除。

    在这里插入图片描述
    在丢失的案例中,ACK(seq)就是丢失列表中的第一个报文,其就是最新收到报文的seq+1。

    Packet Retransmission (NAKs)

    如果packet 4到达了接受者的buffer,但是packet 3并没有到达,NAK报文就需要发送给发送着。NAK被加到一个列表(周期的NAK报告),其周期的发送给发送方,以此避免NAK报文本身传输中丢失或延迟到达。

    在这里插入图片描述
    如果packet 2到达,但是packet 3没有,那么当packet 4到达后,NAK就应该按照规则发送来发起要求重传。

    在这里插入图片描述

    Packet Acknowledgment in SRT

    UDT草案定义周期发送的NAK控制报文,其包含一个丢失报文的列表。UDT4应用去使能这个特性,而用定时重传的方法来代替。NAK的发送仅仅发生在一个丢失报文被检测到(也就是下一个报文都收到了,但是上一个报文未能收到)。如果NAK本身丢失,ACK会阻塞在这个packet,同时阻止发送更多的报文给接收端直到丢弃list为空。在发送方,因为如果没收到NAK报文,丢失的报文也不会被加入到丢失list中去,并会影响到没有收到ACK报文的重传。

    UDT处理拥塞的方法是通过阻止重传直到丢失列表为空,这个做法基本上是错的。因为重传丢失列表报文优先会很大可能阻塞住接收方。

    在SRT接下来的修改中(举例NAK周期发送,基于时间戳的发送,太晚报文丢弃等等),会降低ACK-timeout重传的发生。

    Timestamp-based Packet Delivery(TsbPD)

    这个特性是使用UDT packet头中的timestamp。早期的SRT TsbPD设计是想复制编码器的输出,来作为解码器的输入。这个设计没有考虑到传输的瓶颈,报文传输越快,丢失的报文重传也就越快,避免了低延时。但是SRT协议是基于网络带宽受限的情况下开发的,能占有网络没有任何限制。

    另外一个问题是原始SRT TsbPd的设计是基于CPU限制的。ts packet的时间戳是基于系统能产生和标识packet的时间戳。如果接收者没有同样的CPU容量,也就不能复制发送者的模式。

    SRT的当前版本,TsbPD允许接受者以相同的速率发送packet报文给接收者,其速率是SRT发送者编码器的发送速率。基本上,在接收者把收到的报文上送给应用前,发送者在报文中的时间戳会被调整成接收者的本地时间(补偿时间偏移或不同的时间轴)。packet能被SRT基于配置的接收者延时来保有。更高的延时能容忍更大的报文丢失发生率,或更大的报文丢失突发率。接收到的报文在它们被play后再丢弃掉。

    packet的timestamp(微秒)是关联到SRT的连接建立时间。原始的UDT 编码用packet 发送时间来作为packet的timestamp。对于TsbPD特性来说,是不正确的,因为如果一个新的时间(当前的发送时间)用来重传报文,会导致乱序,因为按时间把重传报文插入到队列中。报文应该基于sequence number来插入。

    当一个packet在应用把packet报文放入SRT的原始时间(微秒)就是packet的timestamp。TsbPD特性用这个时间来作为packet第一次发送的timestamp,和接下来任何时间重传报文的timestamp。时间戳和配置的延时控制控制恢复buffer和实时发送到对方的packet。

    UDT协议本身并不使用packet timestamp,所以这个修改对UDT协议并不影响,也不会影响到当前已存在的拥塞控制方法。

    Fast Retransmit:快速重传

    原始的UDT4未确认ack的报文重传是基于超时机制,这样对于实时数据并不友好。只要在loss list中还有报文,没有收到ack的报文就不会被重传。因为丢失报文的重传是并发发生的,当重传定时器到超时时刻,会开始一波并发事件,其会影响到实时数据(拥塞窗口,发送者buffer慢,丢包等等)。

    快速重传在拥塞窗口满之前,通过重传没有收到ACK的报文来解决这个问题。发送着把在合理时间内没有收到ACK的报文都放入loss list中,合理的时间基于RTT和丢弃报文的timestamp。

    快速重传机制,减少了接收者buffer size,和延时。其也让丢包数量变量变化更平滑,对比于拥塞窗口满时的重传。然而,这个特性也是对带宽非常饥渴的。SRT发送者的这个特性是与SRT1.0接收者可以互通配合的。当有了周期的NAK报告后,这个特性就很少用了,或仅仅作为看门狗。

    Periodic NAK Reports:周期发送NAK

    SRT1.0在报文丢包率大于2%后是非常不高效的。很多报文重传都不止一次,其实都没有完全确认清楚该报文是否真的丢失。造成的情况是,带宽的瓶颈和延时无法承受这样丢包率造成的重传。

    Periodic NAK Reports在UDT4的源码中被去使能了。这个特性在SRT1.1.0的接收者中被重新开启,用来提高SRT适应高丢包环境,和所有的丢包环境。因为重传带宽的超出,这样的应用会造成大概两倍的丢包率。对于SRT配置参数的限制内,10%的抗丢包是可以达到的。

    SRT的Periodic NAK Reports是基于RTT/2为周期,最小20ms(UDT设定是300ms)。一个NAK控制报文含有一个丢失报文的压缩列表。所以,仅仅丢失的报文会被重传。通过使用RTT/2作为NAK报告的周期,这会导致丢失报文可能会被重传一次以上,但是这样会保持低延时在NAK报文丢失的情况下。

    Too-Late-Packet-Drop: 报文太晚丢弃

    这个特性在SRT1.0.5中开始有,允许发送端丢弃报文,如果其没有机会及时发送。在SRT发送端,如果Too-Late-Packet-Drop使能,报文的时间戳比SRT最大延时的125%还要大,就会被认为太晚而不用在发送了,会被编码器丢弃。IFrame尾部的报文就有可能被丢弃。

    接收者(SRT>=1.1.0)可以不让使能发送端的包丢弃,来防止发送端的产生bug。发送端(srt>-1.1.0)会保留报文至少1000ms,如果SRT的最大延时小于1000ms(对最大的RTT不够的话)。
    在接收端,大IFrame的尾部可能晚到,并且不会被SRT接收buffer缓冲到。接受buffer耗尽,如果有发现丢包发生,就没有时间可以重传。丢失的报文被接收者忽略。

    Bidirectional Transmission Queues:双向传输队列

    SRT也支持这样的场景,接收者也有自己的发送队列,发送着也有相应的接受队列,支持双向通信。

    这是很有用的,能支持标准点到点的SRT会话,两端都有发送/接受buffer。发送端的Tx buffer对应接收端的Rx buffer,而接收端的Tx buffer对应发送端的Rx buffer。和普通单方向的会话一样,Tx/RX的延时相互匹配。

    在handshake报文中,发送端提供自己的Tx latency和假想对端的latency(接收端的Tx buffer值)。接收端也响应回复对应的参数。提议的latency值是在单个RTT周期内,双方评估的结果(尽量选择大一点的值)。
    在这里插入图片描述

    ACKs, ACKACKs & Round Trip Time

    Round Trip Time(RTT)是时间的度量,表示报文一个来回的耗时。SRT不能测量单方向的耗时,所以只能用RTT/2来表示单方向耗时。一个ACK(从接收方)会触发ACKACK(从发送方)的发送,几乎不带其他延时。ACK的发送时间与对应ACKACK收到时间的差值就是RTT。

    在这里插入图片描述
    ACKACK告诉接收者停止发送对应便宜点的ACK,因为发送端已经知道接收端收到了。否则,ACK(带有过时信息)将被持续的周期发送。类似的,如果发送端没有收到ACK,它自己也会周期发送没有收到ACK的packet。

    有两种情况发送ACK。一个full ACK是基于10ms(ACK周期)发送。对于高bitrate的传输,一种"light ACK"就能被发送,期是多个packet的一个sequence。在10ms的间隔里,经常有大量packet的发送和接收,以至于发送端ACK的偏移点不能够快的移动。为了减轻这个问题,在收到64packets后(即使ACK发送周期还没到),发送端发送一个light ACK。
    在这里插入图片描述
    ACK动作像ping报文,而ACKACK像ping back回复,以此可以度量出RTT。每个ACK都有一个数值,而ACKACK也有相同的一个数值。接收方有一个ACK的列表去匹配ACKACK。不像full ACK报文(包含当前的RTT和多个其他的控制信息参数),light ACK包含sequence数值(如下表所示)。在接收端,所有控制消息被直接发送和处理,但是ACKACK的处理时间是微不足道的(因为它的处理时间被包括在RTT里面)。

    RTT是在接收端被计算出来的,并且发送下一个full ACK。注意,第一个ACK包含的RTT值默认是100ms,因为早期的计算可能不准确。
    在这里插入图片描述
    发送端永远都是通过接收端获取到RTT。没有一个方法来模拟ACK/ACKACK机制(举例,不可能发送一个消息,这个消息不处理而立刻返回)。

    Dirft Management: 偏移管理

    当发送方进入“连接”状态,它就告诉上层应用有个socket interface接口已经ready可以发送了。在这个时间的,应用可以开始发送数据packet了。它以一定的输入速率把packet加入到SRT发送方的buffer,通过这个buffer,packet以规定的时间发送到接收者。

    同步的时间是需要来保证,接收者/发送者buffer的登记,需要考虑到时间轴和RTT。考虑到加/减RTT,和可能的不同步的系统时间,一个都能认同的时间基准,每分钟约几个微秒的偏移。这样的偏移累积起来可能需要几天才能让发送/接收的buffer耗尽或溢出,从而严重影响视频质量。SRT有时间管理机制来补偿这个偏移量。

    当packet收到后,SRT能得出packet timestamp和期望timestamp之间的差值。时间戳timestamp的计算是在接收方进行。RTT告诉接收方报文要消耗多少时间。SRT在发送者buffer的延时窗口的边缘时间和接收者对应时间之间维护一个参数。这样能允许基于本地时间实时的能调度事件。

    接收者采样时间偏移数据,和周期的计算packet timestamp纠正参数,两者就能用来对每个收到的data packet来调整报文间隔。

    当一个packet收到后,不能马上上送上层应用。当时间推移,接收者就能算出丢失报文预计的时间,并且可以用这些信息去用特殊报文来填补这些“丢包的空洞”。

    接收者用本地时间去调度事件—举例,去决定是否现在上送一个packet。每个packet里的timestamp都与会话开始时候有个差值。当收到一个packet(packet内带有发送方的timestamp),接收者就用本地时间与会话开始时间之间的差值,来重新计算packet的timestamp。start time就是会话开始时的本地时间。packet timestamp就等于当前时间减去start time(packet_timestamp=now-start_time),start time就是socket的创建时刻。

    Loss List

    发送方通过NAK报告来建立lost packe list。当调度到发送,先看lost list中是否有报文需要发送,有的话先发送lost list中的。否则,就发送SndQ list中的。注意,当packet发送后,仍旧在buffer中保留以免对方没有收到。

    收到NAK报文后,就把其中的报文放入lost list。当延时窗口前移,packet将被移出send queue,需要检查一下是否丢弃或重传的packet在lost list中,以此来决定是否把这些报文移出lost list,因为它们没有必要再重传。在send queue和lost list的操作是通过ACKPOS决定。
    在这里插入图片描述
    当ACKPOS前移到一个点,所有比这个点旧的packet都可以被移出send queue。
    在这里插入图片描述当接收者遇到遇到这种情况,下一个应该被play的packet没有收到,它就应该跳过这个packet,并且发送一个fake ACK。对于发送端,fake ACK就是真的ACK,也就是说发送端就认为这个packet真的被成功接收了。这个方法有利于帮助发送者和接收者之间的同步。实际上packet的丢失对于发送端是不知道的。跳过这个报文在接收端的统计statistics中有记录。

    当发送端收到NAK packet。也有个packet的计数器。如果packet没有对应的ACK,它就在lost list中保留,有可能被多次发送。在lost list中的packet优先级更高一些。

    如果在lost list中的packet持续的阻塞住send queue,在一些情况下就会造成send queue被填满。当send queue满了,发送端首先就丢弃packet而不是发送它们。编码器(或上层应用)可能持续的生成packet,但是send queue没有空间放入,所以packet会被直接丢弃。SRT本身不对未发送报文敏感的,其也不会在SRT statistics中显示。

    这种packet上层丢弃的情况几乎不会发生。放在send buffer中packet的数量是基于配置延时参数的。旧的packet,没有机会再被重传或被play的,会被丢弃,为上层应用的新报文留空间。当低延时配置被配置,最小一秒的延时是被使能的。一秒的限制是来源于MPEG I-frame用SRT传输的情况。IFrame是比较大的(通常8倍于其他packet),需要更多的时间来发送。其太大而不能在延时窗口中保留,可能会造成queue中的报文丢弃。为了避免这种情况,SRT应用在丢弃packet前,最少有1秒等等(或延时变量值)。这就可以当应用最小延时变量,仍可以应用到IFrame中。

    SRT Packet Pacing: SRT按速率发送packet

    UDT用最大带宽设置来控制packet输出速率。这个statics设定对于动态的输入不太友好,特别当你改变编码器的编码bitrate的时候。SRT控制packet速率基于输入速率,和重传的负荷(这些都基于输出来计算)。

    早期,SRT用配置的输入速率作为编码器的输出速率(根据packet的音频和最高的bitrate)。但是有时对于编码器经常会输出过高的速率。在低速率输出时,编码器有时太过于乐观,就会输出超过预期过高的bitrate。在这些情况下,SRT packet就不会足够快的输出,因为SRT会最终被过低的错误配置影响到。

    这可以通过计算bitrate来缓解这个问题。SRT检测到要发送的packet,并且计算出它的平均移动bitrate。然而,这样的操作可能会有一些延时。也就是说,如果编码器遇到黑屏或者静帧,它就会大幅度的降低bitrate,就会降低SRT bitrate。而当编码器输出突然增大,SRT也不会立刻增大很快。packet可能会延时,解码器收到就会晚,从而造成问题。

    一个提议的解决方案是,让SRT把编码器的input rate配置,和测量实际input rate,使用这两者的中最大值。

    输出是通过控制packet周期(两个packet之间的间隔)。对于一个指定的bitrate,SRT计算出一个packet的平均大小。packet的间隔是通过比较持续packet中的timestamp来定义。packet的输出是通过packet size和间隔来调度。

    在这里插入图片描述
    传输速度是通过packet之间的定时器来控制的。在老的代码中,packet周期是通过拥塞控制模块来调整的。基于从网络的反馈,packet间隔可以突然减小来加速,或突然增加来减速。但是这在SRT的直播模式中并不适合。音视频流bitrate是在mpegts packet形成,修改出口packet pace病不能影响到接收方单个的流rate–它会影响到解码。早期SRT是在一个周期里,输出rate与输入input相当。默认情况下,SRT测量input流的bitrate,根据这个来调整packet period。

    SRT需要一个确定的足够带宽(比预想的带宽略高),为了有空间插入更多的重发packet,而不影响SRT发送者的主流输出速度太多而导致packet不能正确发送。唯一的办法是通过network的反馈来降低拥塞,来控制编码器的输出(SRT的输入)。不太可能对已经打包到预想bitrate的packet进行调整,因为这个预设定的速度已经是解码器想要的速度了。

    这里有3个配置项:INPUTBW, MAXBW 和 OVERHEAD(%)。

    在这里插入图片描述
    设置输入带宽(INPUTBW)参数为0,意味着用内部测量值(smpinpbw)来设置packet周期,同时与output的overhead最大配置配合来完成。

    一个绝对的最大带宽(MAXBW)能被配置成一个能力极限值。设定MAXBW为0的话,就是只用INPUTBW来调整输出。

    这里有个情况是SRT需要考虑的。问题就是测量输入带宽的方法有一个延后问题,这个测量是平均值。所以如果输入速率突然降为0(举例,因为可能会有黑屏在视频流中),测量结果就会掉入低值的rate。但是当视频速率突然增长,input rate就突然增长。SRT的输出速率就会落后于编码器的输入速率。报文就会累计在SRT发送者的buffer中,因为SRT要花时间来测量速度。如果packet太晚输出,就会导致问题。

    在这里插入图片描述
    为了解决这个问题,SRT的发送方的输出是通过视频编码器的速率来配置的。因为可能通过编码器配置的bitrate来配置SRT的bitrate,任何修改都能被直接copy到SRT的配置中。这个是全局的。
    在这里插入图片描述
    如下表所示,SRT的发送者bitrate因为黑屏而降低,但是不会一直降低。
    在这里插入图片描述
    但是这个解决方案有它自己的弱点。在低bitrate,SRT从编码器来的输入速率经常会超过预先配置的bitrate。因为SRT发送方的输出是基于配置编码器的bitrate来调整,输入突然过高会导致packet再send buffer中的堆积。buffer的堆积比packet的发送更快。但是SRT输出还会依赖配置的速度,但是被累积的packet不得不超时发送。它们会在buffer中累计,不会即使的输出,最后导致一些packet会被发送过晚。

    在这里插入图片描述
    图中橘黄色线以上表示,基于延时需要利用overhead space进行重传的pakets。橘黄色线表示的区域是丢失packet的数量。这些packet不得不加入到图表的上部,实时直播流不得不一直维护这些信息。

    基于这个原则,packet之间的空间决定重传packet在什么地方插入,overhead代表可以提供的边界。有个经验的计算,定义packet之间的间隔从而得出输出bitrate。它是负载的功能(负载包含音频/视频)。

    SRT尝试基于解码器输出来重新定义发送者的输入带宽,重发packet是透明的,就好像它们从来没被重传过。当到达一个临界点,但是一旦packet pacing下降,有很大的累积在send buffer。它突然变满,并且不能足够快的清空,到某个时间点packet就开始丢包。

    SRT版本1.3合并了两种packet pacing的方法。输入rate的检测,但是如果其掉速太多,SRT发送者输出的配置bitrate是公认的。如果测量低于配置速率,它并不遵循测量速率(如果完全没有packet发送,SRT就不发送)。然而,如果编码器输入速率大于配置速率,它就遵循编码器配置速率,越快越去遵循。绑定这两种方法来克服各自的问题。

    在这里插入图片描述理论上,带宽能力是带宽overhead的值。如果有太多packdet而不能发出,SRT不能发出。但是带宽能力的机制不能正常工作。带宽限制就被轻易的击溃。

    另外一个SRT版本1.3的变化,是加了一个配置option,叫OUTPACEMODE,其使能其他pacing项的组合。设置MAXBW模式就是以绝对带宽容量值,其并不随编码器的输入而波动。设置MAXBW为0,意味着使用INPUTBW。相反的,设置INPUTBW为0意味着完全使用内部测量值。

    SRT 1.3版本用这些技术的捆绑来作为配置输入,而不是只用测量值,或使用两者间的最大值。OUTPACEMODE是用来使能其他配置项的合并使用。它定义了MAXBW,INPUTBW,和两者的合并,或两者都不使能(不限制)。

    SRT packet pacing总结如下。默认,直播模式下的输出rate是基于输入rate的(也就是流的输出)。输入rate(sendmsg API)是内部测量到的,输出rate是动态调整的,包括配置overhead(25%),其被加到重传packet的迸发rate中。

    Packet Probes

    当SRT用很多技术方法在流控上,但有很多限制在于无法准确的计算链路的带宽容量。这里的Packet probe技术是每16个packet报文间隔发送一次“packet probe”其没有报文间隔的延时。如果这两个连着的packet到达接收者是有间隔的,意味着网络有影响的背景流量,其也意味着足够的网络带宽有所下降。这也帮助去测量网络带宽能力。但是在packet之间的空间的计算是无法控制的,也就是说足够的带宽量是很难定义出来的。

    在这里插入图片描述

    展开全文
  • SRT协议详解二 工作原理

    千次阅读 2020-05-21 19:45:35
    2.1. SRT工作原理 要说SRT的工作原理,我们先从其纠错机制说起。 下图描述了在数据包传输过程中,不使用数据纠错,使用FEC(Forward Error Correction)纠错,和使用ARQ(Automatic Repeat request)纠错三种链路...

    2.1. SRT工作原理

    要说SRT的工作原理,我们先从其纠错机制说起。

    下图描述了在数据包传输过程中,不使用数据纠错,使用FEC(Forward Error Correction)纠错,和使用ARQ(Automatic Repeat request)纠错三种链路传输纠错方式的模式和结果。

    如果没有数据纠错,结果自不必说,一旦发生丢包,得到的就是不完整的数据流,如下图。
    在这里插入图片描述
    图2-1 数据包传输时没有纠错机制
    (图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》)

    如果使用FEC纠错,则会在传输的数据流中加入一定比例的前向纠错数据,当发生丢包时,接收端就可以根据前向纠错数据,恢复丢掉的数据包,如下图。

    但是使用FEC就必须面对这样的问题:无论是否产生丢包,前向纠错数据都需要占用一定的传输带宽;而且当丢包率超过前向纠错数据能够恢复的阈值时,FEC将无法恢复丢失的数据包。
    在这里插入图片描述
    图2-2 数据包传输时使用FEC纠错
    (图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》)

    如果使用ARQ纠错,就需要在发送端和接收端之间建立双向连接。在接收端收到数据包后,会按照数据包的顺序进行排序(传输过程中数据包可能会发生乱序),如果发现其中有丢失的数据包,就会向发送端发出重传请求,由发送端将丢失的数据包重新发送到接收端,从而实现数据包的恢复,如下图。

    在这里插入图片描述
    图2-3 数据包传输时使用ARQ纠错
    (图片来自SRT Alliance白皮书《Haivision SRT Open Source White Paper》)

    而我们说的SRT技术,正是使用的ARQ纠错机制,这主要是因为在网络传输时,带宽抖动和丢包通常都是随机发生的,只有在网络出现问题的时候才需要纠错机制的介入,只需要在发生丢包之后让发送端重传丢失的数据包就可以了,这样既保证了传输的质量,同时又能减少无谓地消耗传输带宽;除此之外,SRT会为数据包提供更精准的时间戳,让接收端能够准确校准媒体流的包顺序,保证传输正常。

    之前已经说过,SRT协议依靠双向传输的UDP流来保证公网环境下的视频传输质量。除了从SRT源设备到SRT目标设备持续发送视频数据外,在两台设备之间还会持续地交换SRT控制信息,以此来在两台设备之间实现以UDP为底层协议的连接,进行信息交互,确保视频数据能够准确地传输到接收端。

    在这里插入图片描述
    图2-4 SRT连接中的双向UDP流
    *注:

    1. SRT源设备发送的UDP流包含数据业务流和SRT控制信息;
    2. SRT目标设备接收源设备发来的UDP流,同时回复相应的SRT控制信息。

    为了让SRT保持连接状态,必须确保控制信息数据包的发送间隔不超过10ms。每当SRT目标设备收到一个数据包后,都会回复一个“ACK”确认控制信息数据包,告诉SRT源设备已经收到这个数据包了,如果在10ms内收到多个数据包,则只回复一个“ACK”,确认这期间收到的所有数据包;然而,数据包的到达时间间隔难免会超过10ms,这时就需要增加“keep alive”控制信息数据包,确保SRT连接不会断开。

    在SRT连接中,从目标设备返回源设备的控制信息通道也会占用一定的带宽。在业务数据完全正常传输的情况下(即没有错误信息需要返回到发送端),控制信息占用带宽大约为40Kbps;传输时丢失的数据包越多,目标设备发出的控制信息就越多,信息量会与丢包率线性相关,每丢失1个数据包,大约会消耗400bps的可用带宽。

    2.2. SRT握手模式

    现在我们已经知道SRT的工作原理了,那么一个SRT连接又是如何建立的呢?要清楚这个问题,我们就不得不了解SRT握手模式:Caller & Listener和Rendezvous。

    在讨论建立SRT连接时,我们不需要区分SRT源设备和SRT目标设备,发送端和接收端都可以发起建立SRT连接,我们只要知道哪端的设备满足设置相应模式的网络需求即可。

    2.2.1. Caller模式

    ✦ 功能:
    设置Caller模式的设备将作为SRT会话的发起者,它必须知道对应设置Listener模式的设备的公网IP地址及其监听的UDP端口。

    ✦ 使用场景:
    ①让一台设备发起建立一个点对点传输的SRT连接;
    ②设备所在的网络有防火墙,但没有防火墙操作权限;
    ③设备的IP地址是DHCP动态获取的;
    ④设备没有固定的公网IP地址。

    2.2.2. Listener模式

    ✦ 功能:
    设置Listener模式的设备会监听发起SRT会话的请求,它需要知道应该使用的UDP端口(如网络管理员分配给SRT传输使用的UDP端口),并一直在这个端口上监听发起SRT会话的请求。

    ✦ 使用场景:
    ①让一台设备监听发起SRT会话的请求;
    ②设备所在的网络有防火墙,并且可以控制防火墙,打开需要的UDP端口;
    ③设备直接暴露在公网环境下。

    2.2.3. Rendezvous模式

    ✦ 功能:
    两台设置Rendezvous模式的设备会共同协商,通过相同的UDP端口号建立一个SRT会话。

    ✦ 使用场景:
    ①两台设备所在的网络都有防火墙,但是没有防火墙的操作权限,如果防火墙设置了适当的工作模式(将在Chapter 3.实际应用场景中详细介绍),可通过此模式建立SRT会话。

    一旦完成SRT连接的建立,SRT源设备和SRT目标设备便开始交换控制信息,如网络状况信息、丢失的数据包等等,无论设备设置的是Caller、Listener还是Rendezvous模式都无关紧要了,直接利用建立起来的SRT通道去传输数据就可以了。

    2.3. SRT如何建立连接

    那么这三种握手模式实际又是如何把SRT会话建立起来的呢,下面我们通过简单的图示来了解这个过程。

    2.3.1. 由SRT源设备发起建立SRT连接

    如下图,将编码器HDE-650S设置为Caller模式,解码器HDD-461设置为Listener模式,编码器(Caller)将向设置的UDP端口连续发送控制信息数据包,请求建立SRT连接(图中①),当解码器(Listener)收到这些数据包后,便开始回复它自己的控制信息数据包(图中②),一旦握手成功,编码器便开始在UDP流中增加视频流,开始视频传输(图中③)。
    在这里插入图片描述
    2.3.2. 由SRT目标设备发起建立SRT连接
    如下图,将编码器HDE-650S设置为Listener模式,解码器HDD-461设置为Caller模式,解码器(Caller)将向设置的UDP端口连续发送控制信息数据包,请求建立SRT连接(图中①),当编码器(Listener)收到这些数据包后,便开始回复它自己的控制信息数据包(图中②),一旦握手成功,编码器便开始在UDP流中增加视频流,开始视频传输(图中③)。

    在这里插入图片描述
    2.3.3. 使用Rendezvous模式建立SRT连接

    如下图,SRT源设备和SRT目标设备同时设置为Rendezvous模式,两台设备一起向对方发送控制信息数据包,一旦握手成功,编码器便开始在UDP流中增加视频流,开始视频传输。
    在这里插入图片描述
    2.4. SRT与防火墙

    在实际使用场景中,特别是在通过互联网进行数据传输时,终端设备通常都会经过防火墙再连接到互联网,SRT流就必须穿过防火墙进行传输。这种情况下,我们就需要网络管理员来帮忙对防火墙进行适当的配置,尤其像网络地址转换(NAT)和数据包过滤的设置,防火墙的配置情况将会决定设备使用哪一种握手模式。
    下图中,一台编码器尝试通过互联网将视频流发送给解码器,两台设备都在防火墙后。我们不妨假设编码器使用Caller模式,解码器使用Listener模式,为了使它们握手成功,并建立SRT会话,就必须满足下列条件:
    ① 解码器端的防火墙需要允许某个供SRT使用的UDP端口可以从互联网接入;
    ② 编码器必须知道解码器端防火墙的公网IP和开放的UDP端口;
    ③ 两端的防火墙都要允许双向UDP传输;
    ④ 两端的防火墙都要配置端口转发,允许编码器和解码器之间的数据流传输;
    ⑤ 两端的防火墙都要关闭数据包过滤功能,允许编码器和解码器之间的交互数据包通过。

    在这里插入图片描述
    图2-9 经过防火墙进行视频传输
    转载至:
    https://blog.csdn.net/weixin_42228920/article/details/90946259?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-8&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-8

    展开全文
  • SRT协议简介

    千次阅读 2020-05-09 16:53:16
    Haivision联手Wowza在UDT的基础上针对音视频实时性提出了SRT协议。SRT是基于UDT的协议(UDT协议是基于UDP的传输协议,在IETF已经提交了4个版本),具有非常良好的丢包重传机制,丢包重传的控制消息非常丰富,同时...

    SRT是啥?

    Haivision联手Wowza在UDT的基础上针对音视频实时性提出了SRT协议。SRT是基于UDT的协议(UDT协议是基于UDP的传输协议,在IETF已经提交了4个版本),具有非常良好的丢包重传机制,丢包重传的控制消息非常丰富,同时支持ACK、ACKACK、NACK。

    为啥会出现SRT协议?

    当前互联网中使用最多的直播协议使RTMP,但是随着新技术不断发展和新的业务需求不断出现,RTMP的几个不足越发明显:

    1. 长时间不更新:RTMP自2012年之后,没有进行过更新。HEVC/AV1等视频格式没有官方定义,都是CDN厂商自行定义。
    2. 建立连接过程长:RTMP基于TCP,TCP三次握手增加了连接过程,此外,RTMP本身又存在c0/s0到c2/s2的三次握手,再加上connection,createstream,play/publish,RTMP完成一次建连需要进行9次会话,对于网路质量特别是移动端网络质量的要求则很高。
    3. RTMP的拥塞控制完全依赖传输层,即完全依赖于TCP传输层的拥塞控制算法来进行拥塞管理,几乎没有什么优化;RTMP本身基于TCP传输,无法提供带宽自适应的算法。

    众多厂商开始研究基于UDP 的传输协议,例如SRT、QUIC等。

    SRT特点

    1. 基于UDT协议。UDT协议(UDP-based Data Transfer Protocol)是指基于UDP的数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输,建于UDP之上,并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。
    2. 丢包重传机制好,具有丰富的丢包重传的控制消息,同时支持ACK、ACKACK、NACK
    3. 基于时间的报文发送,能够有效防止流量突发
    4. SRT对上层提供了丰富的拥塞控制统计信息,包括RTT、丢包率、inflight、send/receive bitrate等。利用这些丰富的信息,可以实现带宽预测,并根据带宽的变化在编码层去做自适应动态编码与拥塞控制。

    应用案例:

    全链路适配SRT,腾讯云直播平台再升级

    阿里云推出SRT+杜比全景声直播方案,低成本打造高质量直播观感体验

     

    展开全文
  • SRT协议详解三 传输参数

    千次阅读 2020-05-22 11:02:14
    这一节,我将逐个向大家介绍会影响SRT传输性能的参数名称,他们包括:Round Trip Time(RTT,往返延时)、RTT Multiplier(RTT倍数)、Packet Loss Rate(丢包率)、Bandwidth Overhead(带宽开销)以及Latency...
  • SRT 协议的数据包结构解析和抓包分析一些废话文章信息文章正文 一些废话 ...本文从SRT协议的工作流程谈起,着重介绍和解析了SRT协议的数据包结构,并举例说明如何利用Wireshark抓包软件进行链路故障分析
  • SRT协议详解四 应用场景

    千次阅读 2020-05-22 14:09:56
    在了解SRT协议的基本原理后,我们可以尝试使用高骏公司的互联网编解码器模拟来进行视频传输,感受一下协议中提到的参数是如何在实际应用中体现的。 3.1. 在公网环境下开启视频传输:Caller & Listener模式 让...
  • SRT协议详解一测试

    千次阅读 2020-05-21 18:44:41
    最近,在研究低延迟视频传输课题时接触到了SRT协议。SRT是一个时下非常受欢迎的开源低延迟视频传输协议。SRT是Secure Reliable Transport的简称。它拥有三大特点,安全,可靠,低延迟。安全方面,SRT支持AES加密,...
  • SRT协议控制包处理源码解读

    千次阅读 2019-10-12 17:44:09
    SRT协议控制包处理源码解读SRT协议控制包处理源码解读ACK包1. 如果ACK包长度为SEND_LITE_ACK(4)2. 普通ACK包ACKACK包LOSSREPORT包CGWARNING包KEEPALIVE包HANDSHAKESHUTDOWNDROPREQPEERERROREXT源码 SRT协议控制包...
  • SRT协议在电视直播中的应用

    千次阅读 2020-08-14 08:00:00
    本文来自安徽广播电视台 直播技术工程师 张博力在LiveVideoStackCon 2020 线上峰会的演讲,详细介绍了SRT协议在信号传输、远程制作等方面的应用,以及实际工作中遇到的相...
  • 因为RTMP协议安全性稍低,延迟相对较高 ,而相对于SRT协议支持高质量、稳定性、亚秒级延迟、强大的编解码器支持。SRT被许多行业专家认为是视频流的新协议。SRT究竟是什么? 什么是 SRT? 安全可靠传输 (SRT) 是一种...
  • mobile-ffmpeg添加srt协议(Android版本) mobile-ffmpeg项目github 目前该项目未支持srt协议,本文记录向其添加srt协议的过程。 Step0:大致了解mobile-ffmpeg的编译过程 以Android为例,该项目编译入口为android....
  • 本问描述SRT的三种握手模式:listener,caller, rendezvous;并用编码器与vMix和OBS为例,举例说明这3种握手模式的使用方法。
  • 什么是SRT协议? SRT是由Haivision和Wowza共同创建的SRT联盟所发起的互联网传输协议,是一种开源、免费和应用灵活的规范,它的性能与专用的协议一样优秀,同时能够在不同制造商生产的产品之间工作。 SRT是时下非常受...
  • SRT协议详解六 传输架构

    千次阅读 2020-05-22 15:07:55
    SRT配置示例: 配置示例 SRT Url格式: Url格式 SRT参数配置: SRT参数 SRT支持编码格式: SRT支持编码格式
  • 本资源内文档是一个实测实记,使用WowzaStreamingEngine-4.7.6在阿里云上启动SRT流媒体协议并使用手机推流、PC拉流。受够了RTMP协议的小伙伴可以考虑改用更快更好的SRT协议
  • 小白篇之ENC编码器的SRT协议多平台推流配置编码器SRT协议三种模式listener, caller, rendezvous简介1. 背景2. SRT的三种握手模式2.1 握手模式简介2.2 listener模式2.2.1 编码器配置为listener模式发送2.2.2 vMix配置...
  • SRT协议的Wireshark解析器编写(Lua)

    千次阅读 2019-08-17 17:19:44
    WireSharks插件编写(lua)前言APIProtoProtoField满足按位显示的例子(同时满足字符串查找)TvbTvbRangePinfoTreeItem实现协议里面添加子树例子DissectorTable代码部分大致框架完善完善字段完善解析函数关于标志位...
  • Secure Reliable Transport Protocol SRT协议

    千次阅读 2019-01-30 16:51:14
    最近,在研究低延迟视频传输课题时接触到了SRT协议。SRT是一个时下非常受欢迎的开源低延迟视频传输协议。SRT是Secure Reliable Transport的简称。它拥有三大特点,安全,可靠,低延迟。安全方面,SRT支持AES加密,...
  • 什么是SRT协议? SRT是由Haivision和Wowza共同创建的SRT联盟所发起的互联网传输协议,是一种开源、免费和应用灵活的规范,它的性能与专用的协议一样优秀,能够同时在不同制造商的产品之间工作。 SRT是时下非常受欢迎...
  • SRT协议详解五 推流规范

    千次阅读 2020-05-22 14:23:32
    基于srt官网的文章: srt官网的文章 最新的srt推流地址规范修改为: URL for defaultVhost Publish stream by SRT: srt://127.0.0.1:10080?streamid=#!::h=live/livestream,m=publish Play stream by SRT srt://...
  • MinGW配合cmake以及vs 2019 preview编译的srt源码32位,包括所有的lib和dll以及exe,需要用到的.h 使用方式,将文件放入MinGW/msys/1.0/local,输入命令export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig 之后即可...
  • 于是开始着手研究SRT协议,在Github和CSDN不断查找资料,最终还是测试成功,将SRT协议应用于局域网的校园直播。以下为研究过程。 1、SRT协议可以在Ubuntu和centos7系统上,我测试的系统为Ubuntu LST 服务器版,首先...
  • VMIX 23 下Srt协议编码器推流设置教程

    千次阅读 2019-12-24 10:37:40
    SRT协议是一种能够在复杂网络环境下实时、准确地传输数据流的网络传输技术。它传输层基于UDP,继承了UDP开销低、速度快的优点,再加上SRT自身强大的数据恢复能力,给行业提供了一种安全、稳定、快速的传输方案。 ...
  • 我们所知道 SRT 是由 Haivision 和 Wowza 开发的开源视频流协议。很多人会认为在不久的将来,它被是 RTMP 的替代品。因为 RTMP 协议安全性稍低,延迟相对较高 ,而相对于 SRT 协议支持高质量、稳定性、亚秒级延迟、...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,860
精华内容 744
关键字:

srt协议