CN111294634A

CN111294634A - 直播方法、装置、***、设备及计算机可读存储介质

Info

Publication number: CN111294634A
Application number: CN202010122606.8A
Authority: CN
Inventors: 向晨宇
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-02-27
Filing date: 2020-02-27
Publication date: 2020-06-16
Anticipated expiration: 2040-02-27
Also published as: CN111294634B

Abstract

本发明公开了一种直播方法、装置、***、设备及计算机可读存储介质，本发明首先将尚未播放的音视频数据缓存至缓存区，当所述缓存区的音视频数据达到第一阈值，对所述缓存区中未播放的音视频数据中的音频数据进行加速播放；最后播放所述被加速播放的音频数据所对应的视频数据；本发明能够在播放端发生卡顿时，通过对缓存区中的音频数据进行加速播放，在保证直播内容的完整性的同时，缩小播放端播放内容与实时直播内容之间的时间差，自动实现播放端播放内容与实时直播内容同步；另外，本发明能够根据当前正在加速播放的音频数据来播放对应的视频数据，使音频和视频保持同步播放，提升用户的观看体验，可广泛应用于互联网技术领域。

Description

直播方法、装置、***、设备及计算机可读存储介质

技术领域

本发明涉及互联网技术领域，尤其是一种直播方法、装置、***、设备及计算机可读存储介质。

背景技术

直播是目前新兴的一种通过视频和音频的方式在网络平台上进行的实时播放，例如游戏直播、购物直播和秀场直播等。观众可以通过电脑、手机和平板电脑等设备来观看直播。

在直播过程中，由于客户端所处的网络状态环境比较复杂，当客户端所处网络发生抖动时会造成直播画面的突然卡顿，客户端画面会出现黑屏、等待缓冲提示、画面停止、声音停止等现象。等到网络状态恢复正常后，客户端会对尚未播放的音视频进行缓冲，缓冲到一定时长之后才恢复对尚未播放的音视频进行播放，此时，客户端播放的音视频是缓冲的音视频，其播放内容与实时直播内容之间存在时间差，导致用户无法观看到实时的直播内容，即使在网络恢复正常之后，也无法缩小这个时间差。现有技术只能通过刷新客户端的直播画面或者在关闭直播画面后重新进入直播画面，直接跳过非实时的直播内容后，才能观看实时的直播内容，这种通过舍弃未播放的直播内容来获得实时直播的方法，需要用户参与操作，不够智能高效，并且破坏了直播内容的完整性，造成用户观看内容的缺失。

发明内容

有鉴于此，本发明实施例提供了一种直播方法、装置、***、设备及计算机可读存储介质，在客户端发生画面卡顿后自动实现客户端播放内容与实时直播内容的同步，在保证直播内容的完整性的同时，能够缩小客户端播放内容与实时直播内容之间的时间差，并使音频和视频保持同步播放。

根据本发明的第一方面，提供了一种直播方法，包括：

获取直播内容的音视频数据并进行播放；

当播放出现卡顿，将未播放的音视频数据缓存至缓存区；

当所述缓存区的音视频数据达到第一阈值，对所述缓存区中未播放的音视频数据中的音频数据进行加速播放；以及

播放所述被加速播放的音频数据所对应的视频数据。

根据本发明的第二方面，提供了一种直播方法，包括：

向播放端发送音视频数据，以使所述播放端执行本发明第一方面所述的方法对所述音视频数据进行播放。

根据本发明的第三方面，提供了一种直播装置，包括：

获取模块，用于获取直播内容的音视频数据并进行播放；

缓存模块，用于当播放出现卡顿，将未播放的音视频数据缓存至缓存区；

加速播放模块，用于当所述缓存区的音视频数据达到第一阈值，对所述缓存区中未播放的音视频数据中的音频数据进行加速播放；以及播放所述被加速播放的音频数据所对应的视频数据。

根据本发明的第四方面，提供了一种直播***，包括推流端、服务器和播放端；所述推流端向所述服务器发送音视频数据，所述服务器向所述播放端发送所述音视频数据；所述播放端包括获取模块、缓存模块和加速播放模块；其中，

所述获取模块，用于获取直播内容的音视频数据并进行播放；

所述缓存模块，用于当播放出现卡顿，将未播放的音视频数据缓存至缓存区；

所述加速播放模块，用于当所述缓存区的音视频数据达到第一阈值，对所述缓存区中未播放的音视频数据中的音频数据进行加速播放；以及播放所述被加速播放的音频数据所对应的视频数据。

根据本发明的第五方面，提供了一种设备，所述设备包括处理器以及存储器；

所述存储器，用于存储程序；

所述处理器，用于执行所述程序以执行如本发明第一方面或者第二方面所述方法。

根据本发明的第六方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有程序，所述程序被处理器执行完成如本发明第一方面或者第二方面中所述的方法。

本发明能够在播放端的直播画面发生卡顿时，通过对缓存区中的音频数据进行加速播放，在保证直播内容的完整性的同时，缩小播放端播放内容与实时直播内容之间的时间差，自动实现播放端播放内容与实时直播内容同步；另外，本发明能够根据当前正在加速播放的音频数据来播放对应的视频数据，使音频和视频保持同步播放，提升用户的观看体验。

附图说明

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

图1为本发明实施例的一种网络架构示意图；

图2为本发明实施例涉及的音视频传输示意图；

图3为本发明实施例的一种直播方法的流程示意图；

图4为本发明实施例提供的播放端设备播放音视频的流程示意图；

图5为本发明实施例的音频帧/视频帧的排序示意图；

图6为本发明实施例提供的确定视频缓存区大小和音频缓存区大小的流程示意图；

图7为本发明实施例提供的确定视频帧队列大小和音频帧队列大小的流程示意图；

图8为本发明实施例提供的确定第一阈值的流程示意图；

图9为本发明实施例涉及的音视频同步播放的原理示意图；

图10为本发明实施例在正常速度播放时视频帧跟随音频帧同步播放的示意图；

图11为本发明实施例在加速播放时视频帧跟随音频帧同步播放的示意图；

图12为本发明实施例涉及的游戏直播画面卡顿的第一示意图；

图13为本发明实施例涉及的游戏直播画面卡顿的第二示意图；

图14为本发明实施例提供的音频播放流程示意图；

