01如何快速的開發(fā)一個完整的iOS直播app(原理篇)

image.png

來源作者:袁崢
鏈接:http://www.reibang.com/p/bd42bacbe4cc

一、個人見解(直播難與易)

直播難:個人認為要想把直播從零開始做出來谣沸,絕對是牛逼中的牛逼刷钢,大牛中的大牛,因為直播中運用到的技術(shù)難點非常之多乳附,視頻/音頻采集内地,圖形處理,視頻/音頻壓縮赋除,CDN分發(fā)阱缓,即時通訊等技術(shù),每一個技術(shù)都夠你學幾年的举农。

直播易:已經(jīng)有各個領(lǐng)域的大牛荆针,封裝好了許多牛逼的框架,我們只需要用別人寫好的框架并蝗,就能快速的搭建一個直播app祭犯,也就是傳說中的站在大牛肩膀上編程。

二滚停、了解直播

熱門直播產(chǎn)品

映客沃粗,斗魚,熊貓键畴,虎牙最盅,花椒, 一直播等等
直播效果圖

直播效果圖.png

2.1一個完整直播app功能

1、聊天
聊天起惕、聊天室涡贱、點亮、推送惹想、黑名單等

2问词、禮物
普通禮物、豪華禮物嘀粱、紅包激挪、第三方充值、內(nèi)購锋叨、禮物動態(tài)更新垄分、提現(xiàn)、排行榜

3娃磺、直播列表
關(guān)注薄湿、熱門、最新、分類直播用戶列表等豺瘤;

4吆倦、自己直播
錄制、推流炉奴、解碼逼庞、播放、美顏瞻赶、心跳赛糟、后臺切換、主播對管理員操作砸逊、管理員對用戶等璧南;

5、房間邏輯
創(chuàng)建房間师逸、進入房間司倚、退出房間、關(guān)閉房間篓像、切換房間动知、房間管理員設(shè)置、房間用戶列表等员辩;

6盒粮、用戶邏輯
普通登陸、注冊奠滑、第三方登陸丹皱、修改個人信息、忘記密碼宋税、查看個人信息摊崭、關(guān)注列表、粉絲列表杰赛、收入榜呢簸、關(guān)注和取關(guān)、檢索乏屯、搜索等阔墩;

7、觀看直播
聊天信息瓶珊、滾屏彈幕、禮物顯示耸彪、加載界面等伞芹;

8、統(tǒng)計
APP業(yè)務(wù)統(tǒng)計、第三方統(tǒng)計等唱较;

9扎唾、超管
禁播、隱藏南缓、審核等胸遇;

2.2一個完整直播app原理

直播原理:

把主播錄制的視頻,推送到服務(wù)器汉形,在由服務(wù)器分發(fā)給觀眾觀看纸镊。

直播環(huán)節(jié):

推流端(采集、美顏處理概疆、編碼逗威、推流)、服務(wù)端處理(轉(zhuǎn)碼岔冀、錄制凯旭、截圖、鑒黃)使套、播放器(拉流罐呼、解碼、渲染)侦高、互動系統(tǒng)(聊天室嫉柴、禮物系統(tǒng)、贊)

2.3一個完整直播app實現(xiàn)流程

1.采集
2.濾鏡處理
3.編碼
4.推流
5.CDN分發(fā)
6.拉流
7.解碼
8.播放
9.聊天互動
直播App流程.png

2.4一個完整直播app架構(gòu)

直播架構(gòu)

2.5一個完整直播app技術(shù)點

直播技術(shù)點

三矫膨、了解流媒體(直播需要用到流媒體)

流媒體開發(fā):網(wǎng)絡(luò)層(socket或st)負責傳輸差凹,協(xié)議層(rtmp或hls)負責網(wǎng)絡(luò)打包,封裝層(flv侧馅、ts)負責編解碼數(shù)據(jù)的封裝危尿,編碼層(h.264和aac)負責圖像,音頻壓縮馁痴。

幀:每幀代表一幅靜止的圖像

