?[[443150]]??

【51CTO.com原創(chuàng)稿件】

 作者丨徐慧書

策劃丨徐承杰

近幾年直播和短視頻的興起，將整個(gè)音視頻消費(fèi)推上了一個(gè)新的高度，甚至可以說(shuō)每一位互聯(lián)網(wǎng)用戶都是視頻消費(fèi)用戶，并且其中相當(dāng)多的一部分還是視頻生產(chǎn)用戶。作為一名技術(shù)人員，該如何去看待當(dāng)下火熱繁榮的視頻消費(fèi)生態(tài)呢?前不久，來(lái)自阿里巴巴的高級(jí)技術(shù)專家、UC 播放技術(shù)負(fù)責(zé)人徐慧書針對(duì)視頻、播放器及視頻啟播技術(shù)優(yōu)化等話題進(jìn)行了詳細(xì)地解讀與分享。

視頻的壓縮存儲(chǔ)

1、容器概念

如今，人們每天都會(huì)接觸視頻，視頻文件很大，視頻文件所包含的信息也很多。想要對(duì)這些信息進(jìn)行組織，就需要利用容器。容器可以通過(guò)嚴(yán)格的規(guī)范，組織存放視頻中的各類信息，在這個(gè)領(lǐng)域做的比較好的是 mp4。當(dāng)然也有應(yīng)對(duì)于直播、高清等各種差異化需求的一些其他的容器格式。而容器中所存放的最為重要的便是視頻數(shù)據(jù)本身。視頻的原始數(shù)據(jù)是非常大的，以 1080P 的電影為例，90 分鐘時(shí)長(zhǎng)，一秒 30 幀的幀率，其原始視頻的大小大概是一萬(wàn)億個(gè)字節(jié)，換算成更有體感的數(shù)據(jù)，就是 1TB。

???

2、視頻壓縮的多種方法

因此，在進(jìn)行視頻數(shù)據(jù)存儲(chǔ)時(shí)需要對(duì)視頻的原始數(shù)據(jù)進(jìn)行壓縮。視頻是由一幀一幀的圖片組成的，利用人的視覺(jué)暫留的特點(diǎn)，通過(guò)連續(xù)播放形成動(dòng)畫效果。因此在進(jìn)行視頻壓縮時(shí)，首先需要考慮對(duì)單張圖片進(jìn)行幀內(nèi)壓縮，其本質(zhì)是去除空間內(nèi)的冗余信息。例如在這張圖片中，女神的頭發(fā)都是黑色的，如此以來(lái)，在進(jìn)行圖片存儲(chǔ)時(shí)，一個(gè)宏塊之中只需要存儲(chǔ)一個(gè)像素點(diǎn)即可，這樣做便可以實(shí)現(xiàn)空間冗余信息的大幅壓縮。除了幀內(nèi)壓縮，視頻壓縮還有另一個(gè)重要概念——幀間壓縮。視頻在時(shí)間上有一定的連續(xù)性，因此視頻中連續(xù)出現(xiàn)的圖片會(huì)有非常大的相似性。在面對(duì)相似圖片時(shí)，只存儲(chǔ)差異信息，相同信息則不進(jìn)行記錄，這樣可以使視頻的壓縮率保持在一個(gè)極高的水平。

???

除了對(duì)“量”的要求，視頻壓縮對(duì)“質(zhì)”的要求同樣重要。視頻壓縮是有損壓縮，在壓縮過(guò)程中，需要考慮人的視覺(jué)特性，對(duì)圖像中視覺(jué)不敏感的地方進(jìn)行大幅壓縮，視覺(jué)敏感的地方則進(jìn)行小幅度壓縮，盡可能保證視頻質(zhì)量少受損失。在視頻中每幀圖像都是由像素點(diǎn)組成的，而每個(gè)像素點(diǎn)都是由亮度和色度這兩個(gè)維度所組成。人在觀看視頻的過(guò)程中，對(duì)亮度的敏感性是更高的。但圖像一般是由 RGB 三基色所描繪的，其中并沒(méi)有亮度這個(gè)維度。想要保證視頻在壓縮過(guò)程中亮度不丟失，則需要引入 YUV 的概念。YUV 是圖像的一種新的表現(xiàn)形式，Y 表示亮度上的分量，UV 表示色度上的分量。在圖像的壓縮過(guò)程中，利用 YUV 將圖像的亮度和色度進(jìn)行分離，便可保證壓縮色度時(shí)亮度數(shù)據(jù)不受到影響。YUV 的轉(zhuǎn)換公式較為特殊，該公式并非推導(dǎo)公式，而是來(lái)于自實(shí)驗(yàn)室的實(shí)驗(yàn)數(shù)據(jù)。是通過(guò)實(shí)驗(yàn)進(jìn)行反復(fù)大量的驗(yàn)證，最終得出的實(shí)驗(yàn)參數(shù)。

???

Apollo & 秒播優(yōu)化

1、初識(shí) Apollo 播放器

