CN112291498B

CN112291498B - 音视频数据传输的方法、装置和存储介质

Info

Publication number: CN112291498B
Application number: CN202011190303.6A
Authority: CN
Inventors: 李尚进
Original assignee: New Oriental Education Technology Group Co ltd
Current assignee: New Oriental Education Technology Group Co ltd
Priority date: 2020-10-30
Filing date: 2020-10-30
Publication date: 2022-11-04
Anticipated expiration: 2040-10-30
Also published as: CN112291498A

Abstract

本申请实施例提供了一种音视频数据传输的方法、装置和存储介质，在直播场景中即能够满足互动效果，同时节省了带宽资源。该方法包括：在用户处于互动模式时，接收从RTC系统发送的所述直播场景中的音视频数据，并对所述音视频数据和所述直播场景中的信令消息进行实时处理；在所述用户处于观看模式时，接收从CDN系统发送的所述音视频数据，并对所述音视频数据和所述信令消息进行同步处理。

Description

音视频数据传输的方法、装置和存储介质

技术领域

本申请实施例涉及信息技术领域，并且更具体地，涉及一种音视频数据传输的方法、装置和存储介质。

背景技术

目前，随着信息技术的发展，学生的教学形式包括在线的直播课、录播课以及传统的面授课等多种形式，其中，直播课在时间和空间上具有更大的自由性，只要有网络的覆盖，学生就可以随时通过手机、电脑等工具在线听课，并且可以通过音视频系统与老师进行互动。音视频系统需要保证互动师生之间的音视频数据的实时性，从而提高互动效果，但是所需要的带宽资源很大，尤其是在大班课业务学生数量较多的场景中，音视频系统的压力明显增加。因此，如何在满足互动效果的同时节省带宽资源，成为一个亟待解决的技术问题。

申请内容

本申请实施例提供一种音视频数据传输的方法、装置和存储介质，在直播场景中既能够满足互动效果，同时节省了带宽资源。

第一方面，提供了一种音视频数据传输的方法，应用于在线直播场景中，所述方法包括：在用户处于互动模式时，接收从实时通信(Real Time Communication，RTC)系统发送的所述直播场景中的音视频数据，并对从所述RTC系统接收的音视频数据和所述直播场景中的信令消息进行实时处理；在所述用户处于观看模式时，接收从内容分发网络(ContentDelivery Network，CDN)系统发送的所述音视频数据，并对从所述CDN系统接收的音视频数据和所述信令消息进行同步处理。

在一些可能的实现方式中，在对所述音视频数据和所述信令消息进行同步处理之前，所述方法还包括：接收从即时通信(Instant messaging，IM)系统发送的所述信令消息。

在一些可能的实现方式中，所述IM系统为可扩展视频编码(Scalable VideoCoding，SVC)系统。

在一些可能的实现方式中，所述对所述音视频数据和所述信令消息进行同步处理，包括：对所述信令消息进行缓存，并从所述信令消息中获取所述信令消息的网络时间协议(Network Time Protocol，NTP)时间戳；获取所述音视频数据中各个视频帧的NTP时间戳；对NTP时间戳相同的视频帧和信令消息进行同步处理

在一些可能的实现方式中，所述获取所述音视频数据的NTP时间戳，包括：根据所述关键帧的NTP时间戳，以及所述关键帧的显示时间戳，确定所述音视频数据中的各个视频帧的NTP时间戳。

其中，所述关键帧的NTP时间戳位于所述音视频数据的关键帧中的例如补充增强信息(Supplemental Enhancement Information，SEI)字段。

在一些可能的实现方式中，所述根据所述关键帧的NTP时间戳，以及所述关键帧的显示时间戳，确定所述音视频数据中的各个视频帧的NTP时间戳，包括：确定所述关键帧的NTP时间戳与所述关键帧的显示时间戳之间的时间差；根据所述时间差以及所述音视频数据中的各个视频帧的显示时间戳，确定各个视频帧对应的NTP时间戳。

在一些可能的实现方式中，所述方法还包括：当处于互动模式的用户从互动模式切换至观看模式时，同时从所述RTC系统和所述CDN系统接收音视频数据；对所述RTC系统的音视频数据和所述信令消息，进行慢速处理，直至所述CDN系统的音视频数据与所述RTC系统的音视频数据同步时，停止从所述RTC系统接收音视频数据。

在一些可能的实现方式中，所述对所述RTC系统的音视频数据和所述信令消息，进行慢速处理，包括：根据所述RTC系统的音视频数据中的视频帧的参考等级，确定慢速处理的倍数M1，并根据M1对所述视频帧进行慢速处理，其中，M1≤1，所述视频帧的参考等级越高，M1越小。

在一些可能的实现方式中，所述视频帧的参考等级与所述视频帧的类型相关，其中，以下类型的所述视频帧的参考等级依次增加：I帧、仅被P帧和B帧参考的P帧、仅被P帧参考的P帧、仅被B帧参考的P帧、以及B帧。

在一些可能的实现方式中，所述根据所述RTC系统的音视频数据中的视频帧的参考等级，确定慢速处理的倍数M1，包括：根据M1＝K1/A1，确定慢速处理的倍数M1，其中，A1表示所述视频帧的参考等级，K1为预设参数，所述预设参数是基于当前的网络状态确定的，其中，当前的RTC系统的网络状态与CDN系统的网络状态之间的差异越大，则K1值越小。

在一些可能的实现方式中，所述对所述RTC系统的音视频数据和所述信令消息，进行慢速处理，包括：根据所述RTC系统的音视频数据中的视频帧的参考等级，对与所述视频帧匹配的音频数据进行慢速处理。

在一些可能的实现方式中，所述对所述RTC系统的音视频数据和所述信令消息，进行慢速处理，包括：根据所述信令消息的重要等级，确定慢速处理的倍数N1，并根据N1对所述信令消息进行慢速处理，其中，N1≤1，所述信令消息的重要等级越高，N1越大。

在一些可能的实现方式中，针对特定用户发送的信令消息的重要等级，高于针对多个用户广播的信令消息的重要等级。

在一些可能的实现方式中，所述根据所述信令消息的重要等级，确定对所述信令消息进行慢速处理的倍数N1，包括：根据所述信令消息的重要等级，以及与所述信令消息匹配的音频数据的重要程度，确定对所述信令消息进行慢速处理的倍数N1。

在一些可能的实现方式中，所述根据所述信令消息的重要等级，确定慢速处理的倍数N1，包括：根据N1＝K2/A2，确定慢速处理的倍数M1，其中，A2表示所述信令消息的重要等级，K2为预设参数，所述预设参数是基于当前的网络状态确定的，其中，当前的RTC系统的网络状态与CDN系统的网络状态之间的差异越大，则K2值越小。

在一些可能的实现方式中，所述CDN系统的音视频数据与所述RTC系统的音视频数据同步，包括：所述CDN系统的音视频数据的NTP时间戳与所述RTC系统的音视频数据的NTP时间戳相同。

在一些可能的实现方式中，所述方法还包括：当处于观看模式的用户从观看模式切换至互动模式时，获取所述CDN系统与所述RTC系统的时间差范围内的来自所述RTC系统的音视频数据和所述信令消息；对所述时间差范围内的音视频数据和所述信令消息，以及切换后的一段时间内从所述RTC系统接收的音视频数据和所述信令消息，进行快速处理，直至处理完时，恢复对所述RTC系统的音视频数据和所述信令消息的实时处理。

在一些可能的实现方式中，所述对所述时间差范围内的音视频数据和所述信令消息，以及切换后的一段时间内从所述RTC系统接收的音视频数据和所述信令消息，进行快速处理，包括：根据所述RTC系统的音视频数据中的视频帧的参考等级，确定快速处理的倍数M2，并根据M2对所述视频帧进行快速处理，其中，M2≥1，所述视频帧的参考等级越高，M2越大；或者，根据所述RTC系统的音视频数据中的视频帧的参考等级，对所述视频帧进行丢弃。

在一些可能的实现方式中，所述根据所述RTC系统的音视频数据中的视频帧的参考等级，确定快速处理的倍数M2，包括：根据M2＝K3/A1，确定快速处理的倍数M2，其中，A1表示所述视频帧的参考等级，K3为预设参数，所述预设参数是基于当前的网络状态确定的，其中，当前的RTC系统的网络状态与CDN系统的网络状态之间的差异越大，则K3值越大。

在一些可能的实现方式中，所述对所述时间差范围内的音视频数据和所述信令消息，以及切换后的一段时间内从所述RTC系统接收的音视频数据和所述信令消息，进行快速处理，包括：根据所述RTC系统的音视频数据中的视频帧的参考等级，对与所述视频帧匹配的音频数据进行快速处理或者丢弃。

