CN102916989A - 一种视频下载方法、服务端及客户端 - Google Patents

Abstract

本发明实施例公开了一种视频下载方法，包括：服务端接收任一客户端发送的视频下载请求，所述视频下载请求包括：所请求的原始视频文件的网络路径和期望的转码参数；所述服务端根据所请求的原始视频文件的网络路径，获取所述客户端所请求的原始视频文件；所述服务端根据所述期望的转码参数和所述原始视频文件，获得所述客户端所请求的原始视频文件的转码文件；所述服务端将所述转码文件返回给所述客户端。本发明实施例还公开了一种服务端及客户端。本发明由服务端直接为各个客户端提供转码文件，使得转码过程和视频下载过程同步完成，提高视频下载效率，消除各个客户端单独进行视频转码带来的资源浪费。

Description

一种视频下载方法、服务端及客户端

技术领域

本发明涉及视频下载技术领域，尤其涉及一种视频下载方法、服务端及客户端。

背景技术

转码，是将视频从格式转换成另一种格式的过程。转码参数包括：输出容器格式、音视频编码和视频分辨率等信息的一组数据。网络路径，是指任何一种可以标识一个文件的方式，比如：用http（Hyper Text Transfer Protocol，超文件传输协议）、ed2k（eDonkey2000 network，文件共享网络）等URI（Uniform Resource Identifier，通用资源标志符）表示的文件地址，或者bt（bit torrent，比特流）种子文件。

目前，网络上可以下载的视频文件，其格式都千差万别；以容器格式（常称视频格式）为例，容器格式是一种用于容纳视频文件的视频流和音频流的数据组织方式，常见的有：AVI（Audio Video Interleaved，音视频交错格式）、MKV（Matroska File，媒体文件）、WMV（Windows Media Video，视频压缩格式）等格式；相同容器格式的视频文件，其音视频编码、视频分辨率等参数也会存在差异。客户端包括：手机、PDA（Personal Digital Assistant，个人数字助理）、MP4（Moving Pictures Experts Group 4，动态图像专家组4）播放器、PSP（PlayStation Portable，便携式游戏机）等设备，各种客户端所支持的视频格式存在差异，因此，从网络服务端下载至客户端的原始视频文件，往往需要经过转码处理，才能在客户端进行播放。

现有的视频下载方案为：客户端向服务端发送视频下载请求，该请求中包括所请求的原始视频文件的网络路径；所述服务端查询本端是否存在所请求的原始视频文件，若查询结果为是，则提取本端存储的原始视频文件返回给所述客户端；若查询结果为否，则根据所请求的原始视频的网络路径，从互联网的视频资源中下载所请求的原始视频文件返回给所述客户端；所述客户端根据本端所支持视频格式，对服务端返回的原始视频文件进行转码，得到转码文件并进行存储和/或播放。

转码是一个非常耗时的过程，例如：在一台P4、1.6G的计算机上，将1小时的影片从原始视频文件的格式（AVI，H264，1280*720）转码为新格式（MP4，H264，480*320），大概需要1.8小时左右才能完成。目前，市场上可应用于客户端的转码软件如：FFmpeg（Fast Forward MPEG，开源免费跨平台的视频和音频流方案）、格式工厂等都是单机软件，无法与互联网上针对相同视频文件、相同转码参数进行转码的其他客户端共享相同转码文件，因此，现有的视频下载方案中，各个客户端从服务端下载原始视频文件之后，每个客户端均单独进行转码过程，这样会耗费大量时间，导致用户等待时间过长；同时，针对相同视频文件和相同转码参数的转码过程在各个客户端重复多次，造成了资源的严重浪费。

发明内容

本发明实施例所要解决的技术问题在于，提供一种视频下载方法、服务端及客户端，由服务端直接为各个客户端提供转码文件，使得转码过程和视频下载过程同步完成，提高视频下载效率，消除各个客户端单独进行视频转码带来的资源浪费。

为了解决上述技术问题，本发明实施例提供了一种视频下载方法，包括：

服务端接收任一客户端发送的视频下载请求，所述视频下载请求包括：所请求的原始视频文件的网络路径和期望的转码参数；

所述服务端根据所请求的原始视频文件的网络路径，获取所述客户端所请求的原始视频文件；

所述服务端根据所述期望的转码参数和所述原始视频文件，获得所述客户端所请求的原始视频文件的转码文件；

所述服务端将所述转码文件返回给所述客户端。

相应地，本发明实施例还提供了一种服务端，包括：

请求接收模块，用于接收任一客户端发送的视频下载请求，所述视频下载请求包括：所请求的原始视频文件的网络路径和期望的转码参数；

原始文件获取模块，用于根据所述请求接收模块接收的视频下载请求中的所请求的原始视频文件的网络路径，获取所述客户端所请求的原始视频文件；

