视频推送方法、装置、电子设备和可读存储介质

摘要

本公开提供了一种视频推送方法、装置、电子设备和计算机可读存储介质，涉及多媒体技术领域。其中，视频推送方法包括：响应于播放端对媒体流数据的拉流请求，第二源站向第一源站对媒体流数据进行拉流操作；第二源站确定与拉流请求的网络协议匹配的拉流数量，拉流数量为拉取媒体流数据所需的历史画面组GOP的数量；第一源站基于拉流操作向第二源站反馈视频帧，视频帧包括历史GOP；第二源站基于视频帧生成拉流数量的TS文件，以基于拉流数量的TS文件生成媒体流数据，并将媒体流数据推送至播放端。通过本公开的技术方案，返回至播放端的媒体流数据可以直接解析出满足播放需求的TS文件，从而能够实现媒体流的快速播放，以缩短视频直播时产生的延迟。

权利要求

1.一种视频推送方法，应用于服务端，所述服务端包括第一源站和第二源站，其特征在于，包括：响应于播放端对媒体流数据的拉流请求，所述第二源站向所述第一源站对所述媒体流数据进行拉流操作；

所述第二源站确定与所述拉流请求的网络协议匹配的拉流数量，所述拉流数量为拉取所述媒体流数据所需的历史画面组GOP的数量；

所述第一源站基于所述拉流操作向所述第二源站反馈视频帧，所述视频帧包括所述拉流数量的历史GOP，其中，所述第一源站中配置有视频帧缓存队列，所述视频帧缓存队列用于提供所述历史GOP；

所述第二源站基于所述视频帧生成所述拉流数量的TS文件，以基于所述拉流数量的TS文件生成所述媒体流数据，并将所述媒体流数据推送至所述播放端，以由所述播放端解析出所述拉流数量的TS文件，并进行播放。

2.根据权利要求1所述的视频推送方法，其特征在于，所述第二源站确定与所述拉流请求的网络协议匹配的拉流数量，具体包括：所述第二源站检测所述拉流请求的网络协议的类型；

在检测到所述拉流请求的网络协议为第一网络协议时，将第一数量确定为所述拉流数量；

在检测到所述拉流请求的网络协议为第二网络协议时，将第二数量确定为所述拉流数量；

基于所述拉流数量生成拉流参数，以将所述拉流参数发送至所述第一源站。

3.根据权利要求2所述的视频推送方法，其特征在于，所述第一源站中配置有视频帧缓存队列，所述视频帧缓存队列用于提供所述历史GOP，还包括：在所述视频帧缓存队列的头部存储所述视频帧中的编辑帧；

所述第一源站基于所述拉流操作向所述第二源站反馈视频帧，具体包括：所述第一源站自所述视频帧缓存队列的头部起，提取所述历史GOP。

4.根据权利要求3所述的视频推送方法，其特征在于，所述第一源站中配置有视频帧缓存队列，所述视频帧缓存队列用于提供所述历史GOP，还包括：所述第一源站基于推流端的推流操作接收推流数据；

在检测到所述推流数据中的当前编辑帧时，将所述当前编辑帧的上一个GOP作为历史GOP存储在所述视频帧缓存队列，其中，在所述拉流请求的网络协议为第一网络协议时，所述第一源站直接将所述推流数据反馈至所述第二源站，以由所述第二源站基于所述推流数据生成所述媒体流数据。

5.根据权利要求4所述的视频推送方法，其特征在于，所述在检测到所述推流数据中的当前编辑帧时，将所述当前编辑帧的上一个GOP作为历史GOP存储在所述视频帧缓存队列，还包括：在接收到所述当前编辑帧的下一编辑帧时，将基于所述当前编辑帧生成的GOP存储在所述视频帧缓存队列的尾部；以及确定处于所述视频帧缓存队列的头部的第一编辑帧，以及与所述第一编辑帧相邻的第二编辑帧，并删除所述第一编辑帧与所述第二编辑帧之间的历史视频帧。

6.根据权利要求2至5中任一项所述的视频推送方法，其特征在于，所述第二源站包括转码节点、转码源站和边缘节点，所述第二源站向所述第一源站对所述媒体流数据进行拉流操作，具体包括：所述边缘节点向所述转码源站请求所述媒体流数据；