GOP:(Group of Pictures)畫面組谊娇,一個GOP就是一組連續(xù)的畫面,每個畫面都是一幀罗晕,一個GOP就是很多幀的集合

直播的數(shù)據(jù)济欢,其實是一組圖片,包括I幀小渊、P幀法褥、B幀,當用戶第一次觀看的時候酬屉,會尋找I幀半等,而播放器會到服務(wù)器尋找到最近的I幀反饋給用戶揍愁。因此,GOP Cache增加了端到端延遲杀饵,因為它必須要拿到最近的I幀

GOP Cache的長度越長莽囤,畫面質(zhì)量越好

碼率:圖片進行壓縮后每秒顯示的數(shù)據(jù)量。

幀率:每秒顯示的圖片數(shù)切距。影響畫面流暢度朽缎,與畫面流暢度成正比:幀率越大,畫面越流暢谜悟;幀率越小话肖,畫面越有跳動感。

由于人類眼睛的特殊生理結(jié)構(gòu)赌躺,如果所看畫面之幀率高于16的時候狼牺,就會認為是連貫的,此現(xiàn)象稱之為視覺暫留礼患。并且當幀速達到一定數(shù)值后是钥,再增長的話,人眼也不容易察覺到有明顯的流暢度提升了缅叠。

分辨率:(矩形)圖片的長度和寬度悄泥,即圖片的尺寸
壓縮前的每秒數(shù)據(jù)量:幀率X分辨率(單位應(yīng)該是若干個字節(jié))

壓縮比:壓縮前的每秒數(shù)據(jù)量/碼率 (對于同一個視頻源并采用同一種視頻編碼算法,則:壓縮比越高肤粱,畫面質(zhì)量越差弹囚。)

視頻文件格式:文件的后綴,比如.wmv,.mov,.mp4,.mp3,.avi,

主要用處领曼,根據(jù)文件格式鸥鹉,系統(tǒng)會自動判斷用什么軟件打開,

注意: 隨意修改文件格式,對文件的本身不會造成太大的影響庶骄,比如把avi改成mp4,文件還是avi.

視頻封裝格式:一種儲存視頻信息的容器毁渗,流式封裝可以有TS、FLV等单刁,索引式的封裝有MP4,MOV,AVI等灸异,

主要作用:一個視頻文件往往會包含圖像和音頻,還有一些配置信息(如圖像和音頻的關(guān)聯(lián)羔飞,如何解碼它們等):這些內(nèi)容需要按照一定的規(guī)則組織肺樟、封裝起來.

注意:會發(fā)現(xiàn)封裝格式跟文件格式一樣,因為一般視頻文件格式的后綴名即采用相應(yīng)的視頻封裝格式的名稱,所以視頻文件格式就是視頻封裝格式逻淌。

視頻封裝格式和視頻壓縮編碼標準:就好像項目工程和編程語言么伯,封裝格式就是一個項目的工程,視頻編碼方式就是編程語言卡儒,一個項目工程可以用不同語言開發(fā)蹦狂。

四誓篱、直播基礎(chǔ)知識介紹:

4.1.采集視頻、音頻

  • 1.1 采集視頻凯楔、音頻編碼框架

    • AVFoundation:AVFoundation是用來播放和創(chuàng)建實時的視聽媒體數(shù)據(jù)的框架,同時提供Objective-C接口來操作這些視聽數(shù)據(jù)锦募,比如編輯摆屯,旋轉(zhuǎn),重編碼
  • 1.2 視頻糠亩、音頻硬件設(shè)備 *

    • CCD:圖像傳感器: 用于圖像采集和處理的過程虐骑,把圖像轉(zhuǎn)換成電信號。
    • 拾音器:聲音傳感器: 用于聲音采集和處理的過程赎线,把聲音轉(zhuǎn)換成電信號廷没。
    • 音頻采樣數(shù)據(jù):一般都是PCM格式
    • 視頻采樣數(shù)據(jù): 一般都是YUV,或RGB格式,采集到的原始音視頻的體積是非常大的垂寥,需要經(jīng)過壓縮技術(shù)處理來提高傳輸效率

