CN114598428A - 一种基于srt协议的冗余推流方法 - Google Patents

Abstract

本发明属于图像通信技术领域，涉及一种基于SRT协议的冗余推流方法，包括：编码器推流；读取数据；判断主备状态；主流动作；发送SRT负载数据；备流动作；结束播放。本发明利用服务端负责链路故障的切换，针对SRT冗余推流功能，服务自动调度一路正常的链路转发给拉流端，并且能够在其中一路推流断开的时候，自动切换推流链路，直到拉流端正常播放为止。SRT协议基于UDP协议，相比基于TCP的RTMP协议，不仅支持更多的编码格式，而且能高效处理网络丢包、抖动和带宽波动等干扰，获得更低的延时以及流畅性，RTMP很少支持主备冗余模式，因此提供冗余方式的SRT传输流程在专业场景具有现实意义。

Description

一种基于SRT协议的冗余推流方法

技术领域

本发明涉及一种基于SRT协议的冗余推流方法，是一种电处理数字计算处理方法，是一种用于数字影像在网络中进行信息传播的方法。

背景技术

大型赛事的视频直播为了保证安全稳定，往往会有冗余推流的需求，即两台摄像机向同一个URL地址推一主一备的两路数码流，当主流链路出现故障，而备流还正常的情况下，能够无缝切换，以保证整个直播业务不受影响，实现安全播出。

现有的广电IP网络通常采用SMPTE ST 2022-7标准来保证数据传输的可靠性，该标准简单来说就是主备冗余，无缝切换。发送端采集到媒体数据后将数据包复制，通过两个独立的路径送给目的端。同理在互联网领域的直播应用中，一样可以延申该技术思路，在编码器推流阶段，采用冗余推流的方式来保证整个媒体数据在链路传输的可靠性。

然而SMPTE ST 2022-7标准主要是针对广电制作域内的传输无压缩媒体信号，带宽占用大且不支持基于压缩格式的互联网流传输应用。如何在互联网传输中实现基于压缩格式的冗余传输是一个需要解决的问题。

发明内容

为了克服现有技术的问题，本发明提出了一种基于SRT协议的冗余推流方法。所述的方法基于SRT替代传统的RTMP协议进行直播推拉流，除发挥SRT本身的低延迟特效，还提出一种冗余推流方法，在服务端进行故障检测和切换，进一步保障直播的稳定性。

本发明的目的是这样实现的：一种基于SRT协议的冗余推流方法，所述方法所使用的系统包括：依次连接推流端、服务端、拉流端，所述的推流端包括一主一备摄像机或一台摄像机、能够输出一路或两路编码的SRT编码器，负责链路冗余切换的所述服务端为能够输出SRT流的SRT云服务，所述拉流端为支持SRT协议的播放器或者SRT解码器，其特征在于，所述方法的步骤如下：

步骤1，编码器推流：编码器从摄像机获取视频信号，编码后使用两个推流端配置同一个推流URL地址，开启推流，推流到SRT云服务；

步骤2，读取数据：推流数据到达服务端后，服务端从媒体链路上读取SRT负载数据；

步骤3，判断主备状态：如果服务端检测到推流端出现异常，包括某一链路断开或长时间没有信号，则判断出现异常链路的推流主备状态，判定逻辑如下：

如果第一次推流，链路状态默认为主状态，第二次推流的链路为备状态；

一主一备两条链路中，当主链路编码器推流断开的时候，服务端删除该路链路，另一路备流需要改为主状态，参与数据转发，如果后续又有推流上来，新的链路设置为备状态；

主链路中指定时间内无数据交互，则会切换为备状态，同时把备链路修改为主状态，进行转发，相当于主备状态切换，相互切换后，如果指定时间内仍然无数据交互，则继续循环该过程；

步骤4，主流动作：异常端为主流，则查询该路推流URL是否有拉流请求，如果“是”则进入步骤5，如果“否”则进入步骤6；

步骤5，发送SRT负载数据：如果有拉流请求，则将步骤2读取的负载数据发送给各个播放端，如果没有拉流请求，则丢弃数据，准备下一次读取，返回步骤2；

