CN114449200A - 音视频通话方法、装置及终端设备 - Google Patents

Abstract

本申请提供了音视频通话方法、装置及终端设备，适用于音视频通话技术领域，该方法应用于第一终端设备，方法包括：在与第二终端设备音视频通话的过程中，生成流媒体数据和信令，流媒体数据为音频流或视频流；将信令注入至流媒体数据中；将注入信令后的流媒体数据发送至第二终端设备，注入信令后的流媒体数据，用于第二终端设备提取和处理信令。本申请实施例通过复用媒体传输通道并在音视频流中注入信令，避免了信令传输滞后的情况，使得信令与音视频流可以同步传输，提高了信令的实时性。因此本申请实施例可以有效提升音视频通话的质量。

Description

音视频通话方法、装置及终端设备

技术领域

本申请属于音视频通话技术领域，尤其涉及音视频通话方法、装置及终端设备。

背景技术

在音视频通话的过程中，一般都会涉及一些信令的传输。例如两个终端设备进行视频通话的场景中，视频通话一侧终端设备，可以向另一侧终端设备传输屏幕共享信令，以请求共享自身的屏幕内容。

现有的音视频通话方案中，采用双通道(媒体传输通道和信令通道)来传输音视频流和信令。其中，媒体传输通道主要用于传输音视频流，而信令通道主要用于传输信令。媒体传输通道和信令通道之间互不关联、互不影响且没有从属关系。

上述双通道的方案虽然可以实现对音视频通话过程中音视频流和信令的传输，但实际应用中信令传输的时延较为严重，从而导致音视频通话质量较差。

发明内容

有鉴于此，本申请实施例提供了音视频通话方法、装置及终端设备，可以解决现有技术中音视频通话质量较差的问题。

本申请实施例的第一方面提供了一种音视频通话方法，应用于第一终端设备，方法包括：

在与第二终端设备音视频通话的过程中，生成流媒体数据和信令，流媒体数据为音频流或视频流。

将信令注入至流媒体数据中。

将注入信令后的流媒体数据发送至第二终端设备，注入信令后的流媒体数据，用于第二终端设备提取和处理信令。

在本申请实施例中，摒弃了双通道传输的方案，采用单通道来传输音视频流和信令。当某一侧终端设备需要传输信令时，首先会将信令注入至音视频流之中，再将注入有信令的音视频流传输至对端设备。对端设备则在接收到音视频流时，可以先从中提取出信令，再处理提取出的信令和音视频流。相对双通道传输的方案而言，本申请实施例一方面可以摒弃原有信令通道，从而减少了对信令通道资源的占用。另一方面，通过复用媒体传输通道并在音视频流中注入信令，避免了信令传输滞后的情况，使得信令与音视频流可以同步传输，提高了信令的实时性。因此本申请实施例可以有效提升音视频通话的质量。

在第一方面的第一种可能的实现方式中，将信令注入至流媒体数据中，包括：

若流媒体数据为音频流，则将信令注入至音频流的语音帧之中。

若流媒体数据为视频流，则将信令注入至视频流的图像帧之中。

在本申请实施例中，针对流媒体数据是音频流和视频流的情况，分别设置了两种对应的信令注入方法。使得本申请实施例可以兼容于音频通话和视频通话场景需求。

在第一方面的第二种可能的实现方式中，流媒体数据为视频流，将信令注入至流媒体数据中，包括：

对视频流进行编码，得到视频流中各帧图像的网络适配单元。

从得到的网络适配单元中选取出一个I帧图像的网络适配单元，并将该网络适配单元的网络适配单元头中的类型参数赋值为第一参数值，将信令写入至该网络适配单元的网络适配单元载荷中。

在本申请实施例中，第一终端设备采用H.264标准对视频流进行编码，通过将信令注入至I帧图像的网络适配单元(Network Abstract Layer Unit，NALU)之中，并将NALU头中的类型参数修改为预设的第一参数值。使得信令可以实现可靠的注入。同时使得第二终端设备可以根据NALU头中的类型参数值，准确定位出包含信令的NALU，并能准确提取出NALU中包含的信令，实现对信令的数据剥离。利用I帧的高稳定性和可靠性来传输信令，本申请实施例具有以下优点：

1、复用媒体传输通道传输信令，摒弃长连接的信令通道，因此可以减少对通道资源的占用。

2、减少信令通道的使用，可以降低终端设备对信令传输的功耗。

3、利用实际应用中I帧稳定可靠传输的特性，可以降低信令传输时，信令丢失的风险。从而提高对信令传输的稳定性和可靠性。

4、信令跟随I帧同步传输，使得信令可以与视频流同步传输，进而使得信令传输的实时性极高。

在第一方面的第二种可能实现方式的基础上，作为第一方面的第三种可能的实现方式，第一参数值为[13，31]中的任一整数。考虑到实际应用中，13至31均是NALU头中，类型参数nal_unit_type为使用的值。通过使用这些值作为第一参数值，可以实现对注入有信令的NALU的准确标记。使得第二终端设备可以在视频流中准确找出具有信令的I帧图像的NALU，并提取出其中的信令。保障了对信令注入和提取的有效性和可靠性。

在第一方面的第一种至第三种可能实现方式中任一种可能实现方式的基础上，作为第一方面的第四种可能的实现方式，在音视频通话的过程中，第一终端设备将自身的屏幕内容以视频流共享至第二终端设备。

相应的，生成信令的操作，包括：

响应于第一触发操作，生成第一触发操作关联的信令，信令中携带有用户提示信息，用户提示信息用于告知用户第二终端设备黑屏原因。

在本申请实施例中，第一终端设备通过将携带有用户提示信息的信令注入至由黑屏画面组成的视频流，并通过媒体传输通道将视频流发送至第二终端设备的方式，实现对信令的传输。第二终端设备在接收到视频流时先提取出信令，并解析出信令携带的用户提示信息。最后将视频流和用户提示信息均进行显示。从而使得第二终端设备用户可以在看到黑屏的同时，查看到用户提示信息，获知黑屏原因。相对于双通道传输方案而言，本申请实施例避免了信令传输滞后的情况，使得信令与视频流可以同步传输，提高了信令的实时性。因此本申请实施例不会出现第二终端设备黑屏了，用户却无法获知黑屏原因的情况，使得用户体验更佳。

在第一方面的第一种至第三种可能实现方式中任一种可能实现方式的基础上，作为第一方面的第五种可能的实现方式，流媒体数据为视频流，第一终端设备生成信令，包括：

响应于第二触发操作，第一终端设备确定第二触发操作指向的视频特效类型，并生成携带有视频特效类型的信令，携带有视频特效类型的信令，用于第二终端设备根据视频特效类型对播放的视频流添加视频特效。

在本申请实施例中，第一终端设备通过将携带有视频特效类型的信令注入至视频流，并通过媒体传输通道将视频流发送至第二终端设备的方式，实现对信令的传输。第二终端设备在接收到视频流时先提取出信令，并解析出信令携带的视频特效类型。最后在播放视频流的同时，为视频流添加相应的视频特效。相对双通道传输方案而言，本申请实施例避免了信令传输滞后的情况，使得信令与视频流可以同步传输，提高了信令的实时性。即使面对视频特效这种实时性要求较高场景，本申请实施例也可以有效满足信令的实时性需求。

本申请实施例的第二方面提供了一种音视频通话系统，包括第一终端设备和第二终端设备。

第一终端设备在音视频通话过程中，生成流媒体数据和信令，流媒体数据为音频流或视频流。

第一终端设备将信令注入至流媒体数据中。

第一终端设备将注入信令后的流媒体数据发送至第二终端设备。

第二终端设备在接收到注入信令后的流媒体数据后，从注入信令后的流媒体数据中提取出信令，并对信令进行处理。

