一种低延时快速开播方法及装置与流程

本发明涉及视频直播技术领域，尤其涉及一种低延时快速开播方法及装置。

背景技术：

RTMP(Real Time Messaging Protocol，实时消息传送协议)是一种在播放器和服务器之间进行音频、视频和数据传输的协议。RTMP协议在视频点播和直播应用中得到了广泛的应用。客户端(例如播放器)可以利用RTMP协议与服务器进行数据交互。例如，客户端可以接收服务器推送的视频音频数据，并在客户端实现本地播放。

但是，在RTMP实时播放的过程中，由于客户端接入实时视频的播放进入点具有随机性。而为保证客户端的正常播放，当客户端接入实时视频播放从服务器中拉流时，服务器需从直播视频数据中的关键帧开始向客户端发送视频数据。若服务器从接入时间后收到的关键帧开始向客户端发送视频数据，则会导致客户端在视频开播(即在客户端开始播放直播视频)时存在等待时间，无法做到快速或立即开播，不利于提高客户端用户的观看体验。若服务器从接入时间前收到的关键帧开始向客户端发送视频数据，则会在网络延时的基础上进一步加大客户端的播放延时，同样不利于提高客户端用户的观看体验。

因此，本领域技术人员需要提供一种低延时快速开播方法及装置能够在减小开播时用户的等待时间的同时不增加客户端的播放延时，从而提高用户的观看体验。

技术实现要素：

为了解决现有技术问题，本发明提供了一种低延时快速开播方法及装置能够在减小开播时用户的等待时间的同时不增加客户端的播放延时，从而提高用户的观看体验。

本发明实施例提供的低延时快速开播方法，应用于服务器，所述方法包括：

接收第一客户端实时上传的数据集合，所述数据集合包括视频数据；

保存第一子视频数据，并修改所述第一子视频数据中每一帧的时间戳，所述第一子视频数据至少包括所述视频数据中最新接收到的关键帧；

当接收到第二客户端发送的播放请求时，将所述第一子视频数据发送给所述第二客户端播放。

可选的，所述修改所述第一子视频数据中每一帧的时间戳，具体包括：

将所述第一子视频数据中每一帧的时间戳设置为预设时间范围内的任意时间。

可选的，所述预设时间范围内的时间小于或者等于200毫秒。

可选的，所述第一子视频数据为所述视频数据中最新接收到的一组画面组；

所述保存第一子视频数据，具体包括：

逐一检测所述视频数据中最新接收到的帧的帧类型；

当检测到所述最新接收到的帧的帧类型为关键帧时，将该帧所属的画面组保存为所述第一子视频数据；

当再次检测到所述最新接收到的帧的帧类型为关键帧时，将该帧所述的画面组替换为所述第一子视频数据。

可选的，所述数据集合还包括音频数据；所述将所述第一子视频数据发送给所述第二客户端播放，之后还包括：

继续将第二子视频数据和第二子音频数据发送给所述第二客户端，以使所述第二客户端同步播放所述第二子视频数据和第二子音频数据；

其中，所述第二子视频数据属于所述视频数据，所述第二子视频数据与所述第一子视频数据在时间上是连续的且所述第一子视频数据的开始时间早于所述第二子视频数据的开始时间，所述第二子音频数据与所述第二子视频数据相对应。

本发明实施例提供的低延时快速开播装置，应用于服务器，所述装置，包括：数据接收模块、数据处理模块、请求接收模块和数据发送模块；

所述数据接收模块，用于接收第一客户端实时上传的数据集合，所述数据集合包括视频数据；

所述数据处理模块，用于保存第一子视频数据，并修改所述第一子视频数据中每一帧的时间戳，所述第一子视频数据至少包括所述视频数据中最新接收到的关键帧；

所述请求接收模块，用于接收第二客户端发送的播放请求；

所述数据发送模块，用于当所述请求接收模块接收到所述播放请求时，将所述第一子视频数据发送给所述第二客户端播放。

可选的，所述数据处理模块，包括：时间戳修改子模块；

所述时间戳修改子模块，用于将所述第一子视频数据中每一帧的时间戳设置为预设时间范围内的任意时间。

可选的，所述预设时间范围内的时间小于或者等于200毫秒。

可选的，所述第一子视频数据为所述视频数据中最新接收到的一组画面组；

所述数据处理模块，包括：检测子模块和存储子模块；