步骤6，备流动作：异常端为备流，读取的数据丢弃后，准备下一次读取，返回步骤2；

步骤7，结束播放：SRT负载数据发送完成，主备推流均无异常，则结束播放；或者主备推流先后发生故障，并且经过多次主备切换尝试后，仍然长时间没有可用推流，则认为没有播放内容，结束播放。

进一步的，所述的推流和拉流基于NTP服务校时，包括如下子步骤：

子步骤1：推流时将NTP时间写入到码流序列中；

子步骤2：切换时播放器应用SRT得到的码流数据；

子步骤3：解析时间戳并进行分析，如果时间戳有回退，则判定为已过时数据，予以丢弃，丢弃直到大于上一次播放的时间戳数据，再继续播放。

本发明的优点和有益效果是：本发明利用服务端负责链路故障的切换，针对SRT冗余推流功能，服务自动调度一路正常的链路转发给拉流端，并且能够在其中一路推流断开的时候，自动切换推流链路，直到拉流端正常播放为止。SRT协议基于UDP协议，相比基于TCP的RTMP协议，不仅支持更多的编码格式，而且能高效处理网络丢包、抖动和带宽波动等干扰，获得更低的延时以及流畅性，RTMP很少支持主备冗余模式，因此提供冗余方式的SRT传输流程在专业场景具有现实意义。

附图说明

下面结合附图和实施例对本发明作进一步说明。

图1是本发明实施例一所述方法所使用的两台摄像机的系统示意图；

图2是本发明实施例一所述方法所使用的一台摄像机两路相同码率的系统示意图；

图3是本发明实施例一所述方法所使用的一台摄像机两路不同码率的系统示意图；

图4是本发明实施例一所述方法的流程图；

图5是本发明实施例一所述方法的切换逻辑判断示意图；

图6是本发明实施例二所述的校时原理示意图。

具体实施方式

实施例一：

本实施例是一种基于SRT协议的冗余推流方法。所述方法所使用的系统整体有三个角色，分别是推流端，服务端，拉流端。其中推流端可以是支持SRT协议的专用编码器或者是应用软件，拉流端是支持SRT协议的播放器或者专用的解码器。

本实施例根据不同的需要可以将推流端设置为一主一备两台摄像机，这两台摄像机分别连接各自的SRT编码器，在SRT云服务端之前形成两路主、备流，如图1所示。也可以采用一台摄像机，用一台摄像机连接一个编码的SRT编码器，使编码器输出一主一备的两路SRT编码输出。

图1主备摄像机使用同一个URL通过SRT协议推流到云端（接收端），SRT云服务（接收端）针对该URL的推流，根据接入顺序确定主备流身份，在用户侧应用SRT协议对该URL拉流，正常情况下播放SRT主流，当主摄像头SRT推流由于网络或者自身其他原因导致断开的时候，SRT云服务检测到主摄像头断流后，将内部调度SRT备流提供给应用拉流，如果主备摄像头拍摄的是同一个画面的话，拉流端的播放器一定程度上感觉不到推流端的摄像头发生过断开（实现无缝切换）。

这两路编码输出可以根据需要设置为两路相同码率的码流，如图2所示，也可以设置编码器输出的两路高低不同码率的码流，如图3所示。图2、图3是同一个摄像头采集的画面，经过编码器后复制成2路流（图2），也可以是同一个编码器编码两个不同规格的码流（图3），比如编码成一路1080P和一路720P，后面的流程和上述图1是一致的。因为两路码流出自同一个摄像头，故在拉流端播放来看，发送切换的时候，可以实现无缝切换。

所述的服务端负责链路冗余切换，服务端可以是能够输出SRT流的SRT云服务，也可以是专门设置的服务器集群。

所述拉流端为支持SRT协议的播放器或者SRT解码器。播放器或SRT解码器可以安装在OS或WIN等类似系统的PC机中，也可以是支持ios、Android或类似系统的手机或Pid等的手持设备中，或者是支持Linux或类似系统的服务器中。

本实施例所述方法的步骤如下，流程如图4所示：