图15为本发明实施例的直播装置的结构示意图；

图16为本发明实施例的设备的结构示意图。

具体实施方式

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

图1是本发明实施例提供的一种网络架构的示意图。该网络架构可以包括推流端设备101，服务器102以及播放端设备103。其中，推流端设备101可以通过网络与服务器102连接，服务器102可以通过网络与播放端设备103连接。在图1所示的网络构架中，推流端设备101可以为主播上传直播画面的一端，播放端设备103可以为接收并播放直播画面的一端，推流端设备将直播画面上传至服务器102，再由服务器102将直播画面发送给播放端设备，并由播放端设备进行播放。

需要说明的是，本发明实施例的图1虽然仅展示了一个推流端设备、一个服务器和一个播放端设备，但在实际应用中，推流端设备、服务器以及播放端设备的个数均不仅限于一个。例如，当有多个主播同时上传直播画面时，推流端设备可以有多个；又如，当直播画面的数据量较大时，一个服务器无法满足大量数据的快速传输，则可以配置多个服务器；再如，当同一个直播画面有多个用户在观看时，多个用户对应的播放端设备也可以有多个。在此不对推流端设备、服务器和播放端设备的个数进行限定。

另外，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。播放端设备和推流端设备可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。所述设备与服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

基于图1所示的网络架构，在直播过程中，参见图2，推流端设备201将直播画面的音视频数据上传至服务器202时，会首先将音视频数据进行编码封装(也就是把音视频数据的模拟信号编码成计算机的二进制数据格式，视频数据在编码后的封装格式例如AVI、MKV、MP4、MOV、RMVB等封装格式；音频数据在编码后的封装格式例如MP3、AAC、WMA、WAV、FLAC等封装格式)，然后将封装的数据流上传至服务器202，服务器202将数据流发送给播放端设备203后，由播放端设备203对数据流进行解码播放(也称为解复用，就是把二进制数据格式转换成音视频数据的模拟信号)。

参见图2的第一数据流片段和第二数据流片段的传输过程，当推流端设备201的网络状况良好时，数据流上行速率与数据编码速率保持稳定，服务器202将数据流发送给播放端设备203，使得播放端设备203能够流畅播放直播画面。但是，当推流端设备201的数据流上行速率小于音视频数据编码速率时，则会产生积帧，参见图2的第三数据流片段和第四数据流片段的传输过程，第三数据流片段和第四数据流片段的上传时间远远大于第一数据流片段和第二数据流片段的上传时间，也就是封装好的数据流无法及时上传到服务器202，服务器202就无法及时将画面帧发送给播放端设备203，播放端设备203没有可以播放的画面，就会产生卡顿，即出现黑屏、等待缓冲提示、画面停止、声音停止等现象。

另一方面，当主播产生的直播画面帧能及时发送到服务器202，但播放端设备203的下行速率小于播放端设备的播放速率时，也就是服务器202传输的画面帧不能满足播放端设备在该播放速率下的正常播放，也会产生卡顿。

因此，在直播过程中，需要保证推流端设备的数据上行速率大于编码速率，且播放端设备的数据下行速率大于解码速率，才能保证直播画面的流畅。

针对上述卡顿问题，本发明实施例则能够在客户端发生画面卡顿后自动实现客户端播放内容与实时直播内容的同步，在保证直播内容的完整性的同时，能够缩小客户端播放内容与实时直播内容之间的时间差，并使音频和视频保持同步播放。

参见图3，本发明实施例基于图1所示的网络架构，提供了一种由播放端设备执行的直播方法，图3是本发明实施例提供的一种直播方法的流程示意图，包括步骤S301-S304：

S301，获取直播内容的音视频数据并进行播放；

具体地，播放端设备通过服务器接收推流端设备发送的直播内容的音视频数据，直播内容可以由推流端设备在直播现场采集得到，也可以是推流端设备录制播放内容后实时发送给服务器。例如，主播在使用终端设备进行游戏直播时，可以将终端设备上的游戏画面作为直播内容发送给服务器，也可以将主播的现场人物画面作为直播内容发送给服务器，进而由播放端设备进行播放。根据实际应用场景需要，主播还可以将提前录制好的画面内容实时提取出来发送给服务器，作为当前的直播内容。

S302，当播放出现卡顿，将未播放的音视频数据缓存至缓存区；

具体地，在播放出现卡顿时，播放端设备会从服务器下载音视频数据并缓存至缓存区，由于播放卡顿通常是由于网络抖动造成的，因此，本发明实施例为音频数据的缓存区创建一个音频缓存区，为视频数据的缓存区创建一个视频缓存区，在直播画面发生卡顿时，分别将未播放的音频数据存入音频缓存区以及将未播放的视频数据存入视频缓存区。本发明实施例的视频缓存区和音频缓存区大小为2000帧。

S303，当缓存区的音视频数据达到第一阈值，对缓存区中未播放的音视频数据中的音频数据进行加速播放。

具体地，本发明实施例在发生卡顿后，首先将未播放的音视频数据缓存至缓存区，在缓存的数据量达到第一阈值时，对缓存区中未播放的音视频数据中的音频数据进行加速播放，以降低用户看到直播画面的延迟率，使观众用户能够看到最新的直播画面。

本发明实施例中提到的数据量达到第一阈值，包括但不限于以下几种情况：

1)缓存区存储的音视频数据对应的播放时长大于时长阈值；

2)缓存区存储的音视频数据的帧数大于帧数阈值。

比如，以第1)种情况为例，一个实施例中设定好的第一阈值为2秒播放时长对应的数据量，当缓冲的音视频数据量足够播放2秒以上的时长时，将对该缓存内容进行加速播放，以尽快追上实时的直播内容。

S304，播放所述被加速播放的音频数据所对应的视频数据。

本发明实施例在加速播放的音频帧的时候，通过同步播放音频数据所对应的视频数据，实现了加速播放过程中的音视频同步，保障了用户的观看体验。

优选地，在步骤S302和步骤S303之间，本发明实施例还具有以下步骤：

当所述缓存区的音视频数据达到第二阈值，按照正常播放速度对所述缓存区中的未播放的音视频数据中的音频数据进行播放；以及将所述按照正常播放速度播放的音频数据所对应的视频数据进行播放；其中，所述第二阈值小于所述第一阈值。