4.2.視頻處理(美顏颠黎,水印)

  • 視頻處理原理:

    • 因為視頻最終也是通過GPU滞项,一幀一幀渲染到屏幕上的狭归,所以我們可以利用OpenGL ES,對視頻幀進行各種加工文判,從而視頻各種不同的效果过椎,就好像一個水龍頭流出的水,經(jīng)過若干節(jié)管道戏仓,然后流向不同的目標
    • 現(xiàn)在的各種美顏和視頻添加特效的app都是利用GPUImage這個框架實現(xiàn)的,.
  • 視頻處理框架

    • GPUImage : GPUImage是一個基于OpenGL ES的一個強大的圖像/視頻處理框架,封裝好了各種濾鏡同時也可以編寫自定義的濾鏡,其本身內(nèi)置了多達120多種常見的濾鏡效果疚宇。
    • OpenGL:OpenGL(全寫Open Graphics Library)是個定義了一個跨編程語言、跨平臺的編程接口的規(guī)格赏殃,它用于三維圖象(二維的亦可)敷待。OpenGL是個專業(yè)的圖形程序接口,是一個功能強大嗓奢,調(diào)用方便的底層圖形庫讼撒。
    • OpenGL ES:OpenGL ES (OpenGL for Embedded Systems) 是 OpenGL三維圖形 API 的子集,針對手機股耽、PDA和游戲主機等嵌入式設(shè)備而設(shè)計根盒。

4.3.視頻編碼解碼

4.3.1視頻編碼框架
  • FFmpeg:是一個跨平臺的開源視頻框架,能實現(xiàn)如視頻編碼,解碼,轉(zhuǎn)碼,串流,播放等豐富的功能。其支持的視頻格式以及播放協(xié)議非常豐富,幾乎包含了所有音視頻編解碼物蝙、封裝格式以及播放協(xié)議

    • -Libswresample:可以對音頻進行重采樣,rematrixing 以及轉(zhuǎn)換采樣格式等操 作炎滞。
    • -Libavcodec:提供了一個通用的編解碼框架,包含了許多視頻,音頻,字幕流 等編碼/解碼器。
    • -Libavformat:用于對視頻進行封裝/解封裝诬乞。
    • -Libavutil:包含一些共用的函數(shù),如隨機數(shù)生成,數(shù)據(jù)結(jié)構(gòu),數(shù)學運算等册赛。
    • -Libpostproc:用于進行視頻的一些后期處理钠导。
    • -Libswscale:用于視頻圖像縮放,顏色空間轉(zhuǎn)換等。
    • -Libavfilter:提供濾鏡功能森瘪。
  • X264:把視頻原數(shù)據(jù)YUV編碼壓縮成H.264格式

  • VideoToolbox:蘋果自帶的視頻硬解碼和硬編碼API牡属,但是在iOS8之后才開放。

  • AudioToolbox:蘋果自帶的音頻硬解碼和硬編碼API

