一文帶你走進得物視頻
一、背景
當談論如何提升視頻的體驗時,我們需要明確互聯網視頻市場的背景和現狀,并分析用戶對于視頻體驗的期望和挑戰。
首先,隨著移動網絡的普及和互聯網帶寬的不斷提升,視頻觀看已成為互聯網的主要應用之一,視頻內容也涉及更多的領域,例如教育、電商、社交等。同時,視頻流量的份額也逐漸擴大,占據著互聯網流量的重要部分。可是,面對海量的視頻內容,用戶們提出了越來越高的要求,如需要更快的加載速度、更流暢的播放體驗、更高的畫質和分辨率等,這些要求又產生了一系列挑戰。
其次,不良的網絡環境和設備所帶來的影響也是視頻體驗不理想的重要原因之一,例如網絡延遲、帶寬瓶頸、設備性能等,這些因素都可能導致視頻的卡頓、畫面模糊、下載速度慢等質量問題。此外,由于網絡環境的差異和視頻內容的多樣性,保障用戶體驗變得更加復雜,需要針對不同的用戶需求和設備特性,采用不同的優化方案和技術手段。
針對這些問題,我們需要梳理出優化視頻體驗的技術手段和測試角度,以提高視頻的質量和用戶的滿意度。并通過不斷的優化落地,最終來提升視頻體驗并提高市場競爭力。
上半年我們針對得物視頻場景做了數據摸底,主要涉及的場景包含視頻流和沉浸視頻流,收集的指標包括卡頓率,秒開數據,CPU,內存及主客觀質量。從結果來看,我們在內容質量、秒開、卡頓上都有一定的提升空間。
二、視頻體驗技術優化
為了優化以上存在的痛點問題,我們針對視頻規劃了一系列的優化項目,主要從視頻質量提升、視頻卡頓率優化、視頻秒開優化這 3 方面進行整改。
視頻質量提升
圖片
視頻卡頓率優化
圖片
視頻秒開優化
圖片
其他
圖片
三、視頻從發布到消費
發布
發布入口
- App發布
- 創作者后臺發布
- 達人后臺發布
發布流程
- 視頻素材選擇
圖片
- 視頻封面設置
圖片
發布上傳
- 獲取 Oss 上傳地址和 Token
- 將 URL 上傳給社區服務端
編碼
圖片
圖片
云廠商
- 原視頻 720P-H264 窄帶高清轉碼工作流(基礎轉碼)。
- 轉碼完成后調用【算法服務】去水印&加水印。
- 觸發時機:視頻發布完成自動觸發。
社區服務
- 動態發布接口:
保存原視頻鏈接到內容媒體庫。
轉碼檢查,增加云廠商轉碼視頻檢查記錄,待檢查轉碼狀態。
- 轉碼檢查處理腳本:
- 檢查云廠商轉碼是否完成,完成后保存到內容媒體庫,同時請求算法去水印。
- 檢查內容媒體中心轉碼是否完成,完成后保存到內容媒體庫。
- 媒體中心回調:
- 接收媒體中心轉碼回調,更新內容媒體庫原視頻寬高、時長等信息。
- 往轉碼檢查表增加媒體中心轉碼的多種轉碼視頻記錄待檢查轉碼狀態。
- 寬和高同時大于 720 會觸發 2 路轉碼(720P-H265和1080P-H265),否則一路轉碼(720P-H265)。
- 算法處理回調:
- 接收算法去水印、生成封面圖等處理回調,保存處理后內容文件到內容媒體庫。
- 去水印類型,MQ 通知中后臺視頻轉碼已完成,中后臺開始審核流程。
媒體中心
圖片
- 接收服務端原視頻轉碼請求,云廠商轉碼。
- 監聽二審二審通過、熱門視頻、高幀率處理微幀轉碼。
- 監聽打標結果、籃球美妝類視頻,視頻增強轉碼。
- 視頻首幀截取處理。
- 回調社區服務媒體中心,回傳轉碼完成后視頻相關信息。
算法服務:
- 去原視頻水印。
- 生成封面圖。
- 加品宣水印。
- 策略算法商品封面圖。
解碼
業務播放流程
前面我們在轉碼時介紹了很多種不同的轉碼類型、同時針對不同的轉碼定義了 Type 的多個枚舉值,作用就在于業務這邊的播放優先級策略。
- 冷啟動讀取視頻切換策略。
- 視頻動態下發兜底播放 URL、轉碼播放 URL、類型 Type。
圖片
總結:
- 每次冷啟動會拉取配置中心配置的視頻播放策略。
- 播放視頻時,根據配置中心配置優先級,讀取實際下發的 Type,選對應的 Type 進行播放。
- 解碼器選擇:配置中心中配置了 264 解碼器播放類型和 265 解碼器播放類型,我們會根據對應優先級選中對應 Type 的 URL 進行播放,然后再選中對應的解碼器進行解碼。
- 預下載大小:配置中心中配置了不同類型預下載大小,那么我們會根據播放類型進行預下載。
如果 Video 下發為空,那么我們會使用兜底鏈接播放。
首幀加載邏輯
- 可以先看一下下面的例子:
- 為了防止有人惡意將我們服務當做視頻存儲地址,同時出于規避黑灰產的非法資源的合規風險,我們針對視頻做了防盜鏈技術,即視頻地址是有有效期的,超過配置的有效時間,地址會失效,播放時,需要進行換鏈請求。這里帶來的一個問題就是存在一些場景在進入視頻詳情頁時無法加載首幀圖,只有黑底圖到視頻播放的過渡,影響秒開。
- 同時,視頻是可以設置封面的,封面可能是算法識別、也可能是用戶自己選擇,這就造成了很大的不確定性,即封面很有可能不是視頻首幀,甚至和視頻毫無關聯。這類視頻,我們在進入視頻詳情頁先用封面填充,但到播放時會感覺明顯跳幀,畫面不連貫,也非常影響視頻觀看的體驗。
因此,雖然我們有預下載首幀邏輯,但如果視頻地址過期,首幀下載是會失敗的,就存在了如上進入視頻先出現黑底圖的現象。基于此,我們做了首幀加載邏輯的優化。
- 首幀獲取邏輯
圖片
圖片
- 播放邏輯策略
取得新的視頻首幀圖片后需要自行拼接裁剪參數,目前統一轉 Heic 格式圖片,裁剪寬度最大 360(和線上邏輯一致),高度自適配。轉成 Heic 可以有效降低文件大小,減少網絡傳輸成本,提升首幀加載速度。
圖片
優先級:視頻首幀的圖片緩存 > 雙列卡片的封面圖片緩存 > 加載首幀網絡圖并以黑底圖兜底。
沉浸流冷啟優化
圖片
最終展示的數據情況:
- 之前某次啟動的緩存數據 1 條 + 本次啟動沉浸流請求的后續數據 6 條。
- 本次啟動社區首頁請求的數據 1 條 + 本次啟動沉浸流請求的后續數據 6 條。
- 本次啟動沉浸流請求的數據 6 條。
播放器復用
優化前:
優化后:
這里我們可以明顯看到優化前,關注流進入到視頻詳情頁會黑一下,優化后就更加絲滑了,肉眼看不出有黑屏的情況。這里我們主要就是使用了播放器復用來解決這個問題,節省創建播放器內核等待時間。
- 創建 View 的時機
每次點擊提前創建 View 開始解碼。
跳轉后將 View add 到屏幕上。
復用過程就是 A 頁面解綁 -B 頁面綁定 -B 頁面解綁 -A 頁面重新綁定。
當然這里,推薦流是比較特殊的,有個共享的播放器實例。
四、過程中典型案例分析
沉浸流冷啟優化內存泄漏
圖片
Tips:針對端上的一些大需求、模塊技改、底層邏輯重構等等,我們可以結合自動化來驗證 App 的穩定性,業務邏輯測試 + 探索性測試 + 自動化測試 + 灰度驗證,在整個版本周期都能通過一些手段去有效發現問題,左移前置的越多,線上暴露的問題就會越少。
當然往往這些都伴隨了一些 AB,因此我們在跑自動化時要把 AB 打開。讓這些功能能提前得到一些驗證。
高幀率倍速播放音畫不同步
- 原因:在回歸時,發現部分視頻倍速播放出現音畫不同步的現象,排查發現,該視頻是 60fps,2 倍速的話會變成 120fps,播放器渲染不過來了。因此當倍速 *幀率 >60,雙端都存在這個問題。
- 解決:在業務方面,我們是沒有 60fps 轉碼的,因此播放器僅支持 60fps 播放,60+ 倍速沒有支持,這類視頻是百度超分轉碼沒有限制幀率,導致會有部分視頻出現60fps,最終雙端播放器支持 60+fps 播放解決該問題,同時我們這邊其他轉碼也支持高幀率視頻了。
Tips:倍速播放我們這邊采用的是:沒有跳幀的變速播放,在不跳幀的情況下改變視頻的播放速度,從而實現加快或減慢視頻播放的效果。音頻采用變速不變調,能夠改變音頻播放速度,同時不改變其音調的技術。
針對視頻各種各樣的問題,首要原則是不給自己設限,多了解總沒錯,比如不同分辨率視頻播放(480P、720P、1080P、4k......)、不同比例視頻播放(1:1、3:4、4:3、16:9......),不同幀率視頻播放(24fps、30fps、60fps、120fps)、HDR 和 SDR(目前端上播放器不支持 HDR,導致播放 HDR 視頻有色差,轉碼時需要兼容支持HDR轉SDR)、Livephoto、直播切片有水印類視頻播放、外接設備如藍牙耳機播放等等。
了解的越多,覆蓋的場景就會越全面,同時也是一個很好的知識積累機會。
關注流進入視頻詳情頁,再返回關注流沒有續播
原因:這個問題是當時一個技改 Https 轉 Http 播放時出現的一個問題,從關注流到視頻詳情頁我們會切換成 Http 的地址進行播放,當返回時又變成了 Https,播放器接受到的播放地址發生發生變化,導致播放器進行重播了,而不是續播。
解決:外部有播放器,涉及場景切換時兼容這種邏輯。
Tips:這個問題我將其放到經典案例分析,原因很簡單,因為在視頻測試過程中,碰到過視頻播放的很多問題,視覺呈現的問題效果都不一樣,比如這里的沒有續播,還有穿搭精選九宮格點擊視頻到視頻詳情頁視頻跳幀、播放不流暢、黑屏,防盜鏈過期換鏈播放等等,深究原因都是播放地址發生變化而導致的問題。只不過造成地址不一樣的原因不一樣,有的是緩存數據過期,有的是外部數據和里面數據下發不一致、有的是內部域名轉換等等。
因此碰到類似問題,可以先嘗試自己排查,逐一排除,同時對于一些技改保持對問題的敏感度,提前評估一些影響點。
五、視頻體驗我們做了什么
性能
- 安卓性能基線
圖片
- iOS性能基線
圖片
- 左移發現問題雙端累計發現了一些問題,其中有個別問題是版本技改引入,成功左移攔截。
性能分析
圖片
發熱分析
- 發熱壓測分析報告
昨當前報告共包含視頻詳情頁面共 1 個場景。視頻詳情頁面:該場景包含多個性能指標,其中,得物在 Android 端的部分指標上取得 Top。
圖片
總結
性能
- 建立性能基線,覆蓋當前業務核心頁面,雙端性能 Case 穩定運行。
- 針對 Debug 包進行 APM 平臺打通,性能異常指標通知提醒,累計發現多個性能問題。
- 針對 Debug 包進行 Crash 攔截,并打通 Crash 平臺和 Crash 異常通知提醒 ,累計發現多個 Crash。
- 性能問題歸類。
分析
- 針對雙端圖文、視頻、沉浸式、推薦流 4 個場景摸底排查并建立性能基線。
- 針對視頻做發熱壓測分析。
- 推動并支持開發完成視頻內容質量、秒開、卡頓上的一系列技改需求。
- 優化后完成性能分析并輸出報告,各場景指標排名獲得一定的提升,iOS 卡頓率下降 25%、視頻失敗率:下降 66.6%、首幀加載時長:降低 47%;Android 視頻失敗率:降低 42.8%;Android 首幀加載時長:降低 46.6%。