具体地，由于在直播画面发生卡顿的时候，缓存区的缓存数据是从少到多不断积累的，当缓存的数据量较少(即达到第二阈值)时，如果直接对音视频进行加速播放，很快就消耗完缓存区中的缓存数据，新的音视频数据还没接收过来，则又会形成新的卡顿，播放画面不流畅，影响用户的观看体验。因此，本发明实施例在缓存的数据量达到较小的第二阈值时，首先按照正常播放速度对缓存的音视频进行播放，此时缓存区的数据量继续积累，当数据量达到步骤S303所述的第一阈值时，才对缓存区中未播放的音视频数据中的音频数据进行加速播放，这时候，虽然主播仍在实时上传未播放的直播画面，但由于播放端这一侧的加速播放，主播上传的数据量小于加速播放的数据量，会导致缓存区的数据量逐渐减少，直至数据量达到第二阈值时，恢复正常播放速度来播放音频数据；这样就能保证加速播放的过程中，缓存区中始终有缓存数据等候播放，保持了播放画面的流畅，提升用户的观看体验。

比如，一个实施例中设定好的第二阈值为1秒播放时长对应的数据量，当缓冲的音视频数据量仅仅能够播放小于或等于1秒的时长时，将加速播放速度恢复为正常播放速度，以保持播放画面的流畅。

参见图4，对于步骤S303和S304,本发明实施例的播放端设备在播放直播内容的音视频数据时，包括步骤S401-S406。

S401，将封装格式的数据流解封装为音频数据和视频数据；

具体地，本发明实施例首先从服务器中下载带有封装格式的流媒体协议数据，将这些带有封装格式流媒体协议数据，解析为标准的相应的封装格式数据，这些协议在传输视音频数据的同时，也会传输一些信令数据，解协议的过程中会去除掉信令数据而只保留音视频数据。然后将带有封装格式的音视频数据，分离成为音频流压缩编码数据和视频流压缩编码数据。

S402包括S4021和S4022；

S4021，将音频数据存放到音频缓存区；

S4022，将视频数据存放到视频缓存区；

具体地，本发明实施例将解封装得到的音频流压缩编码数据存放到音频缓存区，以及将解封装得到的视频流压缩编码数据存放到视频缓存区。

本发明实施例通过创建音频缓存区和视频缓存区，能够防止网络抖动导致的卡顿，提升用户的观看体验。例如图4所示，以2000帧作为音频缓存区和视频缓存区的缓存大小，本发明实施例可以在缓存了1000帧数据的时候，开始播放第1帧的数据，这样就能保证缓存区中的1-1000帧数据都能流畅播放。如果没有配置本发明实施例的音频缓存区和视频缓存区，则无法提前缓存1000帧数据，那么播放端设备就会从第1帧开始逐帧下载音视频数据并且逐帧播放音视频数据，这种情况下，一旦播放端设备的网络出现抖动，比如播放到第10帧时，第11帧没有下载完成，则会出现卡顿，这时播放端设备只有等待第11帧下载完成后才能继续播放，无法保证播放内容的流畅。

S403，从音频缓存区和视频缓存区中提取音频数据和视频数据，对音频数据和视频数据进行解码，得到音频帧和视频帧；

具体地，本发明实施例将解封装得到的视频压缩编码数据解码成为非压缩的视频原始数据，例如把压缩编码的视频数据，输出成为非压缩的颜色数据，颜色数据包括YUV420P，RGB等数据。

以及，将解封装得到的音频压缩编码数据解码成为非压缩的音频原始数据，例如把压缩编码的音频数据输出成为非压缩的音频抽样数据，音频抽样数据包括PCM数据等。

S404，将解码得到的音频帧和视频帧进行渲染；

具体地，以企鹅电竞平台的视频渲染为例，企鹅电竞平台的渲染器通过接收RGB/YUV数据，具体渲染过程中，播放端设备会通过设备的显卡等硬件来将RGB/YUV数据画成一帧帧图像。

S405包括步骤S4051和S4052，本发明实施例将渲染后的视频帧和音频帧进行重排后执行步骤S4051和S4052：

S4051，将重排后的视频帧存入视频帧队列；

S4052，将重排后的音频帧存入音频帧队列。

具体地，本发明实施例将渲染后的视频帧和音频帧进行重新排序，按照各个所述音频帧所对应的显示时间戳的顺序将各个所述音频帧存入音频帧队列，以及按照各个所述视频帧所对应的显示时间戳的顺序将各个所述视频帧存入视频帧队列。如图5所示，本发明实施例假设渲染后得到的音频帧/视频帧的顺序为：“7、8、9、10、5”，则在经过步骤S405重新排序后的音频帧/视频帧的顺序则为：“5、7、8、9、10”。

S406，播放排列好的视频帧和音频帧。

本发明实施例通过视频帧和音频帧的显示时间戳(Presentation Time Stamp，PTS)来顺序播放音频帧和视频帧。

参见图6，本发明实施例提供了确定视频缓存区大小和音频缓存区大小的方法，图6是本发明实施例提供的确定视频缓存区大小和音频缓存区大小的流程示意图，包括步骤S601-S605；

S601,获取第一数据；

本发明实施例的第一数据的获取可以由直播视频信息监控装置来实现，例如直播平台的后台数据库，可以用来获取用户观看记录；信息监控装置也可以是在视频直播程中能够对直播的视频信息进行监控的设备。信息监控装置可以通过对视频直播过程中的所有数据进行分类采集，得到的源数据可以包括：内容分发网络(Content Delivery Network，CDN)质量数据、用户体验数据、直播质量数据等视频直播过程产生的各种类型的数据，例如用户在观看直播内容时的观看记录。

具体地，以企鹅电竞直播平台为例，用户在企鹅电竞直播平台上观看直播内容时，企鹅电竞直播平台的后台数据库能够收集所有用户的观看记录，本发明实施例的用于数据分析的第一数据包括以下内容：1)用户在打开一个新的直播画面时的首次缓冲时间；2)用户在观看直播画面时发生的二次缓冲时间，需要说明的是，本发明实施例将播放过程中除首次缓冲之外的所有缓冲称为二次缓冲；3)用户在观看完整的直播内容的过程中，画面流畅播放的无缓冲时间在总播放时长的占比；4)用户在观看直播画面时，平均每播放一小时出现的二次缓冲次数；5)用户在观看直播画面时，平均每播放一小时出现的错误次数(例如音频帧丢失，视频帧播放顺序出错等)；6)用户在观看不同直播内容时，出现的二次缓冲次数大于1的直播比例；7)用户在观看完整的直播内容的过程中，不同清晰度的播放时长在总播放时长中的占比。

