CN103220505A - 一种码流发送、处理和控制的方法 - Google Patents

Abstract

本发明提供一种解决丢包的码流处理方法，该方法包括：解码端判断是否存在因多链路捆绑而导致的丢包状况，如果是，将该丢包状况信息通知监控管理服务器，监控管理服务器接收该丢包状况信息，通知码流发送端和解码端对原始码流需执行拆分合并的处理。码流发送端确定原始码流需执行拆分合并的处理后，将原始码流拆分成n条码流，发送拆分后的n条码流。解码端判断接收的码流是否是拆分后的n条码流，如果是对拆分后的n条码流进行合并解码。本发明方案解决了因链路捆绑而导致视频数据丢包问题。该方案实现简单灵活，无需以降低图像清晰度为代价来降低视频码流大小。

Description

一种码流发送、处理和控制的方法

技术领域

本发明涉及视频监控领域，尤其涉及链路捆绑情况下码流的发送、处理和控制处理方法。

背景技术

随着监控大联网的推进，视频监控的应用范围也不在局限于一个园区范围里，有的时候需要通过广域网把几个分支机构和总部的监控都互联起来，这就使得越来越多的监控视频数据穿越广域网络。如图1所示的监控组网，场所1和场所2的监控数据通过因特网传输给监控中心。

大范围的监控场所网络互联促使大流量的视频监控数据必须走运营商提供的网络，但是运营商网络形态各异，比如同样8M的带宽，有可能是以100M的太网链路限速成8M这种方式提供的，也有可能是采用4个E1链路进行捆绑而成的8M，如下图2所示。但是链路捆绑会带来一个问题，有可能导致实时的视频监控数据经过广域网传输后被丢包。具体原因如下：

网络设备，如路由器，对数据报文的转发方式有两种，逐包转包和逐流转发模式。逐包转发模式即每个数据包可能走不同的链路。如果转发过程有负载均衡机制，假设此时数据报文要走由4个E1链路捆绑的通道，则第一个数据报文走第一个E1数据链路，第二个数据报文走第二个E1数据链路，第三个数据报文走第三个E1数据链路，依次类推。而逐流转发模式，一般是通过五元组（源IP地址、目的IP地址、源端口号、目的端口号、协议号）来区分一条流的，如需要转发的数据报文的五元组都一样，那么对系统而言就是同一条流，默认是走同一条链路进行转发。

对网络设备而言，逐流转发模式比逐包转发模式效率更高，不需要对每个数据报文进行匹配和运算。高端的网络设备都支持逐包和逐流这两种模式的切换，默认是逐流转发。中低端网络设备的都仅支持逐流转发模式。

假如一路视频监控流的码率大小是3M，需要通过4个E1的链路捆绑的广域网转发到远端的解码端。而网络设备又是逐流转发的，那么就会出现一个问题，即3M的视频码流无法通过4个E1的捆绑链路进行转发。因为一条流的码率大小是3M，根据逐流的转发规则只会走一个2.048M的E1链路通道，视频数据会存在丢包，导致监控业务不可用。

目前解决的办法是降低视频数据的码率，比如降低到小于2.048M即可。但是降低码率的方法显然损失了部分视频数据，可能对用户观看视频数据存在一定的影响。

发明内容

有鉴于此，本发明提供一种码流发送控制方法，该方法应用于监控管理服务器，该方法包括如下步骤：A、接收解码端反馈的因多链路捆绑而导致的丢包状况信息；B、通知码流发送端和解码端对原始码流执行拆分合并处理。

优选地，该丢包状况信息中包括不丢包阈值。

优选地，该方法进一步包括：在码流发送端和解码端之间传递拆分后的码流的源端口号或目的端口号信息。

对应的，本发明还提供一种码流发送方法，该方法应用于码流发送端，该方法包括如下步骤：A、确定原始码流需执行拆分合并处理；B、将原始码流拆分成n条码流；C、发送拆分后的n条码流。

优选地，n不小于编码码率与不丢包阈值的商向上取整所得值。

优选地，将原始码流拆分成n条码流具体为：将原始码流的源端口号更改为n个不同的源端口号而形成n条码流；或者，将原始码流的目的端口号更改为n个不同的目的端口号而形成n条码流。

对应地，本发明还提供一种丢包后的码流处理方法，该方法应用于解码端，该方法包括：判断是否存在因多链路捆绑而导致的丢包状况，如果是，将该丢包状况信息通知监控管理服务器；确定原始码流需执行拆分合并处理；判断接收到的码流是否是拆分后的n条码流；如果是对该n条码流进行合并解码。