在一些可能的实现方式中，所述对所述时间差范围内的音视频数据和所述信令消息，以及切换后的一段时间内从所述RTC系统接收的音视频数据和所述信令消息，进行快速处理，包括：根据所述信令消息的重要等级，对所述信令消息进行快速处理，其中，对所述信令消息进行快速处理包括执行以下操作中的至少一种：确定快速处理的倍数N2，并根据N2对所述信令消息进行快速处理，其中，N2≥1，所述信令消息的重要等级越低，N2越大；对所述信令消息进行合并处理；对所述信令消息进行丢弃。

在一些可能的实现方式中，所述根据所述信令消息的重要等级，对所述信令消息进行快速处理，包括：根据所述信令消息的重要等级，以及与所述信令消息匹配的音频数据的重要程度，对所述信令消息进行快速处理。

在一些可能的实现方式中，应用于在线直播场景中，所述方法包括：通过实时通信RTC系统向处于互动模式的用户发送音视频数据；将所述音视频数据推送至内容分发网络CDN系统，并通过所述CDN系统向处于观看模式的用户发送所述音视频数据。

在一些可能的实现方式中，所述音视频数据的关键帧的补充增强信息SEI字段中携带所述关键帧的NTP时间戳，所述音视频数据的NTP时间戳用于对所述音视频数据和所述信令消息进行同步处理。

在一些可能的实现方式中，所述确定快速处理的倍数N2，包括：根据N2＝K4/A2，确定快速处理的倍数N2，其中，A2表示所述信令消息的重要等级，K4为预设参数，所述预设参数是基于当前的网络状态确定的，其中，当前的RTC系统的网络状态与CDN系统的网络状态之间的差异越大，则K4值越大。

第二方面，提供了一种音视频数据传输的方法，应用于在线直播场景中，所述方法包括：通过RTC系统向处于互动模式的用户发送音视频数据；将所述音视频数据推送至CDN系统，并通过所述CDN系统向处于观看模式的用户发送所述音视频数据。

在一些可能的实现方式中，所述音视频数据的关键帧的补充增强信息SEI字段中携带所述关键帧的NTP时间戳。

第三方面，提供了一种音视频数据传输的装置，包括执行上述第一方面或其任意可能的实现方式中的方法的模块。

第四方面，提供了一种音视频数据传输的装置，包括执行上述第二方面或其任意可能的实现方式中的方法的模块。

第五方面，提供了一种音视频数据传输的装置，包括处理器和存储器。所述存储器用于存储计算机可执行指令，所述处理器用于访问所述存储器，并执行所述计算机可执行指令，以进行上述第一方面或其任意可能的实现方式中的方法中的操作。

第六方面，提供了一种音视频数据传输的装置，包括处理器和存储器。所述存储器用于存储计算机可执行指令，所述处理器用于访问所述存储器，并执行所述计算机可执行指令，以进行上述第二方面或其任意可能的实现方式中的方法中的操作。

第七方面，提供了一种计算机存储介质，该计算机存储介质中存储有程序代码，该程序代码可以用于指示执行上述第一方面或其任意可能的实现方式中的方法。

第八方面，提供了一种计算机存储介质，该计算机存储介质中存储有程序代码，该程序代码可以用于指示执行上述第二方面或其任意可能的实现方式中的方法。

第九方面，提供了一种包含指令的计算机程序产品，其在计算机上运行时，使得计算机执行上述第一方面或其任意可能的实现方式中的方法。

第十方面，提供了一种包含指令的计算机程序产品，其在计算机上运行时，使得计算机执行上述第二方面或其任意可能的实现方式中的方法。

基于上述技术方案，在直播场景中，对于互动模式的用户，通过RTC系统向其发送音视频数据，从而保证音视频数据的实时性，提高互动效果；而对于观看模式的用户，则将音视频数据从RTC系统推送至CDN系统，从而通过CDN系统向用户发送音视频数据，从而节省带宽开销。可见，针对用户的不同状态采用不同的系统进行音视频数据的传输，即保证了互动用户的互动效果，又节省了带宽资源，降低了成本。另外，考虑到用户还会接收到的该直播场景中的信令消息，而该信令消息与RTC系统中的音视频数据都是基于实时性传输的，因此用户在接收到该信令消息和RTC系统发送的音视频数据后，可以对该信令消息与该音视频数据进行实时处理；而CDN系统中的音视频数据具有一定的延迟，因此需要对CDN系统发送的音视频数据与该信令消息之间进行同步处理，以保证音视频数据和信令消息的同步，提高用户体验。

附图说明

图1是应用本申请实施例的技术方案的架构图。

图2是本申请实施例的音视频数据传输的方法的示意性流程图。

图3是本申请实施例的音视频系统的示意图。

图4是基于图2所示的方法的一种可能的实现方式的示意图。

图5是基于图2所示的方法的一种可能的实现方式的示意图。

图6是本申请一个实施例的音视频数据传输的装置的示意性框图。

图7是本申请另一个实施例的音视频数据传输的装置的示意性框图。

图8是本申请另一个实施例的音视频数据传输的装置的示意性框图。

具体实施方式

下面将结合附图，对本申请实施例中的技术方案进行描述。

应理解，本说明书中的具体的例子只是为了帮助本领域技术人员更好地理解本申请实施例，而非限制本申请实施例的范围。

还应理解，在本申请的各种实施例中，各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

还应理解，本说明书中描述的各种实施方式，既可以单独实施，也可以组合实施，本申请实施例对此并不限定。

除非另有说明，本申请实施例所使用的所有技术和科学术语与本申请的技术领域的技术人员通常理解的含义相同。本申请中所使用的术语只是为了描述具体的实施例的目的，不是旨在限制本申请的范围。

本申请实施例的技术方案可以应用在直播场景，例如在线教育等场景中。以下，均以在线教育场景为例进行描述，但并不限于此。

图1示出了应用本申请实施例的音视频数据传输的方法的一个场景的示意图。如图1所示，音视频传输的装置110可以通过服务器120与其他设备之间进行音视频数据和信令消息的交互。

装置110可以是具有数据处理能力的电子设备或系统，例如计算机、手机、平板电脑等。

装置110包括处理器，用于实现音视频数据的处理，例如，采用本申请实施例的技术方案对音视频数据进行处理。处理器可以为任意种类的处理器，本申请实施例对此不做限定。

装置110还可以包括存储器。该存储器可用于存储数据和指令，例如，实现本申请实施例的技术方案的计算机可执行指令。该存储器可以为任意种类的存储器，本申请实施例对此也不做限定。

装置110和装置120还可以包括通信接口，通过通信接口与服务器120通信连接，该通信连接可以是有线方式，也可以是无线方式。

装置110还可以包括显示设备，用于显示处理结果，例如在线教育场景中的教学素材等。

图2示出了本申请实施例的音视频数据传输的方法200的示意性流程图。该方法200例如可以由发送端和接收端执行。应理解，接收端例如可以包括图1中所示的装置110，发送端例如可以包括图1中所示的服务器120。

方法200应用于直播场景中，如图2所示，方法200包括以下步骤中的部分或全部。

在210中，发送端通过RTC系统向处于互动模式的用户发送音视频数据。

在220中，在用户处于互动模式时，接收端接收从RTC系统发送的该直播场景中的音视频数据，并对从RTC系统接收的该音视频数据和该直播场景中的信令消息进行实时处理。

在230中，发送端将该音视频数据推送至CDN系统，并通过CDN系统向处于观看模式的用户发送该音视频数据。

在240中，在该用户处于观看模式时，接收端接收从CDN系统发送的所述音视频数据，并对从CDN系统接收的该音视频数据和该信令消息进行同步处理。

在教育行业中，教育相关的素材种类较多，主要可以包括以下两类：媒体相关的音视频数据，例如屏幕分享、电影播放、音乐播放等；以及信令相关的数据，例如白板、聊天、PDF等。由于这两类素材在传输时的耗时、可靠性、流量大小等方面存在较大差异，所以本申请实施例中通过不同的系统分别传输直播间中的音视频数据和信令消息。

其中，信令消息在传输过程中产生的流量较小，对传输可靠性的要求较高，可以采用IM系统进行传输。在IM系统中，可以通过可靠性传输协议例如传输控制协议(Transmission Control Protocol，TCP)协议传输信令消息。一条信令消息在发送端和接收端之间传输的时间很短，通常在毫秒(ms)级别，并且可以保证其可达性。

音视频数据产生的流量较大，音视频编解码算法可以保证一定的抗丢包性，例如视频30％的抗丢包率，音频50％的抗丢包率。音视频数据可以通过RTC系统或者CDN系统进行传输。其中，RTC系统可以保证音视频数据的实时性，提高互动效果，但是需要较大的带宽。在线教育中，假设每个人的视频码率是1Mbps。如果有10个人同时参与互动，90个人观看，那么会造成90*10+10*9＝990路音视频下行流，会产生990*1Mbps＝990Mbps的下行带宽。用户量越大，所需的带宽资源越多，成本越高。相比于RTC系统，CDN系统中的音视频数据存在一定延迟，例如3s-5s左右，因此不适宜于互动场景，但是其带宽成本很低。

