項目背景

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

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

問題梳理

最長路徑

對于加速類的問題，對未優(yōu)化流程進行最長路徑分析，并在各個環(huán)節(jié)找到優(yōu)化點，是最有效的解決方式。在直播轉(zhuǎn)點播的場景的最長路徑如下：

• 末段點播轉(zhuǎn)碼

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

• 運營后臺剪輯

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

• 點播稿件生產(chǎn)

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

FLV-->HLSv7

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

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

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

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

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

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

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

流媒體HLSv7體系內(nèi)，已經(jīng)存在一套基于HLSv7的錄制系統(tǒng)，錄制數(shù)據(jù)流與業(yè)務系統(tǒng)都較為完備。直轉(zhuǎn)點轉(zhuǎn)碼采用相同格式輸出，可作為另一種直播錄制，復用大多數(shù)現(xiàn)有錄制系統(tǒng)的更新、管理、查詢等業(yè)務邏輯，實現(xiàn)快速接入。

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

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

技術方案

圖片

新直播錄制系統(tǒng)

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

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

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

新直轉(zhuǎn)點轉(zhuǎn)碼

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

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

系統(tǒng)工作模型

對于一個分布式轉(zhuǎn)碼系統(tǒng)，我們從最大并發(fā)，最快速度的角度出發(fā)，設計了如下的系統(tǒng)工作模型，并以此作為主要的實現(xiàn)目標。

圖片

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

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

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

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

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

事件驅(qū)動的m3u8代理

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

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

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

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

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

1.  分布式存儲系統(tǒng)的穩(wěn)定性風險

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

2.  通信效率低

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

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

圖片

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

1.  易共享

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

2.  本地化

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

3.  生命周期管理

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

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

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

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

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

音畫同步保障

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

新直轉(zhuǎn)點后臺

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

圖片

老直轉(zhuǎn)點后臺預覽部分

新直轉(zhuǎn)點后臺預覽部分

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

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

新直轉(zhuǎn)點稿件生產(chǎn)系統(tǒng)

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

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

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

1）原片生產(chǎn)與點播各個清晰度生產(chǎn)同時進行

2）各清晰度稿件生產(chǎn)跳過FLV，直接輸出DASH

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

圖片

生產(chǎn)保障

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

項目開發(fā)階段

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

標準播放網(wǎng)關

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

自動化音畫不同步檢測

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

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

項目執(zhí)行階段

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

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

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

圖片

圖片

圖片

總結(jié)

最終項目執(zhí)行的優(yōu)化加速效果如下圖：

相比優(yōu)化前，我們獲得了約5倍的加速，完成了這次“大考”。在這一過程中，以實際業(yè)務，驗證了新一代流媒體基建系統(tǒng)。之后，我們面向大型活動之外的日常快速直轉(zhuǎn)點工作，規(guī)劃并執(zhí)行了多項后續(xù)開發(fā)工作，

圖片

進一步從穩(wěn)定性、易用性和性能提升系統(tǒng)能力，推進新一代流媒體基建的建設、迭代與應用，支撐業(yè)務的持續(xù)發(fā)展。