CN107547921A - 视频播放方法、装置及系统 - Google Patents

Abstract

本发明提供了视频播放方法、装置及系统，其中，该方法包括：第一节点接收机顶盒STB在播放视频中数据块chunk损坏的错误信息；该第一节点根据该错误信息向管理系统发送获取损坏的该chunk的重定向请求消息；该第一节点接收该管理系统根据该重定向请求消息返回的响应消息，其中，该响应消息中携带有获取损坏的该chunk对应的数据的第二节点的信息；该第一节点将该第二节点的信息发送给机顶盒供该机顶盒请求损坏的该chunk对应的数据，解决了相关技术中内容chunk损坏时导致视频播放失败的问题，使得视频可以流畅播放。

Description

视频播放方法、装置及系统

技术领域

本发明涉及通信领域，具体而言，涉及视频播放方法、装置及系统。

背景技术

在目前的交互式网络电视(Internet Protocol Television，简称为IPTV)，通过互联网向用户提供各种应用范围OTT(Over The TOP)系统中，为了保证节点内容存储的可靠性，都是使用双副本机制来存储，在现场要存储100T的片源，就要使用200T的存储空间。

同时在对各重要商用局点进行分析和研究，边缘节点只存储20％左右的内容，这些内容根据内容分发网络(Content Delivery Network，简称为CDN)调度策略决定都是热点内容，要能提供80％的用户播放。边缘节点个数众多，如果都是采用双副本存储，会极大的浪费存储空间；以国内某大型局点为例，边缘节点有300个节点，每个节点存储内容大概为100T，如果使用单副本存储就可以节省300*100T的空间，这个在现场成本至上的情况下，可以节省出非常多的利润空间。

节点单副本存储时，内容chunk损坏的概率更高，根据的实际验证，单副本情况下磁盘损坏的概率是双副本情况双磁盘坏的概率的2.2倍，因为播放到损坏chunk时，机顶盒是直接返回播放失败，对用户的体验大大下降。

针对相关技术中内容chunk损坏时导致视频播放失败的问题，还未提出有效的解决方案。

发明内容

本发明实施例提供了视频播放方法、装置及系统，以至少解决相关技术中内容chunk损坏时导致视频播放失败的问题。

根据本发明的一个实施例，提供了一种视频播放方法，包括：第一节点接收机顶盒(Set Top Box，简称为STB)在播放视频中数据块chunk损坏的错误信息；所述第一节点根据所述错误信息向管理系统发送获取损坏的所述chunk对应的数据的重定向请求消息，其中，所述重定向请求消息用于所述管理系统查询获取损坏的所述chunk对应的数据的第二节点；所述第一节点接收所述管理系统根据所述重定向请求消息返回的响应消息，其中，所述响应消息中携带有获取损坏的所述chunk对应的数据的第二节点的信息；所述第一节点将所述第二节点的信息发送给机顶盒供所述机顶盒请求损坏的所述chunk对应的数据。

优选地，在所述第一节点接收机顶盒STB在播放视频中chunk损坏的错误信息之后，所述方法还包括：

所述第一节点将所述错误信息记录到表A，其中，所述表A包括以下属性：

序号，记录表中共有多少条记录，标示为记录序号；

运营商标识，标示运营商的唯一身份；

内容标识，与运营商标识一起，是表的唯一索引；

子文件统一资源定位器(Sub File Uniform Resoure Locator，简称为SUBFILEURL)，文件在节点存放的完整路径名，包括总索引文件和子目录；

起始位置，损坏的chunk在文件中的起始位置；

长度，损坏的chunk大小；

状态，待修复内容的状态标示，共分为两种，一种是待修复状态，另一种是修复完成状态。

优选地，在所述第一节点将所述错误信息记录到所述表A之后，所述方法还包括：所述第一节点将所述表A的状态设置为待修复状态，并将所述表A的内容标识标示为内容损坏。

优选地，所述方法还包括：所述第一节点每10S扫描一次所述表A，查询所述表A中是否有待修复状态的记录；如果没有查询到有待修复字段的记录，所述第一节点继续下一次扫描；如果扫描到有待修复字段的记录，所述第一节点根据所述表A中序号的大小将序号小的优先记录，以该记录对应的内容标识和运营商标识，向所述管理系统请求调度损坏的所述chunk。

优选地，在所述第一节点接收所述管理系统根据所述重定向请求消息返回的响应消息之后，所述方法还包括：所述第一节点根据所述第二节点的信息，结合所述表A中的SUBFILE URL、起始位置和长度三个字段，在所述第二节点关于损坏的所述chunk的信息路径中，加上子文件名称路径、起始位置和长度三个字段，组合成一个完整的文件传输协议(File Transfer Protocol，简称为FTP)URL；所述第一节点根据所述FTP URL从所述第二节点调度损坏的所述chunk。