转码文件获取模块，用于根据所述请求接收模块接收的视频下载请求中的期望的转码参数和所述原始文件获取模块获取的原始视频文件，获得所述客户端所请求的原始视频文件的转码文件；

返回模块，用于将所述转码文件获取模块获得的转码文件返回给所述客户端。

相应地，本发明实施例还提供了一种客户端，包括：

请求模块，用于向服务端发送视频下载请求，所述视频下载请求包括：所请求的原始视频文件的网络路径和期望的转码参数；

接收模块，用于接收所述服务端返回的转码文件。

实施本发明实施例，具有如下有益效果：

1、本发明实施例的服务端接收到任一客户端的视频下载请求时，即读取所述客户端所请求的原始视频文件的网络路径和期望的转码参数，根据该视频下载请求直接向所述客户端返回期望的转码文件，使得转码过程和视频下载过程同步完成，提高了视频下载效率，消除了每个客户端单独进行视频转码带来的资源浪费；

2、本发明实施例中，服务端根据某转码参数对某视频文件进行首次转码后，即存储该转码文件，当再次接收到相同的视频下载请求时，服务端直接从本端提取该转码文件返回给请求的客户端，避免了相同转码过程的重复进行，大大降低了后续各个客户端视频下载的时间，提高了用户响应速度，消除了每个客户端单独进行视频转码带来的资源浪费。

附图说明

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

图1为本发明的服务端的第一实施例的结构示意图；

图2为图1所示的原始文件获取模块的实施例的结构示意图；

图3为图1所示的转码文件获取模块的实施例的结构示意图；

图4为本发明的服务端的第二实施例的结构示意图；

图5为本发明的客户端的实施例的结构示意图；

图6为图5所示的请求模块的实施例的结构示意图；

图7为本发明的视频下载方法的第一实施例的流程图；

图8为图7所示的步骤S102的实施例的具体流程图；

图9为图7所示的步骤S103的实施例的具体流程图；

图10为本发明的视频下载方法的第二实施例的流程图。

具体实施方式

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

下面结合附图1-4，对本发明实施例提供的服务端进行详细介绍。

请参见图1，为本发明的服务端的第一实施例的结构示意图；所述服务端包括：

请求接收模块101，用于接收任一客户端发送的视频下载请求，所述视频下载请求包括：所请求的原始视频文件的网络路径和期望的转码参数。

其中，所请求的原始视频文件的网络路径包括：所请求的原始视频文件的URI或bt种子；所述期望的转码参数包括：期望的输出容器格式、期望的音视频编码、期望的视频分辨率、期望的视频帧率和期望的视频码率中的任一种或多种。

原始文件获取模块102，用于根据所述请求接收模块101接收的视频下载请求中的所请求的原始视频文件的网络路径，获取所述客户端所请求的原始视频文件。

若所述客户端为首个请求下载该原始视频文件的客户端，所述客户端所请求的原始视频文件尚未存储于所述服务端，所述原始文件获取模块102需要根据所请求的原始视频文件的网络路径，从互联网提供的视频资源中获取所述客户端所请求的原始视频文件；若在所述客户端请求之前，已有其他客户端发出相同的视频下载请求并下载了该原始视频文件，则该原始视频文件已存储于所述服务端，所述原始文件获取模块102可直接从所述服务端中获取所述客户端所请求的原始视频文件。

转码文件获取模块103，用于根据所述请求接收模块101接收的视频下载请求中的期望的转码参数和所述原始文件获取模块102获取的原始视频文件，获得所述客户端所请求的原始视频文件的转码文件。

若所述客户端为首个请求下载视频文件的客户端，所述转码文件获取模块103需要根据所述期望的转码参数，在视频下载时同步进行转码得到转码文件；所述服务端对首次转码形成的转码文件进行存储。若在所述客户端请求之前，已有其他客户端发出相同的视频下载请求，则所述转码文件已存储于所述服务端，所述转码文件获取模块103可直接从所述服务端中获取所述客户端所请求的转码文件。

返回模块104，用于将所述转码文件获取模块103获得的转码文件返回给所述客户端。

所述返回模块104将所述转码文件获取模块103获得的转码文件返回给所述客户端，则完成了视频下载的过程，所述客户端接收到所述转码文件后，可直接进行播放，无需再在客户端进行转码，提高了用户响应速度。

本发明实施例的服务端直接为各个客户端提供转码文件，使得转码过程和视频下载过程同步完成，提高了视频下载效率，消除了各个客户端单独进行视频转码带来的资源浪费。

请参见图2，为图1所示的原始文件获取模块的实施例的结构示意图；所述原始文件获取模块102包括：

计算单元211，用于基于Hash算法对所请求的原始视频文件的网络路径U进行计算，获得所请求的原始视频文件的网络路径标识符U_KEY。

