光明灣直播：最佳實踐

借助 Video Cloud Live，您可以輕鬆設置直播活動並向 Web、iOS 和 Android 設備提供多比特率流。本主題概述了一系列最佳實踐和建議，以幫助確保高質量、穩定的實時流媒體體驗。

概述

Brightcove Live 為創建實時流媒體事件或 24/7 實時流提供了強大的服務。本指南概述了優化直播的最佳做法

內容上下文

需要考慮流式傳輸的內容類型，因為它會影響維持輸入質量所需的設置。請注意，需要權衡取捨，使用盡可能高的設置可能會導致諸如跳幀之類的問題。

根據以下信息，我們建議您在直播活動開始前測試不同設置組合的質量和性能。

下表概述了關鍵輸入參數：

直播的關鍵輸入參數
範圍 筆記
輸入比特率 編碼器發送的比特率。較高的速率更容易受到網絡丟失的影響，因此應盡可能低。
輸入分辨率 這應該與源內容匹配。使其大於原始源沒有任何好處，並且該值越高，支持它所需的比特率就越高。
輸入比特率與頂級配置文件的比率 輸入比特率應高於頂級配置文件的速率，但高太多可能會導致丟幀或其他問題 - 例如，如果您的最高速率是 1080p 30fps，則理想情況下輸入應約為 4 MBPS。請注意，這受配置文件的影響。我們通常建議輸入比特率是最高比特率實時再現比特率的 2 倍（兩倍）。

如果您需要高比特率的頂級輸出，則值得測試複製視頻設置只會將您的輸入編碼複製到輸出。
簡介 不同的配置文件（基線、主要、高）按升序壓縮數據（基線：最低，高：最高）。更高的壓縮率提高了傳輸速率，但也需要更多的 CPU 資源來解碼數據。除非編碼器在可用資源方面受到高度限制，否則應避免使用基線配置文件。另一方面，由於所需的解碼 CPU 資源增加，在高比特率下使用 high profile 更有可能導致跳幀。

另見共和黨結構以下。
幀率 這應該與來源相符。

更高的速率將需要成比例地更高的輸入比特率，例如對於極限運動內容，60fps 的輸入流比 30fps 的流攜帶更多的數據。

60fps 等高速率更有可能在高比特率的複雜內容上出現跳幀問題。
關鍵幀率 最有效的設置是片段持續時間 x 幀速率 - 例如，如果您有 6 秒片段和 30fps，則使關鍵幀速率 180 (6x30) 將導致解碼器負載最低。

但是，為了解決任何波動，將其設置為幀速率的 2 倍 - 例如，對於 30 fps 的幀速率，設置為 60。
共和黨結構 看共和黨結構以下。

輸入限制

為了確保最高質量、最一致的流媒體體驗，Brightcove Live 將輸入流設置限制為：

  • 協議：rtmp , rtp , rtp-fec， 或者srt（除了rtmp用於 MPEG2-TS 輸入） [1-1]
  • 解決：最大 1920x1080
  • 最大 30 fps，這是典型值。Brightcove 支持高達 60 fps，但您需要聯繫 Brightcove 支持增加限制。當使用 60fps 時，Brightcove 建議增加比特率以獲得所需的內容視覺質量和恆定的幀率。
  • 小於 10 Mbps
  • 恆定比特率 (CBR) 大大降低了出現問題的機會
  • 視頻編解碼器必須是 H.264
  • 切片：如果您的編碼器有此選項，請將其設置為1
  • 音頻編解碼器必須AAC
  • 音頻採樣率：44.1khz 和 48khz 是推薦使用的樣本音頻速率
  • 關鍵幀速率或 GOP（圖片組）對齊：
    1. A 關鍵幀應該總是每 2 秒發生一次對於輸入和輸出（包括 25fps 視頻） .這意味著流本身每兩秒從編碼器向 Brightcove 發送一個關鍵幀。這個過程可以用不同的方式定義，但是關鍵幀率是最常見的。
    2. 它可以通過不同的編碼器以不同的方式計算。例如：
      • Wirecast 使用通過的幀數，因此對於 30fps 視頻，設置為 60。
      • 基本編碼器使用秒，因此正確設置為“2”。
      • 60 FPS 視頻只有在按幀計算此設置時才會更改，在這種情況下，每 120 幀等於 2 秒。
  • 如果有一個選項關鍵幀對齊 , 同步 GOP , 對齊關鍵幀，或類似的東西，確保關鍵幀對齊。當關鍵幀未對齊時，會導致 HLS 分段出現同步問題。