优选地，所述判断是否存在因多链路捆绑而导致的丢包状况具体为：判断是否丢包，如果是，统计接收到的码率大小，并且判断该码率大小是否稳定，如果是，则判定存在因多链路捆绑而导致的丢包状况。

优选地，判断接收到的码流是否是拆分后的n条码流具体为：如果是码流拆分规则为变更码流的源端口号，则根据源端口号信息来判断接收的码流是否为所述拆分后的n条码流；如果码流拆分规则为变更码流的目的端口号，则根据目的端口号信息来判断接收的码流是否为所述拆分后的n条码流。

本发明方案解决了因链路捆绑而导致视频数据丢包问题。该方案实现简单灵活，无需以降低图像清晰度为代价来降低视频码流大小。

附图说明

图1是现有的一种监控网络图。

图2是现有的链路捆绑示意图。

图3是本发明实施方法流程图。

具体实施方式

以下结合具体实施方式来阐述本发明的方案。

一般的监控系统包括：监控管理服务器（VM）、监控前端设备（网络摄像机IPC或编码器EC）、媒体流交换服务器（MS）以及解码端设备等。要实现大流量的视频数据在具有链路捆绑的广域网上传输，需要监控系统中的各监控设备协同工作来完成此任务。以下结合图3来描述各监控设备执行的具体操作。

步骤S1、解码端判断是否存在因多链路捆绑而导致的丢包状况，如果是，将该丢包状况信息通知监控管理服务器；如果否，则流程结束。

解码端对于是否丢包的判断属于现有技术。本实施例在出现丢包时需要进一步判断该丢包是否由多链路捆绑引起，所以解码端需要统计接收到的码率大小，如果码率大小趋于稳定，则判定存在因多链路捆绑而导致的丢包状况。

解码端确认当前因多链路捆绑而导致的丢包状况后，将该丢包状况信息通知监控管理服务器。解码端可以进一步将丢包状态下统计的稳定的码率大小告知监控管理服务器，由监控管理服务器根据该码率大小指导监控系统设备执行相关操作。

步骤S2、监控管理服务器接收解码端反馈的因多链路捆绑而导致的丢包状况信息。

该丢包状况信息可以包括丢包状态下统计的稳定的码率大小。

步骤S3、监控管理服务器通知码流发送端和解码端对原始码流执行拆分合并处理。

如果是监控前端设备直接将视频码流发送给解码端的话，监控管理服务器通知监控前端设备进行码流拆分；如果由MS来转发码流的话，监控管理服务器通知MS进行码流的拆分。

具体将当前的码流拆分成几条新的子码流可以根据经验预先设定一个具体的值。当然更为灵活的一种做法为由监控管理服务器进行计算获得拆分的条数。具体计算办法为：将该视频流的编码码率除以不丢包阈值所得的商向上取整，得到的结果即为拆分的子码流的条数的最小值，即拆分后的码流的条数只要不小于该向上取整所得的值。这里，不丢包阈值通过为解码端在丢包状态下统计的稳定的码率大小（当然也可以设定得更小一些）。视频流的编码码率通常在监控前端设备向监控管理服务器注册的时候会携带该信息，所以监控管理服务器上保存有各监控前端设备的编码码率。

当然，也可以不由监控管理服务器来计算拆分的子码流的条数，而只是将不丢包阈值告知监控前端设备或者MS。由监控前端设备或者MS来计算要拆分的码流条数。

步骤S4、发送端确定原始码流需执行拆分合并处理后，将原始码流拆分成n条码流。

确定原始码流需执行拆分合并处理是码流发送端进行码流拆分的触发条件。将原始码流拆分成n条码流可以采用以下方法：将原始码流的源端口号更改为n个不同的源端口号而形成n条码流，即原始流的源IP地址、目的IP地址、目的端口号、协议号等四项不变，仅改变源端口号，变为多条流发送出去。这样网络设备就会将这多条流从不同的捆绑链路发送出去，从而解决现有技术中的丢包问题。一种简单有效的方法就是对源端口号进行依次递增。

步骤S5、监控管理服务器告知解码端拆分后的n条码流的源端口号信息。

为了解决不丢包的问题而对原始码流进行了拆分。在解码的时候，则需要把拆分后的码流进行合并后再进行解码。

所以码流发送端在通过改变源端口号的方式对码流进行拆分后，将拆分后的各条码流的源端口号告知监控管理服务器，由监控管理服务器通知解码端对这些源端口号的流进行合并解码。

步骤S6、解码端在确定原始码流需执行拆分合并的处理后，判断接收到的码流是否是拆分后的n条码流；如果是对该n条码流进行合并解码。

