子流进行拼装。
[0051]本发明提出的方法，具体的是应用于【背景技术】中所述的针对带宽虚拟化的直播场景中。通过将视频的直播流按照需要拆分成若干子流，然后再通过虚拟化API的管理，将某个虚拟机所管理的所有终端节点拆分成若干子集合，每个子集合负责分发一条子流。对于视频内容消费端，首先通过第一次请求，得到一个直播流的描述信息SDP(sess1ndescript1n protocol)文件，里边记录了整个直播流的拆分情况，各个子流的描述情况，以便于消费端去获取各条子流并拼接成一个完整的直播流播放。本发明主要描述直播流的拆分，分发，以及客户端对子流的获取和拼接方法。
[0052]首先是拆分方法:
[0053]拆分直播流的目的是为了将直播流尽可能的等分成若干子流，然后起到降低单个子流码率，使其远小于终端RD设备所能提供的上行带宽(如至少小于终端RD设备所能提供的上行带宽的2/5)，从而达到抵抗突发的RD设备可用带宽变少的作用。这个子流码率的上限选取，由两个因素决定，第一个是RD设备的平均可用上行带宽AvgB，子流码率至少要是AvgB的1/2，这样，RD接受一路子流后，至少可以向外输出两路子流，起到了带宽放大的作用；另一个因素是需要抵抗RD设备的突发上行流量的影响，需要再预留一部分余量，在这里，这个余量带宽是由RD设备使用行为分析所得到，不同的RD设备，这个余量值并不一致。通过化整为零，达到仅利用低端低上行带宽设备就可以对高清直播加速的效果。具体的，按照内部传输协议和编码方式的不同，可以采用按时间等分，或者是按分片大小等分的办法，还有考虑关键帧的分割算法。
[0054]按时间等分，就是以1秒为单位，将每秒钟的原始直播流均分为N个子片。假如N=3，则要求分成3个子流，那么每当积累的数据超过1/3秒，就切一个子片。
[0055]按分片大小等分，那么就是按码流平均，假设码流是M，需要均分为N片，则每当收集的流数据超过M/N，则生成一个切片。比如码流是1000kbps，那么当积累的数据超过333kb后就切一个子片。
[0056]考虑关键帧的分割算法，由于视频关键帧通常远大于其他的帧，可以将关键帧单独分到一组，然后剩余的数据按照按时间戳或者分片大小的方案再等分，否则单纯按照时间或者大小等分，会造成含关键帧的子片大小远大于其他子片，达不到均分的目的。即只要收到关键帧，就只为关键帧生成一个切片，也就是关键帧子片，其他的数据再按照时间或者是大小来进行等分。具体的，如果需要N(N> = 3)等分，那么就是关键帧在一组，然后剩下的数据做N-1等分。但是由于关键帧的特殊性，其编号规则不能和普通帧一样，需要单独编号。这是因为，如果切关键帧时，普通帧的大小还不够成为一个新的子片，那么在复原时，关键帧就需要插入到这个后生成的普通子片中，而此时如果不独立编号，那么关键帧的编号就会比普通子片的要小，不利于后边播放器复原直播流。
[0057]从收到直播流开始，对所有子片从1开始编号，每切一个子片，编号加1。如果是针对关键帧单独分组，则采用独立编号，也是从1开始，每切一个关键帧，编号加1。特别的，直播流的元数据，如音视频的解码参数，直播流自带的描述信息，单独切成一个分片(子片)。对每个子片加一个内部协议头，协议头提供的信息包括但不限于:切片编号，起始时间戳，所属的直播流标识，切分方案，是否是关键帧分组还是普通分组等。特别的，元数据分片不需要加内部协议头，它通过不同于其他子片的方式分发。图2是一个切分的示意图。其中A表示音频帧，V表示视频帧，hdr表示新增加的切出的子片的头部。
[0058]分发方法:
[0059]首先以切片为单位将直播流推送到⑶N网络的边缘节点，一个切片对应一个子片，然后通过虚拟化API调度不同RD节点去传输不同的切片分组，由于切片基本是等分的，所以分组可以由取模的方法决定。即分组编号=切片编号mod子流数目，例如子流的数目是3，那么分组编号就是切片编号对3取模得到。对于纯关键帧分组，则就是独立编号，作为一个特殊分组，不和普通分组混淆。推送的方法，和普通的完整的直播流的推送方法一样，而选择RD分组的方法，则是在同一个VM虚拟机内部再按照运维配置的子流数目N值，决定如何选取RD的分组。一旦划分完毕，RD分组只会去选取和分发自己这个分组所对应的子流。
[0060]将每个单位时间内(Is)的视频流切分为若干个切片，每个切片有一个协议编号，而且这个编号是连续增长的(普通帧所在的切片)。
[0061]所以一个直播流切完了以后会是“1，2，3，4，5，6……”这样的编号序列，且会一直增长。而且如果每s切三片的话，编号“ 1，2，3”是第Is的数据，编号“4，5，6”是第2s的数据，以此类推。
[0062]即按照取模的办法，从上述序列中选取一批编号的切片，作为一个子流，并用不同的信道分发。
[0063]如:
[0064]子流1的子片编号:1，4, 7, 10….
[0065]子流2的子片编号:2，5，8，11....
[0066]子流3的子片编号:3，6, 9, 12....
[0067]这里用子流来表述，是因为每个子流是由不同协议编号的切片所组成，且会一直增长。
[0068]另外如上所述，每个子流有一个独立的编号，包含了一组编号一直增长的切片，这些切片的共同特征是他们的编号取某个模时，值相等。
[0069]并且这个子流编号对应了不同的传输信道，并在SDP里进行区分。即SDP只会给出子流的获取路径。
[0070]客户端请求及响应，以及拼接方法:
[0071]首先客户端拿到的是一个完整的直播url，这个地址是一个虚拟地址，标识这个直播流，客户端向服务器发出直播url请求，得到的是一个对于直播url进行描述的SDP文件。这个文件里会给出的数据包括子流的分割数目，每条子流的子频道编号，分组编号，分组类型，每条子流所对应的RD节点列表，也可能会包括直播流的元数据或者是元数据所对应的RD节点列表等。如果这里把元数据也通过某一组RD节点下发，这样在进行虚拟化API调度时，会独立给出一个RD分组来分发元数据。客户端在获得SDP文件后，首先会去获取元数据，接着会按照所有子流所对应的RD节点列表，从中选择一个或多个RD设备分别进行子流的请求。客户端还可以通过P2P的方式与其它客户端建立P2P连接，直接按编号请求缺少的子流切片数据。另一方面，客户端内部维护一个播放窗口，将获取到子流拆除内部协议头部，进行拼装。
[0072]如果子流的切分方法是不考虑关键帧分组的，则直接按子切片编号顺序排列，依次填到播放窗口的对应位置。如果有缺失造成不连续，就再次请求，和传统的P2P-CDN直播方式类似，将窗口分区，紧急需要立即使用的数据从RD节点获取，非紧急数据从其他客户端获取。对于数据缺失或者异常情况的处理也和传统方法相同，如重传，忽略，窗口直接略过缺失数据，从下一个关键帧开始播放等等。
[0073]如果子流的切分方法是包含关键帧分组的，那么需要进行多次排序，规则如下:
[0074]按照编号顺序对普通子流切片统一排序，这里是指所有的普通子流切片，不管它是哪个分组；
[0075]按照编号顺序对关键帧分组排序；
[0076]在普通切片和关键帧切片都连续的情况下，按照每一帧的时间戳先后决定装填到播放器播放缓冲区的顺序。这时的模型类似于将两个有序链表归并为一个有