在本申请实施例中，摒弃了双通道传输的方案，采用单通道来传输音视频流和信令。当某一侧终端设备需要传输信令时，首先会将信令注入至音视频流之中，再将注入有信令的音视频流传输至对端设备。对端设备则在接收到音视频流时，先从中提取出信令，再处理提取出的信令和音视频流。相对双通道传输的方案而言，本申请实施例一方面可以摒弃原有信令通道，从而减少了对信令通道资源的占用。另一方面，通过复用媒体传输通道并在音视频流中注入信令，避免了信令传输滞后的情况，使得信令与音视频流可以同步传输，提高了信令的实时性。因此本申请实施例可以有效提升音视频通话的质量。

在第二方面的第一种可能的实现方式中，将信令注入至流媒体数据中，包括：

若流媒体数据为音频流，则将信令注入至音频流的语音帧之中。

若流媒体数据为视频流，则将信令注入至视频流的图像帧之中。

在本申请实施例中，针对流媒体数据是音频流和视频流的情况，分别设置了两种对应的信令注入方法。使得本申请实施例可以兼容于音频通话和视频通话场景需求。

在第二方面的第二种可能的实现方式中，流媒体数据为视频流，第一终端设备将信令注入至流媒体数据中，包括：

第一终端设备对视频流进行编码，得到视频流中各帧图像的网络适配单元。

第一终端设备从得到的网络适配单元中选取出一个I帧图像的网络适配单元，并将该网络适配单元的网络适配单元头中的类型参数赋值为第一参数值，将信令写入至该网络适配单元的网络适配单元载荷中。

相应的，第二终端设备从注入信令后的流媒体数据中提取出信令，包括：

第二终端设备对视频流中各个网络适配单元的网络适配单元头进行识别，确定出网络适配单元头中类型参数的值为第一参数值的网络适配单元。

第二终端设备从确定出的网络适配单元的网络适配单元载荷中，提取出信令。

在本申请实施例中，第一终端设备通过将信令注入至I帧图像的NALU之中，并将NALU头中的类型参数修改为预设的第一参数值。使得信令可以实现可靠的注入。同时使得第二终端设备可以根据NALU头中的类型参数值，准确定位出包含信令的NALU，并能准确提取出NALU中包含的信令，实现对信令的数据剥离。利用I帧的高稳定性和可靠性来传输信令，本申请实施例具有以下优点：

1、复用媒体传输通道传输信令，摒弃长连接的信令通道，因此可以减少对通道资源的占用。

2、减少信令通道的使用，可以降低终端设备对信令传输的功耗。

3、利用实际应用中I帧稳定可靠传输的特性，可以降低信令传输时，信令丢失的风险。从而提高对信令传输的稳定性和可靠性。

4、信令跟随I帧同步传输，使得信令可以与视频流同步传输，进而使得信令传输的实时性极高。

在第二方面的第二种可能实现方式的基础上，作为第二方面的第三种可能的实现方式，第一参数值为[13，31]中的任一整数。考虑到实际应用中，13至31均是NALU头中，类型参数nal_unit_type为使用的值。通过使用这些值作为第一参数值，可以实现对注入有信令的NALU的准确标记。使得第二终端设备可以在视频流中准确找出具有信令的I帧图像的NALU，并提取出其中的信令。保障了对信令注入和提取的有效性和可靠性。

在第二方面的第一种至第三种可能实现方式中任一种可能实现方式的基础上，作为第二方面的第四种可能的实现方式，在音视频通话的过程中，第一终端设备将自身的屏幕内容以视频流共享至第二终端设备。

相应的，第一终端设备生成信令，包括：

响应于第一触发操作，第一终端设备生成第一触发操作关联的信令，信令中携带有用户提示信息，用户提示信息用于告知用户第二终端设备黑屏原因。

相应的，第二终端设备对信令进行处理，包括：

第二终端设备对信令进行解析，提取出信令中携带的用户提示信息，并对用户提示信息进行显示。

在本申请实施例中，第一终端设备通过将携带有用户提示信息的信令注入至由黑屏画面组成的视频流，并通过媒体传输通道将视频流发送至第二终端设备的方式，实现对信令的传输。第二终端设备在接收到视频流时先提取出信令，并解析出信令携带的用户提示信息。最后将视频流和用户提示信息均进行显示。从而使得第二终端设备用户可以在看到黑屏的同时，查看到用户提示信息，获知黑屏原因。相对于双通道传输方案而言，本申请实施例避免了信令传输滞后的情况，使得信令与视频流可以同步传输，提高了信令的实时性。因此本申请实施例不会出现第二终端设备黑屏了，用户却无法获知黑屏原因的情况，使得用户体验更佳。

在第二方面的第一种至第三种可能实现方式中任一种可能实现方式的基础上，作为第二方面的第五种可能的实现方式，流媒体数据为视频流，第一终端设备生成信令，包括：

响应于第二触发操作，第一终端设备确定第二触发操作指向的视频特效类型，并生成携带有视频特效类型的信令。

相应的，第二终端设备对信令进行处理，包括：

第二终端设备对信令进行解析，确定出视频特效类型。

第二终端设备在播放视频流时，根据视频特效类型对播放的视频流添加视频特效。

在本申请实施例中，第一终端设备通过将携带有视频特效类型的信令注入至视频流，并通过媒体传输通道将视频流发送至第二终端设备的方式，实现对信令的传输。第二终端设备在接收到视频流时先提取出信令，并解析出信令携带的视频特效类型。最后在播放视频流的同时，为视频流添加相应的视频特效。相对双通道传输方案而言，本申请实施例避免了信令传输滞后的情况，使得信令与视频流可以同步传输，提高了信令的实时性。即使面对视频特效这种实时性要求较高场景，本申请实施例也可以有效满足信令的实时性需求。

本申请实施例的第三方面提供了一种音视频通话装置，包括：

数据生成模块，用于在与第二终端设备音视频通话的过程中，生成流媒体数据和信令，所述流媒体数据为音频流或视频流；

信令注入模块，用于将所述信令注入至所述流媒体数据中；

数据发送模块，用于将注入所述信令后的所述流媒体数据发送至所述第二终端设备，注入所述信令后的所述流媒体数据，用于所述第二终端设备提取和处理所述信令。

本申请实施例的第四方面提供了一种终端设备，所述终端设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时，使得终端设备实现如上述第一方面中任一项所述音视频通话方法的步骤。

本申请实施例的第五方面提供了一种计算机可读存储介质，包括：存储有计算机程序，所述计算机程序被处理器执行时，使得终端设备实现如上述第一方面中任一项所述音视频通话方法的步骤。

本申请实施例的第六方面提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面中任一项所述音视频通话方法。

本申请实施例的第七方面提供了一种芯片系统，所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现上述第一方面任一项所述的音视频通话方法。

其中，芯片系统可以是单个芯片或者，多个芯片组成的芯片模组。

可以理解的是，上述第三方面至第七方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1A是本申请一实施例提供的音视频通话过程中，音视频流和信令传输的示意图；

图1B是本申请一实施例提供的音视频通话过程中，音视频流和信令传输的示意图；

图2是本申请一实施例提供的音视频通话方法的流程示意图；

图3是本申请一实施例提供的音视频通话方法的流程示意图；

图4是本申请一实施例提供的音视频通话方法的流程示意图；

图5A是H.264标准中三种帧图像的示意图；

图5B是本申请一实施例提供的多个网络适配单元构成的数据组示意图；

图5C是本申请一实施例提供的音视频通话方法的流程示意图；

图6是本申请一实施例提供的音视频通话方法的流程示意图；

图7是本申请实施例提供的音视频通话装置的结构示意图；

图8是本申请一实施例提供的音视频通话方法所适用于的电子设备的结构示意图；

图9是本申请实施例提供的终端设备的软件结构框图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

为了便于理解本申请，此处先对本申请实施例进行简要说明：

在多个终端设备进行音视频通话的过程中，一般都会涉及一些信令的传输。例如在多个终端设备进行视频通话的场景中，视频通话的某一侧终端设备，可以向其他侧的终端设备传输屏幕共享信令，以请求向其他侧终端设备共享自身的屏幕内容。其中，音视频通话，是指音频通话或者视频通话。

