中国电信网络视频监控业务技术规范V2CU分册.docx

中国电信网络视频监控业务技术规范V2CU分册.docx

《中国电信网络视频监控业务技术规范V2CU分册.docx》由会员分享，可在线阅读，更多相关《中国电信网络视频监控业务技术规范V2CU分册.docx（35页珍藏版）》请在冰豆网上搜索。

中国电信网络视频监控业务技术规范V2CU分册

中国电信网络视频监控业务技术规范V2CU分册

中国电信网络视频监控业务

技术规范V2.0

CU分册〔送审稿〕

中国电信集团公司

中国电信股份上海研究院

2006年2月28日

内部资料，注意保密，未经同意，请勿翻印

文档信息

文档名称

文件编号

编制人

保密级别

修改过程

版本号

日期

作者

概述

评审过程

版本号

日期

评审者

概述

分发范畴

1.适用范畴

本规范要紧适用于客户端子系统的规划设计以及功能定义。

2.引用标准

见«中国电信网络视频监控业务技术规范-总体技术要求»

3.定义和缩略语

见«中国电信网络视频监控业务技术规范-总体技术要求»

4.系统结构

见«中国电信网络视频监控业务技术规范-总体技术要求»

5.CU客户端系统

5.1CU概述

CU是全球眼业务客户端监控应用系统的总称，是远程图像集中监控和爱护治理的应用平台，实现客户向中心服务的认证、多画面监控、报警监控以及客户监控设备以及权限的远程爱护等功能。

5.2CU应用架构

CU对前端设备的访问和操纵都需要通过中心服务系统交互实现。

CU和中心服务系统构成完整的服务器/客户应用架构，CU作为客户端应用。

5.3CU应用分类

CU实现需提供两种客户端治理应用系统：

1）电信客户端

针对电信运维部门使用，提供设备爱护〔添加、删除、划归〕、用户爱护、权限分配、系统爱护等功能。

2）企业客户端

针对电信全球眼业务客户使用，提供远程图象监控系统应用，包括提供电视墙应用解决方案。

5.4CU实现方式要求

1〕跨操作系统平台的支持

要求应用系统必须支持WINDOWS平台用户，建议支持LINUX平台用户。

2〕模块化设计

系统采纳模块化的结构设计思想，将数据业务〔视频数据、操纵命令、报警数据〕和应用逻辑〔监控应用〕分开。

提供视频解码插件和报警采集模块以方便二次开发应用

⏹音视频控件

音视频软解压控件是整个软件设计的核心，它嵌入在客户端应用软件中，应具备与中心服务〔CMS/VTDU〕或直截了当与PU的图像监控数据接收，图像显示、录像及云台操纵，I/O监控等差不多功能，并须向用户提供统一编程接口。

⏹报警模块

开关量报警、移动侦测报警信号等的采集。

3〕支持C/S、B/S两种电信/企业客户端应用系统

电信CU客户端和企业CU客户端系统能够考虑提供C/S结构的胖客户端系统，也能够考虑基于WEB方式的客户端系统，基于WEB方式的客户端系统需要在中心服务端提供相应的WEB服务应用。

6.CU功能要求

用于扫瞄和操纵远端视频及系统的设备。

包括实时、历史音视频的解码播放、用户治理界面、业务开通和治理界面、系统爱护界面、报警显示以及矩阵显示墙等。

6.1电信客户端

电信客户端是电信运维部门实施业务开通,设备治理以及权限治理的系统，为业务开展提供支持平台。

1〕设备治理：

⏹监控设备的系统添加爱护治理操作界面

⏹支持设备状态的查询，并提供系统设备〔如前端〕状态扫瞄、参数设置、初始化等操作界面

⏹支持平台间设备划归

2〕用户治理：

⏹用户组的爱护，能够实现一个企业的多个用户为一个组

⏹负责客户用户的受理，使用情形的统计

⏹提供用户帐号、口令等操纵界面

⏹提供多级区域、机构的设置界面

3〕权限设置：

⏹用户/用户组可访问的设备的列表信息爱护

⏹用户/用户组相应的操纵操作权限设置界面

4〕业务开通：

⏹提供开户、禁用/启用、注销等业务开通治理

5〕系统爱护：

⏹系统日志治理

⏹对中心各功能服务运行状态的监控

6〕巡检与校时：

⏹定时对前端设备进行巡检，当设备有故障时〔断线、无视频〕，产生告警信息

⏹能够统一对系统中的设备进行校时

7〕平台注册：

⏹对有跨平台访问的平台的信息注册

6.2企业客户端

企业CU客户端是面向业务客户的集中监控应用系统。

