概覽

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

內容上下文

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

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

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

流媒體的關鍵問題

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

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

內容類型

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

驗證和測試

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

共和黨結構

視頻的圖片組 (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 * 目標比特率。
• 如果可用，請使用嚴格的符合 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 秒的重試間隔進行大量的重試次數，將減輕編碼器與進入點之間的任何間歇性連線問題。

工作設定

建議的工作設定

輸入需求

下表顯示輸入即時串流的需求。

注意事項

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

石板原始碼檔案建議

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

輸出建議

以下是建議的輸出設定，但請注意，對於許多編碼器，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 支持，請聯繫您的客戶成功經理。