【OSS 排查方案-12 livechannel 直播推流】
摘要：
OSS livechannel 推流過程
生成推流 URL
設定推流狀態
錄製 M3u8 缺失
預設錄製成品的 m3u8 所以只有最後 3 片，遵循的是 hls 協議的預設規則，是正常想象，可以通過呼叫 PostVodPlaylist ...
OSS livechannel 推流過程
錄製 M3u8 缺失
預設錄製成品的 m3u8 所以只有最後 3 片，遵循的是 hls 協議的預設規則，是正常想象，可以通過呼叫 PostVodPlaylist 介面將指定時間範圍內的 ts 檔案匯聚到一個 m3u8 索引內來解決；
tips
-
EndTime必須大於StartTime，且時間跨度不能大於1天。 - OSS會查詢指定時間範圍內的所有該
LiveChannel推流生成的ts檔案，並將其拼裝為一個播放列表。
錄製 m3u8 檔案 失敗
- 先看下是否已經成功推流到來 OSS 才算成功，客戶端抓包必須能看到有 publish succees 的標誌後，和 OSS 有正常的音訊包互動才算成功，所以發現客戶端推流有記錄，但是就是沒有錄製視訊的情況，就需要自己抓包分析下；
錄製 M3u8 檔案卡頓
- 轉儲型別為 HLS 時，寫入當前 ts 檔案的音視訊資料時長達到
FragDuration指定的時長後，OSS 會在收到下一個關鍵幀的時候切換到下一個 ts 檔案；如果max(2*FragDuration, 60s)後仍未收到下一個關鍵幀，OSS 強制切換檔案，此時可能引起播放時卡頓；
錄製 M3u8 檔案沒有音訊或視訊
在此之前沒有 hls 協議基礎，或者對音視訊不懂的同學很難理解，我們先惡補一些關鍵名詞和包結構
RTMP 的音視訊流的封裝形式和 FLV 格式相似, 流媒體伺服器向客戶端傳送包含 H264 和 AAC 的 RTMP 直播流，需要首先發送這兩個 header，沒有這些資訊播放端是無法解碼音視訊流的，其中音訊 tag 格式如下
-
AVCsequence header -
AACsequence header
從上面推論出 AAC sequence header 內容的前 2 個位元組是 0xAF 0x00，我們來看一個示例：
ADIF ：Audio Data Interchange Format 音訊資料交換格式。這種格式的特徵是可以確定的找到這個音訊資料的開始，不需進行在音訊資料流中間開始的解碼，即它的解碼必須在明確定義的開始處進行。故這種格式常用在磁碟檔案中。
ADTS ：Audio Data Transport Stream 音訊資料傳輸流。這種格式的特徵是它是一個有同步字的位元流，解碼可以在這個流中任何位置開始。它的特徵類似於 mp3 資料流格式。
經過知識補充後我們說下以下幾種情況回粗線音訊或者視訊沒有錄製的情況：
-
AVC header或者AAC header沒有傳送，抓包也能看出來。 -
RTMP message長度小於2，或者是sequence header非常小 - 音訊
Message超過緩衝區大小。 -
codec_ ctx攜帶的音視訊資料異常，導致錄製失敗。