4.3.2視頻編碼技術(shù)
  • 視頻壓縮編碼標準:對視頻進行壓縮(視頻編碼)或者解壓縮(視頻解碼)的編碼技術(shù),比如MPEG扼睬,H.264,這些視頻編碼技術(shù)是壓縮編碼視頻的
    • 主要作用:是將視頻像素數(shù)據(jù)壓縮成為視頻碼流逮栅,從而降低視頻的數(shù)據(jù)量。如果視頻不經(jīng)過壓縮編碼的話窗宇,體積通常是非常大的措伐,一部電影可能就要上百G的空間。
    • 注意:最影響視頻質(zhì)量的是其視頻編碼數(shù)據(jù)和音頻編碼數(shù)據(jù)军俊,跟封裝格式?jīng)]有多大關(guān)系
  • MPEG:一種視頻壓縮方式侥加,它采用了幀間壓縮,僅存儲連續(xù)幀之間有差別的地方 粪躬,從而達到較大的壓縮比
  • H.264/AVC:一種視頻壓縮方式,采用事先預測和與MPEG中的P-B幀一樣的幀預測方法壓縮担败,它可以根據(jù)需要產(chǎn)生適合網(wǎng)絡(luò)情況傳輸?shù)囊曨l流,還有更高的壓縮比,有更好的圖象質(zhì)量
    • 注意1:如果是從單個畫面清晰度比較短蜕,MPEG4有優(yōu)勢氢架;從動作連貫性上的清晰度,H.264有優(yōu)勢
    • 注意2:由于264的算法更加復雜朋魔,程序?qū)崿F(xiàn)煩瑣岖研,運行它需要更多的處理器和內(nèi)存資源。因此警检,運行264對系統(tǒng)要求是比較高的孙援。
    • 注意3:由于264的實現(xiàn)更加靈活,它把一些實現(xiàn)留給了廠商自己去實現(xiàn)扇雕,雖然這樣給實現(xiàn)帶來了很多好處拓售,但是不同產(chǎn)品之間互通成了很大的問題,造成了通過A公司的編碼器編出的數(shù)據(jù)镶奉,必須通過A公司的解碼器去解這樣尷尬的事情
  • H.265/HEVC:一種視頻壓縮方式,基于H.264础淤,保留原來的某些技術(shù),同時對一些相關(guān)的技術(shù)加以改進哨苛,以改善碼流鸽凶、編碼質(zhì)量、延時和算法復雜度之間的關(guān)系建峭,達到最優(yōu)化設(shè)置玻侥。
    • H.265 是一種更為高效的編碼標準,能夠在同等畫質(zhì)效果下將內(nèi)容的體積壓縮得更小亿蒸,傳輸時更快更省帶寬
  • I幀:(關(guān)鍵幀)保留一副完整的畫面凑兰,解碼時只需要本幀數(shù)據(jù)就可以完成(因為包含完整畫面)
  • P幀:(差別幀)保留這一幀跟之前幀的差別掌桩,解碼時需要用之前緩存的畫面疊加上本幀定義的差別,生成最終畫面姑食。(P幀沒有完整畫面數(shù)據(jù)波岛,只有與前一幀的畫面差別的數(shù)據(jù))
  • B幀:(雙向差別幀)保留的是本幀與前后幀的差別,解碼B幀音半,不僅要取得之前的緩存畫面盆色,還要解碼之后的畫面,通過前后畫面的與本幀數(shù)據(jù)的疊加取得最終的畫面祟剔。B幀壓縮率高,但是解碼時CPU會比較累
  • 幀內(nèi)(Intraframe)壓縮:當壓縮一幀圖像時摩梧,僅考慮本幀的數(shù)據(jù)而不考慮相鄰幀之間的冗余信息,幀內(nèi)一般采用有損壓縮算法
  • 幀間(Interframe)壓縮:時間壓縮(Temporal compression)物延,它通過比較時間軸上不同幀之間的數(shù)據(jù)進行壓縮。幀間壓縮一般是無損的
  • muxing(合成):將視頻流仅父、音頻流甚至是字幕流封裝到一個文件中(容器格式(FLV叛薯,TS)),作為一個信號進行傳輸笙纤。
4.3.3音頻編碼技術(shù)

AAC耗溜,mp3:這些屬于音頻編碼技術(shù),壓縮音頻用

4.3.4碼率控制
  • 多碼率:觀眾所處的網(wǎng)絡(luò)情況是非常復雜的,有可能是WiFi省容,有可能4G抖拴、3G、甚至2G腥椒,那么怎么滿足多方需求呢阿宅?多搞幾條線路,根據(jù)當前網(wǎng)絡(luò)環(huán)境自定義碼率笼蛛。
    • 列如:常橙鞣牛看見視頻播放軟件中的1024,720滨砍,1080, 高清往湿,標清,流暢等惋戏,指的就是各種碼率领追。