在所述转码源站未存储所述媒体流数据时，所述转码源站通知所述转码节点基于所述第一网络协议向所述第一源站对所述视频帧进行拉流操作。

7.根据权利要求6所述的视频推送方法，其特征在于，所述第二源站基于所述视频帧生成所述拉流数量的TS文件，以基于所述拉流数量的TS文件生成所述媒体流数据，并将所述媒体流数据推送至所述播放端，具体包括：所述转码节点接收所述第一源站反馈的所述视频帧，并对所述视频帧进行转码操作，得到转码文件；

所述转码节点基于所述第一网络协议将所述转码文件推送至所述转码源站；

所述转码源站将所述转码文件转换为所述拉流数量的TS文件，并基于所述拉流数量的TS文件生成媒体分片，以将所述媒体分片作为指定格式的媒体流推送至所述播放端。

8.一种视频推送装置，应用于服务端，所述服务端包括第一源站和第二源站，其特征在于，包括：拉流模块，用于响应于播放端对媒体流数据的拉流请求，所述第二源站向所述第一源站对所述媒体流数据进行拉流操作；

确定模块，用于所述第二源站确定与所述拉流请求的网络协议匹配的拉流数量，所述拉流数量为拉取所述媒体流数据所需的历史画面组GOP的数量；

反馈模块，用于所述第一源站基于所述拉流操作向所述第二源站反馈视频帧，所述视频帧包括所述拉流数量的历史GOP，其中，所述第一源站中配置有视频帧缓存队列，所述视频帧缓存队列用于提供所述历史GOP；

推送模块，用于所述第二源站基于所述视频帧生成所述拉流数量的TS文件，以基于所述拉流数量的TS文件生成所述媒体流数据，并将所述媒体流数据推送至所述播放端，以由所述播放端解析出所述拉流数量的TS文件，并进行播放。

9.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1～7中任意一项所述的视频推送方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1～7中任意一项所述的视频推送方法。

说明书

视频推送方法、装置、电子设备和可读存储介质

技术领域

[0001] 本公开涉及多媒体技术领域，尤其涉及一种视频推送方法、装置、电子设备和计算机可读存储介质。

背景技术

[0002] RTMP协议(Real Time Messaging Protocol)是目前主流的流媒体传输协议，广泛用于直播领域。HLS协议(HTTP Live Streaming)的工作原理是把整个媒体流分成多个基于HTTP的小媒体分片下载，每次只下载一些分片，分片中包括一个m3u8的索引文件，TS媒体分片文件和key加密串文件。

[0003] 相关技术中，计算机流媒体直播技术的主流方案是使用RTMP协议实现推拉流，在播放端使用HLS协议到节点拉流进行播放时，根据HLS标准的建议，需要获取到3个以上的TS格式文件才可以开始播放。并且在通常情况下，必须使用I帧作为TS文件的第一个视频帧以保证TS文件在播放端正常解码，播放端播放HLS格式地址的时候，节点通过RTMP协议去源站拉流的时候，源站只会缓存最后一个I帧之后的数据，节点启动转码之后拿到的数据没有办法快速生成TS文件，只能等到收到足够的视频数据之后才能开始生成TS文件，因此播放端使用HLS格式接入之后只能等到节点产生了足够的TS文件之后才能开始正常播放视频，从而导致视频直播存在延迟。

[0004] 需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

[0005] 本公开的目的在于提供一种视频推送方法、装置、电子设备和计算机可读存储介质，至少在一定程度上克服由于相关技术中视频直播存在延迟的问题。

[0006] 本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

[0007] 根据本公开的一个方面，提供一种视频推送方法，包括：响应于播放端对媒体流数据的拉流请求，所述第二源站向所述第一源站对所述媒体流数据进行拉流操作；所述第二源站确定与所述拉流请求的网络协议匹配的拉流数量，所述拉流数量为拉取所述媒体流数据所需的历史画面组GOP的数量；所述第一源站基于所述拉流操作向所述第二源站反馈视频帧，所述视频帧包括所述拉流数量的历史GOP，其中，所述第一源站中配置有视频帧缓存队列，所述视频帧缓存队列用于提供所述历史GOP；所述第二源站基于所述视频帧生成所述拉流数量的TS文件，以基于所述拉流数量的TS文件生成所述媒体流数据，并将所述媒体流数据推送至所述播放端，以由所述播放端解析出所述拉流数量的TS文件，并进行播放。