现有的音视频通话方案中，采用双通道(媒体传输通道和信令通道)来传输音视频流和信令。其中，媒体传输通道一般是基于用户数据报协议(user datagram protocol，UDP)实现，主要用于传输音视频流。而信令通道一般是基于传输控制协议(TransmissionControl Protocol，TCP)实现，主要用于传输信令。媒体传输通道和信令通道之间互不关联、互不影响且没有从属关系。可以参考图1A，是两终端设备(终端设备A和终端设备B)进行音视频通话时，音视频流和信令传输的示意图。

实际应用中发现，信令通道在传输信令时需要服务器中转，再发送给接收方设备，使得传输时延较高，实时性低。另外媒体传输通道和信令通道之间互不关联影响，也互不依赖，使得两个通道对数据传输的时序难以控制。这些问题导致实际音视频通话过程中，经常会现出信令传输滞后，音视频流和信令不同步的情况。从而使得音视频通话质量较差。

为了降低信令传输时延，提高信令传输实时性，提升音视频通话的效果。在本申请实施例中，摒弃了双通道传输的方案，采用单通道来传输音视频流和信令。例如可以参考图1B，是两终端设备(终端设备A和终端设备B)进行音视频通话时，音视频流和信令传输的示意图。

具体而言，本申请实施例会将信令注入至音视频流之中，并在媒体传输通道与音视频流一并传输。对端设备在接收到音视频流之后，可以先从音视频流中提取出信令，再解析音视频流。通过复用媒体传输通道并在音视频流中注入信令，避免了信令传输滞后的情况，使得信令与音视频流可以同步传输。因此本申请实施例可以有效提升音视频通话的质量。

同时，对本申请实施例中可能涉及到的一些名词和概念进行说明如下：

流媒体(streaming media)数据：在本申请实施例中流媒体数据包括音频流和视频流两种，具体可根据实施例实际应用场景确定是音频流还是视频流。

应当特别说明地，视频是由图像和音频组成的。但在一些视频通话的场景中，若某一侧终端设备未使用音频功能(例如用户手动关闭麦克风或者是终端设备的麦克风损坏无法使用)。会导致视频通话的过程中，该侧终端设备无法传输音频。此时该侧终端设备传输的视频流仅会包含图像内容。因此在此场景下，视频流实质为图像流。由此可知，在本申请实施例中，视频流也可能是图像流。具体需根据实际应用场景确定。

通话发起端和通话接收端(以下简称发起端和接收端)：为了便于区分通话各端设备，在本申请实施例中，将发起音视频通话的终端设备称为发起端，并将发起端的通话对端设备称为接收端。

应当理解地，单次通话过程中，发起端和接收端的数量均可以大于1。例如在一些实例中，用户可以通过手机发起群视频的方式，同时与多个接收端进行视频通话，此时接收端的数量可以大于1。而在另一些实例中，两个不同的用户可以通过各自的手机，向一个同一接收端发出音频通话请求。在接收端支持多端通话的情况下，可以同时接受两个用户的音频通话，从而形成三端通话的场景。另外，音视频通话过程中，发起端和接收端均可以发送和接收音视频流，同时均可能会发送和接收信令。

另外，本申请实施例提供的音视频通话方法可以应用于手机、平板电脑和可穿戴设备等具有音视频通话功能终端设备上，此时终端设备即为本申请实施例提供的音视频通话方法的执行主体。本申请实施例对终端设备的具体类型不作任何限制。具体可根据实际应用场景确定。

为了说明本申请所述的技术方案，下面以音视频通话发起端和接收端均是单个终端设备为例，通过具体实施例来进行说明。可以理解地，当具有多个发起端或接收端时，本申请实施例亦可以适用。

另外，本申请实施例针对的是发起端和接收端已建立起了音视频通话的场景。因此以下本申请实施例的各步操作，均是发起端和接收端在进行音视频通话过程中的相关操作。对于建立音视频通话的方法，本申请实施例不做过多限定，可由技术人员根据实际需求设定。

图2示出了本申请实施例一提供的音视频通话方法的实现流程图，其中第一终端设备和第二终端设备可以构成一个音视频通话系统，详述如下：

S101，在音视频通话的过程中，第一终端设备生成流媒体数据和信令，并将信令注入流媒体数据中。

其中，第一终端设备是音视频通话过程中，需要发送信令的一端。因此理论上可以是音视频通话中任一终端设备，既可以是发起端也可以是接收端，具体可根据实际场景确定。流媒体数据即音视频流，具体是音频流还是视频流，需根据实际场景确定。例如，当发起端和接收端是进行音频通话时，流媒体数据可以是音频流，而当是视频通话的时候，流媒体数据则可以是视频流。

实际应用中有许多需要使用信令的场景。包括但不限于以下几种可能的场景：

场景1：在视频通话的过程中，某一侧终端设备需要共享屏幕给其他侧终端设备。此时该侧终端设备可以生成一个请求共享屏幕的信令并发送给其他侧终端设备，以请求共享自身屏幕内容。

场景2：在场景1中，当某一侧终端设备已经在共享屏幕内容。在此基础上，该侧终端设备可能需要进行一些隐私操作，例如输入密码、查看信息或者隐私消息通知等。此时若不想将隐私操作共享其他侧终端设备，则需要停止屏幕共享或者清除视频流(清除送给其他侧终端设备的视频流，常用方式黑屏传到其他侧终端设备)。而直接停止屏幕共享或者清除视频流，会使得其他侧终端设备使用者不清楚黑屏原因，以为视频通话故障，进而导致用户体验不佳。因此需要该侧终端设备生成一个用于提示用户当前暂停屏幕共享的信令，并发送给其他侧终端设备。

场景3：在视频通话过程中，某一侧终端设备需要传输一些视频特效，如跟随动画、手势识别和面部识别信息等给其他侧终端设备。此时该侧终端设备需要生成视频特效对应的信令至其他侧终端设备，以使得其他侧终端设备执行信令对应的视频特效。

场景4：在音频通话过程中，某一侧终端设备需要传输一些音频特效，如变声或预设音效播放。此时该侧终端设备可以生成音频特效对应的信令至其他侧终端设备，以使得其他侧终端设备执行信令对应的音频特效。

由上述各个场景的说明可知，实际应用中第一终端设备可能会因为各种场景的需求而生成信令。因此本申请实施例不对第一终端设备生成信令的具体场景进行过多限定，具体可根据实际应用场景确定。对应于不同的场景，信令生成的触发条件和信令种类，均可以存在一定的差异。例如在上述场景1-4中，信令的触发条件可以是：用户触发终端设备中对应的功能，例如屏幕共享功能、暂停屏幕共享功能和视频特效功能。而在另一些可能的场景中，信令的触发条件亦可以是非用户触发的其他条件，例如定时触发任务等。信令种类而言，上述场景1-4中，信令种类分别为屏幕共享、暂停屏幕共享提示、视频特效和音频特性。在此基础上，终端设备再根据实际的场景来生成对应的信令。因此，实际信令种类，亦需要终端设备根据实际应用场景确定。

另外，本申请实施例亦不对信令的格式进行过多限定，可由技术人员根据实际需求设定。例如在一些可选实施例中，可以按照下表1的方式定义信令格式。

表1

参数列表	长度	必选/可选	字段说明
				bodylength	2字节	必选	信令总长度
version	2字节	必选	信令版本号
				opType	1字节	必选	信令类型，用于区分不同的信令
body	自定义	必选	具体信令详细内容

在表1对应的实施例中，信令由bodylength、version、opType和body四部分参数构成。其中bodylength用于记录信令的总长度，以帮助终端设备确定所需解析的信令的总长度。version用于记录信令的版本号。opType用于记录信令的类型，在一些实施例可以预先设置号每种类型信令对应的编号，此时opType只需记录对应的编号记录。例如可以设置通话邀请、屏幕共享、暂停屏幕提示、手势和面部表情的编号分别为：0、1、2、3和4。在此基础上opType只需记录信令类型对应数字即可。body用于记录信令的详细内容说明。

在生成所需信令之后，第一终端设备会将信令注入流媒体数据中，使得流媒体数据可以携带信令。其中，本申请实施例不对具体信令注入方式做过多的限定，可由技术人员自行设定。例如在一些可选实施例中，针对音频通话，可以将信令嵌入至一个或多个语音帧之中。而针对视频通话，可以将信令嵌入至视频流的各个图像帧之中，或者亦可以将信令嵌入至视频流中的语音帧之中。

