前面我们历经千难万险和重重障碍,接下来,我们音视频通信的二位主角终于要粉墨登场了,那就是音频君和视频君,这一篇我们来一睹音频君的风采。老样子,抓包文件先摆上来:
说明:
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=10
0x11=3
0x1=1
0x1=1
我们可以得出,该音频书包的编码格式为AAC,采样率为44KHz,位深度为16bit,声道模式为strereo。实际上wireshark也对此有所体现,如下图:
好了,audioTag的header我们终于认清楚他了,在它之后就是具体的经过编码压缩的数据了,本例中就是使用AAC压缩算法编码完成的数据了,播放端需要在使用AAC的解码器解码之后,才可以将其播放。关于AAC的细节,这一篇就不聊了。下一讲,我们来看看rtmp中videoData的神秘面纱!下一期不见不散,朋友们。