4.3.5 視頻封裝格式 *
  • TS : 一種流媒體封裝格式,流媒體封裝有一個好處日川,就是不需要加載索引再播放蔓腐,大大減少了首次載入的延遲,如果片子比較長龄句,mp4文件的索引相當大回论,影響用戶體驗
    • 為什么要用TS:這是因為兩個TS片段可以無縫拼接散罕,播放器能連續(xù)播放
  • FLV: 一種流媒體封裝格式,由于它形成的文件極小、加載速度極快傀蓉,使得網(wǎng)絡(luò)觀看視頻文件成為可能,因此FLV格式成為了當今主流視頻格式.

4.4推流

4.4.1 數(shù)據(jù)傳輸框架

librtmp:用來傳輸RTMP協(xié)議格式的數(shù)據(jù)

4.4.2 流媒體數(shù)據(jù)傳輸協(xié)議 *
  • RTMP:實時消息傳輸協(xié)議,Adobe Systems公司為Flash播放器和服務(wù)器之間音頻欧漱、視頻和數(shù)據(jù)傳輸開發(fā)的開放協(xié)議,因為是開放協(xié)議所以都可以使用了葬燎。
    • RTMP協(xié)議用于對象误甚、視頻、音頻的傳輸谱净。
    • 這個協(xié)議建立在TCP協(xié)議或者輪詢HTTP協(xié)議之上窑邦。
    • RTMP協(xié)議就像一個用來裝數(shù)據(jù)包的容器,這些數(shù)據(jù)可以是FLV中的視音頻數(shù)據(jù)壕探。一個單一的連接可以通過不同的通道傳輸多路網(wǎng)絡(luò)流冈钦,這些通道中的包都是按照固定大小的包傳輸?shù)?/li>
    • chunk:消息包

4.5.流媒體服務(wù)器

4.5.1常用服務(wù)器 *
  • SRS:一款國人開發(fā)的優(yōu)秀開源流媒體服務(wù)器系統(tǒng)
  • BMS:也是一款流媒體服務(wù)器系統(tǒng),但不開源李请,是SRS的商業(yè)版瞧筛,比SRS功能更多
  • nginx:免費開源web服務(wù)器,常用來配置流媒體服務(wù)器导盅。
4.5.2數(shù)據(jù)分發(fā)
  • CDN:(Content Delivery Network)僻澎,即內(nèi)容分發(fā)網(wǎng)絡(luò),將網(wǎng)站的內(nèi)容發(fā)布到最接近用戶的網(wǎng)絡(luò)”邊緣”梧兼,使用戶可以就近取得所需的內(nèi)容正压,解決 Internet網(wǎng)絡(luò)擁擠的狀況馋贤,提高用戶訪問網(wǎng)站的響應(yīng)速度.
    • CDN:代理服務(wù)器,相當于一個中介嘁字。
    • CDN工作原理:比如請求流媒體數(shù)據(jù)
      • 1.上傳流媒體數(shù)據(jù)到服務(wù)器(源站)
      • 2.源站存儲流媒體數(shù)據(jù)
      • 3.客戶端播放流媒體恩急,向CDN請求編碼后的流媒體數(shù)據(jù)
      • 4.CDN的服務(wù)器響應(yīng)請求,若節(jié)點上沒有該流媒體數(shù)據(jù)存在纪蜒,則向源站繼續(xù)請求流媒體數(shù)據(jù)衷恭;若節(jié)點上已經(jīng)緩存了該視頻文件,則跳到第6步纯续。
      • 5.源站響應(yīng)CDN的請求随珠,將流媒體分發(fā)到相應(yīng)的CDN節(jié)點上
      • 6.CDN將流媒體數(shù)據(jù)發(fā)送到客戶端
  • 回源:當有用戶訪問某一個URL的時候,如果被解析到的那個CDN節(jié)點沒有緩存響應(yīng)的內(nèi)容猬错,或者是緩存已經(jīng)到期窗看,就會回源站去獲取搜索。如果沒有人訪問倦炒,那么CDN節(jié)點不會主動去源站拿.
  • 帶寬:在固定的時間可傳輸?shù)臄?shù)據(jù)總量显沈,
    • 比如64位、800MHz的前端總線,它的數(shù)據(jù)傳輸率就等于64bit×800MHz÷8(Byte)=6.4GB/s
  • 負載均衡: 由多臺服務(wù)器以對稱的方式組成一個服務(wù)器集合拉讯,每臺服務(wù)器都具有等價的地位涤浇,都可以單獨對外提供服務(wù)而無須其他服務(wù)器的輔助.
    • 通過某種負載分擔技術(shù),將外部發(fā)送來的請求均勻分配到對稱結(jié)構(gòu)中的某一臺服務(wù)器上魔慷,而接收到請求的服務(wù)器獨立地回應(yīng)客戶的請求只锭。
    • 均衡負載能夠平均分配客戶請求到服務(wù)器列陣,籍此提供快速獲取重要數(shù)據(jù)院尔,解決大量并發(fā)訪問服務(wù)問題蜻展。
    • 這種群集技術(shù)可以用最少的投資獲得接近于大型主機的性能。
  • QoS(帶寬管理):限制每一個組群的帶寬邀摆,讓有限的帶寬發(fā)揮最大的效用

