发现一个非常好用的RTC（实时音视频通信）方案，做直播和视频通话都很牛

港控/mmm° 2022-09-15 11:50 258阅读 0赞

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70][]

# 1、HaaS RTC背景介绍 #

HaaS RTC是阿里云IoT联合视频云开发的IoT设备端上的实时通讯服务，主要面向直播，音视频通话等各种场景。HaaS700是我们HaaS家族新推出的多媒体开发板，它运行AliOS Things操作系统（RTOS），集成了Camera，音视频等多媒体能力，目前HaaS700中集成了HaaS RTC音视频对讲方案。

[HaaS RTC（实时音视频通信）总体方案简介][HaaS RTC]

在RTC技术方案中，目前最具代表性的就是WebRTC，WebRTC是 Google 的一个专门针对网页实时通信的标准及开源项目，只提供了基础的前端功能实现，包括编码解码和抖动缓冲等，开发者若要基于 WebRTC 开发商用项目，那么需要自行做服务端实现和部署，信令前后端选型实现部署，以及手机适配等一系列具体工作；在此之外还要在可用性和高质量方面，进行大量的改进和打磨，对自身开发能力的门槛要求非常高。一个专业的 RTC 技术服务系统，需要除了涵盖上述的通信环节外，实际上还需要有解决互联网不稳定性的专用通信网络，以及针对互联网信道的高容忍度的音视频信号处理算法。

从技术角度出发，两个设备之间的通信可以是设备对设备（P2P），也可以是设备-服务端-设备，设备对设备方案看起来是一个很直观的想法，并且还可以节约流量（不需要通过服务器转一道），但是这种模式是有一定局限性的，它更多的是服务一对一的音视频对讲，并且这种设备还不能太低端，在没有服务端介入的情况下，特别是IOT领域，低端设备要做到适应各种场景（抗网络丢包，NetEQ，音频3A等各种算法）的能力是不现实的。而设备-服务端-设备这种模式，可以把一些耗CPU，耗内存的工作放到服务端，能够做到满足各种不同能力的IoT设备用户体验，同时整体技术方案也可以平滑适配当前新兴的直播等领域。在HaaS RTC中，我们采用的是设备-服务端-设备的整体解决方案。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBASGFhU-aKgOacr-ekvuWMug_size_20_color_FFFFFF_t_70_g_se_x_16][]

HaaS RTC技术方案是在视频云基础上搭建的，它主要关注的是如何在低端的IoT设备上打造跨设备，跨系统的音视频方案，在高可靠，低成本的基础上，为千万级别的IoT多媒体设备带来实时通讯能力。目前在HaaS700的开发板上，支持设备和设备对讲，设备和手机对讲以及设备和PC对讲。

HaaS实现 音视频实时通话

## 1.1、设备对设备 ##

这里设备的概念指的是除了手机，平板以及PC类的其他IoT设备, 在现实生活中，我们常见的音视频通话设备有可穿戴手表（儿童手表），公网对讲机以及智能门禁对讲等，音视频通话能力在这些设备中是具备主导属性的，不同的设备场景在产品化过程中的技术要求有很大的不同。比如在儿童手表中，我们需要考虑功耗问题，通过对音视频的编码格式，帧率，软硬件的编解码还有参数的调整，尽可能的降低设备功耗，确保通话时长，同时，还需要保证视频通话的高清晰度和高保真，在视频通话的场景中，由于孩子始终处于移动的状态，4G信号极其容易不稳定，但是家长和小孩需要能够在视频通话的过程中流畅且清晰的进行沟通，这是尤为重要的；而在门禁对讲中，由于设备本身是得到持续供电的，所以功耗问题不需要特别关注，同时国内的可视对讲系统通常应用于大型的住宅小区，很多是上千户，甚至上万户的小区，对联网户数容量及稳定性要求更高，可视对讲系统的主流仍然是采用RS-485总线信号传输，有向数字化发展的趋势，国内采用TCP/IP的户数容量更大的可视对讲系统正在逐渐走向成熟，所以在门禁对讲领域，我们更需要关注高容量，稳定性等问题。HaaS700考虑到了这些场景的需求，在功耗以及稳定性方面都做了大量的优化，可以应用在各种音视频对讲或直播等场景中。

## 1.2、设备对手机 ##

随着互联网以及设备智能化进程加速，设备和手机之间的通信已经越来越常见。比如手表和手机视频通话，直播设备和手机之间的视频直播，智能音箱和手机之间的视频通话等。在这些场景中，设备和手机之间存在比较大的差异，包括屏幕分辨率差异，视频编解码能力差异，CPU运算能力差异，网络带宽差异等等，这些差异决定了在音视频通话整体方案中，需要从技术角度做到各种差异性的屏蔽，比如常见的音视频编解码格式适配，屏幕分辨率适配，网络拥塞控制算法调整发送码率解决网络带宽变化带来的数据传输问题，NetEQ算法解决网络抖动导致的音频播放不平滑问题等等。同时，在不同的场景中，对音视频延迟的要求也不尽相同，比如音视频通话场景延迟要求要高于直播场景，在音视频通话场景中，需要尽可能确保音视频发送端到接收端的时延在1S以内，这对用户体验尤为重要。

