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

作者:袁崢
鏈接:http://www.reibang.com/p/bd42bacbe4cc
來源:簡書
著作權(quán)歸作者所有门坷。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán),非商業(yè)轉(zhuǎn)載請注明出處。

目錄

前言

大半年沒寫博客了牲览,但我一直關(guān)注著互聯(lián)網(wǎng)的動(dòng)向谴轮,最近會(huì)研究很多東西沾谓,并分享破喻,今年移動(dòng)直播行業(yè)的興起职祷,誕生了一大批網(wǎng)紅盖灸,甚至明星也開始直播了蚁鳖,因此不得不跟上時(shí)代的步伐,由于第一次接觸的原因赁炎,因此花了很多時(shí)間了解直播醉箕,整理了直播的原理,當(dāng)前只是原理篇徙垫,后續(xù)會(huì)持續(xù)發(fā)布實(shí)戰(zhàn)篇讥裤,教你從零開始搭建一個(gè)完整的iOS直播app,希望能幫助到更多的人更快的了解直播姻报。
如果喜歡我的文章己英,可以關(guān)注我微博:袁崢Seemygo

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

直播難:個(gè)人認(rèn)為要想把直播從零開始做出來吴旋,絕對是牛逼中的牛逼损肛,大牛中的大牛厢破,因?yàn)橹辈ブ羞\(yùn)用到的技術(shù)難點(diǎn)非常之多,視頻/音頻處理治拿,圖形處理摩泪,視頻/音頻壓縮,CDN分發(fā)劫谅,即時(shí)通訊等技術(shù)见坑,每一個(gè)技術(shù)都?jí)蚰銓W(xué)幾年的。

直播易:已經(jīng)有各個(gè)領(lǐng)域的大牛捏检,封裝好了許多牛逼的框架鳄梅,我們只需要用別人寫好的框架,就能快速的搭建一個(gè)直播app未檩,也就是傳說中的站在大牛肩膀上編程戴尸。

二、了解直播

熱門直播產(chǎn)品

映客冤狡,斗魚孙蒙,熊貓,虎牙悲雳,花椒等等

直播效果圖

image

1.一個(gè)完整直播app功能(來自落影l(fā)oyinglin分享)

  • 1挎峦、聊天

    • 私聊、聊天室合瓢、點(diǎn)亮坦胶、推送、黑名單等;
  • 2晴楔、禮物

    • 普通禮物顿苇、豪華禮物、紅包税弃、排行榜纪岁、第三方充值、內(nèi)購则果、禮物動(dòng)態(tài)更新幔翰、提現(xiàn)等;
  • 3西壮、直播列表

    • 關(guān)注遗增、熱門、最新款青、分類直播用戶列表等做修;
  • 4、自己直播

    • 錄制、推流缓待、解碼、播放渠牲、美顏旋炒、心跳、后臺(tái)切換签杈、主播對管理員操作瘫镇、管理員對用戶等;
  • 5答姥、房間邏輯

    • 創(chuàng)建房間铣除、進(jìn)入房間、退出房間鹦付、關(guān)閉房間尚粘、切換房間、房間管理員設(shè)置敲长、房間用戶列表等郎嫁;
  • 6、用戶邏輯

    • 普通登陸祈噪、第三方登陸泽铛、注冊、搜索辑鲤、修改個(gè)人信息盔腔、關(guān)注列表、粉絲列表月褥、忘記密碼弛随、查看個(gè)人信息、收入榜宁赤、關(guān)注和取關(guān)撵幽、檢索等;
  • 7礁击、觀看直播

    • 聊天信息盐杂、滾屏彈幕、禮物顯示哆窿、加載界面等链烈;
  • 8、統(tǒng)計(jì)

    • APP業(yè)務(wù)統(tǒng)計(jì)挚躯、第三方統(tǒng)計(jì)等强衡;
  • 9、超管

    • 禁播码荔、隱藏漩勤、審核等感挥;

2.一個(gè)完整直播app原理

直播原理:把主播錄制的視頻,推送到服務(wù)器越败,在由服務(wù)器分發(fā)給觀眾觀看触幼。