在线教育中，特别是大班课的场景中，同一时刻需要进行实施互动的学生数量是有限的，大多数学生还是以观看为主。如果所有学生都在RTC系统中，则会造成很大的带宽浪费。

因此，本申请实施例中，在直播场景中，对于互动模式的用户，发送端通过RTC系统发送音视频数据，处于互动模式的用户从RTC系统中获取音视频数据，从而保证音视频数据的实时性，提高互动效果；而对于观看模式的用户，发送端将音视频数据从RTC系统推送至CDN系统，处于观看模式的用户从CDN系统中获取音视频数据，从而节省带宽开销。可见，针对用户的不同状态采用不同的系统进行音视频数据的传输，即保证了互动用户的互动效果，又节省了带宽资源，降低了成本。

另外，考虑到用户还会接收到的该直播场景中的信令消息，传输信令消息的系统与传输音视频数据的系统是彼此独立的。而该信令消息与RTC系统中的音视频数据基本是实时传输的，因此用户在接收到该信令消息和RTC系统发送的音视频数据后，可以对信令消息与音视频数据进行实时处理；而CDN系统中的音视频数据具有一定的延迟，因此需要对该信令消息与CDN系统发送的音视频数据之间进行同步处理，以保证不同素材的同步显示，从而提高用户体验。

图3所示为本申请实施例的音视频通信系统的示意图。以图3为例，本申请实施例的直播场景中应用了三种不同的系统，分别为RTC系统、CDN系统和IM系统。IM系统用于信令消息的传输，直播中所有参与者的信令消息通过IM系统进行交互，例如，老师与学生1之间的信令消息、学生1和学生2之间的信令消息、以及学生1与学生2之间的信令消息。其中，老师和学生1处于互动模式，学生2处于观看模式。

RTC系统和CDN系统用于音视频数据的交互。其中，处于互动模式的老师和学生1位于RTC系统中，老师与学生1之间音视频数据通过RTC系统进行交互。处于观看模式的学生2位于CDN系统中，学生2通过CDN系统获取学生1和老师之间的音视频数据。

这三个系统是独立的，各自的时间是不同步的，因此，接收端如何对接收到的音视频数据和信令消息进行同步，是本申请需要解决的另一个技术问题。

在某个时刻，一个用户只能通过RTC系统和CDN系统中的一个系统来获取音视频数据，因此不存在RTC系统和CDN系统中的数据同步问题。

处于RTC系统中的用户只需要处理RTC系统中的音视频数据和信令消息的同步。由于RTC系统中的音视频数据和信令消息都是基于实时性传输，基本上可以对接收到的音视频数据和信令消息进行实时处理。

处于CDN系统中的用户只需要处理CDN系统中的音视频数据和信令消息的同步。信令消息是基于实时性传输，而用户从CDN系统中接收的音视频数据是具有延迟的，因此用户从CDN系统中接收的音视频数据和信令消息之间存在时间差，这时就需要对音视频数据和信令消息之间进行同步处理。

本申请实施例提供了一种音视频数据同步的方法，可以实现音视频数据和信令消息之间的同步处理。在该方案中，可选地，步骤240可以包括步骤241至243。

在241中，接收端接收到信令消息后，对该信令消息进行缓存，并从该信令消息中获取该信令消息的NTP时间戳。

在242中，接收端通过CDN系统接收到音视频数据后，获取该音视频数据的NTP时间戳。

在243中，根据该音视频数据的NTP时间戳和该信令消息的NTP时间戳，对该音视频数据和该信令消息进行同步处理。

信令消息例如可以通过IM系统进行传输。IM系统例如可以是SVC系统。因此可以将信令消息也称为IM信令或SVC信令。

信令消息中携带该信令消息的NTP时间戳。发送端的信令消息可以通过Json或者protobuf格式组装之后发送到IM系统中进行转发。每个信令消息中携带时间戳(timestamp)字段，并将该字段设置为信令消息组装时的NTP时间戳。这样，接收端就可以根据信令消息中的NTP时间戳进行同步处理。

例如，老师发送一段文字时，在老师的客户端上组装的信令消息的格式可以为：

其中，timestamp即为NTP时间戳，这里，可以将NTP时间戳认为是基准时间戳，用来保证各个用户的客户端设置的时间戳基准一致。学生的客户端接收到MessageUserText消息时，解析出其中的timestamp，就可以根据该信令消息的NTP时间戳与其他素材之间做同步。

互动模式的用户的音视频数据通过RTC系统进行传输。本申请实施例对RTC系统的类型不做限定，例如，该RTC系统可以采用开源项目webrtc，其中使用内容加密的实时传输协议(Real-Time Transport Protocol，RTP)格式对音视频数据进行传输；该RTC系统也可以使用protobuf格式对音视频数据进行传输，protobuf格式内部的数据也是RTP格式。

RTC系统中的每个直播间中的所有音视频流都会推送一路到CDN系统中，以供处于观看模式的用户拉取查看。本申请实施例对CDN系统的类型也不做限定，例如，CDN系统中的音视频数据可以采用实时信息协议(Real Time Message Protocol，RTMP)进行传输。这时，也可以将CDN系统称为RTMP系统。可以采用例如开源播放器ffplay等拉取RTMP数据流，不断地读取音视频数据。RTMP格式的音视频数据中携带各自的显示时间戳(Presentation TimeStamp，PTS)，该显示时间戳指示不同视频帧之间的显示顺序，该显示时间戳是相对时间戳。视频帧中的显示时间戳可以保证一个视频帧组中各个视频帧的同步，并不能保证该视频帧组中的视频帧与其他系统消息之间的同步。

在本申请一个实施例中，音视频数据的关键帧中携带该关键帧对应的NTP时间戳。例如，在该关键帧中的SEI字段中携带该关键帧对应的NTP时间戳。也就是说，可以将每个关键帧中加入SEI信息，以用于记录当前视频编码时对应的信令消息的NTP时间戳(记为base_ts)。

RTMP中的视频数据是H.264编码格式，H.264编码格式中包括SEI字段，该SEI字段可以自定义。该实施例中，利用视频帧中的关键帧(I帧)中的SEI字段来实现音视频数据和信令消息之间的同步。SEI是伴随着关键帧出现的。因此，发送端将所有参与互动的学生的音视频数据合流后推送至CDN系统时，可以将每个关键帧中的SEI字段设置成该关键帧对应的NTP时间戳(即base_ts)，例如该SEI字段格式为{base_ts：ntp_time}。

该关键帧的NTP时间戳为基准时间，或者说是绝对时间，而该关键帧的显示时间戳为相对时间。这时，在242中，接收端可以根据该关键帧的NTP时间戳，以及该关键帧的显示时间戳，确定音视频数据中各个视频帧对应的NTP时间戳。

例如，接收端可以计算该关键帧的NTP时间戳与该关键帧的显示时间戳之间的时间差，并根据该时间差以及音视频数据中的各个视频帧的显示时间戳确定各个视频帧对应的NTP时间戳。

也就是说，利用关键帧中携带的NTP时间戳与该关键帧的显示时间戳之间的时间差，将其他视频帧的显示时间戳转换为对应的NTP时间戳。这样，接收端就可以对具有相同NTP时间戳的视频帧和信令消息进行同步处理。

接收端接收到信令消息后，确定用户处于互动模式还是观看模式。如果用户处于互动模式，则接收端可以对该信令消息进行实时处理。如果用户处于观看模式，音视频数据是从CDN系统中过来的，会存在延迟，所以接收端需要对信令消息进行缓存。接收端根据信令消息中的NTP时间戳对其进行缓存，并等待对应相同NTP时间戳的音视频数据到达，从而进行同步处理。

在具体实现时，接收端通过CDN系统获取音视频数据后，解码显示音视频数据时，回调出视频帧对应的显示时间戳，并计算各个视频帧对应的NTP时间戳，并且根据视频帧对应的NTP时间戳，执行该NTP时间戳对应的信令消息，达到二者同步。

应理解，由于信令消息中也携带NTP时间戳，因此每个视频帧对应的NTP时间戳，也可以认为是，需要与该视频帧之间保持同步的信令消息的执行时间戳。

例如表一所示，处于观看模式的用户通过CDN系统获取音视频数据，并从IM系统中获取信令消息。在表一中，第一行为视频帧的编号，其中“I”表示关键帧，每隔一定时间出现一个关键帧；第二行为关键帧的SEI字段携带的NTP时间戳(base_ts)；第三行为各个视频帧的显示时间戳(PTS)，是一个相对时间戳，即相对于视频开始的时间；第四行为时间差(记为diff_time)，其中diff_time＝base_ts-PTS；第五行为各个视频帧对应的NTP时间戳，即各个视频帧对应的信令消息的执行时间戳(记为im_time)，其中，im_time＝PTS+diff_time。

表一

从表一中可以看出，关键帧I1对应的base_ts和PTS分别为10000和0，diff_time＝10000，因此，视频帧F2的im_time＝10000+67＝10067，视频帧F3对应的im_time＝10000+134＝10134，视频帧F4对应的im_time＝10000+201＝10201，……，视频帧F30对应的im_time＝10000+1933＝11933。

