項目背景

2025年春晚是公司的年度大型直播活動，在常規的直播之外，直播結束之后轉出點播稿件的耗時，也是一項重要的競爭指標。根據運營團隊同步的信息，一些競品可以在10分鐘之內，將超過4小時的直播內容轉成點播稿件。

視頻云當時已經存在一套快速直轉點系統，用于賽事大型活動的快速轉點播，但是在生成超過4小時內容，需要至少40分鐘，與業務需求的10分鐘內差距較大。所以，技術團隊以此為目標，對直播轉點播的鏈路進行了整體的升級，同時，這也是新一代流媒體基建系統在線上大型活動下的首戰。在春晚當天，4小時40分鐘的晚會內容，在約8分鐘完成了點播稿件的生產，相比優化前實現了約5倍的加速，達成業務目標。

問題梳理

最長路徑

對于加速類的問題，對未優化流程進行最長路徑分析，并在各個環節找到優化點，是最有效的解決方式。在直播轉點播的場景的最長路徑如下：

• 末段點播轉碼

為了不浪費整個直播的時間，直播轉點播的轉碼都會與直播同步進行。而點播轉碼由于其側重點在壓縮率與畫質上，而非速度，往往需要對直播進行分段錄制之后，在分段上進行。當直播結束時，最后一個分段的速度越快，意味著點播轉碼的速度越快，當編碼速度無法顯著提升的情況下，盡可能縮短分片長度是提速最直接有效的優化方式。

• 運營后臺剪輯

一場直播中并非所有內容都適合放入最終的點播稿件中，所以需要由運營人工接入進行判斷，并裁剪時間軸。同時，大型活動往往存在卡段剪輯的需求，人工操作不可避免。讓人工剪輯越準確快速，就意味著點播稿件可以盡快生成。老后臺由于各種歷史原因，方案很重，優化空間較大。

• 點播稿件生產

運營完成剪輯之后，點播稿件生產需要流轉整個點播稿件生產流程，在直轉點的全片上施加裁剪，生產占位原片，格式轉換等多項媒體處理，生成符合點播要求的音視頻產物。在我們的評估中，這一部分在全流程中占比最大。

FLV-->HLSv7

原先的直轉點系統成型于3~4年前，設計的出發點是盡可能復用當時已經較為成熟的點播轉碼系統與相關生產流程，隨著近幾年點播業務體系的演進，當時看起來合理的選擇，已非最優解。其中最為核心的，是流程中媒體格式的選擇。

原先的直轉點流程，媒體格式選擇了FLV，這是當時點播轉碼體系下的主要格式，且與直播RTMP有較高的契合度。

隨著近幾年各種新codec以及HDR等技術的引入，點播播端逐漸轉向以DASH，生產流程使用FLV，帶來了較大的格式轉換，當遇到超長內容時，這部分的轉換帶來的成本也較為顯著。

直播的RTMP錄制FLV的系統采用3分鐘一段的錄制粒度，為了讓直播轉點播的流程加速，需要在直播錄制時，將錄制分段的時長盡可能縮短到秒級，但這套系統游離于主線開發路線之外，代碼陳舊，難以迭代優化。

最后，FLV本身并非是一種分段格式，瀏覽器上沒有較為成熟高效的分段FLV播放方案，而這又是預覽所必須的。所以原先的剪輯后臺在進行剪輯前，需要將各個FLV轉碼分段下載到瀏覽器中。在面對接近5小時時長的內容，就算是使用碼率最低的360p的轉出清晰度，也需要加載接近1G的內容，這一過程耗時巨大，同時如若當時網絡環境不佳，加載失敗，重復加載將意味著更大的時間浪費。

HLSv7可以較好的解決上面提到的各種問題。

首先，HLS本身就是一種基于分片的流式協議，與直轉點場景契合度較高。其中音視頻的容器使用了fmp4（Fragment MP4）格式，可標準化地支持各類新Codec、HDR等新技術，在直播體系中已經實現大規模業務應用。

