今年8月，雷鋒網(wǎng)將在深圳舉辦一場(chǎng)盛況空前的“全球人工智能與機(jī)器人創(chuàng)新大會(huì)（簡(jiǎn)稱(chēng)GAIR）”。屆時(shí)雷鋒網(wǎng)將發(fā)布“人工智能&機(jī)器人Top25創(chuàng)新企業(yè)榜”榜單。目前，我們正在拜訪(fǎng)人工智能、機(jī)器人領(lǐng)域的相關(guān)公司，從中篩選最終入選榜單的公司名單。如果你也想加入我們的榜單之中，請(qǐng)聯(lián)系：2020@leiphone.com

作為世界上最大的視頻平臺(tái)，YouTube 每天都會(huì)新增來(lái)自世界各地的數(shù)百萬(wàn)個(gè)視頻。這些視頻具有非常大的多樣性，對(duì) YouTube 來(lái)說(shuō)，要將這些不同的視頻和相關(guān)的音頻都轉(zhuǎn)換成人們可以接受的播放質(zhì)量是一個(gè)相當(dāng)大的挑戰(zhàn)。此外，盡管谷歌的計(jì)算和存儲(chǔ)資源非常龐大，但也總歸是有限的，要以上傳視頻的原格式存儲(chǔ)網(wǎng)絡(luò)視頻無(wú)疑會(huì)帶來(lái)顯著的額外成本。

為了提高網(wǎng)絡(luò)視頻的播放質(zhì)量，關(guān)鍵是要降低視頻和音頻的壓縮損失。增加比特率是一種方法，但同時(shí)那也需要更強(qiáng)大的網(wǎng)絡(luò)連接和更高的帶寬。而 YouTube 則選擇了另一種更聰明的做法：通過(guò)優(yōu)化視頻處理的參數(shù)使其在滿(mǎn)足最低視頻質(zhì)量標(biāo)準(zhǔn)的同時(shí)不會(huì)增加額外的比特率和計(jì)算周期。

要在視頻壓縮和轉(zhuǎn)碼時(shí)滿(mǎn)足視頻質(zhì)量、比特率和計(jì)算周期的要求，一般的做法是尋找對(duì)大量視頻（而非所有視頻）平均最優(yōu)的轉(zhuǎn)碼參數(shù)組合。這種最優(yōu)組合可以通過(guò)嘗試每種可能來(lái)尋找，直到找到最讓人滿(mǎn)意的結(jié)果。而最近，有一些公司甚至嘗試在每一段視頻上都使用這種“窮舉搜索”的方式來(lái)調(diào)整參數(shù)。
YouTube 通過(guò)在這一技術(shù)的基礎(chǔ)上引入機(jī)器學(xué)習(xí)而開(kāi)發(fā)出了一種新的自動(dòng)調(diào)整參數(shù)的方法。目前，這一技術(shù)已經(jīng)在提升 YouTube 和 Google Play視頻影片的質(zhì)量上得到了應(yīng)用。

并行處理的優(yōu)劣

據(jù) YouTube 的博客介紹，每分鐘都有 400 小時(shí)的視頻被上傳到 YouTube 上。而其中每個(gè)視頻都需要被不同的轉(zhuǎn)碼器轉(zhuǎn)碼成幾種不同的格式，以便可以在不同的設(shè)備上進(jìn)行播放。為了提高轉(zhuǎn)碼速度，讓用戶(hù)更快看到視頻，YouTube 將上傳的每一個(gè)文件都切割成被稱(chēng)為“數(shù)據(jù)塊（chunk）”的片段，然后再將其每一塊都獨(dú)立地在谷歌云計(jì)算基礎(chǔ)設(shè)施的 CPU 中同時(shí)進(jìn)行并行處理。在這一過(guò)程中所涉及到分塊和重組是 YouTube 的視頻轉(zhuǎn)碼中的一大難題。而除了重組轉(zhuǎn)碼后數(shù)據(jù)塊的機(jī)制，保持每一段轉(zhuǎn)碼后的視頻的質(zhì)量也是一個(gè)挑戰(zhàn)。這是因?yàn)闉榱吮M可能快地處理，這些數(shù)據(jù)塊之間不會(huì)有重疊，而且它們會(huì)被切割得非常小——每段只有幾秒鐘。所以并行處理有提升速度和降低延遲的優(yōu)勢(shì)，但它也有劣勢(shì)：缺失了前后臨近視頻塊的信息，也因此難以保證每個(gè)視頻塊在被處理后都具有看上去相同的質(zhì)量。小數(shù)據(jù)塊不會(huì)給編碼器太多時(shí)間使其進(jìn)入一個(gè)穩(wěn)定的狀態(tài)，所以每一個(gè)編碼器在處理每一個(gè)數(shù)據(jù)塊上都略有不同。