所述计算单元211所基于的hash算法可以为MD2（Message Digest Algorithm 2，消息摘要算法2）、MD4、MD5、HAVAL（密码散列函数）和SHA（Secure Hash Algorithm，安全散列算法）中的任一种或多种，所述计算单元211的计算过程与现有技术中基于上述各种算法的计算过程类似，在此不赘述。其中，所述计算单元211计算得到的所述U_KEY为与所述U一一对应的等长度的字符串，表明一个U_KEY可唯一标识一个U。需要说明的是，此处的U无论是采用http、ed2K等URI方式、bt种子或其他方式，只要用于识别相同的原始视频文件，则U均对应相同的U_KEY。

查询单元212，用于查询所述服务端是否存在所述计算单元211得到的U_KEY对应的原始视频文件U_FILE。

其中，所述U_KEY与所述原始视频文件U_FILE一一对应，表明U_KEY标识的网络路径U可以唯一识别所述原始视频文件U_FILE。若所述客户端为首个请求下载该原始视频文件的客户端，所述客户端所请求的原始视频文件U_FILE尚未存储于所述服务端，所述查询单元212无法从所述服务端中查询到U_KEY对应的原始视频文件U_FILE；若在所述客户端请求之前，已有其他客户端发出相同的视频下载请求，则该原始视频文件U_FILE已存储于所述服务端，所述查询单元212可从所述服务端中查询到U_KEY对应的原始视频文件U_FILE。

提取单元213，用于当所述查询单元212查询结果为是时，从所述服务端提取U_KEY对应的原始视频文件U_FILE。

下载单元214，用于当所述查询单元212查询结果为否时，从互联网中下载U对应的原始视频文件U_FILE。

当所述查询单元212查询结果为否时，表明所述服务端尚未存储所述客户端所请求的原始视频文件U_FILE，所述下载单元214根据该原始视频文件U_FILE的网络路径U，从互联网提供的视频资源中下载该原始视频文件U_FILE。需要说明的是，U可以为http或ed2K所表示的所述U_FILE的地址，U还可以为所述U_FILE的bt种子。

请参见图3，为图1所示的转码文件获取模块的实施例的结构示意图；所述转码文件获取模块103包括：

计算单元311，用于基于Hash算法对所述期望的转码参数P进行计算，获得期望的转码参数标识符P_KEY。

所述计算单元311所基于的hash算法可以为MD2、MD4、MD5、HAVAL和SHA中的任一种或多种，所述计算单元311的计算过程与现有技术中采用基于上述各种算法的计算过程类似，在此不赘述。其中，所述计算单元311计算得到的所述P_KEY为与所述P一一对应的等长度的字符串，表明一个P_KEY可唯一标识一组转码参数P。

处理单元312，用于对所述U_KEY和所述P_KEY进行处理，获得查询符UP_KEY。

所述处理单元312的处理过程为：将U_KEY和P_KEY进行字符串拼接，然后对拼接后的字符串基于Hash算法进行计算，得到UP_KEY；或者，将U_KEY和P_KEY进行按位加减，然后对按位加减的结果基于Hash算法进行计算，得到UP_KEY。所述处理单元312所基于的hash算法可以为MD2、MD4、MD5、HAVAL和SHA中的任一种或多种，其计算过程与现有技术中采用基于上述各种算法的计算过程类似，在此不赘述。可以理解的是，所述处理单元312还可以采用其他方式得到UP_KEY，其他方式下可类似分析，在此不赘述。

所述UP_KEY与所述U_KEY和所述P_KEY的组合一一对应，即一个U_KEY和一个P_KEY的组合，对应于唯一一个UP_KEY。

查询单元313，用于查询所述服务端是否存在UP_KEY对应的转码文件UP_FILE。

其中，所述UP_KEY与所述UP_FILE一一对应，表明针对U_KEY所对应的原始视频文件U_FILE，基于相同的转码参数（P_KEY标识的转码参数）进行转码后，得到唯一一个转码文件UP_FILE，该UP_FILE可通过唯一一个查询符UP_KEY查询到。若所述客户端为首个请求下载视频文件的客户端，所述客户端所请求的转码文件尚未存储于所述服务端，所述查询单元313无法从所述服务端中查询到UP_KEY对应的转码文件UP_FILE；若在所述客户端请求之前，已有其他客户端发出相同的视频下载请求，所述客户端所请求的转码文件已存储于所述服务端，所述查询单元313可从所述服务端查询到UP_KEY对应的转码文件UP_FILE。

提取单元314，用于当所述查询单元313查询结果为是时，从所述服务端提取UP_KEY对应的转码文件UP_FILE。

转码单元315，用于当所述查询单元313查询结果为否时，根据P对所述U_FILE进行转码，得到转码文件UP_FILE。

