CN111586344B - 一种网络摄像机的消息发送方法及装置 - Google Patents
一种网络摄像机的消息发送方法及装置 Download PDFInfo
- Publication number
- CN111586344B CN111586344B CN201910123043.1A CN201910123043A CN111586344B CN 111586344 B CN111586344 B CN 111586344B CN 201910123043 A CN201910123043 A CN 201910123043A CN 111586344 B CN111586344 B CN 111586344B
- Authority
- CN
- China
- Prior art keywords
- message
- rtmp
- sent
- data packet
- target
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/18—Closed-circuit television [CCTV] systems, i.e. systems in which the video signal is not broadcast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
- H04N21/2347—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving video stream encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/254—Management at additional data server, e.g. shopping server, rights management server
- H04N21/2541—Rights Management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
- H04N21/4405—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video stream decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4623—Processing of entitlement messages, e.g. ECM [Entitlement Control Message] or EMM [Entitlement Management Message]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4627—Rights management associated to the content
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/6437—Real-time Transport Protocol [RTP]
Abstract
本申请公开了一种网络摄像机的消息发送方法,包括:当IPC发送消息时,根据预设规则对消息进行定义,得到待发送消息;根据RTMP协议将待发送消息进行数据流打包,得到目标RTMP数据包;将目标RTMP数据包发送至CDN服务器,以便客户端从CDN服务器分发的RTMP数据流中解析出消息。通过将消息数据打包为RTMP数据包,采用CDN服务器进行发送,提高了硬件利用率,降低了服务器成本。本申请还公开了一种视频监控客户端的消息接收方法、消息发送系统、消息接收系统、网络视频设备以及计算机可读存储介质,具有以上有益效果。
Description
技术领域
本申请涉及视频监控技术领域,特别涉及一种网络摄像机的消息发送方法、视频监控客户端的消息接收方法、消息发送系统、消息接收系统、网络视频设备以及计算机可读存储介质。
背景技术
随着信息技术的不断发展,视频直播技术应用在各行各业中为安全、监测等管理环节,为获取现场情况提供了方便。目前,视频直播技术主要是应用在广域网和局域网的环境中。当在广域网环境中时,实现方式是通过IPC(IP CAMERA网络摄像机)与服务器连接,服务器再将视频数据发送至客户端中,以便每个客户端收到视频数据。并且,当IPC出现问题需要发送报警信息等状态信息,或者客户端向IPC发送信息数据时,均通过该服务器进行信息数据的转发。也就是说,IPC的状态信息通过服务器发送至客户端,以便客户端可以实时获知摄像机的状态。并且,在现有技术中视频数据和其状态信息都通过不同的协议进行发送和接收,也就是说两种信息的发送接收互不影响,也互不关联。
在此基础上,随着摄像机设备的拍摄数据量越来越大,接收视频数据的客户端越来越多,就需要通过内容分发网络将视频数据进行分发,而摄像机相关的状态信息则通过原有的服务器进行发送,也就是视频数据和状态信息分离进行发送。但是随着视频数据的数据量上升,状态信息的数量也出现上升,此时状态数据只是通过原有的服务器进行发送和接收,会增大原有服务器的压力,带来成本上升。例如,为了降低服务器压力则会提高服务器性能,或增加新的服务器,无形间就提高了成本,降低了服务器性能的利用效率。
因此,如何降低网络架构中的成本是本领域技术人员关注的重点问题。
发明内容
本申请的目的是提供一种网络摄像机的消息发送方法、视频监控客户端的消息接收方法、消息发送系统、消息接收系统、网络视频设备以及计算机可读存储介质,通过将消息数据打包为RTMP(Real Time Messaging Protocol实时消息传输协议)数据包,通过CDN(Content Delivery Network内容分发网络)服务器进行发送,提高了硬件利用率,降低了服务器成本。
为解决上述技术问题,本申请提供一种网络摄像机的消息发送方法,包括:
当IPC发送消息时,根据预设规则对所述消息进行定义,得到待发送消息;
根据RTMP协议将所述待发送消息进行数据流打包,得到目标RTMP数据包;
将所述目标RTMP数据包发送至CDN服务器,以便客户端从所述CDN服务器分发的RTMP数据流中解析出所述消息。
可选的,当IPC发送消息时,根据预设规则对所述消息进行定义,得到待发送消息,包括:
当IPC发送消息时,根据所述预设规则对所述消息的字段进行定义,得到待发送字段;
对所述待发送字段进行加密处理,得到所述待发送消息。
可选的,客户端从所述CDN服务器分发的RTMP数据流中解析出所述消息,包括:
所述客户端判断接收到的RTMP数据包是否为所述目标RTMP数据包;
若是,则对所述目标RTMP数据包进行解析,得到所述消息。
可选的,对所述目标RTMP数据包进行解析,得到所述消息,包括:
根据所述RTMP协议对所述目标RTMP数据包进行解析,得到所述待发送消息;
根据所述预设规则对所述待发送消息进行解析,得到所述消息。
可选的,根据RTMP协议将所述待发送消息进行数据流打包,得到目标RTMP数据包,包括:
根据RTMP协议和预设消息类型将所述待发送消息进行数据流打包,得到所述目标RTMP数据包。
可选的,客户端从所述CDN服务器分发的RTMP数据流中解析出所述消息,包括:
所述客户端判断接收到的RTMP数据包的消息类型是否为所述预设消息类型;
若是,则对所述目标RTMP数据包进行解析,得到所述消息。
可选的,还包括:
在根据预设规则对所述消息进行定义之前,所述IPC判断RTMP流状态是否为被动状态;
若是,则执行所述根据预设规则对所述消息进行定义的步骤。
可选的,还包括:
IPC通过所述CDN服务器将接收到的用户权限信息发送至各客户端;
当客户端接收到所述用户权限信息时,客户端根据所述用户权限信息判断是否符合权限标准;
若是,则所述客户端执行所述用户权限信息对应的权限操作。
本申请还提供一种视频监控客户端的消息接收方法,包括:
客户端判断从CDN服务器中接收到的RTMP数据包是否为所述目标RTMP数据包;其中,所述目标RTMP数据包为将IPC消息进行数据流打包得到的;
若是,则对所述目标RTMP数据包进行解析,得到所述IPC消息。
本申请还提供一种消息发送系统,包括:
消息定义模块,用于当IPC发送消息时,根据预设规则对所述消息进行定义,得到待发送消息;
数据包打包模块,用于根据RTMP协议将所述待发送消息进行数据流打包,得到目标RTMP数据包;
数据流发送模块,用于将所述目标RTMP数据包发送至CDN服务器,以便客户端从所述CDN服务器分发的RTMP数据流中解析出所述消息。
本申请还提供一种消息接收系统,包括:
数据流判断模块,用于判断从CDN服务器中接收到的RTMP数据包是否为所述目标RTMP数据包;其中,所述目标RTMP数据包为将IPC消息进行数据流打包得到的;
数据流解析模块,用于当接收到的RTMP数据包为所述目标RTMP数据包时,对所述目标RTMP数据包进行解析,得到所述IPC消息。
本申请还提供一种网络视频设备,包括:
存储器,用于存储计算机程序;
处理器,用于执行所述计算机程序时实现如上所述的消息发送方法的步骤或所述的消息接收方法的步骤。
本申请还提供一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如上所述的消息发送方法的步骤或所述的消息接收方法的步骤。
本申请所提供的一种网络摄像机的消息发送方法,包括:当IPC发送消息时,根据预设规则对所述消息进行定义,得到待发送消息;根据RTMP协议将所述待发送消息进行数据流打包,得到目标RTMP数据包;将所述目标RTMP数据包发送至CDN服务器,以便客户端从所述CDN服务器分发的RTMP数据流中解析出所述消息。
通过当IPC发送消息时,将所要发送的消息打包为RTMP数据包,并通过CDN服务器的RTMP流进行发送,不用对现有的CDN服务器进行改动,并且采用现有的硬件资源就可以将消息进行传递,减少了IPC消息传送的成本,降低了原服务器的压力,还提高了硬件资源的利用率。
本申请还提供一种视频监控客户端的消息接收方法、消息发送系统、消息接收系统、网络视频设备以及计算机可读存储介质,具有以上有益效果,在此不作赘述。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据提供的附图获得其他的附图。
图1为本申请实施例所提供的一种网络摄像机的消息发送方法的流程图;
图2为本申请实施例所提供的另一种网络摄像机的消息发送方法的流程图;
图3为本申请实施例所提供的又一种网络摄像机的消息发送方法的流程图;
图4为本申请实施例所提供消息发送方法中的权限控制过程的流程图;
图5为本申请实施例所提供的一种消息发送系统的结构示意图;
图6为本申请实施例所提供的一种消息接收系统的结构示意图。
具体实施方式
本申请的核心是提供一种网络摄像机的消息发送方法、视频监控客户端的消息接收方法、消息发送系统、消息接收系统、网络视频设备以及计算机可读存储介质,通过将消息数据打包为RTMP数据包,采用CDN服务器进行发送,提高了硬件利用率,降低了服务器成本。
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
现有技术中,随着摄像机设备的拍摄数据量越来越大,接收视频数据的客户端越来越多,就需要通过内容分发网络将视频数据进行分发,而摄像机相关的状态信息则通过原有的服务器进行发送,也就是视频数据和状态信息分离进行发送。但是随着视频数据的数据量上升,状态信息的数量也出现上升,此时状态数据只是通过原有的服务器进行发送和接收,会增大原有服务器的压力,带来成本上升。例如,为了降低服务器压力则会提高服务器性能,或增加新的服务器,无形间就提高了成本,降低了服务器性能的利用效率。
因此,本申请提供了一种网络摄像机的消息发送方法,通过当IPC发送消息时,将所要发送的消息打包为RTMP数据包,并通过CDN服务器的RTMP流进行发送,不用对现有的CDN服务器进行改动,并且采用现有的硬件资源就可以将消息进行传递,减少了IPC消息传送的成本,降低了原服务器的压力,还提高了硬件资源的利用率。
请参考图1,图1为本申请实施例所提供的一种网络摄像机的消息发送方法的流程图。
在视频监控、视频直播的技术领域中,IPC作为该结构中信息数据的获取方,一般会输出视频数据和消息数据,并且这两种数据一般使用不同的协议进行发送。而本申请中,为了提高提高硬件资源的利用率,降低硬件成本,采用传输视频数据的硬件和软件,使得进行视频数据分发的CDN服务器也可以传输消息数据。
本实施例中,该方法可以包括:
S101,当IPC发送消息时,根据预设规则对消息进行定义,得到待发送消息;
在采用CDN服务器的目标下,本步骤为了使消息接收方可以被解析,根据预设规则对消息进行定义,得到待发送消息。
可见,其中消息是指当IPC中出现消息发送事件时,在IPC内部表征该消息发送事件的状态数据。当消息的类型不同时,消息的格式也可能不同。例如,消息可能是设备状态、普通报警以及智能报警等。这些消息之间的格式也互不相同,因此需要根据预设规则进行定义,得到统一格式的消息,即待发送消息。
在现有技术中,当IPC发送消息时,直接就通过现有的消息协议将该消息进行封装,再通过原有的服务器进行发送,没有使用现有的CDN服务器的资源,对原有的服务器造成了数据处理的压力。
S102,根据RTMP协议将待发送消息进行数据流打包,得到目标RTMP数据包;
在S101的基础上,本步骤主要是将其打包进RTMP数据流中,也就是根据RTMP协议将待发送消息打包为目标RTMP数据包。
本实施例主要是在IPC应用环境中,一般采用RTMP数据流传输视频数据,因此采用RTMP协议对消息进行打包处理。使得可以在RTMP数据流中夹带IPC的消息数据,提高了硬件利用率。
其中,具体如何采用RTMP协议对待发送消息进行数据流打包,可以采用现有技术提供的任意一种数据流打包方法,本实施例中并不做具体限定。
目前,在CDN服务器中对视频数据进行内容分发处理,主要是采用RTMP协议对视频数据进行传输。因此,为了可以使用CDN服务器的硬件资源,并且尽量减少对CDN服务器的改动,直接采用目前的传输方式,避免对消息数据添加新的传输协议。
S103,将目标RTMP数据包发送至CDN服务器,以便客户端从CDN服务器分发的RTMP数据流中解析出消息。
在S102的基础上,本步骤旨在进行RTMP数据流的发送,也就是将打包好的目标RTMP数据包发送至CDN服务器中,使得CDN服务器将该目标RTMP数据包进行数据分发,以便最后客户端从CDN服务器中获取到该目标RTMP数据包,并对其进行解析得到消息。
可见,本步骤进行数据的传输过程时,均采用了现有技术中对视频数据进行发送的方式。只是当客户端接收到对应的目标RTMP数据包时,根据RTMP协议和预设规则对其进行相应的解析处理。
可选的,本实施例中S101可以包括:
步骤一,当IPC发送消息时,根据预设规则对消息的字段进行定义,得到待发送字段;
步骤二,对待发送字段进行加密处理,得到待发送消息。
本可选方案中,主要是将该消息的字段进行定义为待发送字段,也就是定义为预设规则对应的格式,并对该待发送字段进行加密处理,就可以得到最后发送的待发送消息,提高了待发送消息的安全程度,避免了消息被恶意盗取。
其中,可以对待发送字段的会话ID进行加密处理,得到待发送消息。也就是,加密处理的对象可以是全文,也可以是部分数据,还可以是单向内容。在保证安全程度的条件下,减少加密的数据,可以只对待发送字段的会话ID进行加密处理,进而得到待发送消息。
可选的,本步骤的S103中客户端解析出消息的步骤,可以包括:
步骤一、客户端判断接收到的RTMP数据包是否为目标RTMP数据包;
步骤二、若是,则对目标RTMP数据包进行解析,得到消息。
可见,本可选方案主要是说在客户端接收到的分发的RTMP流的数据,并且不断从RTMP数据流中解析出视频数据时,不断的判断RTMP流中的RTMP数据包是否为包含有消息的数据包,也就是判断该RTMP数据包是否为目标RTMP数据包。
当接收到的RTMP数据包为目标RTMP数据包时,就可以对该目标RTMP数据包进行解析,得到消息。
可以想到的是,如果该目标RTMP数据包中的数据为加密数据时,则可以对其进行解密处理,而后得到所需要的消息。
可选的,上一可选方案中的步骤二可以包括:
子步骤一、根据RTMP协议对目标RTMP数据包进行解析,得到待发送消息;
子步骤二、根据预设规则对待发送消息进行解析,得到消息。
本可选方案主要是拆开了对RTMP数据包解析的过程进行了说明,即根据RTMP协议进行解析和根据预设协议进行解析。
综上,本实施例通过当IPC发送消息时,将所要发送的消息打包为RTMP数据包,并通过CDN服务器的RTMP流进行发送,不用对现有的CDN服务器进行改动,并且采用现有的硬件资源就可以将消息进行传递,减少了IPC消息传送的成本,降低了原服务器的压力,还提高了硬件资源的利用率。
在上一实施例的基础上,本实施例提供另一种消息发送方法。本实施例主要是将预设消息类型打包至目标RTMP数据包中,当客户端接收到该目标RTMP数据包时,根据预设类型判断是否对其进行解析处理。以便IPC根据不同的消息类型对消息接收方进行解析控制。其他部分与上一实施例大体相同,相同部分可以参考上一实施例,在此不做赘述。
请参考图2,图2为本申请实施例所提供的另一种网络摄像机的消息发送方法的流程图。
本实施例中,该方法可以包括:
S201,当IPC发送消息时,根据预设规则对消息进行定义,得到待发送消息;
S202,根据RTMP协议和预设消息类型将待发送消息进行数据流打包,得到目标RTMP数据包;
S203,将目标RTMP数据包发送至CDN服务器,以便客户端判断接收到的RTMP数据包的消息类型是否为预设消息类型;若是,则执行S204;
S204,对目标RTMP数据包进行解析,得到消息。
可见,本实施例通过在对消息进行数据流打包的步骤中,根据预设消息类型进行相应的打包处理,得到目标RTMP数据包,也就是说目标RTMP数据包中包含了消息类型的信息,当客户端接收到该数据包时,就可以根据消息类型判断是否进行解析处理,而该消息类型之外的数据包则不进行解析,以便完成解析过程的控制。
其中,预设消息类型可以是添加在数据字段中特定定义的类型参数,例如,将MessageTypeID定义为15,当客户端接收到该数据包时,判断MessageTypeID是否为15,若是,则可以继续进行下一步处理。
在上一实施例的基础上,本实施例提供另一种消息发送方法。本实施例中,主要是考虑到IPC应用的两种情况。第一种,IPC的视频数据是被动发送的,也就是接收到管理服务器发送的指令后才进行视频数据的发送。第二种,IPC的视频数据是主动发送的,也就是IPC不用接收指令,直接向对应的服务器推送视频数据。对应实际的应用情况,IPC主动发送视频数据时,消息数据会占用原服务器的硬件资源,需要将消息数据通过CDN服务器发送。而当IPC被动发送视频数据时,视频数据和消息数据均是通过其他管理方的服务器进行转发,视该管理方的需求再决定需不需要通过CDN服务器发送消息数据。因此,本实施例主要是提供一种对主动被动进行区分后再发送的方法,使得本方案可以灵活操作。
请参考图3,图3为本申请实施例所提供的又一种网络摄像机的消息发送方法的流程图。
本实施例中,该方法可以包括:
S301,当IPC发送消息时,IPC判断RTMP流状态是否为被动状态;若是,则执行S302;
本步骤执行的时间点是在IPC发送消息时,也就是根据预设规则对消息进行定义之前。
S302,根据预设规则对消息进行定义,得到待发送消息;
S303,根据RTMP协议将待发送消息进行数据流打包,得到目标RTMP数据包;
S304,将目标RTMP数据包发送至CDN服务器,以便客户端从CDN服务器分发的RTMP数据流中解析出消息。
可见,本实施例中在IPC发送消息时首先判断RTMP流状态是否为被动状态,若是,则可以执行后续的步骤。若不是,则可以采用其他的方式发送该消息。
其中,RTMP流状态是指RTMP数据流是主动发送的,还是被动发送的。
因此,本实施例通过判断RTMP流状态确定是否采用CDN服务器将消息数据进行发送,满足了使用者的个性化需求,同时还可以在被动发送时,采用CDN服务器进行发送,提高了硬件资源的利用率。
在以上所有实施例的基础上,该一种消息发送的方法,还可以包括权限控制的过程。在消息发送的过程中实现了权限控制的功能,使得客户端可以根据权限控制决定是否获取消息,或者是否执行相应的权限操作。
请参考图4,图4为本申请实施例所提供消息发送方法中的权限控制过程的流程图。
本实施例中,该方法还可以包括:
S401,IPC通过CDN服务器将接收到的用户权限信息发送至各客户端;
S402,当客户端接收到用户权限信息时,客户端根据用户权限信息判断是否符合权限标准;若是,则执行S403;
S403,客户端执行用户权限信息对应的权限操作。
可见,本实施例通过每个客户端接收到的用户权限信息,判断该客户端上的用户是否符合权限标准,或是否符合权限要求,若是,则可以执行各种权限操作,也就是对该客户端开放权限。
其中,该用户权限信息是管理服务器,或原服务器将接收的权限管理信息进行整合,得到的用户权限信息。该用户权限信息中表示了什么用户拥有权限,什么用户没有权限。因此,当客户端接收到该用户权限信息后就可以通过该用户权限信息确定该客户端的用户是否具备相应的权限。
其中,权限操作就是指被权限管控的多个操作,只有客户端具有操作权限后才可以执行这些权限操作。
可见,本实施例通过将用户权限信息发送至IPC,再下发至每个客户端,实现了对客户端的权限控制,提高了对于客户端的控制效率。
基于以上所有实施例,本实施例提供一种以客户端为角度的消息接收方法。本实施例通过从CDN接收到IPC发送的消息,提高了硬件资源的利用率,并且降低了成本。
本实施例中,该方法可以包括:
S501,客户端判断从CDN服务器中接收到的RTMP数据包是否为目标RTMP数据包;其中,目标RTMP数据包为将IPC消息进行数据流打包得到的;若是,则执行S502;
S501,对目标RTMP数据包进行解析,得到IPC消息。
本实施例通过从CDN接收到IPC发送的消息,提高了硬件资源的利用率,并且降低了成本。
在以上所有实施例的基础上,本实施例主要提供一种更加具体的消息发送和消息接收的方法。
本实施例中,该方法主要包括:
步骤1,IPC接入云服务器并推流至CDN时,判断RTMP流与云服务器的关系。IPC在云服务器在线,并在收到云服务器消息向CDN服务器推流后,对RTMP流与云服务器的关系进行判断。如果RTMP流为IPC主动推送至CDN中,CDN在线状态记录为0;如果是收到云服务器推流请求消息后,将RTMP流推送至CDN时,CDN在线状态记录为1;
步骤2,IPC处于CDN云分发环境向服务器推流时,进行消息定义。IPC有信息需要传递给APP时,定义消息结构,并对身份识别信息进行加密;
步骤3,IPC通过RTMP协议推流给CDN服务器时,进行消息透传到APP,也就是将消息打包至数据包中进行传送。在RTMP实况流中增加私有拓展字段,携带IPC的报警、状态等信息;
步骤4,当管理端用户通过云服务器向管理范围内在网APP,或通过管理端APP向其他在网相关APP发送消息时,进行权限控制。管理端用户筛选需要发送消息的下级用户,当下级用户在网时,云服务器定时下发身份验证字段,IPC通过RTMP打包后经CDN服务器透传至APP;
步骤5,CDN服务器再将收到的流推给相关在网用户的手机APP,APP观看实况直播时,对RTMP数据包进行解析。APP收到RTMP数据包后,对RTMP数据包进行解析,码流数据直接传递至播放器进行解码。其他数据信息根据身份验证,仅当验证通过时于APP中显示。
其中,步骤1可以包括:
步骤101:IPC接入云服务器时,接收云服务器传递的RTMP推流,通过RTMP协议推流至CDN服务器;
步骤102:IPC根据用户需求和设置,自身主动与CDN服务器建立连接并通过RTMP协议推流;
步骤103:IPC推流至CDN服务器时,检测自身RTMP流,判断RTMP流与云服务器的关系。当流是自身主动推送至CDN服务器时,状态记为0;当流是接收到云服务器推流请求后推送至CDN服务器时,状态记为1。
步骤104:IPC配置文件增加特殊字段保存目前的RTMP流状态,当RTMP流状态发生更改时,更新配置文件,并将信息同步至云服务器。
此处字段可以定义如下:
<CloudStatus>0</CloudStatus>。
其中,步骤2可以包括:
步骤201:IPC判断自身RTMP流状态。当流状态为1时,执行步骤202;
步骤202:当IPC在RTMP推流过程中,设备有信息需要上报至APP时,对此类信息进行定义。设备上报信息包括但不限于:设备状态,普通报警(运动检测、遮挡检测等),智能报警(区域入侵、越界检测等泛智能以及人脸检测等深度智能);
步骤203:通过对RTMP传输过程的唯一Session进行加密,保证传输的安全性。
此处字段可以定义如下(仅以告警信息举例,*为加密后的SessionID):
<SessionID>********</SessionID>
<Time>UTCtime</Time>
<InfoType>Alarm</InfoType>
<AlarmType>100</AlarmType>。
其中,步骤3可以包括:
步骤301:IPC将消息完成定义后,将消息打包进RTMP流中。修改RTMP包中MessageType ID,将消息打包进RTMP流中;
此处字段可以定义如下(仅以Message Type ID定义为15,消息仅以报警举例):
MessageTypeID:15
<SessionID>********</SessionID>
<Time>UTCtime</Time>
<InfoType>Alarm</InfoType>
<AlarmType>100</AlarmType>;
步骤302:CDN服务器将IPC传输的RTMP数据复制并分发给各个APP。
其中,步骤4可以包括:
步骤401:当管理用户通过云服务器或APP向下级用户发送消息时,执行权限控制的步骤;
步骤402:管理用户进入云服务器或APP后,选择所需要收到消息的云账号,通过LAPI接口发送至云服务器,LAPI接口定义附带云账号信息;
此处举例接口可以定义如下(*代表加密后的云账号名称):
POST LAPI/V1.0/PrivateCloudUser
{“CloudUserName1”:”*********”
“CloudUserName2”:”********”};
步骤403:云服务器收到APP管理用户发送的信息后,对该管理用户下所选中的用户进行标记。未选中用户标记0,选中用户标记1;
步骤404:云服务器将标记为1的用户信息重新打包,通过LAPI接口下发给IPC。
此处举例接口可以定义如下(*代表加密后的云账号名称):
PUT LAPI/V1.0/TransUser
{“CloudUserName1”:”********”,
“CloudUserName2”:”********”}。
其中,步骤4还可以包括:
步骤411:APP根据云账号信息判断权限,当权限符合标准时开放发送信息至其他在网APP的功能;
步骤412:APP中选定某一通道后,APP通过LAPI将信息打包发送至云服务器,此处举例接口定义如下:
PUT LAPI/V1.0/TransData
{“value1”:key1,”value2”:”key2”};
步骤413:云服务器将消息数据发送至IPC,IPC修改MessageTypeID,将消息打包进RTMP流中;
此处举例字段定义如下(仅以Message Type ID定义为16,消息仅以服务器回传消息举例):
MessageTypeID:16
<SessionID>********</SessionID>
<Time>UTCtime</Time>
<InfoType>Message</InfoType>
<Message>Data</Message>;
其中,步骤5可以包括:
步骤501:查看实况直播的APP收到RTMP消息,解析报文,当报文中Message TypeID为15时(此处仅以15举例),判定为IPC通过CDN服务器透传来的信息;
步骤502:APP根据消息字段进行解析:首先解密SessionID,当解密后的SessionID与IPC传输的一致时进行后续字段解析;消息中解析Time字段,明确信息推送的时间;然后解析InfoType,当InfoType为Alarm时,解析AlarmType值,不同的值代表不同的报警上报和状态;
步骤503:APP完成字段解析后,界面UI展示报警等信息。
本申请实施例提供了一种网络摄像机的消息发送方法,可以通过当IPC发送消息时,将所要发送的消息打包为RTMP数据包,并通过CDN服务器的RTMP流进行发送,不用对现有的CDN服务器进行改动,并且采用现有的硬件资源就可以将消息进行传递,减少了IPC消息传送的成本,降低了原服务器的压力,还提高了硬件资源的利用率。
下面对本申请实施例提供的一种消息发送系统进行介绍,下文描述的一种消息发送系统与上文描述的一种消息发送方法可相互对应参照。
请参考图5,图5为本申请实施例所提供的一种消息发送系统的结构示意图。
本实施例中,该系统可以包括:
消息定义模块110,用于当IPC发送消息时,根据预设规则对消息进行定义,得到待发送消息;
数据包打包模块120,用于根据RTMP协议将待发送消息进行数据流打包,得到目标RTMP数据包;
数据流发送模块130,用于将目标RTMP数据包发送至CDN服务器,以便客户端从CDN服务器分发的RTMP数据流中解析出消息。
下面对本申请实施例提供的一种消息接收系统进行介绍,下文描述的一种消息接收系统与上文描述的一种消息接收方法可相互对应参照。
请参考图6,图6为本申请实施例所提供的一种消息接收系统的结构示意图。
本实施例中,该系统可以包括:
数据流判断模块210,用于判断从CDN服务器中接收到的RTMP数据包是否为目标RTMP数据包;其中,目标RTMP数据包为将IPC消息进行数据流打包得到的;
数据流解析模块220,用于当接收到的RTMP数据包为目标RTMP数据包时,对目标RTMP数据包进行解析,得到IPC消息。
本申请实施例还提供一种网络视频设备,包括:
存储器,用于存储计算机程序;
处理器,用于执行所述计算机程序时实现如以上实施例所述的消息发送方法的步骤或以上实施例所述的消息接收方法的步骤。
本申请实施例还提供一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如以上实施例所述的消息发送方法的步骤或以上实施例所述的消息接收方法的步骤。
该计算机可读存储介质可以包括:U盘、移动硬盘、只读存储器(Read-OnlyMemory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。
专业人员还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
以上对本申请所提供的一种网络摄像机的消息发送方法、视频监控客户端的消息接收方法、消息发送系统、消息接收系统、网络视频设备以及计算机可读存储介质进行了详细介绍。本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以对本申请进行若干改进和修饰,这些改进和修饰也落入本申请权利要求的保护范围内。
Claims (7)
1.一种网络摄像机的消息发送方法,其特征在于,包括:
IPC判断RTMP流状态是否为被动状态;若是,则当IPC发送消息时,根据预设规则对所述消息进行定义,得到待发送消息;若不是,则采用其他方式发送该消息;其中,被动状态为接收到管理服务器发送的指令后发送的视频数据;
根据RTMP协议将所述待发送消息进行数据流打包,得到目标RTMP数据包;
将所述目标RTMP数据包发送至CDN服务器,以便客户端从所述CDN服务器分发的RTMP数据流中解析出所述消息;
IPC通过所述CDN服务器将接收到的用户权限信息发送至各客户端;
当客户端接收到所述用户权限信息时,客户端根据所述用户权限信息判断是否符合权限标准;若是,则所述客户端执行所述用户权限信息对应的权限操作。
2.根据权利要求1所述的消息发送方法,其特征在于,当IPC发送消息时,根据预设规则对所述消息进行定义,得到待发送消息,包括:
当IPC发送消息时,根据所述预设规则对所述消息的字段进行定义,得到待发送字段;
对所述待发送字段进行加密处理,得到所述待发送消息。
3.根据权利要求1所述的消息发送方法,其特征在于,客户端从所述CDN服务器分发的RTMP数据流中解析出所述消息,包括:
所述客户端判断接收到的RTMP数据包是否为所述目标RTMP数据包;
若是,则对所述目标RTMP数据包进行解析,得到所述消息。
4.根据权利要求3所述的消息发送方法,其特征在于,对所述目标RTMP数据包进行解析,得到所述消息,包括:
根据所述RTMP协议对所述目标RTMP数据包进行解析,得到所述待发送消息;
根据所述预设规则对所述待发送消息进行解析,得到所述消息。
5.根据权利要求1所述的消息发送方法,其特征在于,根据RTMP协议将所述待发送消息进行数据流打包,得到目标RTMP数据包,包括:
根据RTMP协议和预设消息类型将所述待发送消息进行数据流打包,得到所述目标RTMP数据包。
6.根据权利要求5所述的消息发送方法,其特征在于,客户端从所述CDN服务器分发的RTMP数据流中解析出所述消息,包括:
所述客户端判断接收到的RTMP数据包的消息类型是否为所述预设消息类型;
若是,则对所述目标RTMP数据包进行解析,得到所述消息。
7.一种消息发送系统,其特征在于,包括:
消息定义模块,用于判断RTMP流状态是否为被动状态;若是,则当IPC发送消息时,根据预设规则对所述消息进行定义,得到待发送消息;若不是,则采用其他方式发送该消息;其中,被动状态为接收到管理服务器发送的指令后发送的视频数据;
数据包打包模块,用于根据RTMP协议将所述待发送消息进行数据流打包,得到目标RTMP数据包;
数据流发送模块,用于将所述目标RTMP数据包发送至CDN服务器,以便客户端从所述CDN服务器分发的RTMP数据流中解析出所述消息;IPC通过所述CDN服务器将接收到的用户权限信息发送至各客户端;当客户端接收到所述用户权限信息时,客户端根据所述用户权限信息判断是否符合权限标准;若是,则所述客户端执行所述用户权限信息对应的权限操作。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910123043.1A CN111586344B (zh) | 2019-02-18 | 2019-02-18 | 一种网络摄像机的消息发送方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910123043.1A CN111586344B (zh) | 2019-02-18 | 2019-02-18 | 一种网络摄像机的消息发送方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111586344A CN111586344A (zh) | 2020-08-25 |
CN111586344B true CN111586344B (zh) | 2022-03-11 |
Family
ID=72125943
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910123043.1A Active CN111586344B (zh) | 2019-02-18 | 2019-02-18 | 一种网络摄像机的消息发送方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111586344B (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114786036B (zh) * | 2022-03-02 | 2024-03-22 | 上海仙途智能科技有限公司 | 自动驾驶车辆的监控方法及装置、存储介质、计算机设备 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104219500A (zh) * | 2014-08-27 | 2014-12-17 | 天津市中信互联科技有限公司 | 监控视频直播的装置和方法 |
CN107666619A (zh) * | 2017-06-15 | 2018-02-06 | 北京金山云网络技术有限公司 | 直播数据传输方法、装置、电子设备、服务器及存储介质 |
CN108924577A (zh) * | 2018-07-17 | 2018-11-30 | 杭州雅顾科技有限公司 | 基于直播的节目制作播出系统及方法 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9800690B1 (en) * | 2009-06-26 | 2017-10-24 | Tata Communications (America) Inc. | Content-based redirection |
CA2824203C (en) * | 2011-01-12 | 2021-03-30 | Level 3 Communications, Llc | Customized domain names in a content delivery network (cdn) |
CN106101503A (zh) * | 2016-07-18 | 2016-11-09 | 优势拓展(北京)科技有限公司 | 实时全景直播网络摄像机和系统及方法 |
JP6903172B2 (ja) * | 2017-06-20 | 2021-07-14 | テレフオンアクチーボラゲット エルエム エリクソン(パブル) | ライブアップリンク適応ストリーミングのための装置および方法 |
-
2019
- 2019-02-18 CN CN201910123043.1A patent/CN111586344B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104219500A (zh) * | 2014-08-27 | 2014-12-17 | 天津市中信互联科技有限公司 | 监控视频直播的装置和方法 |
CN107666619A (zh) * | 2017-06-15 | 2018-02-06 | 北京金山云网络技术有限公司 | 直播数据传输方法、装置、电子设备、服务器及存储介质 |
CN108924577A (zh) * | 2018-07-17 | 2018-11-30 | 杭州雅顾科技有限公司 | 基于直播的节目制作播出系统及方法 |
Also Published As
Publication number | Publication date |
---|---|
CN111586344A (zh) | 2020-08-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20170054766A1 (en) | Enterprise client-server system and methods of providing web application support through distributed emulation of websocket communications | |
EP3780523A1 (en) | Network traffic identification method and related device | |
CN110933118A (zh) | 边缘计算网关安全通信方法、系统、终端设备及服务器 | |
CN108390881A (zh) | 一种分布式高并发实时消息推送方法及系统 | |
US11470060B2 (en) | Private exchange of encrypted data over a computer network | |
US20170171166A1 (en) | Anti-hotlinking method and electronic device | |
CN107911336B (zh) | 一种web盗链防护方法 | |
US20230283479A1 (en) | Data Transmission Method and Apparatus, Device, System, and Storage Medium | |
CN113141365A (zh) | 分布式微服务数据传输的方法、装置、系统和电子设备 | |
CN115118705A (zh) | 一种基于微服务的工业边缘管控平台 | |
CN111586344B (zh) | 一种网络摄像机的消息发送方法及装置 | |
CN113726743B (zh) | 一种网络重放攻击的检测方法、装置、设备和介质 | |
CN107113304B (zh) | 用于加密数据交换上的中介委派的方法和模块 | |
CN106572052B (zh) | 一种互联网电视播放内容的校验方法、机顶盒和系统 | |
CN112689014A (zh) | 一种双全工通信方法、装置、计算机设备和存储介质 | |
CN112073963A (zh) | 通信交互数据传输方法及装置 | |
US9825942B2 (en) | System and method of authenticating a live video stream | |
CN112291248A (zh) | 一种防护HTTPS DDoS攻击的方法及设备 | |
CN115766902A (zh) | 一种通过quic发送非敏感数据的方法、装置、设备、介质 | |
CN111382451A (zh) | 一种密级标识方法、装置、电子设备及存储介质 | |
CN106549924A (zh) | 一种通信安全防护方法、装置和系统 | |
CN114996730A (zh) | 一种数据加解密系统、方法、计算机设备及存储介质 | |
Pokharel et al. | Can Android VoIP voice conversations be decoded? I can eavesdrop on your Android VoIP communication | |
CN113992734A (zh) | 会话连接方法及装置、设备 | |
CN109788249B (zh) | 基于工业互联网操作系统的视频监控控制方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |