來(lái)隨便講講 av 吧.

av 就是 audio&video

這里用直播做栗子吧

走一波

采樣都知道吧油够？(不知道自己去百度查啊)

聲音信號(hào)拾酝，圖像信號(hào)都是模擬信號(hào),就是連續(xù)信號(hào)

但是我們手機(jī)啥的現(xiàn)在都是數(shù)字信號(hào),也就是離散信號(hào)

所以要采樣

比如一個(gè)周期的正弦波

正弦波最少采樣2個(gè)點(diǎn)就能完整的恢復(fù)這個(gè)波形

先講點(diǎn) 非常淺顯的有意思的

知道人能聽到的聲音范圍 大概是多少吧

人能聽到的聲音頻率大概是20 ～ 20khz

知道為啥 一般mp3 采樣率都是44k嗎？

一個(gè)周期采樣2個(gè)點(diǎn)就能完全恢復(fù)這個(gè)信號(hào)

20*2??= 40

算上冗余

44k 就能基本絕大部分的還原聲音了

直播中用的語(yǔ)音編碼很多種

就是 考慮到有的人聽力敏銳

能聽到20khz 以上的

一般都是AAC

aac 這個(gè)編碼格式??根mp3 相比??壓縮率高 還原度高

在這再講一個(gè)有意思的

我要告訴你們 打電話 聽對(duì)面放歌??你是聽不很清楚的

電話 語(yǔ)音的采樣率是8k 跟44k 相差甚遠(yuǎn)

為的就是降低數(shù)據(jù)流量

理論上來(lái)講?

8k 采樣率能比44k 降低5倍的流量

8k 的采樣率 最多只能 采集模擬信號(hào) 4k 左右的

人說(shuō)話 大概的范圍就是20到 44k, 20hz 已經(jīng)是聽力下限了

就是咱們聽音樂 重低音啥的

低音就是頻率低高音就是 頻率高

超聲波 為啥我們聽不到慷暂？

因?yàn)橐呀?jīng)超過(guò)20khz的范圍了

以早起電話交換語(yǔ)音格式 用的g729

8k 16位采樣率的情況下

1秒才1k左右的數(shù)據(jù)

1分鐘才60k

1小時(shí)才 3.6M

(什么叫十六位采樣率??

就是 一個(gè)采樣 我量化成2個(gè)字節(jié) 也就是2*8 = 16位

2字節(jié) 是2的16次方(65536)

也就是 1個(gè)信號(hào)??我能量化成65536個(gè)不同的程度

越精細(xì)荧飞，聲音越逼真

但是到一定程度烙无，再精細(xì) 人耳就聽不出來(lái)了

采樣率用于表示信號(hào)幅度

)

再說(shuō)一句,你打電話跟你聽音樂完全兩個(gè)概念

再說(shuō)現(xiàn)在的直播系統(tǒng)

為啥不用電話的那種語(yǔ)音格式毫捣？

因?yàn)橛幸魳钒?。帝际。蔓同。

音樂可是超出8k 采樣率范圍的

所以 如果用8k 采樣率，音樂就會(huì)慘不忍聽

所以wszcug 大佬前年高webrtc 那會(huì)

很多人問wszcug大佬 能不能做直播

wszcug大佬說(shuō)不能

問的人說(shuō)為啥

wszcug大佬說(shuō) webrtc 到哪個(gè)時(shí)候?yàn)橹?還沒有高于16k 采樣率的編碼格式

(webrtc是實(shí)時(shí)視頻通話)

記住 直播系統(tǒng)是偽實(shí)時(shí)

webrtc 這種真實(shí)時(shí)??可以做到 延遲500ms 以內(nèi)

直播用aac 原因很簡(jiǎn)單

首先采樣能滿足

其次跟mp3 比蹲诀，壓縮率搞

再次 不收版權(quán)費(fèi)

ok 前提講了個(gè)差不多?? 進(jìn)入正題

采集同樣一段 聲音

96k 比44k 高一倍的大小

但是呢

因?yàn)槿说闹饔^因素

聽覺方面并不能提升一倍

甚至只能提升一點(diǎn)點(diǎn)

所以 高一倍的容量沒必要

96k 聽音樂比44k 要亮一些??

對(duì)相同一段音樂來(lái)講是這樣

所以最終方案就是采用了aac

那么再講講視頻

視頻的道理其實(shí)跟音頻一樣

同樣是模擬信號(hào)采樣成數(shù)字信號(hào)

蘋果現(xiàn)在可以用sdk 直接采集

采樣的元數(shù)據(jù)非常大

采樣的元數(shù)據(jù)非常的大

采樣的元數(shù)據(jù)非常非常的大

肯定要做壓縮對(duì)吧斑粱？

在壓縮之前 咱先來(lái)個(gè)美顏

這就到了GPUImage

他對(duì)這些采樣數(shù)據(jù) 做gpu運(yùn)算

具體什么算法很多種

雙邊鋁箔 單邊綠波啥啥啥的

這處理完全用的gpu

不占用cpu

處理之后的數(shù)據(jù) gpu 給轉(zhuǎn)化成rbga32