流媒體HLSv7體系內，已經存在一套基于HLSv7的錄制系統，錄制數據流與業務系統都較為完備。直轉點轉碼采用相同格式輸出，可作為另一種直播錄制，復用大多數現有錄制系統的更新、管理、查詢等業務邏輯，實現快速接入。

同時在進行源流HLSv7錄制時，可以實現秒級的單GOP錄制，并對外通知。在轉碼側實現了基于秒級分片的轉碼之后，轉碼速度可以有極大的提升。

最后，瀏覽器上有較為成熟的hls.js項目，提供準原生的播放能力，在面對超長內容時，只需加載一個m3u8播放列表，無需加載整個視頻文件，這對于操作后臺的開發，還是運營同學的操作也都更為友好。

技術方案

圖片

新直播錄制系統

直播錄制系統是新系統中的數據核心交換中樞。由于需要實現秒級的直播錄制，且對接的新直轉點轉碼系統也會以秒級頻率與直播錄制系統交互，同時其又需要面對直轉點后臺剪輯的請求、稿件生產中的請求，其服務QPS是關鍵指標。

新錄制系統與新流媒體服務器Transmition之間簡化了交互協議，內部的錄像上報、外部的查詢和服務都基于m3u8來進行。對長m3u8列表進行一定的分片之后，將相關信息存入數據庫。由于一個m3u8列表中已經含有大量的分片信息，這部分數據可以從數據庫中卸載出來，讓新錄制系統的對外服務能力（QPS）得到了顯著提升，可有效應對新轉碼系統基于小分片頻次的大量錄像請求。

此外，直轉點轉碼需要在m3u8分片之間進行精準地銜接，這是之前錄制系統不需要處理的需求，新系統在原有查詢的基礎上，實現了基于m3u8 media sequence的銜接，保證轉碼的輸入端能獲得正確的錄制視頻數據。

新直轉點轉碼

點播轉碼系統是視頻云中歷史較為悠久的老服務，現行的轉碼系統基于狀態機驅動，狀態存放于中間件之中。轉碼的各個步驟的執行是過程化的，一旦啟動，再響應外部請求實現困難，同時，調度器與執行器之間的耦合較重，開發難度大，在面對新時代的各類媒體處理需求時，顯得力不從心，亟待一次架構更新。

流媒體在更早的時間點，就已面向這些新媒體處理需求，規劃了新一代轉碼系統，其中基于短分片的極速轉碼也是規劃中的重點feature之一，本次春晚項目，是發揮該項特性最為合適的業務場景，也是新轉碼系統的第一個業務落地場景。

系統工作模型

對于一個分布式轉碼系統，我們從最大并發，最快速度的角度出發，設計了如下的系統工作模型，并以此作為主要的實現目標。

圖片

這一模型設計是基于如下觀察：

1. 多個媒體處理操作之間的數據依賴是局部的，也即，允許后一處理，在前一處理得到部分結果之后就立刻開始。
2. 單個媒體處理操作，輸入和輸出之間的數據依賴也是局部的，也即，單個媒體操作完成部分處理之后，即可對外同步結果。

這一工作模型將兩者進行了結合，在同一架構下同時獲得3種高性能特性：

1. 單一計算橫向并發
2. 局部IO與計算并發
3. 多階段流水線并發

此外，單一計算的橫向并發，可以在單個計算調用中處理的分片數目，單獨調節，動態適應于各種資源供給場景，且不影響另外兩點特性獲取收益，比如，在資源供給不富裕的場景下，可以選擇單次計算調用，處理多個連續小分片，降低任務級的總資源需求與并發壓力，同時還能獲得加速。而在春晚這樣，提供重點資源保障的場景下，則可以選擇單次計算調用只處理單個分片，并極限縮短分片的長度，實現可用資源的最大化利用，追求最高的性能。

事件驅動的m3u8代理

新轉碼系統是面向通用的媒體處理而設計的，我們希望新系統具有一定的模塊化特性，能通過小的元系統組合而成，故而，在多個計算之間的分片通信和數據交換機制就是系統的重中之重。