4.6.拉流

  • 直播協(xié)議選擇:
    • 即時性要求較高或有互動需求的可以采用RTMP,RTSP
    • 對于有回放或跨平臺需求的纵顾,推薦使用HLS
  • 直播協(xié)議對比 :
直播協(xié)議對比
  • HLS:由Apple公司定義的用于實時流傳輸?shù)膮f(xié)議,HLS基于HTTP協(xié)議實現(xiàn),傳輸內(nèi)容包括兩部分栋盹,一是M3U8描述文件片挂,二是TS媒體文件≌甓ⅲ可實現(xiàn)流媒體的直播和點播,主要應(yīng)用在iOS系統(tǒng)

    • HLS是以點播的技術(shù)方式來實現(xiàn)直播
    • HLS是自適應(yīng)碼率流播沪饺,客戶端會根據(jù)網(wǎng)絡(luò)狀況自動選擇不同碼率的視頻流躏敢,條件允許的情況下使用高碼率,網(wǎng)絡(luò)繁忙的時候使用低碼率整葡,并且自動在二者間隨意切
      換件余。這對移動設(shè)備網(wǎng)絡(luò)狀況不穩(wěn)定的情況下保障流暢播放非常有幫助。
    • 實現(xiàn)方法是服務(wù)器端提供多碼率視頻流遭居,并且在列表文件中注明啼器,播放器根據(jù)播放進度和下載速度自動調(diào)整。
  • HLS與RTMP對比:HLS主要是延時比較大俱萍,RTMP主要優(yōu)勢在于延時低

    • HLS協(xié)議的小切片方式會生成大量的文件端壳,存儲或處理這些文件會造成大量資源浪費
    • 相比使用RTSP協(xié)議的好處在于,一旦切分完成枪蘑,之后的分發(fā)過程完全不需要額外使用任何專門軟件损谦,普通的網(wǎng)絡(luò)服務(wù)器即可,大大降低了CDN邊緣服務(wù)器的配置要求岳颇,可以使用任何現(xiàn)成的CDN,而一般服務(wù)器很少支持RTSP照捡。
  • HTTP-FLV:基于HTTP協(xié)議流式的傳輸媒體內(nèi)容。
    相對于RTMP话侧,HTTP更簡單和廣為人知栗精,內(nèi)容延遲同樣可以做到1~3秒,打開速度更快瞻鹏,因為HTTP本身沒有復雜的狀態(tài)交互悲立。所以從延遲角度來看鹿寨,HTTP-FLV要優(yōu)于RTMP。

  • RTSP:實時流傳輸協(xié)議,定義了一對多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù).

  • RTP:實時傳輸協(xié)議,RTP是建立在UDP協(xié)議上的级历,常與RTCP一起使用释移,其本身并沒有提供按時發(fā)送機制或其它服務(wù)質(zhì)量(QoS)保證,它依賴于低層服務(wù)去實現(xiàn)這一過程寥殖。

  • RTCP:RTP的配套協(xié)議,主要功能是為RTP所提供的服務(wù)質(zhì)量(QoS)提供反饋玩讳,收集相關(guān)媒體連接的統(tǒng)計信息,例如傳輸字節(jié)數(shù)嚼贡,傳輸分組數(shù)熏纯,丟失分組數(shù),單向和雙向網(wǎng)絡(luò)延遲等等粤策。