当所述查询单元313查询结果为否时，表明所述服务端尚未存储所述客户端所请求的转码文件，所述转码单元315根据P对所述U_FILE进行转码，得到UP_FILE。所述转码单元315的转码过程与现有方案中客户端的转码过程相同，在此不赘述。

请参见图4，为本发明的服务端的第二实施例的结构示意图；与图1-图3中提供的任一种服务端相同，所述服务端包括：请求接收模块101、原始文件获取模块102、转码文件获取模块103和返回模块104。本实施例中，所述服务端还包括：

存储模块105，用于当所述下载单元214从互联网中下载U对应的原始视频文件U_FILE之后，将所述U_FILE与所述U_KEY对应存储；和/或，当所述转码单元315得到UP_FILE之后，将所述UP_FILE与所述UP_KEY对应存储。

具体实现中，所述存储模块105可以为所述服务端的缓存器或存储器，若所述下载单元214从互联网中下载U对应的原始视频文件U_FILE，表明所述服务端尚未存储该U_FILE，所述存储模块105将所述U_FILE与所述U_KEY对应存储，当有客户端再次发出相同的视频下载请求时，所述服务端可以从本端直接提取U_KEY对应的U_FILE，快速做出响应。

若所述转码单元315得到UP_FILE，表明所述服务端首次对基于P_KEY对应的转码参数对原始视频文件U_FILE进行转码，所述存储模块105则将本次转码获得的UP_FILE与所述UP_KEY对应存储；当有客户端再次发出相同的视频下载请求时，所述服务端可以从本端直接提取UP_KEY对应的UP_FILE，快速返回给所述客户端。

本发明实施例中，服务端根据某转码参数对某视频文件进行首次转码后，即存储该转码文件，当再次接收到相同的视频下载请求时，服务端直接从本端提取该转码文件返回给请求的客户端，避免了相同转码过程的重复进行，大大降低了后续各个客户端视频下载的时间，提高了用户响应速度，消除了每个客户端单独进行视频转码带来的资源浪费。

下面将结合附图5-6，对本发明实施例提供的客户端进行详细介绍。

请参见图5，为本发明的客户端的实施例的结构示意图；所述客户端包括： 

请求模块201，用于向服务端发送视频下载请求，所述视频下载请求包括：所请求的原始视频文件的网络路径和期望的转码参数。

当所述客户端的用户想要从服务端下载视频时，所述请求模块201获取该用户所请求的原始视频文件的网络路径和期望的转码参数，并根据获取的所述用户所请求的原始视频文件的网络路径和期望的转码参数，生成视频下载请求发送至服务端。 

接收模块202，用于接收所述服务端返回的转码文件。

所述接收模块202在所述请求模块201向所述服务端发出视频下载请求后，接收所述服务端返回的转码文件。

请参见图6，为图5所示的请求模块的实施例的结构示意图；所述请求模块201包括：

获取单元121，用于获取用户所请求的原始视频文件的网络路径和期望的转码参数。

其中，所请求的原始视频文件的网络路径包括：所请求的原始视频文件的URI或bt种子；所述期望的转码参数包括：期望的输出容器格式、期望的音视频编码、期望的视频分辨率、期望的视频帧率和期望的视频码率中的任一种或多种。

当所述客户端的用户想要从服务端下载视频时，所述获取单元121即获取该用户所请求的原始视频文件的网络路径和期望的转码参数，其中，网络路径的获取过程如下：该用户可在客户端手动输入自己想要下载的视频文件的URI（如：视频的http链接地址）或bt种子，所述获取单元121则获取用户输入的URI或bt种子；或者，该用户可在客户端提供的页面中选择自己想要下载的视频文件，所述获取单元121则获取用户所选择的视频文件的URI或bt种子。其中，期望的转码参数的获取过程如下：用户可在客户端手动输入自己使用的客户端所支持的视频的参数（包括：容器格式、音视频编码、视频分辨率、视频帧率和视频码率等参数），所述获取单元121则获取用户输入的参数作为用户期望的转码参数。可以理解的是，所述获取单元121还可以采用其他方式获取用户所请求的原始视频文件的网络路径和期望的转码参数，当采用其他方式时可类似分析，在此不赘述。

封装单元122，用于对所述获取单元121获取的所请求的原始视频文件的网络路径和期望的转码参数进行封装，形成视频下载请求。所述封装单元122的封装过程与现有技术中各种消息的封装形成过程类似，在此不赘述。

发送单元123，用于将所述封装单元122形成的视频下载请求发送至服务端。

本发明实施例的客户端向服务端发送视频下载请求时，携带所请求的原始视频文件的网络路径和期望的转码参数，并接收所述服务端返回期望的转码文件，提高了视频下载效率。