智能并行處理

為了得到穩(wěn)定的質(zhì)量，可以在編碼器之間溝通同一視頻中不同分塊的信息，這樣每一個(gè)編碼器都可以根據(jù)其處理塊的前后塊進(jìn)行調(diào)整。但這樣做會(huì)導(dǎo)致進(jìn)程間通信的增加，從而提高整個(gè)系統(tǒng)的復(fù)雜度，并在每一個(gè)數(shù)據(jù)塊的處理中都要求額外的迭代。

但“其實(shí)，事實(shí)上我們?cè)诠こ谭矫娑己芄虉?zhí)，我們想知道我們能將‘不要讓數(shù)據(jù)塊彼此通信’的想法推進(jìn)多遠(yuǎn)?！盰ouTube 博客說(shuō)。

下面的曲線(xiàn)圖展示了來(lái)自一段使用 H.264 作為編解碼器的 720p 視頻的兩個(gè)數(shù)據(jù)塊的峰值信噪比（PSNR，單位：dB每幀）。PSNR值越高，意味著圖片（視頻每幀）的質(zhì)量越高；反之則圖片質(zhì)量越低。可以看到每段視頻開(kāi)始時(shí)的質(zhì)量非常不同于結(jié)束時(shí)的質(zhì)量。這不僅在平均質(zhì)量上沒(méi)有達(dá)到我們的要求，這樣劇烈的質(zhì)量變化也會(huì)導(dǎo)致惱人的搏動(dòng)偽影（pulsing artifact）。

因?yàn)閿?shù)據(jù)塊很小，還要讓每一塊的行為都與其前后塊的行為類(lèi)似；所以研究人員需要在連續(xù)數(shù)據(jù)塊的編碼處理上保持一個(gè)大致相同的結(jié)果。盡管這在大部分情況下適用，但卻不適用于本例。一個(gè)直接的解決辦法是改變數(shù)據(jù)塊的邊界使其與高活動(dòng)的視頻行為保持一致，例如快速運(yùn)動(dòng)或場(chǎng)景剪切。但這樣做就能讓保證數(shù)據(jù)塊的相對(duì)質(zhì)量并使編碼后的結(jié)果更均勻嗎。事實(shí)證明這確實(shí)能有所改善，但并不能達(dá)到我們期望的程度，不穩(wěn)定性仍經(jīng)常存在。

關(guān)鍵是要讓編碼器多次處理每一個(gè)數(shù)據(jù)塊，并從每一次迭代中學(xué)習(xí)怎么調(diào)整其參數(shù)以為整個(gè)數(shù)據(jù)塊中將發(fā)生的事做好準(zhǔn)備，而非僅其中的一小部分。這將導(dǎo)致每一個(gè)數(shù)據(jù)塊的開(kāi)端和結(jié)束擁有相似的質(zhì)量，而且因?yàn)閿?shù)據(jù)塊很短，所以總體上不同數(shù)據(jù)塊之間的差異也減少了。但即便如此，要實(shí)現(xiàn)這樣的目標(biāo)，就需要很多次的重復(fù)迭代。研究人員觀(guān)察到，重復(fù)迭代的次數(shù)會(huì)受到編碼器在第一次迭代上的量化相關(guān)參數(shù)（CRF）的很大影響。更妙的是，往往存在一個(gè)“最好的”CRF 可以在保持期望質(zhì)量的同時(shí)只用一次迭代就能達(dá)到目標(biāo)比特率。但這個(gè)“最好的”卻會(huì)隨著每段視頻的變化而變化——這就是棘手的地方。所以只要能找到每段視頻的最好配置，就能得到一個(gè)生成期望編碼視頻的簡(jiǎn)單方法。