优选地，在所述第一节点根据所述FTP URL从所述第二节点调度损坏的所述chunk之后，所述方法还包括：

所述第一节点将所述表A中的状态设置为修复完成状态。

本发明实施例的另一方面，还提供了一种视频播放方法，包括：

管理系统接收第一节点发送的获取损坏的数据块chunk的重定向请求消息，其中，所述重定向请求消息用于所述管理系统查询获取损坏的所述chunk对应的数据的第二节点，所述错误信息是所述第一节点接收的机顶盒STB在播放视频中chunk对应的数据损坏的错误信息；

所述管理系统根据所述重定向请求消息向所述第一节点返回响应消息，其中，所述响应消息中携带有获取损坏的所述chunk对应的数据的第二节点的信息，供所述机顶盒从所述第二节点请求损坏的所述chunk对应的数据。

优选地，所述方法还包括：所述管理系统根据数据库中的记录查询是否制定了节点依赖，依赖的节点是否有损坏的所述chunk，以及有损坏的所述chunk的节点状态是否正常；在判断结果均为是的情况下，所述管理系统向所述第一节点返回所述响应消息；

在判断结果为否的情况下，向所述第一节点返回空消息。

本发明实施例的另一方面，还提供了一种视频播放方法，包括：

机顶盒接收第一节点反馈的获取损坏的chunk的第二节点的信息，其中，所述第二节点的信息携带在所述第一节点从管理系统根据重定向请求消息返回的响应消息中，所述重定向请求消息是所述第一节点根据错误信息向所述管理系统发送的用于获取损坏的所述chunk对应的数据，所述错误信息是所述第一节点接收的在播放视频中chunk损坏的错误信息；

所述机顶盒向所述第二节点请求损坏的所述chunk对应的数据。

本发明实施例的另一方面，还提供了一种视频播放装置，应用于第一节点，包括：

第一接收模块，用于接收机顶盒STB在播放视频中chunk损坏的错误信息；

第一发送模块，用于根据所述错误信息向管理系统发送获取损坏的所述chunk的重定向请求消息，其中，所述重定向请求消息用于所述管理系统查询获取损坏的所述chunk对应的数据的第二节点；

第二接收模块，用于接收所述管理系统根据所述重定向请求消息返回的响应消息，其中，所述响应消息中携带有获取损坏的所述chunk对应的数据的第二节点的信息；

第二发送模块，用于将所述第二节点的信息发送给机顶盒供所述机顶盒请求损坏的所述chunk对应的数据。

本发明实施例的另一方面，还提供了一种视频播放装置，应用于管理系统，包括：

第三接收模块，用于接收第一节点发送的获取损坏的chunk对应的数据的重定向请求消息，其中，所述重定向请求消息用于所述管理系统查询获取损坏的所述chunk对应的数据的第二节点，所述错误信息是所述第一节点接收的在播放视频中chunk损坏的错误信息；

返回模块，用于根据所述重定向请求消息向所述第一节点返回响应消息，其中，所述响应消息中携带有获取损坏的所述chunk对应的数据的第二节点的信息，供所述机顶盒从所述第二节点请求损坏的所述chunk对应的数据。

本发明实施例的另一方面，还提供了一种视频播放装置，应用于机顶盒，包括：

第四接收模块，用于接收第一节点反馈的获取损坏的chunk的第二节点的信息，其中，所述第二节点的信息携带在所述第一节点从管理系统根据重定向请求消息返回的响应消息中，所述重定向请求消息是所述第一节点根据错误信息向所述管理系统发送的用于获取损坏的所述chunk对应的数据，所述错误信息是所述第一节点接收的机顶盒STB在播放视频中chunk损坏的错误信息；

请求模块，用于向所述第二节点请求损坏的所述chunk对应的数据。

本发明实施例的再一方面，还提供了一种视频播放系统，包括第一节点、管理系统和机顶盒，其中，

所述第一节点，用于接收机顶盒在播放视频中数据块chunk损坏的错误信息，根据所述错误信息向所述管理系统发送获取损坏的所述chunk对应的数据的重定向请求消息，其中，所述重定向请求消息用于所述管理系统查询获取损坏的所述chunk对应的数据的第二节点；

所述管理系统，用于接收所述重定向请求消息，并根据所述重定向请求消息向所述第一节点返回响应消息，其中，所述响应消息中携带有获取损坏的所述chunk对应的数据的第二节点的信息；

所述第一节点，还用于接收所述响应消息，并将所述第二节点的信息发送给机顶盒；