所述检测子模块，用于逐一检测所述视频数据中最新接收到的帧的帧类型；

所述存储子模块，用于当所述检测子模块检测到所述最新接收到的帧的帧类型为关键帧时，将该帧所属的画面组保存为所述第一子视频数据；

所述存储子模块，还用于当所述检测子模块再次检测到所述最新接收到的帧的帧类型为关键帧时，将该帧所述的画面组替换为所述第一子视频数据。

可选的，所述数据集合还包括音频数据；

所述数据发送模块，还用于在将所述第一子视频数据发送给所述第二客户端播放后，继续将第二子视频数据和第二子音频数据发送给所述第二客户端，以使所述第二客户端同步播放所述第二子视频数据和第二子音频数据；

其中，所述第二子视频数据属于所述视频数据，所述第二子视频数据与所述第一子视频数据在时间上是连续的且所述第一子视频数据的开始时间早于所述第二子视频数据的开始时间，所述第二子音频数据与所述第二子视频数据相对应。

与现有技术相比，本发明至少具有以下优点：

本发明实施例提供的低延时快速播放方法，在接收到第一客户端实时上传的视频数据和音频数据时，保存视频数据中最新接收到的一组画面组中包括关键帧的一帧或多帧，得到第一子视频数据，并随着视频数据的传输，实时更新保存的第一子视频数据。同时，修改所保存的第一子视频数据中每一帧的时间戳，使得第二客户端在解码播放时能够快速跳过播放第一子视频数据。这样，当接收到第二客户端发送的播放请求时，先将第一子视频数据发送给第二客户端播放，即可使第二客户端能够快速的开播，无需等待下一个关键帧。将第一子视频数据发送给第二客户端之后，再将实时的视频数据发送给第二客户端播放。修改后的第一子视频数据中每一帧的时间戳使得第二客户端能够快速的播放完第一子视频数据，再播放实时的视频数据，可降低第二客户端和第一客户端之间的视频播放延时，提高第二客户端用户的观看体验。

附图说明

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

图1为本发明提供的低延时快速开播方法实施例的流程示意图；

图2为本发明提供的低延时快速开播装置实施例的结构示意图。

具体实施方式

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

首先需要说明的是，本发明实施例提供的低延时快速开播方法及装置，均应用于服务器。该服务器通过RTMP协议分别与第一客户端(直播数据生成端、推流端或主播端等)和第二客户端(直播视频播放端、拉流端或观众端等)通信，实时的将第一客户端的数据转发至第二客户端。第二客户端根据从服务器处接收到的数据，播放第一客户端的直播视频。

方法实施例：

参见图1，该图为本实施例提供的低延时快速开播方法实施例的流程示意图。

本实施例提供的低延时快速开播方法，包括：

S101：接收第一客户端实时上传的数据集合，所述数据集合包括视频数据。

第一客户端在视频编码生成视频数据时，会按照预先的设置，设置视频数据中的关键帧。例如，每隔2秒设置一帧关键帧。之后，第一客户端将与直播相关的各种数据实时的连续的传输给服务器。

S102：保存第一子视频数据，并修改所述第一子视频数据中每一帧的时间戳，所述第一子视频数据至少包括所述视频数据中最新接收到的关键帧(I帧)。

S103：当接收到第二客户端发送的播放请求时，将所述第一子视频数据发送给所述第二客户端播放。

这里需要说明的是，第一子视频数据至少包括服务器最新接收到的I帧。第一子视频数据还可以包括该最新接收到的I帧后的一个或多个帧，该一个或多个帧与该最新接收到的I帧属于同一画面组(GOP，Group of Pictures)。在视频编码中，GOP为视频序列中以第一个I帧为起点，以第二个I帧结尾、但不包括第二个I帧的帧序列。一个GOP包括一个I帧以及若干P帧和B帧。视频序列中的第二个I帧即为另一个GOP的起始点。

在本实施例优选的实施方式中，所述第一子视频数据为所述视频数据中最新接收到的一组画面组。此时，所述保存第一子视频数据，具体包括：逐一检测所述视频数据中最新接收到的帧的帧类型；当检测到所述最新接收到的帧的帧类型为关键帧时，将该帧所属的画面组保存为所述第一子视频数据；当再次检测到所述最新接收到的帧的帧类型为关键帧时，将该帧所述的画面组替换为所述第一子视频数据。

