做了快一年的视频会议部分，现在有时间可以把对音视频的认知总结一下，再次声明所有文章只代表本人对音视频的理解，如果观念不同或者理解错误欢迎批评指正。本人开发了基于android系统的会议客户端以及会议系统的服务器端，以及ios端和MacOSX的音视频会议部分。整个系统并不是基于向webRTC或者FFMPEG等主要框架做集成优化，只是某些工具类使用了webRTC或者FFMPEG的一些方法。
一、音视频会议整体架构
各系统客户端的硬编解码（压缩和解压缩h264/h265 aac） +TCP自定义协议传输+netty转发服务器+各系统客户端播放器(播放缓冲区保质和延迟的取舍)
二、主要模块理解部分
1.各系统客户端的硬编解码
软硬解码：通俗的说一个GPU一个CPU，理论最好使用GPU，本就是做图形图像的事，但是硬编解码我遇到了在一些芯片上颜色不正，例如我之前的mstar公版芯片颜色的默认值和PC电脑上看到的效果颜色会更亮，黑色会更深。如果你有Android系统源码，可以去修改数据库的数值即可，开发修改难度不大，但是要求专门的光学知识的人，一般小规模直接找精品对比。说这么多其实想说用硬编解码，对于app的来说是存在一套代码在同样android系统不同厂家出现差异化色彩的。解决这个问题可以换成软解吗+OpenGL渲染（android和ios的这部分api基本上相同）。所以说软的方案跨平台好，一套FFMPEG可以跑到任何平台，但是我想说如果快速开发多平台使用用现成的框架体系比较适合，但是最好的性能最好是基于不同平台去做改变。我们曾经就在一款芯片上使用ffplay去播放，发现CPU很高出现卡顿不流畅，基于FFMPEG做了很多优化，我们定位每一帧数据的首发时间和播放渲染时间，基于FFMPEG的修改很头痛，研究了RTCP、RTP封包的影响等等，修改协议修改发包频率修改接收和播放缓冲区，后来我换了思路就是基于各个平台做自己的编解码+传输+渲染。因此android端编解码就用MediaCodec，ios和macOSX用VideoToolBox。
2.各系统客户端数据传输
开始我们使用RTSP（RTCP和RTP），我对其理解RTCP就是两边环境实时状态的相互通知，RTP发送和接收想要的数据包。目前我看到的一些demo用的RTSP都比较基础（可能是我看项目看得少）。后来我们自定义协议，本质是是一个用来互通状态，一个传数据，说白了是你需要什么就告知对方你的需要，当异常告知你异常了需要怎么恢复等。遇到的问题本质是基于TCP和UDP封装（TCP和UDP的优缺点我就不说了，一搜一大把），首先TCP/UDP在各平台上会出现什么问题，1）TCP传输在各平台会出现粘包现象，例如发送A之后发送B，接收的时候AB在一起，解决这个问题就是包头加包体。2）UDP发送不一定肯定能接收到，协议本身决定，在有的平台上会出现我发一个很大的包发不出去，例如你这张照片有5M，没发送成功，其本质一次性发送的数据量受MTU控制（各平台设置的不同），我之前改过MacOsx的MTU，可以增大一次性发包数据，但这种做法很傻，其实对于UDP就是分包和组包，要发5M的图片将其分成多个数据发送接收到后再组合。如果多久没收到完整的包，要进行抛包处理，就是将不完整的抛掉，也可以TCP告知对方你异常重传。
其实自定义传输都是服务与怎样让平台的解码器正常解码播放，例如你的解码器告知你少sps和pps错误，你第一时间补充其数据，该重新初始化的重新初始化。其实这块的问题比较好模拟，比如你用android手机自己解码h264时，自己故意少发送sps和pps 、I帧B帧P帧还有整个GOP丢失现象，挨个模拟试试缺少数据会出现什么现象，也就知道怎么去异常恢复了。保证正常的传输和播放后，可以在协议本身加一些安全措施，头部加密，关键音视频信息替换等。具体的不方便细说毕竟我做的是安全会议。
传输协议没使用hls苹果出的，其实前几年我用ios的试过只不过以前的Android将视频分片成.m3u8工具不多，主要是个人时间问题，毕竟当时只是爱好，用ios的实现过，这个本质是将视频分成小段，也就是说你先录制小段，默认的之前是10s这个可以修改，换句话说你最小延迟10s，其实比较适合实时性没那高要求的直播，毕竟可以通俗理解你播放了一个又一个的10s小视频。之后我按着这个思路用json+数据替换ts+.m3u8在一款投影上去试了试，现象没啥印象了。这个只要你的播放器能衔接上就OK。数据封装别用mp4，mp4合成要知道你整个视频合成时长。
3.后台服务端转发
相对我接触java后台时间不长，主要是netty的合包和转发，这部分没啥特别的，主要就是netty的使用和转发，整个服务器集群是自己的主从模式，主服务器分配给从服务器做具体的音视频时间，主服务器获得从服务器资源情况，分配会议音视频资源给从服务器。逻辑业务和普通的没啥区别。在转发音视频数据时将一些异常重发信息做提取，在上传的正常数据做一些关键提取保存到缓存中，会议结束时放掉，例如有时客户端需要sps和pps重新初始化等。
4.各系统客户端收到数据显示
客户端收到数据最理想状态是接收到直接就去显示播放，但是会遇到一些问题：
1）如果播放视频画面网络良好的情况下可以顺畅播放，如果网络波动时就会卡顿。一般会加一个播放缓冲区，其实就是加延迟换流畅度，你的最小缓冲区就类似于上面的HLS的设置的数据大小一个概念。假如你的采集端是fps=25，理想状态下你的接收播放也是fps =25。缓冲区单位时间内播放对应的帧数。在android端注意缓冲区的大小。最好是动态的修改，我的思路是根据收包后发送响应时间给服务端，然后计算出当前的网络环境，动态修改播放缓冲区，将ping和播放缓冲区结合起来用的思路，这个动态修改还可以是更改码率降低清晰度等操作根据业务需求去特定修改。
2）音频在网络波动的时候的处理，如果说音频平均传输需要12kb/s的带宽，你当前是8kb/s甚至更低，那可定是不能正常播放的，这种场景并不多，场景比较多的是某一时刻网速不好，之后又恢复正常，这种的会出现如果你一直顺序直播放，那么就会延迟越来越大，此时需要抛包，也就是缓冲区有两个限制项，一个是最小播放只有满足最小播放才能播放，一个是超出最大数据量抛包。
3）音视频同步问题，其实解决办法很多，例如传输之前合规，也可以在传输前打上标记id，接收到时可以选择合规也可以视频播放视频的音频播放音频的，通过标记id统一处理。我的音视频链路是分开传输的，也可以直接一条链路传输音视频，那么可以忽略音视频同步问题。
三 之后编写部分
之后会重点写写各端上音视频部分，会写一下例子放到github上。也会重点说说遇到的问题情况。例如有的芯片版上同屏IOS数据横竖屏有问题，以及遇到捕获IOS数据的extension的坑等。