需要说明的是，本发明实施例提供的客户端还可以包括播放模块，该播放模块可以为客户端的播放器设备，用于播放所述接收模块202接收到的转码文件。由于所述接收模块202接收到的所述转码文件为所述服务端根据所述客户端支持的转码参数转码形成，因此，所述客户端的播放模块可以直接播放所述接收模块202接收到的转码文件，无需再在客户端进行转码，提高了用户响应速度。

 

对应于本发明实施例在上述图1-图4中提供的任一种服务端，以及上述图5-图6中提供的任一种客户端，下面将结合附图7-10，对本发明实施例提供的视频下载方法进行详细介绍，上述本发明实施例提供的服务端及客户端可应用在下面本发明实施例提供的视频下载方法中。

请参见图7，为本发明的视频下载方法的第一实施例的流程图；所述方法包括：

S101，服务端接收任一客户端发送的视频下载请求，所述视频下载请求包括：所请求的原始视频文件的网络路径和期望的转码参数。

其中，所请求的原始视频文件的网络路径包括：所请求的原始视频文件的URI或bt种子；所述期望的转码参数包括：期望的输出容器格式、期望的音视频编码、期望的视频分辨率、期望的视频帧率和期望的视频码率中的任一种或多种。

S102，所述服务端根据所请求的原始视频文件的网络路径，获取所述客户端所请求的原始视频文件。

若所述客户端为首个请求下载该原始视频文件的客户端，所述客户端所请求的原始视频文件尚未存储于所述服务端，所述服务端在步骤S102中需要根据所请求的原始视频文件的网络路径，从互联网提供的视频资源中获取所述客户端所请求的原始视频文件；若在所述客户端请求之前，已有其他客户端发出相同的视频下载请求并下载了该原始视频文件，则该原始视频文件已存储于所述服务端，所述服务端在步骤S102中可直接从本端获取所述客户端所请求的原始视频文件。

请一并参见图8，为图7所示的步骤S102的实施例的具体流程图；步骤S102包括：

S21，所述服务端基于Hash算法对所请求的原始视频文件的网络路径U进行计算，获得所请求的原始视频文件的网络路径标识符U_KEY。

所述服务端在步骤S21中所基于的hash算法可以为MD2、MD4、MD5、HAVAL和SHA中的任一种或多种，步骤S21中的计算过程与现有技术中基于上述各种算法的计算过程类似，在此不赘述。其中，经过步骤S21计算得到的所述U_KEY为与所述U一一对应的等长度的字符串，表明一个U_KEY可唯一标识一个U。需要说明的是，此处的U无论是采用http、ed2K等URI方式、bt种子或其他方式，只要用于识别相同的原始视频文件，则U均对应相同的U_KEY。

S22，所述服务端查询本端是否存在U_KEY对应的原始视频文件U_FILE；若查询结果为是，转入S23；否则，转入S24。

其中，所述U_KEY与所述原始视频文件U_FILE一一对应，表明U_KEY标识的网络路径U可以唯一识别所述原始视频文件U_FILE。若所述客户端为首个请求下载该原始视频文件的客户端，所述客户端所请求的原始视频文件U_FILE尚未存储于所述服务端，步骤S22中，所述服务端无法从本端查询到U_KEY对应的原始视频文件U_FILE；若在所述客户端请求之前，已有其他客户端发出相同的视频下载请求，则该原始视频文件U_FILE已存储于所述服务端，步骤S22中，所述服务端可从本端直接查询到U_KEY对应的原始视频文件U_FILE。

S23，所述服务端从本端提取U_KEY对应的原始视频文件U_FILE；之后，转入步骤S103。

S24，所述服务端从互联网中下载U对应的原始视频文件U_FILE。

当步骤S22的查询结果为否时，表明所述服务端尚未存储所述客户端所请求的原始视频文件U_FILE，步骤S24中，所述服务端根据该原始视频文件U_FILE的网络路径U，从互联网提供的视频资源中下载该原始视频文件U_FILE。需要说明的是，U可以为http或ed2K所表示的所述U_FILE的地址，U还可以为所述U_FILE的bt种子。

图8所示的步骤S21-S24为图7所示的步骤S102的具体细化。可选地，执行完步骤S24后，可直接转入步骤S103继续执行；也可以转入执行步骤S25。

S25，所述服务端将所述U_FILE与所述U_KEY对应存储于本端；之后，转入步骤S103。

若所述服务端执行步骤S24，表明所述服务端尚未存储该U_FILE，步骤S25将所述U_FILE与所述U_KEY对应存储，当有客户端再次发出相同的视频下载请求时，所述服务端可以从本端直接提取U_KEY对应的U_FILE，快速做出响应。

S103，所述服务端根据所述期望的转码参数和所述原始视频文件，获得所述客户端所请求的原始视频文件的转码文件。

