基于IMX6嵌入式处理器的音频流媒体服务器的设计与实现

刘 勇

（作者单位：安徽广播电视台）

基于IMX6嵌入式处理器的音频流媒体服务器的设计与实现

刘 勇

（作者单位：安徽广播电视台）

为了解决智能广播发射监控系统中广播信号采集并实时回传问题，本文提出了一种基于IMX6嵌入式处理器的流媒体服务器的解决方案。笔者深入研究了流媒体技术以及传输控制协议，详细分析了流媒体技术，并为本文的设计方案制定了最为先进的流媒体传输策略。本文整合了多种技术模块：音频采集、音频压缩、网络传输，实现了一个完整的音频流媒体采集、压缩到传输的链路。值得注意的是，在音频压缩方面，本文采用先进的AAC音频压缩技术，而在网络传输方面，本文实现了单播和组播两种传输方式。

嵌入式；IMX6；流媒体；组播

广播发射监测技术是广播事业发展过程中的热点技术，是提高工作效率和工作质量的重要技术。。智能广播发射监控系统需要具有以下功能：广播信号采集并实时回传功能、广播发射状态监测功能、环境监测功能、供电远程控制功能与有线无线网络自动接入功能。这其中广播信号采集并实时回传功能是最重要的，而这一功能的实现依赖于先进的流媒体传输技术和先进的嵌入式技术。本文设计并实现了一种基于IMX6嵌入式处理器的音频流媒体解决方案，有效地解决了广播信号采集并实时回传的难题。

1　关键理论研究

1.1流媒体

流媒体［1］技术的定义是：将音频、视频或者其他多媒体文件通过流式传输的方法在网络上播放。［2］不同于早先的先下载后播放的模式，通过流媒体技术播放多媒体文件并不需要预先下载媒体数据，只需要在播放开始时将少量的数据存入缓存区。

流媒体传输的特征是网络数据量大，其特定的传输方式：流式传输，对传输的实时性要求较高，因此与传统的网络传输相比，通过Internet网络传输流媒体数据具有以下特点：①流式传输的实现需要一定的缓存空间；②在流式传输之前，多媒体文件必须经过预处理；③多媒体文件通过流式传输需要适当的传输和控制协议。

1.2RTP/RTCP协议

RTP（Real-time Transport Protocol）实时传输协议是一种专门的网络传输协议。［3］RTP传输协议是建立在UDP协议的基础之上的，只能提供端到端的数据传输，没有提供相应的传输质量保障机制。RTP协议是一种应用层协议，在发送RTP数据包之前需要先通过软件编程对媒体文件数据包进行分组和RTP打包，然后将打包后的RTP数据发送给UDP接口，添加UDP传输信息和IP数据包头，再通过Internet发送至接收端。

实时运输控制协议RTCP（RTP Control Protocol）是RTP协议实际使用过程中不可或缺的一部分。［4］RTCP协议主要是在RFC3550和RFC3551中做出了解释［5］［6］。

RTCP协议的主要功能是：为RTP传输服务质量提供监视与反馈机制，对多媒体数据中不同的媒体流进行同步保证，还可以对多播组中的成员进行标识加以区分。RTCP协议同样是UDP协议的子协议，RTCP分组主要是携带发送端和接收端对传输质量的统计信息报告。

1.3MPEG-4 AAC音频压缩标准

AAC编码算法设计了大量算法模块，使用户可以根据编码质量和实际应用的要求，使用不同模块组合成复杂度不同的AAC编码算法。其中，MPEG-4定义了三种不同复杂度的音频编码框架类型［7］。

（1）主配置框架（Main Profile）：此框架包括了除增益控制模块外的所有模块，其运算复杂度和系统资源的消耗是最高的，但与此同时此种框架也可以提供最好的音质。

（2）低复杂度框架（Low Complexity Profile）：此种算法框架拥有较高的适用性和性价比，比较适用于商业用途，如今最流行的Apple的iTunes音乐库就使用了此种编码框架。

