一、背景

當(dāng)談?wù)撊绾翁嵘曨l的體驗(yàn)時(shí)，我們需要明確互聯(lián)網(wǎng)視頻市場(chǎng)的背景和現(xiàn)狀，并分析用戶(hù)對(duì)于視頻體驗(yàn)的期望和挑戰(zhàn)。

首先，隨著移動(dòng)網(wǎng)絡(luò)的普及和互聯(lián)網(wǎng)帶寬的不斷提升，視頻觀看已成為互聯(lián)網(wǎng)的主要應(yīng)用之一，視頻內(nèi)容也涉及更多的領(lǐng)域，例如教育、電商、社交等。同時(shí)，視頻流量的份額也逐漸擴(kuò)大，占據(jù)著互聯(lián)網(wǎng)流量的重要部分。可是，面對(duì)海量的視頻內(nèi)容，用戶(hù)們提出了越來(lái)越高的要求，如需要更快的加載速度、更流暢的播放體驗(yàn)、更高的畫(huà)質(zhì)和分辨率等，這些要求又產(chǎn)生了一系列挑戰(zhàn)。

其次，不良的網(wǎng)絡(luò)環(huán)境和設(shè)備所帶來(lái)的影響也是視頻體驗(yàn)不理想的重要原因之一，例如網(wǎng)絡(luò)延遲、帶寬瓶頸、設(shè)備性能等，這些因素都可能導(dǎo)致視頻的卡頓、畫(huà)面模糊、下載速度慢等質(zhì)量問(wèn)題。此外，由于網(wǎng)絡(luò)環(huán)境的差異和視頻內(nèi)容的多樣性，保障用戶(hù)體驗(yàn)變得更加復(fù)雜，需要針對(duì)不同的用戶(hù)需求和設(shè)備特性，采用不同的優(yōu)化方案和技術(shù)手段。

針對(duì)這些問(wèn)題，我們需要梳理出優(yōu)化視頻體驗(yàn)的技術(shù)手段和測(cè)試角度，以提高視頻的質(zhì)量和用戶(hù)的滿(mǎn)意度。并通過(guò)不斷的優(yōu)化落地，最終來(lái)提升視頻體驗(yàn)并提高市場(chǎng)競(jìng)爭(zhēng)力。

上半年我們針對(duì)得物視頻場(chǎng)景做了數(shù)據(jù)摸底，主要涉及的場(chǎng)景包含視頻流和沉浸視頻流，收集的指標(biāo)包括卡頓率，秒開(kāi)數(shù)據(jù)，CPU，內(nèi)存及主客觀質(zhì)量。從結(jié)果來(lái)看，我們?cè)趦?nèi)容質(zhì)量、秒開(kāi)、卡頓上都有一定的提升空間。

二、視頻體驗(yàn)技術(shù)優(yōu)化

為了優(yōu)化以上存在的痛點(diǎn)問(wèn)題，我們針對(duì)視頻規(guī)劃了一系列的優(yōu)化項(xiàng)目，主要從視頻質(zhì)量提升、視頻卡頓率優(yōu)化、視頻秒開(kāi)優(yōu)化這 3 方面進(jìn)行整改。

視頻質(zhì)量提升

圖片

視頻卡頓率優(yōu)化

圖片

視頻秒開(kāi)優(yōu)化

圖片

其他

圖片

三、視頻從發(fā)布到消費(fèi)

發(fā)布

發(fā)布入口

• App發(fā)布
• 創(chuàng)作者后臺(tái)發(fā)布
• 達(dá)人后臺(tái)發(fā)布

發(fā)布流程

• 視頻素材選擇

圖片

• 視頻封面設(shè)置

圖片

發(fā)布上傳

• 獲取 Oss 上傳地址和 Token
• 將 URL 上傳給社區(qū)服務(wù)端

編碼

圖片

圖片

云廠商