接收端接收到关键帧I31时，接收端更新diff_time。关键帧I31对应的base_ts和PTS分别为12011和2000，diff_time＝10011，因此，视频帧F32对应的im_time＝10011+2067＝12078。

接收端可以根据表一中的im_time，对缓存的信令消息进行处理，使信令消息与音视频数据保持一致。如表一所示，在接收端缓存的信令消息中，NTP时间戳为10000的信令消息与视频帧I1同步呈现给用户，NTP时间戳为10067的信令消息与视频帧F2同步呈现给用户，NTP时间戳为10134的信令消息与视频帧F3，NTP时间戳为10201的信令消息与视频帧F4同步呈现给用户，……，NTP时间戳为11933的信令消息与视频帧F30同步呈现给用户，NTP时间戳为12011的信令消息与视频帧I31同步呈现给用户，NTP时间戳为12078的信令消息与视频帧F32同步呈现给用户。这样，就实现了CDN系统的音视频数据和IM系统的信令消息之间的同步。

可见，通过在音视频数据的关键帧中携带关键帧的NTP时间戳，并根据该NTP时间戳实现音视频数据和信令消息之间的同步，解决了音视频数据和信令消息之间的同步问题。

而利用关键帧中的SEI字段携带该关键帧的NTP时间戳，可以在不改变现有编码格式的基础上，实现音视频数据和信令消息之间的同步。

接收端每次检测到关键帧中携带的NTP时间戳时，可以对上一次计算的diff_time进行更新，并使用更新后的diff_time确定后续的各个视频帧对应的NTP时间戳，从而执行与各个视频帧的NTP时间戳相对应的信令消息。

发送端可以在每个关键帧中都添加NTP时间戳。这样，接收端每次接收到关键帧时都更新diff_time，可以确保diff_time的准确性，提高音视频数据和信令消息的同步效果。

发送端也可以按照一定规律在部分关键帧中增加NTP时间戳，例如每n个关键帧添加一次NTP时间戳。这样，接收端每接收n个关键帧时更新一次diff_time，减轻了接收端的计算量，降低了接收端的实现复杂度。

下面以图4为例，详细描述本申请实施例的音视频数据传输的方法的一种可能的实现方式。如图4所示，该方法可以由接收端执行。此时，用户可能处于互动模式或者观看模式。

在401中，接收端确定用户是否处于互动模式。

若用户处于互动模式，则执行402至406；若用户处于非互动模式，即观看模式，则执行407至418。

在402中，接收端确定用户处于互动模式。

在403中，接收端接收数据，并确定其是否为信令消息。

若该数据为信令消息，则执行404；若该数据不是信令消息，则执行405。

在404中，接收端对该信令消息进行实时处理。

在405中，判断该数据是否为音视频数据。

若该数据为音视频数据，则执行406。

在406中，接收端对该音视频数据进行实时处理。

在407中，接收端确定用户处于观看模式。

在408中，接收端接收数据，并确定其是否为信令消息。

若该数据为信令消息，则执行409；若该数据不是信令消息，则执行410。

在409中，接收端对该信令消息进行缓存。

在410中，接收端判断该数据是否为音视频数据。

若该数据为音视频数据，则执行411至418。

在411中，接收端不断地读取音视频数据。

在412中，接收端检测音视频数据中是否有SEI字段。

其中，SEI字段中会携带关键帧对应的base_ts。

若检测到有SEI字段，执行413；若没有检测到SEI字段，则执行414。

在413中，更新diff_time。

其中，diff_time等于关键帧的base_ts与关键帧的PTS之差。

在414中，接收端确定该音视频数据是否为音频数据。

若该音视频数据为音频数据，则执行415；若该音视频数据不是音频数据，则说明为视频数据，那么执行416。

在415中，接收端对该音频数据进行处理，例如解码、播放等处理。

在416中，接收端从视频数据的各个视频帧中获取对应的PTS。

在417中，接收端根据对应的PTS对该视频数据进行处理，例如解码、渲染、显示等处理。

在418中，接收端根据在413中更新的diff_time，以及在416中获取的各个视频帧的PTS，确定各个视频帧对应的im_time。

在419中，接收端根据在418中获取的im_time，对信令消息进行处理，例如解码、显示等处理。

应理解，图4仅仅为示例，图4中所示的一些步骤可以做适当的顺序调整和合并。

从图4的流程中可以看出，音视频数据包括音频数据和视频数据。如果是音频数据，则直接解码播放；如果是视频数据，在解码、渲染以及播放的同时，将该视频帧的PTS转换成对应的im_time，并使用im_time去缓存中执行该im_time之前的信令消息。这里可以将音频数据和视频数据理解为一个整体，接收端的播放器内部会自行对音频数据和视频数据做同步。

本申请实施例中的信令消息可以通过任何类型的IM系统进行传输，例如，采用SVC系统进行传输。这时，接收端可以采用图5所示的流程进行对音视频数据进行处理。图5所示的流程为本申请实施例的方法的一种可能的实现方式，其中的一些步骤可以做适当的顺序调整和合并。如图5所示，该方法可以由接收端执行，此时，用户处于观看模式。

在501中，接收端通过CDN系统获取音视频数据。

在502中，接收端通过SVC系统获取信令消息。

在503中，接收端将信令消息缓存在SVC缓存队列中。

在504中，接收端检测音视频数据中是否有SEI字段。

其中，SEI字段中会携带关键帧对应的base_ts。

若检测到有SEI字段，则执行505；若音视频数据中没有携带该SEI字段，执行506。

在505中，更新diff_time。

其中，diff_time等于关键帧的base_ts与关键帧的PTS之差。

在506中，接收端确定该音视频数据是否为音频数据。

若该音视频数据为音频数据，则执行507；若该音视频数据不是音频数据，则说明为视频数据，那么执行508。

在507中，接收端对该音频数据进行处理，例如解码、播放等处理。

在508中，接收端从视频数据的各个视频帧中获取对应的PTS。

在509中，接收端对该视频数据进行处理，例如解码、渲染、显示等处理。

在510中，根据在505中更新的diff_time，以及在508中获取的PTS，确定各个视频帧对应的im_time。

在511中，接收端根据在510中获取的im_time，从SVC缓存队列中获取时间戳比im_time小的信令消息进行处理，例如解码、显示等处理。

存在一种情况，处于观看模式的用户需要切换至互动模式从而与老师之间进行互动，或者处于互动模式的用户需要切换至观看模式。但是，相比于RTC系统，CDN系统中的音视频数据存在一定延迟，因此，RTC系统的音视频数据与CDN系统的音视频数据之间存在时间差。

由于互动模式的学生收到的信令消息和通过RTC系统接收的音视频数据都是实时的，观看模式的学生从CDN系统接收的音视频数据是延迟的，例如3s-5s的延迟，因此，当用户在互动模式和观看模式之间切换时，存在过渡的问题。其中，当学生从互动模式切换到观看模式时，由于互动模式的音视频数据是领先于观看模式的音视频数据的，切换时如果直接播放从CDN系统传输过来的音视频数据，会有一段时间重复之前从RTC系统传输过来的已经播放的音视频数据；而学生从观看模式切换到互动模式时，由于观看模式的音视频数据落后于互动模式的音视频数据，切换时如果直接播放从RTC系统传输过来的音视频数据，就会使RTC系统和CDN系统的时间差范围内的音视频数据和信令消息丢失。这样，就会极大地降低用户体验。

为此，本申请实施例还提供了一种切换方式，可以实现互动模式和观看模式之间的有效切换。下面结合情况1和情况2，分别进行描述，其中，情况1为处于互动模式的用户从互动模式切换至观看模式，情况2为处于观看模式的用户从观看模式切换至互动模式。

情况1

当处于互动模式的用户从互动模式切换至观看模式时，可以同时从RTC系统和CDN系统接收音视频数据，并对RTC系统的音视频数据和信令消息，进行慢速处理，直至CDN系统的音视频数据与RTC系统的音视频数据同步时，停止从RTC系统接收音视频数据。

由于互动模式的音视频数据是领先于观看模式的音视频数据的，切换时如果直接播放从CDN系统传输过来的音视频数据，会有一段时间重复之前从RTC系统传输过来的已经播放的音视频数据。因此，该实施例中，在切换时不会立即停止从RTC系统接收音视频数据，而是在一段时间内同时从RTC系统和CDN系统接收音视频数据，并通过对RTC系统的音视频数据和信令消息进行慢速处理，直至CDN系统的音视频数据与RTC系统的音视频数据同步，即等待CDN系统的音视频数据追上RTC系统的音视频数据后，才放弃从RTC系统接收音视频数据，单独处理从CDN系统传输过来的音视频数据。这样，就可以避免向用户播放重复的音视频数据并保证音视频播放的流畅度，使用户感觉不出来卡顿，提高用户体验。