所述机顶盒，用于接收所述第二节点的信息，并向所述第二节点请求损坏的所述chunk对应的数据。

通过本发明，向管理系统发送获取损坏的chunk的重定向请求消息，通过向管理系统返回的可以获取损坏的chunk的第二节点调度损坏的chunk，解决了相关技术中内容chunk损坏时导致视频播放失败的问题，使得视频可以流畅播放。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的视频播放方法的流程图一；

图2是根据本发明实施例的视频播放方法的流程图二；

图3是根据本发明实施例的视频播放方法的流程图三；

图4是根据本发明实施例的视频播放装置的框图一；

图5是根据本发明实施例的视频播放装置的框图二；

图6是根据本发明实施例的视频播放装置的框图三；

图7是根据本发明实施例的整个CDN的组网的结构框图；

图8是根据本发明实施例的节点内部组成的逻辑图；

图9是根据本发明实施例的错误信息携带表的示意图；

图10是根据本发明实施例的在chunk损坏情况下STB无缝播放的流程图一；

图11是根据本发明实施例的在chunk损坏情况下STB无缝播放的流程图二。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

在本实施例中提供了一种视频播放方法，图1是根据本发明实施例的视频播放方法的流程图一，如图1所示，该流程包括如下步骤：

步骤S102，第一节点接收机顶盒STB在播放视频中数据块chunk损坏的错误信息；

步骤S104，第一节点根据该错误信息向管理系统发送获取损坏的该chunk对应的数据的重定向请求消息，其中，该重定向请求消息用于该管理系统查询获取损坏的该chunk对应的数据的第二节点；

步骤S106，第一节点接收该管理系统根据该重定向请求消息返回的响应消息，其中，该响应消息中携带有获取损坏的该chunk对应的数据的第二节点的信息；

步骤S108，该第一节点将该第二节点的信息发送给机顶盒供该机顶盒请求损坏的该chunk对应的数据。

通过上述步骤，向管理系统发送获取损坏的chunk的重定向请求消息，通过向管理系统返回的可以获取损坏的chunk对应的数据的第二节点调度损坏的chunk对应的数据，解决了相关技术中内容chunk损坏时导致视频播放失败的问题，使得视频可以流畅播放。

优选地，在该第一节点接收机顶盒STB在播放视频中chunk损坏的错误信息之后，该第一节点将该错误信息记录到表A，其中，该表A包括以下属性：

序号，记录表中共有多少条记录，标示为记录序号；

运营商标识，标示运营商的唯一身份；

内容标识，与运营商标识一起，是表的唯一索引；

子文件索引SUBFILE URL，文件在节点存放的完整路径名，包括总索引文件和子目录；

起始位置，损坏的chunk在文件中的起始位置；

长度，损坏的chunk大小；

状态，待修复内容的状态标示，共分为两种，一种是待修复状态，另一种是修复完成状态。

优选地，在该第一节点将该错误信息记录到该表A之后，该第一节点将该表A的状态设置为待修复状态，并将该表A的内容标识标示为内容损坏。

优选地，第一节点每10S扫描一次该表A，查询该表A中是否有待修复状态的记录；如果没有查询到有待修复字段的记录，该第一节点继续下一次扫描；如果扫描到有待修复字段的记录，该第一节点根据该表A中序号的大小将序号小的优先记录，以该记录对应的内容标识和运营商标识，向该管理系统请求调度损坏的该chunk对应的数据。

优选地，在该第一节点接收该管理系统根据该重定向请求消息返回的响应消息之后，第一节点根据该第二节点的信息，结合该表A中的SUBFILE URL、起始位置和长度三个字段，在该第二节点关于损坏的该chunk的信息路径中，加上子文件名称路径、起始位置和长度三个字段，组合成一个完整的FTP URL；根据该FTP URL从该第二节点调度损坏的该chunk。

优选地，在该第一节点根据该FTP URL从该第二节点调度损坏的该chunk之后，第一节点将该表A中的状态设置为修复完成状态。

本发明实施例还提供了一种视频播放方法，图2是根据本发明实施例的视频播放方法的流程图二，如图2所示，该流程包括如下步骤：

步骤S202，管理系统接收第一节点发送的获取损坏的数据块chunk的重定向请求消息，其中，该重定向请求消息用于该管理系统查询获取损坏的该chunk对应的数据的第二节点，该错误信息是该第一节点接收的机顶盒STB在播放视频中chunk损坏的错误信息；

步骤S204，管理系统根据该重定向请求消息向该第一节点返回响应消息，其中，该响应消息中携带有获取损坏的该chunk对应的数据的第二节点的信息，供该机顶盒从该第二节点请求损坏的该chunk对应的数据。

