前端視角看視訊處理

TNTWEB發表於2022-06-10

最近在做某視訊剪輯專案的後端開發,之前對於視訊的處理一直是空白狀態。專案中涉及到的很多概念,隨著不斷的接觸,有了一個從模糊到清晰的認知。

視訊,英文:video,直譯為視覺畫面的頻率,最原始的含義,應該是隨著時間的流逝不停地播放畫面,進而產生了一種視覺上連續的效果,彷佛重現了現實世界的場景。

畫面更新頻率

上圖是一組小人跑步的圖片集合(擷取部分片段),組成的圖片序列。當我們設定成連續自動播放後,就會形成一個最簡單、最原始的視訊。

2fps4fps6fps8fps10fps

10fps = 每秒鐘播放 10 張畫面,即每張圖片的視覺停留時間為 0.1秒 (1 / 10)

如上圖所示,每張圖停留從0.5秒到0.1秒不等,當以不同的速度播放畫面時,會產生不同的視覺效果。這裡就引出了視訊中很重要的一個概念:畫面更新頻率,也即幀率(英文:Frame rate,frame per second,FPS)。畫面更新頻率由早期的每秒6或8張,到現在的每秒 120 張不等。

幀數為多少時,可以保證視訊畫面的流暢?

通常在二十四幀以上,人類肉眼的“視覺暫留”和“腦補”現象,前者是指人類視網膜在光訊號消失後,“殘像”還會保留一定時間的現象;後者是大腦自行補足畫面中間幀的“腦補”功能。它們的混合作用,讓我們誤以為每秒24幀回放的照片是連續的。

從這裡可以知道,從視訊裡看到的畫面,可以無限逼近現實的場景,卻很難還原真實的世界。就像數學裡的極限,視訊裡呈現的是分段函式,永遠不能呈現平滑的曲線,可以無限接近去擬合。

視訊大小比例

常見的視訊有720P、1080P、4K等

P,是英文progressive的縮寫,表示視訊畫面擁有的畫素行數。現在的攝像頭都是逐行掃描,即對每一行的畫素逐一掃描。1080P,表示高度為1080行畫素的視訊

例如,1080P視訊一般是1920×1080,即約200萬畫素,而720P視訊則是1280×720,即約92萬畫素。

K,表示視訊的水平解析度,可以理解成每一行的畫素總數。

例如,2K視訊一般是2048×1080,4K視訊一般是 4096×2160(或者:3840×2160 家電顯示器上標準 )

視訊的比例,表示視訊畫面的長和寬的比值。常見的視訊比例有4:3,16:9。

可以看到 4:3的比例,比 16 : 9的比例更方正,更適合閱讀,大部分的書籍或電子閱讀器的螢幕,採用這個比例。

16 : 9,就是俗稱的寬屏,更適合看電視高清視訊或DVD。手機豎著擺放時,拍出照片的比例一般為 9 : 16

軌道

視訊中的軌道,可以想象成各自獨立執行的火車鐵軌,自變數都是時間,因變數是不同軌道上的素材引數。包含背景、視訊、音訊、字幕等軌道。

如上圖所示,類似於,前端web中絕對定位的層疊在一起的DIV塊,或者圖片中的圖層,區別在於視訊中的軌道是隨時間軸不斷延續的。每一條軌道都是獨立存在,可以在單條軌道上自由編輯。除此之外,還可以新增濾鏡、特效、花字、轉場、文字等效果。

濾鏡,和CSS3中的filter屬性是一個意思,相當於是給圖片新增濾鏡,用來實現影像的各種特殊效果,比如灰色、顏色反轉、黑白、馬賽克、銳化等。可以讓畫面呈現另外一種風格,濾鏡實現的效果也非常炫酷,比如開啟美顏濾鏡,瞬間返老還童。背後是一組濾鏡函式,常見的有scale(縮放)、、overlay(疊加)、rotate(旋轉)等

  • 文字的處理,用於實現視訊的字幕、旁白、解說等效果。
  • 轉場很好理解,電視劇中主角突然做了個夢,回到小時候的場景,畫面就切過去了
  • 特效,比如西遊記中騰雲駕霧的效果,武俠電視劇中喬峰大俠的降龍十八掌等等。

視訊編解碼

影像深度,每個畫素點佔據的儲存空間(BPP,byte per pixel,畫素深度),決定了圖片的顯示品質。假如一副彩色影像,每個畫素用R(紅)G(綠)B(藍)三個分量表示,每個分量佔據8位,則一個畫素需要佔據24位,即3個位元組大小。

位元率:每秒傳送的位元(bit)數。單位為bps(Bit Per Second),位元率越高,傳送資料速度越快。

未經過壓縮的視訊資料,佔據的儲存空間非常大,不便於在網路中傳輸。假如視訊每秒播放30張圖片,每張圖片的寬高分別為300和200畫素,每個畫素點需要24位元(每個位元組為8位,即3個位元組)的儲存空間,則一秒鐘的視訊佔據多大的空間呢。

FPS(幀率)size(影像寬高)BPP(影像深度)BPS(位元率)file size(KB)
30300 ✖️ 200241M5273

資料量約為 5.3M,按照1M傳輸頻寬計算,位元率是131072位元組/秒(1Mbps=131072位元組/秒=128kb/s=0.125M/S),則需要等待40多秒鐘。這還不算其它軌道的資訊,一般的視訊都有音訊軌道、字幕的。

