您已經完成了對相當棘手的內容的編碼，其中一些內容比正常情況下涉及的質量控制要多一些，并且可以將其發布以供外部使用。但是首先您需要將其顯示給管理層，因此您需要將流上傳到預發布的登臺服務器，并向老板發送URL文本。幾分鐘后，您會收到一條短信，詢問為什么視頻質量如此差。
老板對視頻 看起來不好表示什么，以及如何解決該問題？是否存在特定場景的問題，媒體服務器中的故障，老板用來觀看視頻的移動設備上過時的播放器甚至公司VPN上的帶寬是否有問題？
歡迎來到我們稱為流媒體的錯綜復雜的世界。
在算法系列的上一篇文章中，我們研究了CDN背后的數學原理。好處是CDN可以準確地提供它們所得到的，并且通常會做得很好。但是有時，獲取方（例如，對點播內容進行編碼）會引入一個異常，該異常會通過CDN到達最終用戶，從而導致回放質量不合格。
在我剛才提到的場景中，編碼，傳輸和回放的算法在最終用戶的播放器應用程序中如何相交？這就是我們在本文中有關球員表現的內容。
編碼和傳送
“編碼一次，到處交付”是我們在 流媒體歷史上一直聽到的口號，這是我們取得不同成功水平的目標。在早期，這意味著使用正確的編解碼器和播放器組合，因為編碼器，媒體服務器和最終用戶播放器都是同一生態系統的一部分，例如Adobe，Microsoft或Real提供的付費解決方案。
問題是“無處不在”僅意味著其中一種專有解決方案的圍墻花園。如果一家公司使用Microsoft，但其客戶使用Real，則每個流平臺必須對內容進行一次編碼。
H.264（又稱高級視頻 編碼，AVC）的出現使編碼方面的情況變得更好了，H.264 通常以 MPEG-2或MPEG-4容器格式存儲。但是隨后，出現了各種不同的基于HTTP的交付方式，例如平滑流，Adobe HDS或Apple HTTP Live Streaming（HLS），它們至少需要以選定的比特率（稱為自適應比特率或ABR）進行多種編碼）或多個細分步驟，以每個專有的HTTP細分大小和清單文件進行交付。
幸運的是，這些問題中的大多數已通過一些專有格式解決，這些專有格式構成了行業標準 MPEG-DASH方法的基礎。同時，我們已經 看到Apple的HLS轉向了DASH使用的分段MP4（fMP4）方法。
因此，在編碼ABR內容時無需擔心，因為所有內容都將在任何給定時間基于適當的帶寬傳送，對嗎？是的，沒有。將ABR內容傳送到支持ABR的播放器時，需要考慮以下三件事。
有多少帶寬可用？
這是ABR播放器性能正常的主要問題之一。這不僅是在任何特定時刻的問題，而且還是在特定時刻之前的問題，請記住（正如大多數股票經紀人在向潛在客戶的推銷中所提到的那樣），過去的表現并不能保證未來的結果。 這是關鍵的原因是，當涉及到清單或MPD文件中接下來要請求哪個比特率合適的ABR段時，很多研究都假定播放器具有最佳決策。
在PV '18上，Brightcove的Yuriy Reznik和其他同事在第23包視頻研討會上發表了題為“ ABR流的編碼配置文件的最佳設計 ”的論文。雖然它描述了建模網絡帶寬的方法以及選擇給定ABR流的可能性（稍后將對此進行更多介紹），但是值得考慮兩種不同的算法方法來解決調度問題。
第一個方法涉及引入平滑濾波器以估計帶寬，如“ 自適應HTTP流的調度和速率自適應算法的設計”中所述”，這是 斯蒂芬·黑塞（Stephan Hesse）在Fraunhofer / HHI工作時寫的，并且部分由歐盟框架計劃7（FP7）開放內容感知網絡（OCEAN）項目資助（見圖1）。Reznik及其合著者在他們的論文中引用了它作為一種實用方式的示例，其中“ ABR流客戶端估算可用帶寬……然后決定接下來要提取的編碼流”以盡可能多地利用可用帶寬。
圖1
黑塞寫道：“ 我們發現適合我們目的的一種眾所周知的平滑濾波器是指數移動平均濾波器。” “使用該濾波器，獲得當前的平滑帶寬估計 C k作為當前帶寬測量值T k和先前的平滑估計C k-1的加權平均值，”得出以下公式：
C k =（1-α）T k +αCk -1
在該式（式3在文章中）， α ＆Element;（0,1），這意味著α之間的具體數量，但不包括0和1。因此，它是一個小數以上0.00但低于1.00，其形成什么黑森說是過濾器參數或“平滑因子”。
黑森繼續指出，此遞歸的擴展產生以下公式：
哪里
是有效權重 w ^ 我施加到先前的測量? K-1個。
實際上，這允許將權重分配給特定的測量，然后將其“針對參數 α的幾個可能值”繪制出來，以最佳地可靠地估計帶寬。
黑塞寫道：“ 平滑因子α的值會影響帶寬估計值對過去測量的依賴程度。” “如果α接近0，則濾波器變為全通，它只會忽略所有過去的測量。”
但是，如果 α增加，則對最新測量的依賴將減少，而對先前測量的依賴將增加。為什么會這樣呢？Hesse指出，客戶端緩沖區可能能夠吸收帶寬的某些間歇性，而不需要切換到不同的ABR段帶寬速率。
他寫道：“另一方面，如果傳輸速率測量結果表明信道帶寬發生永久性變化，我們還希望濾波器足夠快速地做出反應。這對于允許量化單元切換速率（例如避免緩沖）非常重要。 -欠載……情況。”
如果我們（某種程度上）忽略帶寬怎么辦？
黑塞在其dispar.at博客中提到的第二種處理重新緩沖的方法是一種可能更好的方法，該方法是使用Lyapunov優化技術，通過基于緩沖占用率的算法來“最小化重新緩沖并最大化視頻質量”。寶拉 這種方法不測量帶寬，而是根據在任何給定點填充最終用戶視頻播放器緩沖區的分段的百分比來推斷帶寬可用性。
BOLA在2016年的一篇論文中被介紹由Kevin Spiteri（馬薩諸塞大學-阿默斯特大學），Rahul Urgaonkar（亞馬遜）和Ramesh K. Sitaraman（Akamai）撰寫。他們認為，具有臨時算法的現代視頻播放器了解甚少，因此在決定下一個HTTP傳遞的段的帶寬速率時，沒有得到適當的利用。他們寫道，“ [We]制定了比特率自適應，這是一個效用最大化問題，其中包含了QoE的兩個關鍵要素：用戶體驗到的視頻的平均比特率和重新緩沖事件的持續時間。”
此外，他們引用Sitaraman在2013年所做的有關網絡性能及其對觀看者影響的研究，他們說：“我們考慮了影響 用戶總體QoE 的兩個主要性能指標。” 第一個是“時間平均播放質量，它是用戶觀看的塊的比特率的函數”，第二個是不重新緩沖所花費的總觀看時間的一部分。
他們認為，BOLA是一種限制整個緩沖區避免持續消耗（欠載）或填充的方法。（請參見下面的圖2。）緩沖區的大小是有限的，可以用隊列中可以播放的塊或段的數量來度量。如果緩沖區已滿，播放器將等待請求下一個塊；但是，如果可用帶寬下降到請求之間的間隔，則請求的塊（數據速率較高）下載時間可能更長。這可能會級聯成緩沖區欠載情況。作者認為這種重復循環（由于緩沖區已滿而導致欠載或下載暫停）是通常（但并非總是）由可用帶寬波動引起的振蕩。
圖2
但是，以免我們假設當觀看者以恒定比特率消費內容時不會發生帶寬選擇更改，BOLA的作者指出了一個問題，該問題早在 Burst Technologies時就令人困惑，并且 在windows Media中有些不適播放器9：穩定帶寬緩沖選擇。他們寫道：“擁有穩定的網絡帶寬和寬廣的閾值仍然無法避免所有比特率的切換。”
以觀看者為例，該觀眾具有恒定的2Mbps帶寬和兩個節目的ABR再現，一個為1.5Mbps，另一個為3Mbps，當緩沖區填滿時，播放器的性能實際上可能是有害的：“播放器下載時緩沖區達到1.5Mbps時，緩沖區會繼續增長。當緩沖區超過閾值時，播放器將切換到3Mbps，耗盡緩沖區。緩沖區被充分耗盡后，播放器將切換回1.5Mbps，并重復該循環。
如果最終觀看者想要保持恒定的質量，則可以有兩種選擇：以較低質量的1.5Mbps再現觀看整個節目，或者采用舊的Burst Technologies技巧，并以比用戶更高的帶寬觀看整個節目。可供他或她使用。BOLA的作者稱此選擇為“以更大的 振蕩成本來最大化效用并以3Mbps的更高比特率播放視頻的一部分”，但提供了針對振蕩（BOLA-O）或效用（BOLA）的解決方案。 -U）。有關BOLA算法如何響應緩沖區級別的說明，請參見圖3。
圖3
該算法的最后一部分通過引入比特率上限來實現BOLA算法在可用內容比特率之間進行切換時在較高或較低振蕩之間進行選擇的能力。我問Spiteri，將比特率上限描述為將MPD或清單文件中的再現選擇限制為比特率低于視頻播放器設備當前可用帶寬的再現形式是否準確。他確認 這是一個準確的描述，而不是某些人試圖將比特率上限錯誤地等同于Net Neutrality第三軌術語“帶寬限制”的描述。
BOLA作者寫道：“ BOLA-O通過將較高的比特率與下載前一個塊時測得的帶寬進行比較，驗證了較高的比特率是可持續的。” “由于動機是為了限制振蕩而不是預測未來的帶寬，因此這種調整不會將比特率降低到比上一次下載時更低的水平”，以此來限制緩沖區的增長，就像降低緩沖區的大小一樣。 Mbps格式下載。
第二種選擇是使用BOLA故意選擇一個高于持續帶寬的內容比特率，而BOLA-U遵循的原則是不要過多地填充緩沖區。作者寫道：“通過將比特率提高到比可持續帶寬高一個水平，可以避免緩沖區的過度增長。” “使用較小的緩沖區大小并增加BOOL-U的穩定性會得到回報，并且BOLA-U的效用要大于BOLA-FINITE。…實際上，丟失的效用受到編碼比特率之間的距離的限制；如果下一個，較低的比特率水平離網絡帶寬不遠，那么實用程序將丟失。”
Spiteri向我詳細說明了這一點。他說：“ BOLA-U偶爾會使用比設備帶寬更高的比特率，從而獲得更高的平均比特率。” “當然 必須是偶然的；始終以較高的比特率下載會導致重新緩沖。BOLA-U僅在緩沖區級別足夠高時才以如此高的比特率進行下載，因此不存在重新緩沖的風險。”
Spiteri還表示，有經驗證據表明，當內容以更高的比特率和分辨率呈現時，用戶會保持參與，并引用了ACM SIGCOMM 2011上發表的論文“了解視頻質量對用戶參與的影響”。
因此，實際上，編碼比特率之間的距離是否會引起實際問題？2020年1月的論文《了解野外的視頻流算法》Melissa Licciardello，MaximilianGrüner和Ankit Singla撰寫的文章似乎表明，在使用更多可用帶寬以提高最終用戶觀看質量方面，還有改進的余地。它可以衡量各種在線平臺上播放器對ABR視頻流算法的實際使用情況。
作者說：“我們……發現證據表明，大多數部署的算法都針對穩定的行為進行了調整，而不是針對帶寬變化的快速適應；有些算法針對了視覺感知指標，而不是基于比特率的指標進行了調整，其中許多算法出乎意料地 大量使用。未使用的可用帶寬。” 作者沒有解決BOLA最大效用方法帶來穩定性的有意識選擇，但他們指出了另外一個難題：視覺感知指標。
在某些方面，這可能是語義上的區別。例如，BOLA的作者討論了“經驗證據，當視頻以更高的比特率呈現時，用戶會更加投入并觀看更長的時間”，但是討論圍繞的是標準清晰度和高清內容之間的差異，因此與內容以更高帶寬呈現的事實相比，參與的可能性更大。
然而，使用視覺感知指標來調整播放可能會充滿危險， 尤其是在早期的指標（例如峰值信噪比（PSNR））方面，這是臭名昭著的例子，如果PSNR為唯一因素。（請參閱 這些 燈塔并排圖片 一個很好的視覺例子。）
下一步是什么？
在調整播放器性能方面還有更多的算法工作要做嗎？是。
Licciardello，Grüner和Singla最近撰寫了“重構專有視頻流算法”，該論文詳細介紹了他們對包括BOLA在內的許多專有調度算法進行反向工程的研究嘗試。他們計劃在7月的2020 USENIX年度技術會議上介紹它。
并不是說BOLA算法是靜止不動的。實際上，在2019年，BOLA原始論文的兩位作者（Spiteri和Sitaraman）以及他們在論文中感謝的同事Daniel Sparacio發表了“ 從理論到實踐：在DASH參考文獻中提高比特率適應性”播放器”，這是基于以下事實的研究論文：許多針對ABR內容的播放器調度算法通常分為兩類 ：基于吞吐量和基于緩沖區。他們認為，一種更好的模型是使用“吞吐量預測和嘗試利用兩者的優勢。”
為了幫助推動混合方法的發展，三位作者對BOLA算法進行了更新，以包含一個稱為BOLA-E的增強版本。該版本引入了一些概念，例如不包含視頻數據且可用于更改緩沖區級別的“虛擬段”，以及“占位符算法”以更好地允許BOLA做出明智的比特率切換決策。更重要的是，BOLA現在已經實現到Video.js中，該視頻是DASH行業論壇（DASH-IF）倡導的參考視頻播放器。
此外，作者開發的一種稱為快速切換的新算法已在DASH-IF參考播放器中實現。快速切換的概念非常新穎： 如果帶寬突然提高，并且有時間用這些更高質量的片段重新填充緩沖區，則可以通過“用較高位的片段替換客戶端緩沖區中的較低位的片段”來提高視頻質量。這有可能提高低延遲的吞吐量，同時又不會迫使觀看者在整個 內容觀看體驗中忍受不確定的較低質量的體驗。
最后，斯皮提里告訴我，2016年BOLA論文的更新版本已經 發布，該論文討論了理論部分的更多詳細信息，并將BOLA與許多其他算法進行了比較。它還包括符號的更改。Spiteri說：“雖然原始版本使用比特率m = 1表示最高比特率，但是新版本使用比特率m = 1表示最低比特率，”他補充說，這種轉變“主要與dash.js播放器一致，其中較低的比特率具有較低的索引。”
結論
隨著2020年上半年流媒體的激增，包括鎖定期間在家觀看點播內容以及越來越多地使用低延遲，多參與者網絡會議軟件，對播放器性能優化的需求從未如此迫切。幸運的是，當本文試圖用基本的術語進行解釋時，播放器性能魔力的背后的數學繼續建立在基本算法上，同時正在展示和調整新穎和增強的版本，以提供越來越好的最終用戶觀看體驗。