要紧功能应：

1〕登录认证：

提供登录验证界面，实现与CMS治理中心认证服务器的交互后进入系统。

2〕远程扫瞄：

⏹界面友好操作简单，通过治理中心服务器认证后，能自动以树形结构将扫瞄的前端设备和摄影头编排列出来，能够依照职能或业务或区域进行分组。

同时结合手工自由点播，能够专门直观、方便的查看权限许可的实时或非实时画面

⏹支持1、4、6、9、16画面切换监控

⏹支持对音频的实时接收，可选择静音/打开音频

⏹支持多画面轮巡，即系统应具备视频自动巡视功能，在可设定的间隔时刻内对所有的监控点进行图像巡检，参与轮巡的对象能够任意设定，包括不同监控点的图像、同一监控点内不同摄像机、同一摄像机的不同预置位等，轮巡间隔时刻可设置

⏹支持图象实时抓拍功能

⏹支持本地实时录象功能

⏹抓拍和录象路径可设置

⏹提供实时码率显示功能，显示与关闭提供开关操作

2〕提供电子地图功能

⏹支持多级电子地图〔可选择矢量图、三维立体图或图片格式的地图〕

⏹图片格式的地图的方式支持客户自动上载更新图片

⏹报警发生时，报警地点以醒目的标记闪耀在电子地图上，准确判定报警类型和地点

2〕远程操纵

⏹云台操纵〔上、下、左、右〕，包括自动巡航，预制位、灯光/雨刷功能的支持

⏹三可变镜头远近、大小、聚焦调剂

⏹摄象机色度、亮度、饱和度、对比度的实时操纵

3〕报警信息的接收以及报警联动：

⏹支持报警信息的接收。

报警信息经治理中心服务器转发，能够精确的将报警信息传送到客户机，同时具备语音、图像〔画面弹出〕的提示，并在本机生成报警日志，报警提示可依照设备一直发生作用，终止条件是操作人员人工进行干预

⏹报警类别，可能包括消防报警、防盗报警、防火报警、门禁报警、非法闯入及画面异动报警、图像设备故障报警以及通过温度、湿度探测器发出报警信息等

⏹支持红外、光敏报警，当发生报警时，监控中心能自动进行存盘录像，并自动在地理图上提示报警位置及类型

⏹当发生报警时，能联动相关设备，如启动现场照明、警笛等，相关设备启动后，应在设定的时刻内自动关闭，且现场照明在白天〔时刻段可设〕可不打开

⏹报警信息应该和录像数据相结合，可由报警信息检索回放相应的图像录像

⏹支持报警信息的查询，并提供报警信息查询和扫瞄窗口

⏹支持开关量/移动侦测的布防、撤防的设置

⏹画面移动侦测报警的参数可设置

⏹支持联动策略的配置〔支持联动输出报警设备/灯光打开/录象开启〕

⏹对移动目标具有自动跟踪功能，该功能应能随时启动关闭〔可选〕

4〕支持录象操纵

⏹支持实时本地录象

⏹可设置录象储备方式〔前端录象、中心录象、本地录象〕，并配置其IP地址

⏹录象的远程检索回放、下载本地回放

5〕远程操作：

⏹对指定的远端PU进行远程操作，如PU的参数设置、通道参数的设置、串口参数的配置及报警参数的设置、查询

⏹视频画面要求可叠加反映该段视频时刻、地点等信息的字幕，选择实现字母位置可调

6〕系统功能

⏹支持键盘快快捷键云台操纵（建议）

快捷键

功能

TAB

焦点视频窗口切换

空格

焦点视频窗口最大化/回复切换

方向键

焦点摄像头云台转动

Home/End

焦点摄像头镜头放大/缩小

F11

全屏

⏹锁定系统功能

〝锁定系统〞，确实是将系统操纵权限降为最低，使当前系统处于锁定状态，只提供最差不多的监视功能，包括禁用关闭系统。

〝解除锁定〞选项是指，在锁定系统后，要重新复原对系统的操纵权，必须第一解除锁定。

⏹系统日志

支持系统日志的查询，并提供当前系统日志的查询和扫瞄窗口。

7〕辅助功能（可选）

⏹操作杆功能

⏹辅助键盘操纵

8〕电视墙的操纵〔可选〕

电视墙是由多个监视器组成的，每个监视器对应一路视频输出〔比如对应一个解码器的视频输出〕，这些关系是固定的。

能够从PU列表中把某个PU拖到电视墙上，并能对那个PU的图像操纵，如开始播放和停止播放；还能够操纵该PU的云镜。

支持手动调看、序列切换、群组序列调看、群组序列切换功能：