這個(gè)數(shù)據(jù)也很大

現(xiàn)來(lái)說(shuō)說(shuō)這個(gè)名字 rgba32

r 就是red 分量??g 就是green 分量 b blue??a alpha

一個(gè)分量占1個(gè)字節(jié) 也就是256

還記得這個(gè)代碼不

[UIColor colorWithRed:219.f/255.f green:220.f/255.f blue:221.f/255.f alpha:1];

就是這個(gè)玩意兒

32 就是4*8 = 32 32位量化深度

以前非智能機(jī)的時(shí)候

幾千萬(wàn)色 記得沒？

就是說(shuō)色彩量化深度

有2位色??就是黑白

8位色 16位色?

現(xiàn)在真彩色 32位色

影響的是你屏幕的還原度

比如黑白電視機(jī) 和彩色電視機(jī)

黑白電視機(jī)就是1位量化深度

就是0 1

0 就是黑 1 就是白

彩色電視機(jī) 32位量化

可以顯示理論上 2的32次方中顏色

這就是幾千萬(wàn)色的由來(lái)

2的32次方??大概就是6000多萬(wàn)

以前諾基亞有一款手機(jī)?

真色彩 6400 還是6500萬(wàn)色

就說(shuō)的顏色深度

ok 轉(zhuǎn)化成rgba 之后

也要看壓縮算法

凡事有損壓縮 肯定要 有所損失

成rbga 之后 下面就該壓縮了對(duì)吧

現(xiàn)在有兩種壓縮 一種硬件壓縮 一種軟件壓縮

硬件壓縮都知道 蘋果自帶了

軟壓縮 就是 ffmpeg(不熟悉的百度一下)

硬壓縮好處是 速度快 因?yàn)間pu 專門干這個(gè)

軟壓縮就是把gpu 干的活讓cpu 來(lái)干

現(xiàn)在主流的壓縮格式 是h264 或者 vp8

相比較而言

h264 適合動(dòng)態(tài)壓縮??vp8 適合靜態(tài)

但是 圖像哪能不動(dòng)對(duì)吧 所以h264 要好一些

現(xiàn)在可以說(shuō) 主流是硬壓縮??(我說(shuō)ios 上)

至于vp8 是啥 這是谷歌的視頻壓縮算法

最新的 h265 更牛逼

當(dāng)然 運(yùn)算量更大 專利費(fèi)也更貴

所以現(xiàn)在使用h264肯定主流

h264 壓縮算法 我看過(guò)

現(xiàn)在的h264 是不需要專利費(fèi)的

h265 現(xiàn)在還不太適合用在移動(dòng)端

運(yùn)算量達(dá)不到

總之吧??現(xiàn)在都是h264,反正我沒見過(guò)用vp8

包括蘋果壓縮都是264

至于你們說(shuō)的 什么rm 啊??什么 mk 啊

這些??就是文件后綴

或者什么mp4啊

有人說(shuō)這是格式

嚴(yán)格來(lái)講不對(duì)

這是封裝 不是格式

格式都是h264

這些里面裝的都是h264

只是封裝格式不同

h264 裸流 要經(jīng)過(guò)封裝之后才能給播放器識(shí)別

封裝格式針對(duì)的是視頻

裸流 就是沒有封裝格式的二進(jìn)制流

(m3u8 這是切片

切片用的hls 協(xié)議

跟我們現(xiàn)在說(shuō)的直播rtmp 協(xié)議不一樣

hls 延遲很高

rtmp 理想狀態(tài)是3秒不到

如果cdn 給力??1秒也不是不可能

his 不行

)

舉個(gè)栗子

你現(xiàn)在在北京

然后服務(wù)器也在北京

你上傳的圖像 很快能到服務(wù)器上

但是廣東的用戶 拉流很慢

怎么辦脯爪？那就在廣東布一臺(tái)服務(wù)器

讓北京服務(wù)器直接跟廣東服務(wù)器專線通信

專線的速度你懂的

這就相當(dāng)于廣東用戶直接拉流北京的東西

然后 不管軟編碼 還是硬編碼??最后出來(lái)的都是h264裸流

而且是經(jīng)過(guò)美顏的對(duì)吧

這 時(shí)候 就要做封裝了

(為啥要做封裝?

封裝的意義

就在于要把聲音和圖像同步

)

這個(gè)封裝就是把聲音和圖像同步

現(xiàn)在簡(jiǎn)單的同步就是 記錄時(shí)間戳

用時(shí)間戳同步

有時(shí)候你們看電影

會(huì)有音畫不同步的問題

那就是沒封裝好

同步就是根據(jù)時(shí)間戳來(lái)

(

我以前用手機(jī)看電影,一開始是同步的,看著看著就不同步了

那是累積偏差?

越來(lái)越大 越來(lái)越大

然后沒有修正

就這樣

)

(軟編碼跟硬編碼什么區(qū)別啊?

硬 是gpu來(lái)做從結(jié)果來(lái)看沒區(qū)別

軟編碼是cpu 來(lái)做

gpu 能干的cpu 都能干

反過(guò)來(lái)不行

)