优选地，管理系统根据数据库中的记录查询是否制定了节点依赖，依赖的节点是否有损坏的该chunk，以及有损坏的该chunk的节点状态是否正常；在判断结果均为是的情况下，该管理系统向该第一节点返回该响应消息；在判断结果为否的情况下，向该第一节点返回空消息。

本发明实施例还提供了一种视频播放方法，图3是根据本发明实施例的视频播放方法的流程图三，如图3所示，该流程包括如下步骤：

步骤S302，机顶盒接收第一节点反馈的获取损坏的数据块chunk对应的数据的第二节点的信息，其中，该第二节点的信息携带在该第一节点从管理系统根据重定向请求消息返回的响应消息中，该重定向请求消息是该第一节点根据错误信息向该管理系统发送的用于获取损坏的该chunk的，该错误信息是该第一节点接收的在播放视频中chunk损坏的错误信息；

步骤S304，机顶盒向该第二节点请求损坏的该chunk对应的数据。

本发明实施例提供了一种视频播放装置，应用于第一节点，图4是根据本发明实施例的视频播放装置的框图一，如图4所示，包括：

第一接收模块42，用于接收机顶盒STB在播放视频中数据块chunk损坏的错误信息；

第一发送模块44，用于根据该错误信息向管理系统发送获取损坏的该chunk的重定向请求消息，其中，该重定向请求消息用于该管理系统查询获取损坏的该chunk对应的数据的第二节点；

第二接收模块46，用于接收该管理系统根据该重定向请求消息返回的响应消息，其中，该响应消息中携带有获取损坏的该chunk对应的数据的第二节点的信息；

第二发送模块48，用于将该第二节点的信息发送给机顶盒供该机顶盒请求损坏的该chunk对应的数据。

本发明实施例还提供了一种视频播放装置，应用于管理系统，图5是根据本发明实施例的视频播放装置的框图二，如图5所示，包括：

第三接收模块52，用于接收第一节点发送的获取损坏的数据块chunk的重定向请求消息，其中，该重定向请求消息用于该管理系统查询获取损坏的该chunk对应的数据的第二节点，该错误信息是该第一节点接收的在播放视频中chunk损坏的错误信息；

返回模块54，用于根据该重定向请求消息向该第一节点返回响应消息，其中，该响应消息中携带有获取损坏的该chunk对应的数据的第二节点的信息，供该机顶盒从该第二节点请求损坏的该chunk对应的数据。

本发明实施例还提供了一种视频播放装置，应用于机顶盒，图6是根据本发明实施例的视频播放装置的框图三，如图6所示，包括：

第四接收模块62，用于接收第一节点反馈的获取损坏的数据块chunk对应的数据的该第二节点的信息，其中，该第二节点的信息携带在该第一节点从管理系统根据重定向请求消息返回的响应消息中，该重定向请求消息是该第一节点根据错误信息向该管理系统发送的用于获取损坏的该chunk的，该错误信息是该第一节点接收的机顶盒STB在播放视频中chunk损坏的错误信息；

请求模块64，用于向该第二节点请求损坏的该chunk对应的数据。

本发明实施例还提供了一种视频播放系统，包括第一节点、管理系统和机顶盒，其中，

该第一节点，用于接收机顶盒在播放视频中数据块chunk损坏的错误信息，根据该错误信息向该管理系统发送获取损坏的该chunk的重定向请求消息，其中，该重定向请求消息用于该管理系统查询获取损坏的该chunk对应的数据的第二节点；

该管理系统，用于接收该重定向请求消息，并根据该重定向请求消息向该第一节点返回响应消息，其中，该响应消息中携带有获取损坏的该chunk对应的数据的第二节点的信息；

该第一节点，还用于接收该响应消息，并将该第二节点的信息发送给机顶盒；

该机顶盒，用于接收该第二节点的信息，并向该第二节点请求损坏的该chunk对应的数据。

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：

步骤S1，第一节点接收机顶盒STB在播放视频中数据块chunk损坏的错误信息；

步骤S2，第一节点根据该错误信息向管理系统发送获取损坏的该chunk的重定向请求消息，其中，该重定向请求消息用于该管理系统查询获取损坏的该chunk对应的数据的第二节点；

步骤S3，第一节点接收该管理系统根据该重定向请求消息返回的响应消息，其中，该响应消息中携带有获取损坏的该chunk对应的数据的第二节点的信息；

步骤S4，该第一节点将该第二节点的信息发送给机顶盒供该机顶盒请求损坏的该chunk对应的数据。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本发明实施例提供了一个优化流程，可以提升机顶盒用户的观看体验，把机顶盒的播放流程进行了优化处理，在机顶盒播放到错误chunk时，服务器可以检测到是损坏的chunk，然后到CDN管理系统去发起重定向请求，返回给机顶盒一个好的节点URL，机顶盒然后到另外一个节点请求提供服务，这之间的时间很短，只会有短暂的卡顿现象，实际体验比直接播放失败要很很多。

