從去年末至今年年初错蝴，直播真是火了一把，各個(gè)平臺(tái)都做直播颓芭，YY顷锰，斗魚，映客亡问，天貓官紫，淘寶，脈脈州藕，任意類型的App加上直播后都會(huì)有全新業(yè)務(wù)形式束世，今天就從技術(shù)角度來說說直播客戶端以及主要IJKPlayer的相關(guān)日常。
1. 主要直播鏈路如下:
從技術(shù)選型來說來說床玻，播放端在市面上有很多開源播放器毁涉。
1. 在技術(shù)選擇過程中沒有選用AVFoundation中的AVPlayer，由于AVPlayer在播放直播流m3u8過程中對(duì)延遲的控制不好锈死，而rtmp擁有較小的延遲的優(yōu)點(diǎn)贫堰，然而這里還有坑，后續(xù)會(huì)慢慢道來馅精。
2. 由于先前沒有視頻的技術(shù)儲(chǔ)備严嗜，從而選擇業(yè)內(nèi)成熟的直播方案。
整理了一下市面上的直播方案洲敢，有如下幾種：
| 播放器 | 特點(diǎn) | 類型 |
|---|---|---|
| IJKPlayer | 支持格式多漫玄，社區(qū)活躍高 | 直播，錄播压彭，本地播放 |
| ZFPlayer | AVFoundation系統(tǒng)原生 | 支持錄播視頻睦优，業(yè)務(wù)樣式比較多，可參考 |
| VLC | 完全跨平臺(tái)壮不，但是移植到客戶端上成本較高 | 使用范圍廣汗盘，支持360全景 |
| AVFoundation | 蘋果原生、Airplay原生支持 | 支持HLS直播询一、大部分播放功能 |
經(jīng)過市場分析隐孽，B站癌椿，美拍和斗魚都使用IJKPlayer，經(jīng)歷市場試驗(yàn)菱阵，IJKPlayer較為穩(wěn)定的一款播放器踢俄。經(jīng)過對(duì)比，我們選擇了IJKPlayer這套iOS和Android可以基于同一套C層邏輯的直播方案晴及。
為了業(yè)務(wù)快速上線都办，我們選擇了較為穩(wěn)定ffpmeg2.8版本，期間也踩了不少坑虑稼，比如硬件解碼綠屏的問題琳钉，回放視頻時(shí)間軸不準(zhǔn)確的問題，我們都采用對(duì)應(yīng)的規(guī)避手段蛛倦，避免出現(xiàn)這樣的情況歌懒。
2. 流格式的選擇
RTMP和HLS之間的主要優(yōu)劣對(duì)比如下：
| RTMP | HLS | |
|---|---|---|
| 優(yōu)點(diǎn) | 延遲較短，無需多次建連 | 基于分片文件胰蝠，可以做到無縫切換分辨率歼培，HLS是蘋果推出的，iOS支持的很好 |
| 缺點(diǎn) | 累積延遲茸塞，TCP不會(huì)丟包躲庄，對(duì)于服務(wù)器CPU占比較高 | 延遲高，20s-30s钾虐，不適合互動(dòng)很強(qiáng)的直播噪窘，HLS在建立連接和斷開連接時(shí)候的握手，揮手會(huì)產(chǎn)生消耗 |
既然使用了開源代碼效扫，如果使用HLS還不如直接用AVFoundation來的穩(wěn)定和直接倔监。
正如剛才所說的rtmp雖然可以做到很低的延遲，但是沒有辦法解決累積延遲菌仁，通過多路查找浩习，我們先從官方的issue里面也找到相關(guān)問題，然后從播放器參數(shù)角度上一定程度的優(yōu)化了延遲的情況济丘，當(dāng)然這塊也需要推流端以及流媒體服務(wù)器的配合才能將延遲優(yōu)化做到最好谱秽。
3. 直播中播放器相關(guān)幾個(gè)主要問題
1. 視頻打開速度慢
rtmp直播流打開慢，在avformat_find_stream_info（）摹迷，這個(gè)函數(shù)會(huì)花去主要的時(shí)間疟赊，因?yàn)橐隽鞯姆治霾鸱值龋詢?yōu)化可以重點(diǎn)從這個(gè)函數(shù)入手峡碉。
另一種方法比較極端些近哟，自己實(shí)現(xiàn)這個(gè)函數(shù)的功能。根據(jù)metadata信息鲫寄，手動(dòng)設(shè)置解碼參數(shù)吉执，這個(gè)效果比較明顯疯淫，針對(duì)264+aac的rtmp可以考慮這種優(yōu)化方案。
IJKPlayer相關(guān)的優(yōu)化參數(shù)如下:
| 參數(shù) | 優(yōu)化數(shù)值 | 優(yōu)化點(diǎn) |
|---|---|---|
| max_queue_size | 10 x 1024 x 1024 | 減小預(yù)讀取的閥值戳玫，這樣能更快的打開視頻 |
| probsize | 4096 | 探測帶第一幀后就會(huì)數(shù)據(jù)返回峡竣，如果這個(gè)值設(shè)置過小，會(huì)導(dǎo)致流的信息分析不完整量九，從而導(dǎo)致丟失流，用于秒開 |
2. 開啟硬解碼會(huì)綠屏
綠邊相關(guān)問題颂碧，硬件解碼開啟后荠列，OpenGLES的相關(guān)渲染對(duì)推流過來的尺寸有嚴(yán)格要求，需要2*n,這塊需要和推流端一起配合载城，這樣硬件解碼才能給用戶和手機(jī)帶來更多的好處肌似。
3. 累積延遲
通過排查，RTMP經(jīng)過CDN的這一層會(huì)有4.0到5.0秒的延遲诉瓦，我們在IJKPlayer這一層做了對(duì)應(yīng)的參數(shù)優(yōu)化川队，相關(guān)參數(shù)如下:
| 參數(shù) | 優(yōu)化點(diǎn) |
|---|---|
| skip_loop_filter | Skip loop filtering for selected frames. |
| skip_frame | codec discard all non reference |
優(yōu)化延遲問題,也可以從推流端入手，將編碼器調(diào)低GOP睬澡，譬如1秒一個(gè)GOP固额，這樣延遲也很低，也不用等待煞聪，壞處是編碼器壓縮率會(huì)降低斗躏，圖像質(zhì)量沒有那么好。并且對(duì)服務(wù)端的壓力也很大昔脯。
還有一個(gè)主要原因是ffplay默認(rèn)的幀率控制沒有追幀的策略啄糙，所以網(wǎng)絡(luò)如果發(fā)生抖動(dòng)，延時(shí)會(huì)累加云稚。優(yōu)化策略就是調(diào)整幀率控制部分隧饼。原則就是要在流暢度和實(shí)時(shí)性之間得到一個(gè)平衡。
4. 斷開直播推流后静陈，error回調(diào)較慢
這樣的問題主要出在燕雁，IJKPlayer在播放RTMP中對(duì)應(yīng)的Time-out參數(shù)起作用只有在Http這層，如果使用HLS或者FLV的話的確有用窿给，如果是RTMP的話贵白，Time-out參數(shù)完全和Http中的不是一個(gè)含義,rtmp time-out相關(guān),后續(xù)通過咨詢，error狀態(tài)的回調(diào)取決于服務(wù)端流傳遞的情況崩泡，好的狀態(tài)下30s內(nèi)就可以回調(diào)error禁荒。
2. 總結(jié)
斷斷續(xù)續(xù)說了很多直播中采坑，這只是個(gè)開始角撞，后續(xù)慢慢更新呛伴。更多IJKPlayer內(nèi)容可以直接關(guān)注官方Issue
