解碼器收到一個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。