野火音视频高级版的一些知识
音视频高级版提供了强大而又灵活的基础能力，可以二次开发成多种不同的产品形态。如果想要做出功能完备性能最优的的音视频产品，必须对野火的音视频高级版有着较深入的了解。本文就将介绍野火音视频的基础知识和背后的技术实现细节，让您对野火音视频高级版有一定的了解，帮助您更好地开发出自己的音视频产品。
1. 可以实现的产品形态
借助于野火音视频高级版，可以实现1对1的音视频通话、多人的音视频通话、语聊房、会议、实时直播互动、在线课堂（需要第三方白板的支持）等多种产品形态。还有更多的使用场景等待您的挖掘。
2. 四端统一
音视频高级版支持Android/iOS/PC/Web四端（其实PC和Web在音视频方面代码是一样的，严格算是三端），四端接口设计完全一致（可能命名上稍有出入，但基本字面意思一样），可以按照相同的逻辑去实现。因此二开音视频产品时，可以几端一起讨论，互相借鉴，减少总体时间花费和避免踩坑。
3. CallSession和AVEngineKit
这两个对象是野火音视频高级版最重要的了，AVEngineKit是个单例，用来发起/加入会议，还有全局设定。CallSession是一个会议的实体，可以通过这个对象操作当前的会议。接口不多，也比较简单，可以全部看一下接口，通过名字就能知道接口的功能。
4. SFU
野火音视频高级版使用的是SFU架构，音视频服务不做混流，只做转发。这样每个客户端发布自己的音视频流，订阅其他每个人的音视频流，是一种星形结构。音频在客户端播放就自动混流了，视频则可以控制每一路视频的大小和位置。
5. Room（房间）
音视频产品尽管有很多形态，但在音视频服务都用的同一个相同的功能--VideoRoom。相关人员都加入到同一个房间中去，去实现自己的功能。
6. 通话和会议
市面上大部分专业音视频服务提供商都是房间的API接口，原因很简单是因为他们只有音视频服务而没有IM服务（或者是以前没有），这样使用难度就很大，用户需要自己来对接即时通讯系统，只有这样才能达到这边呼出那边显示来电的效果。
野火音视频高级版由于拥有强大的IM能力，从而可以进一步的封装音视频的能力，提供出2类开箱即用的音视频能力。一类是通话类的能力，提供像发起电话、接听电话、挂掉电话这样的接口，可以用来实现通话类应用；另外一类是会议类能力，提供像发起会议，加入会议等接口，可以实现会议，语聊房，在线课堂等。野火的封装大大降低了使用的难度，缺点就是跟IM服务深度的绑定无法分割。
这两类能力的区别就是：通话发起时参与对象确定，参与对象会收到来电通知，其他人不能加入是封闭的；而会议则是建立好房间，等待其他人的加入，知道会议信息的用户都可以加入是开放的。当然也可以修改产品定义，比如群内通话可以让群成员自主加入；比如创建好会议后，然后给目标用户发邀请，目标用户收到邀请后显示全屏的会议邀请界面和来电铃声等。
7. 主播与观众
无论最终产品形态如何，音视频高级版都有主播与观众的概念。上面讲到SFU，客户端发布自己的流，这种角色就是主播（以前也有地方叫做参与者，为了统一以后都叫主播；另外主播也需要拉取其他主播的流）；另外一种角色是自己不发布流，只拉取主播们的流，这种角色叫做观众。在一个十人的视频通话中，所有人都是主播。而在一个大部门的100人的全员会议中，可能只有2名主播，98名观众。合理地设计什么时候主播、什么时候观众是做出高效的会议产品的一个重要因素，甚至有时是必要因素。
8. 信令与流
音视频高级版在运行时有两种服务交互，一种是信令，另外一种是流。流就是WebRTC的音视频流，使用RTP协议实现，从客户端到音视频服务器或者从音视频服务器到客户端单向流动，是UDP协议的，带宽要求高、实时性高，但不用保证Qos。流是无法自动建立起来的，还需要借助与信令才操控流的建立。信令既用于客户端与音视频服务的音视频流的建立，也用于操控音视频服务，比如谁的流转发给谁等等。信令实现在IM服务中，IM服务的音视频信令模块控制着客户端和音视频服务，这也就是为什么音视频高级版需要专业版IM的原因。
9. 音视频的复杂度
假设一个房间中有N个用户，其中有M个主播（也就是有N-M个观众），那么这个房间里就会发布M个流，然后N个人都要拉取M个流，主播不用拉取自己的，总计就是N x M - M。复杂度就是O（M x N）。
信令对流量占用很低，但是会消耗IM服务的计算资源。实际上每一路流的建立的背后都有接近10条以上的信令交互请求，因此当M x N很大时，对IM服务的压力也会相应增大。注意一个主播即使关闭声音和视频，信令的消耗也是不变的。
流则是相反的，对CPU消耗低，但对流量占用大，可以根据音视频高级版的说明计算流量。
为了降低对IM服务和音视频服务的压力，N是总用户数是不能减少的，只能尽量减少M的数量。
10. 大小流
手机屏幕太小，一般多人会议都是有一个大屏用户（焦点用户），其余都是小屏显示。如果小屏显示时拉取同样的流，则会是极大的浪费，因此野火视频高级版支持大小流。
客户端SDK内大小流功能都是默认开启的，但移动端跟Web（包括PC）端实现稍有不同。移动端会自动根据每个人的幕布大小来判断，幕布最大的用户使用大流，其余用户使用小流。Web和PC端则需要UI层来指定是使用大流还是小流。这么设计的原因是因为移动端屏幕比较小，一般都是一个用户大屏其他用户小屏幕。Web和PC则屏幕较大，客户端可以选择所有人都等大小，或者像移动端一样一个大屏的其他小屏。等大小时就可以所有人都是大流，大小屏时则指为大屏指定大流、小屏指定小流。
如果不需要大小流可以关掉，调用AVEngineKit的disableDualStream就可以了。
11. 手动控制视频流
如果主播视频超过一屏，没有显示的主播拉取视频流就是浪费资源的，可以手动控制每个主播的视频流。SDK有个属性autoSwitchVideoType，当值为false时，可以通过setParticipantVideoType方法来控制主播不拉取视频流、拉取视频大流和拉取视频小流。另外还有个属性defaultVideoType是当手动控制流时，一个主播加入时默认的视频类型，建议改成默认为不拉取视频流。这样会议中只拉取当前显示的用户的视频流，当切换界面时需要拉取新显示的用户的视频流，取消不再显示的用户的视频流。另外还可以根据显示屏幕大小来拉取大流或者小流。
12. 视频处理
美颜、虚化背景等功能需要处理视频流，SDK有回调，应用实现回调，可以处理视频Frame。
13. 音视频服务的水平扩展
一台音视频服务支持的总容量是有限的，可以部署多台音视频服务，这样每个会议都会随机分配到某个音视频服务上，因此部署多台音视频服务就可以提高音视频服务的容量。
14. 超级会议
一般情况下会议房间都会落到某一台音视频服务上，如果这个会议的参与者特别多，单台服务器就无法支撑得起，这时就可以使用野火的超级会议功能。超级会议把把所有发布的流转发到所有的音视频服务上，客户端来拉取流时就可以随机从某一台拉取，这样单个会议的容量可以是整个音视频服务集群的容量。
15. audioOnly和advance
创建会议时需要这两个参数，需要注意的是加入此会议的用户audioOnly和advance参数一定要和创建时的参数一致，否则将出现不可预料的错误。
audioOnly参数用来标识此会议是否是仅音频会议。这个参数决定了是否创建视频流（关掉视频也会创建），因此一个纯音频会议要比都关掉视频的视频会议要省资源。但一旦创建就无法切换到视频模式，比如打开屏幕共享等。因此需要根据需求来判断是否是纯音频会议，比如如果产品需求中允许会议中打开摄像头或者开启屏幕共享，就必须使用视频会议开会，可以在加入时关掉视频，然后需要打开时打开。
advance参数标识是否是超级会议。需要保持跟创建时的参数一致。
此外加入会议时还有一个audience参数，audience标识是否以观众身份参加。如果是CallSession中的主持人则会以主播加入。观众与主播可以互相切换。
16. muteVideo和muteAudio
当一个CallSession存在时，任何时刻都可以关掉或打开音频和视频。这也是我们经过多个客户的磨合后得出最合适的方法。当客户端是观众时也可以关闭音频或视频，这样当这个观众切换成主播时，音频和视频就是切换之前设置的状态。
根据前面复杂度可以看出，为了节省资源最好的办法就是减少主播的数量。当一个用户以视频和音频都关掉状态入会时，最好要以观众的身份入会。当一个观众要打开摄像头或者麦克风时，可以设置状态，然后切换成主播。同样当主播摄像头和麦克风都关闭时可以切换成观众然后关闭摄像头和麦克风。目前Demo是主播和观众分开展示的，客户可以根据自己的产品设计来改变。
17. 会议号
会议号的出现的原因是最早做会议产品的公司只有音视频会议产品，没有IM产品。因此一个会议必须要有一个容易传播的短的数字串，便于会议信息通过其他沟通工具进行传递，比如通过邮件、社交工具、电话、甚至是口头传播。后来者纷纷效仿，甚至连某信会议和某钉钉会议也都是这么做的。
我们建议是通过会议邀请消息来传递会议信息。邀请消息内容可以进一步自定义，加入会议的主讲人、会议的议题、会议的材料等。通过邀请信息能够更直观的了解到会议的信息，远比会议号更直观更有效。
如果要用会议号也可以实现，可以在应用服务二次开发加上，当客户端或者server api创建会议时，把所有的信息提交到应用服务，应用服务保存这些信息，然后分配一个会议号。在客户端使用会议号时，先去应用服务获取到会议信息，然后后面就是正常处理了。
18. 会议控制
在音视频服务功能层面，所有的用户都是平等的，比如所有人都可以观众和主播互相切换，所有人都可以把其他人移出会议室，所有人都可以退出或者结束会议。
这就需要UI层来实现所有的会议控制功能。比如谁是主持人，主持人是否可以直接踢人出会议室，主持人是否可以直接打开或者关闭其他人的麦克风或者摄像头，主持人如何转让，观众是否自己有权直接转为主播还是必须经过主持人同步等等。可以通过自定义消息来做主持人和成员的沟通，比如主持人想要关闭用户摄像头，就给该用户发送一条关闭摄像头的自定义消息，该用户收到后关闭摄像头提示用户后关闭摄像头。其他以此类推。
会议的CallSession中有个host属性，本意是为了标识为会议的主持人，其实是没有任何特殊的用途（唯一的作用就是加入会议时会是主播），也具有修改后通知其他人的能力。因此如果需要转移主持人功能，就需要自己来实现会议主持人功能，包括如何识别主持人，如果做支持人转移等功能。
19. Server API
音视频服务除了在客户端操作为，还可以在服务器端用server api来操作。目前支持的API有查询存在的会议、查询会议中的成员、创建会议、销毁会议。
20. 聊天室
可以在会议的同时创建聊天室，在会议的同时可以在聊天室内点赞、发送资料、聊天等。聊天室有个加入时如果不存在就自动创建的功能，可以开启这个功能，这样就不用显式地创建聊天室了，直接加入即可聊天。
21. 录制与回放
关于录制在IM服务有3种配置，0是不录制、1是录制、2是客户端决定是否录制。当客户端决定时，只能在创建会议时指定是否录制，创建会议时有个参数record来决定是否录制，不能在会议进行中改变录制状态。
录制是为每个主播的每个流保存一个文件，一般会保存音频、大流和小流3个文件。录制时先保存为临时文件，等录制完成后保存为mjr格式。文件命名中包含足够多的信息，包含会议ID、主播用户ID，主播开始时间等信息。使用我们提供的工具转为常见的音频文件格式和视频文件格式，最后调用ffmpeg合并成一个文件。音视频处理比较消耗服务器资源，因此不建议在音视频服务处理，可以在会议结束之后把文件传到其它服务器进行处理。
回放时需要根据每个主播的时间做好同步，另外需要合理安排每个主播的画面布局。如果有聊天室，可以根据消息的时间回放聊天内容。