筆記

  • [1-1]如果您的 TS 輸入中有多個視頻/音頻軌道，我們將為每個軌道選擇第一個。我們還強烈建議使用 FEC，因為互聯網上 UDP 上的普通 TS 非常不可靠。對於 FEC，我們可以注意到更小您用於行/列的值越大，糾錯就越可靠（以增加帶寬為代價。

流媒體的關鍵問題

通常會遇到幾個與從編碼器到 Brightcove 的流媒體體驗相關的問題：

  1. 網絡不穩定影響輸入：
    1. 雖然互聯網通常非常可靠，但它並非萬無一失，而且確實會出現問題。比特率越高，問題就越容易被注意到。
    2. 如果上傳視頻的時間比實時時間長，那麼這可能會導致輸入漂移（接收視頻的時間比發送視頻的時間要晚很多）
  2. 轉碼器過載導致跳幀：雖然我們盡一切努力確保我們的轉碼器有足夠的開銷，但有時內容複雜性、網絡中斷/捕獲或轉碼器的其他中斷突然出現峰值可能會導致跳幀。輸入越複雜，遇到跳幀的可能性就越大。還有一個已知問題，即從靜止圖像更改持續時間較長（例如超過 5 分鐘）和突然更改動作內容可能會導致過載。
  3. 編碼器發送可變幀持續時間：幀速率應該是恆定的，並且應該允許關鍵幀間隔是恆定的。例如，對於諸如 29.97 又名 30000/1001 或 23.976 又名 24000/1001 之類的幀率，不可能以固定間隔設置關鍵幀，因此應避免這樣做。
  4. 編碼器發送持續時間不一致的關鍵幀，關鍵幀速率應至少為以秒為單位的幀速率的 2 倍。例如，對於 30fps 的幀速率，關鍵幀間隔應為 60 幀，即 2 秒，並且每個片段的最大間隔應為一次 - 例如，如果您有一個 6 秒的片段，則最大間隔為 180 幀30 幀/秒

內容類型

通常，更複雜的內容需要使用這些設置中的較高者，因此更容易出現跳幀。下表按複雜性順序顯示了一些示例。請注意，這些只是示例，幾乎每個編碼器設置都是不同的。應進行測試和驗證。

內容類型示例
內容類型 示例設置
攝像頭
  • 解決：360p
  • 比特率：1兆每秒
  • 輪廓：基線
網絡會議
  • 解決：480p
  • 比特率：2.5兆每秒
  • 輪廓：主要的
動畫片
  • 解決：720p
  • 比特率：2.5兆每秒
  • 輪廓：主要的
會說話的頭/新聞
  • 解決：720p
  • 比特率：4兆每秒
  • 輪廓：主要的
現場音樂會
  • 解決：1080p（或來源）
  • 比特率：5兆每秒
  • 輪廓：高的
體育直播
  • 解決：1080p（或來源）
  • 比特率：6兆每秒
  • 輪廓：高的
現場運動高 FPS
  • 解決：1080p（或來源）
  • 比特率：10兆每秒
  • 輪廓：高的

Transmux 直播職位

設置關鍵幀的插入，使其與請求分段設置相匹配。例如，如果幀速率為每秒 25 幀並且需要 6 秒的片段，則將關鍵幀間隔設置為至少每 300 幀一次。

使用所需的目標設備測試編碼器設置/輸出。如果使用可能具有高級設置的廣播貢獻編碼器會導致流可能與所有消費者設備不兼容，這一點尤其重要。避免特別高級的設置也是一個好主意——很難說這些是什麼，因為有太多可能的編碼器和選項。但是一般的最高利率概況應該是這樣的：

  • 6Mbps 峰值比特率
  • H264高調
  • B幀：2個
  • 8 位 4:2:0 顏色

驗證和測試

理想情況下，您應該從最複雜（變化最大的內容）的盡可能低的設置開始，然後通過增加各種設置來測試其內容，直到輸出可接受為止。這是因為通常設置越高，在網絡或轉碼中遇到問題的可能性就越大。

測試帶寬