上圖展示了 YouTube 的研究人員在同一段 1080p 視頻片段上使用他們的編碼器實(shí)驗(yàn)不同的 CRF 所得到的比特率結(jié)果（編碼后的視頻質(zhì)量恒定）?？梢钥闯?，CRF 和比特率之間存在一個(gè)明顯的函數(shù)關(guān)系。事實(shí)上這是對(duì)使用三個(gè)參數(shù)的指數(shù)擬合的非常好的建模，而且該圖也表明建模線(xiàn)（藍(lán)線(xiàn)）與實(shí)際觀(guān)察到的數(shù)據(jù)（點(diǎn)）擬合得非常好。如果我們知道該線(xiàn)的參數(shù)，然后我們想得到一個(gè)我們的視頻片段的 5 Mbps 版本，那么我們所需的 CRF 大約為 20.

大腦

那么接下來(lái)需要的就是一種能夠通過(guò)對(duì)視頻片段的低復(fù)雜度的測(cè)量預(yù)測(cè)三個(gè)曲線(xiàn)擬合參數(shù)的方式。這是機(jī)器學(xué)習(xí)、統(tǒng)計(jì)學(xué)和信號(hào)處理中的經(jīng)典問(wèn)題。YouTube 研究人員已將其相關(guān)的數(shù)學(xué)細(xì)節(jié)發(fā)表在他們的論文中（見(jiàn)文末1，其中還包括研究人員想法的演化歷程）。而簡(jiǎn)單總結(jié)來(lái)說(shuō)：通過(guò)已知的關(guān)于輸入視頻片段的信息預(yù)測(cè)三個(gè)參數(shù)，并從中讀出我們所需的 CRF。其中的預(yù)測(cè)階段就是“谷歌大腦（Google Brain）”的用武之地。

前面提到的“關(guān)于輸入視頻片段的信息”被稱(chēng)為視頻的“特征（features）”。在 YouTube 研究人員的定義中，這些特征（包括輸入比特率、輸入文件中的運(yùn)動(dòng)矢量位、視頻分辨率和幀速率）構(gòu)成了一個(gè)特征向量。對(duì)這些特征的測(cè)量也包括來(lái)自輸入視頻片段的非?？焖俚牡唾|(zhì)量轉(zhuǎn)碼（能提供更豐富的信息）。但是，每個(gè)視頻片段的特征和曲線(xiàn)參數(shù)之間的確切關(guān)系實(shí)際上非常復(fù)雜，不是一個(gè)簡(jiǎn)單的方程就能表示的。所以聰明的研究人員并不打算自己來(lái)發(fā)現(xiàn)這些特征，他們轉(zhuǎn)而尋求谷歌大腦的機(jī)器學(xué)習(xí)的幫助。研究人員首先選擇了 10000 段視頻，并對(duì)其中每一段視頻的每一個(gè)質(zhì)量設(shè)置都進(jìn)行了嚴(yán)格的測(cè)試，并測(cè)量了每一種設(shè)置的結(jié)果比特率。然后研究人員得到了 10000 條曲線(xiàn)，通過(guò)測(cè)量這些曲線(xiàn)研究人員又得到了 4×10000 個(gè)參數(shù)。

