一种平台录像方法、 系统及客户端 技术领域 本发明涉及多媒体技术领域， 具体涉及流媒体录像技术。 背景技术 随着网络技术的发展 ,一种新的媒体技术应运而生，这就是流媒体技术。 流媒体是指在网络中使用流式传输技术的连续时基媒体， 如音频、 视频或多 媒体文件。 流服务可以给用户提供持续不断的音视频流， 满足用户在线观看 动态影音的需求， 流媒体技术在媒体点播领域和媒体直播领域得到极大的应 用。 数字录像作为一种重要的视频信息保存方式 ,在诸多领域都有广泛的应 用。 平台录像， 顾名思义是指由平台侧（服务器端） 负责录像的执行和保存。 由于现有的平台录像系统普遍采用 C/S (客户端 /服务器） 架构， 所以在执行 平台录像时， 对服务器端具有较强的依赖性。 如果服务器端出现掉线或宕机 等意外情况， 则会导致平台录像的失败或内容部分缺失。 发明内容 有鉴于此， 本发明提供了一种平台录像方法、 系统及客户端， 用以解决 现有技术中录像服务器出现意外情况不能执行平台录像时 , 导致平台录像失 败或内容缺失的问题。 才艮据本发明的一个方面 , 提供了一种客户端。 该客户端包括发送模块 , 发送模块用于向录像服务器发送录像任务请 求， 发送模块还用于定时向录像服务器发送保活消息， 并用于当录像服务器 恢复正常后 , 向录像 务器发送录像文件。 并且上述客户端还包括： 备份模块， 用于在本地备份发送给录像服务器的录像任务； 检测模块，用于检测本地备份的录像任务列表中是否存在正在执行或者
即将开始执行的录像任务； 连接模块， 用于与编码器连接； 保存模块， 用于保存录像文件。 上述备份模块， 还用于保存从录像服务器获取的全部录像任务列表。 根据本发明的另一个方面， 提供了一种平台录像系统。 该系统包括客户端、 录像服务器、 编码器。 上述客户端， 用于向录像服务器发送录像任务， 并在本地备份该录像任 务。 当录像服务器出现异常时 , 该客户端 , 还用于检测本地备份的录像任务 列表中是否存在正在执行或者即将开始执行的录像任务， 当存在时， 该客户 端与编码器连接进行录像， 并将录像文件保存在本地。 另夕卜， 上述客户端， 还用于， 当录像服务器恢复正常后， 向录像服务器 发送录像文件。 上述录像服务器， 还用于， 当该录像服务器出现异常之前的状况。 如果该录像服务器已经录制了部分录像文件，则按照时间先后顺序拼接 上述客户端发送的录像文件与该录像服务器录制的部分录像文件 , 该录像服 务器还用于保存拼接后的录像文件； 如果该录像服务器没有开始录像任务， 则该录像服务器还用于保存客户端发送的录像文件。 另夕卜， 上述客户端， 还用于定时向上述录像服务器发送保活消息。 上述录像服务器 , 还用于向该客户端发送上述保活消息的响应消息。 上述保活消息的响应消息包括录像服务器的运行状态。 另夕卜， 上述系统还包括与客户端连接的其它服务器。 上述保活消息的响应消息还包括上述录像服务器存储的全部录像任务 列表。 当录像月 务器出现异常时，由上述其它月 务器负载均衡地选定至少一个
在线客户端执行录像任务。 才艮据本发明的又一个方面， 提供了一种平台录像方法。 上述方法包括如下步骤: 客户端向录像服务器发送录像任务， 并将该录像任务在本地备份; 当录像服务器出现异常时，客户端检测本地备份的录像任务列表中是否 存在正在执行或者即将开始执行的录像任务， 当存在时， 客户端与编码器连 接进行录像， 并将录像文件保存在本地。 上述方法还包括： 当录像月 务器恢复正常后 , 上述客户端向录像月 务器发送上述录像文 件； 当录像服务器出现异常之前：如果该录像服务器已经录制了部分录像文 件， 则按照时间先后顺序拼接客户端发送的录像文件与该录像服务器录制的 部分录像文件， 录像服务器保存拼接后的录像文件； 如果该录像服务器没有 开始录像任务， 则该录像服务器保存上述客户端发送的录像文件。 另外， 上述方法还包括： 上述客户端定时向录像服务器发送保活消息 ,该录像服务器向该客户端 发送保活消息的响应消息； 上述保活消息的响应消息包括该录像服务器的运行状态。 上述客户端依据上述保活消息的响应消息 , 判断该录像服务器是否正 常。 另外 , 上述保活消息的响应消息还可用来获取服务器端的录像任务列 表， 客户端依据该保活消息的响应消息 , 获取录像服务器存储的录像任务列 表， 并在本地保存； 客户端通过保活消息可以获取录像服务器端存储的全部录像任务列表， 也可各个客户端只获取本客户端指定的录像任务 , 而不是一个客户端获取所 有客户端制定的全部录像任务；
当录像服务器出现异常时 ,由与客户端连接的其它服务器负载均衡地选 定至少一个在线客户端执行录像任务。 通过本发明的上述至少一个方案，当平台录像机制在服务器侧出现故障 的情况下， 引入客户端与平台互备机制， 在录像服务器出现意外情况不能执 行平台录像时， 由客户端代替录像服务器执行平台录像任务， 可保证平台录 像在录像服务器出现故障时仍可顺利完成录像任务， 具有良好的容灾性。 附图说明 附图用来提供对本发明的进一步理解， 并且构成说明书的一部分， 与本 发明的实施例一起用于解释本发明 , 并不构成对本发明的限制。 在附图中： 图 1为才艮据本发明实施例的客户端的结构才匡图； 图 2为根据本发明实施例的平台录像系统的应用环境部署图； 图 3为本发明实施例一的具体实施过程的流程图。 具体实施方式 如上所述， 本发明提供了一种平台录像方法、 系统及客户端， 用以解决 现有技术中录像服务器出现意外不能执行平台录像时， 平台录像失败或内容 缺失的问题。 在该方案中， 通过客户端与录像服务器互备机制， 使得在录像 服务器出现故障时仍可顺利完成录像任务。 以下结合附图对本发明的优选实施例进行说明 , 应当理解 , 此处所描述 的优选实施例仅用于说明和解释本发明， 并不用于限定本发明。 根据本发明实施例 , 提供了一种客户端， 如图 1为根据本发明实施例 的客户端的结构框图， 根据本发明实施例的客户端包括： 发送模块、 备份模 块、 检测模块、 连接模块、 保存模块。 以下结合附图详细描述上述各个模块。 发送模块 101 , 用于向录像服务器发送录像任务请求， 该发送模块 101 还用于定时向录像服务器发送保活消息 , 并用于当录像服务器恢复正常后 , 向录像 务器发送录像文件；
并且上述客户端还包括: 备份模块 105 , 用于在本地备份发送给录像服务器的录像任务； 检测模块 102 , 用于检测本地备份的录像任务列表中是否存在正在执行 或者即将开始执行的录像任务； 连接模块 103 , 用于与编码器连接； 保存模块 104 , 用于保存录像文件。 上述备份模块 105 , 还用于保存从录像服务器获取的全部录像任务列 表。 根据本发明实施例的上述客户端 , 当录像服务器出现异常时 , 仍可通过 客户端完成录像任务。 才艮据本发明实施例 , 还提供一种平台录像系统， 用于录像服务器出现异 常时， 仍可通过客户端完成录像任务。 图 2 为根据本发明实施例的平台录像系统的应用环境部署图， 如图 2 所示的具体实施环境中， 编码器 203为与摄像头直接连接的能够提供流媒体 数据的设备， 客户端 201可以是很多种， 比如监控终端， 摄像头作为监控系 统的前端设备直接部署在监控现场 , 负责视频图像的采集； 录像服务器与编 码器之间可通过公网 （Internet ) 连接， 也可以通过私有网络连接， 编码器和 摄像头之间是直接的物理连接。 正常情况下， 录像服务器 202与编码器 203连接执行录像任务， 客户端 201向录像服务器 202发起录像任务请求后 , 录像服务器 202根据自身保存 的录像任务列表执行录像任务， 并保存录像文件。 采用本发明平台录像系统， 当录像服务器 202发生异常时， 客户端 201可采用直连的方式直接与位于前 端的编码器 203建立连接， 执行录像任务， 保存录像文件， 比如视频流， 完 成录像操作。 如图 2所示 , 一种平台录像的系统 , 包括客户端 201、 录像服务器 202、 编码器 203 , 以下结合附图进一步描述上述各个实体。 客户端 201 , 用于向录像服务器 202发送录像任务， 并在本地备份该录
像任务; 当录像服务器 202出现异常时 , 该客户端 201 , 还用于检测本地备份的 录像任务列表中是否存在正在执行或者即将开始执行的录像任务 ,当存在时 , 该客户端 201与编码器 203连接进行录像， 并将录像文件保存在本地。 另夕卜， 客户端 201 , 还用于， 当所述录像服务器 202恢复正常后， 向所 述录像服务器发送所述录像文件； 录像服务器 202 , 还用于 , 当该录像服务器 202出现异常之前。 如果该录像服务器 202已经录制了部分录像文件，则按照时间先后顺序 拼接上述客户端 201发送的录像文件与该录像^ ^务器 202录制的部分录像文 件，该录像服务器 202还用于保存拼接后的录像文件；如果该录像服务器 202 没有开始录像任务， 则该录像服务器 202还用于保存所述客户端 201发送的 录像文件。 另夕卜， 上述客户端 201 , 还用于定时向上述录像服务器 202发送保活消 息； 上述录像^^务器 202 , 还用于向该客户端发送上述保活消息的响应消 息； 上述保活消息的响应消息包括所述录像服务器 202的运行状态。 另夕卜， 上述系统还包括与客户端 201连接的其它服务器； 上述保活消息的响应消息还包括上述录像服务器 202 存储的全部录像 任务列表； 当所述录像服务器 202出现异常时，由上述其它服务器负载均衡地选定 至少一个在线客户端 201执行录像任务。 才艮据本发明实施例 , 提供了一种平台录像方法， 以下结合图 3进一步描 述上述各个处理的细节。 该方法包括如下步骤， 对于多个录像任务而言， 下 面步骤可以并行执行， 不分先后： 步骤 301 , 客户端向录像服务器发送录像任务请求;
录像服务器保存客户端发送的录像任务， 并按照系统时间执行录像任 务， 录像服务器 （平台侧） 将各客户端下发的录像任务或计划统一保存在平 台侧数据库中， 或者以数据结构的形式直接保存在内存中以获得更快的录像 任务检索速度 , 并按照系统时间执行相应的录像任务。 步骤 302, 录像任务请求发送成功， 客户端在本地备份该录像任务； 上述两步骤， 具体操作包括： 客户端向录像服务器发送录像任务请求； 上述请求消息包括录像任务 ID、 监控点 ID、 录像开始时间、 录像结束 时间、 录像的周期性信息； 客户端在本地数据库中备份客户端向录像服务器发送的录像任务。客户 端不止可备份自身制定的录像任务， 也可通过保活消息的响应消息 , 获取录 像服务器侧的全部录像任务列表， 在录像服务器发生异常时， 可根据负载均 衡等算法选定其中一个在线的客户端完成录像任务（选中的客户端可能并不 是该录像任务的发起者），其中可由录像服务器以外的其他与客户端连接的其 它服务器， 如登录服务器进行负载均衡判断； 在上述情况下， 客户端保存录像服务器测的全部录像任务表， 在录像服 务器发生异常时， 如果客户端保存的录像任务列表中不存在正在执行或者即 将开始执行的录像任务， 则客户端定时重复检测本地备份的录像任务表，期 间若有需要执行的录像任务则由客户端执行， 同时客户端定时重复发送保活 消息， 若录像^^务器恢复正常则结束流程。 步骤 303 , 录像服务器与编码器连接， 请求视频流， 编码器控制摄像头 开始录像； 步骤 304, 编码器向录像服务器返回视频流； 步骤 305 , 客户端定时向录像服务器发送保活消息； 步骤 306 , 录像服务器向该客户端发送所述保活消息的响应消息； 上述保活消息的响应消息包括该录像服务器的运行状态。 上述客户端依据上述保活消息的响应消息， 判断该录像服务器是否正
常。 上面两步骤， 具体操作包括: 客户端定时（如每隔 1分钟）向录像服务器不停地发送保活消息， 向录 像月 务器通 4艮自身的运行状况， 同步系统时间 , 同时也通过消息响应监视录 像服务器的运行情况。 步骤 307, 保活失败， 表明录像服务器出现异常， 客户端检测本地备份 的录像任务列表中是否存在正在执行或者即将开始执行的录像任务， 当存在 时， 客户端直连编码器， 编码器控制摄像头进行录像； 步骤 308 , 客户端通过直连方式从编码器端获取视频流， 其在本地保存 为录像文件； 上述两个步骤， 具体操作包括： 客户端判断录像服务器保活消息的响应消息是否正常；如果保活失败或 者录像服务器没有相应 , 则表明录像服务器出现异常 , 客户端检测本地备份 的录像任务列表， 根据系统时间判断是否有正在执行或者应该开始执行的录 像任务， 如果存在正在执行或即将开始执行的录像任务， 客户端采用直连的 方式直接与录像任务相关的目标编码器连接， ,并将编码器发来的录像文件保 存在本地。 录像文件名称可以包括录像任务的 ID、 监控点 ID、 本地录像实 际开始时间和结束时间。 步骤 309, 保活恢复， 录像服务器恢复正常， 上述客户端向录像服务器 上传上述本地保存的录像文件； 当录像服务器出现异常之前：如果该录像服务器已经录制了部分录像文 件， 则按照时间先后顺序拼接客户端发送的录像文件与该录像服务器录制的 部分录像文件， 所述录像服务器保存拼接后的录像文件； 如果该录像服务器 没有开始录像任务， 则该录像服务器直接保存上述客户端上传的录像文件。 客户端向录像服务器上传录像文件时，可使用断点续传或多线程并发下 载等技术提高文件传输质量。 步骤 310, 客户端本地保存的录像文件传输完毕， 然后录像服务器把对 应于某一录像任务的完整录像文件发送给请求该录像任务的客户端。
为了进一步描述上述方法的具体实施方式，下面以一种平台录像方法为 例， 对本发明实施例提供的上述方法的具体实施方式进行说明。 实施例一 一种平台录像方法， 主要包括以下步骤： 步骤 1 , 本实施例中以平台定时录像任务为例， 客户端通过 TCP+XML 的方式向平台侧发起录像任务的请求。 请求消息中包括目标录像任务的 ID、 监控点的 ID、 录像的开始和结束时间、 录像的周期性（每周或每天）等信息。 同时将发送至平台侧的录像任务备份在本地数据库中； 步骤 2, 录像服务器收到客户端的录像任务请求后， 将录像任务保存在 平台侧的 Oracle数据库中 , 并定时扫描录像任务表中的记录， 开始或结束时 间符合要求的录像计划； 步骤 3 , 本实施例中， 客户端每隔 1分钟以 TCP+XML的方式向录像服 务器发送保活消息， 并解析录像服务器回复的响应消息。 正常的保活响应消 息应包含月 务器的系统时间 （用来同步客户端的系统时间） 和月 务器当前的 运行状态等内容； 步骤 4 , 若客户端发现保活失败， 则检查保存在本地数据库中的平台录 像任务列表中是否存在正在执行或即将开始执行的录像任务； 步骤 5 , 客户端开启录像任务执行线程， 判断如果有已开始的录像任务 或即将开始的录像任务， 则根据这些录像任务对应的监控点 ID, 向对应的编 码器发起直连， 进行本地录像； 如果客户端不存在正在执行或者即将开始执 行的录像任务， 则客户端定时重复检测本地备份的录像任务表 ,期间若有需 要执行的录像任务则由客户端执行 , 同时客户端定时重复发送保活消息 , 若 录像服务器恢复正常则客户端停止直连录像 , 结束流程； 步骤 6, 客户端通过直连的方式将编码器的视频流保存在本地， 在录像 文件命名时应包含录像任务的 ID、 监控点 ID、 本地录像实际开始时间和结 束时间等重要信息； 步骤 7, 当保活消息恢复正常后， 表示录像服务器恢复正常工作可以继 续执行录像任务， 则客户端停止本地直连录像， 并将本地录像文件上传至平 台侧 (本实施例中采用文件传输十办议 ( File Transfer Protocol, 筒称为 FTP )
上传录像文件）； 步骤 8 , 客户端上传录像文件完成后， 若录像^^务器可 4艮据录像文件对 应的录像任务 ID 判断平台侧是否存在该录像任务的部分录像文件， 若平台 侧有部分录像文件 , 则将平台侧文件与客户端上传的录像文件按照时间的先 后顺序进行拼接， 组成一个完成的录像任务。 若该录像任务完全由客户端完 成， 则直接将客户端上传的文件改名， 保存为平台录像文件。 另夕卜， 在上述实施例中涉及的平台录像方法、 系统及客户端， 客户端本 地录像任务的备份也可只保存在内存的数据结构中 , 如此一来客户端的录像 任务执行线程可以更加有效地检索和执行本地备份录像任务表。 另夕卜， 在上述实施例中涉及的平台录像方法、 系统及客户端， 保活的周 期（时间间隔）可在不给录像服务器带来过重负担的前提下采用更短的时间， 以提高发现录像服务器异常的及时性。 当然， 本发明还可有其他多种实施例， 如采用手动方式开始平台录像， 在不背离本发明精神及其实质的情况下， 熟悉本领域的技术人员可才艮据本发 明作出各种相应的改变和变形， 但这些相应的改变和变形都应属于本发明所 附的权利要求的保护范围。
TECHNICAL FIELD The present invention relates to the field of multimedia technologies, and in particular, to a streaming media recording technology. BACKGROUND With the development of network technologies, a new media technology emerges as the times require. This is streaming media technology. Streaming media refers to continuous time-based media, such as audio, video or multimedia files, that use streaming technology in the network. The streaming service can provide users with continuous audio and video streams to meet the needs of users to watch dynamic video and audio online. Streaming media technology has been greatly applied in the field of media on demand and media broadcast. As an important way to save video information, digital video has been widely used in many fields. Platform recording, as the name implies, is responsible for the execution and preservation of video recording by the platform side (server side). Since the existing platform recording system generally adopts the C/S (client/server) architecture, it has strong dependence on the server side when performing platform recording. If the server side has an unexpected situation such as dropped calls or downtime, it will cause the platform recording to fail or the content is partially missing. SUMMARY OF THE INVENTION In view of this, the present invention provides a platform recording method, system, and client for solving the problem that the platform recording fails or the content is missing when the recording server fails to perform the platform recording in the prior art. According to an aspect of the present invention, a client is provided. The client includes a sending module, and the sending module is configured to send a recording task request to the recording server, and the sending module is further configured to periodically send a keep-alive message to the recording server, and send the video file to the server after the recording server returns to normal. The client further includes: a backup module, configured to locally back up the recording task sent to the recording server; and a detecting module, configured to detect whether the local backup recording task list is being executed or The recording task to be executed soon; the connection module for connecting to the encoder; and the saving module for saving the recording file. The above backup module is also used to save a list of all recording tasks acquired from the recording server. According to another aspect of the present invention, a platform recording system is provided. The system includes a client, a video server, and an encoder. The client is configured to send a recording task to the recording server, and back up the recording task locally. When the recording server is abnormal, the client is further configured to detect whether there is a recording task in the recording task list of the local backup that is being executed or is about to start, and when present, the client is connected to the encoder for recording, and The video file is saved locally. In addition, the client is further configured to send a video file to the recording server after the recording server returns to normal. The above recording server is also used for the situation before the recording server has an abnormality. If the video server has recorded a part of the video file, the video file sent by the client and some video files recorded by the video server are spliced in chronological order, and the video server is further used to save the spliced video file; If the server does not start the recording task, the recording server is also used to save the video file sent by the client. In addition, the client is further configured to periodically send a keep-alive message to the video recording server. The recording server is further configured to send a response message of the keep-alive message to the client. The response message of the keep-alive message includes the running status of the recording server. In addition, the above system also includes other servers connected to the client. The response message of the keep-alive message further includes all the recording task lists stored by the recording server. When the recording server is abnormal, at least one of the other servers is load balancedly selected. The online client performs the recording task. According to still another aspect of the present invention, a platform recording method is provided. The method includes the following steps: The client sends a recording task to the recording server, and the recording task is backed up locally; when the recording server is abnormal, the client detects whether the recording task list of the local backup is executing or is about to start execution. Recording task, when it exists, the client connects to the encoder for recording, and saves the recording file locally. The method further includes: after the video server returns to normal, the client sends the video file to the video server; before the video server is abnormal: if the video server has recorded part of the video file, in chronological order The video file sent by the client and a part of the video file recorded by the video server are spliced, and the video server saves the spliced video file; if the video server does not start the recording task, the video server saves the video file sent by the client. In addition, the method further includes: the client periodically sends a keep-alive message to the recording server, and the recording server sends a response message of the keep-alive message to the client; the response message of the keep-alive message includes an operating state of the recording server. The client determines whether the recording server is normal according to the response message of the keep-alive message. In addition, the response message of the keep-alive message may be used to obtain a video task list of the server, and the client obtains the video task list stored by the video server according to the response message of the keep-alive message, and saves it locally; the client passes the keep-alive message. You can obtain a list of all the recording tasks stored on the recording server. You can also obtain only the recording tasks specified by the client. Instead of one client, all the recording tasks created by all clients are obtained. When an abnormality occurs in the recording server, at least one online client is load-balanced by other servers connected to the client to perform a recording task. Through the above at least one solution of the present invention, when the platform recording mechanism fails on the server side, a mutual standby mechanism between the client and the platform is introduced, and when the recording server fails to perform the platform recording, the client performs the backup instead of the recording server. The platform recording task can ensure that the platform recording can successfully complete the recording task when the recording server fails, which has good disaster tolerance. The drawings are intended to provide a further understanding of the invention, and are intended to be a part of the description of the invention. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a structural diagram of a client according to an embodiment of the present invention; FIG. 2 is an application environment deployment diagram of a platform recording system according to an embodiment of the present invention; Flow chart of the specific implementation process. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS As described above, the present invention provides a platform recording method, system, and client for solving the problem that the platform recording fails or the content is missing when the recording server fails to perform the platform recording in the prior art. In this solution, the mutual backup mechanism between the client and the recording server enables the recording task to be successfully completed when the recording server fails. The preferred embodiments of the present invention are described in the following with reference to the accompanying drawings, which are intended to illustrate and illustrate the invention. According to an embodiment of the present invention, a client is provided. FIG. 1 is a structural block diagram of a client according to an embodiment of the present invention. The client includes a sending module, a backup module, a detecting module, and a connecting module. Save the module. The above various modules are described in detail below with reference to the accompanying drawings. The sending module 101 is configured to send a recording task request to the recording server, and the sending module 101 is further configured to periodically send a keep-alive message to the recording server, and send the video file to the server after the recording server returns to normal; The client further includes: a backup module 105, configured to locally back up the recording task sent to the recording server; and a detecting module 102, configured to detect whether there is a recording task being executed or about to be executed in the local backup recording task list; The connection module 103 is configured to be connected to the encoder; and the saving module 104 is configured to save the video file. The backup module 105 is further configured to save a list of all the recording tasks acquired from the recording server. According to the above client of the embodiment of the present invention, when the recording server is abnormal, the recording task can still be completed by the client. According to the embodiment of the present invention, a platform recording system is further provided, and when the recording server is abnormal, the recording task can still be completed through the client. 2 is an application environment deployment diagram of a platform recording system according to an embodiment of the present invention. In the specific implementation environment shown in FIG. 2, the encoder 203 is a device capable of providing streaming media data directly connected to the camera, and the client 201 can There are many types, such as monitoring terminals. The camera is deployed as a front-end device of the monitoring system directly at the monitoring site, and is responsible for video image collection. The video server and the encoder can be connected through the public network (Internet) or through a private network. There is a direct physical connection between the encoder and the camera. Normally, the recording server 202 is connected to the encoder 203 to perform a recording task. After the client 201 initiates a recording task request to the recording server 202, the recording server 202 performs a recording task according to the saved recording task list, and saves the recording file. With the platform recording system of the present invention, when the recording server 202 is abnormal, the client 201 can directly establish a connection with the encoder 203 located at the front end by directly connecting, performing a recording task, and saving a video file, such as a video stream, to complete the recording operation. . As shown in FIG. 2, a platform recording system includes a client 201, a recording server 202, and an encoder 203. The foregoing entities are further described below with reference to the accompanying drawings. The client 201 is configured to send a recording task to the recording server 202, and back up the recording locally. When the recording server 202 is abnormal, the client 201 is further configured to detect whether there is a recording task being executed or about to start in the recording task list of the local backup, and when present, the client 201 and the encoder The 203 is connected for recording, and the recording file is saved locally. In addition, the client 201 is further configured to: after the recording server 202 returns to normal, send the recording file to the recording server; and the recording server 202 is further configured to: before the recording server 202 is abnormal. If the video server 202 has recorded a part of the video file, the video file sent by the client 201 and a part of the video file recorded by the video server 202 are spliced in chronological order. The video server 202 is also used to save the spliced file. The video file 202 is also used to save the video file sent by the client 201 if the recording server 202 does not start the recording task. In addition, the client 201 is further configured to periodically send a keep-alive message to the video recording server 202. The video server 202 is further configured to send a response message of the keep-alive message to the client. The response message of the message includes the operational status of the recording server 202. In addition, the above system further includes other servers connected to the client 201; the response message of the keep-alive message further includes all the recording task lists stored by the recording server 202; when the recording server 202 is abnormal, the other The server load balancing selects at least one online client 201 to perform a recording task. According to an embodiment of the present invention, a platform recording method is provided, and details of each of the above processes are further described below in conjunction with FIG. The method includes the following steps. For multiple recording tasks, the following steps may be performed in parallel, in no particular order: Step 301, the client sends a recording task request to the recording server; The recording server saves the recording task sent by the client, and performs the recording task according to the system time. The recording server (platform side) uniformly saves the recording task or plan issued by each client in the platform side database, or directly in the form of data structure. Save in memory for faster recording task retrieval speed and perform corresponding recording tasks according to system time. Step 302: The recording task request is successfully sent, and the client backs up the recording task locally. The above two steps include: the client sends a recording task request to the recording server; the request message includes a recording task ID, a monitoring point ID, and a recording start. Time, recording end time, periodic information of recording; The client backs up the recording task sent by the client to the recording server in the local database. The client can not only back up the recording task set by itself, but also obtain the list of all the recording tasks on the recording server side through the response message of the keep-alive message. When an abnormality occurs in the recording server, one of the online ones can be selected according to the algorithm such as load balancing. The client completes the recording task (the selected client may not be the initiator of the recording task), and other servers connected to the client other than the recording server, such as the login server, perform load balancing judgment; in the above case, the client The end saves all the recording task records measured by the recording server. If an abnormality occurs in the recording server, if there is no recording task being executed or about to be executed in the recording task list saved by the client, the client periodically repeats the recording of the local backup recording task. In the table, if there is a recording task that needs to be executed, it is executed by the client, and the client periodically sends the keep-alive message periodically, and if the video server returns to normal, the process ends. Step 303: The recording server is connected to the encoder, requesting a video stream, and the encoder controls the camera to start recording. Step 304: The encoder returns a video stream to the recording server. Step 305: The client periodically sends a keep-alive message to the recording server. Step 306 The recording server sends a response message of the keep-alive message to the client; the response message of the keep-alive message includes an operating status of the recording server. The client determines whether the recording server is positive according to the response message of the keep-alive message. Often. The above two steps, the specific operations include: The client timing (such as every 1 minute) continuously sends a keep-alive message to the recording server, and communicates with the recording server, synchronizes the system time, and also passes the message. Respond to monitoring the operation of the recording server. Step 307: The keep-alive failure indicates that the recording server is abnormal. The client detects whether there is a recording task in the local backup recording task list that is being executed or is about to start. When it exists, the client directly connects to the encoder, and the encoder controls the camera. Step 308: The client obtains the video stream from the encoder end through the direct connection mode, and saves the video stream locally as the video file. The above two steps include: The client determines whether the response message of the video server keep-alive message is normal. If the keep-alive fails or the recording server does not respond, it indicates that the recording server is abnormal. The client detects the local backup recording task list, and judges whether there is a recording task that is being executed or should be started according to the system time. If there is an ongoing or upcoming At the beginning of the recording task, the client directly connects to the target encoder associated with the recording task in a direct connection, and saves the video file sent by the encoder locally. The video file name can include the ID of the recording task, the monitoring point ID, the actual start time and end time of the local recording. Step 309, the recovery is resumed, the recording server is restored to normal, and the client uploads the locally saved video file to the recording server. Before the recording server is abnormal: if the recording server has recorded part of the recording file, splicing according to chronological order The video file sent by the client and a part of the video file recorded by the video server, the video server saves the spliced video file; if the video server does not start the video recording task, the video server directly saves the video file uploaded by the client. When the client uploads video files to the recording server, you can use techniques such as breakpoint resuming or multi-threaded concurrent download to improve the file transfer quality. Step 310: The video file saved locally by the client is transmitted, and then the recording server sends a complete video file corresponding to a video recording task to the client requesting the video recording task. In order to further describe a specific implementation manner of the foregoing method, a specific implementation manner of the foregoing method provided by the embodiment of the present invention is described below by taking a platform recording method as an example. Embodiment 1 A platform recording method mainly includes the following steps: Step 1 In this embodiment, a platform timing recording task is taken as an example, and the client initiates a request for a recording task to the platform side by using TCP+XML. The request message includes the ID of the target recording task, the ID of the monitoring point, the start and end time of the recording, and the periodicity of the recording (weekly or daily). At the same time, the recording task sent to the platform side is backed up in the local database. Step 2: After receiving the video task request from the client, the recording server saves the recording task in the Oracle database on the platform side, and periodically scans the records in the recording task table. The start or end time meets the required recording plan. Step 3: In this embodiment, the client sends a keep-alive message to the recording server in TCP+XML every 1 minute, and parses the response message replied by the recording server. The normal keep-alive response message should include the system time of the server (the system time used to synchronize the client) and the current running status of the server; Step 4: If the client finds that the keep-alive fails, the check is saved locally. Whether there is a recording task being executed or about to start in the platform recording task list in the database; Step 5: The client starts the recording task execution thread, and judges that if there is a recording task that has started or a recording task to be started, according to the recording The monitoring point ID corresponding to the task is directly connected to the corresponding encoder for local recording. If the client does not have a recording task that is being executed or is about to start, the client periodically repeats the recording of the local backup recording task table. The video task that needs to be executed is executed by the client, and the client periodically sends the keep-alive message. If the video server returns to normal, the client stops direct recording and ends the process. Step 6, the client encodes the code through direct connection. The video stream of the device is saved locally, and should be included when naming the video file. Important information such as the ID of the task, the ID of the monitoring point, the actual start time and the ending time of the local recording; Step 7, after the keep-alive message returns to normal, it indicates that the recording server resumes normal operation and can continue to perform the recording task, then the client stops the local straight Even the video is recorded, and the local video file is uploaded to the platform side. In this embodiment, File Transfer Protocol (File Transfer Protocol) is used. Upload video file); Step 8: After the client uploads the video file, if the video server can determine whether there is part of the video file of the video task on the platform side according to the video task ID corresponding to the video file, if there is a video file on the platform side, For some video files, the platform side files and the video files uploaded by the client are spliced in order of time to form a completed recording task. If the recording task is completely completed by the client, the file uploaded by the client is directly renamed and saved as a platform video file. In addition, in the platform recording method, system and client involved in the above embodiment, the backup of the client local recording task can also be saved only in the data structure of the memory, so that the recording task execution thread of the client can be more effective. Search and execute the local backup recording task table. In addition, in the platform recording method, system and client involved in the above embodiments, the period (time interval) of the keep-alive can be shortened by not burdening the recording server to improve the time. Found the timeliness of the recording server exception. Of course, there are other various embodiments of the present invention. For example, the platform recording can be started manually. Without departing from the spirit and essence of the present invention, those skilled in the art can make various corresponding embodiments according to the present invention. Changes and modifications are intended to be included within the scope of the appended claims.