一种OSD叠加管理、执行方法及装置与流程

本发明涉及视频监控技术领域，尤其涉及一种OSD叠加管理、执行方法及装置。

背景技术：
随着智慧城市等监控应用的推广，IP监控正在快速应用到各个行业及公共区域。对于监控点来说，其可能会受到多个不同组织的管理。对于各个组织而言，其对监控视频画面上的OSD（OnScreenDisplay，在屏显示）信息的需求是不尽相同的。举例来说，从位于省级域的省级用户的角度来说，其可能希望视频画面上显示出市、县、乡三级OSD信息。对于位于市级域的市级用户而言，其可能仅仅希望显示县、乡两级OSD信息。事实上这样的需求还有很多种，比如说超市中的监控摄像机所采集到的视频画面，对于超市自身使用而言，其可能希望OSD信息是一个具体的位置，比如说A区东南角，而对于有权限使用该摄像机的部门，如公安部门而言，其可能需要的是XX超市A区东南角。目前对于这样的需求，现有技术通常需要进行复杂的手工配置才能实现，对于大型的监控应用而言，比如平安工程，这样的方式无疑是难以被用户接受的。

技术实现要素：
有鉴于此，本发明提供一种OSD叠加管理装置，应用于监控系统的管理服务器上，其中该监控系统还包括转发服务器、视频数据源端以及视频数据请求端，该装置包括：请求处理单元、应答处理单元以及OSD控制单元；其中：请求处理单元，用于在从视频数据请求端一侧接收到视频数据请求时，向视频数据源端方向发送视频数据请求以将来自源端的视频数据调度给指定接收者；应答处理单元，用于在从视频数据源端一侧接收到与该视频数据请求对应的确认应答后，继续向请求端方向发送确认应答；OSD控制单元，用于在应答处理单元接收到确认应答后且指定接收者属于本域时，向该指定接收者发送OSD叠加控制指令；其中该叠加控制指令中携带有与该视频数据对应的需要叠加的OSD信息，其中该需要叠加OSD信息至少包括本域OSD信息。本发明还提供一种OSD叠加执行装置，应用于监控系统中的转发服务器上，其中该监控系统还包括管理服务器、视频数据源端以及视频数据请求端，该装置包括OSD记录单元以及转发执行单元；其中：OSD记录单元，用于在从管理服务器接收到OSD叠加控制指令时，获取其中携带的需要叠加的OSD信息；转发执行单元，用于将需要叠加的OSD信息插入视频数据流中然后向请求端一侧发送。本发明还提供一种OSD叠加管理方法，应用于监控系统的管理服务器上，其中该监控系统还包括转发服务器、视频数据源端以及视频数据请求端，该方法包括以下步骤：步骤A、在从视频数据请求端一侧接收到视频数据请求时，向视频数据源端方向发送视频数据请求以将来自源端的视频数据调度给指定接收者；步骤B、在从视频数据源端一侧接收到与该视频数据请求对应的确认应答后，继续向请求端方向发送确认应答；步骤C、在接收到确认应答后且指定接收者属于本域时，向该指定接收者发送OSD叠加控制指令；其中该叠加控制指令中携带有与该视频数据对应的需要叠加的OSD信息，其中该需要叠加OSD信息至少包括本域OSD信息。本发明还一种OSD叠加执行方法，应用于监控系统中的转发服务器上，其中该监控系统还包括管理服务器、视频数据源端以及视频数据请求端，该方法包括：步骤I、在从管理服务器接收到OSD叠加控制指令时，获取其中携带的需要叠加的OSD信息；步骤II、将需要叠加的OSD信息插入视频数据流中然后向请求端一侧发送。相对于现有技术而言，本发明能够允许用户快捷方便地得到更为完整的OSD信息，对于大型监控系统的意义显著，而且从实施角度来说，对整个监控系统相关设备的改造简单，实施成本低。附图说明图1是一种典型的多域监控系统的架构图。图2是本发明一种实施方式中OSD叠加管理装置以及OSD叠加执行装置的逻辑结构及相应硬件环境的示意图。图3是本发明一种实施方式中OSD叠加管理方法的处理流程图。图4是本发明一种实施方式中OSD叠加执行方法的处理流程图。图5是本发明一种实施方式中OSD叠加管理及执行的原理示意图。图6a是本发明一种实施方式中用使用RTP封装的报文结构示意图。图6b是本发明一种实施方式中RTP封装下OSD信息封装格式示意图。图7是本发明一种实施方式中用使用PS封装的报文结构示意图。图8是本发明一种实施方式中用使用TS封装的报文结构示意图。图9是本发明一种实施方式中OSD信息封装格式的示意图。具体实施方式目前大型监控系统通常为多域监控系统，每个域可以理解为一个更小规模的监控系统，这些更小的监控系统在业务应用层面实现互联形成大型的监控系统。请参考图1，一个大型监控系统中包括了域1、域2一直到域N。以域1为例，从业务应用层面上来说，一个配置比较完整的域通常包括通过网络连接在一起的管理服务器、回放服务器、存储服务器、转发服务器、前端设备以及后端设备。前端设备通常是一个具有编码能力的终端，比如网络摄像机IPC，其可以将视频流编码为适合网络传输的视频数据然后通过网络传输出去；后端设备通常是一个具备解码能力的终端，比如安装有解码客户端软件的计算机等，其可以将接收到的视频数据进行解码后显示在屏幕上。请继续参考图1，前端设备产生的视频数据其通常有以下用途，一个是实时展现在后端设备的屏幕上，通常称之为实况应用；另一个是将实况视频数据存储到存储设备上以备以后查看，通常称之为回放应用。从视频数据的传输来看，回放应用和实况应用一样，也需要通过网络将视频数据传输给后端设备，只不过视频数据是由回放服务器从存储设备上读取到的。事实上，这两种应用是一种网络化的应用，需要在至少两种不同的设备之间进行交互，因此对于应用两端的参与设备而言，其需要居于中间的指挥调度者。通常管理服务器会充当这一指挥调度的角色。管理服务器的本质作用是从视频数据的源端（前端设备或存储设备）上为视频数据的请求端（通常为后端设备）调度视频数据。由于后端终端数量众多，因此为了减轻中心网络传输视频数据的压力，很多时候域内还可能有转发服务器。转发服务器通常负责把来自前端设备或存储设备的一路视频数据转发给一个或者多个后端设备，转发服务器的存在可有效减少视频数据源端发送视频数据的份数，并可减少网络承载这些视频数据的带宽压力。从实现上来说转发服务器可以是一个安装有相应软件的物理服务器，也可能是通过软硬件改造网络设备（比如交换机或路由器）而实现的一款服务器。本发明旨在提供一种OSD叠加解决方案来解决现有技术所面临的困境。请参考图2所示，以软件实现为例，在该解决方案中，本发明提供一种应用在管理服务器上的OSD叠加管理装置，以及与该叠加管理装置相配合的，应用在转发服务器上的OSD叠加执行装置。请参考图2，其中给出了上述两个装置运行的基本硬件环境，本发明对硬件环境并无特殊要求，可采用各种合适服务器的硬件架构。其中OSD叠加管理装置包括：请求处理单元、应答处理单元以及OSD控制单元；OSD叠加执行装置包括：OSD记录单元、转发判断单元以及转发执行单元。请参考图3，两个装置配合运行过程中执行如下两个对应的处理流程。步骤101，请求处理单元在管理服务器从视频数据请求端一侧接收到视频数据请求时，向该源端方向发送视频数据请求以将来自源端的视频数据调度给指定的接收者；步骤102，在管理服务器从源端一侧接收到与该视频数据请求对应的确认应答时，应答处理单元判断本域是否有指定接收者，如果有，则转步骤104；如果没有，则转步骤103处理；步骤103，应答处理单元继续向请求端方向发送确认应答，并在继续发送的确认应答中携带上本域OSD信息；转步骤104处理；步骤104，应答处理单元检查接收到的确认应答中是否携带有他域OSD信息，如果有则获取该确认应答中携带的他域OSD信息以及本域OSD信息作为需要叠加OSD信息，转步骤105处理；否则将本域OSD信息作为需要叠加OSD信息，转步骤105处理；步骤105，OSD控制单元在管理服务器接收到确认应答后且指定接收者属于本域的情况下，向该接收者发送OSD叠加控制指令，并在该指令中携带该视频数据标识以及对应的需要叠加OSD信息。步骤201，在转发服务器从管理服务器接收到OSD叠加控制指令时，OSD记录单元获取其中携带的需要叠加OSD信息以及对应的视频数据标识并保存两者的对应关系；步骤202，在转发服务器从源端一侧接收到视频数据流时，转发执行单元根据视频数据标识确定对应的需要叠加OSD信息；步骤203，转发判断单元确定当前视频数据的封装类型；步骤204，转发执行单元根据确定的封装类型使用对应的插入规则将需要叠加的OSD信息插入到该视频数据流中，然后向请求端一侧发送。请同时参考图3、图4以及图5，以下通过一个示例性的实况视频数据的传递过程来进行说明。图5所示多域监控系统包括ABCDE五个域，每个域都有对应的管理服务器（ABCDE），其中域B和域D没有转发服务器，而其他三个域均有对应的转发服务器。以下结合上述流程，以实况视频数据的传输过程为例进行说明。位于域E的后端设备，比如一个装有解码软件的计算机，其可以作为视频数据请求端向本域的管理服务器E发起针对域A中作为视频数据源端的前端设备（比如IPC）的实况视频数据请求。管理服务器E收到这个视频数据请求后会发现被请求的IPC并不在本域，于是管理服务器E会继续向下级域D发起视频数据请求。同样的道理域D中的管理服务器D也会发现该IPC并不在本域，其会继续向域C发起视频数据请求。以此类推，最终视频数据请求会被域A中的管理服务器A接收到，管理服务器A会发现该IPC在本域，于是会向该IPC发起视频数据请求。从以上的描述可以看出，视频数据请求是逐级传递到作为源端的IPC上的，每一次传递过程中视频数据请求的消息都有可能被修改。因为每一个域的管理服务器都会在视频数据请求中携带一个指定接收者。如果请求端不在本域，则所谓指定接收者通常是本域转发服务器。如果本域没有可以被指定接收者，比如没有转发服务器同时请求端也不在本域，则可以将向本域发送请求的上级域的接收者作为指定接收者。如果本域没有转发服务器，但请求端在本域，那么请求端就可以作为指定接收者。一旦视频数据请求被源端接受，则视频数据也可以逐级地从作为源端的IPC传送回作为请求端的计算机。当然这一过程在现有技术中已经有比较详尽的描述，本申请不再对此进行赘述。请继续参考图5，IPC接收视频数据请求后，其会在发送视频数据之前对该请求进行确认应答以使得后续的各个指定接收者做好接收准备。确认应答也是逐级传递的。在本发明优选的方式中，对于确认应答的处理分为两部分。在一种基础的实施方式中，假设所有的域都有转发服务器，则本域的管理服务器收到确认应答时，向转发服务器发送OSD叠加控制指令，这个指令中会携带转发服务器上OSD叠加执行装置所需要叠加的OSD信息。转发服务器收到之后会将这个需要叠加的OSD信息保存起来。当视频数据通过网络传输到转发服务器时，OSD叠加执行装置就会将该需要叠加OSD信息插入到视频数据流中。所谓视频数据流是指承载该视频数据报文所组成的报文流，从会话层面来看，其可以是五元组相同的IP报文流。这样承载视频数据的报文最终到达请求端的时候，请求端就能够从报文中获得视频数据以及对应的OSD信息，然后在屏幕上将视频以及该OSD展现出来。从这个过程可以看出，只要一个域中有运行OSD叠加执行装置的指定接收者（比如转发服务器或视频数据请求端），那么需要叠加的OSD信息就可以和视频数据一起传输到视频请求端。在视频数据流到达请求端的时候，视频数据流中可能已经被插入了很多个OSD信息，请求端就可以展示出一个更加丰富的OSD信息。当然如果视频数据请求端上也运行了OSD叠加执行装置，那么在展示之前其会先执行OSD信息的叠加操作。在一个示意性的例子中，假设蓟门桥某超市有一个IPC，若公安部的某个具有权限用户需要该IPC的视频数据，其可以请求该视频数据。IPC在发送视频数据时，首先在超市这个监控域中被OSD叠加执行装置叠加上“某某超市东南2#”这样的OSD信息，在视频数据传送到蓟门桥本地派出所所在的监控域时，其又会被叠加上“蓟门桥东北”这样的OSD信息。视频数据在到达区级监控域时，又会被叠加“海淀区”这样的OSD信息，接下来在北京市这样的省级监控域，又会被叠加上“北京市”。以此类推，最终公安部的用户会看到一个比较完整的OSD信息，比如“北京市海淀区蓟门桥东北某某超市东南2#”这样的OSD信息，这种OSD信息可以协助用户快速地了解到IPC所在的位置，在现有技术中，OSD信息不完整的情况下，可能只能得到非常有限的OSD信息，比如说仅仅能得到“某某超市东南2#”，用户根本无法了解到其迫切需要知道的信息。当然OSD信息不局限于地理位置这些信息，还可以是其他各种业务有需要的信息，这完全取决于监控业务的需要。请继续参考图5，事实上在一次视频数据传递所经过的多个域中，有一部分域可能没有合适的指定接收者，比如说没有转发服务器或者请求端也不在本域。此时该域中就无法部署OSD叠加执行装置。本发明在优选的方式中提供一种方案来完美解决该问题。图5中域B中没有可以实施OSD叠加执行装置的转发服务器，而请求端也不在本域；这一点管理服务器B是可以知晓的。若想将域B的OSD信息也叠加到视频数据的报文中，则需要进行额外处理。本发明优选方式中，管理服务器B向域C的管理服务器C发送确认应答时，将本域的OSD信息写入确认应答中，通过确认应答将本域的OSD信息携带上。管理服务器C在接收到确认应答的时候，会检查确认应答是否有携带他域OSD信息，如果是，则说明其他域有OSD信息需要借助本域的OSD叠加执行装置来协助叠加，也即是说本域需要叠加的OSD信息除了本域的OSD信息之外还可能包括确认应答中携带的他域OSD信息。因此管理服务器C在向本域叠加装置发送叠加控制指令时会将本域的OSD信息以及他域OSD信息一起携带上。当然，如果域C中也没有部署OSD叠加执行装置的话，其也可以将本域的OSD信息插入到确认应答中，继续向域D发送，以请求域D（假设域D有OSD叠加执行装置）来协助叠加，此时域D需要协助将域B和域C来叠加OSD信息。视频数据标识通常可以是源端设备的标识，比如IPC的标识，这个标识的引入可以对不同来源的视频数据进行区别对待。比如说有的视频数据在经过本域时，不需要叠加本域OSD信息，有的则需要，甚至不同来源的视频数据需要叠加的OSD信息不尽相同。管理服务器会将视频数据标识以及对应的需要叠加的OSD信息一起携带在叠加控制指令中发送给OSD叠加执行装置。运行在转发服务器或者请求端上的OSD叠加执行装置则可以在接收到来自源端的视频数据时，根据视频数据标识来确定使用哪个需要叠加的OSD信息。事实上，一个监控系统中，可能会采用多种方式对视频数据进行封装。OSD叠加执行装置需要对视频数据的封装方式进行区别处理。事实上，目前有多种比较流行的协议可以实现视频数据的报文封装。最为典型的三种协议包括RTP协议、TS协议以及PS协议。在接收到视频数据流时，需要判断视频数据的报文封装类型，因为在不同类型视频数据封装中，OSD信息的插入方式不一样，因此需要根据业务需要来预先配置好与封装类型相对应的插入规则，对于不同的封装类型使用不同的插入规则来向视频数据流中插入需要叠加OSD信息。以RTP协议为例，视频数据流采用RTP方式传输时，可以对RTP报文头部信息进行扩展，将需要叠加OSD信息放到RTP报文头部扩展区（Headerextension）中，报文具体格式以及OSD信息封装具体格式可以参考图6a以及图6b所示。如果视频数据流采用PS/TS（ProgramStream/TransportStream）方式传输时，可以在PS报文的PSM（ProgramStreamMap，节目流映射）或者在TS报文的PMT（TSProgramMapTable，传输流节目映射表）中，增加一种信息数据流来描述OSD信息。根据ITU-TRec.H.222.0(05/2006)规定，PID0x0004—0x1FFE范围可以自定义传输类型。在TS报文中，可以选定0x0100为OSD信息数据传输类型；在PS报文中，可以选择保留的0xFE作为OSD信息数据传输的Stream_id（流标识）。改进后PS以及TS具体封装格式可以参考图7以及图8示例，而OSD信息具体封装格式可以参考图9示例。RTP报文、TS报文以及PS报文事实上是一种应用层面的报文。其可以被封装在TCP或UDP报文中，TCP或UDP报文又可以被封装在IP报文中进行传输。事实上一个IP报文中可能承载了多个RTP报文或多个TS报文或多个PS报文。以PS为例，假设一个IP报文中承载有多个PS报文，那么有的PS报文里面封装的是视频数据，有的则是封装OSD信息。所谓视频数据流是从一个会话角度来看的，比如说IP报文五元组相同的IP报文称之为一条视频数据流。OSD信息可以被封装在某些由IP报文承载的PS报文中。经过上述流程后，请求端就可以收到视频数据流，其可以判断视频数据的封装格式，如果是RTP报文封装，则可以先查看是否存在扩展头，如果存在扩展头，则将其中的OSD信息提出来。如果是PS/TS报文封装，则可以判断PID或者Stream_id是否为OSD信息ID，如果是，则读取对应OSD信息。请求端在对视频数据进行解码时将上述获取到的OSD信息叠加到视频画面上，具体在画面上的显示位置，可由解码端控制，也可以由OSD信息携带的位置信息来指明。以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。