（3）可变采样率框架（Scalable Sampling Rate Profile）：算法复杂度随着带宽的变化而变化，并取消了预测模块，适用于网络带宽变换较大的应用场合。

2　嵌入式音频流媒体服务器的实现

本课题的总体设计方案是采用基于IMX6Q处理器的ARM嵌入式开发平台，设计并且实现嵌入式音频流媒体服务器的软件应用程序。服务器系统分为3个模块：原始音频信号采集模块、音频压缩编码模块、传输发送模块。

2.1原始音频信号采集模块设计

在本系统中，将FM解调信号作为音频输入。声卡则根据用户设置参数对模拟音频进行数字采样，在量化之后便形成了原始音频数据PCM流。对音频采集的控制。ALSA中的Libasound库提供了最高级且方便的编程接口。

数据采集函数：

snd_pcm_mmap_readi （snd_pcm_ t *pcm， void *buffer， snd_pcm_uframes_t size）

此函数具体实现了从声卡中采集数据的任务，音频数据采集以size为一个周期，采集数据存入缓冲区buffer，其中size=n*frames，根据MPEG编码标准，MPEG-1 layer3的音频压缩每帧frames为1 152个样点，而MPEG-4 AAC的音频压缩每帧frames为1 024个样点。待一个采集周期结束后，调用fwrite（）函数将buffer里的数据写入管道缓冲区，等待下一模块的接收。在音频采集模块程序设计中，预留了两个参数设置接口，分别为采样时间和采样频率。

2.2音频压缩编码模块设计

在此模块中，采用MP3以及AAC音频编码技术，以满足各种现实需求。MP3编码技术得益于它的高压缩率和高保真度，已经被广泛应用于各种场合。AAC是一种独立开发的音频编码技术，所以并不与MP3等早期音频编码技术相兼容。当AAC音频的压缩码率达到96 kbps时，它便可以达到CD的音质，并且还支持5声道编码，比MP3更加适合于低码率传输。理论上，同样音质的AAC音频传输时的带宽占用量相较于MP3会降低1/4。为了实现多种音频压缩模式，并且简化代码编写，本文使用添加了Libmp3lame依赖库和Faac依赖库的FFMPEG库。

2.3传输发送模块设计

使用Jrtplib实现RTP传输主要有以下流程。

（1）创建一个RTP传输的实例，以MyRTPSession sess为例，sess为此传输实例的名称。

（2）调用RTPTransmissionParams类提供的SetPort base接口设置RTP会话要使用的本地端口号；调用RTPSessionParams类提供的SetOwnTimestampUnit接口设置时戳单元。时间戳单元的设置关系到之后时间戳增量的设置，如果设置的不恰当则会影响接收端的播放质量。时戳单元需要根据所要传输的媒体数据类型来确定，与媒体数据的时钟频率有关。根据标准规定，MPA数据类型的时钟频率为90000 Hz，则时戳单元就应该被设置为1/90 000。同时还需要调用SetAcceptOwnPackets接口，将其设置为true，使RTP会话被允许接受私人定义的数据类型。

（3）RTP会话创建成功后便可以开始RTP包的传输。首先需要调用RTPSession类提供的AddDestination（）接口添加目的端口及其IP地址，同一个会话中允许添加多个目的端口。待准备工作完成后，就可以通过RTPSession类定义创建的SendPacket（）接口发送RTP数据包了。SendPacket（）是一个重载函数，有很多调用方法，其中最常用的一种是：SendPacket（const void *data，size_t len，uint8_ t pt，bool mark，uint32_t timestampinc）。

其中，data指针指向将要被发送的RTP包，len表示此RTP包的数据长度，pt为RTP负载类型的有效负载号。mark为标志位，取值为0或1，可以使用此标志位判断一帧的开始或结束。

针对不同格式的压缩音频数据，需要对传输时的参数进行修改，在传输MP3音频数据时，需要对负载类型加以定义并设置相关的参数。参照RFC1890标准的定义，应该选用的负载类型为MPA，有效负载号为14，时钟频率则为90 000 Hz，相应的时戳单元则需要设置为1/90 000，计算时间戳增量（以采样率为48 kHz为例）：