直播環(huán)節(jié):推流端(采集、美顏處理究飞、編碼置谦、推流)、服務(wù)端處理(轉(zhuǎn)碼亿傅、錄制媒峡、截圖、鑒黃)葵擎、播放器(拉流谅阿、解碼、渲染)酬滤、互動(dòng)系統(tǒng)(聊天室奔穿、禮物系統(tǒng)、贊)

3.一個(gè)完整直播app實(shí)現(xiàn)流程

1.采集敏晤、2.濾鏡處理贱田、3.編碼、4.推流嘴脾、5.CDN分發(fā)男摧、6.拉流、7.解碼译打、8.播放耗拓、9.聊天互動(dòng)

image

4.一個(gè)完整直播app架構(gòu)

image

5.一個(gè)完整直播app技術(shù)點(diǎn)

image

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

  • 流媒體開發(fā):網(wǎng)絡(luò)層(socket或st)負(fù)責(zé)傳輸奏司,協(xié)議層(rtmp或hls)負(fù)責(zé)網(wǎng)絡(luò)打包乔询,封裝層(flv、ts)負(fù)責(zé)編解碼數(shù)據(jù)的封裝韵洋,編碼層(h.264和aac)負(fù)責(zé)圖像竿刁,音頻壓縮。

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

  • GOP:(Group of Pictures)畫面組搪缨,一個(gè)GOP就是一組連續(xù)的畫面食拜,每個(gè)畫面都是一幀,一個(gè)GOP就是很多幀的集合

    • 直播的數(shù)據(jù)副编,其實(shí)是一組圖片负甸,包括I幀、P幀、B幀呻待,當(dāng)用戶第一次觀看的時(shí)候打月,會(huì)尋找I幀,而播放器會(huì)到服務(wù)器尋找到最近的I幀反饋給用戶蚕捉。因此奏篙,GOP Cache增加了端到端延遲,因?yàn)樗仨氁玫阶罱腎幀
    • GOP Cache的長度越長鱼冀,畫面質(zhì)量越好
  • 碼率:圖片進(jìn)行壓縮后每秒顯示的數(shù)據(jù)量报破。

  • 幀率:每秒顯示的圖片數(shù)悠就。影響畫面流暢度千绪,與畫面流暢度成正比:幀率越大,畫面越流暢梗脾;幀率越小荸型,畫面越有跳動(dòng)感。

    • 由于人類眼睛的特殊生理結(jié)構(gòu)炸茧,如果所看畫面之幀率高于16的時(shí)候瑞妇,就會(huì)認(rèn)為是連貫的,此現(xiàn)象稱之為視覺暫留梭冠。并且當(dāng)幀速達(dá)到一定數(shù)值后辕狰,再增長的話控漠,人眼也不容易察覺到有明顯的流暢度提升了蔓倍。
  • 分辨率:(矩形)圖片的長度和寬度,即圖片的尺寸

  • 壓縮前的每秒數(shù)據(jù)量:幀率X分辨率(單位應(yīng)該是若干個(gè)字節(jié))

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

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

    • 主要用處聚谁,根據(jù)文件格式,系統(tǒng)會(huì)自動(dòng)判斷用什么軟件打開,
      注意: 隨意修改文件格式滞诺,對文件的本身不會(huì)造成太大的影響形导,比如把a(bǔ)vi改成mp4,文件還是avi.
  • 視頻封裝格式一種儲(chǔ)存視頻信息的容器,流式封裝可以有TS习霹、FLV等骤宣,索引式的封裝有MP4,MOV,AVI等,

    • 主要作用:一個(gè)視頻文件往往會(huì)包含圖像和音頻序愚,還有一些配置信息(如圖像和音頻的關(guān)聯(lián)憔披,如何解碼它們等):這些內(nèi)容需要按照一定的規(guī)則組織、封裝起來.
    • 注意:會(huì)發(fā)現(xiàn)封裝格式跟文件格式一樣,因?yàn)橐话阋曨l文件格式的后綴名即采用相應(yīng)的視頻封裝格式的名稱,所以視頻文件格式就是視頻封裝格式芬膝。
  • 視頻封裝格式和視頻壓縮編碼標(biāo)準(zhǔn):就好像項(xiàng)目工程和編程語言望门,封裝格式就是一個(gè)項(xiàng)目的工程,視頻編碼方式就是編程語言锰霜,一個(gè)項(xiàng)目工程可以用不同語言開發(fā)筹误。