S102，第一终端设备将注入信令后的流媒体数据发送至第二终端设备。

在完成对音视频流的信令注入之后，第一终端会利用媒体传输通道将音视频流传输至音视频通话的对端设备(即第二终端设备)。本申请实施例不对媒体传输通道实现的方式做过多限定，可由技术人员根据实际设定。例如可以是基于TCP实现，亦可以是基于点对点技术(peer-to-peer，P2P)传输协议或实时传输协议(Real-time Transport Protocol，RTP)等其他技术实现。

另外应当说明地，在音视频通话的终端设备数量大于3的场景中，即第一终端设备有多个对端设备时。S102中可以包含对第二终端设备的选取过程。此时第二终端设备可以是部分对端设备，如单台对端设备或者多台对端设备，亦可以是所有对端设备。具体对第二终端设备的选取方法此处不做过多限定，需根据实际应用场景确定。例如在一些可选实施例中，可以根据第一终端设备用户的操作，来确定出信令所需发送的各个第二终端设备。此时对第二终端设备的选取，是由第一终端设备用户的操作确定的。

S103，第二终端设备在接收到流媒体数据之后，从流媒体数据中提取出信令，并对信令进行处理。

第二终端设备在接收到音视频流之后，会从音视频流中提取出信令。其中，本申请实施例信令的提取方法做过多限定，可由技术人员根据对信令的注入方法来设定对应的提取方法。

另外，应当特别说明地，考虑到实际应用中音视频流往往都会先进行编码再发送给第二终端设备。相应的，第二终端设备会先对音视频流进行解码，才能进行播放。因此在实际应用中，对信令的注入和提取，与音视频流的编码和解码之间可以存在顺序差异。例如在一些可选实施例中，可以先将信令注入音视频流之中，再对注入信令后的音视频流进行编码和传输。此时第二终端设备则需要先对接收到的音视频流进行解码，才能提取出信令数据。而在另一些可选实施例中，亦可以先对音视频流进行编码，再将信令注入至已编码的音视频流之中。此时第二终端设备可以先从接收到的音视频流中提取出信令，再对提取信令后的音视频流进行解码。具体可由技术人员根据实际需求来设定所使用的方案。

在提取出信令之后，第二终端设备会对信令进行处理，具体包括：解析信令，确定出信令具体的内容，再根据信令内容执行信令。考虑到对音视频流的播放可能会受到信令的影响。因此在本申请实施例中，会先处理信令，再播放音视频流。其中，若信令对当前音视频流的播放有所影响，如视频特效和变声。则按照信令具体情况来处理对音视频流的播放，如在播放视频流的同时，播放视频特效，或者将音频流进行变声播放。反之若对当前音视频流的播放没有影响，例如信令是一些业务请求，如屏幕共享请求。此时则可以对信令进行响应，并同步播放音视频流。

作为本申请的一个可选实施例，针对第一终端设备发送的是一些需要进行响应的信令的情况，如业务请求。此时第二终端设备需要进行响应。因此在S103之后，本申请实施例还包括：

第二终端设备生成针对信令的响应消息，并将响应消息注入至流媒体数据之中，再将注入有响应消息的流媒体数据发送至第一终端设备。其中，响应消息又可称为应答信令，用于告知第一终端设备，第二终端设备已经成功处理第一终端设备发送的信令。

在本申请实施例中，第二终端设备需要对第一终端设备发送的信令进行响应，因此会生成针对信令的响应消息。而为了降低响应消息传输时延，实现对信令的实时响应。本申请实施例中第二终端设备会将响应信息注入至通话过程中所需发送的流媒体数据内，并随着流媒体数据一并发送至第一终端设备。其中，具体的响应消息注入方法，以及第一终端设备对响应消息的提取方法。可参考S101和S103中对信令的注入和提取说明。响应消息实际也是信令的一种，此时信令的注入操作是由第二终端设备执行，而信令的提取操作则是由第一终端设备执行。

在本申请实施例中，摒弃了双通道传输的方案，采用单通道来传输音视频流和信令。当某一侧终端设备需要传输信令时，首先会将信令注入至音视频流之中，再将注入有信令的音视频流传输至对端设备。对端设备则在接收到音视频流时，先从中提取出信令，再处理提取出的信令和音视频流。相对双通道传输的方案而言，本申请实施例一方面可以摒弃原有信令通道，从而减少了对信令通道资源的占用。另一方面，通过复用媒体传输通道并在音视频流中注入信令，避免了信令传输滞后的情况，使得信令与音视频流可以同步传输，提高了信令的实时性。因此本申请实施例可以有效提升音视频通话的质量。

为了便于理解图2所示实施例，以下通过具体场景为例，来对图2所示实施例进行实例说明：

一、对应于上述场景2，在本场景中：第一终端设备与第二终端设备处于视频通话过程中，且第一终端设备正在共享屏幕给第二终端设备。此时第一终端设备的用户需要在屏幕中进行一些隐私操作，例如输入密码、查看信息或者隐私消息通知等。且用户不想将隐私操作共享其他侧终端设备。

在本场景之中，第一终端设备需要暂停屏幕共享，如清除视频流(此时第二终端设备会显示第一终端设备的共享屏幕为黑屏)。因此需要给第二终端设备发送实时性较高的用户提示。以告知第二终端设备用户，当前黑屏原因。

参考图3，在本申请实施例中，第一终端设备与第二终端设备之间的视频通话流程如下：

S200，第一终端设备将屏幕内容以视频流的方式共享至第二终端设备。

在第一终端设备和第二终端设备进行视频通话的基础上，第一终端设备可以将自身屏幕内容以视频流的方式共享至第二终端设备。在此基础上，第二终端设备用户可以在第二终端设备中看到第一终端设备的屏幕内容。第一终端设备用户亦可以选择暂停屏幕共享或者停止屏幕共享。

S201，响应于第一触发操作，第一终端设备生成第一触发操作关联的信令，并将信令注入视频流之中。信令中携带有用户提示信息，用户提示信息用于告知第二终端设备黑屏原因。

在本申请实施例中，第一终端设备会为用户提供一个暂停屏幕共享功能。用户在需要进行一些隐私操作时可以使用该功能。其中，第一触发操作，是指对暂停屏幕共享功能的触发操作，以启用该功能。在检测到第一触发操作，即该功能被启用时，一方面，第一终端设备会清除视频流，并生成由黑屏画面组成的视频流。另一方面，第一终端设备会生成一个携带有用户提示信息的信令。其中，用户提示信息用于告知第二终端设备的用户，此次黑屏的原因。在此基础上，本申请实施例不对用户提示信息包含的具体信息内容进行过多限定，可由技术人员根据实际需求设定。例如可以是“当前屏幕共享被暂停，请稍后”，或者是“屏幕共享已暂停，请稍后”。

在得到所需传输的视频流和信令之后，第一终端设备会将信令注入至视频流之中，以方便通过媒体传输通道传输。其中，具体的信令注入方法此处不予限定，可由技术人员根据实际设定，亦可以参考S101中信令注入的相关说明。

在用户对第一终端设备进行第一触发操作，使得暂停屏幕共享功能被启用后。用户可以正常在第一终端设备中进行所需的隐私操作，而无需担心隐私操作内容被共享至第二终端设备。

S202，第一终端设备将注入有信令的视频流发送至第二终端设备。

在完成对信令的注入之后，第一终端设备会利用媒体传输通道，将注入有信令的视频流发送至第二终端设备。

S203，第二终端设备在接收到视频流后，从视频流中提取出信令，并对信令进行解析，提取出信令携带的用户提示信息。

第二终端设备在接收到视频流之后，会从视频流之中提取出信令，再进行信令解析，从而得到信令中实际携带的用户提示信息内容。其中，信令提取的方法此处不予限定，可由技术人员自行设定，或者亦可参考S103的相关说明。

S204，第二终端设备对视频流进行播放，并将用户提示信息进行显示。