若所述客户端为首个请求下载视频文件的客户端，所述服务端在步骤S103中根据所述期望的转码参数，在视频下载时同步进行转码得到转码文件，并对首次转码形成的转码文件进行存储。若在所述客户端请求之前，已有其他客户端发出相同的视频下载请求，则所述转码文件已存储于所述服务端，所述服务端在步骤S103中可直接从所述本端获取所述客户端所请求的转码文件。

请一并参见图9，为图7所示的步骤S103的实施例的具体流程图；步骤S103包括：

S31，所述服务端基于Hash算法对所述期望的转码参数P进行计算，获得期望的转码参数标识符P_KEY。

步骤S31所基于的hash算法可以为MD2、MD4、MD5、HAVAL和SHA中的任一种或多种，步骤S31中的计算过程与现有技术中采用基于上述各种算法的计算过程类似，在此不赘述。其中，步骤S31计算得到的所述P_KEY为与所述P一一对应的等长度的字符串，表明一个P_KEY可唯一标识一组转码参数P。

S32，所述服务端对所述U_KEY和所述P_KEY进行处理，获得查询符UP_KEY。

步骤32的处理过程为：将U_KEY和P_KEY进行字符串拼接，然后对拼接后的字符串基于Hash算法进行计算，得到UP_KEY；或者，将U_KEY和P_KEY进行按位加减，然后对按位加减的结果基于Hash算法进行计算，得到UP_KEY。步骤S32所基于的hash算法可以为MD2、MD4、MD5、HAVAL和SHA中的任一种或多种，其计算过程与现有技术中采用基于上述各种算法的计算过程类似，在此不赘述。可以理解的是，步骤32中所述服务端还可以采用其他方式得到UP_KEY，其他方式下可类似分析，在此不赘述。

所述UP_KEY与所述U_KEY和所述P_KEY的组合一一对应，即一个U_KEY和一个P_KEY的组合，对应于唯一一个UP_KEY。

S33，所述服务端查询本端是否存在UP_KEY对应的转码文件；若查询结果为是，转入S34；否则，转入S35。

其中，所述UP_KEY与所述UP_FILE一一对应，表明针对U_KEY所对应的原始视频文件U_FILE，基于相同的转码参数（P_KEY标识的转码参数）进行转码后，得到唯一一个转码文件UP_FILE，该UP_FILE可通过唯一一个查询符UP_KEY查询。若所述客户端为首个请求下载视频文件的客户端，所述客户端所请求的转码文件尚未存储于所述服务端，在步骤S33中，所述服务端无法从本端查询到UP_KEY对应的转码文件UP_FILE；若在所述客户端请求之前，已有其他客户端发出相同的视频下载请求，所述客户端所请求的转码文件UP_FILE已存储于所述服务端，在步骤S33中，所述服务端可直接从本端查询到UP_KEY对应的转码文件UP_FILE。

S34，所述服务端从本端提取UP_KEY对应的转码文件UP_FILE；之后，转入步骤S104。

S35，若查询结果为否，所述服务端根据P对所述U_FILE进行转码，得到转码文件UP_FILE。

当步骤S33的查询结果为否时，表明所述服务端尚未存储所述客户端所请求的转码文件，在步骤S35中，所述服务端根据P对所述U_FILE进行转码，得到UP_FILE。步骤S35中所述服务端的转码过程与现有方案中客户端的转码过程相同，在此不赘述。

图9所示的步骤S31-S35为图7所示的步骤S103的具体细化。可选地，执行完步骤S35后，可直接转入步骤S104继续执行；也可以转入执行步骤S36。

S36，所述服务端将所述UP_FILE与所述UP_KEY对应存储于本端；之后，转入步骤S104。

若所述服务端执行步骤S35得到UP_FILE，表明所述服务端首次对基于P对应的转码参数对原始视频文件U_FILE进行转码，步骤S36则将本次转码获得的UP_FILE与所述UP_KEY对应存储；当有客户端再次发出相同的视频下载请求时，所述服务端可以从本端直接提取UP_KEY对应的UP_FILE，快速返回给所述客户端。

S104，所述服务端将所述转码文件返回给所述客户端。

步骤S104中，所述服务端将所述转码文件返回给所述客户端，则完成了视频下载的过程，所述客户端接收到所述转码文件后，可直接进行播放，无需再在客户端进行转码，提高了用户响应速度。

本发明实施例的服务端接收到任一客户端的视频下载请求时，即读取所述客户端所请求的原始视频文件的网络路径和期望的转码参数，根据该视频下载请求直接向所述客户端返回期望的转码文件，使得转码过程和视频下载过程同步完成，提高了视频下载效率，消除了每个客户端单独进行视频转码带来的资源浪费。

图10为本发明的视频下载方法的第二实施例的流程图，所述方法包括：

S201，客户端获取用户所请求的原始视频文件的网络路径和期望的转码参数。