四、直播基礎(chǔ)知識(shí)介紹:

1.采集視頻癣缅、音頻

***** 1.1 采集視頻厨剪、音頻編碼框架 *****

  • AVFoundation:AVFoundation是用來播放和創(chuàng)建實(shí)時(shí)的視聽媒體數(shù)據(jù)的框架,同時(shí)提供Objective-C接口來操作這些視聽數(shù)據(jù)友存,比如編輯祷膳,旋轉(zhuǎn),重編碼

***** 1.2 視頻屡立、音頻硬件設(shè)備 *****

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

2.視頻處理(美顏敛摘,水印)

  • 視頻處理原理:因?yàn)橐曨l最終也是通過GPU乳愉,一幀一幀渲染到屏幕上的兄淫,所以我們可以利用OpenGL ES,對視頻幀進(jìn)行各種加工匾委,從而視頻各種不同的效果拖叙,就好像一個(gè)水龍頭流出的水,經(jīng)過若干節(jié)管道赂乐,然后流向不同的目標(biāo)
    • 現(xiàn)在的各種美顏和視頻添加特效的app都是利用GPUImage這個(gè)框架實(shí)現(xiàn)的,.

***** 視頻處理框架 *****

  • GPUImage : GPUImage是一個(gè)基于OpenGL ES的一個(gè)強(qiáng)大的圖像/視頻處理框架,封裝好了各種濾鏡同時(shí)也可以編寫自定義的濾鏡,其本身內(nèi)置了多達(dá)120多種常見的濾鏡效果薯鳍。
  • OpenGL:OpenGL(全寫Open Graphics Library)是個(gè)定義了一個(gè)跨編程語言、跨平臺(tái)的編程接口的規(guī)格挨措,它用于三維圖象(二維的亦可)挖滤。OpenGL是個(gè)專業(yè)的圖形程序接口,是一個(gè)功能強(qiáng)大浅役,調(diào)用方便的底層圖形庫斩松。
  • OpenGL ES:OpenGL ES (OpenGL for Embedded Systems) 是 OpenGL三維圖形 API 的子集,針對手機(jī)觉既、PDA和游戲主機(jī)等嵌入式設(shè)備而設(shè)計(jì)惧盹。

3.視頻編碼解碼

***** 3.1 視頻編碼框架 *****

  • FFmpeg:是一個(gè)跨平臺(tái)的開源視頻框架,能實(shí)現(xiàn)如視頻編碼,解碼,轉(zhuǎn)碼,串流,播放等豐富的功能乳幸。其支持的視頻格式以及播放協(xié)議非常豐富,幾乎包含了所有音視頻編解碼、封裝格式以及播放協(xié)議钧椰。
    • -Libswresample:可以對音頻進(jìn)行重采樣,rematrixing 以及轉(zhuǎn)換采樣格式等操 作粹断。
    • -Libavcodec:提供了一個(gè)通用的編解碼框架,包含了許多視頻,音頻,字幕流 等編碼/解碼器。
    • -Libavformat:用于對視頻進(jìn)行封裝/解封裝嫡霞。
    • -Libavutil:包含一些共用的函數(shù),如隨機(jī)數(shù)生成,數(shù)據(jù)結(jié)構(gòu),數(shù)學(xué)運(yùn)算等瓶埋。
    • -Libpostproc:用于進(jìn)行視頻的一些后期處理。
    • -Libswscale:用于視頻圖像縮放,顏色空間轉(zhuǎn)換等诊沪。
    • -Libavfilter:提供濾鏡功能养筒。
  • X264:把視頻原數(shù)據(jù)YUV編碼壓縮成H.264格式
  • VideoToolbox:蘋果自帶的視頻硬解碼和硬編碼API,但是在iOS8之后才開放端姚。
  • AudioToolbox:蘋果自帶的音頻硬解碼和硬編碼API

