近來，整個機器學習領域似乎被大型語言模型（LLM）和檢索增強生成（RAG）所掩蓋。雖然許多用例可以從這些新的基礎模型中受益，但在非文本數(shù)據(jù)方面仍存在差距。我常把當前的機器學習階段比作汽車工業(yè)中從燃油車向電動車的轉變。燃油車已經(jīng)有完善的基礎設施（如汽車服務、加油站等），而電動車的充電站和專用服務地點尚未成熟——但它們正在追趕。

這個比較的重點在于：基于變壓器的模型在許多用例中已經(jīng)證明了它們的實用性，但在視覺任務上，它們仍需要時間來超越已有且成熟的系統(tǒng)。然而，今天的重點是工程——特別是如何解決使用機器學習的嵌入式視頻流應用中的延遲問題，因為視頻讀取/處理/流媒體是視覺系統(tǒng)的核心。

一、什么是視頻處理？

視頻處理是指一組用于操作和分析視頻流的技術和方法。我們來看看描述視頻處理時必須了解的關鍵組件：

1. 編碼器

編碼器是一種硬件或軟件過程，用于壓縮（編碼）和解壓縮（解碼）大量視頻和音頻數(shù)據(jù)。它們對于減少視頻/音頻文件大小和流媒體至關重要，因為一個原始視頻文件可能占用非常大的空間。例如，一個60秒、1920x1080、30 FPS的視頻文件的原始大小計算如下：

W = Width (pixels)
H = Height (pixels)
FPS = Frame Rate (frames/s)
BIT = Bit Depth (bits per pixel)
DUR = Duration (video length in seconds)

File Size (bytes) = W x H × FPS x BIT x DUR
File Size (bytes) = 1920 x 1080 x 30 x (24 / 8) x 60 = 11197440000 (bytes)
File Size (mbytes) = 11197440000 / (1024 ** 2) = 10678,71 (mbytes)
File Size (gbytes) = 10678,71 / 1024 = 10,42 (gbytes)

如果要存儲和流傳輸視頻，YouTube只能存儲和流傳輸Pewdiepie的頻道——由于存儲和網(wǎng)絡限制，不會有其他內容。

常用的視頻壓縮編碼器包括：

• H.264（AVC）：高效，兼顧質量和相對較小的文件大小，兼容幾乎所有視頻播放器和流媒體服務。
• H.265（HEVC）：在相同的視頻質量水平下提供更好的數(shù)據(jù)壓縮。
• VP9：由Google開發(fā)，主要用于YouTube等平臺的高清流媒體。

2. 比特率

指在給定時間內處理的數(shù)據(jù)量，通常以每秒比特數(shù)（bps）來衡量。在視頻中，比特率至關重要，因為它直接影響視頻的質量和大小：

• 高比特率：每秒數(shù)據(jù)量大，導致視頻質量高但文件大小也大。
• 低比特率：減少文件大小，導致視頻質量差，表現(xiàn)為視頻模糊或塊狀。

3. 分辨率

表示每個維度可以顯示的像素數(shù)。常見的分辨率有HD（1280x720）、FHD（1920x1080）和4K（3840x2160）。

4. 幀率

描述每秒顯示的單獨圖像數(shù)量。我還記得在一臺破舊的電腦上玩GTA4時得到的9FPS。

5. 容器格式

如MP4和AVI，封裝視頻、音頻和元數(shù)據(jù)，管理數(shù)據(jù)的存儲和交換，而不影響質量。由于視頻容器的結構，它使得從一種視頻格式轉換為另一種視頻格式變得簡單。

具體術語包括：

• 源（SOURCE）：格式A的視頻。
• 解復用器（DEMUX）：將視頻流與音頻流分離的組件。
• 解碼器（DECODER）：將兩個流解壓縮為原始格式。
• 編碼器（ENCODER）：使用新的視頻和音頻編碼器重新壓縮原始流。
• 復用器（MUX）：重新鏈接并同步視頻流和音頻流。
• 目標（TARGET）：將新數(shù)據(jù)流（視頻+音頻）轉儲到新容器中。

二、使用Phon進行視頻處理的常見庫

在計算機視覺項目中，圖像處理和操作是必不可少的。從數(shù)據(jù)準備、標注、質量保證、增強和模型訓練，到模型部署后所需的預處理/后處理步驟，以下是計算機視覺工程師必須了解/使用的庫和工具：

1.OpenCV

2.Albumentations

用于數(shù)據(jù)集增強的快速高效庫，主要增強實現(xiàn)為GPU內核。

3.PyAV

包含Python的FFmpeg綁定，適用于需要更詳細控制原始圖像幀數(shù)據(jù)或音頻數(shù)據(jù)的情況。

+----------------+-----------------+--------------------------------+
| Feature        | YUV420          | RGB                            |
+----------------+-----------------+--------------------------------+
|                | Y, U, V         | Red, Green, Blue               |
|    Channels    | (Luminance and  |                                |
|                | two chrominance)|                                |
+----------------+-----------------+--------------------------------+
|   Storage      | Less storage    | More storage required due to   |
|   Efficiency   | due to          | for all three color channels.  |
|                | subsampling     |                                |
+----------------+-----------------+--------------------------------+
|   Bandwidth    | Highly          | Requires more bandwidth, all   |
|   Usage        | efficient for   | channels are fully sampled.    |
|                | transmission    |                                |
+----------------+-----------------+--------------------------------+
|   Complexity   | Higher          | Lower                          |
+----------------+-----------------+--------------------------------+
|   Suitability  | Better          | Better for image editing       |
|                | for video       | Universal compatibility        |
|                | compression and |                                |
|                | transmission    |                                |                |
+----------------+-----------------+--------------------------------+