[0008] 在本公开的一个实施例中，所述第二源站确定与所述拉流请求的网络协议匹配的拉流数量，具体包括：所述第二源站检测所述拉流请求的网络协议的类型；在检测到所述拉流请求的网络协议为第一网络协议时，将第一数量确定为所述拉流数量；在检测到所述拉流请求的网络协议为第二网络协议时，将第二数量确定为所述拉流数量；基于所述拉流数量生成拉流参数，以将所述拉流参数发送至所述第一源站，其中，所述第一数量小于所述第二数量。

[0009] 在本公开的一个实施例中，所述第一源站中配置有视频帧缓存队列，所述视频帧缓存队列用于提供所述历史GOP，还包括：在所述视频帧缓存队列的头部存储所述视频帧中的编辑帧；所述第一源站基于所述拉流操作向所述第二源站反馈视频帧，具体包括：所述第一源站自所述视频帧缓存队列的头部起，提取所述历史GOP。

[0010] 在本公开的一个实施例中，所述第一源站中配置有视频帧缓存队列，所述视频帧缓存队列用于提供所述历史GOP，还包括：所述第一源站基于推流端的推流操作接收推流数据；在检测到所述推流数据中的当前编辑帧时，将所述当前编辑帧的上一个GOP作为历史GOP存储在所述视频帧缓存队列，其中，在所述拉流请求的网络协议为第一网络协议时，所述第一源站直接将所述推流数据反馈至所述第二源站，以由所述第二源站基于所述推流数据生成所述媒体流数据。

[0011] 在本公开的一个实施例中，还包括：所述在检测到所述推流数据中的当前编辑帧时，将所述当前编辑帧的上一个GOP作为历史GOP存储在所述视频帧缓存队列，还包括：在接收到所述当前编辑帧的下一编辑帧时，将基于所述当前编辑帧生成的GOP存储在所述视频帧缓存队列的尾部；以及确定处于所述视频帧缓存队列的头部的第一编辑帧，以及与所述第一编辑帧相邻的第二编辑帧；以及删除所述第一编辑帧与所述第二编辑帧之间的所有所述视频帧。

[0012] 在本公开的一个实施例中，所述第二源站包括转码节点、转码源站和边缘节点，所述第二源站向所述第一源站对所述媒体流数据进行拉流操作，具体包括：所述边缘节点向所述转码源站请求所述媒体流数据；在所述转码源站未存储所述媒体流数据时，所述转码源站通知所述转码节点基于所述第一网络协议向所述第一源站对所述视频帧进行拉流操作。

[0013] 在本公开的一个实施例中，所述第二源站基于所述视频帧生成所述拉流数量的TS文件，以基于所述拉流数量的TS文件生成所述媒体流数据，并将所述媒体流数据推送至所述播放端，具体包括：所述转码节点接收所述第一源站反馈的所述视频帧，并对所述视频帧进行转码操作，得到转码文件；所述转码节点基于所述第一网络协议将所述转码文件推送至所述转码源站；所述转码源站将所述转码文件转换为所述拉流数量的TS文件，并基于所述拉流数量的TS文件生成媒体分片，以将所述媒体分片作为指定格式的媒体流推送至所述播放端。

[0014] 根据本公开的另一个方面，提供一种视频推送装置，包括：拉流模块，用于响应于播放端对媒体流数据的拉流请求，所述第二源站向所述第一源站对所述媒体流数据进行拉流操作；确定模块，用于所述第二源站根据所述拉流请求的网络协议确定拉取所述媒体流数据所需的拉流数量；反馈模块，用于所述第一源站基于所述拉流操作向所述第二源站反馈视频帧，所述视频帧包括所述拉流数量的历史GOP，其中，所述第一源站中配置有视频帧缓存队列，所述视频帧缓存队列用于提供所述历史GOP；推送模块，用于所述第二源站基于所述视频帧生成所述拉流数量的TS文件，以基于所述拉流数量的TS文件生成所述媒体流数据，并将所述媒体流数据推送至所述播放端，以由所述播放端解析出所述拉流数量的TS文件，并进行播放。

