總第354篇
2019年 第32篇
美美導讀:移動互聯網時代,4G的普及推動了移動視頻的發展,豐富的視頻內容滿足了用戶多樣化的需求。美團外賣商家端也嘗試引入了視頻功能,旨在提升商品信息描述的豐富度。本文總結了商家端視頻功能的閉環全流程實踐及部分踩坑經驗。
2013年美團外賣成立,至今一直迅猛發展。隨着外賣業務量級與日俱增,單一的文字和圖片已無法滿足商家的需求,商家迫切需要更豐富的商品描述手段吸引用戶,增加流量,進而提高下單轉化率和下單量。商品視頻的引入,在一定程度上可以提升商品信息描述豐富度,以更加直觀的方式爲商家引流,增加收益。爲此,商家端引入了視頻功能,進行了一系列視頻功能開發,核心功能包含視頻處理(混音,濾鏡,加水印,動畫等)、視頻拍攝、合成等,最終效果圖如下所示:
對於視頻鏈路的開發,我們經歷了方案選型、架構設計及優化、業務實踐、功能測試、監控運維、更新維護等各個環節,核心環節如下圖所示。在開發過程中,遇到了各種技術問題和挑戰,下文會針對遇到的問題、挑戰,及其解決方案進行重點闡述。
方案選型
在方案選型時,重點對核心流程和視頻格式進行選型。我們以功能覆蓋度、穩定性及效率、可定製性、成本及開源性做爲核心指標,從而衡量方案的高可用性和可行性。
1. 核心流程選型
阿里和騰訊的雲視頻點播方案比較成熟,集成度高,且能力豐富,穩定性及效率也很高。但兩者成本較高,需要收費,且SDK大小均在15M以上,對於我們的業務場景來說有些過於臃腫,定製性較弱,無法迅速的支持我們做定製性擴展。
當時的大衆點評App UGC方案,基礎能力是滿足的,但因業務場景差異:
比如外賣的視頻拍攝功能要求在豎屏下保證16:9的視頻寬高比,這就需要對原有的採集區域進行截取,視頻段落的裁剪支持不夠等,業務場景的差異導致了實現方案存在巨大的差異,故放棄了大衆點評App UGC方案。其他的一些開源方案(比如Grafika等),也無法滿足要求,這裏不再一一贅述。
通過技術調研和分析,吸取各開源項目的優點,並參考大衆點評App UGC、Google CTS方案,對核心流程做了最終的方案選型,打造一個適合我們業務場景的方案,如下表所示:
2. 視頻格式選型
採用H.264的視頻協議:H.264的標準成熟穩定,普及率高。其最大的優勢是具有很高的數據壓縮比率,在同等圖像質量的條件下,H.264的壓縮比是MPEG-2的2倍以上,是MPEG-4的1.5~2倍。
採用AAC的音頻協議:AAC是一種專爲聲音數據設計的文件壓縮格式。它採用了全新的算法進行編碼,是新一代的音頻有損壓縮技術,具有更加高效,更具有“性價比”的特點。
整體架構
我們整體的架構設計,用以滿足業務擴展和平臺化需要,可複用、可擴展,且可快速接入。架構採用分層設計,基礎能力和組件進行下沉,業務和視頻能力做分離,最大化降低業務方的接入成本,三方業務只需要接入視頻基礎SDK,直接使用相關能力組件或者工具即可。
整體架構分爲四層,分別爲平臺層、核心能力層、基礎組件層、業務層。
平臺層:依賴系統提供的平臺能力,比如Camera、OpenGL、MediaCodec和MediaMuxer等,也包括引入的平臺能力,比如ijkplayer播放器、mp4parser。
核心能力層:該層提供了視頻服務的核心能力,包括音視頻編解碼、音視頻的轉碼引擎、濾鏡渲染能力等。
基礎能力層:暴露了基礎組件和能力,提供了播放、裁剪、錄屏等基礎組件和對應的基礎工具類,並提供了可定製的播放面板,可定製的緩存接口等。
業務層:包括段落拍攝、自由拍攝、視頻空間、拍攝模版預覽及加載等。
我們的視頻能力層對業務層是透明的,業務層與能力層隔離,並對業務層提供了部分定製化的接口支持,這樣的設計降低了業務方的接入成本,並方便業務方的擴展,比如支持蜜蜂App的播放面板定製,還支持緩存策略、編解碼策略的可定製。整體設計如下圖所示:
實踐經驗
在視頻開發實踐中,因業務場景的複雜性,我們遇到了多種問題和挑戰。下面以核心功能爲基點,圍繞各功能遇到的問題做詳細介紹。
視頻播放
播放器是視頻播放基礎。針對播放器,我們進行了一系列的方案調研和選擇。在此環節,遇到的挑戰如下:
1. 兼容性問題
2. 緩存問題
針對兼容性問題,Android有原生的MediaPlayer,但其版本兼容問題偏多且支持格式有限,而我們需要支持播放本地視頻,本地視頻格式又無法控制,故該方案被捨棄。ijkplayer基於FFmpeg,與MediaPlayer相比,優點比較突出:具備跨平臺能力,支持Android與iOS;提供了類似MediaPlayer的API,可兼容不同版本;可實現軟硬解碼自由切換,擁有FFmpeg的能力,支持多種流媒體協議。基於上述原因,我們最終決定選用ijkplayer。
但緊接着又發現ijkplayer本身不支持邊緩存邊播放,頻繁的加載視頻導致耗費大量的流量,且在弱網或者3G網絡下很容易導致播放卡頓,所以這裏就衍生出了緩存的問題。
針對緩存問題,引入AndroidVideoCache的技術方案,利用本地的代理去請求數據,先本地保存文件緩存,客戶端通過Socket讀取本地的文件緩存進行視頻播放,這樣就做到了邊播放邊緩存的策略,流程如下圖:
此外,我們還對AndroidVideoCache做了一些技術改造:
優化緩存策略。針對緩存策略的單一性,支持有限的最大文件數和文件大小問題,調整爲由業務方可以動態定製緩存策略;
解決內存泄露隱患。對其頁面退出時請求不關閉會導致的內存泄露,爲其添加了完整的生命週期監控,解決了內存泄露問題。
視頻錄製
Camera+AudioRecord+MediaCodec+Surface
MediaRecorder+MediaCodec
方案1需要Camera採集YUV幀,進行截取採集,最後再將YUV幀和PCM幀進行編碼生成mp4文件,雖然其效率高,但存在不可把控的風險。
方案2綜合評估後是改造風險最小的。綜合成本和風險考量,我們保守的採用了方案2,該方案是對裁剪區域進行座標換算(如果用前置攝像頭拍攝錄製視頻,會出現預覽畫面和錄製的視頻是鏡像的問題,需要處理)。當錄製完視頻後,生成了mp4文件,用MediaCodec對其編碼,在編碼階段再利用OpenGL做內容區域的裁剪來實現。但該方案又引發瞭如下挑戰。
(1)對焦問題
因我們對採集區域做了裁剪,引發了點觸對焦問題。比如用戶點擊了相機預覽畫面,正常情況下會觸發相機的對焦動作,但是用戶的點擊區域只是預覽畫面的部分區域,這就導致了相機的對焦區域錯亂,不能正常進行對焦。後期經過問題排查,對點觸區域再次進行相應的座標變換,最終得到正確的對焦區域。
(2)兼容適配
// VIVO Y66 模版拍攝時候,播放某些有問題的視頻文件的同時去錄製視頻,會導致MediaServer掛掉的問題
// 發現將1080P尺寸的配置降低到720P即可避免此問題
// 但是720P尺寸的配置下,又存在綠邊問題,因此再降到480
if(isVIVOY66() && mMediaServerDied) {
return getCamcorderProfile(CamcorderProfile.QUALITY_480P);
}
//SM-C9000,在1280 x 720 分辨率時有一條綠邊。網上有種說法是GPU對數據進行了優化,使得GPU產生的圖像分辨率
//和常規分辨率存在微小差異,造成圖像色彩混亂,修復後存在綠邊問題。
//測試發現,降低分辨率或者升高分辨率都可以繞開這個問題。
if (VideoAdapt.MODEL_SM_C9000.equals(Build.MODEL)) {
return getCamcorderProfile(CamcorderProfile.QUALITY_HIGH);
}
// 優先選擇 1080 P的配置
CamcorderProfile camcorderProfile = getCamcorderProfile(CamcorderProfile.QUALITY_1080P);
if (camcorderProfile == null) {
camcorderProfile = getCamcorderProfile(CamcorderProfile.QUALITY_720P);
}
// 某些機型上這個 QUALITY_HIGH 有點問題,可能通過這個參數拿到的配置是1080p,所以這裏也可能拿不到
if (camcorderProfile == null) {
camcorderProfile = getCamcorderProfile(CamcorderProfile.QUALITY_HIGH);
}
// 兜底
if (camcorderProfile == null) {
camcorderProfile = getCamcorderProfile(CamcorderProfile.QUALITY_480P);
}
視頻合成
我們的視頻拍攝有段落拍攝這種場景,商家可根據事先下載的模板進行分段拍攝,最後會對每一段的視頻做拼接,拼接成一個完整的mp4文件。mp4由若干個Box組成,所有數據都封裝在Box中,且Box可再包含Box的被稱爲Container Box。mp4中Track表示一個視頻或音頻序列,是Sample的集合,而Sample又可分爲Video Smaple和Audio Sample。Video Smaple代表一幀或一組連續視頻幀,Audio Sample即爲一段連續的壓縮音頻數據。(詳見mp4文件結構。)
視頻裁剪
我們剛開始採用mp4parser技術完成視頻裁剪,在實踐中發現其精度誤差存在很大的問題,甚至會影響正常的業務需求。比如禁止裁剪出3s以下的視頻,但是由於mp4parser產生的精度誤差,導致4-5s的視頻很容易裁剪出少於3s的視頻。究其原因,mp4parser只能在關鍵幀(又稱I幀,在視頻編碼中是一種自帶全部信息的獨立幀)進行切割,這樣就可能存在一些問題。比如在視頻截取的起始時間位置並不是關鍵幀,會造成誤差,無法保證精度而且是秒級誤差。以下爲mp4parser裁剪的關鍵代碼:
public static double correctTimeToSyncSample(Track track, double cutHere, boolean next) {
double[] timeOfSyncSamples = new double[track.getSyncSamples().length];
long currentSample = 0;
double currentTime = 0;
for (int i = 0; i < track.getSampleDurations().length; i++) {
long delta = track.getSampleDurations()[i];
int index = Arrays.binarySearch(track.getSyncSamples(), currentSample + 1);
if (index >= 0) {
timeOfSyncSamples[index] = currentTime;
}
currentTime += ((double) delta / (double) track.getTrackMetaData().getTimescale());
currentSample++;
}
double previous = 0;
for (double timeOfSyncSample : timeOfSyncSamples) {
if (timeOfSyncSample > cutHere) {
if (next) {
return timeOfSyncSample;
} else {
return previous;
}
}
previous = timeOfSyncSample;
}
return timeOfSyncSamples[timeOfSyncSamples.length - 1];
}
方案具體實施如下:先獲得目標時間的上一幀信息,對視頻解碼,然後根據起始時間和截取時長進行切割,最後將裁剪後的音視頻信息進行壓縮編碼,再封裝進mp4容器中,這樣我們的裁剪精度從秒級誤差降低到微秒級誤差,大大提高了容錯率。
視頻處理
視頻處理是整個視頻能力最核心的部分,會涉及硬編解碼(遵循OpenMAX框架)、OpenGL、音頻處理等相關能力。
在實踐過程中,我們遇到了一些需要特別注意的問題,比如開發時遇到的坑,嚴重的兼容性問題(包括硬件兼容性和系統版本兼容性問題)等。下面重點講幾個有代表性的問題。
1. 偶數寬高的編解碼器
查閱大量資料,也沒能解釋清楚這個異常的存在。基於日誌錯誤信息,並通過系統源碼定位,也只是發現是了和設置的參數不兼容導致的。經過反覆的試錯,最後確認是部分編解碼器只支持偶數的視頻寬高,所以我們對視頻的寬高做了偶數限制。引起該問題的核心代碼如下:
status_t ACodec::setupVideoEncoder(const char *mime, const sp<AMessage> &msg,
sp<AMessage> &outputFormat, sp<AMessage> &inputFormat) {
if (!msg->findInt32("color-format", &tmp)) {
return INVALID_OPERATION;
}
OMX_COLOR_FORMATTYPE colorFormat =
static_cast<OMX_COLOR_FORMATTYPE>(tmp);
status_t err = setVideoPortFormatType(
kPortIndexInput, OMX_VIDEO_CodingUnused, colorFormat);
if (err != OK) {
ALOGE("[%s] does not support color format %d",
mComponentName.c_str(), colorFormat);
return err;
}
.......
}
status_t ACodec::setVideoPortFormatType(OMX_U32 portIndex,OMX_VIDEO_CODINGTYPE compressionFormat,
OMX_COLOR_FORMATTYPE colorFormat,bool usingNativeBuffers) {
......
for (OMX_U32 index = 0; index <= kMaxIndicesToCheck; ++index) {
format.nIndex = index;
status_t err = mOMX->getParameter(
mNode, OMX_IndexParamVideoPortFormat,
&format, sizeof(format));
if (err != OK) {
return err;
}
......
}
2. 顏色格式
我們在處理視頻幀的時候,一開始獲得的是從Camera讀取到的基本的YUV格式數據,如果給編碼器設置YUV幀格式,需要考慮YUV的顏色格式。這是因爲YUV根據其採樣比例,UV分量的排列順序有很多種不同的顏色格式,Android也支持不同的YUV格式,如果顏色格式不對,會導致花屏等問題。
3. 16位對齊
這也是硬編碼中老生常談的問題了,因爲H264編碼需要16*16的編碼塊大小。如果一開始設置輸出的視頻寬高沒有進行16字節對齊,在某些設備(華爲,三星等)就會出現綠邊,或者花屏。
4. 二次渲染
4.1 視頻旋轉
在最後的視頻處理階段,用戶可以實時的看到加濾鏡後的視頻效果。這就需要對原始的視頻幀進行二次處理,然後在播放器的Surface上渲染。首先我們需要OpenGL 的渲染環境(通過OpenGL的固有流程創建),渲染環境完成後就可以對視頻的幀數據進行二次處理了。通過SurfaceTexture的updateTexImage接口,可將視頻流中最新的幀數據更新到對應的GL紋理,再操作GL紋理進行濾鏡、動畫等處理。在處理視頻幀數據的時候,首先遇到的是角度問題。在正常播放下(不利用OpenGL處理情況下)通過設置TextureView的角度(和視頻的角度做轉換)就可以解決,但是加了濾鏡後這一方案就失效了。原因是視頻的原始數據經過紋理處理再渲染到Surface上,單純設置TextureView的角度就失效了,解決方案就是對OpenGL傳入的紋理座標做相應的旋轉(依據視頻的本身的角度)。
4.2 渲染停滯
視頻在二次渲染後會出現偶現的畫面停滯現象,主要是SurfaceTexture的OnFrameAvailableListener不返回數據了。該問題的根本原因是GPU的渲染和視頻幀的讀取不同步,進而導致SurfaceTexture的底層核心BufferQueue讀取Buffer出了問題。下面我們通過BufferQueue的機制和核心源碼深入研究下:
首先從二次渲染的工作流程入手。從圖像流(來自Camera預覽、視頻解碼、GL繪製場景等)中獲得幀數據,此時OnFrameAvailableListener會回調。再調用updateTexImage(),會根據內容流中最近的圖像更新SurfaceTexture對應的GL紋理對象。我們再對紋理對象做處理,比如添加濾鏡等效果。SurfaceTexture底層核心管理者是BufferQueue,本身基於生產者消費者模式。
SurfaceTexture的核心流程如下圖:
5. 碼流適配
關於碼流還有個問題,就是如果通過系統的接口isBitrateModeSupported(int mode),判斷是否支持該碼流可能會出現誤判,究其原因是framework層寫死了該返回值,而並沒有從硬件層或從media_codecs.xml去獲取該值。關於碼流各硬件廠商支持的差異性,可能谷歌也認爲碼流的兼容性太碎片化,不建議用非默認的碼流。
6. 音頻處理
音頻處理還括對音頻的混音、消聲等操作。在混音操作的時候,還要注意音頻文件的單聲道轉換等問題。
其實視頻問題總結起來,大部分是都會牽扯到編解碼(尤其是使用硬編碼),需要大量的適配工作(以上也只是部分問題,碎片化還是很嚴峻的),所以就需要兜底容錯方案,比如加入軟編。
線上監控
我們以拍攝流程爲例,來看看鏈路各核心節點的監控,如下圖:
容災降級
維護更新
視頻功能上線後,經歷了幾個穩定的版本,保持着較高的成功率。但近期收到了Sniffer(美團內部監控系統)的郵件報警,發現視頻處理鏈路的失敗次數明顯增多,通過Sniffer收集的信息發現大部分都是Android 9.0的問題(也就是上面講的Android 9.0碼流適配的問題),我們在商家端5.2版本進行了修復。該問題解決後,我們的視頻處理鏈路成功率也恢復到了98%以上。
總結和規劃
參考資料
mp4文件結構(一)、(二)、(三)、(四)
作者簡介
金輝、李瓊,美團外賣商家終端研發工程師。
---------- END ----------