⏹通过中文名称列表方式或电子地图图标方式手动在任意监视器上切换系统中任一个摄像机图像

⏹在任一个监视器上调用任一个序列进行自动切换显示

⏹在多个监视器一次性同时调看任一个编组序列的所有摄像机图像

⏹将多个编组序列同时在多个监视器上进行群组的自动切换显示

⏹切换间隔时刻可调〔8-99秒〕

9〕与PU双向语音交流

能与自己权限许可的前端设备之间进行双向的实时语音对讲，同时具有对前端设备分组进行语音广播。

10〕多画面合成的操纵〔可选〕

支持对用户选择的多个PU视频流合成包括多个画面的一路视频流。

11〕解码器/解码矩阵的治理功能〔可选〕

⏹对中心一个或多个解码器/解码矩阵的配置治理；其IP地址、通道数、每个通道对应的默认的显示图象的IP地址、通道号配置信息的储备

⏹每个解码器通道对应的电视墙信息的储备

⏹每个监视器可显示多个通道的信息〔IP〕配置治理

⏹是否轮跳配置治理。

轮跳策略

⏹可设定每个解码器/解码矩阵报警时输出图象的通道；当收到报警联动输出信息时将指定图象在设定的通道输出

⏹可设定每个解码器/解码矩阵音频的通道选择和操纵

⏹将网络中任意假设干个摄像机编组成假设干个切换序列

12〕客户自助治理

可由客户治理员自助进行相应的治理如，配置治理、权限治理、操作员治理、告警治理、日志治理等。

13〕图像辨识功能

通过图像辨识处理实现行业的智能辨识需要，如交通系统和交警系统需要的车牌辨识功能。

7.软件的要求

7.1差不多要求

1）要求软件采纳分层的模块化结构，模块之间的通信应按规定接口进行。

任何一层的任何一个模块的爱护和更新以及新模块的追加都不阻碍其它模块。

2）系统参数、用户资料与处理程序应有相对的独立性。

用户资料的任何变更都不应引起运行版本程序的变更。

处理程序应与系统参数、用户资料相适应。

3）软件应有容错能力，一样的软件故障不应引起各类严峻的系统再激活。

4）软件设计应有防护性能，某一软件模块内的软件错误应限制在本模块内，而不应造成其它软件模块的错误。

5）应具有软件运行故障的监视功能。

一旦软件显现死循环等重大故障，应能自动再激活，并能出实时故障报告信息。

6）系统中所有涉及到时刻的信息和资料其年份部分采纳带纪元表示法。

7）软件具有详细、完善、灵活的业务、用户等资料的统计、分析、推测能力。

8）系统中使用的协议不显现在互联网中目前不支持的协议现象。

7.2软件设计要求

1）应用软件应采纳分层次的体系结构，以便于系统的爱护和扩展；

2）应用软件应能依照用户规模的不同支持集中处理模式和分布式处理；

3）应用软件应具有专门好的开放性，以便于与其它应用系统的连接；系统应提供完整的二次开发工具及使用说明，便于进行客户化工作；

4）应用软件应具有专门好的可移植性，支持多种操作系统，并能移植到不同厂家的硬件平台上运行；

5）应用软件应能适应多种大型数据库系统，例如MSSQL,Oracle、Sybase等；

6）系统的运行应是安全、可靠的，具备完善的、分级的操作/访问权限操纵；

7）系统应具有资料备份及灾难复原功能。

8.接口协议

8.1接口通信协议结构

8.1.1MessageHeader:

字段名

长度（BYTE）

描述

0xFFFF

2

消息包标志位

Version

2

协议版本号：

前为大版本、后为小版本

MessageType

2

消息类型ENUM_MSG_TYPE

MessageLength

2

整个消息包长度，不包含MessageType和MessageLength域

SequenceNumber

2

包序号〔从启动开始依次递增，要求与响应保持一致；到达极限后归零重新开始〕

Session_ID

4

会话ID〔通过PuId、UserId应该能够查询到会话SessionID〕

Source_ID

15

通讯源设备/用户ID，编号规那么见«系统编码部分»。

Destination_ID

15

通讯目的设备/用户ID，编号规那么见«系统编码部分»。

Reserved

4

保留字段

Authenticator

4

对整个数据包的完整性校验值，采纳crc32的算法来运算校验值.

〔MessageType+MessageLength+Version+SequenceNumber＋SessionID＋SourceCMSID＋SourceID＋DestinationID+Reserved+IE信息+……〕

8.1.2Message:

消息格式：

1.每个消息由一个消息头与0个〔承诺为空〕或多个IE组成。

IE，即InformationElement信息单元。