可以理解的是，本领域的技术人员可以根据实际需要获取其他观看记录数据，上述举例的观看记录数据是为了清楚说明本发明实施例的一种具体实施方案，在此不对观看记录数据的内容进行限定。

S602,从所述第一数据中获取不同帧数大小的缓存区对应的播放质量参数的值，所述播放质量参数包括以下一种或多种：首次缓冲时长、二次缓冲时长、无缓冲率、平均每播放一小时出现的二次缓冲次数、平均每播放一小时出现的错误次数以及清晰度；

具体地，本发明实施例可以选取不同帧数大小的缓存区(例如1500帧、2000帧、2500帧、3000帧)，分配给不同的用户，然后通过步骤S601来获取这些用户的观看记录，进而得到不同帧数大小对应的播放质量参数的值。

需要说明的是，本发明实施例的播放质量参数中，首次缓冲时长根据用户在打开一个新的直播画面时的首次缓冲时间来确定；首次缓冲时长的计算公式为：

首次缓冲时长＝max(0,min(100,-0.5+103.52829×(0.00001/(1+exp((X₁×1.3-1.6)/0.8))+(1-0.00001)/(1+exp((X₁×1.3-4.8)/1.2)))))；

其中，exp代表开方；X₁代表首次缓冲时间的具体数值。

二次缓冲时长根据用户在观看直播画面时发生的二次缓冲时间来确定；二次缓冲时长的计算公式为：

二次缓冲时长＝min(100,max(0,(-2.65489)×pow(10,-7)×exp(-min(24,X₂/2+1.5)/-0.52007)-8.55291×exp(-min(24,X₂/2+1.5)/-5.68698)+112.19011))；

其中，exp代表开方；X₂代表二次缓冲时间的具体数值；pow代表平方。

无缓冲率根据用户在观看完整的直播内容的过程中，画面流畅播放的无缓冲时间在总播放时长的占比来确定；无缓冲率的计算公式为：

无缓冲率＝min(100,max(0,109.65485-111.02498/pow((1-0.01009×min(100,(0.98-X₃)×100)),(1/-1.82083))))；

其中，X₃代表画面流畅播放的无缓冲时间在总播放时长的占比；pow代表平方。

平均每播放一小时出现的二次缓冲次数的计算公式为：

平均每播放一小时出现的二次缓冲次数＝

min(100,max(0,min(100,-5.7+113.84829×(0.45469/(1+exp(((X₄/2.2+1.5)×10-24.48895)/5.64201))+(1-0.45469)/(1+exp(((X₄/2.2+1.5)×10-56.82314)/4.61486))))))；

其中，exp代表开方；X₄代表平均每播放一小时出现的二次缓冲次数。

平均每播放一小时出现的错误次数的计算公式为：

平均每播放一小时出现的错误次数＝

min(100,max(0,-1084875+1084960×exp(-X₅×2.2/155685.63359)+29.7503×exp(-X₅×2.2/0.8932)))；

其中，exp代表开方；X₅代表平均每播放一小时出现的错误次数。

清晰度根据用户在观看完整的直播内容的过程中，不同清晰度的播放时长在总播放时长中的占比来确定。

本发明实施例提供了清晰度的值的确定步骤，具体包括：获取蓝光播放时长占比、超清播放时长占比和流畅播放时长占比；确定所述蓝光播放时长占比的权重、超清播放时长占比的权重和流畅播放时长占比的权重；以及根据所述蓝光播放时长占比、超清播放时长占比、流畅播放时长占比、所述蓝光播放时长占比的权重、超清播放时长占比的权重和流畅播放时长占比的权重，确定所述清晰度。

具体地，本发明实施例中，蓝光播放时长占比的权重为100，超清播放时长占比的权重为80，流畅播放时长占比的权重为60，即清晰度的计算公式为：

清晰度＝蓝光播放时长占比×100+超清播放时长占比×80+流畅播放时长占比×60。

本发明实施例在获取到不同帧数大小的缓存区对应的各个变量值(包括首次缓冲时间的值、二次缓冲时间的值、无缓冲时间在总播放时长的占比值、平均每播放一小时出现的二次缓冲次数以及平均每播放一小时出现的错误次数)后，代入上述播放质量参数的计算公式，计算得到各个播放质量参数的值。

S603，确定各个播放质量参数对应的权重；

本发明实施例设置各个播放质量参数的权重为：

首次缓冲时长的权重为15％、二次缓冲时长的权重为10％、无缓冲率的权重为20％、平均每播放一小时出现的二次缓冲次数的权重为10％、平均每播放一小时出现的错误次数的权重为20％以及清晰度的权重为25％。

S604，根据播放质量参数的值和权重，计算各个帧数大小对应的播放质量总分；以及

S605，将总分最高对应的帧数大小确定为视频缓存区大小和音频缓存区大小。

经计算，2000帧的音频缓存区和视频缓存区对应的播放质量总分最高，说明用户体验较优，因此本发明实施例将2000帧作为音频缓存区和视频缓存区的大小，即如图4所示的视频缓存区和音频缓存区大小。对于总分较高的缓存区大小，既能为播放端设备提供足够的缓存数据，以保证播放内容连贯流畅，又能避免因缓存区的空间需求过大而造成存储成本较高，实现了播放效果与成本控制的最优平衡。

另外，参见图7，本发明实施例提供了确定所述视频帧队列大小和音频帧队列大小的方法，包括步骤S701-S705：

S701，获取第二数据；

S702，从所述第二数据中获取不同帧数大小对应的帧队列的播放质量参数的值，所述播放质量参数包括以下一种或多种：首次缓冲时长、二次缓冲时长、无缓冲率、平均每播放一小时出现的二次缓冲次数、平均每播放一小时出现的错误次数以及清晰度；

S703，确定各个播放质量参数对应的权重；