在一种实现方式中，可以对RTC系统的音视频数据进行M1倍的慢速处理，其中，M1≤1。应理解，当M1＝1时，可以认为是按照正常速度对音视频数据进行处理。

其中，可选地，可以根据RTC系统的音视频数据中的视频帧的参考等级确定M1。其中，视频帧的参考等级越高，M1越小。

该视频帧的参考等级与该视频帧的类型相关。通常，视频帧可以分为三类：I帧、P帧和B帧。其中，I帧是关键帧，后面的P帧和B帧的解码需要参考I帧。如果I帧丢失，后面参考该I帧的所有P帧和B帧解的码都会异常。I帧的压缩率有限。P帧是向前参考，只参考前面的I帧或者P帧。P帧的压缩率比I帧高。如果P帧丢失，会影响后面参考该P帧的P帧或者B帧的解码。B帧是前后参考帧，会参考前面的I帧、P帧、以及后面的P帧，压缩率很高。B帧的丢失不会影响其他帧的解码。

因此，以下类型的所述视频帧的参考等级依次增加：I帧、仅被P帧和B帧参考的P帧、仅被P帧参考的P帧、仅被B帧参考的P帧、以及B帧。例如，该视频帧为I帧时，其参考等级为0；该视频帧为P帧，且仅被P帧和B帧参考，其参考等级为1；该视频帧为P帧，且仅被P帧参考，其参考等级为2；该视频帧为P帧，且仅被B帧参考，其参考等级为3；该视频帧为B帧，其参考等级为4。参考等级越高，可丢弃程度越高。

视频帧的参考等级越高，M1越小。例如，视频帧的参考等级为0，M1＝1，即对该视频帧进行正常处理；视频帧的参考等级为1，M1＝0.8，即对该视频帧进行0.8倍的慢速处理；视频帧的参考等级为2，M1＝0.6，即对该视频帧进行0.6倍的慢速处理；视频帧的参考等级为3，M1＝0.4，即对该视频帧进行0.4倍的慢速处理；视频帧的参考等级为4，M1＝0.2，即对该视频帧进行0.2倍的慢速处理。

由于RTC网络和CDN网络中的音视频数据之间的时延差还与当前的网络状态相关，因此还可以结合当前的网络状态，确定M1的值，从而更加准确地实现用户从互动模式向观看模式的切换。例如，可以根据M1＝K1/A1，确定对该视频帧进行慢速处理的倍数M1，其中，A1表示该视频帧的参考等级，K1为预设参数，该预设参数是基于当前的网络状态确定的。

如果当前的RTC系统的网络状态与CDN网络的网络状态之间的差异越大，则设置的K1值越小。这样，对于相同参考等级的视频帧而言，慢速处理的倍数M1越小，即，对视频帧的处理更慢，从而帮助CDN系统的音视频数据尽快追上RTC系统的音视频数据。

该网络状态可以通过例如网络中的数据传输速率等参数体现，数据传输速率越快，表示网络状态越好。

在一种实现方式中，可以根据RTC系统的音视频数据中的视频帧的参考等级，对与该视频帧匹配的音频数据进行慢速处理。

该实施例中，考虑了视频数据与音频数据之间的匹配。在对视频数据与音频数据进行匹配时，可以对老师讲课时的语音中识别出来的文字和视频内容中出现的文字之间做匹配。之后，根据与该音频数据匹配的视频帧的参考等级，确定是否对该音频数据做类似的慢速处理。

以静音数据为例，当与该静音数据匹配的视频帧的参考等级为0时，对该静音数据和该视频帧进行正常处理即可；当与该静音数据匹配的视频帧的参考等级为4时，则慢速处理例如以0.2倍的速度处理该静音数据和该视频帧。

在一种实现方式中，可以对该信令消息进行N1倍的慢速处理，其中，N1≤1。应理解，当N1＝1时，可以认为是按照正常速度对该信令消息进行处理。

其中，可选地，可以根据信令消息的重要等级，确定对该信令消息进行慢速处理的倍数N1。其中，该信令消息的重要等级越高，N1越大。

可以针对信令消息的重要性将其划分为例如0-9不同的重要等级。其中，针对特定用户发送的信令消息的重要等级，高于针对多个用户广播的信令消息的重要等级。例如，老师向所有学生发布一条信令消息，以指示学生回复一条信令消息作为应答，从而表明收到老师发布的该信令消息，那么老师发送的该信令消息的重要等级较低；又例如，如果老师发送信令消息单独@某个学生，那么这种信令消息的重要等级较高。其中，重要等级越高，N1越大。

进一步地，可选地，可以根据信令消息的重要等级，以及与该信令消息匹配的音频数据的重要程度，确定对该信令消息进行慢速处理的倍数N1。

该实施例中，考虑了信令消息与音频数据之间的匹配。在对信令消息与音频数据进行匹配时，可以对老师讲课时的语音中识别出来的文字和信令消息中出现的文字之间做匹配。如果该信令消息匹配到重要程度较高的音频数据，则表示这段语音较为重要，因此可以不对该段语音以及匹配的该信令消息进行慢速处理，或者以较大的N1值对其进行处理；如果信令消息匹配到重要程度较低的音频数据，则以较小的N1值对该段语音以及匹配的该信令消息进行慢速处理。

应理解，对于匹配的音频数据和信令消息，只要两者中有一者的重要程度较高，则就应当考虑选择较大的N1值。除非两者都不重要，那么可以选择较小的N1值。

由于RTC网络和CDN网络中的音视频数据之间的时延差还与当前的网络状态相关，而信令消息需要与音视频数据进行匹配。因此，类似地，还可以结合当前的网络状态，确定N1的值。例如，可以根据N1＝K2/A2，确定对信令消息进行慢速处理的倍数N1，其中，A2表示该信令消息的重要等级，K2为预设参数，该预设参数是基于当前的网络状态确定的。

类似地，如果当前的RTC系统的网络状态与CDN网络的网络状态之间的差异越大，则设置的K2值越小。该网络状态可以通过例如网络中的数据传输速率等参数体现，数据传输速率越快，表示网络状态越好。

这里，需要在一段时间内对RTC系统的音视频数据和信令消息进行慢速处理，直至CDN系统的音视频数据与RTC系统的音视频数据同步时才停止从RTC系统接收音视频数据。

判断CDN系统的音视频数据与RTC系统的音视频数据何时同步，可以参考CDN系统和RTC系统中的音视频数据的NTP时间戳。例如，当CDN系统的音视频数据的NTP时间戳，与RTC系统的音视频数据的NTP时间戳相同时，可以认为CDN系统的音视频数据与RTC系统的音视频数据之间同步了。

其中，可以采用前述针对步骤241至243所描述的方式，获取CDN系统的音视频数据的NTP时间戳。例如，CDN系统的音视频数据的关键帧的SEI字段中，可以携带有该关键帧的NTP时间戳。具体地，可以根据该关键帧的NTP时间戳与该关键帧的显示时间戳之间的时间差，以及CDN系统的音视频数据中各个视频帧的显示时间戳，确定各个视频帧对应的NTP时间戳。

这里，具体计算CDN系统的音视频数据的NTP时间戳的方法，可以参考前面针对NTP时间戳的确定方法的具体描述，为了简洁，这里不再赘述。

而对于RTC系统的NTP时间戳的确定，由于RTC系统的音视频数据和信令消息都是实时传输的，因此在接收到RTC系统的音视频数据和信令消息时，就可以通过调用参数，获得接收时刻的NTP时间戳，从而作为RTC系统的音视频数据的NPT时间戳。

当CDN系统的音视频数据的NTP时间戳，与RTC系统的音视频数据的NTP时间戳相同时，CDN系统的音视频数据与RTC系统的音视频数据同步，这时用户仅从切换后的CDN系统中接收音视频数据即可。

情况2

当处于观看模式的用户从观看模式切换至互动模式时，获取CDN系统与RTC系统的时间差范围内的来自RTC系统的音视频数据和信令消息，并对该时间差范围内的音视频数据和信令消息，以及切换后的一段时间内从RTC系统接收的音视频数据和信令消息，进行快速处理，直至处理完时，恢复对RTC系统的音视频数据和信令消息的实时处理。

这里，所述的一段时间内，是指对该时间差范围内的音视频数据和信令消息的处理时长，在对其进行处理的过程中，用户仍会从RTC系统接收音视频数据并且从IM系统接收信令消息，因此，对这部分数据也需要进行快速处理。

由于观看模式的音视频数据落后于互动模式的音视频数据，切换时如果直接播放从RTC系统传输过来的音视频数据，就会使RTC系统和CDN系统的该时间差范围内的音视频数据和信令消息丢失。因此，该实施例中，在切换时，会从RTC系统中拉取该时间差范围内的音视频数据和信令消息(也可以是客户端中获取缓存的该时间差范围内的音视频数据和信令消息)，然后对拉取的这部分数据以及后续从RTC系统接收的数据进行快速处理，直到处理完，才恢复对RTC系统的音视频数据和信令消息的实时处理。这样，就可以避免RTC系统与CDN系统之间的时间差范围内的数据的丢失，保证音视频播放的流畅度，使用户感觉不出来卡顿，提高用户体验。