4.7.解碼

4.7.1 解封裝
  • demuxing(分離):從視頻流樟澜、音頻流,字幕流合成的文件(容器格式(FLV叮盘,TS))中秩贰, 分解出視頻、音頻或字幕柔吼,各自進行解碼毒费。
4.7.2 音頻編碼框架
  • fdk_aac:音頻編碼解碼框架,PCM音頻數(shù)據(jù)和AAC音頻數(shù)據(jù)互轉(zhuǎn)
4.7.3 解碼介紹
  • 硬解碼:用GPU來解碼愈魏,減少CPU運算
    • 優(yōu)點:播放流暢觅玻、低功耗,解碼速度快培漏,
      缺點:兼容不好
  • 軟解碼:用CPU來解碼
    • 優(yōu)點:兼容好
      缺點:加大CPU負擔溪厘,耗電增加、沒有硬解碼流暢牌柄,解碼速度相對慢

4.8.播放

  • ijkplayer:一個基于FFmpeg的開源Android/iOS視頻播放器.
    • API易于集成畸悬;
    • 編譯配置可裁剪,方便控制安裝包大猩河丁傻昙;
    • 支持硬件加速解碼,更加省電
    • 簡單易用彩扔,指定拉流URL妆档,自動解碼播放.

4.9.聊天互動

  • IM:(InstantMessaging)即時通訊:是一個實時通信系統(tǒng),允許兩人或多人使用網(wǎng)絡(luò)實時的傳遞文字消息虫碉、文件贾惦、語音與視頻交流.

    • IM在直播系統(tǒng)中的主要作用是實現(xiàn)觀眾與主播、觀眾與觀眾之間的文字互動.***** 第三方SDK *****
  • 騰訊云:騰訊提供的即時通訊SDK,可作為直播的聊天室

  • 融云:一個比較常用的即時通訊SDK须板,可作為直播的聊天室

五碰镜、如何快速的開發(fā)一個完整的iOS直播app

1.利用第三方直播SDK快速的開發(fā)

  • 七牛云:七牛直播云是專為直播平臺打造的全球化直播流服務(wù)和一站式實現(xiàn)SDK端到端直播場景的企業(yè)級直播云服務(wù)平臺.

    熊貓TV,龍珠TV等直播平臺都是用的七牛云
    
  • 網(wǎng)易視頻云:基于專業(yè)的跨平臺視頻編解碼技術(shù)和大規(guī)模視頻內(nèi)容分發(fā)網(wǎng)絡(luò),提供穩(wěn)定流暢习瑰、低延時绪颖、高并發(fā)的實時音視頻服務(wù),可將視頻直播無縫對接到自身App.

2.第三方SDK公司為什么要提供SDK給我們甜奄?

  • 希望把我們的產(chǎn)品和它綁在一條船上柠横,更加的依賴它。
  • 技術(shù)生錢课兄,幫養(yǎng)一大批牛B的程序員

3.直播功能:自研還是使用第三方直播SDK開發(fā)牍氛?

  • 第三方SDK開發(fā): 對于一個初創(chuàng)團隊來講,自研直播不管在技術(shù)門檻烟阐、CDN搬俊、帶寬上都是有很大的門檻的,而且需要耗費大量的時間才能做出成品蜒茄,不利于拉投資唉擂。

  • 自研:公司直播平臺大,從長遠看檀葛,自研可以節(jié)省成本楔敌,技術(shù)成面比直接用SDK可控多了。

