本发明涉及视频播放技术，更具体地，涉及一种视频直播方法及视频直播服务器。
背景技术：
视频编码将画面(即帧)分为i、p、b三种，i帧采用帧内独立编码，而p帧和b帧是参考已编码的帧进行帧间预测编码，可以说p帧、b帧记录的是与之前编码的画面的差异。没有i帧，p帧和b帧是无法解码。画面组(gop：groupofpictures)是一段连续的可以独立解码的画面。一段长视频可以按照gop切分成一个个独立的小片段。一个gop可以包括多个i帧，但第一帧一定是i帧。每一个视频帧都带着一个播放时间戳(pts：presentationtimestamp)，表示这一帧在什么时间点播放出来。图1示出了gop的结构，其中标记了“i”、“p”和“b”的长方形分别表示i帧、p帧和b帧，无标记的长方形代表了相应时间段内的一组音频帧。图中一个gop包含的视频帧的数量和组合方式仅仅是示意性的，不同的视频中该数量和组合方式可以不同。
观看视频直播时，卡顿率、播放延时(从主播拍摄画面到观众看到画面的延时)、首屏开启延时(从用户点开直播频道到看到画面的等待时间)是影响直播用户体验的三个重要方面。
因为没有i帧，p帧和b帧是无法解码的。用户要想看视频必须从gop的头部也即第一帧开始接收数据。例如，服务器在图1中箭头所示的时间点接收到用户的直播请求，文中将该时间点称为启播时间点，也可以称为接入时间点。该启播时间点和视频帧之间存在着时间上的位置关系，该启播时间点对应于一个视频帧的播放时间(该视频帧称为启播时间点所在的视频帧)，有些视频帧在该启播时间点之前，有些视频帧在该启播时间点之后。图中所示的启播时间点上视频尚未播放到i帧，此时服务器需要等到直播流的下一个i帧才开始下发数据，用户经过长时间等待才能看到画面，这种下发方式的首屏开启延时长，用户体验不好。
在一些致力于减少首屏开启延时的方案中，在视频直播服务器上缓存一个gop的数据，在接收到用户的直播请求时，从启播时间点所在的gop(也称为当前gop)的头部开始下发数据，如图1所示。这种方式省去了等待下一个i帧到来的时间，减小了首屏开启延时。但是会引入了较大的播放延时。假如启播时间点距离当前gop头部原本的播放时间点相差2秒，那么播放延时就会一直多这2秒，同样会影响用户体验。
技术实现要素：
有鉴于此，本申请提供了一种视频直播方法，包括：
服务器将视频直播的源数据分别压缩为启播数据和常规数据，所述启播数据的画面组gop的长度小于所述常规数据的gop的长度；
所述服务器收到直播请求后，确定所述启播数据中启播时间点所在的当前gop，从该当前gop的头部开始先下发所述启播数据；
所述服务器从所述常规数据中位于启播时间点之后的一个gop的头部开始，改为下发所述常规数据。
本申请还提供了一种视频直播服务器，包括：
数据压缩模块，设置为：将视频直播的源数据分别压缩为启播数据和常规数据，所述启播数据的画面组gop的长度小于所述常规数据的gop的长度；
启播下发模块，设置为：在收到直播请求后，确定所述启播数据中启播时间点所在的当前gop，从该当前gop的头部开始先下发所述启播数据；
常规下发模块，设置为：从所述常规数据中位于启播时间点之后的一个gop的头部开始，改为下发所述常规数据。
本申请还提供了一种视频直播服务器，包括处理器和存储器，其中：
所述存储器，设置为：保存程序代码；
所述处理器，设置为：读取所述程序代码并执行以下处理：将视频直播的源数据分别压缩为启播数据和常规数据；收到直播请求后，确定所述启播数据中启播时间点所在的当前gop，从该当前gop的头部开始先下发所述启播数据；及，从所述常规数据中位于启播时间点之后的一个常规gop的头部开始，改为下发所述常规数据；其中，所述启播数据的画面组gop的长度小于所述常规数据的gop的长度。
上述方案通过先下发gop较小的启播数据，使得首屏开启延时和播放延时均较小，而后改为下发gop较大的常规数据，也不会导致码率明显上升而提高直播业务的成本。
有鉴于此，本申请提供了一种视频直播方法，包括：
服务器收到直播请求后，确定待下发视频数据中启播时间点所在的当前画面组gop；
所述服务器修改所述当前gop中视频帧的播放时间戳，使得播放时间戳被修改的视频帧之间的播放间隔变小；
所述服务器完成所述修改后，从所述当前gop的头部开始下发所述视频数据。
本申请还提供了一种视频直播服务器，包括：
画面组确定模块，设置为：在收到直播请求后，确定待下发视频数据中启播时间点所在的当前画面组gop；
时间戳修改模块，设置为：修改所述当前gop中视频帧的播放时间戳，使得播放时间戳被修改的视频帧之间的播放间隔变小；
数据下发模块，设置为：在所述时间戳修改模块完成所述修改后，从所述当前gop的头部开始下发所述视频数据。
本申请还提供了一种视频直播服务器，包括处理器和存储器，其中：
所述存储器，设置为：保存程序代码；
所述处理器，设置为：读取所述程序代码并执行以下处理：在收到直播请求后，确定待下发视频数据中启播时间点所在的当前画面组gop；修改所述当前gop中视频帧的播放时间戳，使得播放时间戳被修改的视频帧之间的播放间隔变小；及，完成所述修改后，从所述当前gop的头部开始下发所述视频数据。
上述方案在收到直播请求后即开始下发数据，客户端收到后即可开始播放，因而首屏开启延时小，而通过对时间戳的修改，进一步减小了播放延时。
附图说明
图1是gop结构及相关技术下发数据的示意图；
图2是本发明实施例一视频直播方法的流程图；
图3是本发明实施例一修改时间戳的3种方式的示意图；
图4是本发明实施例一视频直播服务器的模块图；
图5是本发明实施例二视频直播方法的流程图；
图6是本发明实施例二视频直播服务器的模块图；
图7是本发明实施例三服务器下发视频数据的示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。
实施例一
本实施例视频直播方法如图2所示，包括
步骤110，服务器收到直播请求后，确定待下发视频数据中启播时间点所在的当前画面组gop；
本实施例的服务器可以是下发直播数据的任何设备如cdn节点。本实施例是从当前gop下发，服务器中需要缓存至少一个gop的数据。
步骤120，所述服务器修改所述当前gop中视频帧的播放时间戳，使得播放时间戳被修改的视频帧之间的播放间隔变小；
本实施例中，所述服务器修改所述当前gop中视频帧的播放时间戳，包括：将所述当前gop中位于启播时间点之前的所有视频帧的时间戳修改为启播时间点所在的视频帧的时间戳。为了不让用户观看直播流一直有3帧的滞后，对视频帧的时间戳进行修改。如图3所示，为了方便示意，将启播时间点所在的视频帧的时间戳用0表示，启播时间点之前的第一个视频帧、第二个视频帧和第三个视频帧(该帧为当前gop的第一个i帧)的时间戳分别用-1、-2和-3表示，启播时间点之后的第一个视频帧、第二个视频帧的时间戳分别用1和2表示，则本实施例对时间戳的修改如图中的pts1所示，是将前播放点之前的第一个视频帧、第二个视频帧和第三个视频帧的时间戳均修改为0，播放间隔为0，同时各个视频帧对应的音频帧的时间戳应当统一修改。这样，客户端按照修改后的时间戳播放该3个视频帧时，3帧画面一闪而过，可以直接追上播放进度，且在当前时间点之后的视频帧将按照正常速度播放。这3个视频帧对应的音频帧也不会播放。
在pts1所示的时间戳修改方式中，服务器将启播时间点之前的音频帧全部下发，而在pts2所示的另一时间戳修改方式中，服务器对启播时间点之前的音频帧不进行下发，以节约流量。
图3中的pts2示出了又一种时间戳修改方式，在该方式下，服务器将启播时间点之前的第一个视频帧、第二个视频帧和第三个视频帧的时间戳均修改为-1，也即修改为启播时间点之前的第一个视频帧的时间戳。客户端的播放器一般需要收到音频帧才会启动播放，在这种方式下，客户端会先收到当前gop中第一个i帧对应的音频帧，有利于及时启动播放。
但是，本发明的时间戳修改方式并不局限于以上三种。在其他实施例中，还可以是对当前gop中所有视频帧的播放时间戳进行修改，并且也并不排除对当前gop之后的gop中视频帧的播放时间戳进行修改。通过对一个或多个gop中视频帧的播放时间戳的修改，使得该多个gop的播放速度加快，也可以达到逐步消除播放延时的效果。
步骤130，所述服务器完成所述修改后，从所述当前gop的头部开始下发所述视频数据。
客户端的播放器接收到下发的视频数据后，会按照修改后的时间戳进行播放，播放器本身并不需要进行修改。
另需说明的是，本实施例待下发的视频数据可以是一种视频数据，也可以包括多种视频数据。如下文实施二中服务器将视频直播的源数据压缩为两种不同的数据，先下发启播数据，再下发常规数据。在此场景下应用本实施例方案时，待下发视频数据可以包括启播放数据和常规数据，其中当前gop是启播数据中的gop。
本实施例还提供了一种视频直播服务器，如图4所示，包括：
画面组确定模块10，设置为：在收到直播请求后，确定待下发视频数据中启播时间点所在的当前画面组gop；
时间戳修改模块20，设置为：修改所述当前gop中视频帧的播放时间戳，使得播放时间戳被修改的视频帧之间的播放间隔变小；
数据下发模块30，设置为：在所述时间戳修改模块完成所述修改后，从所述当前gop的头部开始下发所述视频数据。
可选地，所述时间戳修改模块修改所述当前gop中视频帧的播放时间戳，包括：将所述当前gop中位于启播时间点之前的所有视频帧的时间戳修改为启播时间点所在的视频帧的时间戳，或修改为启播时间点之前第一个视频帧的时间戳。
可选地，所述数据下发模块从所述当前gop的头部开始下发所述视频数据，包括：对所述当前gop中位于启播时间点之前的音频帧，不进行下发或者只进行部分下发。
本实施例方法流程中描述的任何处理，如对时间戳的各种修改方式，均可以通过本实施例视频直播服务器中相应模块来实现，这里不再赘述。
本实施例还提供了一种视频直播服务器，包括处理器和存储器，其中：
所述存储器，设置为：保存程序代码；
所述处理器，设置为：读取所述程序代码并执行以下处理：在收到直播请求后，确定待下发视频数据中启播时间点所在的当前画面组gop；修改所述当前gop中视频帧的播放时间戳，使得播放时间戳被修改的视频帧之间的播放间隔变小；及，完成所述修改后，从所述当前gop的头部开始下发所述视频数据。
本实施例方法流程中描述的任何处理，如对时间戳的各种修改方式，均可以通过本实施例视频直播服务器的处理器来执行，这里不再赘述。
本实施例方案在收到直播请求后即开始下发数据，客户端收到后即可开始播放，因而首屏开启延时小。而通过对时间戳的修改，又可以加快部分视频帧的播放速度，减小播放延时，保证播放的实时性。
实施例二
视频直播的过程可以分为以下阶段：a，客户端与服务器建立连接并接收视频数据；b，客户端解析视频数据，获取视频头信息；c，当客户端视频帧的缓冲(buffer)达到可播放的量之后，开始播放。假定阶段a建立连接的耗时为t1，阶段b解析视频数据的耗时为t2，客户端帧buffer达到可播放的量的下载耗时为t3，首屏开启延时为t，则有：t＝t1+max(t2,t3)。实测时，通常是t3占据了首屏开启延时的大部分。假定常规播放器设定当帧buffer达到了n秒数据后即可启播，当前视频数据的码率为br，用户下载带宽为bw，启播时间点距离当前gop头部的时间为m秒，假定对这m秒数据中视频帧的时间戳进行修改使其一闪而过，则这m秒数据不能算作启播buffer，这样可以得到：t3＝br(m+n)/bw
为了首屏开启快，可以通过设置较小的gop以减小m，例如从5秒一个gop减少到2秒一个，这样可以保证m<2。但这样做的代价是直播流中的i帧增多了，导致相同画质下码率上升10～25％。从而增加直播业务的带宽成本。
为了首屏开启快，还可以将n设为0，甚至在客户端收到第一帧视频数据的时候就开始播放。但是，如果bw不是远远大于br，客户端收到的数据会被瞬间清空而发生卡顿。buffer处于空的状态下启播，是危险的事情。
为了首屏开启快，还可以降低br，但会导致画质降低。
如上分析，减小n卡顿率上升，减小br画质会降低，减小m流量成本升高，而bw是客户端的网速决定，服务提供方无法控制。本实施例减小首屏开启延时的策略是：通过服务器侧的处理，在启播时降低br和m，而且不引入额外的带宽成本代价。
如图5所示，本实施例视频直播方法包括：
步骤210，服务器将视频直播的源数据分别压缩为启播数据和常规数据，所述启播数据的画面组gop的长度小于所述常规数据的gop的长度；
本实施例的服务器可以是下发直播数据的任何设备如cdn节点。
本步骤中，视频直播的源数据是主播录制并向服务端推送的数据。压缩后的两种数据称为启播数据和常规数据，仅仅是为了区别两者，也可以叫其他的名称，如第一路数据和第二路数据等等。本实施例中，启播数据和常规数据可以分别承载在两路视频流中，但在其他实施例中，这两种数据也可以承载在一路视频流中，即在一路视频流中包含两路视频数据。为了从当前gop的头部下发，服务器中需要缓存至少一个gop的启播数据。
本实施例中，启播数据的gop的长度较小，因而m较小(m小于启播数据的gop长度)，使t3变小，从而减小了首屏开启延时t。
本文中，限定所述启播数据的gop的长度小于所述常规数据的gop的长度，即意味着常规数据中的i帧少于启播数据中的i帧(本发明并不包括gop长度小的数据中i帧数量却等于或多于gop长度大的数据的情况，这些情况往往采用了特定的i帧设置，并不属于本发明讨论的情形)，因为仅仅在开始阶段下发少量的启播数据，随后即改为下发常规数据，因而并不会导致码率明显上升而增加直播业务的带宽成本。
本实施例中，可选地，所述启播数据的码率低于所述常规数据的码率，即常规数据画面的清晰度更高。因为开始下发的数据总是包括启播数据，上述公式中的br变小，使得t3变小，从而进一步减小了首屏开启延时t。
本实施例中，可选地，所述常规数据中每个gop的第一个i帧均与所述启播数据中一个相应的i帧对齐。i帧的对应使下发数据改变时，播放的内容不发生跳跃，播放更为流畅。
另外，上文中“源数据分别压缩为启播数据和常规数据”的描述，并不排除将源数据分别压缩为更多种数据，如三种以上的数据，只要其中包括本实施例使用的启播数据和常规数据即可。
步骤220，所述服务器收到直播请求后，确定所述启播数据中启播时间点所在的当前gop，从该当前gop的头部开始先下发所述启播数据；
本实施例中，通过对视频帧时间戳的修改进一步减小播放延时。具体地，所述服务器开始下发所述启播数据之前，还包括：修改所述当前gop中视频帧的播放时间戳，使得播放时间戳被修改的视频帧之间的播放间隔变小。例如，可以将所述当前gop中位于启播时间点之前的所有视频帧的时间戳修改为启播时间点所在的视频帧的时间戳，或修改为启播时间点之前第一个视频帧的时间戳。本实施例对视频帧时间戳的修改，可以采用实施例一中描述的各种方式。这里不再重复说明。特别地，如果采用对多个gop中视频帧的时间戳进行修改的方式，则也可以对常规数据gop中视频帧的时间戳进行修改。
步骤230，所述服务器从所述常规数据中位于启播时间点之后的一个gop的头部开始，改为下发所述常规数据。
本实施例中，所述服务器从所述当前gop的头部开始下发所述启播数据，包括：对所述当前gop中位于启播时间点之前的音频帧，不进行下发或者只进行部分下发。在进行部分下发时，可以下发当前gop中第一个i帧对应的音频帧。
本实施例中，所述服务器从所述常规数据中位于启播时间点之后的第一个gop的头部开始，改为下发所述常规数据。但本发明并不局限于此，从常规数据中位于启播时间点之后的第二个gop或更后一些的gop的头部开始改为下发常规数据也是可以的，这可以由用户根据需要来设置。
本实施例还提供了一种视频直播服务器，如图6所示，包括：
数据压缩模块50，设置为：将视频直播的源数据分别压缩为启播数据和常规数据，所述启播数据的画面组gop的长度小于所述常规数据的gop的长度；
启播下发模块60，设置为：在收到直播请求后，确定所述启播数据中启播时间点所在的当前gop，从该当前gop的头部开始先下发所述启播数据；
常规下发模块70，设置为：从所述常规数据中位于启播时间点之后的一个gop的头部开始，改为下发所述常规数据。
可选地，所述数据压缩模块压缩得到的所述启播数据的码率低于所述常规数据的码率。
可选地，所述启播下发模块开始下发所述启播数据之前，还包括：修改所述当前gop中视频帧的播放时间戳，使得播放时间戳被修改的视频帧之间的播放间隔变小。
可选地，所述启播下发模块修改所述当前gop中视频帧的播放时间戳，包括：将所述当前gop中位于启播时间点之前的所有视频帧的时间戳修改为启播时间点所在的视频帧的时间戳，或修改为启播时间点之前第一个视频帧的时间戳。
可选地，所述启播下发模块从所述当前gop的头部开始下发所述启播数据，包括：对所述当前gop中位于启播时间点之前的音频帧，不进行下发或者只进行部分下发。
可选地，所述数据压缩模块压缩得到的所述常规数据中每个gop的第一个i帧，均与压缩得到的所述启播数据中一个相应的i帧对齐。
本实施例方法流程中描述的任何处理，均可以通过本实施例视频直播服务器中相应模块来实现，这里不再赘述。
本实施例还提供了一种视频直播服务器，包括处理器和存储器，其中：
所述存储器，设置为：保存程序代码；
所述处理器，设置为：读取所述程序代码并执行以下处理：在收到直播请求后，确定待下发视频数据中启播时间点所在的当前画面组gop；修改所述当前gop中视频帧的播放时间戳，使得播放时间戳被修改的视频帧之间的播放间隔变小；及，完成所述修改后，从所述当前gop的头部开始下发所述视频数据。
本实施例方法流程中描述的任何处理，均可以通过本实施例视频直播服务器的处理器来执行，这里不再赘述。
本实施例方案提供多种码率和gop配置的直播流的能力，在用户刚刚接入时，先下发低码率短gop的视频数据，之后的常规直播阶段切换到高码率长gop的视频数据。可以减小首屏开启延时，且不会明显增加直播业务的带宽成本，也不影响画质。同时可以修改时间戳使得视频首屏开启更快，但不引入播放延时。
实施例三
本实施例提供基于实施例二的一个具体应用中的示例。
本示例中，服务器将主播推上来的源流压成2种不同清晰度的流，一种是常规流(图中表示为hd流)，具有高码率br1，长gop；另一种是启播流(图中表示为sd流)，具有低码率br2，短gop。其他参数完全相同。hd流的每一个关键帧即i帧都对应着sd流上一个相应的关键帧。
其中：
hd流的参数：br1＝800kbps，8秒一个gop,如使用hd流启播，启播时间点距离当前gop头的最大播放延时m1<8。
sd流的参数：br2＝300kbps，1秒一个gop，如使用sd流启播，启播时间点距离当前gop头的最大播放延时m2<1。
用户请求直播流，客户端与服务器建立连接并准备接收数据。服务器一直缓存sd流一个gop的视频数据，当收到直播请求后，从sd流中当前gop的头部开始下发视频数据。请参见图7，图7中的数字用于表示时间点的先后，并不表示实际的时间。图中，用户在时间点6请求接入直播流，服务器从启播流中找到启播时间点所在的当前gop，从该当前gop的头部(时间点4)开始先下发启播数据，可能导致的最大播放延时为m2。
从启播流中当前gop的头部到启播时间点之间(从时间点4到时间点6)的视频帧的时间戳都被调整，例如都修改为启播流中启播时间点所在的视频帧的时间戳。这样可以消除掉该2个视频帧的播放延时。
服务器下发启播流时，当前gop的第一个i帧对应的音频数据可以下发，但该i帧之后直到启播时间点之前的音频数据不必下发。如图7所示，用户收到的数据中有一格音频数据未下发。
服务器下发sd流数据，直到hd流中位于启播时间点之后的第一个gop的头部(对应于时间点13)，从该gop的头部(即从时间点13)开始，服务端不再下发sd流转而改为下发hd流。
客户端收到视频数据后即开始解析获取视频头信息，准备播放。当客户端buffer中的视频数据能维持的播放时长达到n秒时，开始播放画面。
本实施例的视频直播方案，用户请求直播流后，极短的时间内就可以看到画面，而且不引入更多的播放延时，同时不引入更多的流量消耗。仅仅在启播时短暂地牺牲了清晰度，保证了大部分播放时间请求的都是高清晰度长gop的直播流。客户端也不用激进地进行无buffer启播，保证了流畅度；由于启播时br和m都很小，比现有方案启播更快。是一种快启播、低延时、低卡顿、无流量代价的直播方案。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。