在服务器感知到某一个内容的chunk损坏后，会触发内容损坏流程，反向告知CDN管理系统触发内容调度，管理系统在数据库中查询到该内容是好的节点返回，然后服务器到好的节点去请求内容调度，在内容调度时，不是整个内容都进行调度，而是只调度损坏的chunk，就是增加了该chunk在该内容中的起始位置和大小，到对端节点进行内容调度，这样大大节省了节点的内容调度压力，也给运营商的骨干网节省了很大的带宽。

为了实现单副本存储主要在做了两方面的优化和改进：节点和机顶盒之间播放流程优化，在遇到损坏的chunk时，机顶盒侧不是播放失败，而是可以继续播放，真正实现无缝播放；在节点之间的内容调度，实现了chunk级别的调度，使内容调度更加精细化；实现了chunk级复用调度。

本发明实施例针对目前IPTV/OTT系统中存储功能的改进和创新，整个改进在使存储节省50％空间的同时，使播放体验更加流畅，使内容调度的管理和流程更加精细化。着重在业务的处理流程上进行创新和改进，并不需要增加硬件设备，不需要增加额外的大的功能模块；所以在基本没有额外投入的情况下，实现了上述所说的两种优化，对于运营商和设备提供商来说，是一个很大的利好。

图7是根据本发明实施例的整个CDN的组网的结构框图，如图7所示，管理系统是负责所有节点的管理，包括内容调度、播放时重定向等，所有节点都和该管理系统保持长链接；节点分为中心节点、边缘节点；其中中心节点存储内容最全，它负责向边缘节点进行内容调度等；STB是播放终端，它直接和电视机连线，当STB播放时，直接到节点通过实时流传输协议，(RealTime Streaming Protectol，简称为RTSP)链接去请求码流进行播放。

图8是根据本发明实施例的节点内部组成的逻辑图，如图8所示，整个节点在硬件上是一台服务器组成，包括很多用于存储的磁盘；节点上按照SUSE 11SP3操作系统；在操作系统上面是分布式文件系统(Distributed File System，简称为DFS)，负责通过OS的底层文件系统向磁盘读写内容；流媒体服务器SS是在负责ftp调度和对媒体文件进行流化、对外发送媒体流的逻辑模块，它和DFS之间有调用接口；Agent是节点侧的上层，负责对节点管理，有内存数据库存储内容的一些信息，是管理系统和节点之间的纽带，负责接受管理系统的命令，并下发给SS去实际执行。

上述的表A主要是记录chunk损坏的内容信息，该表一共7个字段，下面对表中每个字段做详细解释说明，图9是根据本发明实施例的错误信息携带表的示意图，如图9所示，包括：

Sequence：该字段记录A表中共有多少条记录，标示为记录序号；

运营商标识VCDNID：该字段记录运营商的ID，是标示运营商的唯一身份，在实际运行过程中可能会对应多个运营商。

内容ID CID：该字段为vod的contentid，这个字段和VCDNID两个字段一起，是该表的唯一索引；他们两个组合在一起是不能有重复记录存在；而且表A与节点中的内容表之间关系就是两个组合字段为纽带。

SUBFILE URL：该字段为文件在节点存放的完整路径名，以前的内容调度的路径名是截止到contentid，但是以前调度是以内容为单位，现在调度是以chunk为单位，所以调度的路径到细化到文件级别；这里要解释说明的是，我们的内容一般是分为多个文件存在的，有总索引文件、子目录(包括实际媒体文件和子索引文件)。

START POINT：该字段是损坏的chunk在文件中的起始位置，该位置是由DFS也就是文件系统模块上报给SS进而上报给Agent写入数据库表A中的；

LENGTH：该字段是损坏的chunk大小，该字段和上面的START POINT一样，也是由DFS上报来的；

STATUS：该字段为待修复内容的状态标示，共分为两种，一个是刚插入记录表后为待修复状态，再就是修复完成后标示修复完成状态，再修复完成后会有一个30S的定时任务扫描该表，扫描到修复完成状态的记录，会把该记录从表A中删除掉。

这里需要重点说明的是，由SUBFILE URL、START POINT和LENGTH三个字段形成的组合，是表A的核心，这三个字段是由DFS上报而来的，该方案中的chunk级调度复用就是指的这里Agent复用了DFS上报来的这三个字段，进而进行chunk级别的FTP调度，使内容调度更加精细化和准确化，节省了带宽、IO等能力。

