將音頻+視頻流式傳輸到瀏覽器

Question

對於我的一個項目（在 C++，Linux 中），我正在尋找一種輕量級的方法（CPU 方面，也可以在沒有硬件加速的 raspberry pi 類似系統上運行的東西）用於將視頻 + 音頻流式傳輸到網絡瀏覽器。

僅對於視頻，mjpeg 適用於所有主要瀏覽器。

根據https://caniuse.com/#search=mpeg4我應該 mpeg4 用於視頻 + 音頻，不幸的是 mpeg4 不是輕量級的。 一種替代方法可能是 matroska 容器，但在僅受 vp8 支持的蘋果上，也有點重（？）。

所以我正在尋找使用什么的建議。 linux、mac 和 windows 支持該平台的主要瀏覽器。 帶寬使用不太重要。

Answer 1

解決方案取決於您是在尋找服務器端還是客戶端。

換句話說，以樹莓派 PI 為例，您希望 PI 是提供視頻的流媒體服務器還是播放視頻的主機。

以 PI 為例，對於 PI 是流媒體服務器的情況，您有多種選擇。

您可以將 PI 設置為簡單的 static 文件服務器並以這種方式提供 MP4，或者您可以使用許多可用的開源和第 3 方流媒體服務器解決方案，這些解決方案允許 PI 提供媒體服務器功能。 一些例子：

• ReadyMedia（以前是 MiniDLNA） - https://wiki.archlinux.org/index.php/ReadyMedia
• 叢-http://www.rasplex.com/get-started/rasplex-installers.html
• 基於 Kodi 的 OSMC - https://osmc.tv/download/

對於 PI 在播放端的情況，PI 文檔（ https://www.raspberrypi.org/documentation/raspbian/applications/omxplayer.md ）中記錄了本機播放器：

• omxplayer /opt/vc/src/hello_pi/hello_video/test.h264

對於您將在設備上或連接到設備上的攝像頭的情況，攝像頭解決方案本身通常支持編碼為常用格式。

例如，Raspberry PI 攝像頭解決方案支持 h.264 編碼，利用 PI 上的編碼硬件 - 請參閱此處了解更多信息：

• https://www.raspberrypi.org/documentation/raspbian/applications/camera.md

要了解這如何影響您的解決方案性能要求，值得研究視頻的編碼和傳輸方式。 高層次的步驟是：

• 為每幀捕獲的原始像素 bitmap
• 原始像素編碼（egh264 編碼）
• 編碼的視頻 stream 打包（有時稱為“混合”）到帶有音頻流、字幕等的容器中（例如 mp4 容器）
• 對於更高級的多用戶流式傳輸服務，也可以使用 ABR 流式傳輸，並將容器分成“塊”或分段進行流式傳輸（在 iOS 上使用 HLS 流式傳輸格式）。

用圖解法，大致是這樣的：

上述處理器最密集的步驟通常是編碼步驟 - 作為一個非常粗略的經驗法則，假設您正在尋找高質量的視頻 stream，編碼器提供的壓縮越多，以使文件或 stream 尺寸更小，則越高高架。

如果我們再次以 PI 為例，PI 具有對 H.264 編碼的硬件支持，默認的 Camera SW 將利用此支持盡可能高效地為您進行編碼 - 即以最小的處理開銷。

對您來說最有效的解決方案可能取決於您的特定設備“本機”支持的編解碼器 - 即利用設備上的硬件。 H.264 是一種非常常見的編解碼器，它還具有大多數播放視頻的客戶端設備通常也會支持它的優點（此時）。

如果您的意思是當您說“沒有硬件加速”時不想使用此原生支持，那么您可能會尋找可以找到的最低處理開銷編解碼器。 這可能不是具有最佳壓縮或最廣泛支持的一種，但是對專門設計用於低處理能力的編解碼器進行了一些研究-例如

• https://ieeexplore.ieee.org/abstract/document/7079872

這個 Netflix 技術博客也值得一看：

• https://netflixtechblog.com/performance-comparison-of-video-coding-standards-an-adaptive-streaming-perspective-d45d0183ca95

最后，只是為了增加最后一個復雜性（對不起，），可能是這樣的情況，即編碼開銷低的解決方案實際上解碼開銷很大。 因此您可能需要檢查選定的解決方案是否也適用於您的最終用戶設備。