在一种实现方式中，可以对RTC系统的音视频数据中的视频帧进行M2倍的快速处理或者对其进行丢弃，其中，M2≥1。应理解，当M1＝2时，可以认为是按照正常速度对音视频数据进行处理。

其中，可选地，可以根据RTC系统的音视频数据中的视频帧的参考等级确定M2。其中，视频帧的参考等级越高，M2越大。

该视频帧的参考等级与该视频帧的类型相关。例如，以下类型的所述视频帧的参考等级依次增加：I帧、仅被P帧和B帧参考的P帧、仅被P帧参考的P帧、仅被B帧参考的P帧、以及B帧。例如，该视频帧为I帧时，其参考等级为0；该视频帧为P帧，且仅被P帧和B帧参考，其参考等级为1；该视频帧为P帧，且仅被P帧参考，其参考等级为2；该视频帧为P帧，且仅被B帧参考，其参考等级为3；该视频帧为B帧，其参考等级为4。参考等级越高，可丢弃程度越高。

视频帧的参考等级越高，M2越大。例如，视频帧的参考等级为0，M1＝1，即对该视频帧进行正常处理；视频帧的参考等级为1，M2＝1.2，即对该视频帧进行1.2倍的快速处理；视频帧的参考等级为2，M2＝1.5，即对该视频帧进行1.5倍的快速处理；视频帧的参考等级为3，M2＝2，即对该视频帧进行2倍的快速处理；视频帧的参考等级为4，对该视频帧进行丢弃。

由于RTC网络和CDN网络中的音视频数据之间的时延差还与当前的网络状态相关，因此还可以结合当前的网络状态，确定M2的值，从而更加准确地实现用户从互动模式向观看模式的切换。例如，可以根据M2＝K3/A1，确定对该视频帧进行快速处理的倍数M2，其中，A1表示该视频帧的参考等级，K3为预设参数，该预设参数是基于当前的网络状态确定的。

如果当前的RTC系统的网络状态与CDN网络的网络状态之间的差异越大，则设置的K3值越大。这样，对于相同参考等级的视频帧而言，快速处理的倍数M3越大，即，对视频帧的处理更快，以尽快播放完上述由于切换导致的RTC系统与CDN系统之间的时间差范围内的数据。

在一种实现方式中，可以根据RTC系统的音视频数据中的视频帧的参考等级，对与该视频帧匹配的音频数据进行快速处理或者丢弃。

以静音数据为例，同一时间段内的静音数据有10s，但是视频数据仅快速处理了5s，那么静音数据也可以按照相同的M2快速处理5s；或者，静音数据丢弃5s并对剩余5s的静音数据与视频数据进行同步处理。

在一种实现方式中，可以对该信令消息进行N2倍的慢速处理，其中，N2≥1。应理解，当N2＝1时，可以认为是按照正常速度对该信令消息进行处理。

其中，可选地，可以根据信令消息的重要等级，确定对该信令消息进行慢速处理的倍数N2。其中，该信令消息的重要等级越低，N2越大。

可以针对信令消息的重要性将其划分为例如0-9不同的重要等级。其中，针对特定用户发送的信令消息的重要等级，高于针对多个用户广播的信令消息的重要等级。例如，老师向所有学生发布一条信令消息，以指示学生回复一条信令消息作为应答，从而表明收到老师发布的该信令消息，那么老师发送的该信令消息的重要等级较低；又例如，如果老师发送信令消息单独@某个学生，那么这种信令消息的重要等级较高。其中，重要等级越低，N2越大。

由于需要对RTC系统和CDN系统的时间差范围内的信令消息进行快速消耗，因此，除了快速处理该时间差范围内的信令消息之外，还可以根据信令消息的重要等级，执行对信令消息的合并处理或者丢弃等操作。例如，老师点名时的信令消息的重要等级较低，那么，可以对点名的信令消息进行合并处理、丢弃、或者以较大的N2进行快速处理。

进一步地，可选地，可以根据信令消息的重要等级，以及与该信令消息匹配的音频数据的重要程度，对该信令消息进行快速处理。

该实施例中，考虑了信令消息与音频数据之间的匹配。在对信令消息与音频数据进行匹配时，可以对老师讲课时的语音中识别出来的文字和信令消息中出现的文字之间做匹配。如果该信令消息匹配到重要程度较高的音频数据，则表示这段语音较为重要，因此可以不对该段语音及匹配的该信令消息进行快速处理，或者以较小的N2值对其进行处理；如果信令消息匹配到重要程度较低的音频数据，则以较大的N2值对该段语音及匹配的该信令消息进行快速处理或者丢弃。

应理解，对于匹配的音频数据和信令消息，只要两者中有一者的重要程度较高，则就应当考虑选择较小的N2值。除非两者都不重要，那么可以选择较大的N2值或者丢弃数据。

由于RTC网络和CDN网络中的音视频数据之间的时延差还与当前的网络状态相关，而信令消息需要与音视频数据进行匹配。因此，类似地，还可以结合当前的网络状态，确定N2的值。例如，可以根据N2＝K4/A2，确定对信令消息进行快速处理的倍数N2，其中，A2表示该信令消息的重要等级，K4为预设参数，该预设参数是基于当前的网络状态确定的。

类似地，如果当前的RTC系统的网络状态与CDN网络的网络状态之间的差异越大，则设置的K4值越大。该网络状态可以通过例如网络中的数据传输速率等参数体现，数据传输速率越快，表示网络状态越好。

这里，需要快速将CDN系统与RTC系统的时间差范围内的音视频数据和信令消息消耗完，才恢复对RTC系统的音视频数据的正常处理逻辑。在判断何时恢复对RTC系统的音视频数据的正常处理逻辑时，可以参考CDN系统和RTC系统中的音视频数据的NTP时间戳。当CDN系统的音视频数据的NTP时间戳，与RTC系统的音视频数据的NTP时间戳相同时，可以认为CDN系统的音视频数据与RTC系统的音视频数据之间同步了。

应理解，本申请实施例的方案同样适用于其他音视频系统。其中，RTC系统可以替换为其他无时延的音视频系统，而CDN系统可以替换为其他有延时的音视频系统。

上文中详细描述了本申请实施例的音视频数据传输的方法，下面将描述本申请实施例的音视频数据传输的装置。

图6示出了本申请一个实施例的音视频数据传输的装置600的示意性框图。该装置600可以执行上述本申请实施例的音视频数据传输的方法，例如，该装置600可以为前述装置110。

如图6所示，该装置600包括：

接收模块610，用于在用户处于互动模式时，接收从实时通信RTC系统发送的所述直播场景中的音视频数据；

处理模块620，用于在所述用户处于互动模式时，对所述接收模块从所述RTC系统接收的所述音视频数据和从即时通信IM系统接收的信令消息进行实时处理；

接收模块610还用于，在所述用户处于观看模式时，接收从内容分发网络CDN系统发送的所述音视频数据；

处理模块620还用于，在所述用户处于观看模式时，对所述接收模块从所述CDN系统接收的所述音视频数据和从所述IM系统接收的信令消息进行同步处理。

由于针对用户的不同状态采用不同的系统进行音视频数据的传输，即保证了互动用户的互动效果，又节省了带宽资源，降低了成本。

可选地，如图6所示，装置600还包括存储模块630，用于对所述信令消息进行缓存；其中，处理模块620还用于：从所述信令消息中获取所述信令消息的网络时间协议NTP时间戳；获取所述音视频数据中各个视频帧的NTP时间戳；对NTP时间戳相同的视频帧和信令消息进行同步处理。

可选地，处理模块620具体用于：确定所述关键帧的NTP时间戳与所述关键帧的显示时间戳之间的时间差，其中，所述关键帧的NTP时间戳位于所述音视频数据的关键帧中的补充增强信息SEI字段中；根据所述时间差以及所述音视频数据中的各个视频帧的显示时间戳，确定各个视频帧对应的NTP时间戳。

可选地，接收模块610还用于，当处于互动模式的用户从互动模式切换至观看模式时，同时从所述RTC系统和所述CDN系统接收音视频数据；处理模块620还用于，对所述RTC系统的音视频数据和所述信令消息，进行慢速处理，直至所述CDN系统的音视频数据与所述RTC系统的音视频数据同步时，停止从所述RTC系统接收音视频数据。

可选地，处理模块620具体用于：根据所述RTC系统的音视频数据中的视频帧的参考等级，确定慢速处理的倍数M1，并根据M1对所述视频帧进行慢速处理，其中，M1≤1，所述视频帧的参考等级越高，M1越小。

可选地，所述视频帧的参考等级与所述视频帧的类型相关，其中，以下类型的所述视频帧的参考等级依次增加：I帧、仅被P帧和B帧参考的P帧、仅被P帧参考的P帧、仅被B帧参考的P帧、以及B帧。