由于媒體協議圍繞HLSv7展開，使用m3u8列表，在系統各個節點之間同步分片信息是最匹配的選擇，有大量現有的標準化媒體IO的能力，可以復用。但是在分布式節點之間傳遞m3u8列表在實現上，還需要解決如下問題：

首先，m3u8有2種標準化的更新方式。局部更新主要應用于直播播放場景下，最新的m3u8文件中只會包含最新分片幾其之前幾個分片的信息。全局更新的差異在于，最新的m3u8會包含從開始到最新的所有的分片信息。在轉碼場景這種，我們只能選擇全局更新，主要原因是：

1. 不同轉碼用來存儲的中間文件的分布式存儲會有業務策略與類型的差異，訪存與媒體處理的實現需要解耦。如此，訪存邏輯很難獲取到媒體處理內部的分片進度，只更新部分分片會有丟分片的風險，而這對轉碼來說是不可接受的。
2. 系統主要服務于點播場景，存在異常恢復，分片復用等業務需求，只有全局更新才能滿足這些需求。

在如何執行全局方面，最直觀的做法是，生產端對每一個新分片都更新m3u8，并上傳到分布式存儲上進行覆蓋，在消費端，按照一定的間隔輪詢從分布式存儲上讀取m3u8，獲得新分片的信息。這樣的做法簡單清晰，卻存在如下問題：

1.  分布式存儲系統的穩定性風險

在海量小分片的場景下，在分布式存儲上會生成海量的、同名的小文件。在消費端，由于并不了解生產側的狀態，并不保證每次讀取都會獲得新的分片信息，這種讀取是盲目的，這些都會對存儲系統不友好在業務擴量時，很容易對存儲系統造成沖擊，影響其穩定性。

2.  通信效率低

由于使用全局更新，每次傳輸的m3u8會包含之前的所有歷史分片，存在大量信息重復發送的情況，真正有效的通信數據占比，會隨著進度的推進逐漸劣化。

為了解決這些問題，我們基于流媒體存算團隊研發的OpenBayes快速計算平臺，設計實現了事件驅動的m3u8代理機制：

圖片

首先，我們基于OpenBayes提供的Ray Actor組件，實現了輕量化的分布式隊列，這種隊列擁有一些對系統實現非常友好的特性：

1.  易共享

兩個媒體計算流程通過傳參，即可建立點對點的連接，讓計算流程，在啟動之后不再是無法對外響應的孤島。

2.  本地化

隊列資源都由計算集群本身提供，避免外部依賴，也提供了理論上勝過中間件的通信效率。

3.  生命周期管理

其生命周期被一套引用計數管理，當隊列兩端的計算結束，隊列和對應的資源也一并被回收，無需業務管理。

這是一種非常強大而靈活的機制，未來有大量的想象空間，而現階段，我們借此，實現了分片生產與消費之間的消息同步。

1. 消費端通過消費消息隊列，觸發分片下行同步，可以做到生產一片，同步一片的高效協同，避免了對存儲系統上對m3u8的反復、盲目的讀取。
2. 當新的輸入分片完成同步后，會在計算節點本地的m3u8副本中更新分片，本地副本用于承接媒體計算組件對m3u8的高頻輪詢，減低媒體處理的響應延時，同時避免對分布式存儲造成高壓力。
3. 在媒體計算輸出一個分片后，分片的信息，仍以消息，通知關心的下游，在非必須更新m3u8的場景下（絕大多數場景下），在媒體處理過程中可只上傳分片，在處理完成后上傳一份完整的m3u8，從而避免在存儲系統上產生海量、重名的小文件。
4. 在隊列中傳遞的都是新生成的分片信息，歷史分片信息由代理的本地m3u副本提供，通信效率無劣化。
5. 計算節點上，所有的媒體計算組件都只訪問由代理托管的本地m3u8進行讀寫。媒體計算與訪存之間實現完全的解耦。