[0015] 根据本公开的再一个方面，提供一种电子设备，包括：处理器；以及存储器，用于存储处理器的可执行指令；其中，处理器配置为经由执行可执行指令来执行上述任意一项的视频推送方法。

[0016] 根据本公开的又一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任意一项的视频推送方法。

[0017] 本公开的实施例所提供的视频推送方案，通过在接收到播放端的拉流请求时，基于播放端的拉流请求所使用的网络协议确定第一源站基于第二源站的拉流操作反馈的拉流数量，以使第二源站将拉流数量的历史GOP转换为媒体流数据，这样返回至播放端的媒体流数据可以直接解析出满足播放需求的TS文件，对于需要多个TS文件才能播放的网络协议，能够实现媒体流的快速播放，以缩短视频直播时产生的延迟。

[0018] 进一步地，对于只需要一个TS文件就能够播放的网络协议，也能够防止返回的TS文件过多导致增加拉流延时。

[0019] 应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

[0020] 此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

[0021] 图1示出本公开实施例中一种视频推送方法的流程图；

[0022] 图2示出本公开实施例中一种视频帧缓存队列的示意图；

[0023] 图3示出本公开实施例中一种视频推送方案的架构示意图；

[0024] 图4示出本公开实施例中另一种视频推送方法的流程图；

[0025] 图5示出本公开实施例中另一种视频推送方案的架构示意图；

[0026] 图6示出本公开实施例中再一种视频推送方法的流程图；

[0027] 图7示出本公开实施例中一种视频推送装置的示意图；

[0028] 图8示出本公开实施例中一种电子设备的示意图；和

[0029] 图9示出本公开实施例中一种计算机可读存储介质的示意图。

具体实施方式

[0030] 现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的征、结构或性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述定细节中的一个或更多，或者可以采用其它的、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

[0031] 此外，附图仅为本公开的示意性图解，图中相同的附图标记表示相同或类似的分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

[0032] 为了便于理解，下面首先对本公开涉及到的几个名词进行解释。

[0033] RTMP协议(Real Time Messaging Protocol)：即实时消息传输协议，该协议基于TCP，是一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种，RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。

[0034] HLS协议(HTTP Live Streaming)：基于HTTP的自适应码率流媒体传输协议，是一种动态码率自适应技术，包括一个m3u(8)的索引文件，TS媒体分片文件和key加密串文件。

[0035] 推流，指的是把采集阶段封包好的内容传输到服务器的过程。其实就是将现场的视频信号传到网络的过程，即将直播内容推送至服务器的过程。

[0036] 拉流：为服务器已有直播内容，用指定地址进行拉取的过程。

[0037] 视频转码：指将视频信号从一种格式转换成另一种格式。

[0038] GOP(Group of Pictures)策略影响编码质量，所谓GOP，意思是画面组，一个GOP就是一组连续的画面，GOP是序列中的一个图片集，用来辅助随机存取。GOP的第一个图像必须为I帧，这样就能保证GOP不需要参考其他图像，可以独立解码。

[0039] I帧：帧内编码帧，又称intra picture，I帧通常是每个GOP(MPEG所使用的一种视频压缩技术)的第一个帧，经过适度地压缩，做为随机访问的参考点，可以当成图象。I帧可以看成是一个图像经过压缩后的产物。I帧画面完整保留，解码时只需要本帧数据就可以完成(因为包含完整画面)。

[0040] P帧：前向预测编码帧，又称predictive‑frame，通过充分将图像序列中前面已编码帧的时间冗余信息来压缩传输数据量的编码图像，也叫预测帧；表示的是这一帧跟之前的一个关键帧(或P帧)的差别，解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面。(也就是差别帧，P帧没有完整画面数据，只有与前一帧的画面差别的数据)。

[0041] B帧：双向差别帧，也就是B帧记录的是本帧与前后帧的差别，换言之，要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的与本帧数据的叠加取得最终的画面。B帧压缩率高，但是解码时CPU会比较累。

[0042] TS文件：指日本高清摄像机拍摄下进行的封装格式，全称为MPEG2‑TS。

[0043] 下面结合附图对本公开示例实施方式进行详细说明。

