CN109005430A - 一种音/视频内容的点播方法、***、装置及存储介质 - Google Patents
一种音/视频内容的点播方法、***、装置及存储介质 Download PDFInfo
- Publication number
- CN109005430A CN109005430A CN201811082868.5A CN201811082868A CN109005430A CN 109005430 A CN109005430 A CN 109005430A CN 201811082868 A CN201811082868 A CN 201811082868A CN 109005430 A CN109005430 A CN 109005430A
- Authority
- CN
- China
- Prior art keywords
- node
- video
- audio
- client
- content fragment
- 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.)
- Granted
Links
Classifications
-
- 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
-
- 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/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
- H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
-
- 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/432—Content retrieval operation from a local storage medium, e.g. hard-disk
- H04N21/4325—Content retrieval operation from a local storage medium, e.g. hard-disk by playing back content from the storage medium
-
- 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/845—Structuring of content, e.g. decomposing content into time segments
- H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
本申请公开了一种音/视频内容的点播方法,在发起点播请求的客户端支持并行传输时,从构成目标音/视频文件的各内容分片分别所在的目标节点中同时拉取其中存储的内容分片,并在完成组装后将其传输至该客户端,以加速音/视频资源的点播速度,相较于传统从中心化服务器进行单点拉取的方式,从单路数据传输变为多路,在单路数据传输未达用户带宽上限时,可有效提升目标音/视频资源的点播速度,用户观看体验更佳。本申请还同时公开了一种音/视频内容的点播***、装置及计算机可读存储介质,具有上述有益效果。
Description
技术领域
本申请涉及音/视频点播技术领域,特别涉及一种音/视频内容的点播方法、***、装置及计算机可读存储介质。
背景技术
随着互联网的普及和信息化时代的广泛信息来源,越来越多的人们会通过网络选取自己感兴趣的信息进行观看,最为普遍的就是各类音/视频资源,区别于受电视台控制播放的电视节目,网络上的音/视频资源不仅整合度更高,且可根据用户意愿随意挑选,随意点播,用户体验更佳。
现有技术中,为了防止中心化存储方式在故障时出现的严重后果,还出现一种利用由众多用户提供存储空间形成的分布式存储方式,将每个数据文件分割成多个内容分片,并将各内容分片按照一定的冗余方式分别存放在不同的节点中进行存储,即使某个用户掉线或故障,还能够从其它节点中得到相同的内容分片,最终还原回完整的数据文件,此种方式由于并非将每个完整数据文件在每个节点都存储一份,一来能够有效节省节点的存储空间,二来也能够防止节点的用户直接获得完整的数据文件。
基于上述方式虽然给出了一种去中心化的分布式存储方式,但如何将该种方式应用于音/视频资源的点播方面,以加速资源的缓冲速度,尽可能的达到用户带宽上限,是本领域技术人员亟待解决的问题。
发明内容
本申请的目的是提供一种音/视频内容的点播方法,在发起点播请求的客户端支持并行传输时,从构成目标音/视频文件的各内容分片分别所在的目标节点中同时拉取其中存储的内容分片,并在完成组装后将其传输至该客户端,以加速音/视频资源的点播速度,相较于传统从中心化服务器进行单点拉取的方式,从单路数据传输变为多路,在单路数据传输未达用户带宽上限时,可有效提升目标音/视频资源的点播速度,用户观看体验更佳。
本申请的另一目的在于提供了一种音/视频内容的点播***、装置及计算机可读存储介质。
为实现上述目的,本申请提供一种音/视频内容的点播方法,该方法包括:
接收目标音/视频的点播请求;
根据所述点播请求确定发起所述点播请求的客户端是否支持并行传输;
当所述客户端支持并行传输时,获取构成所述目标音/视频的各内容分片分别所在的目标节点;
同时从各所述目标节点中拉取所述目标音/视频的各内容分片,并根据各所述内容分片的时间特征重新组装为完整音/视频;
将所述完整音/视频返回至所述客户端。
可选的,根据所述点播请求确定发起所述点播请求的客户端是否支持并行传输,包括:
从所述点播请求中提取得到所述客户端支持的接口类型;
当所述接口类型包括MSE和/或Fetch接口时,判定所述客户端支持并行传输;
当所述接口类型不包括所述MSE和/或所述Fetch接口时,判定所述客户端不支持并行传输。
可选的,获取构成所述目标音/视频的各内容分片分别所在的目标节点,包括:
向调度中心发送所述目标音/视频的内容分片分布请求;
接收所述调度中心根据所述内容分片分布请求返回的包含有各所述内容分片所在节点的请求返回信息,并根据所述请求返回信息确定构成各所述目标节点。
可选的,同时从各所述目标节点中拉取所述目标音/视频的各内容分片,包括:
以Range的方式同时从各所述目标节点中拉取所述目标音/视频的各内容分片。
可选的,该点播方法还包括:
根据各所述内容分片以及各所述内容分片分别所在的各目标节点建立数据拉取对应表。
可选的,该点播方法还包括:
当所述客户端不支持并行传输时,从可用节点池任选一个支持HTTP协议的HTTP节点;
将所述数据拉取对应表下发至所述HTTP节点,以使所述HTTP节点从各所述目标节点中拉取各所述内容分片,并在将各所述内容分片重新组成为所述完整音/视频后通过HTTP协议单点传输至所述客户端。
可选的,从可用节点池任选一个支持HTTP协议的HTTP节点,包括:
从所述可用节点池中选取所有支持HTTP协议的节点,得到初步可用节点集;
根据所述初步可用节点集中各节点的网络质量选取得到一个优选HTTP节点;其中,所述优选HTTP节点为所述初步可用节点集中所述网络质量最佳的节点;
将所述数据拉取对应表下发至所述HTTP节点,以使所述HTTP节点从各所述目标节点中拉取各所述内容分片,并在将各所述内容分片重新组装为所述完整音/视频后通过HTTP协议单点传输至所述客户端,包括:
将所述数据拉取对应表下发至所述优选HTTP节点,以使所述优选HTTP节点从各所述目标节点中拉取各所述内容分片,并在将所述内容分片重新组装所述完整音/视频后通过HTTP协议单点传输至所述客户端。
可选的,该点播方法还包括:
当构成所述目标音/视频的一个内容分片同时位于N个节点上时,按预设选取规则从由所述N个节点组成的相同内容分片节点集中选取得到唯一的所述目标节点;其中,N≥2。
为实现上述目的,本申请还提供了一种音/视频内容的点播***,包括:
点播请求接收单元,用于接收目标音/视频的点播请求;
并行传输支持判断单元,用于根据所述点播请求确定发起所述点播请求的客户端是否支持并行传输;
内容分片所在节点确定单元,用于当所述客户端支持并行传输时,获取构成所述目标音/视频的各内容分片分别所在的目标节点;
多节点数据拉取及组装单元,用于同时从各所述目标节点中拉取所述目标音/视频的各内容分片,并根据各所述内容分片的时间特征重新组装为完整音/视频;
完整音/视频返回单元,用于将所述完整音/视频返回至所述客户端。
可选的,所述并行传输支持判断单元包括:
接口类型提取子单元,用于从所述点播请求中提取得到所述客户端支持的接口类型;
并行传输支持判定子单元,用于当所述接口类型包括MSE和/或Fetch接口时,判定所述客户端支持并行传输;
并行传输不支持判定子单元,用于当所述接口类型不包括所述MSE和/或所述Fetch接口时,判定所述客户端不支持并行传输。
可选的,所述内容分片所在节点确定单元包括:
分布请求发送子单元,用于向调度中心发送所述目标音/视频的内容分片分布请求;
各目标节点确定子单元,用于接收所述调度中心根据所述内容分片分布请求返回的包含有各所述内容分片所在节点的请求返回信息,并根据所述请求返回信息确定构成各所述目标节点。
可选的,所述多节点数据拉取及组装单元包括:
Range多源数据拉取子单元,用于以Range的方式同时从各所述目标节点中拉取所述目标音/视频的各内容分片。
可选的,该点播方法还包括:
对应表建立单元,用于根据各所述内容分片以及各所述内容分片分别所在的各目标节点建立数据拉取对应表。
可选的,该点播方法还包括:
HTTP节点选取单元,用于当所述客户端不支持并行传输时,从可用节点池任选一个支持HTTP协议的HTTP节点;
单点传输处理单元,用于将所述数据拉取对应表下发至所述HTTP节点,以使所述HTTP节点从各所述目标节点中拉取各所述内容分片,并在将各所述内容分片重新组成为所述完整音/视频后通过HTTP协议单点传输至所述客户端。
可选的,所述HTTP节点选取单元包括:
初步可用节点集确定子单元,用于从所述可用节点池中选取所有支持HTTP协议的节点,得到初步可用节点集;
优选HTTP节点选取子单元,用于根据所述初步可用节点集中各节点的网络质量选取得到一个优选HTTP节点;其中,所述优选HTTP节点为所述初步可用节点集中所述网络质量最佳的节点;
所述单点传输处理单元包括:
优选HTTP节点传输子单元,用于将所述数据拉取对应表下发至所述优选HTTP节点,以使所述优选HTTP节点从各所述目标节点中拉取各所述内容分片,并在将所述内容分片重新组装所述完整音/视频后通过HTTP协议单点传输至所述客户端。
可选的,该点播方法还包括:
冗余节点选取单元,用于当构成所述目标音/视频的一个内容分片同时位于N个节点上时,按预设选取规则从由所述N个节点组成的相同内容分片节点集中选取得到唯一的所述目标节点;其中,N≥2。
为实现上述目的,本申请还提供了一种音/视频内容的点播装置,包括:
存储器,用于存储计算机程序;
处理器,用于执行所述计算机程序时实现如上述内容所描述的音/视频内容的点播方法的步骤。
为实现上述目的,本申请还提供了一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如上述内容所描述的音/视频内容的点播方法的步骤。
显然,本申请所提供的一种音/视频内容的点播方法,在发起点播请求的客户端支持并行传输时,从构成目标音/视频文件的各内容分片分别所在的目标节点中同时拉取其中存储的内容分片,并在完成组装后将其传输至该客户端,以加速音/视频资源的点播速度,相较于传统从中心化服务器进行单点拉取的方式,从单路数据传输变为多路,在单路数据传输未达用户带宽上限时,可有效提升目标音/视频资源的点播速度,用户观看体验更佳。本申请同时还提供了一种音/视频内容的点播***、装置及计算机可读存储介质,具有上述有益效果,在此不再赘述。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据提供的附图获得其他的附图。
图1为本申请实施例提供的一种音/视频内容的点播方法的流程图;
图2为本申请实施例提供的音/视频内容的点播方法中一种确定是否支持并行传输的流程图;
图3为本申请实施例提供的音/视频内容的点播方法中一种不支持并行传输时实现音/视频内容播放的流程图;
图4为本申请实施例提供的不支持并行传输时实现音/视频内容播放方法中一种选取优选HTTP节点的方法的流程图;
图5为本申请实施例提供的一种音/视频内容的点播***的结构框图;
图6为本申请实施例提供的一种通过并行传输加速目标音/视频内容缓冲速度的点播***的逻辑示意图;
图7为本申请实施例提供的一种客户端不支持并行传输时基于HTTP协议实现目标音/视频内容加速缓冲的点播***的逻辑示意图。
具体实施方式
本申请的核心是提供一种音/视频内容的点播方法、***、装置及计算机可读存储介质,在发起点播请求的客户端支持并行传输时,从构成目标音/视频文件的各内容分片分别所在的目标节点中同时拉取其中存储的内容分片,并在完成组装后将其传输至该客户端,以加速音/视频资源的点播速度,相较于传统从中心化服务器进行单点拉取的方式,从单路数据传输变为多路,在单路数据传输未达用户带宽上限时,可有效提升目标音/视频资源的点播速度,用户观看体验更佳。
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本申请保护的范围。
实施例一
以下结合图1,图1为本申请实施例提供的一种音/视频内容的点播方法的流程图,本实施例的执行主体为能够发起点播请求的客户端(根据所处平台,包括网页客户端、PC客户端、移动客户端)的一个功能组件,在业界通常被称为SDK(Software Development Kit,软件开发工具包,此处指为特定的软件包、软件框架、硬件平台、操作***等建立应用软件时的开发工具的集合),其具体包括以下步骤:
S101:接收目标音/视频的点播请求;
当用户在客户端上点击了某个音/视频内容的播放键时,相应的功能组件就会发起该目标音/视频内容的点播请求,该点播请求用于向拥有该目标音/视频内容的节点(传统方式下则向中心化的数据服务器)请求返回该目标音视频的数据文件,以待在接收到返回的数据文件后为用户通过相应的播放器进行播放,进而完成整个点播过程。
S102:根据点播请求确定发起点播请求的客户端是否支持并行传输;
在S101的基础上,本步骤旨在根据该点播请求确定发起点播请求的客户端是否支持并行传输,之所以能够根据该点播请求确定对应的客户端是否支持并行传输,这是因为为了能够确定发起点播请求的客户端类型、向谁返回目标数据文件以及如何返目标数据等后续待进行的操作,因此在发起该点播请求时,通常还会携带所在客户端的部分特征信息,可以包括:客户端型号、IP地址、使用的播放器类型、支持的数据传输接口类型等等信息,以便能够根据这些信息确定应使用何种形式组织将要返回的目标数据文件、基于哪种协议完成数据传输等等。
本申请的侧重点在于如何在数据文件分散存放在多个节点上的分布式存储形式下,实现尽可能快的将用户点播的目标音/视频内容呈现在用户眼前,因此本步骤旨在根据点播请求确定请求发起终端是否支持并行传输。当然,描述客户端是否支持并行传输的信息或字段并不唯一,由于不同类型的播放器在原理上还是存在较大的差异,因此可以根据不同的播放器实现相应的调整,目的在于确定请求发起端是否支持可实现数据加速传输的并行传输方式。
一种包括但不限于的方式为:根据支持的接口类型来判断,由于不同阶段为不同播放器设计的不同数据接口,可满足不同实际场景的要求,因此可基于此进行是否支持并行传输的判断。以HTML5(超文本标记语言第5版)播放器为例,若播放器所在客户端支持MSE接口或Fetch接口,HTML5播放器就可以同时多个下载链接从多个数据源下载数据文件。
Media Source Extensions(MSE)是Chrome、Safari、Edge等主流浏览器支持的一个新的Web API(网页接口)。MSE是一个W3C(万维网联盟)标准,允许JavaScript(一种直译式脚本语言,是浏览器的一部分)动态构建<video>(视频)和<audio>(音频)的媒体流。它定义了对象,允许JavaScript传输媒体流片段到一个HTMLMediaElement(HTML媒体元素)。通过使用MSE,可以动态地修改媒体流而不需要任何插件。这让前端JavaScript可以做更多的事情,例如在JavaScript进行转封装、处理,甚至转码。虽然MSE不能让流直接传输到mediatags(媒体标签)上,但是MSE提供了构建跨浏览器播放器的核心技术,让浏览器通过JavaScript API来推音视频到media tags上。
Fetch接口,更准确的说,Fetch接口是在Fetch框架下的一部分,在前端快速发展地过程中,为了契合更好的设计模式,产生了fetch框架,fetch框架简直就是为了提供更加强大、高效的网络请求而生,虽然在目前会有一点浏览器兼容的问题,可以使用fetch进行完美的网络请求。
在使用HTML5播放器的实际环境下,支持MSE接口和/或Fetch接口的客户端均可使得HTML5播放器实现并行传输的方式,实现加速点播的目的。
S103:当客户端支持并行传输时,获取构成目标音/视频的各内容分片分别所在的目标节点;
本步骤建立在S102的判断结果为发起点播请求的客户端支持并行传输的基础上,旨在确定构成目标音/视频的各内容分片分别所在的目标节点。
根据背景技术部分的描述,还预先将各数据文件分割为各个内容分片,并基于冗余的方式分散存储于各节点中,以实现去中心化的分布式存储,因此,相应的,在接收到一个音/视频内容的点播请求、且请求发起的客户端恰好支持并行传输时,就需要从各目标节点中取出该目标音/视频的各内容分片,以便将其重组后返回至请求发起的客户端用于播放。因此,本步骤旨在确定各内容分片的存储位置,在实际操作过程中,通常是借助记录有构成所有完整音/视频的各内容分片的节点存储信息的调度中心来确定目标节点的,在接收到目标音/视频的各内容分片的分布请求时,就会在自身的数据库中进行搜索,并将各内容分片所在节点的信息返回给请求端,以便请求端根据各节点信息同时与这些节点建立数据连接,以拉取各内容分片。进一步的,该调度中心还能够实施监听与其通信的各节点的是否在线等状态信息。
一种包括但不限于的实现方式为:
向调度中心发送目标音/视频的内容分片分布请求;
接收调度中心根据内容分片分布请求返回的包含有各内容分片所在节点的请求返回信息,并根据请求返回信息确定构成各目标节点。
进一步的,由于基于冗余的数据拆分存储方式,可能会使得某些内容分片会同时被存储于不同的节点中,意图在其中一个节点因异常掉线时还可以保证重组得到一个完整的数据文件,因此还可能涉及到如何从多个节点中选取一个节点,并从选中的节点中取出想要的内容分片,方式多种多样,可以基于优先级的方式、就近原因、主备机制等等措施,还可以在从选中的节点中取出的内容分片存在异常时,附加相应标记并及时更换另一节点,以充分实现冗余,此处并不做具体限定,可根据实际情况灵活选择。
S104:同时从各目标节点中拉取目标音/视频的各内容分片,并根据各内容分片的时间特征重新组装为完整音/视频;
在S103的基础上,本步骤旨在同时从各目标节点中拉取目标音/视频的各内容分片,并根据各内容分片的时间特征重新组装为完整音/视频。需要说明的是,此处描述的同时拉取,其能够实现的并行拉取的路数或并行数,不一定需要与内容分片数一致,可以在内容分片数较多的情况下,分几次完成所有内容分片的拉取过程,例如在目标音/视频由100个不同的内容分片组成时,且这100个内容分片分别存储于100个不同的节点上时,一种拉取方式为,同时拉取10个节点上的内容分片,共前后分10次完成全部内容分片的拉取。当然,根据实际情况的不同、不同接口类型支持的并行拉取数上限等限制因素,可进行灵活调整。
Range方式是其中一种多源数据拉取方式,也可以采用其它同类型的数据拉取方式来实现,此处并不做具体限定。
S105:将完整音/视频返回至客户端。
在S104的基础上,本步骤旨在将重组得到的完整音/视频通过相应的路径(包含于点播请求中,例如IP地址)返回至客户端,并利用客户端的播放器完成目标音/视频的播放。
区别于传统单点从数据服务器上拉取的方式,本申请在采用分布式存储的基础上,通过并行传输的方式实现了资源点播的加速。
基于上述技术方案,本申请实施例提供的一种音/视频内容的点播方法,在发起点播请求的客户端支持并行传输时,从构成目标音/视频文件的各内容分片分别所在的目标节点中同时拉取其中存储的内容分片,并在完成组装后将其传输至该客户端,以加速音/视频资源的点播速度,相较于传统从中心化服务器进行单点拉取的方式,从单路数据传输变为多路,在单路数据传输未达用户带宽上限时,可有效提升目标音/视频资源的点播速度,用户观看体验更佳。
实施例二
以下结合图2,图2为本申请实施例提供的音/视频内容的点播方法中一种确定是否支持并行传输的流程图,本实施例旨在针对S102给出一种具体的实现方式,该实现基于发起点播请求的客户端是否支持特定类型的接口来完成判断,具体步骤如下:
S201:从点播请求中提取得到客户端支持的接口类型;
S202:当接口类型包括MSE和/或Fetch接口时,判定客户端支持并行传输;
S203:当接口类型不包括MSE和/或Fetch接口时,判定客户端不支持并行传输。
需要说明的是,S202和S203是基于S201的两个并列步骤,而非如步骤名一样存在先后顺序。
相比于实施例一,通过本实施例提供的基于支持接口类型判断是否支持并行传输的方法,更加简单、易用,工程实现上更加方便。
实施例三
以下结合图3,图3为本申请实施例提供的音/视频内容的点播方法中一种不支持并行传输时实现音/视频内容播放的流程图,本实施例旨在S102判断得出该客户端不支持并行传输的基础上,给出一种变相实现加速音/视频内容点播的方式,具体实施步骤如下:
S301:根据各内容分片以及各内容分片分别所在的各目标节点建立数据拉取对应表;
本步骤旨在根据包含各内容分片与各节点间对应关系的数据拉取对应表确定构成目标音/视频内容的各内容分片所在的目标节点,以便从这些节点中获取各内容分片。
S302:当客户端不支持并行传输时,从可用节点池任选一个支持HTTP协议的HTTP节点;
由于发起点播请求的客户端不支持并行传输,因此只能基于传统的单点数据传输方式通过HTTP协议(HyperText Transfer Protocol,超文本传输协议)完成,因此还需要在可用节点池任选一个支持HTTP协议的HTTP节点,其中,可用节点池包含有数量庞大的可用节点,由于这些节点都是基于用户的设备提供的,因此存在支持协议不一的情况。
S303:将数据拉取对应表下发至HTTP节点,以使HTTP节点从各目标节点中拉取各内容分片,并在将各内容分片重新组成为完整音/视频后通过HTTP协议单点传输至客户端。
在S302的基础上,本步骤旨在将数据拉取对应表下发至HTTP节点,以使HTTP节点从各目标节点中拉取各内容分片,由于客户端不支持并行传输,因此其需要的完整音/视频数据必须从选中的HTTP节点中获取,由于通常情况下每个节点中只存储一些内容分片,因此在不存在完整音/视频的情况下,还需要根据数据拉取对应表完成数据补全,以便在将各内容分片重新组成为完整音/视频后通过HTTP协议单点传输至客户端。
在实施例一的基础上,本实施例在判断请求端不支持并行数据传输的方式下,通过对基于传统HTTP单点传输协议使用方法的改造在一定程度上提升了数据传输速度。
实施例四
以下结合图4,图4为本申请实施例提供的不支持并行传输时实现音/视频内容播放方法中一种选取优选HTTP节点的方法的流程图,本实施例在实施例三的基础上,提供了一种如何选取一个优选HTTP节点的方式,以最大化的优化用户的资源点播体验,实际情景为存在多个支持HTTP协议的节点,具体步骤如下:
S401:从可用节点池中选取所有支持HTTP协议的节点,得到初步可用节点集;
S402:根据初步可用节点集中各节点的网络质量选取得到一个优选HTTP节点;
其中,优选HTTP节点为初步可用节点集中网络质量最佳的节点。
本实施例旨在通过衡量各节点的网络质量的方式来选取得到一个优选HTPP节点,当然,还可以基于其它选取原则得到优选HTTP节点,目的在于尽可能的为用户提供一个好的资源点播体验。
S403:将数据拉取对应表下发至优选HTTP节点,以使优选HTTP节点从各目标节点中拉取各内容分片,并在将内容分片重新组装完整音/视频后通过HTTP协议单点传输至客户端。
相比于上述各实施例,本实施例在确定出所有支持HTTP协议的节点后,还根据网络质量这一因素选取得到拥有最佳网络质量的优选HTTP节点,以为用户提供尽可能最优的资源点播体验。
实施例五
下面请参见图5,图5为本申请实施例提供的一种音/视频内容的点播***的结构框图,该***可以包括:
点播请求接收单元100,用于接收目标音/视频的点播请求;
并行传输支持判断单元200,用于根据点播请求确定发起点播请求的客户端是否支持并行传输;
内容分片所在节点确定单元300,用于当客户端支持并行传输时,获取构成目标音/视频的各内容分片分别所在的目标节点;
多节点数据拉取及组装单元400,用于同时从各目标节点中拉取目标音/视频的各内容分片,并根据各内容分片的时间特征重新组装为完整音/视频;
完整音/视频返回单元500,用于将完整音/视频返回至客户端。
其中,并行传输支持判断单元200可以包括:
接口类型提取子单元,用于从点播请求中提取得到客户端支持的接口类型;
并行传输支持判定子单元,用于当接口类型包括MSE和/或Fetch接口时,判定客户端支持并行传输;
并行传输不支持判定子单元,用于当接口类型不包括MSE和/或Fetch接口时,判定客户端不支持并行传输。
其中,内容分片所在节点确定单元300可以包括:
分布请求发送子单元,用于向调度中心发送目标音/视频的内容分片分布请求;
各目标节点确定子单元,用于接收调度中心根据内容分片分布请求返回的包含有各内容分片所在节点的请求返回信息,并根据请求返回信息确定构成各目标节点。
其中,多节点数据拉取及组装单元400可以包括:
Range多源数据拉取子单元,用于以Range的方式同时从各目标节点中拉取目标音/视频的各内容分片。
进一步的,该点播方法还可以包括:
对应表建立单元,用于根据各内容分片以及各内容分片分别所在的各目标节点建立数据拉取对应表;
HTTP节点选取单元,用于当客户端不支持并行传输时,从可用节点池任选一个支持HTTP协议的HTTP节点;
单点传输处理单元,用于将数据拉取对应表下发至HTTP节点,以使HTTP节点从各目标节点中拉取各内容分片,并在将各内容分片重新组成为完整音/视频后通过HTTP协议单点传输至客户端。
更进一步的,HTTP节点选取单元可以包括:
初步可用节点集确定子单元,用于从可用节点池中选取所有支持HTTP协议的节点,得到初步可用节点集;
优选HTTP节点选取子单元,用于根据初步可用节点集中各节点的网络质量选取得到一个优选HTTP节点;其中,优选HTTP节点为初步可用节点集中网络质量最佳的节点;
单点传输处理单元可以包括:
优选HTTP节点传输子单元,用于将数据拉取对应表下发至优选HTTP节点,以使优选HTTP节点从各目标节点中拉取各内容分片,并在将内容分片重新组装完整音/视频后通过HTTP协议单点传输至客户端。
进一步的,该点播方法还可以包括:
冗余节点选取单元,用于当构成目标音/视频的一个内容分片同时位于N个节点上时,按预设选取规则从由N个节点组成的相同内容分片节点集中选取得到唯一的目标节点;其中,N≥2。
基于上述实施例,本申请还提供了一种音/视频内容的点播装置,该点播装置可以包括存储器和处理器,其中,该存储器中存有计算机程序,该处理器调用该存储器中的计算机程序时,可以实现上述实施例所提供的步骤。当然,该点播装置还可以包括各种必要的网络接口、电源以及其它零部件等。
实施例六
本实施例以玩客云为例,结合这一实际应用场景给出一种具体的实现方式,具体包括几个涉及到的部分,数量庞大的玩客云节点,每个玩客云设备都是一个节点,一个负责数据分布式存储和记录相关参数的星域云调度中心,以及SDK端,其中SDK端可具体表现为移动端(手机等移动设备)上的功能组件、固定端(PC等固定设备)上的功能组件、以及Web端上的网页浏览器功能组件,其中,移动端、固定端以及Web端均以客户端进行统一表述。
以下首先给出当客户端支持MSE和/或Fetch接口时,如何实现以并行传输实现资源点播加速的方式:
客户端支持H5的MSE,Fetch接口,即H5播放器能支持通过JS从多个节点拉取音视频数据分片,同时在端组装成完整的音视频文件,再通过接口将音视频数据传给H5的播放器,完成播放器的正常视频播放;
如图6所示,具体的流程如下:
1、客户端触发播放一个音视频文件,例如http://a.com/app/vodvedio.flv;
2、SDK检查该客户端JS是否支持MSE和/或Fetch接口;如果支持,则走到第3步;
3、SDK向星域云调度请求该视频文件有哪些玩客云有缓存资源,云调度返回一批有资源的节点给SDK端;
4、SDK发起这些接点的链接,连上后,通过RANGE方式,开始并发数据请求;完成数据视频文件的加速下载。
此处还给出了一种当客户端不支持MSE和/或Fetch接口时,以另一种方式实现变相资源点播加速的实现方式:
客户端不支持支持H5的MSE和/或Fetch接口,即H5播放器不能通过JS从多个节点拉取音视频数据分片,这类情形,H5播放器只支持从一个加速节点请求标准http协议,完成数据的加速下载。
如图7所示,具体的流程如下:
1、客户端触发播放一个音视频文件,例如http://a.com/app/vodvedio.flv;
2、SDK检查该客户端JS是否支持MSE和/或Fetch接口;如果不支持,则走到第3步;
3、SDK向星域云调度请求该视频文件有哪些玩客云有缓存资源,并且要求玩客云节点里面有支持HTTP协议的,云调度返回最优质的HTTP玩客云节点给SDK端;
4、SDK端通过HTTP协议向HTTP玩客云节点发起音视频数据请求;
5、HTTP玩客云节点上是否有该视频完整的数据,有的话,则全部传给SDK播放端,如果不全的话,请走到第6步;
6、该HTTP玩客云节点会同时从星域云调度发起获取有这个音视频资源的列表请求;
7、云调度返回一批命中资源的玩客云节点给HTTP玩客云节点;
8、HTTP玩客云节点会并发链接这批玩客云节点,同时发起拉取数据片的请求;
9、HTTP玩客云节点将完整的视频文件发送到播放端,完成播放端的文件加速和播放器。
因为情况复杂,无法一一列举进行阐述,本领域技术人员应能意识到根据本申请提供的基本方法原理结合实际情况可以存在很多的例子,在不付出足够的创造性劳动下,应均在本申请的保护范围内。
本申请还提供了一种计算机可读存储介质,其上存有计算机程序,该计算机程序被执行终端或处理器执行时可以实现上述实施例所提供的步骤。该存储介质可以包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random AccessMemory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
本文中应用了具体个例对本申请的原理及实施方式进行了阐述,且各个实施例间为递进关系,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言,可参见对应的方法部分说明。以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以对本申请进行若干改进和修饰,这些改进和修饰也落入本申请权利要求的保护范围内。
还需要说明的是,在本说明书中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其它要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
Claims (11)
1.一种音/视频内容的点播方法,其特征在于,包括:
接收目标音/视频的点播请求;
根据所述点播请求确定发起所述点播请求的客户端是否支持并行传输;
当所述客户端支持并行传输时,获取构成所述目标音/视频的各内容分片分别所在的目标节点;
同时从各所述目标节点中拉取所述目标音/视频的各内容分片,并根据各所述内容分片的时间特征重新组装为完整音/视频;
将所述完整音/视频返回至所述客户端。
2.根据权利要求1所述的点播方法,其特征在于,根据所述点播请求确定发起所述点播请求的客户端是否支持并行传输,包括:
从所述点播请求中提取得到所述客户端支持的接口类型;
当所述接口类型包括MSE和/或Fetch接口时,判定所述客户端支持并行传输;
当所述接口类型不包括所述MSE和/或所述Fetch接口时,判定所述客户端不支持并行传输。
3.根据权利要求1所述的点播方法,其特征在于,获取构成所述目标音/视频的各内容分片分别所在的目标节点,包括:
向调度中心发送所述目标音/视频的内容分片分布请求;
接收所述调度中心根据所述内容分片分布请求返回的包含有各所述内容分片所在节点的请求返回信息,并根据所述请求返回信息确定构成各所述目标节点。
4.根据权利要求1所述的点播方法,其特征在于,同时从各所述目标节点中拉取所述目标音/视频的各内容分片,包括:
以Range的方式同时从各所述目标节点中拉取所述目标音/视频的各内容分片。
5.根据权利要求1所述的点播方法,其特征在于,还包括:
根据各所述内容分片以及各所述内容分片分别所在的各目标节点建立数据拉取对应表。
6.根据权利要求5所述的点播方法,其特征在于,还包括:
当所述客户端不支持并行传输时,从可用节点池任选一个支持HTTP协议的HTTP节点;
将所述数据拉取对应表下发至所述HTTP节点,以使所述HTTP节点从各所述目标节点中拉取各所述内容分片,并在将各所述内容分片重新组成为所述完整音/视频后通过HTTP协议单点传输至所述客户端。
7.根据权利要求6所述的点播方法,其特征在于,从可用节点池任选一个支持HTTP协议的HTTP节点,包括:
从所述可用节点池中选取所有支持HTTP协议的节点,得到初步可用节点集;
根据所述初步可用节点集中各节点的网络质量选取得到一个优选HTTP节点;其中,所述优选HTTP节点为所述初步可用节点集中所述网络质量最佳的节点;
将所述数据拉取对应表下发至所述HTTP节点,以使所述HTTP节点从各所述目标节点中拉取各所述内容分片,并在将各所述内容分片重新组装为所述完整音/视频后通过HTTP协议单点传输至所述客户端,包括:
将所述数据拉取对应表下发至所述优选HTTP节点,以使所述优选HTTP节点从各所述目标节点中拉取各所述内容分片,并在将所述内容分片重新组装所述完整音/视频后通过HTTP协议单点传输至所述客户端。
8.根据权利要求1至7任一项所述的点播方法,其特征在于,还包括:
当构成所述目标音/视频的一个内容分片同时位于N个节点上时,按预设选取规则从由所述N个节点组成的相同内容分片节点集中选取得到唯一的所述目标节点;其中,N≥2。
9.一种音/视频内容的点播***,其特征在于,包括:
点播请求接收单元,用于接收目标音/视频的点播请求;
并行传输支持判断单元,用于根据所述点播请求确定发起所述点播请求的客户端是否支持并行传输;
内容分片所在节点确定单元,用于当所述客户端支持并行传输时,获取构成所述目标音/视频的各内容分片分别所在的目标节点;
多节点数据拉取及组装单元,用于同时从各所述目标节点中拉取所述目标音/视频的各内容分片,并根据各所述内容分片的时间特征重新组装为完整音/视频;
完整音/视频返回单元,用于将所述完整音/视频返回至所述客户端。
10.一种音/视频内容的点播装置,其特征在于,包括:
存储器,用于存储计算机程序;
处理器,用于执行所述计算机程序时实现如权利要求1至8任一项所述的音/视频内容的点播方法。
11.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如权利要求1至8任一项所述的音/视频内容的点播方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811082868.5A CN109005430B (zh) | 2018-09-17 | 2018-09-17 | 一种音/视频内容的点播方法、***、装置及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811082868.5A CN109005430B (zh) | 2018-09-17 | 2018-09-17 | 一种音/视频内容的点播方法、***、装置及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109005430A true CN109005430A (zh) | 2018-12-14 |
CN109005430B CN109005430B (zh) | 2021-05-18 |
Family
ID=64591856
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811082868.5A Active CN109005430B (zh) | 2018-09-17 | 2018-09-17 | 一种音/视频内容的点播方法、***、装置及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109005430B (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109714606A (zh) * | 2018-12-29 | 2019-05-03 | 深圳市网心科技有限公司 | 一种hls文件播放方法、***及电子设备和存储介质 |
CN109788301A (zh) * | 2019-01-08 | 2019-05-21 | 深圳市网心科技有限公司 | 一种流媒体的直播方法、终端设备、直播***及计算机可读存储介质 |
CN112929756A (zh) * | 2021-03-05 | 2021-06-08 | 深圳市迅雷网络技术有限公司 | 视频点播方法、p2p节点及计算机可读存储介质 |
CN114257835A (zh) * | 2021-12-31 | 2022-03-29 | 广东省教育研究院 | 基于教育云平台的直播***及其直播方法 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101087403A (zh) * | 2007-05-31 | 2007-12-12 | 吴彬 | 基于p2p技术上的分布式流媒体点播***及其点播流媒体节目的实现方法 |
CN101959054A (zh) * | 2009-07-14 | 2011-01-26 | 中国电信股份有限公司 | 集中式对等点播***和伙伴节点选择方法 |
CN102063486A (zh) * | 2010-12-28 | 2011-05-18 | 东北大学 | 一种面向多维数据管理的云计算平台查询处理方法 |
CN102143237A (zh) * | 2011-05-09 | 2011-08-03 | 宋健 | 一种基于网格的互联网内容分发方法和*** |
CN102196298A (zh) * | 2011-05-19 | 2011-09-21 | 广东星海数字家庭产业技术研究院有限公司 | 一种分布式视频点播***与方法 |
CN105392068A (zh) * | 2015-11-04 | 2016-03-09 | 合一网络技术(北京)有限公司 | 分布式多传输信道网络直播视频并行分发方法及*** |
US20170124173A1 (en) * | 2014-03-31 | 2017-05-04 | International Business Machines Corporation | Parallel bootstrap aggregating in a data warehouse appliance |
CN106789956A (zh) * | 2016-12-01 | 2017-05-31 | 武汉市烽视威科技有限公司 | 一种基于hls的p2p点播方法及*** |
-
2018
- 2018-09-17 CN CN201811082868.5A patent/CN109005430B/zh active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101087403A (zh) * | 2007-05-31 | 2007-12-12 | 吴彬 | 基于p2p技术上的分布式流媒体点播***及其点播流媒体节目的实现方法 |
CN101959054A (zh) * | 2009-07-14 | 2011-01-26 | 中国电信股份有限公司 | 集中式对等点播***和伙伴节点选择方法 |
CN102063486A (zh) * | 2010-12-28 | 2011-05-18 | 东北大学 | 一种面向多维数据管理的云计算平台查询处理方法 |
CN102143237A (zh) * | 2011-05-09 | 2011-08-03 | 宋健 | 一种基于网格的互联网内容分发方法和*** |
CN102196298A (zh) * | 2011-05-19 | 2011-09-21 | 广东星海数字家庭产业技术研究院有限公司 | 一种分布式视频点播***与方法 |
US20170124173A1 (en) * | 2014-03-31 | 2017-05-04 | International Business Machines Corporation | Parallel bootstrap aggregating in a data warehouse appliance |
CN105392068A (zh) * | 2015-11-04 | 2016-03-09 | 合一网络技术(北京)有限公司 | 分布式多传输信道网络直播视频并行分发方法及*** |
CN106789956A (zh) * | 2016-12-01 | 2017-05-31 | 武汉市烽视威科技有限公司 | 一种基于hls的p2p点播方法及*** |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109714606A (zh) * | 2018-12-29 | 2019-05-03 | 深圳市网心科技有限公司 | 一种hls文件播放方法、***及电子设备和存储介质 |
CN109788301A (zh) * | 2019-01-08 | 2019-05-21 | 深圳市网心科技有限公司 | 一种流媒体的直播方法、终端设备、直播***及计算机可读存储介质 |
CN109788301B (zh) * | 2019-01-08 | 2021-12-03 | 深圳市网心科技有限公司 | 一种流媒体的直播方法、终端设备、直播***及计算机可读存储介质 |
CN112929756A (zh) * | 2021-03-05 | 2021-06-08 | 深圳市迅雷网络技术有限公司 | 视频点播方法、p2p节点及计算机可读存储介质 |
CN114257835A (zh) * | 2021-12-31 | 2022-03-29 | 广东省教育研究院 | 基于教育云平台的直播***及其直播方法 |
Also Published As
Publication number | Publication date |
---|---|
CN109005430B (zh) | 2021-05-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109005430A (zh) | 一种音/视频内容的点播方法、***、装置及存储介质 | |
US9615119B2 (en) | Method and apparatus for providing timeshift service in digital broadcasting system and system thereof | |
US8595342B2 (en) | Synchronized media playback using autonomous clients over standard Internet protocols | |
KR100870587B1 (ko) | 멀티미디어 세션 관리 | |
WO2015043415A1 (zh) | 一种视频内容互动方法、装置及*** | |
CN103813185B (zh) | 一种分段节目快速分发的方法、服务器及客户端 | |
JP2011130018A (ja) | コンテンツ配信システム、コンテンツ配信装置、コンテンツ再生端末およびコンテンツ配信方法 | |
CN109600673A (zh) | 信息处理装置、信息处理方法、以及计算机可读介质 | |
EP2515536A1 (en) | Content distribution system, content distribution device, content playback terminal, and content distribution method | |
CN105828210A (zh) | 一种基于弹幕的点播歌曲的方法及装置 | |
CN108076383A (zh) | 自适应播放、控制方法、机顶盒及电子节目服务器 | |
CN103702178B (zh) | 一种播放方法及电子设备 | |
WO2011029355A1 (zh) | 节目推送方法、机顶盒及电子节目菜单 | |
WO2015070796A1 (zh) | 智能电视向移动通信终端推送资源的方法和装置 | |
CN101867777A (zh) | 一种基于对等计算机顶盒的视频点播传输方法 | |
WO2013097454A1 (zh) | 一种视频插播的方法、装置及*** | |
JP2010062963A (ja) | テレビ受像機およびテレビ受像機の処理方法 | |
JP2013232697A (ja) | コンテンツ転送装置及びコンテンツ転送方法、コンテンツ再生装置及びコンテンツ再生方法、コンテンツ配信システム、並びにコンピューター・プログラム | |
CN103596019B (zh) | 用于跨屏显示iptv内容的方法和*** | |
KR20170141677A (ko) | 수신 장치, 송신 장치 및 데이터 처리 방법 | |
CN108833552A (zh) | 一种混杂模式的p2p内容分发*** | |
JP2010154523A (ja) | コンテンツ放送システム及びコンテンツ放送方法 | |
CN107318052A (zh) | 电视机视频的播放方法、电视机及存储介质 | |
CN103139601B (zh) | Iptv业务的实现方法与装置 | |
CN106303754A (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 |