對輸入流進行適當設置的第一步是確定現場的可用帶寬。有一些工具可以提供幫助：

  • SpeedOf.Me ( https://speedof.me ) - 確定可用於 HTTP 連接的總帶寬是良好的開端。但是，由於輸入源將通過 RTMP 而不是 HTTP 流式傳輸到 Live 模塊，因此可用於 RTMP 連接的實際帶寬將大大減少。
  • 測速 ( https://www.speedtest.net ) - 用於確定當前上傳和下載速度的在線工具。

輸入帶寬

提供高質量、穩定的輸入流是確保觀眾獲得最佳用戶體驗的唯一途徑。良好的輸入流可以從一個位置以最高的持續可用帶寬提供最佳的視頻質量。

  • 最小輸入帶寬：2.5 兆每秒
  • 最大輸入帶寬：10 兆每秒

確定編碼器功能

了解用於編碼直播流並將其發送到直播模塊的軟件和硬件的功能也很重要。可能有足夠的比特率來發送高質量的 1080p 輸入流，但硬件也需要能夠以比實時更快的速度進行編碼。一些編碼工具顯示有關總 CPU 使用率和正在使用的帶寬的信息。例如，Telestream Wirecast 將在 Wirecast 窗口底部顯示輸出統計信息。

在確定給定硬件上可能的最穩定、最高質量的流時，此信息很有用。Wirecast 的看點：

  • CPU 應低於 80%
  • 數據速率應接近目標比特率
  • FPS 應為輸入流設置的速率

共和黨結構

視頻的圖片組 (GOP) 結構首先取決於用作以下用途的配置文件：

  1. 基線 profile只支持I幀和P幀以及CAVLC熵編碼
  2. 主要的和高的支持I、B、P幀和CABAC熵編碼

Main 和 High 配置文件通常會以更好的質量實現更好的壓縮，但也需要額外的計算來編碼和解碼，因為這樣可能更容易出現跳幀。此外，由於這些配置文件使用 B（雙向）幀，因此它們會在編碼過程中引起一些延遲。

基線配置文件需要較少的 CPU 來編碼和解碼，但由於它提供較少的壓縮，因此需要更高的比特率來保持質量，因此更容易受到網絡問題的影響。

關於幀類型及其對性能的可能影響的註釋：

  1. 我幀 : 使用最多的帶寬。最好為完整的場景更改或在片段邊界添加 - 即內容更改越多，您需要的內容越多（GOP 長度越短）
  2. P幀 : 是 I 幀之間的基本單元
  3. B幀：同時使用之前和未來的幀，添加的越多，壓縮效果越好，但 CPU 和延遲越高

指某東西的用途我幀理想情況下應限於段的開始（如果使用 passthrough 則很關鍵）或場景更改。應避免所有 I 幀或大量 I 幀，因為這會導致過載導致跳幀。

補充筆記：

  • 使用選項來防止關鍵幀的密集放置（例如： min_keyin = 3+）。
  • 使用確保定期插入關鍵幀的選項。例如，不是以秒為單位指定 GOP 長度，而是以精確的分數或幀指定它。

比特率

  • 最小輸入帶寬：2.5 兆每秒
  • 最大輸入帶寬：10 兆每秒
  • 使流“幾乎是 CBR”” - 使用最大比特率 = 1.1 * 目標比特率。
  • 如果可用，請使用嚴格的符合 HRD 的速率控制模式。

協議

重要的是要注意，互聯網並不是一個有保證的傳輸網絡，雖然互聯網連接可能被認為是“良好”的，但對於可靠的高質量實時視頻流來說可能還不夠好。客戶編碼器和 Brightcove 轉碼平台之間路徑的小中斷（例如 ISP 處的少量擁塞、路由器之間的意外故障轉移或類似問題）都可能導致視頻輸出中斷。在高風險直播中，通常的做法是擁有多個專用網絡，包括專用光纖、預訂衛星帶寬或託管網絡上的承諾帶寬。這帶來了巨大的成本，並且在大多數情況下，可以通過互聯網獲得足夠好的結果。但是，如果保持無故障傳輸至關重要，請考慮使用 AWS Direct Connect 或可以提供某種程度的專用帶寬的 ISP。

通常，我們建議專用帶寬是編碼器預期流大小的兩倍，以完全避免任何與帶寬相關的網絡問題。

我們推薦的選項是（按順序）：

  1. SRT - 提供傳輸速度 (UDP) 與一些控制和錯誤恢復的良好組合。並非在所有編碼器上都可用，儘管有一些工具可以從本地 RTP 進行轉換，例如 srt-transmit。
  2. 實時播放協議 - 基於 TCP，它提供了良好的錯誤恢復能力，缺點是這會帶來大量開銷。請注意，並非所有功能（例如多音軌）都適用於 RTMP。
  3. RTP前向糾錯 - 提供基於 UDP 的快速傳輸，具有一定的錯誤恢復能力
  4. 實時傳輸協議 - 提供快速傳輸和高級功能，無錯誤恢復能力

支持的編碼器

看現場活動支持的編碼器用於已知可與 Live 一起使用的編碼器列表。請注意，其他編碼器也可能有效，但尚未經過測試。

支持的 CDN

  • 阿卡邁
  • 亞馬遜雲端

重試

我們建議為來自編碼器的 RTMP 連接啟用重試。具有 5 秒重試間隔的大量重試嘗試將緩解編碼器和入口點之間的任何間歇性連接問題。

作業設置（僅限 Live API）

推薦的作業設置

作業設置
場地 推薦值
ad_audio_loudness_level -23 （EBU R.128 標準）

開始直播推薦

必須在編碼器連接之前激活作業。此外，從編碼器啟動流後激活作業不是受支持的過程，可能會導致意外行為。

Slate 源文件建議

  • 解決 : (在你的編碼階梯中最好)
  • 第一人稱射擊：（與您的來源相同）
  • 比特率 : (在你的編碼階梯中最好或更好)
  • 聲音的：（與最佳再現或輸入相同的比特率、通道、採樣頻率和每個樣本的位數）

輸出建議

以下是推薦的輸出設置，但請注意，對於許多編碼器，RTMP 輸入限制為 10 MBPS（視頻 + 音頻）和 30fps 的幀速率。

輸出建議
物品 推薦
視頻編解碼器 h264是目前唯一的選擇
音頻編解碼器 aac是目前唯一的選擇
寬度 如果不width或者height提供時，使用源尺寸。如果width或者height提供時，將計算另一個維度以保持源的縱橫比。
高度 如果不width或者height提供時，使用源尺寸。如果width或者height提供時，將計算另一個維度以保持源的縱橫比。
比特率 小於或等於輸入比特率（為獲得最佳效果，最高輸出比特率應為輸入比特率的一半）
關鍵幀率 2秒

常問問題

創建實時作業後，您必須多久開始流式傳輸？ 在 Brightcove Live 中，狀態從waiting 到finishing :
  1. 如果工作在等待狀態（尚未開始）和max_waiting_time_ms已經過去，作業已完成/停用。
  2. 如果工作在斷開連接狀態（已啟動，但已斷開連接）和reconnect_time已經過去，作業已完成/停用。

如果event_length 大於 30 分鐘，作業將在 30 分鐘後終止。如果event_length 少於 30 分鐘，作業將在event_length .

例如，如果event_length 為 60 分鐘，則直播作業將在 30 分鐘後終止。如果event_length 是15分鐘，那麼live job會在15分鐘後結束

這reconnect_time 對等待狀態沒有影響。

並發實時 job_settings 的限制是什麼？

最多5個活動等待，未開始任何時候都允許工作。

並發作業的其他限制：

  • 的數量channel (24x7) 作業在每個區域限制為 0 或較少數量（取決於帳戶類型）。
  • 並發數跑步event jobs是有地域限制的，一般為100個。
  • 並發數等待連接event職位限制為 5 個。
  • 每個區域的 SEP 作業數量限制為 3 或 10（請參閱支持的 AWS 區域 ).

這些限制中的任何一個都可以由支持人員在帳戶級別進行調整。如果您需要額外的容量，請聯繫您的客戶成功經理。

如果輸入帶寬足夠，Brightcove Live 能否推 1080p 質量？ 是的，所有帳戶都啟用了 1080p 輸入。
DRM 可用嗎？ 是的！如果您有興趣為您的真實賬戶添加 DRM 支持，請聯繫您的客戶成功經理。

如需進一步幫助

如果您需要進一步的幫助來讓您的現場活動正常進行，您可以聯繫我們 .為確保您獲得盡可能快的響應，下面列出了 Brightcove 支持部門解決問題所需的內容。

  • 流具有的特定症狀。例如，它根本不播放還是卡頓或凍結？
  • 此流在過去是否正常工作
  • 您在編碼器中使用的入口點 URL
  • 您使用的編碼軟硬件
  • 您向其發布實時事件的播放器的 URL
  • 您的實時資產的視頻 ID
  • 從編碼器到發佈點主機的跟踪路由結果