由于监控管理服务器告知解码端拆分的码流的各源端口号信息，所以就将这些源端口的码流进行合并后再解码。当然，目的端口号还是之前码流发送端和解码端协商的端口号，而源IP地址、目的IP地址、协议号和未拆分之前的码流是一致的，解码端在收流的时候也是要区分这些信息的。

关于将原始码流进行拆分除了上述源端口号变更的方式外，还可以是目的端口号变更的方式，即将原始码流的目的端口号更改为n个不同的目的端口号而形成n条码流。具体地，可以由监控管理服务器将需要进行码流拆分合并的信息分别告知码流发送端和解码端，解码端可以将拆分的流使用的n个目的端口号先通知监控管理服务器，监控管理服务器将这n个目的端口号信息告知码流发送端，码流发送端在拆分码流的时候，不改变原始码流的源IP地址、源端口号、目的IP地址、协议号，仅将目的端口号更改为这n个目的端口号而形成n条码流，并进行发送。解码端判断接收的码流是否是这些目的端口号的码流，如果是就执行合并解码的处理。

类似的，还可以采用既改变源端口号又改变目的端口号的方式，具体实现方式可以参照上文描述。

网络设备对一条流在哪条链路上发送一般采用hash算法进行确定，如果hash算法不是特别理想的话，会出现按照上面计算获得的拆流条数（即采用n等于编码码率除以丢包阈值的商向上取整的值）去拆流的话，可能还会存在丢包的状况，那么解码端通过通知监控管理服务器，再由监控管理服务器继续通知码流发送端进行码流拆分的操作，即在原先拆分的n条码流的基础上增加拆分的码流条数直至拆分的多条码流能分散到不同的捆绑链路为止，这样就不会再出现丢包的现象。

如果还有新的解码端也需要同时查看码流发送端发送的实况视频流，监控管理服务器接收到解码端的请求后，发现要查看的视频流是步骤S1中探测到的需要通过捆绑链路发送的视频流，再进一步判断该视频流到达该新的解码端是否也需要经过该捆绑链路（可以通过目的IP地址进行判断），如果是，就通知该解码端，对拆分后的码流进行合并解码，具体方法同上。如果监控管理服务器无法判断是否新的解码端在接收所点播的该视频流时是否需要经过捆绑链路，则该新的解码端还可以采用同样的方法来进行是否存储捆绑链路的判断，从而通知监控管理服务器。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (10)

1.一种码流发送控制方法，该方法应用于监控管理服务器，其特征在于，该方法包括如下步骤：

A、接收解码端反馈的因多链路捆绑而导致的丢包状况信息；

B、通知码流发送端和解码端对原始码流执行拆分合并的处理。

2.如权利要求1所述的方法，其特征在于，所述丢包状况信息中包括不丢包阈值。

3.如权利要求1所述的方法，其特征在于，所述方法进一步包括：在码流发送端和解码端之间传递拆分后的码流的源端口号或目的端口号信息。

4.一种码流发送方法，该方法应用于码流发送端，其特征在于，该方法包括如下步骤：

A、确定原始码流需执行拆分合并处理；

B、将原始码流拆分成n条码流；

C、发送拆分后的n条码流。

5.如权利要求4所述的方法，其特征在于，n不小于编码码率与不丢包阈值的商向上取整所得值。

6.如权利要求4所述的方法，其特征在于，将原始码流拆分成n条码流具体为：

将原始码流的源端口号更改为n个不同的源端口号而形成n条码流；或者，

将原始码流的目的端口号更改为n个不同的目的端口号而形成n条码流。

7.一种丢包后的码流处理方法，该方法应用于解码端，其特征在于，该方法包括：

判断是否存在因多链路捆绑而导致的丢包状况，如果是，将该丢包状况信息通知监控管理服务器；

确定原始码流需执行拆分合并处理；

判断接收到的码流是否是拆分后的n条码流；如果是对该n条码流进行合并解码。

8.如权利要求7所述的方法，其特征在于，所述判断是否存在因多链路捆绑而导致的丢包状况具体为：判断是否丢包，如果是，统计接收到的码率大小，并且判断该码率大小是否稳定，如果是，则判定存在因多链路捆绑而导致的丢包状况。

9.如权利要求8所述的方法，其特征在于，所述丢包状态信息包括不丢包阈值，该不丢包阈值为丢包状态下统计的稳定的码率大小。

10.如权利要求7所述的方法，其特征在于，判断接收到的码流是否是拆分后的n条码流具体为：如果是码流拆分规则为变更码流的源端口号，则根据源端口号信息来判断接收的码流是否为所述拆分后的n条码流；如果码流拆分规则为变更码流的目的端口号，则根据目的端口号信息来判断接收的码流是否为所述拆分后的n条码流。

Images