[0044] 如图1所示，服务器执行视频推送方法，包括以下步骤：

[0045] 步骤S102，响应于播放端对媒体流数据的拉流请求，第二源站向第一源站对媒体流数据进行拉流操作。

[0046] 其中，第一源站可以为接收推流端的上行RTMP推流的源站。

[0047] 第二源站可以为进行转码功能的源站和/或节点。

[0048] 另外，播放端对媒体流数据的拉流请求，可以基于HLS协议向服务端进行拉流，也可以基于RTMP协议向服务端进行拉流。

[0049] 所请求的媒体流数据可以为m3u8格式文件。

[0050] 步骤S104，第二源站确定与拉流请求的网络协议匹配的拉流数量，拉流数量为拉取媒体流数据所需的历史画面组GOP的数量。

[0051] 其中，由于不同的网络协议播放媒体流所需的TS文件不同，因此通过确定网络协议的类型，并进一步确定该类型的网络协议保证播放端获取到媒体流数据即可播放的拉流数量，以保证播放端在接收到媒体流文件时进行实时播放。

[0052] 步骤S106，第一源站基于拉流操作向第二源站反馈视频帧，视频帧包括拉流数量的历史GOP，其中，第一源站中配置有视频帧缓存队列，视频帧缓存队列用于提供历史GOP。

[0053] 其中，通过确定拉流数量，以基于该拉流数量向第一源站进行拉流，从而使第一源站向第二源站返回包括拉流数量的历史GOP的视频帧。

[0054] 步骤S108，第二源站基于视频帧生成拉流数量的TS文件，以基于拉流数量的TS文件生成媒体流数据，并将媒体流数据推送至播放端，以由播放端解析出拉流数量的TS文件，并进行播放。

[0055] 其中，通过对包括拉流数量的历史GOP的视频帧进行转化处理，生成适于播放端播放的媒体流数据文件，由于媒体流数据中包括与网络协议匹配的拉流数量的TS文件，因此适于使播放端快速对媒体流数据进行解码并播放。

[0056] 在该实施例中，通过在接收到播放端的拉流请求时，基于播放端的拉流请求所使用的网络协议确定第一源站基于第二源站的拉流操作反馈的拉流数量，以使第二源站将拉流数量的历史GOP转换为媒体流数据，这样返回至播放端的媒体流数据可以直接解析出满足播放需求的TS文件，对于需要多个TS文件才能播放的网络协议，能够实现媒体流的快速播放，以缩短视频直播时产生的延迟。

[0057] 进一步地，对于只需要一个TS文件就能够播放的网络协议，也能够防止返回的TS文件过多导致增加拉流延时。

[0058] 如图2所示，视频帧缓存队列用于缓存历史GOP，GOP中可以包括I帧、P帧等，I帧为编辑帧，P帧为前向预测编码帧，其中，从一个I帧开始，到下一个I帧之前，为一个完整的GOP，包括一个I帧和多个P帧。

[0059] 如图3所示，直播视频推送系统包括推流端302、服务端、播放端308和播放端310，其中，服务端包括第一源站304和第二源站306，推流端向302第一源站304进行上行RTMP推流，第一源站304对第二源站306进行RTMP拉流，第二源站306基于播放端308的HSL拉流向播308放端推送媒体流，第二源站306基于播放端310的RTMP拉流向播放端310推送媒体流，基于HSL协议和RTMP协议的不同，相对应的播放端返回的视频帧的数量不同，以I帧为例，HSL协议需要反馈4个I帧，RTMP协议只需要返回一个I帧。

[0060] 如图4所示，在本公开的一个实施例中第二源站确定与拉流请求的网络协议匹配的拉流数量，具体包括：

[0061] 步骤S402，第二源站检测拉流请求的网络协议的类型。

[0062] 步骤S404，在检测到拉流请求的网络协议为第一网络协议时，将第一数量确定为拉流数量。

[0063] 步骤S406，在检测到拉流请求的网络协议为第二网络协议时，将第二数量确定为拉流数量。

[0064] 步骤S408基于拉流数量生成拉流参数，以将拉流参数发送至第一源站。

[0065] 其中，第一数量小于第二数量。

