天天看點

直播系統開發之推流及拉流概述

拉流(播放):

根據直播系統開發協定類型(如RTMP、RTP、RTSP、HTTP等),與伺服器建立連接配接并接收資料;

解析二進制資料,從中找到相關流資訊;

根據不同的封裝格式(如FLV、TS)解複用(demux);

分别得到已編碼的H.264視訊資料和AAC音頻資料;

使用硬解碼(對應系統的API)或軟解碼(FFMpeg)來解壓音視訊資料;

經過解碼後得到原始的視訊資料(YUV)和音頻資料(AAC);

因為音頻和視訊解碼是分開的,是以我們得把它們同步起來,否則會出現音視訊不同步的現象,比如别人說話會跟口型對不上;

最後把同步的音頻資料送到耳機或外放,視訊資料送到螢幕上顯示。

了解了直播系統開發播放器的播放流程後,我們可以優化以下幾點:

首屏時間優化

從步驟2入手,通過預設解碼器類型,省去探測檔案類型時間;

從步驟5入手,縮小視訊資料探測範圍,同時也意味着減少了需要下載下傳的資料量,特别是在網絡不好的時候,減少下載下傳的資料量能為啟動播放節省大量的時間,當檢測到I幀資料後就立馬傳回并進入解碼環節。

推流:

推流.jpg

經過輸出裝置(AVCaptureVideoDataOutput)得到原始的采樣資料--視訊資料(YUV)和音頻資料(AAC);

使用寫死(對應系統的API)或軟編碼(FFMpeg)來編碼壓縮音視訊資料;

根據不同的封裝格式(如FLV、TS、MPEG-TS);

使用HLS協定的時候加上這一步(HLS分段生成政策及m3u8索引檔案)

通過流上傳到伺服器;

伺服器進行相關協定的分發

推流步驟說明:很容易看出推流跟播放其實是逆向的,具體流程就不多說了。

優化一:适當的Qos(Quality of Service,服務品質)政策。

直播系統開發推流端會根據目前上行網絡情況控制音視訊資料發包和編碼,在網絡較差的情況下,音視訊資料發送不出去,造成資料滞留在本地,這時,會停掉編碼器防止發送資料進一步滞留,同時會根據網絡情況選擇合适的政策控制音視訊發送。

比如網絡很差的情況下,推流端會優先發送音頻資料,保證使用者能聽到聲音,并在一定間隔内發關鍵幀資料,保證使用者在一定時間間隔之後能看到一些畫面的變化。

優化二:合理的關鍵幀配置。

合理控制直播系統開發關鍵幀發送間隔(建議2秒或1秒一個),這樣可以減少後端處理過程,為後端的緩沖區設定更小創造條件。

軟硬編解選擇

網上有不少關于選擇軟解還是硬解的分析文章,這裡也介紹一些經驗,但根本問題是,沒有一個通用方案能最優适配所有作業系統和機型。

推流編碼: 推薦Andorid4.3(API18)或以上使用硬編,以下版本使用軟編;iOS使用全硬編方案;

播放解碼:Andorid、iOS播放器都使用軟解碼方案,經過我們和大量客戶的測試以及總結,雖然犧牲了功耗,但是在部分細節方面表現會較優,且可控性強,相容性也強,出錯情況少,推薦使用。

附軟硬編解碼優缺點對比:

寫死軟編碼優缺點.jpg

采集

采集的步驟:

建立AVCaptureSession

輸入對象AVCaptureDeviceInput

輸出對象AVCaptureVideoDataOutput

輸出代理方法captureOutput(_:didOutputSampleBuffer:fromConnection:)

相關内容

采集資料:iOS平台上采集直播系統開發音視訊資料,需要使用AVFoundation.Framework架構,從captureSession會話的回調中擷取音頻,視訊資料。

傳輸層協定:主要采用RTMP協定居多(預設端口1935,采用TCP協定),也有部分使用HLS協定

音/視訊編碼解碼:FFMpege編碼解碼

視訊編碼格式:H.265、H.264、MPEG-4等,封裝容器有TS、MKV、AVI、MP4等

音頻編碼格式:G.711μ、AAC、Opus等,封裝有MP3、OGG、AAC等

渲染工具:采用OpenGL渲染YUV資料,呈現視訊畫面。将PCM送入裝置的硬體資源播放,産生聲音。iOS播放流式音頻,使用Audio Queue 的方式,即,利用AudioToolbox.Framework 架構。

本文轉自

https://blog.csdn.net/yanceyxin/article/details/82750686?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522160067980719724848356004%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=160067980719724848356004&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_v2~rank_v28-1-82750686.pc_first_rank_v2_rank_v28&utm_term=%E6%8E%A8%E6%B5%81&spm=1018.2118.3001.4187

僅作分享用。

繼續閱讀