S704，根据播放质量参数的值和所述权重，计算各个帧数大小对应的播放质量总分；以及

S705，根据各个帧数大小对应的播放质量总分，确定音频帧队列大小和视频帧队列大小。

具体地，对于本发明实施例的第二数据，其获取也可以由直播视频信息监控装置来实现；信息监控装置可以是在视频直播程中能够对直播的视频信息进行监控的设备。信息监控装置可以通过对视频直播过程中的所有数据进行分类采集，得到的源数据可以包括：内容分发网络(Content Delivery Network，CDN)质量数据、用户体验数据、直播质量数据等视频直播过程产生的各种类型的数据，例如用户在观看直播内容时的观看记录。

可以理解的是，本发明实施例描述的第二数据的获取方式可以与第一数据的获取方式一样，区别于第一数据，本发明实施例则是选取不同帧数大小的视频帧队列和音频帧队列(例如5帧、6帧、7帧、8帧、10帧)，分配给不同的用户，然后通过步骤S701来获取这些用户的观看记录，进而得到不同帧数大小对应的播放质量参数的值，最终确定第二数据的值。例如，为用户配置视频帧队列大小为10帧，音频帧队列大小为6帧，用户在观看直播内容的时候发生卡顿，此时能获取用户在10帧的视频帧队列大小和6帧的音频帧队列大小下的观看记录，观看记录包括以下内容：1)用户在打开一个新的直播画面时的首次缓冲时间；2)用户在观看直播画面时发生的二次缓冲时间，需要说明的是，本发明实施例将播放过程中除首次缓冲之外的所有缓冲称为二次缓冲；3)用户在观看完整的直播内容的过程中，画面流畅播放的无缓冲时间在总播放时长的占比；4)用户在观看直播画面时，平均每播放一小时出现的二次缓冲次数；5)用户在观看直播画面时，平均每播放一小时出现的错误次数(例如音频帧丢失，视频帧播放顺序出错等)；6)用户在观看不同直播内容时，出现的二次缓冲次数大于1的直播比例；7)用户在观看完整的直播内容的过程中，不同清晰度的播放时长在总播放时长中的占比。

另外，对于本发明实施例的步骤S702-S705的实现过程，本领域技术人员可以理解到其实现原理与步骤S602-S605的实现原理相同，均是通过计算不同帧数大小对应的播放质量总分来确定一个最优的视频帧队列大小和音频帧队列大小。如图4所示，本发明实施例确定的最优视频帧队列大小为10帧，最优音频帧队列大小为6帧。基于10帧的视频帧队列和6帧的音频帧队列，能够实现音视频播放的连贯流畅，又能避免因队列的空间需求过大而造成存储成本较高，实现了播放效果与成本控制的最优平衡。但需要说明的是，本发明实施例描述的最优视频帧队列大小和最优音频帧队列大小只是一个具体实施方式，在此并不对视频帧队列大小和音频帧队列大小进行限定。

参见图8，本发明实施例提供了确定第一阈值的方法，该方法包括步骤S801-S805。

S801，获取第三数据；

S802，从第三数据中获取不同缓存量对应的播放质量参数的值，所述播放质量参数包括以下一种或多种：首次缓冲时长、二次缓冲时长、无缓冲率、平均每播放一小时出现的二次缓冲次数、平均每播放一小时出现的错误次数以及清晰度；

S803，确定各个播放质量参数对应的权重；

S804，根据播放质量参数的值和所述权重，计算各个缓存量对应的播放质量总分；以及

S805，将总分最高对应的缓存量确定为第一阈值。

具体地，对于本发明实施例的第三数据，其获取也可以由直播视频信息监控装置来实现；信息监控装置可以是在视频直播程中能够对直播的视频信息进行监控的设备。信息监控装置可以通过对视频直播过程中的所有数据进行分类采集，得到的源数据可以包括：内容分发网络(Content Delivery Network，CDN)质量数据、用户体验数据、直播质量数据等视频直播过程产生的各种类型的数据，例如用户在观看直播内容时的观看记录。

可以理解的是，本发明实施例描述的第三数据的获取方式可以与第一数据/第二数据的获取方式一样。区别于第一数据和第二数据，本发明实施例则是选取不同缓存量的缓存时长(例如2秒、5秒、10秒)，然后记录各个用户在观看不同缓存量的直播内容时的观看记录，进而得到不同缓存量对应的播放质量参数的值。例如，当缓存量的缓存时长设为2秒时，用户在观看直播的过程中发生了卡顿，此时这个2秒的缓存量就能发挥作用，进而就能获取用户在观看直播内容时候的观看记录，观看记录包括以下内容：1)用户在打开一个新的直播画面时的首次缓冲时间；2)用户在观看直播画面时发生的二次缓冲时间，需要说明的是，本发明实施例将播放过程中除首次缓冲之外的所有缓冲称为二次缓冲；3)用户在观看完整的直播内容的过程中，画面流畅播放的无缓冲时间在总播放时长的占比；4)用户在观看直播画面时，平均每播放一小时出现的二次缓冲次数；5)用户在观看直播画面时，平均每播放一小时出现的错误次数(例如音频帧丢失，视频帧播放顺序出错等)；6)用户在观看不同直播内容时，出现的二次缓冲次数大于1的直播比例；7)用户在观看完整的直播内容的过程中，不同清晰度的播放时长在总播放时长中的占比。

另外，对于本发明实施例的步骤S802-S805的实现过程，本领域技术人员可以理解到其实现原理与步骤S602-S605的实现原理相同，步骤S802-S805是通过计算不同缓存量对应的播放质量总分来确定一个最优的第一阈值。本发明实施例确定的第一阈值为2秒播放时长的数据量。也就是说，当缓存区中缓存的数据量可以播放2秒以上时，则对所述缓存区中的未播放的音视频数据中的音频数据进行加速播放，能够在实现尽快追上实时直播内容的同时，保持音视频播放的流畅。但需要说明的是，本发明实施例描述的最优第一阈值只是一个具体实施方式，在此并不对第一阈值的大小进行限定。

还需要说明的是，本发明实施例对所述缓存区中未播放的音视频数据中的音频数据进行加速播放的速度小于或等于正常播放速度的1.185倍。

