CN116233421A - 基于WebRtc的拉流方法及相关设备 - Google Patents

Abstract

本发明提供一种基于WebRtc的拉流方法及相关设备。方法包括：在接收到数据包的情况下，利用包排序模块对数据包进行缓存、排序，以获得完整音视频帧；利用帧排序模块针对每个完整音视频帧填充对应的参考帧，以获得带参考帧的完整音视频帧；利用帧连续判断模块判断任一完整音视频帧是否连续，以在完整音视频帧连续并且该完整音视频帧的所有参考帧均解码的情况下，对完整音视频帧进行解码，进而获得解码后的音视频帧。由此，可以保证帧的连续性和完整性，进而可以有效避免出现拉流卡顿现象，实现了卡顿优化的同时，避免出现数据丢帧等问题。

Description

基于WebRtc的拉流方法及相关设备

技术领域

本发明涉及数据传输技术领域，更具体地，涉及一种基于WebRtc的拉流方法、一种基于WebRtc的拉流装置、一种电子设备以及一种存储介质。

背景技术

目前，WebRtc开源框架中实现了一套完整的从音视频推流到拉流的完整方案。Licode则是基于WebRtc的SFU/MCU实现，是具有音视频流订阅和分发能力的一套系统。而现有的基于WebRtc的拉流方案是完全以延时优先的一套策略，从音视频数据包接收到组帧、解码、渲染都以延时优先。而完全以延时优先的策略，在下行网络拉流过程中可能会出现丢包、乱序、网络抖动的情况，因此，基于WebRtc中现有拉流方案很容易出现渲染卡顿的情况。

因此，亟需一种新的技术方案以解决上述技术问题。

发明内容

在发明内容部分中引入了一系列简化形式的概念，这将在具体实施方式部分中进一步详细说明。本发明的发明内容部分并不意味着要试图限定出所要求保护的技术方案的关键特征和必要技术特征，更不意味着试图确定所要求保护的技术方案的保护范围。

第一方面，本发明提出一种基于WebRtc的拉流方法，包括：

在接收到数据包的情况下，利用包排序模块对数据包进行缓存、排序，以获得完整音视频帧；

利用帧排序模块针对每个完整音视频帧填充对应的参考帧，以获得带参考帧的完整音视频帧；

利用帧连续判断模块判断任一完整音视频帧是否连续，以在完整音视频帧连续并且该完整音视频帧的所有参考帧均解码的情况下，对完整音视频帧进行解码，进而获得解码后的音视频帧。

可选地，方法还包括：针对数据包进行编码，以根据所编码的数据大小将数据包封装为RTP格式；

利用包排序模块对数据包进行缓存、排序，以获得完整音视频帧，包括：根据封包格式和/或帧大小，将数据包拆分为一个或多个RTP数据包；将一个或多个RTP数据包按照序列号递增的顺序发送至服务器；根据序列号对RTP数据包进行标识，以获得开始帧和结束帧；基于开始帧和结束帧，从服务器拉流收取RTP数据包；针对RTP数据包进行桶排序，以获得完整视频帧。

可选地，针对RTP数据包进行桶排序，包括：

将RTP数据包插入包排序模块，以根据RTP数据包的序列号与当前包排序模块的容量进行哈希，以将RTP数据包插入对应的位置，若RTP数据包插入的位置已经存在数据包，则将当前包排序模块的容量进行扩张，其中，包排序模块的最大容量为4096。

可选地，在扩张当前包排序模块的容量的同时，方法还包括：

判断所插入的RTP数据包的序列号与当前最新的RTP数据包的序列号减去当前包排序模块的容量的数值之间的大小，对于所插入的RTP数据包的序列号小于数值的情况，丢弃所插入的RTP数据包。

可选地，利用帧排序模块针对每个完整音视频帧填充对应的参考帧，以获得带参考帧的完整音视频帧，包括：

对于帧排序模块收到任一帧的情况，确定任一帧所属的GOP表，并将任一帧的参考帧设置为GOP表内的任一帧的上一帧。

可选地，方法还包括：利用帧排序模块维护最近的至少三个GOP表。

可选地，方法还包括：计算下行网络的往返时延，并根据往返时延，对数据包进行重传。