在解析出用户提示信息之后，第二终端设备一方面会对视频流进行播放，此时视频流播放的黑屏画面。另一方面还会将用户提示信息显示于屏幕。因此用户在第二终端设备的屏幕中看到黑屏的同时，还可以看到对应的用户提示信息，获知当前黑屏的原因。

S205，第二终端设备生成针对信令的响应消息，并将响应消息注入至视频流之中，再将注入有响应消息的视频流发送至第一终端设备。

其中，响应消息用于告知第一终端设备，第二终端设备当前已执行信令相关操作，即在第二终端设备屏幕中显示了用户提示信息。在本申请实施例中，第二终端设备还会及时向第一终端设备返回针对信令的响应消息，从而实现对第一终端设备的实时回复。

在本申请实施例中，第一终端设备通过将携带有用户提示信息的信令注入至由黑屏画面组成的视频流，并通过媒体传输通道将视频流发送至第二终端设备的方式，实现对信令的传输。第二终端设备在接收到视频流时先提取出信令，并解析出信令携带的用户提示信息。最后将视频流和用户提示信息均进行显示。从而使得第二终端设备用户可以在看到黑屏的同时，查看到用户提示信息，获知黑屏原因。相对于双通道传输方案而言，本申请实施例避免了信令传输滞后的情况，使得信令与视频流可以同步传输，提高了信令的实时性。因此本申请实施例不会出现第二终端设备黑屏了，用户却无法获知黑屏原因的情况，使得用户体验更佳。

二、对应于上述场景3，在本场景中：第一终端设备与第二终端设备处于视频通话过程中。且第一终端设备用户想使用视频特效给第二终端设备，以使得第二终端设备可以在视频同时看到一些视频特效。

参考图4，在本申请实施例中，第一终端设备与第二终端设备之间的视频通话流程如下：

S301，响应于第二触发操作，第一终端设备确定第二触发操作指向的视频特效类型，生成携带有视频特效类型的信令，并将信令注入视频流之中。

在本申请实施例中，第一终端设备会为用户提供一个视频特效功能。在视频通话的过程中，用户可以根据需求使用该功能。其中，第二触发操作是指对视频特效功能的触发操作，以启动视频特效功能并选择所需使用的视频特效类型。本申请实施例不对视频特效类型做过多限定，可根据实际应用场景确定。例如在一些可选实施例中，视频特效类型包括但不限于跟随动画、手势识别和面部识别信息。其中，具体的信令注入方法此处不予限定，可由技术人员根据实际设定，亦可以参考S101中信令注入的相关说明。

S302，第一终端设备将注入有信令的视频流发送至第二终端设备。

在完成对信令的注入之后，第一终端设备会利用媒体传输通道，将注入有信令的视频流发送至第二终端设备。

S303，第二终端设备在接收到视频流后，从视频流中提取出信令，并对信令进行解析，确定出视频特效类型。

第二终端设备在接收到视频流之后，会从视频流之中提取出信令，再进行信令解析，从而得到信令中实际携带的视频特效类型。其中，信令提取的方法此处不予限定，可由技术人员自行设定，或者亦可参考S103的相关说明。

S304，第二终端设备对视频流进行播放，并根据视频特效类型，对播放的视频流添加视频特效。

在解析出视频特效类型之后，第二终端设备会播放视频流，并对播放的视频流添加相应的视频流特效。例如对视频流添加跟随动画、手势识别或面部识别等视频特效。

S305，第二终端设备生成针对信令的响应消息，并将响应消息注入至视频流之中，再将注入有响应消息的视频流发送至第一终端设备。

其中，响应消息用于告知第一终端设备，第二终端设备当前已执行信令相关操作，即在第二终端设备屏幕中对播放的视频流添加了视频特效。在本申请实施例中，第二终端设备还会及时向第一终端设备返回针对信令的响应消息，从而实现对第一终端设备的实时回复。

在本申请实施例中，第一终端设备通过将携带有视频特效类型的信令注入至视频流，并通过媒体传输通道将视频流发送至第二终端设备的方式，实现对信令的传输。第二终端设备在接收到视频流时先提取出信令，并解析出信令携带的视频特效类型。最后在播放视频流的同时，为视频流添加相应的视频特效。相对双通道传输方案而言，本申请实施例避免了信令传输滞后的情况，使得信令与视频流可以同步传输，提高了信令的实时性。即使面对视频特效这种实时性要求较高场景，本申请实施例也可以有效满足信令的实时性需求。

关于图2至图4所示实施例的相关说明：

一、一种具体的信令注入方法。

为了实现对视频通话过程中的信令有效注入，针对图2至图4所示实施例，本申请实施例提供了一种具体的信令注入方法，可以实现图2至图4所示实施例中的信令注入(此时流媒体数据为视频流)。在本申请实施例中，针对视频通话采用H.264标准进行视频流编码，并将信令注入至视频流的I帧之中。

为了便于理解，此处先对H.264标准、I帧、B帧、P帧以及其他相关概念进行简要介绍：

H.264是国际标准化组织和国际电信联盟共同提出的继MPEG4之后的新一代数字视频压缩格式标准。H.264是ITU-T以H.26x系列为名称命名的视频编解码技术标准之一。以高压缩高质量和支持多种网络的流媒体传输著称。H.264通常被称为H.264/AVC(亦可以称为AVC/H.264、H.264/MPEG-4AVC或者MPEG-4/H.264AVC)。

可参考图5A，在H.246中定义了三种帧。其中，完整编码的图像帧叫I帧图像(简称I帧)，参考之前的I帧生成的仅包含差异部分编码的图像帧叫P帧图像(简称P帧)，还有一种参考前后的帧编码的图像帧叫B帧图像(简称B帧)。详述如下：

I帧：关键帧也叫I帧，它是帧间压缩编码里的重要帧。它是一个全帧压缩的编码帧，I帧不需要参考其他画面而生成。因此解码时仅用I帧的数据就可重构完整图像。

P帧：前向预测编码帧，解码时需参考其前面的一个I帧或者B帧来生成一张完整的图片。

B帧：双向预测，解码时需参考内插的多个P帧来生成一张完整的图片。

在基于H.264标准对视频流编码时，流程大致如下：

1.图像分组:把视频流中的几帧图像分为一组(亦可称为一个序列)，为防止运动变化差异过大，帧数不宜取多。

2.定义帧:将每组内各帧图像定义为三种类型，即I帧、B帧和P帧。

3.预测帧:以I帧做为基础帧，以I帧预测P帧，再由I帧和P帧预测B帧。最后得到I帧数据与预测的差值信息(即B帧和P帧)，并将得到的各个帧数据封装为网络适配单元(Network Abstract Layer Unit，NALU)，以适应基于包的网络传输或面向包的多路复用环境。因此编码的过程，每帧图像均会有被编码位一个NALU。

实际应用中，NALU由开始码(Start Code)、NALU头(NALU Header)和NALU载荷(NALU Payload)三部分构成。

其中开始码一般为：00 00 00 01，用于将各个NALU相区分开。以一实例进行举例说明，可以参考图5B，是由多个NALU构成的数据组。根据开始码00 00 00 01进行数据划分，可知图5B中包含三个不同的NALU。开始码作为NALU的开始边界和结束边界，解码时使用开始码逐个字节匹配数据流，计算NALU的长度，然后开始解码。

NALU头用来标识后面的NALU载荷是什么类型的数据，他是否会被其他帧参考以及网络传输是否有错误。

NALU头由一个字节(8个二进制位)组成，格式如下：

|0|1|2|3|4|5|6|7|。

其中：第一个二进制位|0|用于存储参数F(forbidden_zero_bit)，F的值在H.264标准中声明值设置为1表示语法违例。

第二个和第三个二进制位|1|2|，用于存储参数NRI(又称nal_ref_idc)，NRI的值表示NALU的优先级。NRI取值越大，NALU优先级越高。

第四个至第八个二进制位|3|4|5|6|7|用于存储参数Type(即类型参数，又称nal_unit_type)，Type的值表示NALU的类型。由5个二进制位组合可以得到00000至11111共32个值，因此Type共有32种不同的值。当换算为十进制时，则有0至31共32个不同的值。

