解码器收到一个RTP的AAC流，发现RTP流里的音频里带有4个字节AU头，然后才是AAC的ADTS头。     这种情况之前已经出现过多次，每次我们都告知对方，不要往AAC前面加AU头，解码器不支持。而且在这种一个RTP packet只打一个音频帧的情况，AU头完全没有用啊！     但是发流的同事也很为难，有的地方，你不加AU头，人家解不了。说是标准协议里面要求的。 算了，还是自己动手，在解码器侧，检测AU头，并自动跳过吧！   查阅RFC3640，关于音频AU头信息的使用，一般是这样的：一个packet，包含多个AU。但实际很少有编码器这样打包。

网上很多帖子都说AU头是4个字节，添加方式如下：

1.     packet[0] = 0x00;  
2.     packet[1] = 0x10;  
3.     packet[2] = (len & 0x1fe0) >> 5;  
4.     packet[3] = (len & 0x1f) << 3;  

但是协议具体是怎么规定的呢？

但是在RFC3640中，并没有发现AU头的具体定义，只找到下面两幅图

继续看文档，发现关于AU头的格式，并没有协议描述其刚好是13bit来定义帧长度，具体的长度实际还是要看sdp文件 下面的两个截图，分别是13bit和6bit的。 每个RTP包的载荷，最前面2个字节一般是0x00 0x10，这是 AU-headers-length，表示AU header的长度是16个比特也就是2个字节。后面2个字节，高13位是AAC帧的长度，低3位为0。     格式不固定，那么我们就没有办法检测判断AU头是否存在，然后跳过了。 算了，还是先按照一个AU头4个字节来处理，sizeLength为13。