可选地，方法还包括：根据往返时延，增加可控延时，并根据不同的往返时延动态调整可控延时。

第二方面，还提出了一种基于WebRtc的拉流装置，包括：

数据包排序模块，用于在接收到数据包的情况下，利用包排序模块对数据包进行缓存、排序，以获得完整音视频帧；

参考帧填充模块，用于利用帧排序模块针对每个完整音视频帧填充对应的参考帧，以获得带参考帧的完整音视频帧；

解码模块，用于利用帧连续判断模块判断任一完整音视频帧是否连续，以在完整音视频帧连续并且该完整音视频帧的所有参考帧均解码的情况下，对完整音视频帧进行解码，进而获得解码后的音视频帧。

第三方面，还提出了一种电子设备，其特征在于，包括处理器和存储器，其中，所述存储器中存储有计算机程序指令，计算机程序指令被处理器运行时用于执行如上所述基于WebRtc的拉流方法。

第四方面，还提出了一种存储介质，在所述存储介质上存储了程序指令，程序指令在运行时用于执行如上所述基于WebRtc的拉流方法。

根据上述技术方案，首先对数据包进行包排序，以获得完整音视频帧，接着针对完整音视频帧的每一帧填充参考帧，以对其进行帧排序，之后在所有参考帧全部收到并且所有参考帧均已解码的情况下，对可解码的、连续的音视频帧进行解码操作，最终获得解码后的音视频帧。由此，可以保证帧的连续性和完整性，进而可以有效避免出现拉流卡顿现象，实现了卡顿优化的同时，避免出现数据丢帧等问题。

本发明的基于WebRtc的拉流方法，本发明的其它优点、目标和特征将部分通过下面的说明体现，部分还将通过对本发明的研究和实践而为本领域的技术人员所理解。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本说明书的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的基于WebRtc的拉流方法的示意性流程图；

图2示出了根据本发明一个实施例的数据包接收与组帧优化的示意性流程图；

图3示出了根据本发明一个实施例的根据序列号对RTP数据包进行标识的示意图；

图4示出了根据本发明一个实施例的确定参考帧的示意图；

图5示出了根据本发明一个实施例的计算下行网络发送端的往返时延的示意图；

图6示出了根据本发明一个实施例的基于WebRtc的拉流装置的示意性框图；以及

图7示出了根据本发明一个实施例的电子设备的示意性框图。

具体实施方式

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。

根据本发明的第一方面，提出了一种基于WebRtc的拉流方法。图1示出了根据本发明一个实施例的基于WebRtc的拉流方法100的示意性流程图。如图1所示，方法100可以包括以下步骤。

步骤S110，在接收到数据包的情况下，利用包排序模块对数据包进行缓存、排序，以获得完整音视频帧。

步骤S120，利用帧排序模块针对每个完整音视频帧填充对应的参考帧，以获得带参考帧的完整音视频帧。

步骤S130，利用帧连续判断模块判断任一完整音视频帧是否连续，以在完整音视频帧连续并且该完整音视频帧的所有参考帧均解码的情况下，对完整音视频帧进行解码，进而获得解码后的音视频帧。

示例性地，WebRtc可以包括多个模块。其中，包排序模块可以利用PacketBuffer类实现对应的功能。具体地，PacketBuffer类负责帧的完整性，可以保证组成音视频帧的每个包的序列号的连续，并且有一个包标识着音视频帧的开始，有一个包标识着音视频帧的结束。帧排序模块可以利用RtpFrameReferenceFinder类实现对应的功能。具体地，RtpFrameReferenceFinder类负责给音视频帧的每个帧设置参考帧，同时兼顾GOP内各帧的连续性。帧连续判断模块可以利用FrameBuffer类实现对应的功能。具体地，FrameBuffer类负责帧的连续性和可解码性。可以理解，帧的连续性可以是指某帧的所有参考帧都已经收到，帧的可解码性可以是指某帧的所有参考帧均已经被解码。