## 1.3、设备对PC ##

在移动互联网时代，用户的通信方式更多的转向移动设备，设备和PC之间的通信越来越偏向行业化的趋势发展，特别是近两年直播的兴起以及疫情的影响，加速了各种电商直播，线上教学以及线上会议的普及化，不同于设备对设备以及设备对手机之间的一对一音视频通话场景，电商直播主要是一对N，而线上教学，线上会议更是N对N的关系，这意味这要满足线上会议等场景，我们需要实现N路推流，N路拉流，从技术角度来说，目前已经有比较成熟的技术方案，但对于设备端，主要的挑战是设备性能（CPU，内存带宽等），特别是一些低端的设备，在这种情况下，我们可以把一些性能和内存要求比较高的操作放在服务端，比如N路推流在服务端建立映射，设备端只推一路，N路拉流在服务端进行，合成一路后，再下发到设备端。把这些性能要求比较高的操作转嫁到服务端后，设备端实际上还是一路拉流和一路推流，性能要求和一对一的音视频通话并无区别。在HaaS RTC中，我们打通了设备和PC之间的音视频通话，进一步推进了HaaS设备通信跨系统跨硬件平台的能力，实现真正的三端互通。

# 2、HaaS RTC技术方案 #

HaaS RTC支持在RTOS级别的系统上搭建音视频通话能力，为此，我们做了整体的架构调整和性能优化。区别于Android和Linux系统，RTOS操作系统一般CPU能力弱，内存小，比如HaaS700的CPU是ARM A7单核800Hz, 剩余可用内存24MB左右，这要求我们需要尽可能的减少内存消耗，重构线程模型，比如一些串行或者不是很耗时操作的线程合并，降低简单线程的线程栈空间等，同时，由于RTOS系统是单进程，它的线程调度和Android和Linux有很大的区别，对于需要及时响应的收发数据线程，我们需要显式的提高线程调度优先级，避免出现需要及时响应的线程长时间没有被调度到。除了一些线程调度和线程模型的调整，我们还需要进行业务逻辑上的优化，比如缩减高CPU消耗，低反馈的业务模块，降低CPU消耗，限制业务逻辑队列内存分配增长空间，避免某些业务场景中内存持续增长导致系统奔溃。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBASGFhU-aKgOacr-ekvuWMug_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

在架构层面，为了快速适配不同的系统平台，HaaS RTC打造了系统和驱动统一适配层，包括Camera，Display，渲染，编解码以及系统线程，时钟等，这样的好处是在不同的系统平台上，HaaS RTC核心代码不需要做修改，只需要在适配层做一些简单的底层适配。在适配层之上，包括音视频推流，音视频拉流，视频云SDK以及信令系统模块，其中音视频推流模块主要负责推流通道建立，编码后的音视频数据推送，音视频拉流模块负责拉流通道建立，接收服务端发送的音视频码流，视频云SDK主要负责音视频数据传输，以及适应传输过程中的网络抖动算法实现，包括带宽估计，NetEQ等等，信令系统负责信令的呼叫控制，包括呼叫响应，呼叫接听，呼叫挂断等流程中涉及到的各种信息控制管理，在音视频对讲场景下，它需要和服务端配合，比如双方建立会话过程中，服务端需要查询验证呼叫方和被呼叫方账号信息和设备信息，经过验证后，通知被呼叫方，被呼叫方可以接听或者挂断呼叫，服务端根据被呼叫方的反馈建立会话通道或中止会话流程。RTC Manager是基于音视频推流，音视频拉流以及信令和系统能力之上的RTC管理模块，在推流场景中，它负责音频和视频数据采集，并进行音视频编码，编码器输出的码流传到推流模块并上传到服务端，在拉流场景中，它负责接收音视频推流模块下发的音视频数据，并通过音视频解码器进行解码操作，最终通过播控模块播放音频和视频画面。除此之外，RTC Manager负责向应用层暴露RTC场景的所有能力，应用层通过RTC Manager暴露的接口实现视频通话能力。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBASGFhU-aKgOacr-ekvuWMug_size_20_color_FFFFFF_t_70_g_se_x_16 2][]

HaaS RTC设备端技术方案只是满足了RTOS和Linux设备端上的技术能力支撑，对于一套完整的RTC解决方案，还需要移动端以及强大的服务端能力支撑，移动端需要解决各种手机平台的能力适配，让用户获得一致的用户体验，服务端需要提供大规模实时的音视频推流，拉流能力，能够配合设备端应对网络波动影响带来的丢包，延迟等各种问题。

# 3、性能优化 #

我们常见的RTC场景大部分是基于成熟的系统上，比如IOS，Android以及Windows等等，这些系统一般都具备性能比较高的处理器以及比较大的内存容量，而RTC场景本身对CPU和内存要求也是比较高的（曾经微信视频通话一段时间后，手机烫成暖宝宝的体验还记忆犹新）。对于低端设备，如果要集成RTC能力，需要我们针对RTC场景做大量的性能，内存调优工作。相比于动辄4核CPU，内存2G的Android设备，HaaS700CPU是arm A7单核，频率只有800MHz，并且剩余可用内存不到24MB。