三、視頻流方法

在需要實時流媒體的生產(chǎn)用例中，計算機視覺工程師經(jīng)常需要開發(fā)優(yōu)化的低計算視頻處理工作流程，尤其是在部署用例還包括目標檢測或分割模型并打算在邊緣設備上運行時。視頻解碼消耗大量CPU資源，部署在邊緣時，由于硬件資源有限，應盡可能利用已部署系統(tǒng)，同時保持資源和能源足跡較低。

在大多數(shù)計算機視覺項目中，處理是在邊緣完成的，要么是在可以訪問RTSP攝像頭的服務器上，要么是在本地轉儲幀或通過以太網(wǎng)流傳輸?shù)脑O備上。例如，為了解決工廠生產(chǎn)線中檢測不合格產(chǎn)品的問題，可以訓練和部署使用實時視頻流和分割模型的系統(tǒng)來識別風險區(qū)域。

另一個例子是通過目標檢測、深度預測和語義分割來識別商店貨架補貨時間的問題，實時提醒員工補貨。

本文將首先介紹使用Python實現(xiàn)的常見視頻流方法，以解決從API到客戶端應用實時流傳輸幀的問題。我們將使用FastAPI作為我們的流媒體API，并使用一個基本的React應用程序作為客戶端來演示這個概念。

我們將介紹三種方法：HTTP、WebSockets和WebRTC。對于每種方法，我們將迭代代碼，包括FastAPI和React，并說明該方法的最佳適用場景。

1.使用HTTP流媒體

這是一種快速且實用的方法，是驗證將視頻流傳輸?shù)絎eb應用程序的最直接的方法。對于小規(guī)模用例，這可能會奏效，但一旦應用程序擴展并需要支持許多設備或工作流流，由HTTP頭添加的延遲、開銷和帶寬就開始帶來挑戰(zhàn)。

FastAPI端點：

React Web端點：

2.使用WebSockets流媒體

與HTTP相比，Websockets提供了一種更高效的方法，因為它們允許更低的延遲、實時交互和更優(yōu)化的數(shù)據(jù)傳輸方式。與HTTP相比，HTTP是無狀態(tài)的，意味著你觸發(fā)端點并得到響應，在套接字上——一旦握手完成，只要連接處于Open狀態(tài)，數(shù)據(jù)就會流式傳輸。這導致了管理和“存儲”套接字狀態(tài)的需求，使它們成為有狀態(tài)的。

FastAPI端點：

React Web端點：

3.使用WebRTC流媒體

WebRTC（Web實時通信）是一種技術標準，它允許在不需要復雜的服務器端實現(xiàn)的情況下，通過P2P（點對點）連接進行實時通信。與HTTP和Websockets相比，這是一個更復雜的協(xié)議，它專門處理視頻/音頻流式傳輸。

無論是Zoom通話、Facetime、Teams還是Google會議——都是RTC在起作用！以下是它的主要組件：

• 數(shù)據(jù)通道：允許不同對等方之間任意交換數(shù)據(jù)，無論是瀏覽器到瀏覽器還是API到客戶端。
• 加密：所有通信、音頻和視頻都經(jīng)過加密，確保通信安全。
• SDP（會話描述協(xié)議）：在WebRTC握手期間，兩個對等方交換SDP提議和答復。簡而言之，SDP描述了對等方的媒體能力，以便他們可以收集有關會話的信息。SDP提議描述了對等方請求的媒體類型，而SDP答復確認已收到提議，并相應地交換其媒體配置。
• 信令：實現(xiàn)提議-響應通信的方法（套接字，REST API）。在我們的用例中，我們使用POST端點來打開通道。

隨著我們迭代了流式傳輸方法，讓我們看看它們的實際效果。完整代碼可以參考：

https://github.com/decodingml/articles-code/tree/main/articles/computer_vision， 安裝README文件中描述的所需軟件包，請運行以下命令：

W = Width (pixels)
H = Height (pixels)
FPS = Frame Rate (frames/s)
BIT = Bit Depth (bits per pixel)
DUR = Duration (video length in seconds)

File Size (bytes) = W x H × FPS x BIT x DUR
File Size (bytes) = 1920 x 1080 x 30 x (24 / 8) x 60 = 11197440000 (bytes)
File Size (mbytes) = 11197440000 / (1024 ** 2) = 10678,71 (mbytes)
File Size (gbytes) = 10678,71 / 1024 = 10,42 (gbytes)

當你啟動了FastAPI后端和ReactWeb前端，可以轉到瀏覽器中的localhost:3000并檢查結果。

結論

在本文中，我們介紹了視頻格式的結構及其關鍵組件，以理解視頻的工作原理。我們還介紹了一些廣為人知的庫，使得處理視頻/圖像數(shù)據(jù)變得容易。最后，我們逐步介紹了三種視頻流方法：HTTP、WebSockets和WebRTC。