图2示出了根据本发明一个实施例的数据包接收与组帧优化的示意性流程图。如图2所示，WebRtc的底层网络框架在接收到数据包后，可以根据数据包体类型进行路由，在图2所示实施例中，数据包是RTP包。RtpVideoStreamReceiver类在接收到RTP包后，将其发送给PacketBuffer类进行缓存、排序。PacketBuffer类在收集满一个完整的音视频帧后，将该完整音视频帧交还给RtpVideoStreamReceiver类。RtpVideoStreamReceiver类将该完整视频帧交给RtpFrameReferenceFinder类。如前所述，RtpFrameReferenceFinder类可以给音视频帧的每个帧设置参考帧。具体地，RtpFrameReferenceFinder类缓存最近的GOP表，每个完整音视频帧落在一个GOP表中会填充好该帧的参考帧，之后将填充了参考帧的完整音视频帧交还给RtpVideoStreamReceiver类，RtpVideoStreamReceiver类将填充好参考帧的完整音视频帧交给FrameBuffer类，FrameBuffer类判断所接收到的音视频帧的所有参考帧是否都收到，若所有参考帧都收到，则认为该音视频帧连续，反之，所有参考帧未都收到，则可以认为该音视频帧不连续。在该音视频帧的所有参考帧都解码后，可以对该音视频帧进行解码操作。具体地，可以将该音视频帧交给解码器例如VideoDecoder进行解码，进而获得解码后的音视频帧，最后可以对解码后的音视频帧进行渲染等操作。

根据上述技术方案，首先对数据包进行包排序，以获得完整音视频帧，接着针对完整音视频帧的每一帧填充参考帧，以对其进行帧排序，之后在所有参考帧全部收到并且所有参考帧均已解码的情况下，对可解码的、连续的音视频帧进行解码操作，最终获得解码后的音视频帧。由此，可以保证帧的连续性和完整性，进而可以有效避免出现拉流卡顿现象，实现了卡顿优化的同时，避免出现数据丢帧等问题。

可选地，方法还可以包括：针对数据包进行编码，以根据所编码的数据大小将数据包封装为RTP格式。

如前所述，Webrtc的底层网络框架接收到数据包后，可以根据数据包体类型进行路由，在一个实施例中，如果数据包是RTP包，可以将其插入到PacketBuffer类。具体地，针对数据包进行编码，可以在数据包编码后根据编码后的数据大小对推流侧的视频帧进行封装，将其封装成RTP格式的数据包。

在该实施例中，步骤S110利用包排序模块对数据包进行缓存、排序，以获得完整音视频帧可以包括以下步骤。

步骤S111，根据封包格式和/或帧大小，将数据包拆分为一个或多个RTP数据包。

具体地，可以根据数据包的封包格式和/或帧大小，将该数据包拆分成一个或者多个RTP数据包。对于拆分后的多个RTP数据包，赋予其连续的序列号。图3示出了根据本发明一个实施例的根据序列号对RTP数据包进行标识的示意图。如图3所示，数据包的序列号为5、6、7……。

步骤S112，将一个或多个RTP数据包按照序列号递增的顺序发送至服务器。

可选地，可以将多个RTP数据包按照序列号递增的顺序进行排列，之后将该递增序列发送到服务器。下行网络可以从服务器拉流收取RTP数据包。如前所述，Webrtc中PacketBuffer类则是负责视频帧的完整性，保证组成视频帧的每个RTP数据包的序列号连续。

步骤S113，根据序列号对RTP数据包进行标识，以获得开始帧和结束帧。

再次参见图3，序列号为5、6、7的RTP数据包组成完成的一帧视频，序列号为5的是帧的开始，具体地，对于序列号为5的数据包标识有“frame_start”，序列号为7的是帧的结束，对于序列号为7的数据包标识有“frame_end”。可以理解，序列号为5的数据包为开始帧，序列号为7的数据包为结束帧。

步骤S114，基于开始帧和结束帧，从服务器拉流收取RTP数据包。

结合前文所述，下行网络可以从服务器按照序列号5、6、7的顺序拉流收取RTP数据包。

步骤S115，针对RTP数据包进行桶排序，以获得完整视频帧。

在RTP数据包插入到PacketBuffer类中之后，可以对RTP数据包进行桶排序。本领域普通技术人员可以理解桶排序相关算法，为了简洁在此不进行详细描述。例如，PacketBuffer类在接收视频RTP数据包后可以进行序列号遍历，当有了前述开始帧和结束帧之后，同时从开始帧到结束帧之间RTP数据包的序列号是连续的情况下，即可以获得一个完整的视频帧。