图10是根据本发明实施例的在chunk损坏情况下STB无缝播放的流程图一，如图10所示，包括：

步骤1001：STB在节点X中处于正常播放流程；

步骤1002：DFS在向磁盘读取文件进而发送给流媒体服务器SS时，遇到读取文件错误，导致STB收不到码流。

步骤1003：文件系统进而进行判断，有可能是磁盘损坏进而导致chunk损坏；

步骤1004：如果是其他原因导致的读文件失败，则返回给SS约定的错误码；

步骤1005：SS进而翻译该错误码，把相关的错误信息发送给STB，STB发送teardown消息，关闭此次播放链接，播放失败。

步骤1006：如果是chunk损坏导致的读文件错误，那么把相关的错误信息返回给SS，这些错误信息重点就是上文中表A中的SUBFILE URL、START POINT和LENGTH三个字段形成的组合；也就是根据这三个字段实现了上层业务Agent和下层文件系统DFS之间的chunk级调度复用。

步骤1007：SS进而再把该错误信息传递给它的上层业务Agent，此时Agent所要做的操作就是把该记录插入到表A中，把该记录标示为待修复状态，并且在内容表中把内容标示为内容损坏，此时如果有其他STB用户过来播放该内容，在内容表中查询到该内容为损坏状态时，就直接触发重定向流程。这个流程在下面的附图3的介绍中会重点介绍。

步骤1008：在插入表A记录的同时，Agent会向管理系统请求重定向，就是向管理系统查询，是否有其他节点可以正常播放该内容。

步骤1009：管理系统根据自己数据库中的记录，包括查询是否有制定了节点依赖、依赖的节点是否有该内容、有该内容的节点状态是否正常等；

步骤1010：如果上述条件没有满足，就是说没有查询到符合条件的节点时，则管理系统向节点返回空。

步骤1011：节点收到该信息后，触发播放失败流程，告知STB对应的错误码，STB播放失败。

步骤1012：如果管理系统查询有符合条件的节点，管理系统会选择一个最优节点Y，把节点Y的相关信息告诉Agent；

步骤1013：Agent把节点Y的相关信息，以2103重定向的形式告知STB；

步骤1014：STB收到2103重定向的请求时，STB会把断掉与节点X的链接，到新节点Y去请求播放；注意，这里要重点说明的是该STB到新节点Y去请求播放时，不管携带节点的URL等信息，还附带了STB在节点X播放时遇到错误的时间点信息，到了节点Y时，直接请求从该时间点开始播放。

通过完善节点和STB之间的一个2103重定向机制，实现了在chunk损坏情况下的STB无缝播放的效果，在实际实现过程中，该过程只有不到1秒钟，电视机的卡顿微乎其微，可以忽略不计；达到了无缝播放的效果。

图11是根据本发明实施例的在chunk损坏情况下STB无缝播放的流程图二，如图11所示，就是chunk级调度复用的流程进行详细解释说明：

步骤1101：在节点X为用户复位的情况下，DFS遇到chunk损坏的情况下，SS会把DFS返回的SUBFILE URL、START POINT和LENGTH等信息上报给Agent；这里也是Agent和DFS之间复用chunk的关键所在；

步骤1102：Agent会将该记录插入表A中，并标示该记录为待修复状态；

步骤1103：同时在内容表中将该内容所对应的记录置为内容损坏状态，此时如果有其他机顶盒再过来请求该内容时，节点查询到该内容为损坏状态，会直接触发重定向流程，向管理系统请求一个可用节点，把该节点信息以3011重定向的方式告诉STB。

步骤1104：节点中会启动一个定时任务S，该定时任务每10S扫描一次表A，针对表中待修复字段的记录都查询出来；

步骤1105:10S扫描表A，是否有待修复字段的记录存在；

步骤1106：如果没有查询到有待修复字段的记录，则继续下一次扫描即可；

步骤1107：如果扫描到有记录存在，则根据序号大小，以序号小的记录优先；以该条记录对应的CID和VCDNID，向管理系统请求内容调度；

步骤1108：管理系统收到节点X的请求后，在数据库中进行查询，判断条件仍然是，是否有依赖节点、依赖节点中是否有该内容、该依赖节点是否状态正常等；

步骤1109：如果管理系统没有查询到可用的节点，则返回为空。节点X继续下一轮扫描循环；

步骤1110：管理系统如果查询到有可用的节点，则选择一个最优节点Y，把Y节点的关于该内容相关信息路径以及ftp用户名和密码等告诉节点X；