<table> 
 <tbody> 
 <tr> 
 <td> 性能指标 </td> 
 <td> 数据值 </td> 
 </tr> 
 <tr> 
 <td> CPU占用率 </td> 
 <td> 100% </td> 
 </tr> 
 <tr> 
 <td> 内存 </td> 
 <td> 24MB </td> 
 </tr> 
 <tr> 
 <td> 帧率 </td> 
 <td> 10fps </td> 
 </tr> 
 <tr> 
 <td> 分辨率 </td> 
 <td> 320x240 </td> 
 </tr> 
 <tr> 
 <td> 码率 </td> 
 <td> 100K </td> 
 </tr> 
 <tr> 
 <td> 视频延迟 </td> 
 <td> &gt;6S </td> 
 </tr> 
 <tr> 
 <td> 音频延迟 </td> 
 <td> &gt;3S </td> 
 </tr> 
 <tr> 
 <td> 音频3A </td> 
 <td> Enable </td> 
 </tr> 
 </tbody> 
</table>

**HaaS700 RTC性能（优化前）**

在HaaS700上刚bring up RTC时，CPU占用率100%，音视频延迟大于6S，系统正常运行时间不超过1分钟，因为内存快速增加很快就超过24MB，导致系统crash。特别是在弱网情况下，由于数据包发送速率降低，带宽估计模块需要持续运转，这不仅提高了CPU占用率，同时还导致发送队列码流大量堆积，使得内存申请持续增长，整体系统基本处于不可用的状态。所以单纯把Android或Linux这种面向偏高端的设备端系统运行经验照搬到RTOS级别的低端系统上，是不可行的，我们需要线程级别的代码重构，功能模块裁减以及整体的性能和内存优化。

<table> 
 <tbody> 
 <tr> 
 <td> 性能指标 </td> 
 <td> 数据值 </td> 
 </tr> 
 <tr> 
 <td> CPU占用率 </td> 
 <td> 85% </td> 
 </tr> 
 <tr> 
 <td> 内存 </td> 
 <td> 12.5MB </td> 
 </tr> 
 <tr> 
 <td> 帧率 </td> 
 <td> 20fps </td> 
 </tr> 
 <tr> 
 <td> 分辨率 </td> 
 <td> 640x360 </td> 
 </tr> 
 <tr> 
 <td> 码率 </td> 
 <td> 400K </td> 
 </tr> 
 <tr> 
 <td> 视频延迟 </td> 
 <td> &lt;500 MS </td> 
 </tr> 
 <tr> 
 <td> 音频延迟 </td> 
 <td> &lt;250 MS </td> 
 </tr> 
 <tr> 
 <td> 音频3A </td> 
 <td> Enable </td> 
 </tr> 
 </tbody> 
</table>

**HaaS700 RTC性能（优化后）**

为此，在HaaS700上，我们针对视频通话场景做了线程级别的代码重构，并做了大量的性能和内存优化，整体性能和内存要求达到了可产品化水平，同时，在用户体验上，我们对音视频延迟做了进一步的优化，在设备对设备，设备对手机上都可以达到音视频通话场景的产品化水准。

# 4、小结和展望 #

自从智能手机出现以来，音视频通话在现实生活中已经随处可见，目前运用最广泛的莫过于微信，而近两年来新兴业务的蓬勃发展，让RTC技术方案得以渗透到各个领域，比如直播，远程教育，线上会议等等。我们可以预见在不久的将来，RTC技术会有更多的业务形态，特别是需要一些线上线下相结合的领域，值得我们不断挖掘和探索。比如现在很多餐厅提倡透明卫生厨房，顾客可以通过透明玻璃看到厨师炒菜，让顾客更放心。这种方式是否可以有更好的表达？如果我们在餐厅厨房按照一个直播摄像头，顾客在座位上直接扫码就可以观看厨房情况，是否可以达到更好的效果？同时，这种模式是不是可以降低餐厅打造安心厨房的改造成本，更容易复制和推广。

# **开发者支持** #

如需更多技术支持，可加入钉钉开发者群，或者关注微信公众号。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70 1][]

更多技术与解决方案介绍，请访问HaaS官方网站[https://haas.iot.aliyun.com][https_haas.iot.aliyun.com]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70]: /images/20220828/c69c56933edd409d90be780eaca24e45.png
[HaaS RTC]: https://blog.csdn.net/HaaSTech/article/details/118761816
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBASGFhU-aKgOacr-ekvuWMug_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/4ff7042549324c43b0cef3065e3436dd.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBASGFhU-aKgOacr-ekvuWMug_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/6fe9880e6df64306a6232799cdac451f.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBASGFhU-aKgOacr-ekvuWMug_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/8e3265c123d24c1c940c56415d05133a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70 1]: /images/20220828/290fce7e8b49426ebfab1e49f51b886a.png
[https_haas.iot.aliyun.com]: https://haas.iot.aliyun.com/