步骤1，编码器推流：编码器从摄像机获取视频信号，编码后使用两个推流端配置同一个推流URL地址，开启推流，推流到SRT云服务。

为解决冗余问题，本步骤相对不同的系统采取不同的冗余方式，对于两台摄像机的冗余系统，采用的两套摄像机输出的一主一备两路SRT流，通过两个编码器编码后推出两路SRT服务；对于一个摄像机则可以采用一个编码器推出一主一备两路质量相同或质量高低搭配的两路SRT流。

步骤2，读取数据：推流数据到达服务端后，服务端从媒体链路上读取SRT负载数据；

SRT协议原则上并不限制上层的负载格式，但实际使用中大多遵循MPEG-TS标准。

需要说明的是，SRT服务区别于传统的流媒体服务会对数据进行缓存，SRT服务不缓存数据是基于如下两个原因：

i. SRT从设计上就用于低延迟媒体传输，服务器缓存数据会不可避免的带来额外延迟。

ii. SRT基于时间戳的数据包传送特性（Timestamp-based Packet Delivery），SRT内部本身管理数据缓存，上层只需要通过接口设置缓存时间即可，不需要再在应用层二次缓存。

步骤3，判断主备状态：如果服务端检测到推流端出现异常，包括某一链路断开或长时间没有信号，则判断出现异常链路的推流主备状态，判定逻辑如下，如图5所示：

如果先推流，链路状态默认为主状态，后续推流链路为备状态；

一主一备两条链路中，当主链路编码器推流断开的时候，服务端删除该路链路，另一路备流需要改为主状态，参与数据转发，如果后续又有推流上来，新的链路设置为备状态；

主链路中指定时间内无数据交互，则会切换为备状态，此时备链路正常，则把备链路修改为主状态，进行转发，相当于主备状态切换，相互切换后，如果指定时间内仍然无数据交互，则继续循环该过程。

在实际链路运行过程中，可能会出现两种情况产生链路的切换：一种是其中一个链路出现断路，另一种情况是链路指定时间内没有信号。为此本步骤设计了两套切换逻辑，一套是主链路断开则切换至备链路，而备链路断开则丢弃；另一套是主链路指定时间内没有信号，则切换至备链路，再次指定时间内没有切换则再次切换，以此来避免播放中拉流可能出现的断路。

所述的“长时间”的范围需要结合实际业务场景，例如低延时场景下，这个延时一般可以设定300-500毫秒；如果是要求高质量视频播放的场景，这个延时建议1-1.5秒，同时如果网络条件差、波动干扰剧烈的情况下，延时设置还需要酌情增大。这个时间的界定至不能一概而论，原因是在SRT数据链路建立的过程中，存在网络实际传输延时，还有业务上层根据实际应用场景设定的业务延时，需要在这两个延时之间协商确定最后的整体流程的延时（一般取大者），然后将这个时间值作为门限即可。实际应用中注意：

一、数据缓存通常只保留此延时时长数据，过晚或过早切换到备流，可能导致上层应用出现静帧（重复帧）或跳帧。

二、此时间值为根据业务及网络环境综合得出，涵盖了业务要求及抗网络波动因素，过早或过晚切到备流，冗余切换点处的时间特性与整个传输过程的时间属性有阶跳跃可能（无法保证无缝切换）

步骤4，主流动作：异常端为主流，则查询该路推流URL是否有拉流请求，如果“是”则进入步骤5，如果“否”则进入步骤6。

本步骤则是在切换过程中对主流的判断，判断根据是有没有拉流请求。

步骤5，发送SRT负载数据：如果有拉流请求，则将步骤2读取的负载数据发送给各个播放端，如果没有拉流请求，则丢弃数据，准备下一次读取，返回步骤2。

步骤6，备流动作：异常端为备流，读取的数据丢弃后，准备下一次读取，返回步骤2。

步骤7，结束播放：SRT负载数据发送完成，主备推流均无异常，则结束播放；或者主备推流先后发生故障，并且经过多次主备切换尝试后，仍然长时间没有可用推流，则认为没有播放内容，结束播放。

