一种基于缓存编码的视频传输方法与流程

本发明涉及无线通信技术领域，具体地，涉及一种基于缓存编码的视频传输方法。

背景技术：

视频点播推动了今天的网络流量增长，这一趋势预计将持续到十年。事实上，一些研究预测，视频流量在2010年到2020年之间将增长12倍。视频流量本质上是随时间变化的，晚上有一个高峰。这种特性使得服务提供商的负担加重，即使在非高峰时间网络仍然未充分利用的情况下，必须扩展其网络以处理增加的峰值流量。缓存是通过在时间和整个网络中平滑流量来缓解此问题的关键技术。缓存使用分布在整个网络中的记忆在非高峰时间重复流行内容。在峰值流量时间期间，这些存储器然后用于以较少的压力在网络上传递所请求的内容。

传统的视频缓存点播技术，多个客户端同时在向服务器请求文件时，服务器一一响应每个客户端的请求，在客户端数量增加时，服务器传输的数据量增加，负担随之加重。

对现有的技术检索发现，mohammadalimaddah-ali等在2014年ieeetransactionsoninformationtheory发表的fundamentallimitsofcaching(缓存的基本限制)提出了缓存编码方案，与传统的未编码方案不同，编码缓存创建了不同用户所要求的内容块的线性组合。这样的组合使得每个用户可以使用本地的高速缓存的内容来恢复他所请求的块。因此，高速缓存不仅用于在本地传送部分内容，还用于创建编码多播机会。结果表明，对于一些基本的网络结构，编码缓存可以比未编码的缓存显着提高性能。广泛使用的缓存算法，如最不频繁使用(lfu)或最近最少使用的(lru)可能对于缓存网络而言是非常不理想的。ursniesen等在2015年ieeeinternationalconferenceoncommunications上发表的codedcachingfordelay-sensitivecontent(针对延迟敏感内容的编码缓存)提出了一种可计算地有效缓存算法，它提供了编码的增益和对延迟约束的约束。所提出的算法实现了大延迟的最佳性能，但是对于小的延迟仍然是主要的增益。但是该算法在理想条件下实现的，未考虑实际网络中丢包的影响。

技术实现要素：

针对现有技术中的缺陷，本发明的目的是提出一种基于缓存编码的视频传输方法，服务器端根据各客户端本地的缓存文件，将客户端请求的文件编码，并以单播或者广播的方式将请求文件发送到客户端，客户端利用本地缓存将收到的请求文件解码，得到请求的视频文件。

为达到上述目的，本发明所采用的技术方案如下：

一种基于缓存编码的视频传输方法，是按照如下步骤工作的：

步骤s1，服务器对视频文件进行预处理，并在客户端分配缓存；

受传输协议的限制，每次传输的视频文件的大小应该被限定在一定大小范围内，而视频文件被切成小文件后不能直接播放，所以首先将视频文件切割成可播放的ts文件，然后将每个ts文件切割为等大小的小文件(切割文件)，并对小文件进行编号；将小文件(切割文件)中的至少一部分作为缓存文件分配至客户端。下文中的缓存文件、请求文件均指切割后的小文件；

服务器内储存每个视频的全部小文件作为请求文件，并且已知每个客户端的缓存文件，具体地，服务器已知每个客户端关于每个视频的缓存文件；每个客户端储存每个视频的部分缓存文件，由于切割每个ts文件生成的最后一个小文件的大小通常会小于规定的文件大小，所以规定每个客户端一定缓存每个ts文件的最后一个小文件，这样也方便获取ts文件切割后的小文件数量，以便恢复ts文件。

步骤s2，客户端播放视频文件前，向服务器发送请求；

客户端在播放某个视频文件前，根据本地已有的该视频的缓存文件，将需要向服务器请求的请求文件生成请求列表，客户端将列表中的请求一一以单播的方式发送给服务器；

客户端将每个请求发送之后，将请求加入到已发送请求队列。客户端对加入已发送请求队列的每个请求设置一个定时器，在定时器结束之前，若客户端没有收到该请求的请求文件，客户端在计时器结束时会再次发送该请求。