***** 3.2 視頻編碼技術(shù) *****

  • 視頻壓縮編碼標(biāo)準(zhǔn)對視頻進(jìn)行壓縮(視頻編碼)或者解壓縮(視頻解碼)的編碼技術(shù),比如MPEG晕粪,H.264,這些視頻編碼技術(shù)是壓縮編碼視頻的
    • 主要作用:是將視頻像素?cái)?shù)據(jù)壓縮成為視頻碼流,從而降低視頻的數(shù)據(jù)量寄锐。如果視頻不經(jīng)過壓縮編碼的話兵多,體積通常是非常大的尖啡,一部電影可能就要上百G的空間橄仆。
    • 注意:最影響視頻質(zhì)量的是其視頻編碼數(shù)據(jù)和音頻編碼數(shù)據(jù),跟封裝格式?jīng)]有多大關(guān)系
  • MPEG:一種視頻壓縮方式衅斩,它采用了幀間壓縮盆顾,僅存儲(chǔ)連續(xù)幀之間有差別的地方 ,從而達(dá)到較大的壓縮比
  • H.264/AVC:一種視頻壓縮方式,采用事先預(yù)測和與MPEG中的P-B幀一樣的幀預(yù)測方法壓縮畏梆,它可以根據(jù)需要產(chǎn)生適合網(wǎng)絡(luò)情況傳輸?shù)囊曨l流,還有更高的壓縮比您宪,有更好的圖象質(zhì)量
    • 注意1:如果是從單個(gè)畫面清晰度比較,MPEG4有優(yōu)勢奠涌;從動(dòng)作連貫性上的清晰度宪巨,H.264有優(yōu)勢
    • 注意2:由于264的算法更加復(fù)雜,程序?qū)崿F(xiàn)煩瑣溜畅,運(yùn)行它需要更多的處理器和內(nèi)存資源捏卓。因此,運(yùn)行264對系統(tǒng)要求是比較高的慈格。
    • 注意3:由于264的實(shí)現(xiàn)更加靈活怠晴,它把一些實(shí)現(xiàn)留給了廠商自己去實(shí)現(xiàn),雖然這樣給實(shí)現(xiàn)帶來了很多好處浴捆,但是不同產(chǎn)品之間互通成了很大的問題蒜田,造成了通過A公司的編碼器編出的數(shù)據(jù),必須通過A公司的解碼器去解這樣尷尬的事情
  • H.265/HEVC:一種視頻壓縮方式,基于H.264选泻,保留原來的某些技術(shù)冲粤,同時(shí)對一些相關(guān)的技術(shù)加以改進(jìn)美莫,以改善碼流、編碼質(zhì)量梯捕、延時(shí)和算法復(fù)雜度之間的關(guān)系茂嗓,達(dá)到最優(yōu)化設(shè)置。
    • H.265 是一種更為高效的編碼標(biāo)準(zhǔn)科阎,能夠在同等畫質(zhì)效果下將內(nèi)容的體積壓縮得更小述吸,傳輸時(shí)更快更省帶寬
    • I幀:(關(guān)鍵幀)保留一副完整的畫面,解碼時(shí)只需要本幀數(shù)據(jù)就可以完成(因?yàn)榘暾嬅妫?/li>
  • P幀:(差別幀)保留這一幀跟之前幀的差別锣笨,解碼時(shí)需要用之前緩存的畫面疊加上本幀定義的差別蝌矛,生成最終畫面。(P幀沒有完整畫面數(shù)據(jù)错英,只有與前一幀的畫面差別的數(shù)據(jù))
  • B幀:(雙向差別幀)保留的是本幀與前后幀的差別入撒,解碼B幀,不僅要取得之前的緩存畫面椭岩,還要解碼之后的畫面茅逮,通過前后畫面的與本幀數(shù)據(jù)的疊加取得最終的畫面。B幀壓縮率高判哥,但是解碼時(shí)CPU會(huì)比較累
  • 幀內(nèi)(Intraframe)壓縮:當(dāng)壓縮一幀圖像時(shí)献雅,僅考慮本幀的數(shù)據(jù)而不考慮相鄰幀之間的冗余信息,幀內(nèi)一般采用有損壓縮算法
  • 幀間(Interframe)壓縮:時(shí)間壓縮(Temporal compression),它通過比較時(shí)間軸上不同幀之間的數(shù)據(jù)進(jìn)行壓縮塌计。幀間壓縮一般是無損的
  • muxing(合成):將視頻流挺身、音頻流甚至是字幕流封裝到一個(gè)文件中(容器格式(FLV,TS))锌仅,作為一個(gè)信號(hào)進(jìn)行傳輸章钾。

***** 3.3 音頻編碼技術(shù) *****

  • AACmp3:這些屬于音頻編碼技術(shù),壓縮音頻用