步骤1111：节点收到信息后，会根据Y节点的相关信息，结合表A中的SUBFILE URL、START POINT和LENGTH三个字段，也就是说在Y节点关于该内容的信息路径中，再加上子文件名称路径、起始位置和长度大小三个字段；组合成一个完整的FTP URL；这里也是体现了chunk级调度复用的一个精细化管理的地方，只需要针对损坏的chunk进行调度，内容中其他没有损坏的chunk不再调度，大大节省了资源和时间。

步骤1112：节点把拼装好的FTP调度告知SS，由SS去到对端Y节点进行chunk调度；

步骤1113：chunk调度完成之后，该内容的实际物理文件就已经完整，Agent会将表A中的该内容对应的记录的状态修改为修复完成状态；

步骤1114：然后，Agent会将内容表中对应的该记录由内容损坏状态修改为良好状态；此时该内容如果有STB请求播放，则可以正常提供播放；

步骤1115：节点会再增加一个定时器T，该定时器为每30秒钟扫描一次表A，找到表A中状态为修复完成的记录；

步骤1116：如果没有找到，则继续下一轮循环扫描；

步骤1117：如果找到有这种记录，则把该记录从表A中删除表。

本发明实施例在旨在实现存储的单副本，进而在STB的无缝播放，节点的chunk级调度复用上进行创新，在节省空间，节省成本的同时，实现了精细化管理和提升了用户的体验。无缝播放的发明，是在机顶盒遇到chunk损坏时的重大流程改进，相信也是将来提升用户体验的主要改进流程，让用户感知不到节点内部的问题和异常。而chunk级调度复用是内容调度的优化，以前的内容损坏后，都是直接把该调度从另外一个节点调度过来，而现在的片源不少都是4K片源，码率非常高，有的要甚至20G左右，如果在一个chunk损坏后要把整个20G的内容全部调度过来，会非常浪费IO、带宽资源以及增加时间成本；本发明中使Agent能够复用也就是能够知晓具体损坏的chunk信息，也就是损坏的起始位置和大小，只是把该损坏的一部分从其他节点调度过来。两个发明之点，相辅相成，共同实现了单副本存储的优化和改进，也是未来CDN发展的一个方向。

本发明实施例主要是通过STB无缝播放和chunk级调度复用来实现单副本存储，与此同时，其他类似方案也在本专利要求的包含范围之内。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (13)

1.一种视频播放方法，其特征在于，包括：

第一节点接收机顶盒STB在播放视频中数据块chunk损坏的错误信息；

所述第一节点根据所述错误信息向管理系统发送获取损坏的所述chunk对应的数据的重定向请求消息，其中，所述重定向请求消息用于所述管理系统查询获取损坏的所述chunk对应的数据的第二节点；

所述第一节点接收所述管理系统根据所述重定向请求消息返回的响应消息，其中，所述响应消息中携带有获取损坏的所述chunk对应的数据的第二节点的信息；

所述第一节点将所述第二节点的信息发送给机顶盒供所述机顶盒请求损坏的所述chunk对应的数据。

2.根据权利要求1所述的方法，其特征在于，在所述第一节点接收机顶盒STB在播放视频中数据块chunk损坏的错误信息之后，所述方法还包括：

所述第一节点将所述错误信息记录到表A，其中，所述表A包括以下属性：

序号，记录表中共有多少条记录，标示为记录序号；

运营商标识，标示运营商的唯一身份；

内容标识，与运营商标识一起，是表的唯一索引；

子文件统一资源定位器SUBFILE URL，文件在节点存放的完整路径名，包括总索引文件和子目录；

起始位置，损坏的chunk在文件中的起始位置；

长度，损坏的chunk大小；

状态，待修复内容的状态标示，共分为两种，一种是待修复状态，另一种是修复完成状态。

3.根据权利要求1所述的方法，其特征在于，在所述第一节点将所述错误信息记录到所述表A之后，所述方法还包括：

所述第一节点将所述表A的状态设置为待修复状态，并将所述表A的内容标识标示为内容损坏。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

所述第一节点每10S扫描一次所述表A，查询所述表A中是否有待修复状态的记录；

如果没有查询到有待修复字段的记录，所述第一节点继续下一次扫描；

如果扫描到有待修复字段的记录，所述第一节点根据所述表A中序号的大小将序号小的优先记录，以该记录对应的内容标识和运营商标识，向所述管理系统请求调度损坏的所述chunk。

5.根据权利要求3所述的方法，其特征在于，在所述第一节点接收所述管理系统根据所述重定向请求消息返回的响应消息之后，所述方法还包括：

所述第一节点根据所述第二节点的信息，结合所述表A中的SUBFILE URL、起始位置和长度三个字段，在所述第二节点关于损坏的所述chunk的信息路径中，加上子文件名称路径、起始位置和长度三个字段，组合成一个完整的文件传输协议统一资源定位器FTP URL；