4.第三方SDK好處

  • 降低成本
    使用好的第三方企業(yè)服務(wù)驻谆,將不用再花高價請獵頭去挖昂貴的大牛,也不用去安撫大牛們個性化的脾氣
    提升效率
    第三方服務(wù)的專注與代碼集成所帶來的方便庆聘,所花費的時間可能僅僅是1-2個小時胜臊,節(jié)約近99%的時間,足夠換取更多的時間去和競爭對手斗智斗勇伙判,增加更大的成功可能性
  • 降低風險
    借助專業(yè)的第三方服務(wù)象对,由于它的快速、專業(yè)宴抚、穩(wěn)定等特點勒魔,能夠極大地加強產(chǎn)品的競爭能力(優(yōu)質(zhì)服務(wù)、研發(fā)速度等)菇曲,縮短試錯時間冠绢,必將是創(chuàng)業(yè)中保命的手段之一
  • 專業(yè)的事,找專業(yè)的人來做
    第三方服務(wù)最少是10-20人的團隊專注地解決同一個問題常潮,做同一件事情弟胀。第三方服務(wù)所帶來的支持效果,絕不是通過1-2個人處理所能對比的
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市孵户,隨后出現(xiàn)的幾起案子萧朝,更是在濱河造成了極大的恐慌,老刑警劉巖夏哭,帶你破解...
    沈念sama閱讀 222,104評論 6 515
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件检柬,死亡現(xiàn)場離奇詭異,居然都是意外死亡竖配,警方通過查閱死者的電腦和手機何址,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,816評論 3 399
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來械念,“玉大人头朱,你說我怎么就攤上這事×浼酰” “怎么了项钮?”我有些...
    開封第一講書人閱讀 168,697評論 0 360
  • 文/不壞的土叔 我叫張陵,是天一觀的道長希停。 經(jīng)常有香客問我烁巫,道長,這世上最難降的妖魔是什么宠能? 我笑而不...
    開封第一講書人閱讀 59,836評論 1 298
  • 正文 為了忘掉前任亚隙,我火速辦了婚禮,結(jié)果婚禮上违崇,老公的妹妹穿的比我還像新娘阿弃。我一直安慰自己,他們只是感情好羞延,可當我...
    茶點故事閱讀 68,851評論 6 397
  • 文/花漫 我一把揭開白布渣淳。 她就那樣靜靜地躺著,像睡著了一般伴箩。 火紅的嫁衣襯著肌膚如雪入愧。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 52,441評論 1 310
  • 那天嗤谚,我揣著相機與錄音棺蛛,去河邊找鬼。 笑死巩步,一個胖子當著我的面吹牛旁赊,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播椅野,決...
    沈念sama閱讀 40,992評論 3 421
  • 文/蒼蘭香墨 我猛地睜開眼彤恶,長吁一口氣:“原來是場噩夢啊……” “哼钞钙!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起声离,我...
    開封第一講書人閱讀 39,899評論 0 276
  • 序言:老撾萬榮一對情侶失蹤芒炼,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后术徊,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體本刽,經(jīng)...
    沈念sama閱讀 46,457評論 1 318
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,529評論 3 341
  • 正文 我和宋清朗相戀三年赠涮,在試婚紗的時候發(fā)現(xiàn)自己被綠了子寓。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,664評論 1 352
  • 序言:一個原本活蹦亂跳的男人離奇死亡笋除,死狀恐怖斜友,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情垃它,我是刑警寧澤鲜屏,帶...
    沈念sama閱讀 36,346評論 5 350
  • 正文 年R本政府宣布,位于F島的核電站国拇,受9級特大地震影響洛史,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜酱吝,卻給世界環(huán)境...
    茶點故事閱讀 42,025評論 3 334
  • 文/蒙蒙 一也殖、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧务热,春花似錦忆嗜、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,511評論 0 24
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至该镣,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間响谓,已是汗流浹背损合。 一陣腳步聲響...
    開封第一講書人閱讀 33,611評論 1 272
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留娘纷,地道東北人嫁审。 一個月前我還...
    沈念sama閱讀 49,081評論 3 377
  • 正文 我出身青樓,卻偏偏與公主長得像赖晶,于是被迫代替她去往敵國和親律适。 傳聞我的和親對象是個殘疾皇子辐烂,可洞房花燭夜當晚...
    茶點故事閱讀 45,675評論 2 359

推薦閱讀更多精彩內(nèi)容