• 原視頻 720P-H264 窄帶高清轉(zhuǎn)碼工作流（基礎(chǔ)轉(zhuǎn)碼）。
• 轉(zhuǎn)碼完成后調(diào)用【算法服務(wù)】去水印&加水印。
• 觸發(fā)時(shí)機(jī)：視頻發(fā)布完成自動(dòng)觸發(fā)。

社區(qū)服務(wù)

• 動(dòng)態(tài)發(fā)布接口：

保存原視頻鏈接到內(nèi)容媒體庫(kù)。

轉(zhuǎn)碼檢查，增加云廠商轉(zhuǎn)碼視頻檢查記錄，待檢查轉(zhuǎn)碼狀態(tài)。

• 轉(zhuǎn)碼檢查處理腳本：
• 檢查云廠商轉(zhuǎn)碼是否完成，完成后保存到內(nèi)容媒體庫(kù)，同時(shí)請(qǐng)求算法去水印。
• 檢查內(nèi)容媒體中心轉(zhuǎn)碼是否完成，完成后保存到內(nèi)容媒體庫(kù)。
• 媒體中心回調(diào)：
• 接收媒體中心轉(zhuǎn)碼回調(diào)，更新內(nèi)容媒體庫(kù)原視頻寬高、時(shí)長(zhǎng)等信息。
• 往轉(zhuǎn)碼檢查表增加媒體中心轉(zhuǎn)碼的多種轉(zhuǎn)碼視頻記錄待檢查轉(zhuǎn)碼狀態(tài)。
• 寬和高同時(shí)大于 720 會(huì)觸發(fā) 2 路轉(zhuǎn)碼（720P-H265和1080P-H265），否則一路轉(zhuǎn)碼（720P-H265）。
• 算法處理回調(diào)：
• 接收算法去水印、生成封面圖等處理回調(diào)，保存處理后內(nèi)容文件到內(nèi)容媒體庫(kù)。
• 去水印類(lèi)型，MQ 通知中后臺(tái)視頻轉(zhuǎn)碼已完成，中后臺(tái)開(kāi)始審核流程。

媒體中心

圖片

• 接收服務(wù)端原視頻轉(zhuǎn)碼請(qǐng)求，云廠商轉(zhuǎn)碼。
• 監(jiān)聽(tīng)二審二審?fù)ㄟ^(guò)、熱門(mén)視頻、高幀率處理微幀轉(zhuǎn)碼。
• 監(jiān)聽(tīng)打標(biāo)結(jié)果、籃球美妝類(lèi)視頻，視頻增強(qiáng)轉(zhuǎn)碼。
• 視頻首幀截取處理。
• 回調(diào)社區(qū)服務(wù)媒體中心，回傳轉(zhuǎn)碼完成后視頻相關(guān)信息。

算法服務(wù)：

• 去原視頻水印。
• 生成封面圖。
• 加品宣水印。
• 策略算法商品封面圖。

解碼

業(yè)務(wù)播放流程

前面我們?cè)谵D(zhuǎn)碼時(shí)介紹了很多種不同的轉(zhuǎn)碼類(lèi)型、同時(shí)針對(duì)不同的轉(zhuǎn)碼定義了 Type 的多個(gè)枚舉值，作用就在于業(yè)務(wù)這邊的播放優(yōu)先級(jí)策略。

• 冷啟動(dòng)讀取視頻切換策略。
• 視頻動(dòng)態(tài)下發(fā)兜底播放 URL、轉(zhuǎn)碼播放 URL、類(lèi)型 Type。

圖片

總結(jié)：

• 每次冷啟動(dòng)會(huì)拉取配置中心配置的視頻播放策略。
• 播放視頻時(shí)，根據(jù)配置中心配置優(yōu)先級(jí)，讀取實(shí)際下發(fā)的 Type，選對(duì)應(yīng)的 Type 進(jìn)行播放。
• 解碼器選擇：配置中心中配置了 264 解碼器播放類(lèi)型和 265 解碼器播放類(lèi)型，我們會(huì)根據(jù)對(duì)應(yīng)優(yōu)先級(jí)選中對(duì)應(yīng) Type 的 URL 進(jìn)行播放，然后再選中對(duì)應(yīng)的解碼器進(jìn)行解碼。
• 預(yù)下載大小：配置中心中配置了不同類(lèi)型預(yù)下載大小，那么我們會(huì)根據(jù)播放類(lèi)型進(jìn)行預(yù)下載。

