CN105872599A

CN105872599A - 一种提供、下载视频的方法及设备

Info

Publication number: CN105872599A
Application number: CN201610266874.0A
Authority: CN
Inventors: 韩旭
Original assignee: Leshi Zhixin Electronic Technology Tianjin Co Ltd; LeTV Holding Beijing Co Ltd
Current assignee: Leshi Zhixin Electronic Technology Tianjin Co Ltd; LeTV Holding Beijing Co Ltd
Priority date: 2016-04-26
Filing date: 2016-04-26
Publication date: 2016-08-17
Also published as: WO2017185601A1

Abstract

本发明实施例提供一种提供、下载视频的方法及设备，包括：在网络侧提供视频时，向终端提供至少一个描述信息，一个描述信息与一个视频片段相匹配，一个视频文件由若干视频片段组成，并根据终端发送的下载请求向终端提供视频片段。在终端侧下载视频时，根据描述信息确定需要下载的视频片段；向网络侧发送下载请求，所述下载请求用于供终端指示网络侧所需下载的视频片段。采用本发明实施例中提供的技术方案，用户不再只能被动的进行下载观看，或者，仅仅只能按照视频的分段进行下载观看，而是使用户能够按照自身的需求进行视频的选择及观看。

Description

一种提供、下载视频的方法及设备

技术领域

本发明实施例涉及视频技术领域，尤其涉及一种提供、下载视频的方法及设备。

背景技术

视频点播系统主要由片源库系统、流媒体服务系统、影柜系统、传输及交换网络、用户终端设备机顶盒+电视机或个人计算机组成。

在视频点播时，当用户发出点播请求时，流媒体服务系统就会根据点播信息，将存放在片源库中的节目信息检索出来，以视频和音频流文件，通过高速传输网络传送到用户终端。

在点播的过程中，在播放端放置缓冲区，流式传输将动画、音频和视频等多媒体经过特殊的压缩方式分成一个个压缩包，由视频服务器向用户计算机连续、实时地传送。在采用流式传输方式的系统中，用户不必象非流式播放那样等到整个文件全部下载完毕后才能看到具体的内容，只需经过几秒或几十秒的启动延时即可利用相应播放器对压缩的动画、音频、视频等流式多媒体文件解压后进行播放，多媒体文件的剩余部分也将在后台的服务器内继续下载。

但现有技术的不足在于：在该过程中，用户只能被动的进行观看，或者，按照视频的分段进行观看；用户不能按照自身的需求进行选择及观看。

发明内容

本发明实施例提供了一种提供、下载视频的方法及设备，用以解决现有技术中，用户不能快速浏览想看的精彩内容或重点内容的缺陷。

本发明实施例提供一种提供视频的方法，包括：

向终端提供至少一个描述信息，一个描述信息与一个视频片段相匹配，一个视频文件由若干视频片段组成；

根据终端发送的下载请求向终端提供视频片段，所述下载请求用于供终端指示网络侧所需下载的视频片段。

本发明实施例提供一种下载视频的方法，包括：

接收网络侧向终端提供的至少一个描述信息，一个描述信息与一个视频片段相匹配，一个视频文件由若干视频片段组成；

根据描述信息确定需要下载的视频片段；

向网络侧发送下载请求，所述下载请求用于供终端指示网络侧所需下载的视频片段。

本发明实施例提供一种提供视频的设备，包括：

信息提供模块，用于向终端提供至少一个描述信息，一个描述信息与一个视频片段相匹配，一个视频文件由若干视频片段组成；

视频提供模块，用于根据终端发送的下载请求向终端提供视频片段，所述下载请求用于供终端指示网络侧所需下载的视频片段。

本发明实施例提供一种下载视频的设备，包括：

信息接收模块，用于接收网络侧向终端提供的至少一个描述信息，一个描述信息与一个视频片段相匹配，一个视频文件由若干视频片段组成；

视频确定模块，用于根据描述信息确定需要下载的视频片段；

视频下载模块，用于向网络侧发送下载请求，所述下载请求用于供终端指示网络侧所需下载的视频片段。

在本发明实施例提供的一种提供、下载视频的方法及设备中，由于网络侧首先向终端提供了与视频片段相匹配的描述信息，使得终端能够依据描述信息确定需要下载的视频片段，这样，用户不再只能被动的进行下载观看，或者，仅仅只能按照视频的分段进行下载观看，实现了用户按照自身的需求进行视频的选择及观看。