具体地，图9是本发明实施例涉及的音视频同步播放的原理示意图，在采集音频帧和视频帧的时候会给每一帧数据标记上对应的显示时间戳，用来标记音频帧和视频帧的播放时间。音频帧被采集后送入扬声器以既定的速率播放，每播放一帧音频数据，就把当前正在播放音频帧的显示时间戳更新到主时钟(Master Clock)中，视频帧则根据主时钟的时间戳来决定是否进行渲染，实现音视频同步播放。如图9所示，例如当前播放的音频帧1的显示时间戳为1，将该显示时间戳更新至主时钟，由于此时主时钟的时间戳为1。在播放视频帧的时候，如图9所示，存在以下三种情况：

1)假设音视频同步的阈值为min(例如25ms)，则当前待渲染的视频帧与主时钟之间的时间戳差值在25ms范围内(即-min≤diff≤min)，即可将待渲染的视频帧进行正常的渲染播放。

2)假设当前待渲染的视频帧与主时钟之间的时间戳差值为diff，如果diff大于0(即min<diff<max)，则代表待渲染的视频帧已经提前准备好了，这种情况下可以等待主时钟的更新，直到当前待渲染的视频帧与主时钟之间的时间戳差值在min范围内(即等待时长为diff-min)，再渲染并播放视频帧。

3)假设视频帧等待主时钟的时间过长，说明出现了异常视频帧，此时需要丢弃异常视频帧，本发明实施例为了防止视频帧等待渲染的时间过长，设定一个异常阈值max(例如1000ms)，如果diff超过这个max(即diff<-min||diff>max)，则认为当前待渲染的视频帧为异常帧，丢弃对应的视频帧。

由于音频数据和视频数据是分开采集并分别播放的，所以音频帧和视频帧的显示时间戳不一定能够完全对得上，因此，只要音频帧和对应视频帧的播放间隔在一个合理的阈值范围内，即可认为音频和视频是同步播放的。对此，国际标准ITU-R BT.1359-1定义了以下阈值，来明确肉眼无法察觉、能够察觉以及无法接受的音视频播放间隔：

1.无法察觉：播放音频和视频的时间戳差值在：-100ms～+25ms之间；

2.能够察觉：播放音频相对于视频滞后了100ms以上，或者超前了25ms以上；

3.无法接受：播放音频相对于视频滞后了185ms以上，或者超前了90ms以上。

基于上述国际标准可知，当直播发生卡顿的时候，以1000帧作为音频缓存区的大小为例，则播放端设备以正常播放速度的“1+(185/1000)＝1.185”倍速度来进行加速播放，即可实现在肉眼可接受的范围内最快实现追帧。因此，本发明实施例对缓存区中未播放的音视频数据中的音频数据进行加速播放的速度确定为小于或等于正常播放速度的1.185倍。

对于步骤S304中所述播放被加速播放的音频数据所对应的视频数据，本发明实施例提供了以下步骤S3041和S3042这两种实现方式：

S3041，将排列在当前正在加速播放的音频帧所对应的视频帧之前的视频帧丢弃，从当前正在加速播放的音频帧所对应的视频帧开始，顺序播放视频帧队列中的视频帧；

或者，

S3042，跳过排列在当前正在加速播放的音频帧所对应的视频帧之前的视频帧，从当前正在加速播放的音频帧所对应的视频帧开始，顺序播放视频帧队列中的视频帧。

在正常播放速度的情况下，如图10所示，假设本发明实施例的音频帧从第5帧开始播放，同时，视频帧也从第5帧开始播放，当视频帧播放完第6帧视频时，此时音频帧正在播放第7帧音频，因此视频帧只需跟随音频帧播放第7帧，就能实现视频跟音频同步播放；同理，当音频正常播放到其他帧数时，视频也能正常同步播放。

在加速播放速度的情况下，如图11所示，假设本发明实施例的音频帧从第5帧开始加速播放，由于音频帧是加速播放，当音频帧播放完第10帧的时候，视频帧才播放完第6帧，此时，音频和视频的播放内容显然无法保持同步，因此，本发明实施例会将排列在当前正在加速播放的音频帧所对应的视频帧之前的视频帧丢弃(如图11所示的7-10帧)，或者，跳过排列在当前正在加速播放的音频帧所对应的视频帧之前的视频帧(如图11所示的7-10帧)，从当前正在加速播放的音频帧所对应的视频帧开始(即第11帧视频帧)，顺序播放视频帧队列中的视频帧，从而实现了加速播放过程中的音视频同步，保障了用户的观看体验。

下面以游戏直播的应用场景为例，来进一步说明本发明实施例的直播方法。游戏直播是指实时播放游戏玩家在游戏应用中的游戏画面，这里的游戏玩家即为主播。本申请中的游戏可以是例如王者荣耀、欢乐斗地主、QQ飞车等运行在移动终端的游戏应用，也可以是例如英雄联盟、穿越火线、地下城与勇士等运行在计算机终端的游戏应用，本申请不对游戏的种类进行限定。

如图12所示，当播放端设备的网络发生抖动时，游戏直播画面出现卡顿，客户端画面出现黑屏，并提示“当前无网络，请稍候再试”，这时，用户只能通过客户端画面的返回键1201关闭直播画面后重新进入直播画面，直接跳过非实时的直播内容后，才能观看实时的直播内容；或者通过客户端画面的刷新键1202来刷新客户端的直播画面，同样在跳过非实时的直播内容后，才能观看实时的直播内容。

又如图13所示，在例如王者荣耀的游戏直播过程中，当播放端设备的网络发生抖动时，游戏直播画面出现卡顿，客户端画面出现等待缓冲提示(如图13的缓冲标记1303)，这时，用户同样只能通过客户端画面的返回键1301关闭直播画面后重新进入直播画面，直接跳过非实时的直播内容后，才能观看实时的直播内容；或者通过客户端画面的刷新键1302刷新客户端的直播画面，同样在跳过非实时的直播内容后，才能观看实时的直播内容。

图14是以王者荣耀的游戏直播为例的音视频播放流程示意图，包括步骤S1401-S1407。

首先，S1401，播放王者荣耀的游戏画面内容。

S1402，判断游戏直播画面是否出现卡顿，若是，则执行步骤S1403；反之，则返回执行步骤S1401。