***** 3.4碼率控制 *****

  • 多碼率:觀眾所處的網(wǎng)絡(luò)情況是非常復(fù)雜的热芹,有可能是WiFi贱傀,有可能4G、3G伊脓、甚至2G府寒,那么怎么滿足多方需求呢?多搞幾條線路丽旅,根據(jù)當(dāng)前網(wǎng)絡(luò)環(huán)境自定義碼率椰棘。
    • 列如:常常看見視頻播放軟件中的1024榄笙,720邪狞,高清,標(biāo)清茅撞,流暢等帆卓,指的就是各種碼率巨朦。

***** 3.5 視頻封裝格式 *****

  • TS : 一種流媒體封裝格式,流媒體封裝有一個(gè)好處剑令,就是不需要加載索引再播放糊啡,大大減少了首次載入的延遲,如果片子比較長吁津,mp4文件的索引相當(dāng)大棚蓄,影響用戶體驗(yàn)

    • 為什么要用TS:這是因?yàn)閮蓚€(gè)TS片段可以無縫拼接,播放器能連續(xù)播放
  • FLV: 一種流媒體封裝格式,由于它形成的文件極小碍脏、加載速度極快梭依,使得網(wǎng)絡(luò)觀看視頻文件成為可能,因此FLV格式成為了當(dāng)今主流視頻格式

4.推流

***** 4.1 數(shù)據(jù)傳輸框架 *****

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

***** 4.2 流媒體數(shù)據(jù)傳輸協(xié)議 *****

  • RTMP:實(shí)時(shí)消息傳輸協(xié)議,Adobe Systems公司為Flash播放器和服務(wù)器之間音頻、視頻和數(shù)據(jù)傳輸開發(fā)的開放協(xié)議典尾,因?yàn)槭情_放協(xié)議所以都可以使用了役拴。

    • RTMP協(xié)議用于對象、視頻钾埂、音頻的傳輸河闰。
    • 這個(gè)協(xié)議建立在TCP協(xié)議或者輪詢HTTP協(xié)議之上。
    • RTMP協(xié)議就像一個(gè)用來裝數(shù)據(jù)包的容器褥紫,這些數(shù)據(jù)可以是FLV中的視音頻數(shù)據(jù)姜性。一個(gè)單一的連接可以通過不同的通道傳輸多路網(wǎng)絡(luò)流,這些通道中的包都是按照固定大小的包傳輸?shù)?/li>

    chunk:消息包

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

***** 5.1常用服務(wù)器 *****

  • SRS:一款國人開發(fā)的優(yōu)秀開源流媒體服務(wù)器系統(tǒng)
  • BMS:也是一款流媒體服務(wù)器系統(tǒng)故源,但不開源污抬,是SRS的商業(yè)版汞贸,比SRS功能更多
  • nginx:免費(fèi)開源web服務(wù)器绳军,常用來配置流媒體服務(wù)器。