具体实施时，服务器在接收视频数据时，先判断接收到的帧是否为I帧；如果是，则从该帧开始，缓存接收到的每一个帧。当服务器再次判断出接收到的帧为I帧时，停止缓存。之后，将缓存的全部的帧替换为第一子视频数据。

这样，第二客户端在发送直播请求以接入视频直播后，能够立即接收到服务器发送的第一子视频数据，无需等待时间，直接对第一子视频数据进行解码播放即可。

这里需要说明的是，显然，为了保证视频直播的正常播放，所述数据集合还包括音频数据。但是，如果将与第一子视频数据相对应的音频数据同时发送给第二客户端播放，则第二客户端在解码时需进行音视频同步操作。这会延迟直播视频在第二客户端上的开播时间，延迟第二客户端的开播时间，还会增加第二客户端和第一客户端之间的播放延时，不利于提高第二客户端用户的观看体验。因此，在开播时只将第一子视频数据发送给第二客户端播放，不向第二客户端传输相应的音频数据，可在一定程度上加快第二客户端的开播速度，降低第二客户端的播放延时。

在本实施例优选的实施方式中，步骤S103之后还包括：继续将第二子视频数据和第二子音频数据发送给所述第二客户端，以使所述第二客户端同步播放所述第二子视频数据和第二子音频数据；其中，所述第二子视频数据属于所述视频数据，所述第二子视频数据与所述第一子视频数据在时间上是连续的且所述第一子视频数据的开始时间早于所述第二子视频数据的开始时间，所述第二子音频数据与所述第二子视频数据相对应。

之后，服务器即可继续向第二客户端发送实时接收到的视频数据和与其对应的音频数据，以使第二客户端正常的进行直播视频的播放。

在一个例子中，第二子视频数据的起始帧可以为与第一子视频数据之后的第一个I帧，这样能够保证第二客户端所播放的视频的连续性。但第一子视频数据的播放会加大第二客户端和第一客户端之间的播放延时，影响第二客户端用户的观看效果。

在另一个例子中，第二子视频数据的起始帧还可以为当前服务器最新接收到的I帧，这样可降低第二客户端与第一客户端的播放延时。但第二客户端播放的视频不连续，跳过的视频时长受第一子视频数据的播放时间和网络传输等因素的影响，同样不利于第二客户端用户的观看效果。

因此，可通过修改第一子视频数据中每一帧的时间戳，缩短第二客户端播放第一子视频数据的时间，以减小第二客户端的播放延时。进一步的，还可在第二子视频数据的起始帧为当前服务器最新接收到的I帧时，减小第二客户端播放时所跳过的直播视频的时长。

在本实施例的一些可能的实现方式中，可以将所述第一子视频数据中每一帧的时间戳设置为预设时间范围内的任意时间。

作为一个示例，所述预设时间范围内的时间小于或者等于200毫秒(ms)。

具体的，可将所述第一子视频数据中每一帧的时间戳均设为0ms或近似为0ms的时间。这样，第二客户端在解码播放时，即可根据第一子视频数据中每一帧的时间戳快速的播放完第一子视频数据，减小了第二客户端的播放延时。

另外，还可以将第一子视频数据中每一帧的时间戳按顺序修改成递增的时间戳，但每一帧之间的时间戳相差比较小。例如将每一帧的时间戳分别设置为0ms、10ms、20ms、30ms等，相邻两帧之间的时间戳以10ms间隔递增。具体操作中，当第一子视频数据的总帧数较少时，可以将第一子视频数据中相邻两帧的时间戳之间的间隔设置的较大一点；反之，当第一子视频数据的总帧数较多时，则需相应的减小将第一子视频数据中相邻两帧的时间戳之间的间隔，以保证在播放时，能够用较短的时间播放完第一子视频数据中的帧。

这里需要说明的是，在修改第一子视频数据中每一帧的时间戳时，需保证修改后实际播放时，能够达到快速播放完第一子视频数据的效果。因此，一般来说，第一子视频数据中最后一帧的时间戳不应大于200ms。