如果 Video 下發(fā)為空，那么我們會(huì)使用兜底鏈接播放。

首幀加載邏輯

• 可以先看一下下面的例子：

• 為了防止有人惡意將我們服務(wù)當(dāng)做視頻存儲(chǔ)地址，同時(shí)出于規(guī)避黑灰產(chǎn)的非法資源的合規(guī)風(fēng)險(xiǎn)，我們針對(duì)視頻做了防盜鏈技術(shù)，即視頻地址是有有效期的，超過(guò)配置的有效時(shí)間，地址會(huì)失效，播放時(shí)，需要進(jìn)行換鏈請(qǐng)求。這里帶來(lái)的一個(gè)問(wèn)題就是存在一些場(chǎng)景在進(jìn)入視頻詳情頁(yè)時(shí)無(wú)法加載首幀圖，只有黑底圖到視頻播放的過(guò)渡，影響秒開(kāi)。
• 同時(shí)，視頻是可以設(shè)置封面的，封面可能是算法識(shí)別、也可能是用戶(hù)自己選擇，這就造成了很大的不確定性，即封面很有可能不是視頻首幀，甚至和視頻毫無(wú)關(guān)聯(lián)。這類(lèi)視頻，我們?cè)谶M(jìn)入視頻詳情頁(yè)先用封面填充，但到播放時(shí)會(huì)感覺(jué)明顯跳幀，畫(huà)面不連貫，也非常影響視頻觀看的體驗(yàn)。

因此，雖然我們有預(yù)下載首幀邏輯，但如果視頻地址過(guò)期，首幀下載是會(huì)失敗的，就存在了如上進(jìn)入視頻先出現(xiàn)黑底圖的現(xiàn)象。基于此，我們做了首幀加載邏輯的優(yōu)化。

• 首幀獲取邏輯

圖片

圖片

• 播放邏輯策略

取得新的視頻首幀圖片后需要自行拼接裁剪參數(shù)，目前統(tǒng)一轉(zhuǎn) Heic 格式圖片，裁剪寬度最大 360（和線(xiàn)上邏輯一致），高度自適配。轉(zhuǎn)成 Heic 可以有效降低文件大小，減少網(wǎng)絡(luò)傳輸成本，提升首幀加載速度。

圖片

優(yōu)先級(jí)：視頻首幀的圖片緩存 > 雙列卡片的封面圖片緩存 > 加載首幀網(wǎng)絡(luò)圖并以黑底圖兜底。

沉浸流冷啟優(yōu)化

圖片

最終展示的數(shù)據(jù)情況：

• 之前某次啟動(dòng)的緩存數(shù)據(jù) 1 條 + 本次啟動(dòng)沉浸流請(qǐng)求的后續(xù)數(shù)據(jù) 6 條。
• 本次啟動(dòng)社區(qū)首頁(yè)請(qǐng)求的數(shù)據(jù) 1 條 + 本次啟動(dòng)沉浸流請(qǐng)求的后續(xù)數(shù)據(jù) 6 條。
• 本次啟動(dòng)沉浸流請(qǐng)求的數(shù)據(jù) 6 條。

播放器復(fù)用

優(yōu)化前：

優(yōu)化后：

這里我們可以明顯看到優(yōu)化前，關(guān)注流進(jìn)入到視頻詳情頁(yè)會(huì)黑一下，優(yōu)化后就更加絲滑了，肉眼看不出有黑屏的情況。這里我們主要就是使用了播放器復(fù)用來(lái)解決這個(gè)問(wèn)題，節(jié)省創(chuàng)建播放器內(nèi)核等待時(shí)間。

• 創(chuàng)建 View 的時(shí)機(jī)

