在今年Facebook F8大會上,Facebook宣佈了將在Instagram Direct上開放一對一與羣組視頻聊天功能,這種新功能能夠幫助用戶使用實時視頻聊天來相互鏈接,即便是他們沒能相聚在一塊兒。毫無疑問,社交領域的一線平臺開始愈來愈重視實時音視頻技術在社交領域的應用。html
不過,在Instagram正準備增長視頻社交功能以前,咱們國內的某款已上市社交應用,已經基於實時音視頻基礎能力,開始拓展新的玩法了。並且,聽說上線後,馬上成爲用戶們正向體驗的功能,用戶活躍與留存雙破新高。這個新功能就是KTV。咱們也用電腦+手機錄製了一段視頻,你們能夠感覺下這款設計應用中的多人KTV功能(若是你只想聽效果,請空降38秒處)。git
在社交直播中,有人是靠顏值上位,有人則是以優美的聲線取勝,KTV正是爲後者準備的。從上面這個視頻能夠看出,具體功能以下:github
房主創建房間後,開啓KTV功能,上麥;算法
房主在線點歌,歌曲與KTV歌房中常見MV同樣,包括畫面、字幕伴奏;網絡
觀衆能夠申請上麥,進行點歌、演唱;post
上麥的觀衆在演唱時可自主調節伴奏與人聲音量;優化
房主可控制歌曲暫停、切歌。編碼
你可能想問:聽上去就是直播秀場,這有什麼差異麼?其實,二者之間在功能和體驗都存在差異。設計
在功能方面如表格所示,秀場直播主播演唱時,觀衆能夠文字參與評論、互動,也能夠上麥。但觀衆上麥後只能聊天,不能上臺演唱。而一塊兒KTV的伴奏曲庫存放於線上,任何觀衆均可以在線點歌、演唱。orm
從體驗角度講,秀場直播只是主播的我的秀。秀場至關因而主播的「獨樂樂」。而一塊兒KTV更接近線下KTV體驗。每一個人均可以點歌,都有機會演唱,是一種互動體驗的升級。
一塊兒KTV與咱們曾分享過的「賽事直播」場景很像,都是基於實時音視頻技術的基本能力拓展而來的。從表面來看,一塊兒KTV功能很簡單,但其中存在一些難點:
歌曲控制同步
「一塊兒KTV」強調的是要「一塊兒」唱,主播能夠邀請多個聽衆上麥,你方唱罷,我登場,每一個人都有機會站在聚光燈下。
在這個過程當中,「話筒」會按順序傳遞給不一樣連麥觀衆,主播仍然能夠控制歌曲的播放,如切歌、暫停等操做。但若是採用RTMP傳輸,網絡延時較高。那麼網絡狀況較好狀況下,當主播暫停歌曲或切歌后,可能連麥演唱的觀衆在3~4秒後纔會發現,或者歌曲已經開始,下一個演唱者還沒能開唱。若是網絡狀況差,延遲可能會超過10秒。
高音質、高畫質
每一個站上臺演唱的人都想展示本身真正的技術。若是沒法以高質量音質傳輸,無疑會影響用戶體驗。同時,該場景下的MV畫面至關於連麥中的視頻畫面,卡頓、模糊等問題一樣存在。開發者若是但願經過自研實現,須要基於UDP協議進行傳輸,並在邊緣節點的部署、主幹網絡擁塞、弱網傳輸等方面作出優化策略。
如咱們在《詳解音視頻直播中的低延時》中所說,開發者除了要對網絡傳輸進行優化,還須要儘量優化編解碼算法,下降音視頻在端上的延時。
咱們具體研究了該功能的實現方式,開發者們能夠點擊這裏查看詳細開發步驟,或者也能夠經過Github直接獲取 源碼,本身動手嘗試一下。咱們的實現邏輯如上圖所示,具體邏輯是這樣的:
房主開啓「一塊兒KTV」功能後成爲演唱者;
房主端從第三方在線曲庫讀取MV歌曲數據;
觀衆上麥申請被房主經過後,可在線點歌,並開始排麥;
房主的歌聲與MV伴奏在本地通過混音、編碼,基於UDP協議傳輸至Agora SD-RTN™;
而後咱們經過UDP協議將房主K歌歌聲與MV畫面傳輸給觀衆;
輪到播放上麥觀衆所點的歌時,觀衆成爲演唱者,除了沒有歌曲控制權限外,歌曲演唱、混音、編碼、傳輸流程與房主一致。
除實現主要的功能以外,咱們還須要支持傳輸720p以上的高清畫面。這是爲了保證在手機上MV(包含了歌詞)的觀看體驗。同時,還須要額外開發包括音量調節、切歌、演唱者切換等主播控制功能。
如對咱們的方案感興趣,或遇到開發問題,歡迎訪問聲網 Agora問答版塊,發帖與聲網工程師交流。