进一步的，由于不再需要增加额外的存储空间去单独存储精彩内容或重点内容的“精彩视频”，所以可以使片源方节省大量存储空间。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例中网络侧提供视频的方法实施流程示意图；

图2为本发明实施例中终端侧下载视频的方法实施流程示意图；

图3为本发明实施例中网络侧提供视频的设备结构示意图；

图4为本发明实施例中终端侧下载视频的设备结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

发明人在发明过程中注意到：

现有机制下用户不能自主的去观看某个自己需要观看的视频片段。以用户点播一部电影为例，一部电影通常会有一些代表性的精彩片段，而这些片段的出现位置并不固定。这样，如果在现有的点播机制下，用户只能被动的进行观看，或者，按照视频的分段进行观看；当用户需要只观看精彩片段时，用户并不能按照自身的需求进行选择、观看。

进一步的，为了满足这部分仅看精彩片断的用户，商家不得不将这些片段经过后期人工编辑成独立的视频，然后放在网络服务器上供用户观看。这种方式至少带来以下问题：

由于每部电影的精彩片断出现位置不固定，且内容也需要进行判断，因此不得不采用人工的方式去进行编辑，这无疑会照成大量的人工浪费；另外，由于编辑后的视频实质上是一个与原电影视频并无关系的视频文件，因此用户要观看就不得不额外的进行检索或者去获取，这也将增加用户方的投入。

基于此，本发明实施例中提供了一种视频播放方案，用以使用户能够主动的观看自己需要视频部分，下面进行说明。

在说明过程中，将分别从终端与网络侧的实施进行说明，其中网络侧将说明提供视频片段的过程，终端侧将说明视频片段下载的过程，然后还将给出二者配合实施的实例以更好地理解本发明实施例中给出的方案的实施。这样的说明方式并不意味着二者必须配合实施、或者必须单独实施，实际上，当终端与网络侧分开实施时，其也各自解决终端侧、网络侧的问题，而二者结合使用时，会获得更好的技术效果。

图1为网络侧提供视频的方法实施流程示意图，如图所示，可以包括：

步骤101、向终端提供至少一个描述信息，一个描述信息与一个视频片段相匹配，一个视频文件由若干视频片段组成；

步骤102、根据终端发送的下载请求向终端提供视频片段，所述下载请求用于供终端指示网络侧所需下载的视频片段。

图2为终端侧下载视频的方法实施流程示意图，如图所示，可以包括：

步骤201、接收网络侧向终端提供的至少一个描述信息，一个描述信息与一个视频片段相匹配，一个视频文件由若干视频片段组成；

步骤202、根据描述信息确定需要下载的视频片段；

步骤203、向网络侧发送下载请求，所述下载请求用于供终端指示网络侧所需下载的视频片段。

实施中，描述信息可以是在向终端提供的视频片段的播放列表中携带的。可以是，视频提供方在制作播放列表时，按照视频实际的情节，抽取出精彩内容或重点内容，然后在播放列表中添加一种标记标识出精彩内容或重点内容。

具体实施中，播放列表可以是按HLS(HTTP Live Streaming，Apple的动态码率自适应技术)协议播放视频文件时传输的播放列表。

下面具体以HLS协议下的实施进行说明，以HLS协议为例是因为HLS传输内容包括两部分，一是M3U8描述文件，二是TS媒体文件。一方面这样的结构比较容易实现本发明实施例中提供的技术方案，另一方面是因为HLS协议是目前比较常用、比较具有代表性的技术，所以这里以HLS协议为例；但是，本发明实施例提供的技术方案在于，是在将视频文件分割为视频片段后，在传输前，将携带视频片段的描述信息发送至终端供其选择下载对象，容易理解，从理论上来说，用其它的协议、或者其他手段、或者专门配置相应的技术方案来实现也是可以的，因此，以HLS协议为例仅用于教导本领域技术人员具体如何实施本发明，但不意味仅能使用HLS协议来实现，实施过程中可以结合实践需要来确定相应的技术手段。

下面先对HLS进行简单说明。