可选地，步骤S115针对RTP数据包进行桶排序可以包括：将RTP数据包插入包排序模块，以根据RTP数据包的序列号与当前包排序模块的容量进行哈希，以将RTP数据包插入对应的位置，若RTP数据包插入的位置已经存在数据包，则将当前包排序模块的容量进行扩张，其中，包排序模块的最大容量为4096。

具体地，如前所述，可以将RTP数据包插入根据插入PacketBuffer类。此时，将插进来的视频RTP数据包的序列号与当前PacketBuffer类的容量进行哈希。可以理解，哈希是把任意长度的输入通过散列算法变换成固定长度的输出，这种转换是一种压缩映射。即，可以将RTP数据包插入到PacketBuffer类中的对应的位置，如果对应的位置已经存在有数据包，可以以倍数的形式对PacketBuffer类的容量进行扩张。在该实施例中，可以将PacketBuffer类的最大容量设置为4096。如果通过前述容量扩张操作，使得PacketBuffer类的容量超出其最大容量，那么在超出时可以清空整个PacketBuffer类里面所有缓存的视频数据，这个时候可能会造成帧的不连续，导致卡顿。可以理解，与现有的优化方法相比，将PacketBuffer类的默认最大容量从2048扩张成4096，可以存储更多的数据，防止PacketBuffer类的容量轻易被打爆。避免数据清空，造成卡顿。

可选地，在扩张当前包排序模块的容量的同时，方法还可以包括：判断所插入的RTP数据包的序列号与当前最新的RTP数据包的序列号减去当前包排序模块的容量的数值之间的大小，对于所插入的RTP数据包的序列号小于数值的情况，丢弃所插入的RTP数据包。

在前述扩张PacketBuffer类容量的同时，还可以执行判断操作。具体地，判断前述插入的RTP数据包的序列号与当前最新的视频RTP数据包序列号减去当前PacketBuffer类的容量的数值之间的大小关系，若插入的RTP数据包的序列号小于前述二者的差值，则可以丢弃该插入的RTP数据包。

由此，有效防止网络传输过程中，由于重传时间较长或路由时间较长的数据包重新发送到接收端，导致PacketBuffer类的容量被打爆，从而造成PacketBuffer类中的数据清空，造成卡顿现象。

可选地，步骤S120利用帧排序模块针对每个完整音视频帧填充对应的参考帧，以获得带参考帧的完整音视频帧可以包括：

步骤S121对于帧排序模块收到任一帧的情况，确定任一帧所属的GOP表，并将任一帧的参考帧设置为GOP表内的任一帧的上一帧。

图4示出了根据本发明一个实施例的确定参考帧的示意图。由于视频帧之间存在参考关系，也需要保证视频帧之间的连续性。如前所述，RtpFrameReferenceFinder类负责给每个帧设置参考帧，同时兼顾GOP内各帧的连续性。参见图4，I帧是GOP起始帧的自参考，后续GOP表内的每个帧都要参考上一帧。在收到P帧后，RtpFrameReferenceFinder类要对应找到P帧所属的GOP表，并将P帧的参考帧设置为GOP表内的该帧的上一帧。

由此可以保证视频帧的连续性，避免数据的丢失。

可选地，方法还包括：利用帧排序模块维护最近的至少三个GOP表。

在现有技术中，如果当前GOP收到I帧，在后续缺失P帧的情况下，若新来I帧，则创建一个新的GOP表，并清空当前的GOP表。换言之，现有技术中WebRtc只负责维护一个GOP表。而在本申请中，可以利用帧排序模块维护至少3个GOP表。由此，这样维持的GOP表中如果有P帧缺失的情况也不会立即清空对应的GOP表，即允许视频数据在一定时间内晚到，不会丢弃视频数据，保证了视频数据的完整性，避免造成卡顿。

可选地，方法还包括：计算下行网络的往返时延，并根据往返时延，对数据包进行重传。可以理解，往返时延可以指网络请求从起点到目的地然后再回到起点所花费的时长，在这个时长中不包括接收端的处理时间。对于WebRtc的往返世琰的计算可以分为两种情况，一是发送端估计，通过Sender Report(SR)和Receiver Report(RR)计算；二是只存在接收流，由接收端估计，通过RTCP Extended ReportRTCP(XR)计算。

