[发明专利]一种视频直播方法及视频直播服务器

说明书

一种视频直播方法及视频直播服务器，服务器将视频直播的源数据分别压缩为启播数据和常规数据，所述启播数据的画面组GOP的长度小于所述常规数据的GOP的长度；所述服务器收到直播请求后，确定所述启播数据中启播时间点所在的当前GOP，从该当前GOP的头部开始先下发所述启播数据；所述服务器从所述常规数据中位于启播时间点之后的一个GOP的头部开始，改为下发所述常规数据。本申请先下发GOP较小的启播数据，首屏开启延时和播放延时小，而后改为下发GOP较大的常规数据，也不会导致码率明显上升而提高直播业务的成本。

技术领域

本发明涉及视频播放技术，更具体地，涉及一种视频直播方法及视频直播服务器。

背景技术

视频编码将画面(即帧)分为I、P、B三种，I帧采用帧内独立编码，而P帧和B帧是参考已编码的帧进行帧间预测编码，可以说P帧、B帧记录的是与之前编码的画面的差异。没有I帧，P帧和B帧是无法解码。画面组(GOP：Group of Pictures)是一段连续的可以独立解码的画面。一段长视频可以按照GOP切分成一个个独立的小片段。一个GOP可以包括多个I帧，但第一帧一定是I帧。每一个视频帧都带着一个播放时间戳(PTS：presentation timestamp)，表示这一帧在什么时间点播放出来。图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的头部开始，改为下发所述常规数据。