步骤s3，服务器收到请求，处理该请求；

服务器在收到客户端发送的请求后，判断该请求是否是来自对应客户端的第一次请求。

若该请求是来自对应客户端的第一次请求，服务器将该请求加入待发送请求队列；否则，服务器立即向客户端以单播的方式发送信息，信息中包含客户端请求的请求文件、客户端的信息以及客户端的请求。

服务器为每个请求以及队列中元素设置定时器。第一次到达的请求加入待发送请求队列时，从队首元素开始，对队列中的每个元素与第一次到达的请求进行比较，判断当前元素是否可以与第一次到达的请求进行合并。如果合并，将当前元素与第一次到达的请求合并，合并后元素的定时器与未合并之前当前元素的定时器保持一致；否则，将第一次到达的请求作为一个新元素加入到队尾，该新元素的定时器与第一次到达请求的定时器保持一致。

待发送请求队列中的元素与第一次到达的请求进行比较时，如果第一次到达的请求对应客户端的缓存文件中包含当前元素中的所有客户端的请求文件，并且当前元素内的每个客户端的缓存文件都包含第一次到达请求的请求文件，则该元素可与第一次到达请求合并；否则，不能合并。

步骤s4，服务器将客户端请求的请求文件编码，并发送给客户端；

在待发送请求队列队首元素的定时器到达规定时间时，服务器判断该元素中包含的客户端请求的数量。若该元素只包含一个客户端的请求，则服务器向该客户端以单播的方式发送信息，信息包括客户端的请求文件、客户端的信息以及客户端的请求；若该元素包含两个或以上客户端的请求，对该元素中包含的请求文件进行编码，具体地，将该元素中所有请求文件的内容进行异或，得到新文件，并将新文件的内容、该元素中所有的客户端的信息以及对应客户端的请求作为发送信息，以广播的方式发送给客户端。

步骤s5，客户端收到服务器发送的请求文件，并解码该客户端所请求的请求文件

客户端在收到信息后，首先判断该信息中是否包含本客户端的请求。若包含本客户端的请求，首先将该请求从已发送请求队列中移除，然后将信息中包含的所有请求文件内容提取出来，最后根据本地缓存文件中已有的其他客户端请求的请求文件将收到的请求文件解码，得到本客户端所请求的请求文件，具体地，将收到的请求文件内容与本地缓存文件中已有的其他客户端请求的请求文件进行异或，即可得到本客户端所请求的请求文件。

步骤s6，客户端播放视频文件

在客户端解码得到请求的请求文件之后，根据每个ts文件切割后最后一个文件判断本地是否已获得该ts文件切割后的全部文件，具体方式为，最后一个文件的编号包含了该ts文件的切割文件的数量的信息，判断其是否与本地已有的该ts文件的切割文件的数量相等。在获取某ts文件的全部切割文件后，恢复该ts文件，并按ts文件编号的顺序将ts文件的信息写入到m3u8文件中，当m3u8文件写入第一个ts文件的信息后即可播放视频文件。

与现有技术相比，本发明具有如下有益效果：

第一，本发明利用无线广播的特性，混合单播与广播的传输方式，减少了服务器端的传输次数和传输数据量；

第二，本发明考虑了实时视频传输的需求，为客户端的请求设置定时器，保证客户端播放视频的流畅度；

第三，本发明考虑网络丢包的情况，加入了重传的机制，保证了客户端播放视频的完整性。

附图说明

通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1是本发明的工作流程图；

图2是本发明的工作架构；

图3是本发明的文件合并过程的具体实例；

图4是本发明的包含两个客户端的视频文件传输具体实例；

图5为本发明的实验结果。

具体实施方式

下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进。这些都属于本发明的保护范围。

参见图1，下面更详细地将本发明的实施过程进行阐述。

第一步，处理视频文件，将视频文件切割成可播放的ts文件，然后将每个ts文件切割为等大小的小文件(切割文件)，并对小文件进行编号。服务器内储存每个视频的全部切割文件作为请求文件，并且已知每个客户端的缓存方案(缓存文件)；客户端储存每个视频的部分缓存文件并且必须缓存每个ts文件的最后一个文件。

