布萊特灣直播:最佳實務

透過 Video Cloud Live,您可以輕鬆設定即時活動,並將多位元速率串流傳遞至網路、iOS 和 Android 裝置。本主題概述了一系列的最佳做法和建議,以協助確保高品質、穩定的直播體驗。

概覽

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

內容上下文

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

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

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

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

如果您需要高比特率的頂級輸出,則值得測試 copy_video 設置,它只會將您的輸入編碼複製到輸出。

設定檔 不同的配置文件(基線、主要、高)按升序壓縮數據(基線:最低,高:最高)。更高的壓縮率提高了傳輸速率,但也需要更多的 CPU 資源來解碼數據。除非編碼器在可用資源方面受到高度限制,否則應避免使用基線配置文件。另一方面,由於所需的解碼 CPU 資源增加,在高比特率下使用 high profile 更有可能導致跳幀。

另見下面的 GOP 結構

影格速率 這應該與來源相符。

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

60fps 等高速率更有可能在高比特率的複雜內容上出現跳幀問題。

關鍵影格速率 最有效的設置是片段持續時間 x 幀速率 - 例如,如果您有 6 秒片段和 30fps,則使關鍵幀速率 180 (6x30) 將導致解碼器負載最低。

但是,為了解決任何波動,將其設置為幀速率的 2 倍 - 例如,對於 30 fps 的幀速率,設置為 60。

共和黨結構 請參閱下面的 GOP 結構

輸入限制

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

  • 通訊協定:rtmprtprtp-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 幀/秒

內容類型

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

內容類型示例
內容類型 範例設定
攝像頭
  • 解決: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 串流至即時模組,因此 RTMP 連線的實際可用頻寬將會大幅減少。
  • Speedtest ( https://www.speedtest.net ) - 用於確定當前上傳和下載速度的在線工具。

輸入頻寬

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

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

確定編碼器功能

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

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

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

共和黨結構

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

  1. Baseline profile 僅支持 I 幀和 P 幀以及 CAVLC 熵編碼
  2. MainHigh 支持 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)

建議的工作設定

工作設定
欄位 建議值
ad_audio_loudness_level -23 (EBU R.128標準)

開始直播推薦

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

石板原始碼檔案建議

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

輸出建議

以下是建議的輸出設定,但請注意,對於許多編碼器,RTMP 輸入限制為 10 MBPS (視訊 + 音訊),畫面播放速率為 30fps。

輸出建議
料號 建議
視訊轉碼器 h264是目前唯一的選擇
音訊轉碼器 aac是目前唯一的選擇
寬度 如果不width或者height提供時,使用源尺寸。如果提供了widthheight,則會計算其他維度以維持來源的縱橫比。
高度 如果不width或者height提供時,使用源尺寸。如果提供了widthheight,則會計算其他維度以維持來源的縱橫比。
位元速率 小於或等於輸入比特率(為獲得最佳效果,最高輸出比特率應為輸入比特率的一半)
關鍵影格速率 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分鐘,那麼實時作業將在15分鐘後終止

reconnect_time 對等待狀態沒有影響。

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

任何時候最多允許 5 個使用中等待未啟動的工作。

並行工單的其他限制:

  • channel ( 24x7) 工作數量限制為 0 或每個區域的數目較少 (取決於帳戶類型)。
  • 同時執行event工作數目受區域限制,通常為 100。
  • 同時等待連線event工作的數目限制為 5 個。
  • 每個區域的SEP作業數量限制為3或10(請參見支持的AWS區域)。

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

只要輸入頻寬足夠,布萊特灣直播能否推動 1080p 品質? 是,所有帳戶都啟用 1080p 輸入功能。
DRM 是否可用? 是的!如果您有興趣為您的真實賬戶添加 DRM 支持,請聯繫您的客戶成功經理。

如需進一步說明

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

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