在本次春晚的極速直轉點中，從錄制系統中獲取到的新分片、音視頻數據清洗、重組、音視頻分離、音視頻轉碼、轉碼產物合并的每一個步驟都通過這一機制互聯，實現了全鏈路，各步驟高效的事件驅動與協同。同時，依托OpenBayes高度靈活的編排能力和高性能調度，進一步提升系統整體的吞吐。

針對快速直轉點本身，轉碼系統會對最終產物，重新按照5秒再切片，盡可能提升在HLS上剪輯的精度。同時協議上與快速直轉點業務主控服務系統，實現了直播錄制上報的協議，以5秒分段的頻率，向直播錄制系統上報，讓剪輯后臺可以盡早獲取到新的轉碼產物，早預覽，早剪輯。

音畫同步保障

音畫同步一直是分布式轉碼的挑戰，一般來說，切分片越多，出現不同步的概率會越大。為解決這一問題，我們通過若干個媒體組件和相關配套建設，避免這一問題。在新轉碼系統中，收到的音視頻內容的組件會經過時間戳清洗、包重組和重切片，對于源流中的異常時間序列進行重排或修正。在此基礎上，后續的所有操作，包括轉碼、合并、重切片等，都采用對齊修復后源時間軸的方式控制時間戳。這套方案除了在新轉碼系統實現之外，在基于老架構的點播的流式轉碼項目中也先行進行了部署和上線，在春晚前，已得到較長時間和過較為完善的驗證。故而本次春晚，我們有更大的信心，保證在片源音畫同步的條件下，無論轉碼多長的內容，切成多少片轉碼，都不會出現音畫不同步。

新直轉點后臺

新直轉點后臺保留老后臺的絕大多數功能，針對媒體預覽和剪輯這兩個核心功能，面向超長內容剪輯需求，進行了較大的優化。以下二圖為預覽剪輯操作區域新老后臺的變化。

圖片

老直轉點后臺預覽部分

新直轉點后臺預覽部分

可以看到，在面對超長內容時，新后臺不需要像老后臺那樣，人工選取大量的轉碼產物分片，也不需要專門的“加載”操作。頁面長度顯著縮短，所有視頻剪輯的操作可以“同屏”進行。依托HLS協議和hls.js播放器，后臺頁面省去了之前大量分段播放flv的代碼，新播放器即使面對十幾小時的內容，也可以實現“秒加載”。

在此基礎基礎體驗得到保證之后，新后臺增加了大量與時間軸展示、時間軸控制、直播精度追趕的操作按鈕，無論是剪輯卡段還是全片內容，操作效率都顯著提升。操作的運營同學可以在先固定剪輯起始時間的情況下，不斷點擊“刷新直播流”，結合轉碼的小分片級上報，可以讓預覽緊追最新的直播轉碼進度，在需要成片時，直接選定結束時間，生成分片即可，實現極速剪輯。

新直轉點稿件生產系統

之前提到過，點播體系從FLV轉向Dash之后，生產流程引入了多次媒體封裝格式轉換，這種轉換雖然消耗的算力不多，但是對IO的負擔較重，對于超長內容進行多次轉封裝的時間成本已不可忽視。

在老流程中，生產流程需要先獲取到剪輯所需分片，根據剪輯的起止時間裁合并裁剪出對應的FLV產物，之后會對FLV再轉成Dash，生成點播清晰度的各個產物。同時，由于稿件生產流程是由稿件原片驅動的，為了盡可能兼容稿件生產的上下游系統，快速直轉點流程也需要一個占位原片，這次原片的生成與一次剪輯的耗時是接近的。

在這種情況下，全鏈路速度最快的實現方式需要做到2點：

1）原片生產與點播各個清晰度生產同時進行

2）各清晰度稿件生產跳過FLV，直接輸出DASH

在這一過程中，流媒體點播業務團隊對稿件流程完成全并發改造，并完善了相關的數據監控與可觀測性建設。流媒體組件團隊為該功能，先于ffmpeg社區實現了正確Seek m3u8的能力，同時支持直出dash的onDemand Profile功能，做到了兩次本地IO讀寫，完成剪輯、分片合并、音視頻分離、輸出Dash 4個步驟，讓整個稿件生產的流程成倍提升。

