本文將介紹的是:
2019年4月8日首次完成該文章,內容包括:
2019年9月7日進行二次修改,修改內容如下:
相信所有人對視頻一定不陌生,平時也一定經常在各大視頻網站(如騰訊視頻、嗶哩嗶哩)瀏覽,甚至偶爾也會把視頻緩存到本地,保存成.mkv,.avi文件之類啦。前者是我們常說的『網絡流媒體』,后者是『本地視頻文件』。提到這里,兩個問題來了:
介紹第一個問題之前,必須引入一個名詞『視頻封裝格式』,簡稱『視頻格式』,也稱為『容器』。有的說法還要區分是視頻文件格式和視頻封裝格式,本文統一稱『視頻封裝格式』。
問題1:本地視頻文件常見有MP4、MKV、AVI等,這些都是什么?有什么區別?
首先,MP4、AVI、MKV都是本地視頻文件的后綴,在windows系統下,用于提示操作系統應該采用哪個應用程序打開。而在流媒體領域,這些都被稱為『視頻封裝格式』,因為除了音視頻流之外,它們還包含了一些輔助信息以及組織視音頻的方式。不同格式的視頻在不同平臺上用戶體驗不同,很大原因在于對視音頻的組織方式帶來的差異。筆者以為百度百科上的解釋蠻通俗易懂的(維基百科的說法不夠直白):
視頻格式是視頻播放軟件為了能夠播放視頻文件而賦予視頻文件的一種識別符號。
簡言之,視頻格式規定了和播放器的通信協議。
其次,筆者最近準備開始深入研究MP4、AVI、MKV等內部原理,主要是對視音頻的組織方式,比如在播放視頻的時候,我們可以選擇國語、粵語、英語等各種語言,這就意味著這段視音頻中包括了多個音頻流。【給自己留個坑吧。】
最后,筆者推薦一篇非常棒的博客:視頻文件格式知多少,匯總的非常全。
問題1引申:對要做視音頻處理的開發們來說,接觸MP4、MKV、AVI等各種格式視音頻文件時,有什么需要注意的嗎?
視音頻處理可以延展出很多領域,包括解碼、編碼、過濾、增強處理等等。筆者目前只在解碼領域探索,答案是:對于解碼而言,沒有區別。其他領域暫不清楚。
『視頻封裝格式』,是在編碼的視音頻基礎上進行一次“包裝”,添加與播放相關的協議數據(這個是筆者的認知,如有表述不準確,歡迎批評指正)。目前主流開源的框架,在“解包裝”工作上做的已經非常成熟了,如FFMpeg
,提供了用于打開視音頻的API,開發人員無需關注具體視頻格式,直接可以取出視音頻流做處理。
接下來,介紹第二個問題,筆者再引入名詞『視頻協議』,也有說法認為『視頻協議』也屬于『視頻封裝格式』。
問題2:在騰訊視頻、嗶哩嗶哩網上看的視頻,與本地播放的MP4、MKV、AVI文件,有什么區別?
『視頻協議』是針對網絡流媒體而言的,也就是只有在有網絡時通過瀏覽器或者移動端APP才能看到的視頻,目前常見的協議有RTSP、RTMP、HLS、HTTP等。筆者短暫地接觸過GStreamer開發,在連接到RSTP視頻時,發現除了視音頻流和metadata之外,還攜帶了播放的信令。
也有文章會把『視頻協議』歸入『視頻封裝格式』。筆者看來,這么分類也有其道理:『視頻協議』和『視頻封裝格式』都同時攜帶了視音頻和metadata,以及協議/格式需要的其他信息。以FFMpeg
為例,并不區分視頻格式和視頻協議;但是GStreamer
的話,還時需要指定『視頻協議』,但是不區分『視頻封裝格式』。
剝開『視頻封裝格式』和『視頻協議』的外殼,接下來了解視音頻流本身,這才是流媒體領域中真正的主角。本文僅介紹視頻流。
就視頻流而言,相信大家平時一定經常聽到類似“h264碼流”、“yuv流”、“編碼流”、“解碼流”,“原始流”、“裸流”,“壓縮后的流”或者“未壓縮的流”等等。歸納而言,提到『視頻流』的時候,一定只有兩種形式:
總結出現的名稱,“h264碼流”、“編碼流”、“壓縮后的流”是壓縮/編碼后的視頻流;而“yuv流”、“解碼流”、“未壓縮的流”則是未經壓縮/編碼的視頻流。“裸流”是一個具有歧義的詞,是上下文內容,既可以是前者,也可以是后者。
因此,如果以后閱讀任何流媒體相關的文章時,看到『視頻流』都應該搞清楚,這究竟是編碼/壓縮的,還是沒有。在生活中,接觸到的視頻文件絕大部分都是編碼/壓縮后的;在網絡傳輸場景中,絕大部分也是編碼/壓縮后的。只有在視頻播放時,觀眾觀賞到的時一幀幀被『轉碼』為『RGB』的解碼后視頻流。
編碼/壓縮在流媒體領域是一項非常重要的技術:從『H264碼流』到『YUV流』的過程稱為解碼,反之稱為編碼。
流媒體領域,『流』很重要,『流』的基本元素『幀』同樣重要。原因在于:對于視頻編碼/壓縮而言,它的核心是采用盡量小的空間存儲一組時間上連續的幀數據;而對于視頻解碼而言,就是把被編碼/壓縮后的一組幀數據盡量恢復成原來的樣子。能夠被100%恢復的編碼/壓縮算法稱為無損壓縮,反之稱為有損壓縮(雖然無損壓縮是最理想的,但是在很多實際場景中為了追求高壓縮率,比如為了減小網絡帶寬壓力,常常不得不選擇有損壓縮)。由此可見,『幀』是視頻流媒體領域的核心。接下來,一起來認識什么是『幀』。
『幀』,可以聯想成我們平時看到的一幅幅“圖像”,只不過我們平時接觸的圖片是『RGB』格式的,而視頻幀通常是『YUV』格式的。既然提到了『RGB』和『YUV』,那么就來了解下幀的格式『YUV』,引出第一個問題:
問題3:幀為什么采用『YUV』格式?『YUV』是什么?
為此,筆者曾經花了很久去了解顏色空間、電視成像的發展史等,整理結論如下:
接下來解釋『YUV』是什么,筆者以為,『YUV』是一種廣義的概念,在視頻領域,當提到『YUV』的時候,往往是以下幾個意思:
“Y”表示明亮度(Luminance、Luma),“U”和“V”則是色度(Chrominance)、濃度(Chroma)。這里表示的是色彩空間的基,即類似XYZ坐標系的一種色標表示基準,也就是說每一種顏色可以通過三維向量<y^i^,u^i^,v^i^>來表示。與其類似的還有RGB顏色空間、HSV顏色空間等。下圖來自How does the YUV color coding work?
隨著通信行業的發展,實際應用之多之復雜,導致『YUV』衍生出了一個大家族。接觸視頻領域的一定聽說過YCbCr,甚至還有YPbPr、YIQ等。它們有的已經被時代淘汰,有的現在還在使用。之所以出現『YUV』大家族,完全是因為實際電路系統之間的差異,導致要從『YUV』轉到『RGB』空間,實際對應的轉化系數是有些許差異的,于是各個部門開始制定各種規范,才有了我們現在看到的『YUV』大家族。
YCbCr是專門針對數字電路而誕生的;YPbPr則是模擬電路。但是,現在是數字時代,所以為了模擬電路而生的YPbPr已經逐漸被淘汰了,而YCbCr還一直發揮著作用。因此現在,YCbCr有時也會被簡單地稱為/認為『YUV』。
2. 采樣率
讀者可能聽說過“YUV444”,“YUV422”,“YUV420”,到這里可能會納悶:“YUV不是顏色空間嗎?為什么后面還會跟著一串數字?” 因為當你看到YUV后面跟著一串數字的時候,『YUV』已經不再是顏色空間的基的含義了,而是意味著在原始『YUV流』上的采樣。
在以前流媒體剛剛興起時,還沒有什么4G/5G,當時為了減小網絡傳輸的帶寬的壓力,可謂做了種種努力。除了編碼/壓縮之外,YUV采樣率也是一種。
444,422和420是三種『YUV』(在數字電路中指代YCbCr)的采樣,三位數分別代表Y\U\V(數字電路中為Y\Cb\Cr,本段后同)通道的抽樣比。所以可以理解,444是全采樣;而422是對Y進行全采樣,對U\V分別進行1/2均勻采樣。有趣的問題來了,420難道是完全丟棄了V通道/分量數據嘛?答案是否定的。
首先,必須要搞明白一個問題,一幀圖像是由一個個像素組成的矩形,譬如4x4的尺寸的圖像,就是由16個像素點組成的。在平時接觸的『RGB』圖像中,每個像素必然至少由R\G\B這三個通道組成的(有的圖像還有\alpha分量),每個分量的取值一般都是[0,255],也就是[2^0,2^8],因此經常說一個像素占用3字節(如果還有其他分量,比如RGBA,就另當別論)。『YUV』圖像同理,它的每個像素是由Y\U\V組成的。
接下來,從整張圖像宏觀考慮采樣問題。還是以4X4的圖像為例,444的如下圖2-1,這個是形象化成圖像的樣子,實際在機器內存儲并不是這樣,具體可以參見博客《圖像原始格式一探究竟》。422和420分別如下圖2-2和2-3。
?圖2-1對應YUV444采樣,即全采樣,圖示中可以看出每個像素中的Y\U\V通道都保留下來了,一般來說YUV444太大了,因此很少使用。
圖2-2對應YUV422采樣,這種采樣方式是:每個掃描線或者說每行相鄰2個像素,只取1個像素的U\V分量。此外,可以計算出來,每個像素占用的大小為原來的2/3,因此說YUV422是YUV444的2/3大小。
這個時候就有一個問題,在『YUV』轉『RGB』時,被抽走了U\V分量的像素要怎么辦呢?做法很簡單,就是相鄰2個像素的Y分量公用保留著的U\V分量。
圖2-3對應YUV420采樣,這種采樣方式是:隔行進行YUV422每行采樣的辦法,即相鄰2個像素只取1個像素的U\V分量;下一行丟棄所有的U\V分量。此外,可以計算出來,每個像素占用的大小為原來的1/2,因此說YUV420是YUV444的1/2大小。恢復U\V分量的辦法同YUV422,只不過這里是2X2的矩陣共享保留著的U\V分量。
這種設計辦法真的很巧妙!前文提到的"人眼對UV的敏感度最低,因此可以極大比例地壓縮UV兩個通道的數值",且對于圖像而言,相鄰的區域像素的色彩、飽和度一般非常接近,因此這種以2X2矩陣為基本單位,只保留1組U\V分量合情合理。
3. 編碼/存儲格式
大家肯定還聽說過YV12、YU12、NV12、NV21吧,看到這里是不是又納悶:“后面的數字怎么變成2個了?而且前面的英文字母還變了?”
以上統稱為『視頻的存儲格式』,也就是說,計算機是如何存儲一幀視頻的。
首先,『視頻的存儲格式』總分為兩大類:『打包格式(packed)』和『平面格式(planar)』。前者又被稱作『緊湊格式(packed)』。其實除此之外還有『半平面模式(Semi-Planar)』,估計是使用的比較少,因此在很多文章中常被忽略。
筆者很感興趣,為什么會出現『打包格式』和『平面格式』兩大派系,網上搜了很多資料也沒找到原因,博客【音視頻基礎】:I420、YV12、NV12、NV21等常見的YUV420存儲格式提到了需要約定存儲格式,但也沒提到為什么會分成這兩種。要么就是派系之爭,類似貝葉斯學派和頻率學派;要么就是實際應用中逐漸衍生出這兩大格式。時至今日,這兩個格式還在被使用,因此對于多媒體開發者們都有必要了解。
『打包格式』是把Y\U\V分量交叉存儲,『平面格式』則是把Y\U\V嚴格分開存儲,『半平面模式』介于兩者之間,Y分量分開存儲,U\V交叉存儲。
以下圖為例說明『打包格式』、『平面格式』和『半平面模式』應該是非常清楚的,圖摘自博客YUV格式初探:
但是關于上圖的『打包格式』,筆者是是有一點疑惑的,大多數的說法是”Y\U\V通道交叉存儲,相鄰的像素盡量打包在一起“,圖3-3中U1后面跟著的是U2而不是V1,而且Y\U\V的排列方式似乎也不完全是交叉?筆者嘗試在網上搜索『打包格式』更多的例子,沒有找到特別好的資料,【這里給自己挖一個坑吧】。
接下來,我們繼續了解一些幀相關的概念。
常見的幀名詞
『幀率』『分辨率』和『碼率』三者之間的關系
最理想的情況是畫面越清晰、越流暢是最好的。但在實際應用中,還需要結合硬件的處理能力、實際帶寬條件選擇。高『幀率』高『分辨率』,也就意味著高『碼率』,也意味著需要高帶寬和強大的硬件能力進行編解碼和圖像處理。所以『幀率』和『分辨率』應該視情況而定。
要說三者之間的關系,其實就是對于『碼率』的理解。在碼率(BPS)概念中提到了幾段摘自網上的說法,說的都太模糊了,筆者直到閱讀了文章Video Bitrate Vs. Frame Rate,才真的理解了『碼率』。
首先,這些說法都沒有交代一個前提:『幀率』、『分辨率』和『壓縮率』都會影響『碼率』。Video Bitrate Vs. Frame Rate](https://www.techwalla.com/articles/video-bitrate-vs-frame-rate)文章在一開始就明確指出:
Bitrate serves as a more general indicator of quality, with higher resolutions, higher frame rates and lower compression all leading to an increased bitrate.
『碼率』是更廣泛的(視頻)質量指標:更高的『分辨率』,更高的『幀率』和更低的『壓縮率』,都會導致『碼率』增加。
文章后面又特別強調『分辨率』和『壓縮率』對『碼率』的影響:高分辨率意味著圖片可以包括更多的細節,低壓縮率意味著圖片壓縮損失越少,即失真越少,越清晰。那為什么不特地討論『幀率』呢?筆者認為原因有二:一個是『幀率』的影響非常直觀,每秒幀數增加必然導致數據量增加;另一個是實際應用場景中『幀率』是相對固定的,我們觀看的一般視頻都在25-30fps之間,現在一些高幀視頻是60fps,可見視頻『幀率』在實際場景中被討論的很少。
奇怪的幀名詞:1080p和1080i、場
筆者僅僅出于覺得有趣才放上來的,1080p和1080i、場都是相對比較“老”的概念了,在還是CRT電視的時代,顯示器顯示畫面都是靠電子槍一行一行掃描畫面才能產生一副完整的圖像,這就被稱作『場』,后來這個名詞也不常使用了,被取代它的是『幀』。【科技在進步,過時的概念、應用都會被新興的替換,所以真的要不斷學習緊跟時代啊!】
1080p和1080i也是『場』同一時期的概念:
既然都是老概念了,那為什么還要再提呢?借用文章1080P和1080i是什么意思?的一段來說:
進入液晶時代的如今,隔行和逐行其實已經沒有太大的意義了,現在的電視或者是顯示器都屬于固定像素設備,像素點同時發光,并不需要掃描,但是硬要說的話可以認為現在的顯示設備都是逐行掃描的,但也并不是說1080P和1080i等就可以淘汰了,畢竟還涉及到攝像機的格式,不過普通觀眾也不會關心是用什么攝像機拍的,只關心呈現出來的樣貌就好了。
視頻『幀』和編解碼密切相關,因此還有不少『幀』的概念是和視頻編解碼相關的。
視頻編解碼而衍生的幀名詞
I/P/B幀,并不是依據視頻幀數據內部的元素的不同來區分的,從解碼后的幀本身而言,它們沒有任何區別。僅僅是在編碼時,對幀處理的方式不同而已。
這個概念在做視音頻同步的時候特別重要,尤其是PTS,目前常見的視音頻同步的三種策略“同步到音頻的PTS”、“同步到視頻的PTS”和“同步到系統/外部時鐘”,都是基于PTS完成的。
快搜