隨著云剪輯、云導播、音視頻生產在線協作的興起， 生產環境下的音視頻處理越發為人所關注。音視頻處理在生產環境下，對控制精準性有著更高的要求。從服務端到客戶端，精準的時間控制、畫面控制都是生產環境音視頻和分發環境下音視頻處理的重要區別。服務端與客戶端的協同上，容易產生微小的差異。

文 / 姜雨晴

整理 / LiveVideoStack

視頻回放：

https://www.livevideostack.cn/video/online-jyq/

大家好，我叫姜雨晴，是MediaTrack音視頻研發負責人，之前就職于熊貓直播，一直從事前端的播放器，后來有幸去了字節跳動，最近在參與和熊貓直播的創業項目。這個項目主要是關于生產環境下的解決方案，我們不再做傳統2C的視頻分發解決方案，而是針對于視頻的創作者的協同和合作進行一個解決方案，這和傳統2C的觀看端有很多不一樣的地方。

本次內容主要分為四個部分：一是架構；二是工作流；三是一致性；四是擴展性。

首先，了解一下我們的產品，在網頁端和小程序端會有修改和批注的功能，也就是我們最早上線這版的功能。如果要做一個生產環境下的解決方案，我個人比較傾向于先了解生產環境下，用戶如何去使用這款產品。

因為我個人比較喜歡使用一些剪輯軟件去剪輯一些片子。這張圖是我個人剪輯時的狀態，首先需要精確到幀的控制，而且每一段的時間戳都非常準確，要清楚哪一段插進的內容，如要清楚知道圖中字幕的位置等要精確到哪一個像素。尤其在網絡的視頻分發過程中，并不能保證這樣的一致性。平時在觀看時是不需要保證到幀的，這就給我們的服務帶來了很大的挑戰。

我們現在最核心的兩個業務是：媒體轉碼和視頻標注和截圖。首先，媒體轉碼是網絡分發，我們所看到的東西不可能用源流，因為源流可能特別大，有可能在網頁或小程序端解碼不了，這就涉及到轉碼，所以轉碼流和源流是否保持一致就成了很大的問題。其次，視頻標注和截圖也會在一致性上產生差異。

1

架構

這張圖是我們現在的MediaTrack整個的架構，整個命名方式延續了熊貓的命名方式，所有的項目都采用英雄聯盟的英雄為項目名稱。現在最主要的兩個項目是：一是對用戶可見的Web端的Sona和小程序的Neeko，它們的背后是第二層長連接Riven和API的Kayn這兩個部分，也就是和前端進行交互的這層，它們的靈活性會比較高，并根據產品的需求加接口。

最后這部分是微服務集群，重點是音視頻服務Ahri，對于系統內的其他服務而言，Ahri只是音視頻服務，與其他的微服務沒有任何區別。

Ahri是所有媒體相關操作的微服務集合，包括媒體轉碼、文件格式矯正、媒體信息的獲取、截圖、音頻waveform抽樣、標注點繪制、圖片處理等一系列工作。Ahri對外僅是個普通的微服務。對內是微服務組，這也是它命名的原因。Ahri是一個九尾妖狐，它可以將能量存儲在火球中并釋放出去，它的九條尾巴就像對內的微服務一樣，都是它不可或缺的部分。

這張圖展示了Ahri的架構，Ahri對外的服務就是Ahri網關，并沒有自己實際的操作，它所有的操作都是向內部的微服務創建任務并匯總這些任務，但轉碼還是采用云廠商的轉碼。

2

工作流

我們兩個比較重要的工作流：一是調用工作流，Ahri先要知道需要做什么再進行工作，利用Magic number判斷文件類型。因為我們的系統允許用戶傳任何文件，這樣會把文件的擴展名改掉，或者前端無法判斷它是否是一個音視頻文件。這時Ahri會再進行判斷，如果是一個視頻文件會通知其他服務矯正它，并進入真正的媒體處理的流程。

媒體處理流程也會做一個矯正，實際并不想同一個文件處理多次。當多個用戶上傳同一個文件時，需要做hash。當事件任務完成或者狀態更新時，就進行廣播消息。

如果沒有媒體信息、獲取媒體信息矯正。截圖標記會遇到一些坑點：一是時間戳找齊；二是畫圖標記找齊。

3

一致性

時間一致性，傳統上，現在可以看到的視頻片段如圖所示，首先是格式上的時間零點，然后是音頻首幀時間點、視頻首幀時間點，最后是標注點。

圖中上部分是服務器的原片，因為用戶比較專業，大部分上傳的片子都是如圖所示，也就是音頻時間原點和視頻時間原點幾乎是一致的，甚至有些在上面打了時間碼。

但我們現在所用的轉碼服務經常會把轉碼流變成圖中下部分，也就是它們起始時間并不一致。所以在找一幀畫面時是需要基準點的，一般基準點是視頻圖像的首幀，也就是start time，然后標記時間戳是以視頻時間的start time基準點去找。

我以前是做網頁播放器出身，網頁播放器會對start time進行處理。因為依據圖中的轉碼流處理，如果start time是4秒鐘，首屏時間就要等4秒之久，所以一般會計算一個Base-Time，也就是把音頻和視頻的start time小的值作為基準時間點，作為時間零點，之后的每一幀都會減去這個時間點。像這種時間點的控制就會造成真正的start time其實并不是首幀的PTS，這時MSE Buffer就需要再一次找齊時間點。

這其中會有一個坑點，現在的時間點在瀏覽器上有可能會被清除掉，因為瀏覽器有一個機制是播放一定時間時會把前面的緩存清除，以節省內存空間，但這時候的start time點就不準了。所以在取視頻的時間點時要保證是第一個片段塞進MSR Buffer。

根據圖中所展示的處理，目的是加速起播時間，其次是盡量保留展現數據。

因為小程序播放器是小程序的底層，它的起始時間點是視頻的首幀，這是利用用戶打好時間戳的視頻，根據視頻的轉碼流和源流PTS對出來的，小程序的基準時間點為0。

小程序以視頻為基準播放，無需特殊處理。小程序另外一個坑是小程序為了保證它的消化不會過大，會保持timeupdate為250ms，需要精確到幀，必須自制定時器。但需要注意，定時器過多，會導致程序崩潰，建議做全局定時器。

這部分是關于畫面的定位，這比時間上的一致性效果要好得多，圖中展示的是一個特殊情況，圖中圓點是基準點，內部方形是實際畫面，外部是播放框。以實際畫面為準，將它的寬和高定一個百分比作為標記點。即使這個視頻被處理了，也可以根據相對標點找到實際位置。

4

拓展性

這部分介紹我們系統的擴展性，圖中是Ahri整個架構圖，首先Ahri會創建workflow并下發任務，這些任務可能會在Ahri自己的服務上進行，也可能在云廠商服務上進行。如果云廠商質量達不到我們的精度，需要做自己的服務時，可以直接在workflow這一層做遷移，如果需要加比如第三方轉碼時，可以橫向擴展我們的workflow。

---

LiveVideoStackCon 2020?北京

2020年10月31日-11月1日

點擊【閱讀原文】了解更多詳細信息

總結

以上是生活随笔為你收集整理的视频生产环境下的音视频解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。