***** 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ù)器奶是,相當(dāng)于一個(gè)中介。
    • CDN工作原理:比如請求流媒體數(shù)據(jù)
      • 1.上傳流媒體數(shù)據(jù)到服務(wù)器(源站)
      • 2.源站存儲(chǔ)流媒體數(shù)據(jù)
      • 3.客戶端播放流媒體竣灌,向CDN請求編碼后的流媒體數(shù)據(jù)
      • 4.CDN的服務(wù)器響應(yīng)請求聂沙,若節(jié)點(diǎn)上沒有該流媒體數(shù)據(jù)存在,則向源站繼續(xù)請求流媒體數(shù)據(jù)初嘹;若節(jié)點(diǎn)上已經(jīng)緩存了該視頻文件及汉,則跳到第6步。
      • 5.源站響應(yīng)CDN的請求屯烦,將流媒體分發(fā)到相應(yīng)的CDN節(jié)點(diǎn)上
      • 6.CDN將流媒體數(shù)據(jù)發(fā)送到客戶端
  • 回源:當(dāng)有用戶訪問某一個(gè)URL的時(shí)候坷随,如果被解析到的那個(gè)CDN節(jié)點(diǎn)沒有緩存響應(yīng)的內(nèi)容房铭,或者是緩存已經(jīng)到期,就會(huì)回源站去獲取搜索温眉。如果沒有人訪問缸匪,那么CDN節(jié)點(diǎn)不會(huì)主動(dòng)去源站拿.
  • 帶寬:在固定的時(shí)間可傳輸?shù)臄?shù)據(jù)總量,
    • 比如64位类溢、800MHz的前端總線凌蔬,它的數(shù)據(jù)傳輸率就等于64bit×800MHz÷8(Byte)=6.4GB/s
  • 負(fù)載均衡: 由多臺(tái)服務(wù)器以對稱的方式組成一個(gè)服務(wù)器集合,每臺(tái)服務(wù)器都具有等價(jià)的地位闯冷,都可以單獨(dú)對外提供服務(wù)而無須其他服務(wù)器的輔助.
    • 通過某種負(fù)載分擔(dān)技術(shù)龟梦,將外部發(fā)送來的請求均勻分配到對稱結(jié)構(gòu)中的某一臺(tái)服務(wù)器上,而接收到請求的服務(wù)器獨(dú)立地回應(yīng)客戶的請求窃躲。
    • 均衡負(fù)載能夠平均分配客戶請求到服務(wù)器列陣计贰,籍此提供快速獲取重要數(shù)據(jù),解決大量并發(fā)訪問服務(wù)問題蒂窒。
    • 這種群集技術(shù)可以用最少的投資獲得接近于大型主機(jī)的性能躁倒。
  • QoS(帶寬管理):限制每一個(gè)組群的帶寬,讓有限的帶寬發(fā)揮最大的效用

6.拉流

  • 直播協(xié)議選擇
    • 即時(shí)性要求較高或有互動(dòng)需求的可以采用RTMP,RTSP
    • 對于有回放或跨平臺(tái)需求的洒琢,推薦使用HLS
  •   `直播協(xié)議對比`    :
    
    
image
  • HLS:由Apple公司定義的用于實(shí)時(shí)流傳輸?shù)膮f(xié)議,HLS基于HTTP協(xié)議實(shí)現(xiàn)秧秉,傳輸內(nèi)容包括兩部分,一是M3U8描述文件衰抑,二是TS媒體文件象迎。可實(shí)現(xiàn)流媒體的直播和點(diǎn)播呛踊,主要應(yīng)用在iOS系統(tǒng)
    • HLS是以點(diǎn)播的技術(shù)方式來實(shí)現(xiàn)直播
    • HLS是自適應(yīng)碼率流播砾淌,客戶端會(huì)根據(jù)網(wǎng)絡(luò)狀況自動(dòng)選擇不同碼率的視頻流,條件允許的情況下使用高碼率谭网,網(wǎng)絡(luò)繁忙的時(shí)候使用低碼率汪厨,并且自動(dòng)在二者間隨意切
      換。這對移動(dòng)設(shè)備網(wǎng)絡(luò)狀況不穩(wěn)定的情況下保障流暢播放非常有幫助愉择。
    • 實(shí)現(xiàn)方法是服務(wù)器端提供多碼率視頻流劫乱,并且在列表文件中注明,播放器根據(jù)播放進(jìn)度和下載速度自動(dòng)調(diào)整锥涕。
  • HLS與RTMP對比:HLS主要是延時(shí)比較大衷戈,RTMP主要優(yōu)勢在于延時(shí)低
    • HLS協(xié)議的小切片方式會(huì)生成大量的文件,存儲(chǔ)或處理這些文件會(huì)造成大量資源浪費(fèi)
    • 相比使用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秒,打開速度更快嫡纠,因?yàn)镠TTP本身沒有復(fù)雜的狀態(tài)交互烦租。所以從延遲角度來看,HTTP-FLV要優(yōu)于RTMP除盏。
  • RTSP:實(shí)時(shí)流傳輸協(xié)議,定義了一對多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù).
  • RTP:實(shí)時(shí)傳輸協(xié)議,RTP是建立在UDP協(xié)議上的叉橱,常與RTCP一起使用,其本身并沒有提供按時(shí)發(fā)送機(jī)制或其它服務(wù)質(zhì)量(QoS)保證者蠕,它依賴于低層服務(wù)去實(shí)現(xiàn)這一過程窃祝。
  • RTCP:RTP的配套協(xié)議,主要功能是為RTP所提供的服務(wù)質(zhì)量(QoS)提供反饋,收集相關(guān)媒體連接的統(tǒng)計(jì)信息踱侣,例如傳輸字節(jié)數(shù)粪小,傳輸分組數(shù),丟失分組數(shù)抡句,單向和雙向網(wǎng)絡(luò)延遲等等探膊。

