手撕Rtmp协议细节（10）——audio

前面我们历经千难万险和重重障碍，接下来，我们音视频通信的二位主角终于要粉墨登场了，那就是音频君和视频君，这一篇我们来一睹音频君的风采。老样子，抓包文件先摆上来：

说明：

rtmp协议wireshark中过滤音频数据包的条件为：

rtmpt.header.typeid == 0x08

通过抓包文件，我们看到音频数据也是按照RTMP Header + Rtmp Body的组织结构来进行封装的。Header部分之前的文章解析过，我们主要来看Body部分。因为rtmp是Adobe公司开发的协议，所以对自己东西当然是青睐有加，音频的数据的Body部分正是按照FLV的格式进行组装的。而Flv的封装以tag为单位来进行组织，对于音频数据，包含tagHeader + tagData，tagHeader占用一个字节，表明音频编码的相关参数，tagData为具体的音频编码数据。

我们基于前述的抓包文件来进行进一步分析：

小的红色框中的数据即为audioTag的header，此处值为0xaf。接下来，我们就看下flv中audioTag的Header是如何组织的：

如图示：

tag占用1个字节，我们从高到低，依次来看：

• 音频编码格式：

高4比特，用于表示音频编码格式，具体可选值如下：

• 音频采样率：

在之后的2个bit，表示音频采样率，可选值如下：

• 位深：

之后的1个bit表示采样位深度，可选值为0，1，0表示8比特深度，1表示16比特深度。

• 声道：

之后的1个bit表示声道数的参数，可选值为0，1，0表示sndMono，1表示sndStereo。

好了，熟悉完这个组织格式以后，我们来看抓包中的例子，rtmp Body中的数据是audio类型，audio类型的第一个字节表示header，其值为0xaf=0x10101111，将二进制隔开为4段：

0x1010=100x11=30x1=10x1=1

我们可以得出，该音频书包的编码格式为AAC，采样率为44KHz，位深度为16bit，声道模式为strereo。实际上wireshark也对此有所体现，如下图：

好了，audioTag的header我们终于认清楚他了，在它之后就是具体的经过编码压缩的数据了，本例中就是使用AAC压缩算法编码完成的数据了，播放端需要在使用AAC的解码器解码之后，才可以将其播放。关于AAC的细节，这一篇就不聊了。下一讲，我们来看看rtmp中videoData的神秘面纱！