有了這些參數(shù)，就可以從視頻片段中提取特征了。通過(guò)這些訓(xùn)練數(shù)據(jù)和特征集合，YouTube 的機(jī)器學(xué)習(xí)系統(tǒng)學(xué)到了一個(gè)可以預(yù)測(cè)特征的參數(shù)的“大腦（Brain）”配置?！皩?shí)際上我們?cè)谑褂么竽X的同時(shí)也使用一種簡(jiǎn)單的‘回歸（regression）’技術(shù)。這兩者都優(yōu)于我們現(xiàn)有的策略。盡管訓(xùn)練大腦的過(guò)程需要相對(duì)較多的計(jì)算，但得到的系統(tǒng)實(shí)際上相當(dāng)簡(jiǎn)單且只需要在我們的特征上的一點(diǎn)操作。那意味著生產(chǎn)過(guò)程中的計(jì)算負(fù)載很小?！?/span>

這種方法有效嗎？

上圖展示了在 10000 個(gè)視頻片段上的各個(gè)系統(tǒng)的性能。其中每一個(gè)點(diǎn)（x,y）代表了壓縮后的結(jié)果視頻的比特率為原視頻的比特率的 x% 時(shí)的質(zhì)量百分比（y 軸）。其中的藍(lán)線(xiàn)表示在每一個(gè)視頻片段上都使用窮舉搜索獲取完美的 CRF 所得到的最好的情況。任何接近它的系統(tǒng)都是好系統(tǒng)?？梢钥吹剑诒忍芈蕿?20% 時(shí)，舊系統(tǒng)（綠線(xiàn)）的結(jié)果視頻質(zhì)量只有 15 %. 而使用了大腦系統(tǒng)之后，如果僅使用你所上傳的視頻的特征，質(zhì)量可以達(dá)到 65%；如果還使用一些來(lái)自非常快速低質(zhì)量轉(zhuǎn)碼的特征，更是能超過(guò) 80%（虛線(xiàn)）。

但是，實(shí)際上看起來(lái)如何？你可能已經(jīng)注意到比起畫(huà)質(zhì)，YouTube 研究人員似乎更關(guān)注比特率。因?yàn)椤拔覀儗?duì)這個(gè)問(wèn)題分析表明這才是根本原因 ”。畫(huà)質(zhì)只有真正被看到眼里時(shí)我們才知道好不好。下面展示了來(lái)自一段 720p 視頻的一些幀（從一輛賽車(chē)上拍攝）。上一列的兩幀來(lái)自一個(gè)典型數(shù)據(jù)塊的開(kāi)始和結(jié)尾，可以看到第一幀的質(zhì)量遠(yuǎn)差于最后一幀。下一列的兩幀來(lái)自上述的新型自動(dòng)剪輯適應(yīng)系統(tǒng)處理后的同一個(gè)數(shù)據(jù)塊。兩個(gè)結(jié)果視頻的比特率為相同的 2.8 Mbps。可以看到，第一幀的質(zhì)量已有了顯著的提升，最后一幀看起來(lái)也更好了。所以質(zhì)量上的暫時(shí)波動(dòng)消失了，片段的整體質(zhì)量也得到了提升。

據(jù)悉，這一概念在 YouTube 視頻基礎(chǔ)設(shè)施部分的生產(chǎn)中已被使用了大約一年時(shí)間。YouTube的博客寫(xiě)道：“我們很高興地報(bào)告：它已經(jīng)幫助我們?yōu)椤短┨鼓峥颂?hào)》和最近的《007：幽靈黨》這樣的電影提供了非常好的視頻傳輸流。我們不期望任何人注意到這一點(diǎn)，因?yàn)樗麄儾恢浪雌饋?lái)還能是什么樣?！?/span>

參考文獻(xiàn)：

1. Optimizing transcoder quality targets using a neural network with an embedded bitrate model, Michele Covell, Martin Arjovsky, Yao-Chung Lin and Anil Kokaram, Proceedings of the Conference on Visual Information Processing and Communications 2016, San Francisco

2. Multipass Encoding for reducing pulsing artefacts in cloud based video transcoding, Yao-Chung Lin, Anil Kokaram and Hugh Denman, IEEE International Conference on Image Processing, pp 907-911, Quebec 2015

via YouTube

雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見(jiàn)轉(zhuǎn)載須知。