S1403，将直播画面的音频帧和视频帧缓存至缓存区。

S1404，判断缓存区中缓存的数据是否达到第二阈值的音频数据，若是，则执行步骤S1405；反之，则返回执行步骤S1403。

S1405，判断缓存区中缓存的数据是否达到第一阈值的音频数据，若是，则执行步骤S1406；反之，则执行步骤S1407。

S1406，对缓存区中的未播放的音视频数据中的音频数据进行加速播放。

S1407，按照正常播放速度对缓存区中的未播放的音视频数据中的音频数据进行播放。

具体地，本发明实施例在对游戏直播画面的音频帧和视频帧进行缓存时，当缓存区的音视频数据达到第二阈值且未达到第一阈值时，按照正常播放速度对缓存区中的未播放的音视频数据中的音频数据进行播放；以及将按照正常播放速度播放的音频数据所对应的视频数据进行播放。其中，第二阈值小于所述第一阈值。

由于在直播画面发生卡顿的时候，缓存区的缓存数据是从少到多不断积累的，当缓存的数据量较少(即达到第二阈值)时，如果直接对音视频进行加速播放，很快就消耗完缓存区中的缓存数据，新的音视频数据还没接收过来，则又会形成新的卡顿，播放画面不流畅，影响用户的观看体验。因此，本发明实施例在缓存的数据量达到较小的第二阈值时，首先按照正常播放速度对缓存的音视频进行播放，此时缓存区的数据量继续积累，当数据量达到步骤S303所述的第一阈值时，才对缓存区中未播放的音视频数据中的音频数据进行加速播放，这时候，虽然主播的推流端设备仍在实时上传未播放的直播画面，但由于播放端这一侧的加速播放，主播上传的数据量小于加速播放的数据量，会导致缓存区的数据量逐渐减少，直至数据量达到第二阈值时，恢复正常播放速度来播放音频数据；这样就能保证加速播放的过程中，缓存区中始终有缓存数据等候播放，保持了播放画面的流畅，提升用户的观看体验。

本发明实施例在游戏直播内容的播放出现卡顿时，将未播放的音视频数据缓存至缓存区；当缓存区的音视频数据达到第一阈值，对缓存区中未播放的音视频数据中的音频数据进行加速播放；以及播放所述被加速播放的音频数据所对应的视频数据。

通过本发明实施例的方法，能够在保证游戏直播内容的完整性的同时，缩小播放端播放内容与实时直播内容之间的时间差，自动实现播放端播放内容与实时直播内容同步；另外，本发明能够根据当前正在加速播放的音频数据来播放对应的视频数据，使音频和视频保持同步播放，提升用户的观看体验。

本发明实施例还提供了一种直播方法，由推流端执行，包括：向播放端发送音视频数据，以使所述播放端执行前述直播方法对音视频数据进行播放。

参见图15，其示出了本发明实施例一种直播装置的方框图，该直播装置应用于播放端设备中，比如该装置可以通过硬件或者软硬结合的方式实现播放端设备的部分或者全部功能，以实现如上述直播方法中的步骤。其中，播放端设备可以是图1所示的网络架构中的播放端设备。如图15所示，该直播装置包括获取模块1501、缓存模块1502以及加速播放模块1503，其中：

获取模块1501，用于获取直播内容的音视频数据并进行播放；

缓存模块1502，用于当播放出现卡顿，将未播放的音视频数据缓存至缓存区；以及

加速播放模块1503，用于当缓存区的音视频数据达到第一阈值，对缓存区中未播放的音视频数据中的音频数据进行加速播放；以及播放所述被加速播放的音频数据所对应的视频数据。

另外，本发明实施例的直播装置还包括：

获取单元，用于从所述缓存区的视频缓存区中获取视频数据，从所述缓存区的音频缓存区中获取音频数据；

解码单元，用于对所述视频数据和所述音频数据进行解码渲染，得到视频帧和音频帧；

音频帧存放单元，用于按照各个所述音频帧所对应的显示时间戳的顺序将各个所述音频帧存入音频帧队列；以及

视频帧存放单元，用于按照各个所述视频帧所对应的显示时间戳的顺序将各个所述视频帧存入视频帧队列。

本发明实施例中对所述缓存区中未播放的音视频数据中的音频数据进行加速播放的速度小于或等于正常播放速度的1.185倍。

再有，本发明实施例的加速播放模块1503包括视频帧播放单元；

视频帧播放单元，用于将排列在当前正在加速播放的音频帧所对应的视频帧之前的视频帧丢弃，从当前正在加速播放的音频帧所对应的视频帧开始，顺序播放视频帧队列中的视频帧；或者，

用于跳过排列在当前正在加速播放的音频帧所对应的视频帧之前的视频帧，从当前正在加速播放的音频帧所对应的视频帧开始，顺序播放视频帧队列中的视频帧。

综上所述，本发明实施例中提供的直播装置，能够在播放端发生卡顿时，通过对缓存区中的音频数据进行加速播放，在保证直播内容的完整性的同时，缩小播放端播放内容与实时直播内容之间的时间差，自动实现播放端播放内容与实时直播内容同步；另外，本发明能够根据当前正在加速播放的音频数据来播放对应的视频数据，使音频和视频保持同步播放，提升用户的观看体验。

参见图1的网络架构，本发明实施例还提供了一种直播***，包括推流端、服务器和播放端；推流端向所述服务器发送音视频数据，服务器向所述播放端发送所述音视频数据；播放端包括获取模块、缓存模块和加速播放模块；其中，

获取模块，用于获取直播内容的音视频数据并进行播放；

本发明实施例还提供了一种设备，该设备包括处理器以及存储器；

存储器，用于存储程序；

处理器，用于执行所述程序以执行播放端设备或推流端设备的方法。本发明实施例的设备可以实现播放端的功能，也可以实现推流端的功能。该设备还可以是终端设备，该终端设备可以为包括手机、平板电脑、个人数字助理(Personal Digital Assistant，简称PDA)、销售终端(Point of Sales，简称POS)、车载电脑等任意智能终端，下面结合附图对该设备进行介绍，参见图16，本发明实施例以终端设备为手机为例：