HLS，Http Live Streaming是由Apple公司定义的用于实时流传输的协议，HLS基于HTTP协议实现，传输内容包括两部分，一是播放列表M3U8描述文件，二是TS媒体文件。

1、M3U8文件：

用文本方式对媒体文件进行描述，由一系列标签组成。具体是对MPEG2-TS片段的ID、时长、url下载地址信息进行描述。

#EXTM3U

#EXT-X-TARGETDURATION:5

#EXTINF:5,

http://xxxx././0.ts

#EXTINF:3,

http://xxxx././1.ts

#EXTINF:4,

http://xxxx././2.ts

#EXTINF:5,

http://xxxx././3.ts

#EXTINF:5,

http://xxxx././4.ts

#ENDLIST

#EXTM3U：每个M3U8文件第一行必须是这个tag。

#EXT-X-TARGETDURATION：指定最大的媒体段时间长度(秒)，#EXTINF中指定的时间长度必须小于或等于这个最大值。该值只能出现一次。

#EXTINF：描述单个媒体文件的长度。后面为媒体文件的url地址，如http://xxxx./0.ts

下面是添加描述信息后的M3U8播放列表文件格式：

1、M3U8文件：

用文本方式对媒体文件进行描述，由一系列标签组成。具体是对MPEG2-TS片段的ID、时长、url下载地址信息进行描述。假设我们通过观看视频，发现播放列表中1.ts的内容是全片中最精彩或最重要的，那么我们在EXTINFO:3后面再加如一个描述信息的标签，比如(但不局限于)“#MARK”。

#EXTM3U

#EXT-X-TARGETDURATION:5

#EXTINF:5,

http://xxxx././0.ts

#EXTINF:3,#MARK

http://xxxx././1.ts

#EXTINF:4,

http://xxxx././2.ts

#EXTINF:5,

http://xxxx././3.ts

#EXTINF:5,

http://xxxx././4.ts

#ENDLIST

2、TS文件

DVB定义的文件格式，用于音视频的网络传输，其中音视频按时间戳进行交织。每个数据包大小为188个字节。

在点播时，先传输播放列表，然后终端根据播放列表进行url的下载，获取到TS的数据，然后进行TS数据的解析，进而得到H264 sample和AACsample数据以及pts时间戳信息，送给解码器进行解码。

容易看出，实施中可以将描述信息通过在向终端提供的视频片段的播放列表M3U8文件中携带。然后根据描述信息确定需要下载的视频片段，下载后播放即可。显然，下载播放的视频片段即为自身需要的视频片段。

以用户点播一部电影为例，设该部电影具有一些代表性的精彩片段，设这些片段包括：

与涉及精彩风景内容A有关的视频片段a1、a2；

与涉及精彩人物内容B有关的视频片段b1、b2；

与涉及精彩动作内容C有关的视频片段c1、c2。

容易理解，每部影片精彩的内容一般都不相同，组成的视频片段数量一般也不相同，一般情况下视频片段的出现位置也不相同。

假设将涉及精彩风景内容的视频片段a1、a2标签为#MARK-A；涉及精彩人物内容的视频片段b1、b2标签为#MARK-B；涉及精彩动作内容的视频片段c1、c2标签为#MARK-C。

那么，在采用HLS协议进行视频文件网络传输时，会先传输播放列表，然后终端根据播放列表进行url的下载，获取到TS的数据，然后进行TS数据的解析，进而得到H264 sample和AAC sample数据以及pts时间戳信息，然后进行播放。

则在本实施例中，在播放列表中，视频片段的描述信息中将会出现该视频片段相匹配的描述信息：也即标签。在上例中，则将会在播放列表中，出现视频片段a1、a2标签#MARK-A，视频片段b1、b2标签#MARK-B，视频片段c1、c2标签#MARK-C。

播放列表样式如下：

#EXTM3U

#EXT-X-TARGETDURATION:5

#EXTINF:5,#MARK-A

http://xxxx././a1.ts

#EXTINF:3,#MARK-A

http://xxxx././a2.ts

#EXTINF:4,#MARK-B

http://xxxx././b1.ts

#EXTINF:5,#MARK-B

http://xxxx././b2.ts

#EXTINF:5,#MARK-C

http://xxxx././c1.ts

#EXTINF:5,#MARK-C

http://xxxx././c2.ts