所述第一节点根据所述FTP URL从所述第二节点调度损坏的所述chunk。

6.根据权利要求5所述的方法，其特征在于，在所述第一节点根据所述FTP URL从所述第二节点调度损坏的所述chunk之后，所述方法还包括：

所述第一节点将所述表A中的状态设置为修复完成状态。

7.一种视频播放方法，其特征在于，包括：

管理系统接收第一节点发送的获取损坏的数据块chunk的重定向请求消息，其中，所述重定向请求消息用于所述管理系统查询获取损坏的所述chunk对应的数据的第二节点，所述错误信息是所述第一节点接收的机顶盒STB在播放视频中数据块chunk损坏的错误信息；

所述管理系统根据所述重定向请求消息向所述第一节点返回响应消息，其中，所述响应消息中携带有获取损坏的所述chunk对应的数据的第二节点的信息，供所述机顶盒从所述第二节点请求损坏的所述chunk对应的数据。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

所述管理系统根据数据库中的记录查询是否制定了节点依赖，依赖的节点是否有损坏的所述chunk，以及有损坏的所述chunk的节点状态是否正常；

在判断结果均为是的情况下，所述管理系统向所述第一节点返回所述响应消息；

在判断结果为否的情况下，向所述第一节点返回空消息。

9.一种视频播放方法，其特征在于，包括：

机顶盒接收第一节点反馈的获取损坏的数据块chunk对应的数据的第二节点的信息，其中，所述第二节点的信息携带在所述第一节点从管理系统根据重定向请求消息返回的响应消息中，所述重定向请求消息是所述第一节点根据错误信息向所述管理系统发送的用于获取损坏的所述chunk对应的数据，所述错误信息是所述第一节点接收的在播放视频中数据块chunk损坏的错误信息；

所述机顶盒向所述第二节点请求损坏的所述chunk对应的数据。

10.一种视频播放装置，应用于第一节点，其特征在于，包括：

第一接收模块，用于接收机顶盒STB在播放视频中数据块chunk损坏的错误信息；

第一发送模块，用于根据所述错误信息向管理系统发送获取损坏的所述chunk的重定向请求消息，其中，所述重定向请求消息用于所述管理系统查询获取损坏的所述chunk对应的数据的第二节点；

第二接收模块，用于接收所述管理系统根据所述重定向请求消息返回的响应消息，其中，所述响应消息中携带有获取损坏的所述chunk对应的数据的第二节点的信息；

第二发送模块，用于将所述第二节点的信息发送给机顶盒供所述机顶盒请求损坏的所述chunk对应的数据。

11.一种视频播放装置，应用于管理系统，其特征在于，包括：

第三接收模块，用于接收第一节点发送的获取损坏的数据块chunk的重定向请求消息，其中，所述重定向请求消息用于所述管理系统查询获取损坏的所述chunk对应的数据的第二节点，所述错误信息是所述第一节点接收的在播放视频中chunk损坏的错误信息；

返回模块，用于根据所述重定向请求消息向所述第一节点返回响应消息，其中，所述响应消息中携带有获取损坏的所述chunk对应的数据的第二节点的信息，供所述机顶盒从所述第二节点请求损坏的所述chunk对应的数据。

12.一种视频播放装置，应用于机顶盒，其特征在于，包括：

第四接收模块，用于接收第一节点反馈的获取损坏的数据块chunk对应的数据的第二节点的信息，其中，所述第二节点的信息携带在所述第一节点从管理系统根据重定向请求消息返回的响应消息中，所述重定向请求消息是所述第一节点根据错误信息向所述管理系统发送的用于获取损坏的所述chunk对应的数据，所述错误信息是所述第一节点接收的机顶盒STB在播放视频中chunk损坏的错误信息；

请求模块，用于向所述第二节点请求损坏的所述chunk对应的数据。

13.一种视频播放系统，其特征在于，包括第一节点、管理系统和机顶盒，其中，

所述第一节点，用于接收机顶盒在播放视频中数据块chunk损坏的错误信息，根据所述错误信息向所述管理系统发送获取损坏的所述chunk对应的数据的重定向请求消息，其中，所述重定向请求消息用于所述管理系统查询获取损坏的所述chunk对应的数据的第二节点；

所述管理系统，用于接收所述重定向请求消息，并根据所述重定向请求消息向所述第一节点返回响应消息，其中，所述响应消息中携带有获取损坏的所述chunk对应的数据的第二节点的信息；

所述第一节点，还用于接收所述响应消息，并将所述第二节点的信息发送给机顶盒；

所述机顶盒，用于接收所述第二节点的信息，并向所述第二节点请求损坏的所述chunk对应的数据。