图5示出了根据本发明一个实施例的计算下行网络发送端的往返时延的示意图。如图5所示，发送端的往返时延(RTT)可以通过以下公式进行计算：RTT＝receive_time_ntp-send_time_ntp-delay_since_last_sr。类似地，接收端的往返时延通过以下公式进行计算：RTT＝DLRR Report Block_Receiver Reference Time Report Block_delay_since_last_sr，其中，Receiver Reference Time Report Block由媒体流接收端发送，DLRRReport Block由媒体流发送端发送。一般地，WebRtc下行重传nack模块的默认重传往返时延是100毫秒，此时的往返时延没有根据下行真实网络情况去进行重传。而在客户端与服务端同时支持XR协议之后，可以根据上述技术方案计算出下行网络的往返时延，由此，当网络出现丢包情况，可以根据实际的网络情况进行更精准的重传，以实现对卡顿的优化。

可选地，方法还包括：根据往返时延，增加可控延时，并根据不同的往返时延动态调整可控延时。

可以理解，由于音频和视频帧大小的不同，在WebRtc中，音频和视频的jitterbuffer也就有各自的实现。其中音频延时为playout_delay_ms和jitter_delay(NetEq接收缓存延时)。视频延时则包含jitter_delay(jitterbuffer接收缓存延时)，decode_delay和render_delay，其中decode_delay和render_delay比较稳定，对整体延时计算影响较小。其中，不论是音频还是视频，对延时影响较大都是网络延时或者网络抖动。WebRtc由VCMJitterEstimator模块计算网络抖动，也就是jitter_delay，主要是为了平滑播放而人为增添的一个延时。WebRtc中音频和视频分别计算各自的网络抖动jitter_delay，最后作用到渲染时间得计算，然后由RtpStreamsSynchronizer模块去同步音视频。示例性地，根据下行网络是否发生卡顿，即往返时延，增加一个可控的延时，可以理解，延时buffer设置得越大，抗卡顿能力越强，当然延时也就越大。优选地，可以根据下行拉流发生卡顿情况对延时buffer进行调整。若没有发生卡顿，即设置最低延时；若发生卡顿，即增大延时，对应地，可以缓存更多的数据包，以方便重传，抗弱网。同时还可以根据不同的卡顿情况，去动态的增大目标延时。换言之，可以根据用户真实观看体验去调整用户的延时，以达到抗卡顿的效果。在一个具体实施例中，可以将相邻两帧渲染间隔大于200毫秒和/或相邻两帧采集间隔大于300毫秒的情况定义为卡顿。具体地，可以通过以下公式计算卡顿时长：render_dalta＝render_time_ms-last_render_time_ms，ntp_time_ms_delta＝ntp_time_ms-last_ntp_time_ms，lag_time＝max(render_dalta，ntp_time_ms_delta)，其中，render_time_ms表示当前帧渲染时间，last_render_time_ms表示与当前帧相邻的上一帧的渲染时间，render_dalta表示相邻两帧渲染间隔；ntp_time_ms表示当前帧采集时间，last_ntp_time_ms表示与当前帧相邻的上一帧的采集时间，ntp_time_ms_delta表示相邻两帧采集间隔，max(render_dalta，ntp_time_ms_delta)表示取相邻两帧渲染间隔差和采集时间差中较大者，lag_time表示卡顿时长。之后分别计算单次卡顿超过300毫秒、500毫秒、1000毫秒及以上的次数及卡顿时长，统计卡顿信息。根据当前延时与最大延时计算出一个比例因子increase_factor，目标延时调整延时大小adjust_delay由increase_factor与卡顿信息共同计算所得。具体可以通过以下公式计算得出：

其中，target_delay_ms表示目标延时，min_delay_ms表示最小延时，max_delay_ms表示最大延时。

，其中，lag_count_300ms、lag_count_500ms、ag_count_1000ms分别表示单次卡顿超过300毫秒、500毫秒、1000毫秒的卡顿时长，last_lag_count_300ms、last_lag_count_500ms、last_lag_count_1000ms分别表示上一次单次卡顿超过300毫秒、500毫秒、1000毫秒的卡顿时长。当目标延时趋近于max_delay_ms时，increase_factor越大，也就是目标延时愈发逼近最大延时，继续增大延时就越发困难。