其中，所请求的原始视频文件的网络路径包括：所请求的原始视频文件的URI或bt种子；所述期望的转码参数包括：期望的输出容器格式、期望的音视频编码、期望的视频分辨率、期望的视频帧率和期望的视频码率中的任一种或多种。

当所述客户端的用户想要从服务端下载视频时，所述客户端即执行步骤S201，获取该用户所请求的原始视频文件的网络路径和期望的转码参数，其中，网络路径的获取过程如下：该用户可在客户端手动输入自己想要下载的视频文件的URI（如：视频的http链接地址）或bt种子，所述客户端则获取用户输入的URI或bt种子；或者，该用户可在客户端提供的页面中选择自己想要下载的视频文件，所述客户端则获取用户所选择的视频文件的URI或bt种子。其中，期望的转码参数的获取过程如下：用户可在客户端手动输入自己使用的客户端所支持的视频的参数（包括：容器格式、音视频编码、视频分辨率、视频帧率和视频码率等参数），所述客户端则获取用户输入的参数作为用户期望的转码参数。可以理解的是，本步骤中，所述客户端还可以采用其他方式获取用户所请求的原始视频文件的网络路径和期望的转码参数，当采用其他方式时可类似分析，在此不赘述。

S202，所述客户端对获取的所请求的原始视频文件的网络路径和期望的转码参数进行封装，形成视频下载请求。步骤S202的封装过程与现有技术中各种消息的封装形成过程类似，在此不赘述。

S203，所述客户端将所述视频下载请求发送至服务端。

S204，服务端接收任一客户端发送的视频下载请求，所述视频下载请求包括：所请求的原始视频文件的网络路径和期望的转码参数。

S205，所述服务端根据所请求的原始视频文件的网络路径，获取所述客户端所请求的原始视频文件；

S206，所述服务端根据所述期望的转码参数和所述原始视频文件，获得所述客户端所请求的原始视频文件的转码文件。

S207，所述服务端将所述转码文件返回给所述客户端。

本实施例中，步骤S204-S207与图7所示实施例的步骤S101-S104相同，在此不赘述。

由于所述服务端向所述客户端返回的所述转码文件由所述服务端根据所述客户端支持的转码参数转码形成，因此，所述客户端接收到所述转码文件后，可以直接播放从所述服务端接收到的转码文件，无需再进行转码，提高了用户响应速度。

本发明实施例的服务端接收到任一客户端的视频下载请求时，直接向所述客户端返回期望的转码文件，使得转码过程和视频下载过程在服务端同步完成，提高了视频下载效率，消除了每个客户端单独进行视频转码带来的资源浪费；另外，客户端接收并直接播放所述服务端返回期望的转码文件，无需再进行转码，提高了用户响应速度。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体（Read-Only Memory，ROM）或随机存储记忆体（Random Access Memory，RAM）等。

以上所揭露的仅为本发明一种较佳实施例而已，当然不能以此来限定本发明之权利范围，本领域普通技术人员可以理解实现上述实施例的全部或部分流程，并依本发明权利要求所作的等同变化，仍属于发明所涵盖的范围。

Claims (11)

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

服务端接收任一客户端发送的视频下载请求，所述视频下载请求包括：所请求的原始视频文件的网络路径和期望的转码参数；

所述服务端根据所请求的原始视频文件的网络路径，获取所述客户端所请求的原始视频文件；

所述服务端根据所述期望的转码参数和所述原始视频文件，获得所述客户端所请求的原始视频文件的转码文件；

所述服务端将所述转码文件返回给所述客户端。

2.如权利要求1所述的方法，其特征在于，所述服务端接收任一客户端发送的视频下载请求之前，还包括：

客户端获取用户所请求的原始视频文件的网络路径和期望的转码参数；

所述客户端对获取的所请求的原始视频文件的网络路径和期望的转码参数进行封装，形成视频下载请求；

所述客户端将所述视频下载请求发送至服务端；

其中，所请求的原始视频文件的网络路径包括：所请求的原始视频文件的通用资源标志符URI或比特流bt种子；

所述期望的转码参数包括：期望的输出容器格式、期望的音视频编码、期望的视频分辨率、期望的视频帧率和期望的视频码率中的任一种或多种。

3.如权利要求1或2所述的方法，其特征在于，所述服务端根据所请求的原始视频文件的网络路径，获取所述客户端所请求的原始视频文件，包括：

所述服务端基于哈希Hash算法对所请求的原始视频文件的网络路径U进行计算，获得所请求的原始视频文件的网络路径标识符U_KEY；

所述服务端查询本端是否存在U_KEY对应的原始视频文件U_FILE；

若查询结果为是，所述服务端从本端提取U_KEY对应的原始视频文件U_FILE；

若查询结果为否，所述服务端从互联网中下载U对应的原始视频文件U_FILE，并将所述U_FILE与所述U_KEY对应存储于本端；

