2.1.3　插件化管理

对于音视频直播客户端来说，我们不但希望它可以处理音频数据、视频数据，而且还希望它可以分享屏幕、播放多媒体文件、共享白板……此外，即使是处理音视频，我们也希望它可以支持多种编解码格式，如音频除了可以支持Opus、AAC外，还可以支持G.711/G.722、iLBC、Speex等，视频除了可以支持H264外，还可以支持H265、VP8、VP9、AVI等，这样它才能应用得更广泛。

实际上，这些音视频编解码器都有各自的优缺点，也有各自适用的范围。比如G.711/G.722主要用于电话系统，音视频直播客户端要想与电话系统对接，就要支持这种编解码格式；Opus主要用于实时通话；AAC主要用于音乐类的应用，如钢琴教学等。我们希望直播客户端能够支持尽可能多的编解码器，这样的直播客户端才足够强大。

如何才能做到这一点呢？最好的设计方案就是实现插件化管理。当需要支持某个功能时，直接编写一个插件放上去即可；当不需要的时候，可以随时将插件拿下来。这样的设计方案灵活、安全、可靠。

为了让直播客户端支持插件化管理，我们对之前的架构图又做了调整，如图2.4所示。从图中可以看到，为了支持插件化管理，我们将原来架构图中的音视频编解码模块换成音视频编解码插件管理模块，而各种音视频编解码器（Opus、AAC、iLBC……）都可以作为一个插件注册到其中。当想使用某种类型的编码器时，可以通过参数进行设定，这样从音视频采集模块采集到的数据就会被送往对应的编码器进行编码；当接收到RTP格式的音视频数据时，又可以根据RTP头中的Payload Type来区分数据，将数据交由对应的解码器进行解码。经这样处理后，音视频直播客户端的功能就更强大了，应用范围也更广了。

图2.4　插件管理直播客户端架构图

这里以音频编解码器为例，简要介绍一下直播客户端增加插件管理前后的区别。客户端在增加插件管理之前，只能使用一种音频编解码器，如Opus。因此，在一场直播活动中，所有参与直播的终端都只能使用同一种音频的编解码器（Opus）。这样看起来好像也不会产生什么问题。不过，假如此时我们想将一路电话语音接入这场直播中（电话语音使用的编解码器为G.711/G.722），那它就无能为力了。而有了插件管理模块情况就不同了，各终端可以根据接收到的音频数据类型调用不同的音频解码器进行解码，从而实现不同编解码器在同一场直播中互通的场景，这就是插件化管理给我们带来的好处。

[1] 关于RTP的相关信息将在第9章中详细介绍。