視訊是可以壓縮的,因為原始視訊包含大量的冗餘資訊,比如:人的視覺系統有一些先天的特性,對某些細節不敏感。從理論上分析,基於人的視覺特性去掉視訊冗餘資訊既可以保證視訊質量又可以壓縮視訊體積。

  • 預測:通過幀內預測和幀間預測降低視訊影像的空間冗餘和時間冗餘。
  • 變換:通過從時域到頻域的變換,去除相鄰資料之間的相關性,即去除空間冗餘。
  • 量化:通過用更粗糙的資料表示精細的資料來降低編碼的資料量,或者通過去除人眼不敏感的資訊來降低編碼資料量。
  • 掃描:將二維變換量化資料重新組織成一維的資料序列。
  • 熵編碼:根據待編碼資料的概率特性減少編碼冗餘。

視訊編碼的國際標準組織:l ITU-T(國際電信聯盟通訊標準部)視訊編碼標準以H.26x的形式表示,主要為視訊會議和可視電話等實時視訊通訊應用設計的。

ISO/IEC(國際標準化組織;I國際電工技術委員會)標準以MPEG-x的形式表示,主要為視訊儲存(DVD)、廣播視訊以及視訊流(例如,網上視訊、無線視訊應用)設計的。

視訊編碼標準演變

上圖可以清晰地看到各種編碼的演進歷史。當前通行的編碼標準為ITU-T組織的H.26x系列視訊編碼和MPEG組織制定的部分編碼標準,同一標準在不同的組織叫法可能不同。比如,AVC(高階視訊編碼),大家可能更熟悉它的另一個名字——H.264,AVC是MPEG組織在標準中給它起的名字。

專案實踐

目前接觸過OpenCV 和 FFmpeg 兩款開源的視訊處理庫。OpenCV是計算機視覺的處理庫,開源、跨平臺,提供了C++、Python 和 Java 介面,多用於基於機器學習及深度學習的計算機視覺應用場景。FFmpeg是一套可以用來記錄、轉換數字音訊、視訊,並能將其轉化為流的開源計算機程式。openCV中會包含FFmpeg,更加專注於影像方面的處理,而FFmpeg提供了強大的視訊加工能力。在最近參與的專案中,兩者均使用到了。

上圖展示了,視訊剪輯專案的業務處理流程。

  • 解析專案的配置後,初始化專案的工作目錄
  • 解析素材地址,並下載到本地目錄
  • 採用多執行緒和多程式結合的方式,渲染素材媒體,控制併發數
  • 底層呼叫 OpenCV 和 FFmpeg,合成視訊,生成目標格式
  • 新增片頭、片尾以及水印等,上傳到雲端
  • 刪除中間環節產生的檔案,釋放系統資源

web前端延展

上圖粗淺地展示了瀏覽器執行頁面的過程,從輸入頁面地址,到最終呈現檢視,經歷一些列的過程。在某種程度上,可以將瀏覽器視作特殊的視訊播放器,它也是一幀一甄的處理頁面。

當遇到網路延遲或電腦效能問題時,便會出現卡頓的現象。這種問題,主要是由於丟幀造成的,某些關鍵的畫面幀沒有展示出來,進而無法在腦海中形成連續的畫面,給人一種斷層的感覺。

FFCreator

我們團隊推出的 FFCreator 是一個基於 node.js 的輕量、靈活的短視訊製作庫。您只需要新增幾張圖片或視訊片段再加一段背景音樂,就可以快速生成一個很酷的的視訊短片。

你可以為視訊新增音樂、字幕、文字、虛擬主播等各種元素。當然可以非常方便的來製作單個或批量資料視覺化類的視訊。

特性

  • 完全基於node.js開發,非常易於使用,並且易於擴充套件和開發。
  • 依賴很少、易安裝、跨平臺,對機器配置要求較低。
  • 視訊製作速度極快,一個 5 分鐘的視訊只需要 1-2 分鐘。
  • 支援近百種場景炫酷過渡動畫效果。
  • 支援圖片、聲音、視訊剪輯、文字等元素。
  • 支援字幕元件、可以將字幕與語音 tts 結合合成音訊新聞。
  • 支援圖表元件,可以製作資料視覺化類視訊。
  • 支援簡單(可擴充套件)的虛擬主播,您可以製作自己的虛擬主播。
  • 包含animate.css90%的動畫效果,可以將 css 動畫轉換為視訊。

FFCreator官方網址:https://github.com/tnfe/FFCre...

總結

本文粗淺地介紹了視訊處理的一些基本概念,結合實際專案中遇到的困惑,逐一展開解釋。然後,介紹了一些業務專案的處理過程,以及和Web前端的關聯。最後,推薦一款我們團隊自主研發的視訊處理工具,感興趣的小夥伴歡迎點贊收藏。

相關參考

https://github.com/tnfe/FFCre...

Wetzel C D, Radtke P H, Stern H W. Instructional effectiveness of video media[M]. Lawrence Erlbaum Associates, Inc, 1994.

https://github.com/sitkevij/a...

https://www.jianshu.com/p/6ef...

https://www.zhihu.com/questio...

https://www.zhihu.com/questio...

https://blog.csdn.net/longsan...

http://www.360doc.com/content...

相關文章