7.解碼

***** 7.1 解封裝 *****

  • demuxing(分離):從視頻流、音頻流待榔,字幕流合成的文件(容器格式(FLV逞壁,TS))中, 分解出視頻锐锣、音頻或字幕腌闯,各自進(jìn)行解碼。

***** 7.2 音頻編碼框架 *****

  • fdk_aac:音頻編碼解碼框架刺下,PCM音頻數(shù)據(jù)和AAC音頻數(shù)據(jù)互轉(zhuǎn)

***** 7.3 解碼介紹 *****

  • 硬解碼:用GPU來解碼绑嘹,減少CPU運(yùn)算
    • 優(yōu)點(diǎn):播放流暢、低功耗橘茉,解碼速度快,
         * 缺點(diǎn):兼容不好
  • 軟解碼:用CPU來解碼
    • 優(yōu)點(diǎn):兼容好
         * 缺點(diǎn):加大CPU負(fù)擔(dān)姨丈,耗電增加畅卓、沒有硬解碼流暢,解碼速度相對慢

8.播放

  • ijkplayer:一個(gè)基于FFmpeg的開源Android/iOS視頻播放器
    • API易于集成蟋恬;
    • 編譯配置可裁剪翁潘,方便控制安裝包大小歼争;
    • 支持硬件加速解碼拜马,更加省電
    • 簡單易用渗勘,指定拉流URL,自動(dòng)解碼播放.

9.聊天互動(dòng)

  • IM:(InstantMessaging)即時(shí)通訊:是一個(gè)實(shí)時(shí)通信系統(tǒng)俩莽,允許兩人或多人使用網(wǎng)絡(luò)實(shí)時(shí)的傳遞文字消息旺坠、文件、語音與視頻交流.
    • IM在直播系統(tǒng)中的主要作用是實(shí)現(xiàn)觀眾與主播扮超、觀眾與觀眾之間的文字互動(dòng).
      ***** 第三方SDK *****
  • 騰訊云:騰訊提供的即時(shí)通訊SDK取刃,可作為直播的聊天室
  • 融云:一個(gè)比較常用的即時(shí)通訊SDK,可作為直播的聊天室

五出刷、如何快速的開發(fā)一個(gè)完整的iOS直播app

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

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

  • 熊貓TV,龍珠TV等直播平臺(tái)都是用的七牛云

網(wǎng)易視頻云:基于專業(yè)的跨平臺(tái)視頻編解碼技術(shù)和大規(guī)模視頻內(nèi)容分發(fā)網(wǎng)絡(luò),提供穩(wěn)定流暢馁龟、低延時(shí)崩侠、高并發(fā)的實(shí)時(shí)音視頻服務(wù),可將視頻直播無縫對接到自身App.

2坷檩、第三方SDK公司為什么要提供SDK給我們啦膜?

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

3、直播功能:自研還是使用第三方直播SDK開發(fā)裸删?

第三方SDK開發(fā): 對于一個(gè)初創(chuàng)團(tuán)隊(duì)來講八拱,自研直播不管在技術(shù)門檻、CDN涯塔、帶寬上都是有很大的門檻的肌稻,而且需要耗費(fèi)大量的時(shí)間才能做出成品,不利于拉投資匕荸。

自研:公司直播平臺(tái)大爹谭,從長遠(yuǎn)看,自研可以節(jié)省成本榛搔,技術(shù)成面比直接用SDK可控多了诺凡。