第二步，客户端在播放某个视频前，根据本地已有的该视频的缓存文件，将需要向服务器请求的文件生成请求列表，客户端将列表中的请求一一以单播的方式发送给服务器；客户端将每个请求发送之后，将请求加入到已发送请求队列。客户端对加入已发送请求队列的每个请求设置一个定时器，在定时器结束之前，若客户端没有收到该请求的文件，客户端在计时器结束时会再次发送该请求。

第三步，服务器在收到客户端发送的请求后，若该请求为来自该客户端的第一次请求，将该请求加入待发送请求队列，否则，服务器立即向客户端以单播的方式发送信息，信息中包含客户端的请求文件、客户端的信息以及客户端的请求。服务器为每个请求以及队列中元素设置定时器。第一次到达的请求加入待发送请求队列时，从队首元素开始，对每个队列中的元素与待加入的请求进行比较，如果待加入请求客户端的缓存文件中包含元素中的所有客户端的请求文件，并且元素内的每个客户端的缓存文件都包含待加入请求的请求文件，则该元素可与待加入请求合并，将当前元素与待加入的请求合并，合并后元素的定时器与未合并之前元素的定时器保持一致；否则，将待加入的请求作为一个元素加入到队尾，该元素的定时器与待加入请求的定时器保持一致。

第四步，在待发送请求队列队首元素的定时器到达规定时间时，该元素只包含一个客户端的请求，则服务器向该客户端以单播的方式发送信息，信息中包括客户端的请求文件，客户端的信息以及客户端的请求；若该元素包含两个或以上客户端的请求，服务器将元素中所有请求文件的内容进行异或，得到新的文件，并将新文件的内容，元素中所有的客户端的信息以及对应的请求作为发送信息，以广播的方式发送给客户端。

第五步，客户端在收到信息后，若该信息中包含该客户端的请求，首先将该请求从已发送请求队列中移除，然后将信息中包含的所有请求和文件内容提取出来，最后将收到的文件内容与本地缓存文件中已有的其他客户端请求的文件进行异或，即可得到本客户端所请求的文件。

第六步，在客户端解码得到请求的文件之后，根据每个ts文件切割后最后一个文件判断本地是否已获得该ts文件切割后的全部文件。在获取某ts文件的全部切割文件后，恢复该ts文件，并按ts文件编号的顺序将ts文件的信息写入到m3u8文件中，当m3u8文件写入第一个ts文件的信息后播放该视频。

本实施例以图3对文件的合并过程进行说明，本方法中包含一个服务器与两个客户端，服务器端缓存了所有文件，包括文件1，文件2，文件3和文件4；客户端a缓存了文件1和文件2，客户端b缓存了文件1和文件3。客户端a向服务器请求文件3与文件4，客户端b向服务器请求文件2与文件4。服务器在收到两个客户端的请求之后，将所有的请求加入到待发送请求队列，由于客户端a中缓存了客户端b请求文件2，同时，客户端b缓存了客户端a请求的文件3，因此可以将这两个请求合并，并将编码后的文件广播发送给两个客户端；而客户端a和客户端b请求的文件4都不在对方的缓存中，因此服务器需要将文件4一一发送给两个客户端。

本实施例以图4对含有两个客户端的视频文件传输系统进行说明，该系统中包含了一个服务器与两个客户端，在客户端发送请求之前，将两个视频文件按本实施例的要求处理，服务器中储存两个视频的全部切割文件，每个客户端分别随机缓存每个视频的文件总数约50％的切割文件，客户端a播放视频1，客户端b播放视频2，并向服务器发送对应的请求。实验结果图5所示，在实验室环境下，该系统采用本实施例提供的视频传输方法，与传统方案相比，可以得到约25％的增益，并且视频播放过程流畅。

尽管本发明的内容已经通过上述优选实施例作了详细介绍，但应当认识到上述的描述不应被认为是对本发明的限制。在本领域技术人员阅读了上述内容后，对于本发明的多种修改和替代都将是显而易见的。因此，本发明的保护范围应由所附的权利要求来限定。