項(xiàng)目背景

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

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

問題梳理

最長(zhǎng)路徑

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

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

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

• 運(yùn)營(yíng)后臺(tái)剪輯

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

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

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

FLV-->HLSv7

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

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

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

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

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

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

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

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

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

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

技術(shù)方案

圖片

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

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

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

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

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

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

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

系統(tǒng)工作模型

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

圖片

這一模型設(shè)計(jì)是基于如下觀察：

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

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

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

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

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

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

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

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

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

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

1.  分布式存儲(chǔ)系統(tǒng)的穩(wěn)定性風(fēng)險(xiǎn)

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

2.  通信效率低

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

為了解決這些問題，我們基于流媒體存算團(tuán)隊(duì)研發(fā)的OpenBayes快速計(jì)算平臺(tái)，設(shè)計(jì)實(shí)現(xiàn)了事件驅(qū)動(dòng)的m3u8代理機(jī)制：

圖片

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

1.  易共享

兩個(gè)媒體計(jì)算流程通過傳參，即可建立點(diǎn)對(duì)點(diǎn)的連接，讓計(jì)算流程，在啟動(dòng)之后不再是無法對(duì)外響應(yīng)的孤島。

2.  本地化

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

3.  生命周期管理

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

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

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

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

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

音畫同步保障

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

新直轉(zhuǎn)點(diǎn)后臺(tái)

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

圖片

老直轉(zhuǎn)點(diǎn)后臺(tái)預(yù)覽部分

新直轉(zhuǎn)點(diǎn)后臺(tái)預(yù)覽部分

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

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

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

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

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

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

1）原片生產(chǎn)與點(diǎn)播各個(gè)清晰度生產(chǎn)同時(shí)進(jìn)行

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

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

圖片

生產(chǎn)保障

春晚活動(dòng)本身的分量以及大量新系統(tǒng)需要在這樣的重大活動(dòng)中上線，我們?cè)诒Ｕ瞎ぷ魃媳厝徊桓宜尚浮Ｖ饕猪?xiàng)目開發(fā)階段和項(xiàng)目執(zhí)行兩階段規(guī)劃保障工作。

項(xiàng)目開發(fā)階段

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

標(biāo)準(zhǔn)播放網(wǎng)關(guān)

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

自動(dòng)化音畫不同步檢測(cè)

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

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

項(xiàng)目執(zhí)行階段

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

在春晚當(dāng)天，我們?cè)谫Y源與流程2個(gè)維度做了專門的保障主要包括：

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

圖片

圖片

圖片

總結(jié)

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

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

圖片

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