根据上述技术方案，根据卡顿情况计算出了目标延时，最后需要同步到渲染延时上。而视频的目标延时TargetVideoDelay即current_delay_ms。

其中jitter_delay_ms为WebRtc中VCMJitterEstimator模块计算的网络抖动，RequiredDecodeTimeMs()为解码延时(固定延时)，render_delay_ms也为固定延时，只需要将根据卡顿计算的目标延时作用到min_playout_delay_ms，就可以控制视频的当前延时。同理，音频延时也是类似，将目标延时作用到音频的当前最小播放延时，但是同时还得考虑音视频同步过程。音视频同步过程中，可以根据当前音频延时与视频延时的差距，同时考虑音视频的采集时间差，也就是relative_delay_ms，一起进行控制，使得在延时增大或者下降过程尽量保证音视频同步。最后将同步后的目标延时设置到音视频各自的最小播放延时，达到可以动态控制延时的效果，从而可以很大程度上抗卡顿。

根据上述技术方案，根据当前延时与卡顿计算后的卡顿目标延时差距，去逼近，如果当前延时小于目标延时，就处于延时增大状态，如果当前延时大于目标延时，就处于延时减小状态，如果当前延时趋近于目标延时，就处于延时保持状态。当下行网络发生卡顿，可以根据用户卡顿情况增大目标延时。如果卡顿继续加剧，可以继续增大目标延时。待用户网络情况好转并且一定时间内没有发生卡顿，可以减小延时，即，动态控制下行网络延时，从而可以在很大程度上避免卡顿现象的发生。

根据本发明的第二方面，还提出了一种基于WebRtc的拉流装置。图6示出了根据本发明一个实施例的基于WebRtc的拉流装置600的示意性框图。如图6所示，装置600可以包括：数据包排序模块610、参考帧填充模块620、解码模块630。

数据包排序模块610，用于在接收到数据包的情况下，利用包排序模块对数据包进行缓存、排序，以获得完整音视频帧；

参考帧填充模块620，用于利用帧排序模块针对每个完整音视频帧填充对应的参考帧，以获得带参考帧的完整音视频帧；

解码模块630，用于利用帧连续判断模块判断任一完整音视频帧是否连续，以在完整音视频帧连续并且该完整音视频帧的所有参考帧均解码的情况下，对完整音视频帧进行解码，进而获得解码后的音视频帧。

根据本发明的第三方面，还提出了一种电子设备。图7示出了根据本发明一个实施例的电子设备700的示意性框图。如图7所示，电子设备700可以包括处理器710和存储器720，其中，存储器720中存储有计算机程序指令，计算机程序指令被处理器710运行时用于执行如上所述基于WebRtc的拉流方法。处理器710可以采用微处理器、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)中的至少一种硬件形式来实现。处理器710也可以是中央处理单元(CPU)、图形处理器(GPU)、专用的集成电路(ASIC)或者具有数据处理能力和/或指令执行能力的其它形式的处理单元中的一种或几种的组合，并且可以控制电子设备700中的其它组件以执行期望的功能。存储器720可以包括一个或多个计算机程序产品。计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。易失性存储器例如可以包括随机存取存储器(RAM)和/或高速缓冲存储器(cache)等。非易失性存储器例如可以包括只读存储器(ROM)、硬盘、闪存等。在计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器710可以运行该程序指令，以实现下文所述的本发明实施例中(由处理器实现)的客户端功能以及/或者其它期望的功能。在计算机可读存储介质中还可以存储各种应用程序和各种数据，例如所述应用程序使用和/或产生的各种数据等。

根据本发明的第四方面，还提出了一种存储介质，在存储介质上存储了程序指令，程序指令在运行时用于执行如上所述基于WebRtc的拉流方法。存储介质例如可以包括平板电脑的存储部件、计算机的硬盘、只读存储器(ROM)、可擦除可编程只读存储器(EPROM)、便携式紧致盘只读存储器(CD-ROM)、USB存储器、或者上述存储介质的任意组合。所述计算机可读存储介质可以是一个或多个计算机可读存储介质的任意组合。

