流媒体开发入门：实时语音房间开发

背景：公司的游戏实时语音房间使用的腾讯的GVoice，希望自研一套实时语音房间服务，现在做一些技术调研

技术难点:

1. 实时性，最好在300ms以下
2. 网络原因产生的丢包问题
3. 噪声消除、回声消除

初步的解决方案:

对于数据传输，有两种模式可选

1. BS架构：客户端推流到服务端，服务端混流，客户端再拉流
2. P2P架构：参考WebRTC，服务端部署信令服务器，客户端P2P的通话

调研了各家云服务厂的解决方案，大部分都是混合架构，相当于在P2P架构中加入一个特殊的客户端——即BS架构中的服务端。但开发时间有限，需要从BS架构与P2P架构中任选其一。
对于P2P架构，个人不是很自信，参考WebRTC，由于不是每个客户端都会有公网IP，两个客户端的通信中间需要进行NET穿透，ICE协议无法保证一定能找到双方可用的通信地址，因此可能会存在无法建立通信的情况。
并且，P2P架构下，适用范围更窄，基本仅适用于4人以下实时音频房间。
故使用BS架构，BS架构的缺点在于，由于要经过服务端，实时性一定比P2P更差，且服务器维护费用也会比P2P模式高得多。

技术难点的初步解决方案

1. 实时性：使用AAC格式有损压缩音频数据，减小带宽占用。
2. 网络原因产生的丢包问题：初步有三个想法，一是查找下有没有某种补偿算法，二是在每个音频包里携带上一帧的有损压缩信息，三是看有没有可能搞一个补帧模型，现在很多手机自带NPU，应该有本地AI部署能力。
3. 噪声消除、回声消除：现在的手机很多都自带降噪芯片，但对于部分低端机无法保证有这个降噪芯片，需要在先实现一个先看看效果，如果低端机效果很差，可能需要研究研究降噪算法或者降噪模型。

初步实现思路：

1. 客户端方面，开启录音，20ms切个片，做回声消除等，再使用FFmpeg转成AAC后上传
2. 服务端使用FFmpeg，拿到音频切片后混合各个客户端的音频
   流媒体通信协议方面，调研后发现Android大部分使用RTSP，IOS不开放底层协议，只能用HLS协议，因此服务端也需要做两份协议的支持。

个人对流媒体开发目前并不熟悉，赶鸭子上架，若有错误的地方请评论指正