Apollo 是 UC 一款內(nèi)核自研的視頻播放器，擁有高性能、高可用、高業(yè)務(wù)服務(wù)能力以及低資源消耗等優(yōu)點(diǎn)。作為一款自研播放器，Apollo 在視頻播放的流程上與其他播放器保持了基本的一致，首先進(jìn)行數(shù)據(jù)獲取，而后通過(guò) FFmpeg 解協(xié)議解封裝以得到原始數(shù)據(jù)，接著通過(guò)解碼解壓以及 YUV 轉(zhuǎn)化得到 RGB 數(shù)據(jù)，最后通過(guò) PDS 進(jìn)行音視頻同步并渲染到相應(yīng)的驅(qū)動(dòng)設(shè)備上，以實(shí)現(xiàn)視頻和音頻的呈現(xiàn)。而 Apollo 最大的特點(diǎn)，是接管了 FFmpeg 底層的數(shù)據(jù)網(wǎng)絡(luò)庫(kù)，并對(duì)數(shù)據(jù)層進(jìn)行非常多的優(yōu)化。

???

2、精準(zhǔn)預(yù)加載的新思路

在如今的移動(dòng)視頻消費(fèi)中，用戶最關(guān)注的一點(diǎn)是視頻秒播，而視頻秒播則需要視頻預(yù)加載技術(shù)的支持。傳統(tǒng)的預(yù)加載方案面臨流量消耗和秒播平衡的挑戰(zhàn)，預(yù)加載過(guò)多會(huì)造成資源浪費(fèi)，預(yù)加載過(guò)少則可能會(huì)由于數(shù)據(jù)缺失導(dǎo)致秒播失敗。傳統(tǒng)的預(yù)加載方案以視頻文件大小為視角進(jìn)行數(shù)據(jù)的預(yù)加載，但由于每一個(gè)視頻秒播所需的數(shù)據(jù)都不同，因此傳統(tǒng)的預(yù)加載方案例如估算和特定 size 的方法其實(shí)都無(wú)法做到對(duì)數(shù)據(jù)的精準(zhǔn)預(yù)加載。而 Apollo 在執(zhí)行預(yù)加載的過(guò)程中，以用戶播放為視角并模擬用戶播放的行為。當(dāng)所加載數(shù)據(jù)達(dá)到啟播需求時(shí)，將這些數(shù)據(jù)進(jìn)行緩存。這樣，當(dāng)預(yù)加載命中時(shí)，就必然能夠?qū)崿F(xiàn)視頻的秒播。但這也引出一個(gè)新的問(wèn)題，播放是一個(gè)非常消耗資源的行為，不可能因?yàn)轭A(yù)加載的優(yōu)化措施而浪費(fèi)用戶資源。因此，我們通過(guò)對(duì)整個(gè)流程的梳理與重構(gòu)，將 FFmpeg 抽離為 FFmpegMediaStream，將其從捆綁式的播放流程中解耦，作為一個(gè)通用的基礎(chǔ)組件供播放與預(yù)加載共同使用。這樣即可在不啟動(dòng)高資源消耗模塊的情況下，實(shí)現(xiàn)輕量級(jí)的模擬用戶播放。

???

優(yōu)化案例分享

1、Mp3 播放優(yōu)化方案

一個(gè)傳統(tǒng)的 Mp3 文件由頭文件、音頻數(shù)據(jù)及末尾的版權(quán)信息記錄組成。在播放過(guò)程中，會(huì)優(yōu)先讀取頭文件，接著跳轉(zhuǎn)到末尾讀取版權(quán)信息，最后跳轉(zhuǎn)回中間讀取音頻信息并進(jìn)行播放。這種讀取方式在離線消費(fèi)時(shí)代是沒(méi)有問(wèn)題的，但在在線播放時(shí)代，這樣的讀取方式會(huì)建立三次 HTTP 連接，每一次連接都會(huì)進(jìn)行 TCP 的三次握手。在國(guó)內(nèi)網(wǎng)絡(luò)比較好的情況下，一次也需要 100 多毫秒，而在公域或網(wǎng)絡(luò)條件較差的情況下，所需的時(shí)間更會(huì)成倍增長(zhǎng)。為解決這個(gè)問(wèn)題，我們?nèi)∠瞬シ胚^(guò)程中版權(quán)信息的讀取。由于在在線消費(fèi)時(shí)代，這些數(shù)據(jù)都來(lái)自于 API 獲取，且經(jīng)過(guò)大量的數(shù)據(jù)分析，我們發(fā)現(xiàn) Mp3 文件中末尾的版權(quán)信息都是無(wú)效數(shù)據(jù)，僅是用于格式對(duì)齊。因此這樣做并不會(huì)影響 Mp3 文件的正常讀取，且利用這種新的讀取模式能夠?qū)⒉サ暮臅r(shí)降低 60%。

???

2、Mp4 播放優(yōu)化方案

