作者：張醫博
OSS livechannel 推流過程
案例：錄制 M3u8 缺失
預設錄制成品的 m3u8 是以隻有最後 3 片，遵循的是 hls 協定的預設規則，是正常想象，可以通過調用 PostVodPlaylist 接口将指定時間範圍内的 ts 檔案彙聚到一個 m3u8 索引内來解決；
tips
- EndTime 必須大于 StartTime，且時間跨度不能大于 1 天。
- OSS會查詢指定時間範圍内的所有該 LiveChannel 推流生成的 ts 檔案，并将其拼裝為一個播放清單。
案例：錄制 m3u8 檔案 失敗
- 先看下是否已經成功推流到來 OSS 才算成功，用戶端抓包必須能看到有 publish succees 的标志後，和 OSS 有正常的音頻包互動才算成功，是以發現用戶端推流有記錄，但是就是沒有錄制視訊的情況，就需要自己抓包分析下；
案例：用戶端無法推流到 OSS
ffmpeg -re -i 0_20180525105430445.aac -acodec aac -strict -2 -f flv rtmp://xxx.oss-cn-beijing.aliyuncs.com/live/test_1000?Expires=1540458859&OSSAccessKeyId=LTAlujianb6C9z&Signature=qwh31xQsanmao6ygCFJgovNIg%3D&playlistName=playlist.m3u8
- 使用 ffmpeg 推不上去的時候建議用最原始的指令推流，不要加一些複雜的參數，而且推流 URL 在有 & 符号時請用 "" 囊括起來；
- 嘗試更換成 obs 推流測試下，看是否是 ffmpeg 問題導緻的推流失敗；
案例：錄制 M3u8 檔案卡頓
- 轉儲類型為 HLS 時，寫入目前 ts 檔案的音視訊資料時長達到FragDuration 指定的時長後，OSS 會在收到下一個關鍵幀的時候切換到下一個 ts 檔案；如果 max(2*FragDuration, 60s) 後仍未收到下一個關鍵幀，OSS 強制切換檔案，此時可能引起播放時卡頓；
案例：錄制 M3u8 檔案沒有音頻或視訊
在此之前沒有 hls 協定基礎，或者對音視訊不懂的同學很難了解，我們先惡補一些關鍵名詞和包結構
RTMP 的音視訊流的封裝形式和 FLV 格式相似, 流媒體伺服器向用戶端發送包含 H264 和 AAC 的 RTMP 直播流，需要首先發送這兩個 header，沒有這些資訊播放端是無法解碼音視訊流的，其中音頻 tag 格式如下
- AVC sequence header
- AAC sequence header
【OSS 排查方案-12 livechannel 直播推流】
從上面推論出 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 解碼上下文的關鍵資訊，如果攜帶的音視訊資料異常，也會導緻錄制失敗。
案例：ffmpeg 推流到 OSS 錄制沒有音頻
背景：
想問下，我們使用類似于這樣的指令錄制直播轉推到阿裡雲OSS，錄制下來的視訊沒有聲音
ffmpeg -re -v -1 -loglevel debug -timeout 60000 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 60 -i
http://laochouzhibo.com/live/10456_33832518963510801728548610115630440343599.flv-acodec copy -vcodec copy -f flv rtmp://laochou.oss-cn-beijing-internal.aliyuncs.com/live/6db24fe6307e4cbcbf4f1764f5a1fb86?OSSAccessKeyId=LTAHSFdouboolevJG&Expires=1541002834&Signature=yRPuvIsIe90ipETg%3D
分析：
- 出現這種問題，可以直接看下 ffmpeg 記錄的 log ，可以發現用戶端是沒有發送 aac_header 。
- 或者用戶端抓個 RTMP 的包也可以看到是否發送了 aac_header