其中，所述U_KEY与所述U一一对应，所述U_KEY与所述U_FILE一一对应。

4.如权利要求3所述的方法，其特征在于，所述服务端根据所述期望的转码参数和所述原始视频文件，获得所述客户端所请求的原始视频文件的转码文件，包括：

所述服务端基于Hash算法对所述期望的转码参数P进行计算，获得期望的转码参数标识符P_KEY；

所述服务端对所述U_KEY和所述P_KEY进行处理，获得查询符UP_KEY；

所述服务端查询本端是否存在UP_KEY对应的转码文件UP_FILE；

若查询结果为是，所述服务端从本端提取UP_KEY对应的转码文件UP_FILE；

若查询结果为否，所述服务端根据P对所述U_FILE进行转码，得到转码文件UP_FILE，并将所述UP_FILE与所述UP_KEY对应存储于本端；

其中，所述P_KEY与所述P一一对应，所述UP_KEY与所述U_KEY和所述P_KEY的组合一一对应，所述UP_KEY与所述UP_FILE一一对应。

5.一种服务端，其特征在于，包括：

请求接收模块，用于接收任一客户端发送的视频下载请求，所述视频下载请求包括：所请求的原始视频文件的网络路径和期望的转码参数；

原始文件获取模块，用于根据所述请求接收模块接收的视频下载请求中的所请求的原始视频文件的网络路径，获取所述客户端所请求的原始视频文件；

转码文件获取模块，用于根据所述请求接收模块接收的视频下载请求中的期望的转码参数和所述原始文件获取模块获取的原始视频文件，获得所述客户端所请求的原始视频文件的转码文件；

返回模块，用于将所述转码文件获取模块获得的转码文件返回给所述客户端。

6.如权利要求5所述服务端，其特征在于，所述原始文件获取模块包括：

计算单元，用于基于Hash算法对所请求的原始视频文件的网络路径U进行计算，获得所请求的原始视频文件的网络路径标识符U_KEY；

查询单元，用于查询所述服务端是否存在所述计算单元得到的U_KEY对应的原始视频文件U_FILE；

提取单元，用于当所述查询单元查询结果为是时，从所述服务端提取U_KEY对应的原始视频文件U_FILE；

下载单元，用于当所述查询单元查询结果为否时，从互联网中下载U对应的原始视频文件U_FILE；

其中，所述U_KEY与所述U一一对应，所述U_KEY与所述U_FILE一一对应。

7.如权利要求6所述的服务端，其特征在于，所述转码文件获取模块包括：

计算单元，用于基于Hash算法对所述期望的转码参数P进行计算，获得期望的转码参数标识符P_KEY；

处理单元，用于对所述U_KEY和所述P_KEY进行处理，获得查询符UP_KEY；

查询单元，用于查询所述服务端是否存在UP_KEY对应的转码文件UP_FILE；

提取单元，用于当所述查询单元查询结果为是时，从所述服务端提取UP_KEY对应的转码文件UP_FILE；

转码单元，用于当所述查询单元查询结果为否时，根据P对所述U_FILE进行转码，得到转码文件UP_FILE；

其中，所述P_KEY与所述P一一对应，所述UP_KEY与所述U_KEY和所述P_KEY的组合一一对应, 所述UP_KEY与所述UP_FILE一一对应。

8.如权利要求7所述的服务端，其特征在于，还包括：

存储模块，用于当所述下载单元从互联网中下载U对应的原始视频文件U_FILE之后，将所述U_FILE与所述U_KEY对应存储；和/或，当所述转码单元得到UP_FILE之后，将所述UP_FILE与所述UP_KEY对应存储。

9.如权利要求5-8任一项所述的服务端，其特征在于，所请求的原始视频文件的网络路径包括：所请求的原始视频文件的URI或bt种子；

所述期望的转码参数包括：期望的输出容器格式、期望的音视频编码、期望的视频分辨率、期望的视频帧率和期望的视频码率中的任一种或多种。

10.一种客户端，其特征在于，包括：

请求模块，用于向服务端发送视频下载请求，所述视频下载请求包括：所请求的原始视频文件的网络路径和期望的转码参数；

接收模块，用于接收所述服务端返回的转码文件。

11.如权利要求10所述的客户端，其特征在于，所述请求模块包括：

获取单元，用于获取用户所请求的原始视频文件的网络路径和期望的转码参数；

封装单元，用于对所述获取单元获取的所请求的原始视频文件的网络路径和期望的转码参数进行封装，形成视频下载请求；

发送单元，用于将所述封装单元形成的视频下载请求发送至服务端；

其中，所请求的原始视频文件的网络路径包括：所请求的原始视频文件的URI或bt种子；

所述期望的转码参数包括：期望的输出容器格式、期望的音视频编码、期望的视频分辨率、期望的视频帧率和期望的视频码率中的任一种或多种。

Images