4.第三方SDK好處

  • 降低成本
    • 使用好的第三方企業(yè)服務(wù),將不用再花高價(jià)請獵頭去挖昂貴的大牛践惑,也不用去安撫大牛們個(gè)性化的脾氣
  • 提升效率
    • 第三方服務(wù)的專注與代碼集成所帶來的方便腹泌,所花費(fèi)的時(shí)間可能僅僅是1-2個(gè)小時(shí),節(jié)約近99%的時(shí)間尔觉,足夠換取更多的時(shí)間去和競爭對手斗智斗勇凉袱,增加更大的成功可能性
  • 降低風(fēng)險(xiǎn)
    • 借助專業(yè)的第三方服務(wù),由于它的快速、專業(yè)专甩、穩(wěn)定等特點(diǎn)钟鸵,能夠極大地加強(qiáng)產(chǎn)品的競爭能力(優(yōu)質(zhì)服務(wù)、研發(fā)速度等)涤躲,縮短試錯(cuò)時(shí)間棺耍,必將是創(chuàng)業(yè)中保命的手段之一
  • 專業(yè)的事,找專業(yè)的人來做
    • 第三方服務(wù)最少是10-20人的團(tuán)隊(duì)專注地解決同一個(gè)問題篓叶,做同一件事情烈掠。第三方服務(wù)所帶來的支持效果,絕不是通過1-2個(gè)人處理所能對比的,難道不是嗎

結(jié)束語

后續(xù)還會(huì)有講解視頻采集,美顏止潘,聊天室,禮物系統(tǒng)等更多功能矫限,敬請關(guān)注!E迥ā叼风!

作者:袁崢
鏈接:http://www.reibang.com/p/bd42bacbe4cc
來源:簡書
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)棍苹,非商業(yè)轉(zhuǎn)載請注明出處无宿。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市枢里,隨后出現(xiàn)的幾起案子孽鸡,更是在濱河造成了極大的恐慌,老刑警劉巖栏豺,帶你破解...
    沈念sama閱讀 206,602評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件彬碱,死亡現(xiàn)場離奇詭異,居然都是意外死亡奥洼,警方通過查閱死者的電腦和手機(jī)巷疼,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,442評論 2 382
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來灵奖,“玉大人嚼沿,你說我怎么就攤上這事∩U” “怎么了伏尼?”我有些...
    開封第一講書人閱讀 152,878評論 0 344
  • 文/不壞的土叔 我叫張陵,是天一觀的道長尉尾。 經(jīng)常有香客問我,道長燥透,這世上最難降的妖魔是什么沙咏? 我笑而不...
    開封第一講書人閱讀 55,306評論 1 279
  • 正文 為了忘掉前任辨图,我火速辦了婚禮,結(jié)果婚禮上肢藐,老公的妹妹穿的比我還像新娘故河。我一直安慰自己,他們只是感情好吆豹,可當(dāng)我...
    茶點(diǎn)故事閱讀 64,330評論 5 373
  • 文/花漫 我一把揭開白布鱼的。 她就那樣靜靜地躺著,像睡著了一般痘煤。 火紅的嫁衣襯著肌膚如雪凑阶。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 49,071評論 1 285
  • 那天衷快,我揣著相機(jī)與錄音宙橱,去河邊找鬼。 笑死蘸拔,一個(gè)胖子當(dāng)著我的面吹牛师郑,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播调窍,決...
    沈念sama閱讀 38,382評論 3 400
  • 文/蒼蘭香墨 我猛地睜開眼宝冕,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了邓萨?” 一聲冷哼從身側(cè)響起地梨,我...
    開封第一講書人閱讀 37,006評論 0 259
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎先誉,沒想到半個(gè)月后湿刽,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 43,512評論 1 300
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡褐耳,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 35,965評論 2 325
  • 正文 我和宋清朗相戀三年诈闺,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片铃芦。...
    茶點(diǎn)故事閱讀 38,094評論 1 333
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡雅镊,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出刃滓,到底是詐尸還是另有隱情仁烹,我是刑警寧澤,帶...
    沈念sama閱讀 33,732評論 4 323
  • 正文 年R本政府宣布咧虎,位于F島的核電站卓缰,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜征唬,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,283評論 3 307
  • 文/蒙蒙 一捌显、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧总寒,春花似錦扶歪、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,286評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至年枕,卻和暖如春炫欺,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背画切。 一陣腳步聲響...
    開封第一講書人閱讀 31,512評論 1 262
  • 我被黑心中介騙來泰國打工竣稽, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人霍弹。 一個(gè)月前我還...
    沈念sama閱讀 45,536評論 2 354
  • 正文 我出身青樓毫别,卻偏偏與公主長得像,于是被迫代替她去往敵國和親典格。 傳聞我的和親對象是個(gè)殘疾皇子岛宦,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 42,828評論 2 345

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