可选地，处理模块620具体用于：根据M1＝K1/A1，确定慢速处理的倍数M1，其中，A1表示所述视频帧的参考等级，K1为预设参数，所述预设参数是基于当前的网络状态确定的，其中，当前的RTC系统的网络状态与CDN系统的网络状态之间的差异越大，则K1值越小。

可选地，处理模块620具体用于：根据所述RTC系统的音视频数据中的视频帧的参考等级，对与所述视频帧匹配的音频数据进行慢速处理。

可选地，处理模块620具体用于：根据所述信令消息的重要等级，确定慢速处理的倍数N1，并根据N1对所述信令消息进行慢速处理，其中，N1≤1，所述信令消息的重要等级越高，N1越大。

可选地，针对特定用户发送的信令消息的重要等级，高于针对多个用户广播的信令消息的重要等级。

可选地，处理模块620具体用于：根据所述信令消息的重要等级，以及与所述信令消息匹配的音频数据的重要程度，确定对所述信令消息进行慢速处理的倍数N1。

可选地，处理模块620具体用于：根据N1＝K2/A2，确定慢速处理的倍数M1，其中，A2表示所述信令消息的重要等级，K2为预设参数，所述预设参数是基于当前的网络状态确定的，其中，当前的RTC系统的网络状态与CDN系统的网络状态之间的差异越大，则K2值越小。

可选地，所述CDN系统的音视频数据与所述RTC系统的音视频数据同步，包括：所述CDN系统的音视频数据的NTP时间戳与所述RTC系统的音视频数据的NTP时间戳相同。

可选地，接收模块610还用于，当处于观看模式的用户从观看模式切换至互动模式时，获取所述CDN系统与所述RTC系统的时间差范围内的来自所述RTC系统的音视频数据和所述信令消息；处理模块620还用于，对所述时间差范围内的音视频数据和所述信令消息，以及切换后的一段时间内从所述RTC系统接收的音视频数据和所述信令消息，进行快速处理，直至处理完时，恢复对所述RTC系统的音视频数据和所述信令消息的实时处理。

可选地，处理模块620具体用于：根据所述RTC系统的音视频数据中的视频帧的参考等级，确定快速处理的倍数M2，并根据M2对所述视频帧进行快速处理，其中，M2≥1，所述视频帧的参考等级越高，M2越大；或者，根据所述RTC系统的音视频数据中的视频帧的参考等级，对所述视频帧进行丢弃。

可选地，处理模块620具体用于：根据M2＝K3/A1，确定快速处理的倍数M2，其中，A1表示所述视频帧的参考等级，K3为预设参数，所述预设参数是基于当前的网络状态确定的，其中，当前的RTC系统的网络状态与CDN系统的网络状态之间的差异越大，则K3值越大。

可选地，处理模块620具体用于：根据所述RTC系统的音视频数据中的视频帧的参考等级，对与所述视频帧匹配的音频数据进行快速处理或者丢弃。

可选地，处理模块620具体用于：根据所述信令消息的重要等级，对所述信令消息进行快速处理，其中，对所述信令消息进行快速处理包括执行以下操作中的至少一种：确定快速处理的倍数N2，并根据N2对所述信令消息进行快速处理，其中，N2≥1，所述信令消息的重要等级越低，N2越大；对所述信令消息进行合并处理；对所述信令消息进行丢弃。

可选地，处理模块620具体用于：根据所述信令消息的重要等级，以及与所述信令消息匹配的音频数据的重要程度，对所述信令消息进行快速处理。

可选地，处理模块620具体用于：根据N2＝K4/A2，确定快速处理的倍数N2，其中，A2表示所述信令消息的重要等级，K4为预设参数，所述预设参数是基于当前的网络状态确定的，其中，当前的RTC系统的网络状态与CDN系统的网络状态之间的差异越大，则K4值越大。

应理解，装置600接收和处理音视频数据的具体方式以及产生的有益效果可以参见方法实施例中的相关描述，为了简洁，这里不再赘述。

图7示出了本申请一个实施例的音视频数据传输的装置700的示意性框图。该装置700可以执行上述本申请实施例的音视频数据传输的方法，例如，该装置700可以为前述装置120。

如图7所示，该装置700可以包括：

第一发送模块710，用于通过RTC系统向处于互动模式的用户发送音视频数据；

第二发送模块710，用于将所述音视频数据推送至CDN系统，并通过所述CDN系统向处于观看模式的用户发送所述音视频数据。

可选地，所述音视频数据的关键帧的补充增强信息SEI字段中携带所述关键帧的NTP时间戳，所述音视频数据的NTP时间戳用于对所述音视频数据和所述信令消息进行同步处理。

本申请实施例还提供了一种计算机(或其他终端设备)，包含上述的音视频数据传输的装置600或者装置700。

本申请实施例还提供了一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为执行上述音视频数据传输的方法200。

本申请实施例还提供了一种计算机程序产品，所述计算机程序产品包括存储在计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使所述计算机执行上述音视频数据传输的方法200。

上述的计算机可读存储介质可以是暂态计算机可读存储介质，也可以是非暂态计算机可读存储介质。

本申请实施例还提供了一种电子设备800，其结构如图8所示，该电子设备包括：

至少一个处理器(processor)810，图8中以一个处理器810为例；和存储器(memory)820，还可以包括通信接口(communication interface)840和总线830。其中，处理器810、通信接口840、存储器820可以通过总线830完成相互间的通信。通信接口840可以用于信息传输。处理器810可以调用存储器820中的逻辑指令，以执行上述实施例的语音识别的方法。

此外，上述的存储器820中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。

存储器820作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序，如本申请实施例中的方法对应的程序指令或模块。处理器810通过运行存储在存储器820中的软件程序、指令以及模块，从而执行功能应用以及数据处理，即实现上述方法实施例中的语音识别的方法。

存储器820可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端设备的使用所创建的数据等。此外，存储器820可以包括高速随机存取存储器，还可以包括非易失性存储器。

本申请实施例的技术方案可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括一个或多个指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请实施例所述方法的全部或部分步骤。而前述的存储介质可以是非暂态存储介质，包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等多种可以存储程序代码的介质，也可以是暂态存储介质。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

本申请中使用的用词仅用于描述实施例并且不用于限制权利要求。如在实施例以及权利要求的描述中使用的，除非上下文清楚地表明，否则单数形式的“一个”(a)、“一个”(an)和“所述”(the)旨在同样包括复数形式。类似地，如在本申请中所使用的术语“和/或”是指包含一个或一个以上相关联的列出的任何以及所有可能的组合。另外，当用于本申请中时，术语“包括”(comprise)及其变型“包括”(comprises)和/或包括(comprising)等指陈述的特征、整体、步骤、操作、元素，和/或组件的存在，但不排除一个或一个以上其它特征、整体、步骤、操作、元素、组件和/或这些的分组的存在或添加。

所描述的实施例中的各方面、实施方式、实现或特征能够单独使用或以任意组合的方式使用。所描述的实施例中的各方面可由软件、硬件或软硬件的结合实现。所描述的实施例也可以由存储有计算机可读代码的计算机可读介质体现，该计算机可读代码包括可由至少一个计算装置执行的指令。所述计算机可读介质可与任何能够存储数据的数据存储装置相关联，该数据可由计算机系统读取。用于举例的计算机可读介质可以包括只读存储器、随机存取存储器、CD-ROM、HDD、DVD、磁带以及光数据存储装置等。所述计算机可读介质还可以分布于通过网络联接的计算机系统中，这样计算机可读代码就可以分布式存储并执行。

上述技术描述可参照附图，这些附图形成了本申请的一部分，并且通过描述在附图中示出了依照所描述的实施例的实施方式。虽然这些实施例描述的足够详细以使本领域技术人员能够实现这些实施例，但这些实施例是非限制性的；这样就可以使用其它的实施例，并且在不脱离所描述的实施例的范围的情况下还可以做出变化。比如，流程图中所描述的操作顺序是非限制性的，因此在流程图中阐释并且根据流程图描述的两个或两个以上操作的顺序可以根据若干实施例进行改变。作为另一个例子，在若干实施例中，在流程图中阐释并且根据流程图描述的一个或一个以上操作是可选的，或是可删除的。另外，某些步骤或功能可以添加到所公开的实施例中，或两个以上的步骤顺序被置换。所有这些变化被认为包含在所公开的实施例以及权利要求中。

另外，上述技术描述中使用术语以提供所描述的实施例的透彻理解。然而，并不需要过于详细的细节以实现所描述的实施例。因此，实施例的上述描述是为了阐释和描述而呈现的。上述描述中所呈现的实施例以及根据这些实施例所公开的例子是单独提供的，以添加上下文并有助于理解所描述的实施例。上述说明书不用于做到无遗漏或将所描述的实施例限制到本申请的精确形式。根据上述教导，若干修改、选择适用以及变化是可行的。在某些情况下，没有详细描述为人所熟知的处理步骤以避免不必要地影响所描述的实施例。