结束的步骤分为两种情况，一种是两路均无故障，主备两路输入端均无推流，则结束；还有一种情况是，主备两路均现有发生故障（故障顺序不限），多次主备切换尝试也不能获得可用推流，则结束。需要说明的是这里的“长时间”与步骤3中的“长时间”有相同的时间长度含义。

实施例二：

本实施例是上述实施例的改进，是上述实施例关于推流和拉流的细化，本实施例所述的推流和拉流基于NTP服务校时是这样的：推流和拉流基于NTP服务校时，在推流的时候把NTP时间写入到码流序列中，这样在发生切换的时候，播放器应用SRT得到的码流数据，解析出时间戳后进行分析，如果时间戳如果有回退，说明可能服务端发生了调度切换，此数据为已经过时的数据，丢弃直到大于上一次播放的时间戳，即可在数据层面实现精准的同步机制，如图6所示。

本实施例具体包括如下子步骤：

子步骤1：推流时将NTP时间写入到码流序列中。

子步骤2：切换时播放器应用SRT得到的码流数据。

子步骤3：解析时间戳并进行分析，如果时间戳有回退，则判定为已过时数据，予以丢弃，丢弃直到大于上一次播放的时间戳数据，再继续播放。

最后应说明的是，以上仅用以说明本发明的技术方案而非限制，尽管参照较佳布置方案对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案（比如所述方法所采用的系统、SRT编码的运用方式、步骤的先后顺序等）进行修改或者等同替换，而不脱离本发明技术方案的精神和范围。

Claims (2)

1.一种基于SRT协议的冗余推流方法，所述方法所使用的系统包括：依次连接推流端、服务端、拉流端，所述的推流端包括一主一备摄像机或一台摄像机、能够输出一路或两路编码的SRT编码器，负责链路冗余切换的所述服务端为能够输出SRT流的SRT云服务，所述拉流端为支持SRT协议的播放器或者SRT解码器，其特征在于，所述方法的步骤如下：

步骤1，编码器推流：编码器从摄像机获取视频信号，编码后使用两个推流端配置同一个推流URL地址，开启推流，推流到SRT云服务；

步骤2，读取数据：推流数据到达服务端后，服务端从媒体链路上读取SRT负载数据；

步骤3，判断主备状态：如果服务端检测到推流端出现异常，包括某一链路断开或长时间没有信号，则判断出现异常链路的推流主备状态，判定逻辑如下：

如果第一次推流，链路状态默认为主状态，第二次推流的链路为备状态；

一主一备两条链路中，当主链路编码器推流断开的时候，服务端删除该路链路，另一路备流需要改为主状态，参与数据转发，如果后续又有推流上来，新的链路设置为备状态；

主链路中指定时间内无数据交互，则会切换为备状态，同时把备链路修改为主状态，进行转发，相当于主备状态切换，相互切换后，如果指定时间内仍然无数据交互，则继续循环该过程；

步骤4，主流动作：异常端为主流，则查询该路推流URL是否有拉流请求，如果“是”则进入步骤5，如果“否”则进入步骤6；

步骤5，发送SRT负载数据：如果有拉流请求，则将步骤2读取的负载数据发送给各个播放端，如果没有拉流请求，则丢弃数据，准备下一次读取，返回步骤2；

步骤6，备流动作：异常端为备流，读取的数据丢弃后，准备下一次读取，返回步骤2；

步骤7，结束播放：SRT负载数据发送完成，主备推流均无异常，则结束播放；或者主备推流先后发生故障，并且经过多次主备切换尝试后，仍然长时间没有可用推流，则认为没有播放内容，结束播放。

2.根据权利要求1所述的方法，其特征在于，所述的推流和拉流基于NTP服务校时，包括如下子步骤：

子步骤1：推流时将NTP时间写入到码流序列中；

子步骤2：切换时播放器应用SRT得到的码流数据；

子步骤3：解析时间戳并进行分析，如果时间戳有回退，则判定为已过时数据，予以丢弃，丢弃直到大于上一次播放的时间戳数据，再继续播放。

Images