圖片

生產保障

春晚活動本身的分量以及大量新系統需要在這樣的重大活動中上線，我們在保障工作上必然不敢松懈。主要分項目開發階段和項目執行兩階段規劃保障工作。

項目開發階段

鑒于有大量新系統，項目開發階段保障工作最重要的目標就是發現問題，而整個流程較為冗長，不能完全依賴測試同學。所以，我們與項目開發過程中，同時積累了兩項基礎驗證能力：標準化播放網關與自動音畫不同步檢測。

標準播放網關

線上播放器與業務深度定制集成，投稿視頻必須完成完整的生產審核流程才能在真實環境中驗證播放效果，這個過程較為繁瑣。目前后端接口提供的調試能力有限，不利于開發人員快速迭代測試，而單純依賴本地測試又無法驗證瀏覽器兼容性等問題。為解決這些問題，我們開發了一套標準播放網關，能將數據庫中的結構化元數據通過模板轉換為 mpd 文件并生成 playlist。我們還與播放器團隊協作，專注于核心功能驗證的精簡版 player，建立了規范的調試流程。這套方案不僅支持測試未公開狀態的稿件及其不同清晰度，還可以實現音視頻清晰度的自由組合測試，顯著提高了調試效率。

自動化音畫不同步檢測

音畫同步一直是分布式音視頻生產過程中的一項挑戰，而新快速直轉點轉碼又是基于海量小分片進行轉碼，產生音畫不同步的風險會更大。雖然新轉碼系統為此有過專門的優化，但是仍然需要較多case驗證，同時，整個稿件生產并非只有轉碼一步，鏈路上任何操作都有可能引入不同步，其又是影響體驗的關鍵因素，需要重點驗證。同時音畫同步又是所有媒體處理的常規要求，無論是為了本項目還是之后的開發，自動化地音畫不同步檢測都有很高的價值。

常規音畫同步檢測是開發人員肉眼觀看產物是否音畫同步，這個方法耗時且不利于開發人員快速迭代測試。基于轉碼操作不會改變場景變化時間點原理，我們開發了基于場景變化檢測轉碼產物和原片音畫同步的功能，并將其應用到新快速直轉點平臺投稿流程中，協助新快速直轉點平臺快速定位排查異常時間點和轉碼問題。新快速直轉點平臺錄制投稿并且稿件開放完成之后，會自動化觸發后臺服務的音畫同步檢測任務，在音畫同步檢測完成之后，如果音畫不同步則會自動向預設對象(如群機器人)發送音畫不同步檢測結果。

項目執行階段

對項目驗證最好的方法無疑是投入線上實戰，由于開發進度得力，項目上線時距離春晚還有一段不短的時間，除了很早就involve當天實際操作剪輯的OGV同學，我們得以有機會邀請游戲賽事運營的同學在生產環境實際試用我們的新系統，同時老的系統作為兜底備份，保證生產安全。在這一過程中，我們根據試用的反饋意見持續打磨系統，提升操作便利度，解決諸如反復斷流等邊緣case，直至春節前一周封板前。

在春晚當天，我們在資源與流程2個維度做了專門的保障主要包括：

1. 直播流3備份，3路同錄，同轉，都可以剪，都可以投稿
2. 直播錄制從邊緣到中心準備3路傳輸，保障錄像獲取高效穩定
3. OpenBayes專項集群保障，集群在除夕前進行了重置，恢復到最佳狀態。
4. 保障群、機器人通知、業務監控大盤、故障處置SOP等

圖片

圖片

圖片

總結

最終項目執行的優化加速效果如下圖：

相比優化前，我們獲得了約5倍的加速，完成了這次“大考”。在這一過程中，以實際業務，驗證了新一代流媒體基建系統。之后，我們面向大型活動之外的日常快速直轉點工作，規劃并執行了多項后續開發工作，

圖片

進一步從穩定性、易用性和性能提升系統能力，推進新一代流媒體基建的建設、迭代與應用，支撐業務的持續發展。