Type值(以十进制为例进行说明，其他进制对应关系也相同)与NALU类型的对应关系如下：

0：未使用；

1：非IDR图像的片，不分区；

2：片分区A；

3：片分区B；

4：片分区C；

5：IDR图像中的片；

6：补充增强信息单元；

7：序列参数集；

8：图像参数集；

9：分界符；

10：序列结束符；

11：码流结束符；

12：填充数据；

13-23：保留；

24-31：未使用。

NALU载荷则为具体的帧数据内容。

由上述说明可知，在视频通话过程中若采用H.264标准进行编码，相较于B帧和P帧，I帧可以保留完整的画面信息，重要性更高。实际应用中为了保障视频通话质量，往往会采用更多的资源和技术(例如抗丢包和去冗余等技术)来保障I帧可以稳定可靠的传输。从而使得实际应用中I帧传输的稳定性和可靠性，往往高于B帧和P帧。基于这一原理，本申请实施例选择将信令注入至I帧之中，以使得信令的传输可以更为稳定可靠。参考图5C，是本申请实施例提供的信令注入方法结合图2所示实施例之后，得到的音视频通话方法的流程示意图，详述如下：

在S101之中，将信令注入流媒体数据中的操作，包括：

第一终端设备对视频流进行编码，得到各帧图像的NALU。

第一终端设备选取出一个I帧的NALU，将该NALU的NALU头中的类型参数赋值为第一参数值，并将信令写入至该NALU的NALU载荷之中。其中，第一参数值为13-31中的任一整数值。在一些可选实施例中，第一参数值亦可以是0。

在本申请实施例中，会将信令嵌入至I帧的NALU载荷之中，从而实现对信令的注入。其中，为了将注入有信令的NALU与其他的NALU区分开来，以使得第二终端设备后续可以准确找出包含信令的NALU。本申请实施例会由技术人员预先设置一个用于标记当前NALU具有信令的第一参数值(亦可称为信令标志位)。此时第一参数值代表该NALU既是I帧的NALU，又包含信令。考虑到实际应用中类型参数nal_unit_type，其值1-12均已被使用，具有特定的含义。因此在本申请实施例中，第一参数值选用了13-31中的值。例如可以将31设为第一参数值。

在设置好第一参数值的基础上，当需要进行信令注入时，第一终端设备会从编码后的视频流数据之中，选取出一个I帧的NALU作为注入对象。其中，本申请实施例不对具体的选取方法进行过多限定，可由技术人员根据实际需求设定。例如在一些可选实施例之中，可以将距离信令生成时间最近，且还没有发送出去的I帧作为注入对象。此时第一终端设备会在生成信令后，将最新生成的I帧的NALU选取出来。

在选取出作为注入对象的NALU之后，一方面，第一终端设备会将信令写入至该NALU的NALU载荷内的预设位置之中。另一方面，还会将NALU头中的类型参数nal_unit_type(即NALU头的第四个至第八个二进制位)的值，设置为第一参数值。例如假设第一参数值为31，此时类型参数即会被设置为二进制的11111。其中，本申请实施例不对信令在NALU载荷内的具体位置做过多限定，可由技术人员根据实际需求设定。例如可以设置为将NALU载荷的前n位或后n位作为信令的写入位置，亦可以将从NALU载荷内的第m位开始的n位作为信令的写入位置。其中，n的值可由技术人员根据信令实际情况设定，m的值则可以由技术人员自行设定。此处不做过多限定。

相应的，在S103中，从流媒体数据中提取出信令的操作，包括：

第二终端设备对视频流的各个NALU的NALU头进行识别，确定出NALU头中类型参数的值为第一参数值的NALU，并从该NALU的NALU载荷中提取出信令。

第二终端设备理论上难以预知哪个NALU中会包含信令。因此在接收到视频流时，会对视频流中各个NALU的NALU头进行识别，判断NALU头中的类型参数nal_unit_type的值是否为第一参数值。当某个NALU的NALU头中，类型参数的值为第一参数值，说明该NALU是I帧的NALU且包含信令。因此在识别出NALU头中类型参数的值为第一参数值的NALU时，第二终端设备会从该NALU的NALU载荷中提取出信令，从而实现对信令的提取。其中，对的NALU载荷中信令的提取操作，是将信令写入至的NALU载荷中的反向操作。即从该NALU的NALU载荷内的预设位置之中，提取出信令。在提取出信令之后NALU载荷内包含的数据，即为该I帧实际的帧数据，可用于解码出I帧图像并还原视频流。

在本申请实施例中，第一终端设备通过将信令注入至I帧图像的NALU之中，并将NALU头中的类型参数修改为预设的第一参数值。使得信令可以实现可靠的注入。同时使得第二终端设备可以根据NALU头中的类型参数值，准确定位出包含信令的NALU，并能准确提取出NALU中包含的信令，实现对信令的数据剥离。利用I帧的高稳定性和可靠性来传输信令，本申请实施例具有以下优点：

1、复用媒体传输通道传输信令，摒弃长连接的信令通道，因此可以减少对通道资源的占用。

2、减少信令通道的使用，可以降低终端设备对信令传输的功耗。

3、利用实际应用中I帧稳定可靠传输的特性，可以降低信令传输时，信令丢失的风险。从而提高对信令传输的稳定性和可靠性。

4、信令跟随I帧同步传输，使得信令可以与视频流同步传输，进而使得信令传输的实时性极高。

二、在说明点一中的信令注入方法实施例与图2所示实施例的结合方案的基础上，本申请实施例提供一种可选的视频通话方法实例：

参考图6，是本申请实施例提供的视频通话方法的流程示意图，详述如下：

在音视频通话的过程中，第一终端设备生成视频流及信令。

第一终端设备对视频流进行软件编码或者硬件编码，得到由各个帧图像的NALU组成的编码后的视频流。其中，硬件编码可以是基于芯片实现，而软件编码则可以是基于软件开发工具包(Software Development Kit，SDK)实现。此处不做过多限定。

第一终端设备对编码后的视频流注入信令，即从编码后的视频流选取出一个I帧的NALU，将该NALU的NALU头中的类型参数赋值为第一参数值，并将信令写入至该NALU的NALU载荷之中。

第一终端设备将注入信令后的视频流发送至第二终端设备。其中，发送视频流所使用的媒体传输通道可以是媒体云，该媒体云可以是基于P2P或者基于RTP实现。

第二终端设备在接收到视频流之后，先从视频流中提取出信令。即对视频流的各个NALU的NALU头进行识别，确定出NALU头中类型参数的值为第一参数值的NALU，并从该NALU的NALU载荷中提取出信令。

在提取出信令之后，第二终端设备对提取信令后的视频流进行解码播放，并对信令进行处理。

同时，第二终端设备生成对信令的响应消息并发送给第一终端设备。即将响应消息注入至流媒体数据之中，再将注入有响应消息的流媒体数据发送至第一终端设备。其中，对响应消息的注入方式，亦与第一终端设备对信令的注入方式相同。

关于本申请实施例中各个步骤的实现细节及有益效果，可参考说明点一中的信令注入方法实施例和图2所示实施例中的相关说明，此处不予赘述。

对应于上文实施例所述的音视频通话方法，图7示出了本申请实施例提供的音视频通话装置的结构示意图，为了便于说明，仅示出了与本申请实施例相关的部分。

参照图7，该音视频通话装置包括：

数据生成模块71，用于在与第二终端设备音视频通话的过程中，生成流媒体数据和信令，所述流媒体数据为音频流或视频流；

信令注入模块72，用于将所述信令注入至所述流媒体数据中；

数据发送模块73，用于将注入所述信令后的所述流媒体数据发送至所述第二终端设备，注入所述信令后的所述流媒体数据，用于所述第二终端设备提取和处理所述信令。

作为本申请的一个可选实施例，信令注入模块72，包括：

第一注入子模块，用于在所述流媒体数据为所述音频流时，将所述信令注入至所述音频流的语音帧之中；