时间戳增量=（1152/48000）*（1/90000）=2160

所以参照标准，传输MP3音频数据的发送函数为：

status = sess.SendPacket（buff，pksize，14，true，2160）；

相比于MP3音频的传输，传输AAC压缩音频数据则要复杂很多，在RFC协议中并没有对AAC格式音频定义负载类型，所以再次需要自己定义。参照RFC1890标准，有效负载号段96—127为动态号段，及用户可以根据自身需求进行定义，在此将AAC的有效负载号定义为97，时钟频率设为90 000 Hz，相对应的时戳单元就等于1/90 000，时间戳增量的计算公式为：

时间戳增量=（1024/48000）*（1/90 000）=1920

AAC格式音频的发送函数为：

status= sess.SendPacket（buff，pksize，14，t rue，1920）

此时虽然数据的发送函数已经设计完毕，但是目前从音频压缩模块传输过来的AAC音频是ADTS格式并不能直接进行RTP传输，需要将此种格式的AAC音频转化为可供RTP传输的特殊格式。此步骤分为两步，第一步，去除原AAC音频的7字节长的ADTS头，得到纯音频压缩流。第二步，添加AU头，共4字节，分为AU_HEADER_LENGTH和AU_ HEADER。程序实现如下。

此段程序中，AU_HEADER_LENGTH设置为16，及AU_HEADER的长度为2个字节。AU_HEADER的前13个比特为AAC负载长度。

由于在RTP传输会话中，AAC的负载类型是自己定义的，第三方软件在接收时并不能自动识别音频格式并调用合适的解码器，对此需要通过带外的方式传递载有音频编码信息的SDP文件给第三方播放器（如VLC）。SDP文件的编写规范参照RFC3016、RFC3064标准。［8］［9］

在此，笔者参考各种规范，定义了用来传输AAC媒体流的SDP文件，并且经过实际验证，可以通过VLC播放器打开并实现流媒体接收。

3　音频流媒体服务器系统性能测试

3.1硬件资源占用率测试

笔者通过Linux的TOP命令查看流媒体系统各个程序模块的资源占用率情况（此阶段，使用MP3格式作为测试格式）。进程PID3930为音频采集模块，PID3931为音频编码模块，PID 3932 为传输发送模块。可以看出，CPU占用率最高的为音频编解码模块。其中音频编码模块CPU占用率为44%，而其他模块的CPU占用率都不高于1%。而在内存占用率方面，各模块都不超过0.1%，可见此流媒体系统对硬件内存要求不高。

3.2网络传输性能测试

经过网络分析，笔者得到服务器端的数据发送速率，从在20秒内，发送速率一直维持在120Kbps～135Kbps，发送速率相对稳定。

4　结语

本文采用基于IMX6Q处理器的嵌入式开发板，设计与实现了嵌入式流媒体服务器。整个系统分为3个模块，分别是音频采集模块、音频编码模块、网络传输发送模块。围绕该系统的设计与实现，本文进行了以下的研究工作。

（1）在音频编解码技术上，本文采用了MP3以及AAC两种音频编码技术，可以满足系统在不同环境下的传输要求。其中对AAC压缩编码的支持，是本课题实现的一个亮点。

（2）在流媒体传输技术上，本课题不只实现了一对一的网络传输，同时还可以实现组播模式，实现一对多的网络传输，这是本课题实现的另一个亮点。

但是由于时间有限以及本人能力的不足，整个系统还有许多可以完善的地方。

（1）在硬件层面上，虽然IMX6Q是一种相当先进的微处理器，但是由于其他相关硬件的限制，尚不能完全发挥该处理器的性能。所以在未来的研究中，可以通过自行设计相关技术模块，使其可以成为专业的流媒体服务器系统。

（2）在软件层面上，本文设计的软件系统总体分为3个模块，但是在传输发送模块由于需要添加对多种压缩格式的支持，需要分别编写应用程序，调用比较复杂，所以希望在后续的研究中，将此模块进行整合，简化程序调用方法。