[0066] 在一种应用场景中，第一网络协议为RTMP协议，对应的第一数量为0；第二网络协议为HLS协议，对应的第二数量为3。

[0067] 在该实施例中，拉流参数具体为GOP_NUM参数，该参数表示历史GOP缓存数量，在播放端基于HLS协议到服务端拉流时，该参数设置为3，在播放端基于RTMP协议到服务端拉流时，该参数设置为0，也就是说，针对HLS协议，需要拉取3个历史GOP，以及少于一个GOP的实时数据，针对RTMP协议，则不需要拉取历史GOP，只拉取最新的不少于一个GOP的实时数据，通过根据不同的网络协议设置对应的拉流数量，以在播放端基于对应的网络协议进行拉流请求时，直接向第一源站申请对应的视频帧，通过直接将视频帧反馈给播放端，以提高视频播放的实时性。

[0068] 具体地，在播放端基于HLS协议请求第二源站拉转码流时，第二源站直接向第一源站申请3个GOP的数据，所以推送到第二源站的时候已经有了3个GOP的数据了，第二源站可以使用这3个GOP的数据来生成3个TS文件，这样的话，播放端在接入的时候就能够快速拿到3个TS文件进行播放。

[0069] 而在播放端使用RTMP到第二源站拉转码流时，如果返回多个GOP数据会导致延迟增长，因此只需要返回一个GOP，具体地，如果视频帧缓存队列中缓存有多个GOP数据，则反馈最后一个缓存的GOP，如果服务器的缓存少于3个，则等待一个时间之后再检查服务器的缓存，如果还是没有大于3个GOP，则返回最后一个缓存的GOP。

[0070] 在本公开的一个实施例中，第一源站中配置有视频帧缓存队列，视频帧缓存队列用于提供历史GOP，还包括：在视频帧缓存队列的头部存储视频帧中的编辑帧；第一源站基于拉流操作向第二源站反馈视频帧，具体包括：第一源站自视频帧缓存队列的头部起，提取历史GOP

[0071] 在该实施例中，为了保证推送视频的第一帧都是I帧，在视频帧缓存队列的第一个视频帧只会是I帧，如果推送上来的第一帧不是I帧，则需要把视频帧丢弃，从而保证播放端解析出的TS文件中的第一个视频帧为I帧，以保证流媒体在播放端能够正常解码与播放。

[0072] 在本公开的一个实施例中，第一源站中配置有视频帧缓存队列，视频帧缓存队列用于提供历史GOP，还包括：第一源站基于推流端的推流操作接收推流数据；在检测到推流数据中的当前编辑帧时，将当前编辑帧的上一个GOP作为历史GOP存储在视频帧缓存队列，其中，在拉流请求的网络协议为第一网络协议时，第一源站直接将推流数据反馈至第二源站，以由第二源站基于推流数据生成媒体流数据。

[0073] 具体地，在直播场景，推流端持续将媒体数据流推送到服务器，第一源站每接收到一个I帧，就把上一个GOP作为历史GOP缓存到视频帧缓存队列。以该I帧开始的GOP长度持续增长，直至接收到下一个I帧，得到一个完整的GOP。然后将这个GOP移至视频帧缓存队列。

[0074] 由上可知，服务器中的缓存数据包括两个部分，即N个完整的历史GOP和小于一个GOP的最新缓存数据。

[0075] 如图2所示，队列的头部视频帧出栈，进行视频帧的推送，保证视频的第一帧都是I帧，将最新接收到的待缓存的视频帧push到队列的尾部。

[0076] 在本公开的一个实施例中，在检测到推流数据中的当前编辑帧时，将当前编辑帧的上一个GOP作为历史GOP存储在视频帧缓存队列，还包括：在接收到当前编辑帧的下一编辑帧时，将基于当前编辑帧生成的GOP存储在视频帧缓存队列的尾部；以及确定处于视频帧缓存队列的头部的第一编辑帧，以及与第一编辑帧相邻的第二编辑帧，并删除第一编辑帧与第二编辑帧之间的历史视频帧。