图16示出的是与本申请实施例提供的终端设备相关的手机的部分结构的框图。参考图16，手机包括：射频(Radio Frequency，简称RF)电路1610、存储器1620、输入单元1630、显示单元1640、传感器1650、音频电路1660、无线保真(wireless fidelity，简称WiFi)模块1670、处理器1680、以及电源1690等部件。本领域技术人员可以理解，图16中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

在本发明实施例中，该终端设备所包括的处理器1680具有以下功能：

获取直播内容的音视频数据并进行播放；

当播放出现卡顿，将未播放的音视频数据缓存至缓存区；

播放所述被加速播放的音频数据所对应的视频数据。

该终端设备所包括的处理器1680还具有以下功能：

向播放端发送音视频数据，以使所述播放端执行图3所述的方法对所述音视频数据进行播放。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有程序，所述程序被处理器执行完成如前述各个实施例所述的直播方法。

本申请实施例还提供一种包括指令的计算机程序产品，当其在计算机上运行时，使得计算机执行前述各个实施例所述的直播方法。

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

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

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

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

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

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

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

Claims

1.一种直播方法，其特征在于，包括：

获取直播内容的音视频数据并进行播放；

当播放出现卡顿，将未播放的音视频数据缓存至缓存区；

播放所述被加速播放的音频数据所对应的视频数据。

2.根据权利要求1所述的方法，其特征在于，所述缓存区包括用于存储所述音频数据的音频缓存区和用于存储所述视频数据的视频缓存区；

所述当所述缓存区的音视频数据达到第一阈值，对所述缓存区中未播放的音视频数据中的音频数据进行加速播放，包括：

从所述音频缓存区中获取音频数据；从所述视频缓存区中获取视频数据；

对所述音频数据和所述视频数据进行解码及渲染，得到音频帧和视频帧；

按照所述音频帧所对应的显示时间戳的顺序将所述音频帧存入音频帧队列；

按照所述视频帧所对应的显示时间戳的顺序将所述视频帧存入视频帧队列；以及

加速播放所述音频帧队列中的音频帧。

3.根据权利要求2所述的方法，其特征在于，所述播放所述被加速播放的音频数据所对应的视频数据，包括：

将排列在当前正在加速播放的音频帧所对应的视频帧之前的视频帧丢弃，从当前正在加速播放的音频帧所对应的视频帧开始，顺序播放视频帧队列中的视频帧；

或者，

跳过排列在当前正在加速播放的音频帧所对应的视频帧之前的视频帧，从当前正在加速播放的音频帧所对应的视频帧开始，顺序播放视频帧队列中的视频帧。

4.根据权利要求2所述的方法，其特征在于，还包括确定所述视频缓存区大小和所述音频缓存区大小的步骤，该步骤包括：

获取第一数据；

从所述第一数据中获取不同帧数大小的缓存区对应的播放质量参数的值，所述播放质量参数包括以下一种或多种：首次缓冲时长、二次缓冲时长、无缓冲率、平均每播放一小时出现的二次缓冲次数、平均每播放一小时出现的错误次数以及清晰度；

确定所述各个播放质量参数对应的权重；

根据所述播放质量参数的值和所述权重，计算各个帧数大小对应的播放质量总分；以及

将总分最高对应的帧数大小确定为所述视频缓存区大小和音频缓存区大小。

5.根据权利要求2所述的方法，其特征在于，还包括确定所述视频帧队列大小和音频帧队列大小的步骤，该步骤包括：

获取第二数据；

从所述第二数据中获取不同帧数大小对应的帧队列的播放质量参数的值，所述播放质量参数包括以下一种或多种：首次缓冲时长、二次缓冲时长、无缓冲率、平均每播放一小时出现的二次缓冲次数、平均每播放一小时出现的错误次数以及清晰度；

确定所述各个播放质量参数对应的权重；

根据各个帧数大小对应的播放质量总分，确定所述音频帧队列大小和所述视频帧队列大小。

6.根据权利要求1所述的方法，其特征在于，还包括确定所述第一阈值的步骤，该步骤包括：

获取第三数据；

从所述第三数据中获取不同缓存量对应的播放质量参数的值，所述播放质量参数包括以下一种或多种：首次缓冲时长、二次缓冲时长、无缓冲率、平均每播放一小时出现的二次缓冲次数、平均每播放一小时出现的错误次数以及清晰度；

确定所述各个播放质量参数对应的权重；

根据所述播放质量参数的值和所述权重，计算各个缓存量对应的播放质量总分；以及

将总分最高对应的缓存量确定为所述第一阈值。

7.根据权利要求4-6任一项所述的方法，其特征在于，还包括所述清晰度的值的确定步骤，该步骤包括：

获取蓝光播放时长占比、超清播放时长占比和流畅播放时长占比；

确定所述蓝光播放时长占比的权重、超清播放时长占比的权重和流畅播放时长占比的权重；以及

根据所述蓝光播放时长占比、超清播放时长占比、流畅播放时长占比、所述蓝光播放时长占比的权重、超清播放时长占比的权重和流畅播放时长占比的权重，确定所述清晰度的值。

8.根据权利要求1所述的方法，其特征在于，还包括：

当所述缓存区的音视频数据达到第二阈值，按照正常播放速度对所述缓存区中的未播放的音视频数据中的音频数据进行播放；以及

将所述按照正常播放速度播放的音频数据所对应的视频数据进行播放；

其中，所述第二阈值小于所述第一阈值。

9.一种直播方法，其特征在于，包括：

向播放端发送音视频数据，以使所述播放端执行权利要求1-8中任一项所述的方法对所述音视频数据进行播放。

10.一种直播装置，其特征在于，包括：

获取模块，用于获取直播内容的音视频数据并进行播放；

缓存模块，用于当播放出现卡顿，将未播放的音视频数据缓存至缓存区；以及

11.一种直播***，其特征在于，包括：推流端、服务器和播放端；所述推流端向所述服务器发送音视频数据，所述服务器向所述播放端发送所述音视频数据；所述播放端包括获取模块、缓存模块和加速播放模块；其中，

12.一种设备，其特征在于，所述设备包括处理器以及存储器；

所述存储器，用于存储程序；

所述处理器，用于执行所述程序以执行如权利要求1-9任一项所述的方法。

13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有程序，所述程序被处理器执行完成如权利要求1-9中任一项所述的方法。