封裝之后就是flv?

flv 就相當(dāng)于mp4

或者mk

就是個(gè)封裝格式

之所以采用flv 原因很簡(jiǎn)單

兼容瀏覽器

瀏覽器的flash 可以無(wú)縫兼容flv

另外由于這個(gè)封裝相對(duì)簡(jiǎn)單

所以就采用了flv

然后封裝之后就要開始推流了

推流使用的是rtmp協(xié)議 這個(gè)是機(jī)遇tcp可靠傳輸協(xié)議

為啥用tcp呢则北？

為啥不用upd矿微？

因?yàn)閡pd 不可靠傳輸!

容易丟包

丟包之后可能花屏

所以你們看直播

很少看到有花瓶的

你們?nèi)ビ梦⑿乓曨l呢

很容易花屏

因?yàn)槲⑿庞玫膗pd 協(xié)議

而直播用的tcp

直播基本上都是tcp

現(xiàn)在有最新的據(jù)說(shuō)upd 重傳(upd本身不支持重傳)

但是我只是聽說(shuō) 沒見過(guò)

客戶端推流可能會(huì)有阻塞

因?yàn)榫W(wǎng)絡(luò)差

我采集端一致在采集

推流是主播到服務(wù)器

服務(wù)器到客戶是拉流

另外推流還有緩沖期

緩沖區(qū)的作用就是作為一個(gè)平滑過(guò)渡

舉個(gè)栗子

比如某一瞬間

網(wǎng)絡(luò)很不好

流推不出去

咋辦？ 不能扔了不要把尚揣？

扔了不要 觀眾那邊就看不到了

那就先放進(jìn)緩沖區(qū)

等網(wǎng)絡(luò)好了我再推出去

但是如果 網(wǎng)絡(luò)不好的時(shí)間很長(zhǎng) 涌矢，緩沖區(qū)都滿了

咋辦？

觀眾那邊就會(huì)看到阿花剛剛正在脫衣服快骗，就快到關(guān)鍵時(shí)刻了

下一個(gè)畫面看到的是阿花衣服已經(jīng)穿好了

多他媽掃興

緩沖區(qū)時(shí)間不能過(guò)大也不能過(guò)小

過(guò)大娜庇，觀眾那邊遲遲看不到畫面

過(guò)小??起不到緩沖的作用

緩沖區(qū)一般又個(gè)1～2秒的數(shù)據(jù)容量就差不多

音頻編解碼上又個(gè)Jitterbuffer

起的作用其實(shí)跟視頻的緩沖區(qū)其實(shí)是一樣的

那就是拉流的過(guò)程了

流到了服務(wù)器之后

客戶端現(xiàn)在一般現(xiàn)成的 比如ijkplayer 拉流

這個(gè)過(guò)程相對(duì) 推流簡(jiǎn)單很多 就不廢話了

就是一個(gè)反向過(guò)程

不需要客戶端做啥處理 直接丟包給播放器播放就行了

這是整個(gè)直播系統(tǒng)大概的流程

理論上來(lái)講 美顏是去不掉的

這是直播系統(tǒng)。當(dāng)然 還有 實(shí)時(shí)音視頻系統(tǒng)?

比如webrtc方篮。名秀。。藕溅。這個(gè)匕得。。巾表。汁掠。暫時(shí)不講

采樣 美顏 編碼 封裝 推流 拉流 解封裝 解碼 播放

那是必然的

在服務(wù)器端做美顏也是可以的

不過(guò)需要服務(wù)器先解碼，解碼成采樣數(shù)據(jù)之后 美顏攒发，美顏完成之后再編碼 這樣

美顏只能對(duì)采樣數(shù)據(jù)進(jìn)行

對(duì)編碼之后的數(shù)據(jù)不行

總之這就是 直播系統(tǒng)了

說(shuō)來(lái)過(guò)程其實(shí)并不復(fù)雜

還有一種 就是 微信的實(shí)施語(yǔ)音視頻聊天

這種调塌，并不屬于直播

因?yàn)槭莡gp.

cpu 比你想象的快的多

現(xiàn)在直播項(xiàng)目都不是什么特別難的技術(shù)了

技術(shù)難點(diǎn)在于服務(wù)端的并發(fā)

難的比如還是音視頻這塊

實(shí)時(shí)的語(yǔ)音視頻

p2p

服務(wù)端做不好 客戶端沒卵用

實(shí)時(shí)音視頻

我剛說(shuō)了??直播延遲 3秒

webrtc 可以做到300ms 之內(nèi)(常人極限反應(yīng)50ms)

類似 qq視頻??微信視頻

qq早期買的Global IP Solutions技術(shù)

webrtc 使用rtc 協(xié)議 實(shí)際上就是udp 協(xié)議的封裝

rtp協(xié)議

rtp rtcp協(xié)議?

不講這個(gè)?

這個(gè)太復(fù)雜

wszcug 大佬都弄了三年

這里面非常多好的 音頻壓縮算法

就不說(shuō)了(我也不會(huì))

最后送大家一句 wszcug 大佬的話

其實(shí) 技術(shù)永無(wú)止境