第二注入子模块，用于在所述流媒体数据为所述视频流时，将所述信令注入至所述视频流的图像帧之中。

作为本申请的一个可选实施例，所述流媒体数据为视频流，所述信令注入模块72，包括：

编码模块，用于对所述视频流进行编码，得到所述视频流中各帧图像的网络适配单元；

注入模块，用于从得到的网络适配单元中选取出一个I帧图像的网络适配单元，并将该网络适配单元的网络适配单元头中的类型参数赋值为第一参数值，将所述信令写入至该网络适配单元的网络适配单元载荷中。

作为本申请的一个可选实施例，第一参数值为[13，31]中的任一整数。

作为本申请的一个可选实施例，在音视频通话的过程中，所述第一终端设备将自身的屏幕内容以视频流共享至所述第二终端设备；

相应的，数据生成模块71中，生成所述信令的操作，包括：

响应于第一触发操作，生成所述第一触发操作关联的所述信令，所述信令中携带有用户提示信息，所述用户提示信息用于告知用户所述第二终端设备黑屏原因。

作为本申请的一个可选实施例，流媒体数据为视频流，数据生成模块71，包括：

信令生成模块，用于响应于第二触发操作，第一终端设备确定第二触发操作指向的视频特效类型，并生成携带有视频特效类型的信令，携带有视频特效类型的信令，用于第二终端设备根据视频特效类型对播放的视频流添加视频特效。

本申请实施例提供的音视频通话装置中各模块实现各自功能的过程，具体可参考前述图2至图6所示实施例以及其他相关方法实施例的描述，此处不再赘述。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

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

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。还应理解的是，虽然术语“第一”、“第二”等在文本中在一些本申请实施例中用来描述各种元素，但是这些元素不应该受到这些术语的限制。这些术语只是用来将一个元素与另一元素区分开。例如，第一终端设备可以被命名为第二终端设备，并且类似地，第二终端设备可以被命名为第一终端设备，而不背离各种所描述的实施例的范围。第一终端设备和第二终端设备都是终端设备，但是它们不是同一终端设备。因此在本申请的各个实施例中，若未明确说明，则终端设备包含第一终端设备和第二终端设备等。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

本申请实施例提供的音视频通话方法可以应用于手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等可以进行音频通话或者视频通话的终端设备上，本申请实施例对终端设备的具体类型不作任何限制。

例如，所述终端设备可以是蜂窝电话、无绳电话、会话启动协议(SessionInitiationProtocol，SIP)电话、无线本地环路(Wireless Local Loop，WLL)站、个人数字处理(Personal Digital Assistant，PDA)设备、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、车联网终端、电脑、膝上型计算机、手持式通信设备、手持式计算设备、卫星无线设备、用户驻地设备(customer premiseequipment，CPE)和/或用于在无线系统上进行通信的其它设备以及下一代通信系统，例如，5G网络中的终端设备或者未来演进的公共陆地移动网络(Public Land Mobile Network，PLMN)网络中的终端设备等。

作为示例而非限定，当所述终端设备为可穿戴设备时，该可穿戴设备还可以是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称，如眼镜、手套、手表、服饰及鞋等。可穿戴设备即直接穿在身上，或是整合到用户的衣服或配件的一种便携式设备。可穿戴设备不仅仅是一种硬件设备，更是通过软件支持以及数据交互、云端交互来实现强大的功能。广义穿戴式智能设备包括功能全、尺寸大、可不依赖智能手机实现完整或者部分的功能，如智能手表或智能眼镜等，以及只专注于某一类应用功能，需要和其它设备如智能手机配合使用，如各类进行体征监测的智能手环、智能首饰等。

下文以终端设备是电子设备为例，图8示出了电子设备100的结构示意图。其中，终端设备既可以是第一终端设备，也可以是第二终端设备。

电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及SIM卡接口195等。其中传感器模块180可以包括陀螺仪传感器180A，加速度传感器180B，气压传感器180C，磁传感器180D，环境光传感器180E，接近光传感器180G、指纹传感器180H，温度传感器180J，触摸传感器180K(当然，电子设备100还可以包括其它传感器，比如温度传感器，压力传感器、距离传感器、气压传感器、骨传导传感器等，图中未示出)。