本实施例提供的低延时快速播放方法，在接收到第一客户端实时上传的视频数据和音频数据时，保存视频数据中最新接收到的一组画面组中包括关键帧的一帧或多帧，得到第一子视频数据，并随着视频数据的传输，实时更新保存的第一子视频数据。同时，修改所保存的第一子视频数据中每一帧的时间戳，使得第二客户端在解码播放时能够快速跳过播放第一子视频数据。这样，当接收到第二客户端发送的播放请求时，先将第一子视频数据发送给第二客户端播放，即可使第二客户端能够快速的开播，无需等待下一个关键帧。将第一子视频数据发送给第二客户端之后，再将实时的视频数据发送给第二客户端播放。修改后的第一子视频数据中每一帧的时间戳使得第二客户端能够快速的播放完第一子视频数据，再播放实时的视频数据，可降低第二客户端和第一客户端之间的视频播放延时，提高第二客户端用户的观看体验。

基于上述实施例所述的低延时快速开播方法，本发明实施例还提供了一种低延时快速开播装置。

装置实施例：

参见图2，该图为本发明提供的低延时快速开播装置实施例的结构示意图。

本实施例提供的低延时快速开播装置，包括：数据接收模块100、数据处理模块200、请求接收模块300和数据发送模块400；

所述数据接收模块100，用于接收第一客户端实时上传的数据集合，所述数据集合包括视频数据；

所述数据处理模块200，用于保存第一子视频数据，并修改所述第一子视频数据中每一帧的时间戳，所述第一子视频数据至少包括所述视频数据中最新接收到的关键帧；

在本实施例的一些可能的实现方式中，所述第一子视频数据为所述视频数据中最新接收到的一组画面组。

此时，所述数据处理模块200，包括：检测子模块和存储子模块(均为在图中示出)；

所述检测子模块，用于逐一检测所述视频数据中最新接收到的帧的帧类型；

所述存储子模块，用于当所述检测子模块检测到所述最新接收到的帧的帧类型为关键帧时，将该帧所属的画面组保存为所述第一子视频数据；

所述存储子模块，还用于当所述检测子模块再次检测到所述最新接收到的帧的帧类型为关键帧时，将该帧所述的画面组替换为所述第一子视频数据。

在本实施例的一些可能的实现方式中，所述数据处理模块200，包括：时间戳修改子模块(未在图中示出)；

在一个例子中，所述时间戳修改子模块，用于将所述第一子视频数据中每一帧的时间戳设置为预设时间范围内的任意时间。

所述预设时间范围内的时间小于或者等于200毫秒。

所述请求接收模块300，用于接收第二客户端发送的播放请求；

所述数据发送模块400，用于当所述请求接收模块300接收到所述播放请求时，将所述第一子视频数据发送给所述第二客户端播放。

显然，所述数据集合还包括音频数据。此时，在本实施例的一些可能的实现方式中，所述数据发送模块400，还用于在将所述第一子视频数据发送给所述第二客户端播放后，继续将第二子视频数据和第二子音频数据发送给所述第二客户端，以使所述第二客户端同步播放所述第二子视频数据和第二子音频数据；其中，所述第二子视频数据属于所述视频数据，所述第二子视频数据与所述第一子视频数据在时间上是连续的且所述第一子视频数据的开始时间早于所述第二子视频数据的开始时间，所述第二子音频数据与所述第二子视频数据相对应。

本实施例提供的低延时快速播放装置，在数据接收模块接收到第一客户端实时上传的视频数据和音频数据时，数据处理模块保存视频数据中最新接收到的一组画面组中包括关键帧的一帧或多帧，得到第一子视频数据，并随着视频数据的传输，实时更新保存的第一子视频数据。同时，数据处理模块还修改所保存的第一子视频数据中每一帧的时间戳，使得第二客户端在解码播放时能够快速跳过播放第一子视频数据。这样，当请求接收模块接收到第二客户端发送的播放请求时，数据发送模块先将第一子视频数据发送给第二客户端播放，即可使第二客户端能够快速的开播，无需等待下一个关键帧。将第一子视频数据发送给第二客户端之后，数据发送模块再将实时的视频数据发送给第二客户端播放。修改后的第一子视频数据中每一帧的时间戳使得第二客户端能够快速的播放完第一子视频数据，再播放实时的视频数据，可降低第二客户端和第一客户端之间的播放延时，提高第二客户端用户的观看体验。

需要说明的是，本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述比较简单，相关之处参见方法部分说明即可。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制。虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明。任何熟悉本领域的技术人员，在不脱离本发明技术方案范围情况下，都可利用上述揭示的方法和技术内容对本发明技术方案做出许多可能的变动和修饰，或修改为等同变化的等效实施例。因此，凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所做的任何简单修改、等同变化及修饰，均仍属于本发明技术方案保护的范围内。