本领域普通技术人员通过阅读上述有关基于WebRtc的拉流方法的相关描述，可以理解基于WebRtc的拉流装置、电子设备以及存储介质的具体细节以及有益效果，为了简洁在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和/或设备，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (11)

1.一种基于WebRtc的拉流方法，其特征在于，包括：

在接收到数据包的情况下，利用包排序模块对所述数据包进行缓存、排序，以获得完整音视频帧；

利用帧排序模块针对每个完整音视频帧填充对应的参考帧，以获得带参考帧的完整音视频帧；

利用帧连续判断模块判断任一完整音视频帧是否连续，以在所述完整音视频帧连续并且该完整音视频帧的所有参考帧均解码的情况下，对所述完整音视频帧进行解码，进而获得解码后的音视频帧。

2.如权利要求1所述的基于WebRtc的拉流方法，其特征在于，所述方法还包括：

针对所述数据包进行编码，以根据所编码的数据大小将所述数据包封装为RTP格式；

所述利用包排序模块对所述数据包进行缓存、排序，以获得完整音视频帧，包括：

根据封包格式和/或帧大小，将所述数据包拆分为一个或多个RTP数据包；

将所述一个或多个RTP数据包按照序列号递增的顺序发送至服务器；

根据所述序列号对所述RTP数据包进行标识，以获得开始帧和结束帧；

基于所述开始帧和所述结束帧，从所述服务器拉流收取所述RTP数据包；

针对所述RTP数据包进行桶排序，以获得所述完整视频帧。

3.如权利要求2所述的基于WebRtc的拉流方法，其特征在于，所述针对所述RTP数据包进行桶排序，包括：

将所述RTP数据包插入所述包排序模块，以根据所述RTP数据包的序列号与当前包排序模块的容量进行哈希，以将所述RTP数据包插入对应的位置，若所述RTP数据包插入的位置已经存在数据包，则将所述当前包排序模块的容量进行扩张，其中，所述包排序模块的最大容量为4096。

4.如权利要求3所述的基于WebRtc的拉流方法，其特征在于，在扩张所述当前包排序模块的容量的同时，所述方法还包括：

判断所插入的RTP数据包的序列号与当前最新的RTP数据包的序列号减去所述当前包排序模块的容量的数值之间的大小，对于所述所插入的RTP数据包的序列号小于所述数值的情况，丢弃所述所插入的RTP数据包。

5.如权利要求1至4任一项所述的基于WebRtc的拉流方法，其特征在于，所述利用帧排序模块针对每个完整音视频帧填充对应的参考帧，以获得带参考帧的完整音视频帧，包括：

对于所述帧排序模块收到任一帧的情况，确定所述任一帧所属的GOP表，并将所述任一帧的参考帧设置为所述GOP表内的所述任一帧的上一帧。

6.如权利要求4所述的基于WebRtc的拉流方法，其特征在于，所述方法还包括：

利用帧排序模块维护最近的至少三个GOP表。

7.如权利要求1至4任一项所述的基于WebRtc的拉流方法，其特征在于，所述方法还包括：

计算下行网络的往返时延，并根据所述往返时延，对所述数据包进行重传。

8.如权利要求7所述的基于WebRtc的拉流方法，其特征在于，所述方法还包括：

根据所述往返时延，增加可控延时，并根据不同的往返时延动态调整所述可控延时。

9.一种基于WebRtc的拉流装置，其特征在于，包括：

数据包排序模块，用于在接收到数据包的情况下，利用包排序模块对所述数据包进行缓存、排序，以获得完整音视频帧；

参考帧填充模块，用于利用帧排序模块针对每个完整音视频帧填充对应的参考帧，以获得带参考帧的完整音视频帧；

解码模块，用于利用帧连续判断模块判断任一完整音视频帧是否连续，以在所述完整音视频帧连续并且该完整音视频帧的所有参考帧均解码的情况下，对所述完整音视频帧进行解码，进而获得解码后的音视频帧。

10.一种电子设备，其特征在于，包括处理器和存储器，其中，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器运行时用于执行如权利要求1至8任一项所述基于WebRtc的拉流方法。

11.一种存储介质，在所述存储介质上存储了程序指令，所述程序指令在运行时用于执行如权利要求1至8任一项所述基于WebRtc的拉流方法。

Images