Mp4 的結(jié)構(gòu)是由 MOOV 數(shù)據(jù)頭和媒體數(shù)據(jù)組成的，在 MOOV 數(shù)據(jù)頭中會(huì)詳細(xì)記錄視頻中的每一幀信息，因此視頻時(shí)間越長(zhǎng)，MOOV 頭數(shù)據(jù)就會(huì)越多，這也就是在觀看長(zhǎng)電影時(shí)啟播速度慢的原因。當(dāng)然這依然是較為理想的情況，在現(xiàn)實(shí)情況中，F(xiàn)Fmpeg 在處理視頻時(shí)，會(huì)默認(rèn)將 MOOV 頭后置，這會(huì)導(dǎo)致啟播從一次 HTTP 連接增加為三次，進(jìn)一步增加啟播的耗時(shí)。在進(jìn)行這類場(chǎng)景的優(yōu)化時(shí)，針對(duì)這種內(nèi)部自 seek 情況，可以將前一次的連接任務(wù)進(jìn)行保存，當(dāng)完成 MOOV 頭數(shù)據(jù)讀取后，再進(jìn)行連接復(fù)用，這樣既可以減少一次 HTTP 連接，還可以增加網(wǎng)絡(luò)吞吐量。這種 MOOV 后置的優(yōu)化方式，可以將 Mp4 文件的播放性能提升 10% 以上。

???

3、HLS 播放優(yōu)化方案

HLS 是蘋果推出的一款流媒體傳輸協(xié)議。由一個(gè)后綴名為“.m3u8”的 TXT 的索引文件與指定個(gè)數(shù)的 TS 切片文件組成的。m3u8 文件記錄了每一個(gè) TS 文件的時(shí)長(zhǎng)、順序與下載鏈接。HLS 視頻的基礎(chǔ)播放流程是，首先開(kāi)始 m3u8 文件的下載，而后對(duì)文件進(jìn)行同步的解析與下載，接著逐個(gè)下載 TS 文件直到用戶播放。但在長(zhǎng)電影的播放場(chǎng)景下，TS 文件的個(gè)數(shù)有可能會(huì)多達(dá)幾千個(gè)，這將影響視頻的啟播速度。針對(duì)這類場(chǎng)景的優(yōu)化，我們采用的是在解析 m3u8 文件時(shí)，增加流失解析，解析到第一個(gè) TS 文件時(shí)即開(kāi)啟預(yù)下載，等解析完 m3u8 文件后再去做第一個(gè) TS 文件的下載，這樣就能夠?qū)?TS 文件從網(wǎng)絡(luò)數(shù)據(jù)的下載，轉(zhuǎn)化為本地?cái)?shù)據(jù)的獲取。如此以來(lái)，TS 文件的下載效率將得到極大的提升。

???

總結(jié)與展望

本次分享主要介紹了視頻與移動(dòng)播放器的概念，以及視頻秒播優(yōu)化的一些思路和方案。在未來(lái)，更加豐富的業(yè)務(wù)場(chǎng)景還將對(duì)播放器的極致優(yōu)化提出更多新的挑戰(zhàn)。視頻起播全鏈路耗時(shí)治理，公、私域視頻特點(diǎn)結(jié)合的優(yōu)化提速將會(huì)是 Apollo 技術(shù)團(tuán)隊(duì)后續(xù)的重點(diǎn)研究方向。希望在將來(lái)能夠給大家?guī)?lái)更加豐富的成果展示與技術(shù)分享。

嘉賓介紹

徐慧書，阿里巴巴高級(jí)技術(shù)專家 /UC 播放技術(shù)負(fù)責(zé)人，負(fù)責(zé)阿里創(chuàng)新事業(yè)群播放器技術(shù)團(tuán)隊(duì)，致力于打造業(yè)界最快的視頻播放器。服務(wù) UC 國(guó)內(nèi)、國(guó)際瀏覽器數(shù)億音視頻用戶，不斷提升用戶公、私域音視頻播放體驗(yàn)，同時(shí)拓展阿里集團(tuán)支付寶、釘釘、高德、天貓精靈、互娛等多個(gè)超級(jí) App 及數(shù)十個(gè)業(yè)務(wù)板塊的 web& 小程序視頻播放業(yè)務(wù)，承載每日近 30 億的視頻播放量。

2022 年 4 月 9 日的 WOT 全球技術(shù)創(chuàng)新大會(huì)“音視頻體驗(yàn)優(yōu)化”專題中，徐慧書老師也將作為演講嘉賓為大家?guī)?lái)《Android 自研播放器起播性能優(yōu)化》的演講。主要分享除常規(guī)視頻秒播技術(shù)優(yōu)化外，基于自研播放器的視頻播放全鏈路研究成果，內(nèi)容涉及視頻的數(shù)據(jù)加載、預(yù)加載、硬解碼、主流格式針對(duì)性優(yōu)化等方面的進(jìn)一步優(yōu)化。除此之外，來(lái)自阿里、快手、Disney 等企業(yè)的數(shù)位資深技術(shù)專家，也將在該專題中為大家?guī)?lái)有關(guān)音視頻應(yīng)用體驗(yàn)優(yōu)化的最佳實(shí)踐經(jīng)驗(yàn)分享。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】

???

???