每次點(diǎn)擊提前創(chuàng)建 View 開(kāi)始解碼。

跳轉(zhuǎn)后將 View add 到屏幕上。

復(fù)用過(guò)程就是 A 頁(yè)面解綁 -B 頁(yè)面綁定 -B 頁(yè)面解綁 -A 頁(yè)面重新綁定。

當(dāng)然這里，推薦流是比較特殊的，有個(gè)共享的播放器實(shí)例。

四、過(guò)程中典型案例分析

沉浸流冷啟優(yōu)化內(nèi)存泄漏

圖片

Tips：針對(duì)端上的一些大需求、模塊技改、底層邏輯重構(gòu)等等，我們可以結(jié)合自動(dòng)化來(lái)驗(yàn)證 App 的穩(wěn)定性，業(yè)務(wù)邏輯測(cè)試 + 探索性測(cè)試 + 自動(dòng)化測(cè)試 + 灰度驗(yàn)證，在整個(gè)版本周期都能通過(guò)一些手段去有效發(fā)現(xiàn)問(wèn)題，左移前置的越多，線(xiàn)上暴露的問(wèn)題就會(huì)越少。

當(dāng)然往往這些都伴隨了一些 AB，因此我們?cè)谂茏詣?dòng)化時(shí)要把 AB 打開(kāi)。讓這些功能能提前得到一些驗(yàn)證。

高幀率倍速播放音畫(huà)不同步

• 原因：在回歸時(shí)，發(fā)現(xiàn)部分視頻倍速播放出現(xiàn)音畫(huà)不同步的現(xiàn)象，排查發(fā)現(xiàn)，該視頻是 60fps，2 倍速的話(huà)會(huì)變成 120fps，播放器渲染不過(guò)來(lái)了。因此當(dāng)倍速 *幀率 >60，雙端都存在這個(gè)問(wèn)題。
• 解決：在業(yè)務(wù)方面，我們是沒(méi)有 60fps 轉(zhuǎn)碼的，因此播放器僅支持 60fps 播放，60+ 倍速?zèng)]有支持，這類(lèi)視頻是百度超分轉(zhuǎn)碼沒(méi)有限制幀率，導(dǎo)致會(huì)有部分視頻出現(xiàn)60fps，最終雙端播放器支持 60+fps 播放解決該問(wèn)題，同時(shí)我們這邊其他轉(zhuǎn)碼也支持高幀率視頻了。

Tips：倍速播放我們這邊采用的是：沒(méi)有跳幀的變速播放，在不跳幀的情況下改變視頻的播放速度，從而實(shí)現(xiàn)加快或減慢視頻播放的效果。音頻采用變速不變調(diào)，能夠改變音頻播放速度，同時(shí)不改變其音調(diào)的技術(shù)。

針對(duì)視頻各種各樣的問(wèn)題，首要原則是不給自己設(shè)限，多了解總沒(méi)錯(cuò)，比如不同分辨率視頻播放（480P、720P、1080P、4k......）、不同比例視頻播放（1：1、3：4、4：3、16:9......），不同幀率視頻播放（24fps、30fps、60fps、120fps）、HDR 和 SDR（目前端上播放器不支持 HDR，導(dǎo)致播放 HDR 視頻有色差，轉(zhuǎn)碼時(shí)需要兼容支持HDR轉(zhuǎn)SDR）、Livephoto、直播切片有水印類(lèi)視頻播放、外接設(shè)備如藍(lán)牙耳機(jī)播放等等。

了解的越多，覆蓋的場(chǎng)景就會(huì)越全面，同時(shí)也是一個(gè)很好的知識(shí)積累機(jī)會(huì)。

關(guān)注流進(jìn)入視頻詳情頁(yè)，再返回關(guān)注流沒(méi)有續(xù)播

