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