#ENDLIST

在终端接收到播放列表后，若需要观看涉及精彩风景内容的片段，则只需根据描述信息标签MARK-A确定需要下载的视频片段为视频片段a1、a2，然后终端根据播放列表进行视频片段a1、a2的url的下载，获取到视频片段a1、a2的获取到视频片段a1、a2的TS的数据，然后进行TS数据的解析，进而得到H264 sample和AAC sample数据以及pts时间戳信息，然后进行播放即可。

同理，若需要观看涉及精彩动作内容的片段，则下载标签为MARK-C的视频片段c1、c2。

例中仅是简单的以MARK-A、MARK-B、MARK-C来标签视频片段，实际上可以采用多种方式，如本例中约定MARK-A代表涉及风景、MARK-C代表涉及动作，终端只需识别MARK-A、MARK-C便可获知该视频片段涉及的内容。当然也可以直接标识，例如直接将视频片段c1、c2的标签指明为：涉及动作。

基于同一发明构思，本发明实施例中还提供了一种提供、下载视频设备，由于这些设备解决问题的原理与一种提供、下载视频的方法相似，因此这些设备的实施可以参见方法的实施，重复之处不再赘述。

图3为网络侧提供视频的设备结构示意图，如图所示，可以包括：

信息提供模块301，用于向终端提供至少一个描述信息，一个描述信息与一个视频片段相匹配，一个视频文件由若干视频片段组成；

视频提供模块302，用于根据终端发送的下载请求向终端提供视频片段，所述下载请求用于供终端指示网络侧所需下载的视频片段。

实施中，信息提供模块可以进一步用于在向终端提供的视频片段的播放列表中携带所述描述信息。

实施中，所述播放列表可以是按HLS协议播放视频文件时传输的播放列表。

图4为终端侧下载视频的设备结构示意图，如图所示，可以包括：

信息接收模块401，用于接收网络侧向终端提供的至少一个描述信息，一个描述信息与一个视频片段相匹配，一个视频文件由若干视频片段组成；

视频确定模块402，用于根据描述信息确定需要下载的视频片段；

视频下载模块403，用于向网络侧发送下载请求，所述下载请求用于供终端指示网络侧所需下载的视频片段。

实施中，信息接收模块可以进一步用于接收在网络侧向终端提供的视频片段的播放列表中携带的所述描述信息。

综上所述，现有技术中，通常一部电影的精彩片段都是需要人为后期剪辑，生成一个几分钟的新片，放到网络服务器上，供给用户观看。而通过本发明实施例提供的技术方案可以免去这个新片的生成，只需要通过描述信息便可以使用户确认自己需要的片段，自行下载即可，不用再额外生成新的“精彩视频”，大大节省网络存储空间。同理，由于没有生成额外的“精彩视频”，所以用户也不再需要去网络上搜索精彩片段成片进行观看。事实上，这样下载的“精彩视频”本质上是用户自己剪辑而成的，更为契合用户需求，能够明显提升用户的服务感受。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims

1.一种提供视频的方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，所述描述信息是在向终端提供的视频片段的播放列表中携带的。

3.根据权利要求2所述的方法，其特征在于，所述播放列表是按HLS协议播放视频文件时传输的播放列表。

4.一种下载视频的方法，其特征在于，包括：

根据描述信息确定需要下载的视频片段；

5.根据权利要求4所述的方法，其特征在于，所述描述信息是在向终端提供的视频片段的播放列表中携带的。

6.根据权利要求5所述的方法，其特征在于，所述播放列表是按HLS协议播放视频文件时传输的播放列表。

7.一种提供视频的设备，其特征在于，包括：

8.根据权利要求7所述的设备，其特征在于，信息提供模块进一步用于在向终端提供的视频片段的播放列表中携带所述描述信息。

9.根据权利要求8所述的设备，其特征在于，所述播放列表是按HLS协议播放视频文件时传输的播放列表。

10.一种下载视频的设备，其特征在于，包括：

11.根据权利要求10所述的设备，其特征在于，信息接收模块进一步用于接收在网络侧向终端提供的视频片段的播放列表中携带的所述描述信息。

12.根据权利要求11所述的设备，其特征在于，所述播放列表是按HLS协议播放视频文件时传输的播放列表。