2.以上提到的多字节数据均以小边模式存放（先低字节后高字节）。

字段名

长度（BYTE）

描述

MessageHeader

56

消息包头，见下面MessageHeader定义

InformationElement

*

信息单元

InformationElement

*

信息单元

……

信息单元

8.1.3InformationElement（IE）:

字段名

长度（BYTE）

描述

IEType

2

IE类型ENUM_IE_TYPE

IELength

2

IE长度，包含IEType和IELength域

IEContent

*

依照具体IEType不同

8.1.4IE结构的差不多数据类型定义

ie结构由差不多的数据类型定义，描述如下：

字段类型

长度（byte）

描述

BYTE

1

单字节

WORD

2

双字节

DWORD

4

四字节

char

协议具体指定

定长字符串，’\0’不表示终止符

nchar

协议具体指定

带长度的不定长字符串,’\0’表示终止

nchar表示如下：

假如字符串长度小于255，起始第一个字节为字符串长度；

假如字符串长度大于等于255，起始第一个字节为专门标记0xff，后续三个字节为实际长度；字符串最大长度为65535字节。

实际有效字符串可能是以下两种情形

1．最后一个字节是’\0’，那么以第一个显现的’\0’表示终止符，尾部必须全填’\0’;

2．最后一个字节非’\0’，那么往常导长度为准;不做要求

8.2CU与VTDU的通信协议

8.2.1接口定义对象

CU与VTDU接口规范的对象要紧：

⏹音视频数据流格式

⏹音视频数据要求/响应消息格式

8.2.2音视频数据流格式

媒体封装格式

报头标志2bytes

13bytes

Variable

FLAG

MediaStreamHeader

MediaBuf

说明：

〔1〕FLAG=0xfffe代表媒体音视频数据包；

FLAG=0xfffd代表媒体信令包；

媒体头字节总数：

15字节。

〔2〕在传输实时视频流时，需要在每一帧的多媒体数据前加一个视频流头，格式如下：

MediaStreamHeader〔13字节〕

1bytes

2bytes

2bytes

4bytes

4bytes

〔Flag1〕

〔Flag2〕

PacketLength

PacketSequence

SessionID

PacketLength：

整个包的大小〔包括头部〕。

PacketLength＝14＋净荷长度；

Flag1:

MediaType:

b7b6表示该包内的媒体类型。

00：

视频01：

音频10：

音视频；

I/B/P:

b1b0表示当前数据包所在的帧类型。

I:

01,B:

10,P:

11。

关于没有区分的填0。

其余各位保留位；

Flag2:

保留字节

（2）；高字节：

厂家代号，低字节：

该厂家的播放器版本号；这2个字节必须是中国电信统一派发并登记才能识别和实现互相访问；

PacketSequence：

包的序列号。

2个字节，每经网络发送一次加1，达到最大值65535后重新从0开始计数；

SessionID:

SessionID猎取连接的相关信息，由前端设备连接CMS时分派。

〔3〕MediaBuf：

音视频数据包的净荷数据，其中的格式由不同按照优化能在中国电信宽带网的网络中进行高效传输。

在传输实时视频流时，需要在每一帧的多媒体数据前加那个地点统一定义的视频流头格式。

其中的净荷数据是各个厂家具体的视音频传输协议。

8.2.3视频数据流传输方式

8.2.3.1UDP单播传输方式

当采纳UDP单播方式传输时，VTDU/CU直截了当发送UDP单播通信端口查询消息，PU将UDP单播地址和端口发给VTDU/CU〔客户端〕，或者由CMS将查询的端口直截了当返回给VTDU/CU。

收到该消息后，向该端口发送单播要求消息。

该方式数据实时性强，但数据传输的可靠性没有保证，存在网络丢包的可能，适合在局域网环境下使用。

8.2.3.2UDP组播传输方式：

当采纳UDP组播方式传输时，PU将数据向一个组播地址传送。

VTDU组播端口要求时，返回信息中包含组播地址和端口，当收到那个组播地址和端口号后，VTDU发送组播要求，加入组播地址收取视频数据。

组播地址和端口在PU上可配置或按照最后两位地址默认为设备IP地址的最后两位。

组播方式在多个相同视频通道的要求时能够有效节约带宽，它是基于UDP，存在网络丢包问题。

8.2.3.3TCP传输方式

TCP传输方式是一种可靠的传输方式，采纳这种方式要紧使用长连接模式。

这种传输方式不存在网络丢包的可能。

8.2.3.4RTP/RTCP传输方式