[0077] 具体地，使用一个队列来保存所有的视频帧数据，每次收到一个视频帧的时候，就保存在队列的尾部，判断如果帧的类型是I帧，则从队列头部把第一个I帧到第二个I帧之间的所有视频帧从队列的头部删除。正常情况下，推送视频的第一帧都是I帧，所以缓存队列的第一个视频帧只会是I帧，如果推送上来的第一帧不是I帧，则需要把视频帧丢弃。

[0078] 在该实施例中，在接收到新的待缓存的视频帧时，将待缓存的视频帧缓存在缓存队列的队尾，并删除处于队列头部的I帧开头的视频帧，以防止旧的视频被推送至播放端，进而有利于保证视频推送的实时性。

[0079] 如图5所示，本公开的视频推送方法的交互方包括推流端502、服务端、播放端512和播放端514。其中，服务端包括第一源站504和第二源站，第二源站又进一步包括转码节点506、转码源站508和边缘节点510。

[0080] 具体地，播放端512使用HLS协议通过边缘节点510向转码源站508请求m3u8格式媒体流数据，转码源站508此时没有媒体流则请求阻塞。转码源站508通知转码节点506使用RTMP协议向第一源站504拉流，第一源站504快速返回3个GOP的媒体流数据给转码节点506。转码节点506使用拿到的数据进行转码，并使用RTMP协议推送到转码源站508生成TS文件。
转码源站508生成m3u8文件返回给播放端512，播放端512收到m3u8文件之后，请求3个TS文件，开始播放,实现播放HLS格式的转码流快速出视频。

[0081] 播放端514使用RTMP协议通过边缘节点510向转码源站508请求m3u8格式媒体流数据，转码源站508此时没有媒体流则请求阻塞。转码源站508通知转码节点506使用RTMP协议向第一源站504拉流，第一源站504快速返回1个GOP的媒体流数据给转码节点506。转码节点506使用拿到的数据进行转码，并使用RTMP协议推送到转码源站508生成TS文件。转码源站
508生成m3u8文件返回给播放端512，播放端开始播放,减少直播延迟。

[0082] 如图6所示，根据本公开的一个实施例的视频推送方法，包括：

[0083] 步骤S602，响应于播放端对媒体流数据的拉流请求，边缘节点向转码源站请求媒体流数据。

[0084] 步骤S604，在转码源站未存储媒体流数据时，转码源站通知转码节点基于第一网络协议向第一源站对视频帧进行拉流操作。

[0085] 步骤S606，解析拉流操作中的拉流参数。

[0086] 步骤S608，在播放端使用第一网络协议请求媒体流数据时，将拉流参数中包括的第一数量确定为拉流数量。

[0087] 步骤S610，在播放端使用第二网络协议请求媒体流数据时，将拉流参数中包括的第二数量确定为拉流数量。

[0088] 步骤S612，在第一源站基于推流端的推流操作接收到待缓存的视频帧时，将待缓存的视频帧存储在视频帧缓存队列的尾部。

[0089] 步骤S614，第一源站自视频帧缓存队列的头部起，提取拉流数量的历史GOP，并基于历史GOP和实时推流数据生成视频帧，以基于拉流操作向转码节点反馈视频帧。

[0090] 步骤S616，转码节点接收第一源站反馈的视频帧，并对视频帧进行转码操作，得到转码文件。

[0091] 步骤S618，转码节点基于第一网络协议将转码文件推送至转码源站。

[0092] 步骤S620，转码源站将转码文件转换为拉流数量的TS文件，并基于拉流数量的TS文件生成媒体分片，以将媒体分片作为指定格式的媒体流推送至播放端。

[0093] 在该实施例中，第一网络协议为RTMP协议，第二网络协议为HLS协议，播放HLS转码流的快速接入：在转码节点拉取源流进行转码的时候，快速推送多个GOP的数据，使转码节点能够快速生成多个GOP并推送到源站，转码生成多个TS文件，播放端在转码开始之后就能够快速播放。

[0094] 播放RTMP转码流的时候保持低延迟：转码节点同时转码多个GOP，在推送到转码源站之后，会使转码源站多出几个GOP的缓存，这个时候使用RTMP协议拉流就会产生较大延迟；使用RTMP拉流的时候需要设置获取源站最后的一个GOP缓存，保证RTMP的延迟不会大于一个GOP。

[0095] 需要注意的是，上述附图仅是根据本发明示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