可以理解的是，本发明实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(Neural-network Processing Unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

处理器110可以运行本申请实施例提供的音视频通话，以便于提升信令传输的稳定性和可靠性，提升用户的体验。处理器110可以包括不同的器件，比如集成CPU和GPU时，CPU和GPU可以配合执行本申请实施例提供的音视频通话，比如音视频通话中部分算法由CPU执行，另一部分算法由GPU执行，以得到较快的处理效率。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。显示屏194可用于显示由用户输入的信息或提供给用户的信息以及各种图形用户界面(graphical user interface，GUI)。例如，显示屏194可以显示照片、视频、网页、或者文件等。再例如，显示屏194可以显示图形用户界面。其中图形用户界面上包括状态栏、可隐藏的导航栏、时间和天气小组件(widget)、以及应用的图标，例如浏览器图标等。状态栏中包括运营商名称(例如中国移动)、移动网络(例如4G)、时间和剩余电量。导航栏中包括后退(back)键图标、主屏幕(home)键图标和前进键图标。此外，可以理解的是，在一些实施例中，状态栏中还可以包括蓝牙图标、Wi-Fi图标、外接设备图标等。还可以理解的是，在另一些实施例中，图形用户界面中还可以包括Dock栏，Dock栏中可以包括常用的应用图标等。当处理器检测到用户的手指(或触控笔等)针对某一应用图标的触摸事件后，响应于该触摸事件，打开与该应用图标对应的应用的用户界面，并在显示屏194上显示该应用的用户界面。

在本申请实施例中，显示屏194可以是一个一体的柔性显示屏，也可以采用两个刚性屏以及位于两个刚性屏之间的一个柔性屏组成的拼接显示屏。当处理器110运行本申请实施例提供的音视频通话后，处理器110可以控制外接的音频输出设备切换输出的音频信号。

摄像头193(前置摄像头或者后置摄像头，或者一个摄像头既可作为前置摄像头，也可作为后置摄像头)用于捕获静态图像或视频。通常，摄像头193可以包括感光元件比如镜头组和图像传感器，其中，镜头组包括多个透镜(凸透镜或凹透镜)，用于采集待拍摄物体反射的光信号，并将采集的光信号传递给图像传感器。图像传感器根据所述光信号生成待拍摄物体的原始图像。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，应用程序(比如相机应用，微信应用等)的代码等。存储数据区可存储电子设备100使用过程中所创建的数据(比如相机应用采集的图像、视频等)等。

内部存储器121还可以存储本申请实施例提供的音视频通话对应的一个或多个计算机程序。该一个或多个计算机程序被存储在上述存储器121中并被配置为被该一个或多个处理器110执行，该一个或多个计算机程序包括指令，上述指令可以用于执行如图2至图6相应实施例中的各个步骤，该计算机程序可以包括帐号验证模块、优先级比较模块。其中，帐号验证模块，用于对局域网内的其它终端设备的系统认证帐号进行认证；优先级比较模块，可用于比较音频输出请求业务的优先级和音频输出设备当前输出业务的优先级。状态同步模块，可用于将终端设备当前接入的音频输出设备的设备状态同步至其它终端设备，或者将其它设备当前接入的音频输出设备的设备状态同步至本地。当内部存储器121中存储的音视频通话的代码被处理器110运行时，处理器110可以控制终端设备进行信令注入或提取处理。

此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

当然，本申请实施例提供的音视频通话的代码还可以存储在外部存储器中。这种情况下，处理器110可以通过外部存储器接口120运行存储在外部存储器中的音视频通话的代码，处理器110可以控制终端设备进行投屏数据处理。

下面介绍传感器模块180的功能。

触摸传感器180K，也称“触控面板”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于电子设备100的表面，与显示屏194所处的位置不同。

示例性的，电子设备100的显示屏194显示主界面，主界面中包括多个应用(比如相机应用等)的图标。用户通过触摸传感器180K点击主界面中相机应用的图标，触发处理器110启动相机应用，打开摄像头193。显示屏194显示相机应用的界面，例如取景界面。

电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。在本申请实施例中，移动通信模块150还可以用于与其它终端设备进行信息交互，即向其它终端设备发送投屏相关数据，或者移动通信模块150可用于接收投屏请求，并将接收的投屏请求封装成指定格式的消息。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

无线通信模块160可以提供应用在电子设备100上的包括无线局域网(wirelesslocal area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。本申请实施例中，无线通信模块160可以用于接入接入点设备，向其它终端设备发送和接收消息。

另外，电子设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。电子设备100可以接收按键190输入，产生与电子设备100的用户设置以及功能控制有关的键信号输入。电子设备100可以利用马达191产生振动提示(比如来电振动提示)。电子设备100中的指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。电子设备100中的SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和电子设备100的接触和分离。

应理解，在实际应用中，电子设备100可以包括比图8所示的更多或更少的部件，本申请实施例不作限定。图示电子设备100仅是一个范例，并且电子设备100可以具有比图中所示出的更多的或者更少的部件，可以组合两个或更多的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

终端设备(包括第一终端设备和第二终端设备)的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的Android系统为例，示例性说明终端设备的软件结构。图9是本发明实施例的终端设备的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图9所示，应用程序包可以包括电话、相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图9所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

电话管理器用于提供终端设备的通信功能。例如通话状态的管理(包括接通，挂断等)。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，终端设备振动，指示灯闪烁等。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.164，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

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

本申请实施例还提供了一种终端设备，所述终端设备包括至少一个存储器、至少一个处理器以及存储在所述至少一个存储器中并可在所述至少一个处理器上运行的计算机程序，所述处理器执行所述计算机程序时，使所述终端设备实现上述任意各个方法实施例中的步骤。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行时可实现上述各个方法实施例中的步骤。

本申请实施例还提供了一种芯片系统，所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现上述各个方法实施例中的步骤。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读存储介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

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

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

最后应说明的是：以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (16)

1.一种音视频通话方法，其特征在于，应用于第一终端设备，所述方法包括：

在与第二终端设备音视频通话的过程中，生成流媒体数据和信令，所述流媒体数据为音频流或视频流；

将所述信令注入至所述流媒体数据中；

将注入所述信令后的所述流媒体数据发送至所述第二终端设备，注入所述信令后的所述流媒体数据，用于所述第二终端设备提取和处理所述信令。

2.根据权利要求1所述的音视频通话方法，其特征在于，所述将所述信令注入至所述流媒体数据中，包括：

若所述流媒体数据为所述音频流，则将所述信令注入至所述音频流的语音帧之中；

若所述流媒体数据为所述视频流，则将所述信令注入至所述视频流的图像帧之中。

3.根据权利要求1所述的音视频通话方法，其特征在于，所述流媒体数据为视频流，所述将所述信令注入至所述流媒体数据中，包括：

对所述视频流进行编码，得到所述视频流中各帧图像的网络适配单元；

从得到的网络适配单元中选取出一个I帧图像的网络适配单元，并将该网络适配单元的网络适配单元头中的类型参数赋值为第一参数值，将所述信令写入至该网络适配单元的网络适配单元载荷中。

4.根据权利要求3所述的音视频通话方法，其特征在于，第一参数值为[13，31]中的任一整数。

5.根据权利要求1至3任意一项所述的音视频通话方法，其特征在于，在音视频通话的过程中，所述第一终端设备将自身的屏幕内容以视频流共享至所述第二终端设备；

相应的，生成所述信令的操作，包括：

响应于第一触发操作，生成所述第一触发操作关联的所述信令，所述信令中携带有用户提示信息，所述用户提示信息用于告知用户所述第二终端设备黑屏原因。

6.一种音视频通话系统，其特征在于，包括第一终端设备和第二终端设备；

所述第一终端设备在音视频通话过程中，生成流媒体数据和信令，所述流媒体数据为音频流或视频流；

所述第一终端设备将所述信令注入至所述流媒体数据中；

所述第一终端设备将注入所述信令后的所述流媒体数据发送至所述第二终端设备；

所述第二终端设备在接收到注入所述信令后的所述流媒体数据后，从注入所述信令后的所述流媒体数据中提取出所述信令，并对所述信令进行处理。

7.根据权利要求6所述的音视频通话系统，其特征在于，所述将所述信令注入至所述流媒体数据中，包括：

若所述流媒体数据为所述音频流，则将所述信令注入至所述音频流的语音帧之中；

若所述流媒体数据为所述视频流，则将所述信令注入至所述视频流的图像帧之中。

8.根据权利要求6或7所述的音视频通话系统，其特征在于，所述流媒体数据为所述视频流，所述第一终端设备将所述信令注入至所述流媒体数据中，包括：

所述第一终端设备对所述视频流进行编码，得到所述视频流中各帧图像的网络适配单元；

所述第一终端设备从得到的网络适配单元中选取出一个I帧图像的网络适配单元，并将该网络适配单元的网络适配单元头中的类型参数赋值为第一参数值，将所述信令写入至该网络适配单元的网络适配单元载荷中；

相应的，所述第二终端设备从注入所述信令后的所述流媒体数据中提取出所述信令，包括：

所述第二终端设备对所述视频流中各个网络适配单元的网络适配单元头进行识别，确定出网络适配单元头中类型参数的值为所述第一参数值的网络适配单元；

所述第二终端设备从确定出的网络适配单元的网络适配单元载荷中，提取出所述信令。

9.根据权利要求8所述的音视频通话系统，其特征在于，第一参数值为[13，31]中的任一整数。

10.根据权利要求6至9任意一项所述的音视频通话系统，其特征在于，在所述音视频通话的过程中，所述第一终端设备将自身的屏幕内容以视频流共享至所述第二终端设备；

相应的，所述第一终端设备生成所述信令，包括：

响应于第一触发操作，所述第一终端设备生成所述第一触发操作关联的所述信令，所述信令中携带有用户提示信息，所述用户提示信息用于告知用户所述第二终端设备黑屏原因；

相应的，所述第二终端设备对所述信令进行处理，包括：

所述第二终端设备对所述信令进行解析，提取出所述信令中携带的所述用户提示信息，并对所述用户提示信息进行显示。

11.根据权利要求6至9任意一项所述的音视频通话系统，其特征在于，所述流媒体数据为所述视频流，所述第一终端设备生成所述信令，包括：

响应于第二触发操作，所述第一终端设备确定所述第二触发操作指向的视频特效类型，并生成携带有所述视频特效类型的所述信令；

相应的，所述第二终端设备对所述信令进行处理，包括：

所述第二终端设备对所述信令进行解析，确定出所述视频特效类型；

所述第二终端设备在播放所述视频流时，根据所述视频特效类型对播放的所述视频流添加视频特效。

12.一种音视频通话装置，其特征在于，包括：

数据生成模块，用于在与第二终端设备音视频通话的过程中，生成流媒体数据和信令，所述流媒体数据为音频流或视频流；

信令注入模块，用于将所述信令注入至所述流媒体数据中；

数据发送模块，用于将注入所述信令后的所述流媒体数据发送至所述第二终端设备，注入所述信令后的所述流媒体数据，用于所述第二终端设备提取和处理所述信令。

13.根据权利要求12所述的音视频通话装置，其特征在于，所述流媒体数据为视频流，所述信令注入模块，包括：

编码模块，用于对所述视频流进行编码，得到所述视频流中各帧图像的网络适配单元；

注入模块，用于从得到的网络适配单元中选取出一个I帧图像的网络适配单元，并将该网络适配单元的网络适配单元头中的类型参数赋值为第一参数值，将所述信令写入至该网络适配单元的网络适配单元载荷中。

14.一种终端设备，其特征在于，所述终端设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现根据权利要求1至5任一项所述方法的步骤。

15.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现根据权利要求1至5任一项所述方法的步骤。

16.一种芯片系统，其特征在于，所述芯片系统包括处理器，所述处理器与存储器耦合，所述处理器执行存储器中存储的计算机程序，以实现如权利要求1至5任一项所述的音视频通话方法。

Images