实时传输协议〔Real-timeTransportProtocol，PRT〕是在Internet上处理多媒体数据流的一种网络协议，利用它能够在一对一〔unicast，单播〕或者一对多〔multicast，多播〕的网络环境中实现传流媒体数据的实时传输，RTP和RTCP结合使用，为按序传输数据包提供可靠的保证以及提供流量操纵和拥塞操纵。

8.2.4通信方式

客户与服务器对应关系：

客户端

服务器端

VTDV

PU

CU

PU

CU

VTDU

服务器端各项服务默认消息端口定义〔待讨论〕

端口号

应用

7000

UDP〔单播〕数据要求服务端口

7001

UDP〔组播〕数据要求服务端口

8000

TCP数据要求服务端口

9000

RTP数据要求服务端口

8.2.5视频要求消息接口

8.2.5.1消息流

要紧消息流：

8.2.5.2视频数据要求消息

MessageType:

MSG_START_VIDEO_REQ

Direction:

CU→VTDU

IE

M/O

描述

IE_OPEN_VIDEO

M

IE_NETLINK

O

简要描述：

客户端向服务器〔PU/VTDU〕发送的要求音视频数据的要求，服务器同意到该要求后，爱护用户表信息，并发送目前编码设备的一些关键编解码配置给客户端，然后发送音视频数据流到客户端。

打开视频IE_OPEN_VIDEO

字段名

类型

长度

描述

Type

WORD

2B

IE_OPEN_VIDEO

Length

WORD

2B

该IE类型的结构长度

PUID

Char

15

设备ID

ChannelNo

WORD

2

音视频数据源所在的通道号

MeidaType

BYTE

1

媒体数据类型

0：

音频数据

1：

视频数据

2：

音频＋视频数据

TransMode

BYTE

1

要求PU对音视频数据的传输方式

0：

TCP

1：

UDP单播

2：

组播

3:

：

RTP….

ReqReason

BYTE

1

要求音视频数据的缘故

0：

一样的要求

1：

因报警要求

….

网络连接IE_NETLINK

字段名

类型

长度〔B〕

描述

Type

WORD

2

=IE_NETLINK〔301〕

Length

WORD

2

该IE类型的结构长度

AddType

BYTE

1

IPV4=1;IPV6=2;DN=3

AddRESPs

nChar

地址可为IP或DN

Port

WORD

2

端口

ConnectType

BYTE

1

网络接入连接方式：

1公网/0私网

TransType

BYTE

1

视频数据传输方式

＝1：

TCP

＝2：

UDP

＝3：

RTP

＝4：

Multicast〔多播地址和端口在视频通道参数IE里头指定〕

8.2.5.3视频要求回应消息

MessageType:

MSG_START_VIDEO_ACK

Direction：

PU→VTDU，PU→CU，VTDU→CU

IE

M/O

描述

IE_OPEN_VIDEO_ACK

M

音视频要求回应

简要描述：

对MSG_START_VIDEO_REQ的回应，要紧是发送音视频流头信息到客户端解码插件；

打开视频响应IE_OPEN_VIDEO_ACK

字段名

类型

长度〔B〕

描述

Type

WORD

2

=IE_OPEN_VIDEO_ACK

Length

WORD

2

该IE类型的结构长度

MeidiaType

BYTE

1

媒体数据类型

0：

音频数据

1：

视频数据

2：

音频＋视频数据

VidEncode

BYTE

1

视频编码算法

0：

MPEG-4

1：

MPEG-2

2：

MPEG-1

3：

H.263

4：

MPEG-4

3：

H.264

….

VidWidth

WORD

2

视频数据象素宽度

VidHight

WORD

2

视频数据象素高度

VidFormat

BYTE

1

视频制式

0：

PAL

1：

NTSC

VidFrameRate

BYTE

1

视频输出具体帧数〔PAL制式0-25，NTSC制式0-30〕

AudEncode

BYTE

音频编码算法

0：

MPEG1L2

1：

u-LawPCM

2：

ADPCM

音频编码算法

0：

MPEG1L2

1：

u-LawPCM

2：

ADPCM

AudSamping

BYTE

1

音频采样频率〔采样频率依照音频编码算法的不同，其值的含义也有不同说明〕。

u-LawPCM与ADPCM编码算法：

0：

8KHZ

1：

48KHZ

AudBitRate

BYTE

1s

音频输出Bit率〔依照不同的音频编码算法，取值的含义不同〕。

u-LawPCM编码算法：

0：

64Kbps

ADPCM编码算法：

0：

32Kbps

AudTrack

BYTE

1

音频声道模式

0：

立体声

1：

单声道

DeviceTypeIndex

WORD

2

唯独设备类型索引码，用于解码器调用，索引码需向中国电信申请。