布萊特灣直播：最佳實務

概覽

Brightcove 直播提供強大的服務，用於創建直播活動或全天候實時流。本指南概述最佳化直播的最佳做法

內容上下文

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

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

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

輸入限制

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

• 通訊協定：rtmp、rtprtp-fec、或srt (除了 MPEG2-TS 輸入以外rtmp的所有通訊協定) ^[1-1]
• 解決：最大值
• 最多 30 fps，這是典型的。Brightcove 最高支援 60 fps，但您需要聯絡 Brightcove 支援部門才能提高上限。當使用 60fps 時，Brightcove 建議增加比特率以獲得所需的內容視覺質量和恆定的幀率。
• 低於 10 Mbps
• 恆定位元率 (CBR) 可大幅降低問題的機會
• 視頻編解碼器必須是 H.264
• 切片：如果您的編碼器具有此選項，請將其設置為1
• 音頻編解碼器必須是AAC
• 音訊取樣率：建議使用 44.1 kHz 和 48 kHz 的取樣音訊速率
• 關鍵影格速率或 GOP (圖片群組) 對齊：
  1. 對於輸入和輸出（包括 25fps 視頻）， 關鍵幀 應始終每 2 秒出現一次。意思是每隔兩秒串流本身就會從編碼器傳送關鍵影格到 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 幀/秒

內容類型

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

Transmux 直播職位

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

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

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

驗證和測試

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

測試頻寬

達到輸入流的適當設置的第一步是確定現場的可用帶寬。有幾個工具可以幫助：

• 速度。我（https://speedof.me）-確定 HTTP 連接可用的總帶寬是一個很好的第一步。不過，由於輸入摘要會透過 RTMP 而非 HTTP 串流至即時模組，因此 RTMP 連線的實際可用頻寬將會大幅減少。
• 速度測試（https://www.speedtest.net）-用於確定當前上傳和下載速度的在線工具。

輸入頻寬

提供高品質、穩定的輸入串流是確保觀眾獲得最佳使用者體驗的唯一途徑。良好的輸入串流以最高一致的可用頻寬提供最佳的視訊品質。

• 最小輸入頻寬：2.5 兆
• 最大輸入頻寬：10 兆

確定編碼器功能

了解用來編碼即時串流並將其傳送至 Live 模組的軟體和硬體功能也很重要。可能有大量的位元速率來傳送高品質的 1080p 輸入串流，但硬體也需要能夠以比即時速度更快的速度進行編碼。某些編碼工具會顯示有關所使用的總 CPU 使用率和頻寬的資訊。例如，Telestream Wirecast 將在 Wirecast 窗口底部顯示輸出統計信息。

此資訊在判斷指定硬體上可能的最穩定、最高品質的串流時非常有用。維雷卡斯特觀賞活動:

• 中央處理器應少於 80%
• 資料表應該靠近目標位元速率
• FPS 應以輸入串流設定的速率為

共和黨結構

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

1. Baseline profile 僅支持 I 幀和 P 幀以及 CAVLC 熵編碼
2. Main 和 High 支持 I、B 和 P 幀和 CABAC 熵編碼

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

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

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

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

理想情況下， I 幀 的使用應限於段的開始（如果使用直通則很關鍵）或場景變化。應避免所有 I 幀或大量 I 幀，因為這會導致過載導致跳幀。

補充筆記：

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

位元速率

• 最小輸入頻寬：2.5 兆
• 最大輸入頻寬：10 兆

• 使流“幾乎是 CBR”- 使用 max_bitrate = 1.1 * target_bitrate。
• 如果可用，請使用嚴格的符合 HRD 的速率控制模式。

協議

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

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

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

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

支援的編碼器

如需已知可與 Live 搭配使用的編碼器清單，請參閱即時活動支援的編碼器。請注意，其他編碼器也可以工作，但尚未經過測試。

支援的 CDN

• 阿卡
• 亞馬遜雲端

重試

建議您從編碼器啟用 RTMP 連線的重試次數。5 秒的重試間隔進行大量的重試次數，將減輕編碼器與進入點之間的任何間歇性連線問題。

作業設置（僅限 Live API）

建議的工作設定

開始直播推薦

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

石板原始碼檔案建議

• 解析度：（在您的編碼階梯中最好）
• 第一人稱射擊：（與您的來源相同）
• 比特率：（最好在您的編碼階梯中或更佳）
• 音訊：（相同的比特率，通道，採樣頻率和每個採樣的比特作為最佳再現，或與您的輸入相同）

輸出建議

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

常問問題

建立即時工作後，您需要多久才能開始串流？

在 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 分鐘，那麼現場工作將在 15 分鐘內終止

對等待狀態沒reconnect_time 有影響。

並發現時 job_設置有什麼限制？

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

並行工單的其他限制：

• 每個區域的channel (24x7) 工作數量限制為 0 或較低數目 (視帳戶類型而定)。
• 同時執行的event工作數量會受到區域限制，通常為 100。
• 同時等待連接event工作的數量限制為 5。
• 每個區域的 SEP 任務數量限制為 3 或 10 個 (請參閱支援的 AWS 區域 )。

任何這些限制都可以由支援在帳戶層級調整。如果您需要額外的容量，請聯繫您的客戶成功經理。

只要輸入頻寬足夠，布萊特灣直播能否推動 1080p 品質？

是，所有帳戶都啟用 1080p 輸入功能。

DRM 是否可用？

是的！如果您有興趣為您的真實賬戶添加 DRM 支持，請聯繫您的客戶成功經理。

如需進一步說明

如果您需要進一步的協助，讓您的現場活動正常運作，您可以聯絡我們。為了確保您能夠獲得最快速的回應，以下是 Brightcove 支援部門解決問題所需的清單。

• 流的具體症狀。例如，它是根本不播放還是口吃或凍結？
• 這個流是否在過去正常工作
• 您在編碼器中使用的入口點 URL
• 您使用的編碼軟件和硬件
• 您發佈直播活動的玩家 URL
• 您的實時資產的視頻 ID
• 從編碼器到發佈點主機的追蹤路由結果