原因：這個(gè)問(wèn)題是當(dāng)時(shí)一個(gè)技改 Https 轉(zhuǎn) Http 播放時(shí)出現(xiàn)的一個(gè)問(wèn)題，從關(guān)注流到視頻詳情頁(yè)我們會(huì)切換成 Http 的地址進(jìn)行播放，當(dāng)返回時(shí)又變成了 Https，播放器接受到的播放地址發(fā)生發(fā)生變化，導(dǎo)致播放器進(jìn)行重播了，而不是續(xù)播。

解決：外部有播放器，涉及場(chǎng)景切換時(shí)兼容這種邏輯。

Tips：這個(gè)問(wèn)題我將其放到經(jīng)典案例分析，原因很簡(jiǎn)單，因?yàn)樵谝曨l測(cè)試過(guò)程中，碰到過(guò)視頻播放的很多問(wèn)題，視覺(jué)呈現(xiàn)的問(wèn)題效果都不一樣，比如這里的沒(méi)有續(xù)播，還有穿搭精選九宮格點(diǎn)擊視頻到視頻詳情頁(yè)視頻跳幀、播放不流暢、黑屏，防盜鏈過(guò)期換鏈播放等等，深究原因都是播放地址發(fā)生變化而導(dǎo)致的問(wèn)題。只不過(guò)造成地址不一樣的原因不一樣，有的是緩存數(shù)據(jù)過(guò)期，有的是外部數(shù)據(jù)和里面數(shù)據(jù)下發(fā)不一致、有的是內(nèi)部域名轉(zhuǎn)換等等。

因此碰到類(lèi)似問(wèn)題，可以先嘗試自己排查，逐一排除，同時(shí)對(duì)于一些技改保持對(duì)問(wèn)題的敏感度，提前評(píng)估一些影響點(diǎn)。

五、視頻體驗(yàn)我們做了什么

性能

• 安卓性能基線(xiàn)

圖片

• iOS性能基線(xiàn)

圖片

• 左移發(fā)現(xiàn)問(wèn)題雙端累計(jì)發(fā)現(xiàn)了一些問(wèn)題，其中有個(gè)別問(wèn)題是版本技改引入，成功左移攔截。

性能分析

圖片

發(fā)熱分析

• 發(fā)熱壓測(cè)分析報(bào)告

昨當(dāng)前報(bào)告共包含視頻詳情頁(yè)面共 1 個(gè)場(chǎng)景。視頻詳情頁(yè)面：該場(chǎng)景包含多個(gè)性能指標(biāo)，其中，得物在 Android 端的部分指標(biāo)上取得 Top。

圖片

總結(jié)

性能

• 建立性能基線(xiàn)，覆蓋當(dāng)前業(yè)務(wù)核心頁(yè)面，雙端性能 Case 穩(wěn)定運(yùn)行。
• 針對(duì) Debug 包進(jìn)行 APM 平臺(tái)打通，性能異常指標(biāo)通知提醒，累計(jì)發(fā)現(xiàn)多個(gè)性能問(wèn)題。
• 針對(duì) Debug 包進(jìn)行 Crash 攔截，并打通 Crash 平臺(tái)和 Crash 異常通知提醒 ，累計(jì)發(fā)現(xiàn)多個(gè) Crash。
• 性能問(wèn)題歸類(lèi)。

分析

• 針對(duì)雙端圖文、視頻、沉浸式、推薦流 4 個(gè)場(chǎng)景摸底排查并建立性能基線(xiàn)。
• 針對(duì)視頻做發(fā)熱壓測(cè)分析。
• 推動(dòng)并支持開(kāi)發(fā)完成視頻內(nèi)容質(zhì)量、秒開(kāi)、卡頓上的一系列技改需求。
• 優(yōu)化后完成性能分析并輸出報(bào)告，各場(chǎng)景指標(biāo)排名獲得一定的提升，iOS 卡頓率下降 25%、視頻失敗率：下降 66.6%、首幀加載時(shí)長(zhǎng)：降低 47%；Android 視頻失敗率：降低 42.8%；Android 首幀加載時(shí)長(zhǎng)：降低 46.6%。

六、未來(lái)展望