[0096] 所属技术领域的技术人员能够理解，本发明的各个方面可以实现为系统、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

[0097] 下面参照图7来描述根据本发明的这种实施方式的视频推送装置700。图7所示的视频推送装置700仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

[0098] 视频推送装置700以硬件模块的形式表现。视频推送装置700的组件可以包括但不限于：拉流模块702，用于响应于播放端对媒体流数据的拉流请求，第二源站向第一源站对媒体流数据进行拉流操作；确定模块704，用于第二源站根据拉流请求的网络协议确定拉取媒体流数据所需的拉流数量；反馈模块706，用于第一源站基于拉流操作向第二源站反馈拉流数量的视频帧，其中，第一源站中配置有视频帧缓存队列，视频帧缓存队列用于提供拉流数量的视频帧；推送模块708，用于第二源站基于拉流数量的视频帧生成拉流数量的TS文件，以基于拉流数量的TS文件生成媒体流数据，并将媒体流数据推送至播放端，以由播放端解析出拉流数量的TS文件，并进行播放。

[0099] 在本公开的一个实施例中，确定模块704还用于：解析拉流操作中的拉流参数；在播放端使用第一网络协议请求媒体流数据时，将拉流参数中包括的第一数量确定为拉流数量；在播放端使用第一网络协议请求媒体流数据时，将拉流参数中包括的第二数量确定为拉流数量，其中，在第一数量小于第二数量。

[0100] 在本公开的一个实施例中，还包括：配置模块710，用于在视频帧缓存队列的头部存储视频帧中的编辑帧。

[0101] 在本公开的一个实施例中，配置模块710还用于：在第一源站基于推流端的推流操作接收到待缓存的视频帧时，将待缓存的视频帧存储在视频帧缓存队列的尾部。

[0102] 在本公开的一个实施例中，配置模块710还用于：检测待缓存的视频帧的类型；在检测到待缓存的视频帧为编辑帧时，确定处于视频帧缓存队列的头部的第一编辑帧，以及与第一编辑帧相邻的第二编辑帧；以及删除第一编辑帧与第二编辑帧之间的所有视频帧。

[0103] 在本公开的一个实施例中，第二源站包括转码节点、转码源站和边缘节点，拉流模块702还用于：边缘节点向转码源站请求媒体流数据；在转码源站未存储媒体流数据时，转码源站通知转码节点基于第一网络协议向第一源站对视频帧进行拉流操作。

[0104] 在本公开的一个实施例中，推送模块708还用于：转码节点接收第一源站反馈的拉流数量的视频帧，并对拉流数量的视频帧进行转码操作，得到转码文件；转码节点基于第一网络协议将转码文件推送至转码源站；转码源站将转码文件转换为拉流数量的TS文件，并基于拉流数量的TS文件生成媒体分片，以将媒体分片作为指定格式的媒体流推送至播放端。

[0105] 下面参照图8来描述根据本发明的这种实施方式的电子设备800。图8显示的电子设备800仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

[0106] 如图8所示，电子设备800以通用计算设备的形式表现。电子设备800的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830。

[0107] 其中，存储单元存储有程序代码，程序代码可以被处理单元810执行，使得处理单元810执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。例如，处理单元810可以执行如图1中所示的步骤S102、S104、S106和S108，以及本公开的视频推送方法中限定的其他步骤。

[0108] 存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)8201和/或高速缓存存储单元8202，还可以进一步包括只读存储单元(ROM)8203。

[0109] 存储单元820还可以包括具有一组(至少一个)程序模块8205的程序/实用工具8204，这样的程序模块8205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

[0110] 总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

[0111] 电子设备800也可以与一个或多个外部设备870(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备交互的设备通信，和/或与使得该电子设备800能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口850进行。并且，电子设备800还可以通过网络适配器860与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器860通过总线830与电子设备800的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

[0112] 通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD‑ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

[0113] 在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在终端设备上运行时，程序代码用于使终端设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。

[0114] 参考图9所示，描述了根据本发明的实施方式的用于实现上述方法的程序产品900，其可以采用便携式紧凑盘只读存储器(CD‑ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

[0115] 计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

[0116] 可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

[0117] 可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

[0118] 应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

[0119] 此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

[0120] 通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD‑ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

[0121] 本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。