以上所述，仅为本申请实施例的具体实施方式，但本申请实施例的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请实施例揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应以所述权利要求的保护范围为准。

Claims

1.一种音视频数据传输的方法，其特征在于，应用于在线直播场景中，所述方法包括：

在用户处于互动模式时，接收从实时通信RTC系统发送的所述直播场景中的音视频数据，并对从所述RTC系统接收的音视频数据和从即时通信IM系统接收的信令消息进行实时处理；

在所述用户处于观看模式时，接收从内容分发网络CDN系统发送的音视频数据，并对从所述CDN系统接收的音视频数据和从所述IM系统接收的信令消息进行同步处理；

所述方法还包括：

当处于互动模式的用户从互动模式切换至观看模式时，同时从所述RTC系统和所述CDN系统接收音视频数据；

对所述RTC系统的音视频数据和所述信令消息，进行慢速处理，直至所述CDN系统的音视频数据与所述RTC系统的音视频数据同步时，停止从所述RTC系统接收音视频数据。

2.根据权利要求1所述的方法，其特征在于，所述对从所述CDN系统接收的音视频数据和从所述IM系统接收的信令消息进行同步处理，包括：

对所述信令消息进行缓存，并从所述信令消息中获取所述信令消息的网络时间协议NTP时间戳；

获取所述音视频数据中各个视频帧的NTP时间戳；

对NTP时间戳相同的视频帧和信令消息进行同步处理。

3.根据权利要求2所述的方法，其特征在于，所述获取所述音视频数据中各个视频帧的NTP时间戳，包括：

确定所述音视频数据的关键帧的NTP时间戳与所述关键帧的显示时间戳之间的时间差，其中，所述关键帧的NTP时间戳位于所述关键帧中的补充增强信息SEI字段中；

根据所述时间差以及所述音视频数据中的各个视频帧的显示时间戳，确定各个视频帧对应的NTP时间戳。

4.根据权利要求1至3中任一项所述的方法，其特征在于，所述对所述RTC系统的音视频数据和所述信令消息，进行慢速处理，包括：

根据所述RTC系统的音视频数据中的视频帧的参考等级，确定慢速处理的倍数M1，并根据M1对所述视频帧进行慢速处理，其中，M1≤1，所述视频帧的参考等级越高，M1越小。

5.根据权利要求4所述的方法，其特征在于，所述视频帧的参考等级与所述视频帧的类型相关，其中，以下类型的所述视频帧的参考等级依次增加：I帧、仅被P帧和B帧参考的P帧、仅被P帧参考的P帧、仅被B帧参考的P帧、以及B帧。

6.根据权利要求4所述的方法，其特征在于，所述根据所述RTC系统的音视频数据中的视频帧的参考等级，确定慢速处理的倍数M1，包括：

根据M1＝K1/A1，确定慢速处理的倍数M1，其中，A1表示所述视频帧的参考等级，K1为预设参数，所述预设参数是基于当前的网络状态确定的，其中，当前的RTC系统的网络状态与CDN系统的网络状态之间的差异越大，则K1值越小。

7.根据权利要求1至3中任一项所述的方法，其特征在于，所述对所述RTC系统的音视频数据和所述信令消息，进行慢速处理，包括：

根据所述RTC系统的音视频数据中的视频帧的参考等级，对与所述视频帧匹配的音频数据进行慢速处理。

8.根据权利要求1至3中任一项所述的方法，其特征在于，所述对所述RTC系统的音视频数据和所述信令消息，进行慢速处理，包括：

根据所述信令消息的重要等级，确定慢速处理的倍数N1，并根据N1对所述信令消息进行慢速处理，其中，N1≤1，所述信令消息的重要等级越高，N1越大。

9.根据权利要求8所述的方法，其特征在于，针对特定用户发送的信令消息的重要等级，高于针对多个用户广播的信令消息的重要等级。

10.根据权利要求8所述的方法，其特征在于，所述根据所述信令消息的重要等级，确定慢速处理的倍数N1，包括：

根据所述信令消息的重要等级，以及与所述信令消息匹配的音频数据的重要程度，确定对所述信令消息进行慢速处理的倍数N1。

11.根据权利要求8所述的方法，其特征在于，所述根据所述信令消息的重要等级，确定慢速处理的倍数N1，包括：

根据N1＝K2/A2，确定慢速处理的倍数M1，其中，A2表示所述信令消息的重要等级，K2为预设参数，所述预设参数是基于当前的网络状态确定的，其中，当前的RTC系统的网络状态与CDN系统的网络状态之间的差异越大，则K2值越小。

12.根据权利要求1至3中任一项所述的方法，其特征在于，所述CDN系统的音视频数据与所述RTC系统的音视频数据同步，包括：

所述CDN系统的音视频数据的NTP时间戳与所述RTC系统的音视频数据的NTP时间戳相同。

13.根据权利要求1至3中任一项所述的方法，其特征在于，所述方法还包括：

当处于观看模式的用户从观看模式切换至互动模式时，获取所述CDN系统与所述RTC系统的时间差范围内的来自所述RTC系统的音视频数据和所述信令消息；

对所述时间差范围内的音视频数据和所述信令消息，以及切换后的一段时间内从所述RTC系统接收的音视频数据和所述信令消息，进行快速处理，直至处理完时，恢复对所述RTC系统的音视频数据和所述信令消息的实时处理。

14.根据权利要求13所述的方法，其特征在于，所述对所述时间差范围内的音视频数据和所述信令消息，以及切换后的一段时间内从所述RTC系统接收的音视频数据和所述信令消息，进行快速处理，包括：

根据所述RTC系统的音视频数据中的视频帧的参考等级，确定快速处理的倍数M2，并根据M2对所述视频帧进行快速处理，其中，M2≥1，所述视频帧的参考等级越高，M2越大；或者，

根据所述RTC系统的音视频数据中的视频帧的参考等级，对所述视频帧进行丢弃。

15.根据权利要求14所述的方法，其特征在于，所述视频帧的参考等级与所述视频帧的类型相关，其中，以下类型的所述视频帧的参考等级依次增加：I帧、仅被P帧和B帧参考的P帧、仅被P帧参考的P帧、仅被B帧参考的P帧、以及B帧。

16.根据权利要求14所述的方法，其特征在于，所述根据所述RTC系统的音视频数据中的视频帧的参考等级，确定快速处理的倍数M2，包括：

根据M2＝K3/A1，确定快速处理的倍数M2，其中，A1表示所述视频帧的参考等级，K3为预设参数，所述预设参数是基于当前的网络状态确定的，其中，当前的RTC系统的网络状态与CDN系统的网络状态之间的差异越大，则K3值越大。

17.根据权利要求13所述的方法，其特征在于，所述对所述时间差范围内的音视频数据和所述信令消息，以及切换后的一段时间内从所述RTC系统接收的音视频数据和所述信令消息，进行快速处理，包括：

根据所述RTC系统的音视频数据中的视频帧的参考等级，对与所述视频帧匹配的音频数据进行快速处理或者丢弃。

18.根据权利要求13所述的方法，其特征在于，所述对所述时间差范围内的音视频数据和所述信令消息，以及切换后的一段时间内从所述RTC系统接收的音视频数据和所述信令消息，进行快速处理，包括：

根据所述信令消息的重要等级，对所述信令消息进行快速处理，其中，对所述信令消息进行快速处理包括执行以下操作中的至少一种：

确定快速处理的倍数N2，并根据N2对所述信令消息进行快速处理，其中，N2≥1，所述信令消息的重要等级越低，N2越大；

对所述信令消息进行合并处理；

对所述信令消息进行丢弃。

19.根据权利要求18所述的方法，其特征在于，所述根据所述信令消息的重要等级，对所述信令消息进行快速处理，包括：

根据所述信令消息的重要等级，以及与所述信令消息匹配的音频数据的重要程度，对所述信令消息进行快速处理。

20.根据权利要求18所述的方法，其特征在于，针对特定用户发送的信令消息的重要等级，高于针对多个用户广播的信令消息的重要等级。

21.根据权利要求18所述的方法，其特征在于，所述确定快速处理的倍数N2，包括：

根据N2＝K4/A2，确定快速处理的倍数N2，其中，A2表示所述信令消息的重要等级，K4为预设参数，所述预设参数是基于当前的网络状态确定的，其中，当前的RTC系统的网络状态与CDN系统的网络状态之间的差异越大，则K4值越大。

22.一种音视频数据传输的装置，其特征在于，包括处理器和存储器，其中，所述存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，所述计算机程序包括用于执行实现权利要求1至21中任一所述的音视频数据传输的方法的指令。

23.一种存储介质，其特征在于，用于非暂时性地存储计算机可读指令，其中，当所述计算机可读指令由计算机执行时，可以实现权利要求1至21中任一项所述的音视频数据传输的方法。