摘要：
本文總結了發表在IBC2018上，由英國Streampunk Media Ltd.的R. I. Cartwright和美國Gilmer＆Associates Inc.的B. Gilmer撰寫的“The Infinite Capacity Media Machine”，介紹了全能媒體機(具有無限的計算-存儲-傳輸能力的理想媒體機器)的概念以及敏捷媒體藍圖計劃，並分析了當前系統的性能以及未來的工作方向。
雲計算的快節奏發展正在推動將應用於專業媒體制作的新型機器的發展。無服務、分佈式、集羣和GPU加速，雲適應架構的本質正在改變軟件和服務的模式和設計。是否有可能將現有媒體架構的高度順序性、線路定時架構轉變爲隨機、消息驅動和異步雲？從可擴展以實現個性化生產的平臺中出現了哪些可能的新創意？
如果我們在網絡，存儲和計算方面擁有無限的性能，媒體機將被如何構建？這種機器的設計和構建它的計劃以Agile Media Blueprint（敏捷媒體藍圖）的形式介紹，並呈現了在視頻數據的背景下，全能的理想概念相關的當前系統的性能測量和分析。
引言
在大數據和社交媒體等趨勢的推動下，信息技術的綜合應用正在迅速發展。根據首選模型（例如摩爾定律，Gilder定律），網絡、計算性能和存儲容量（帶寬和容量）每六個月到三年翻一番。同時，軟件開發和雲的趨勢正在重新組織計算資源的配置和訪問方式，超越單個計算機的邊界，以開發大規模並行圖形處理單元（GPU）和計算集羣。
正在根據IT趨勢規劃其未來技術平臺的媒體公司需要考慮部署時可用機器的潛在性能。IT技術的性能提升率是否超過了媒體質量的數據速率的增長速度，甚至超過了從SD到HD到4K到8K具有更高的幀速率和更高的色彩深度的趨勢？如果是這種情況，應考慮理想主義機器，其能夠處理所需的任何媒體數據，適用於任何給定的工作流程並且使用趨於零的時間，在此稱爲全能媒體機。
本文首先從媒體格式、網絡、計算和存儲方面描述全能媒體機。利用當今可用的技術，引入了敏捷媒體藍圖[1]——一種如何在今天建立這種機器的技術計劃。爲了測試從通用信息技術（IT）到理想機器的道路有多遠，我們使用商品網絡傳輸的媒體數據的一些測量，用GPU處理並由集羣內存緩存管理。然後分析理想工作和全能之間的差距，描述未來建立機器的工作並縮小差距。
全能媒體機
在本節中，將研究全能機器的各方面性能，包括視頻格式、視頻傳輸、處理和存儲方式。
格式考慮
本文主要關注關於無壓縮媒體格式的創建、處理和存儲，以完整質量信號替換基帶信號，而無需犧牲媒體質量以節省比特率。在許多當前的媒體工作流程中，壓縮具有克服傳輸瓶頸和存儲容量問題的優點。但同時，壓縮增加了延遲、複雜性及能源消耗。假設性能無限，本文主張無壓縮格式是更可取的。
此外，無壓縮格式在並行處理環境中具有顯著優勢。圖像很好地分成像素的子陣列，並且每個區域可以同時工作。將圖片分割成串行移動的連續線序列可能降低傳輸延遲。無壓縮方法可以省去打包、解包、數據複製和轉換過程，尤其是當整個處理流程中使用通用的無壓縮格式時。
也就是說，在實現全能媒體機的設計時，應該在增加業務價值的地方應用壓縮。例如，降低相對低價值材料的長期存儲成本。本文假設的是，如果可以在第一個事項中進行無壓縮工作，則可以應用成本函數來在稍後階段通過壓縮來優化工作流。
傳輸架構
想象媒體工作流程爲旅程，包括將一系列圖片從位置A移動到位置B。如何從A到B取決於交通類型：
- 像鐵路一樣，建造從A到B的軌道和運行列車，每個車廂都是圖片的一條線。任何時候只有一列火車可以在軌道上運行，需要時間表、信號和管理，以及彈性所需的備用容量。從A到B，鐵路網絡快速高效。但是，添加新位置需要大量計劃和成本。
- 像道路網絡一樣，A和B之間存在許多不同的路線，並且每一幀或幀的一部分攜帶於單獨的自動駕駛車輛中。通過衛星導航和實時交通報告，車輛各自找到自己的最佳路線，並且在沒有整體擁堵的情況下，圖片的各部分將全部及時到達。大多數地點都先發制人地連接到道路網絡，彈性通過冗餘路線和及時重新發送任何缺失的部分。
列車網絡相當於專用的點對點媒體架構，如SDI架構和使用託管網絡的IP等價架構，如SMPTEST2110。
道路網絡就像一個通用的計算機網絡，許多雲平臺的優化支持更像道路的互聯網架構。雖然鐵路提供快速、高效、可靠的交通方式，但公路網提供了高度的靈活性和個體選擇。
如果所有圖片都及時到達，傳輸方式是否重要？如果在自我優化道路網絡中，圖片不按時間表（例如實時狀況）運行導致內容提前到達怎麼辦？由於全能性，即高速且無擁堵，道路網絡的靈活性是一個重要的優點。通過局域網中的100Gbps無阻塞網絡，一幀高清視頻可以在不到2毫秒的時間內以線速傳輸，如果每幀或部分幀可以並行傳輸則更快。因此，本文假設自我優化傳輸比實時更快，甚至趨於瞬時，對大多數工作流程都是有益的。
計算服務
轉換媒體、應用圖形、縮放、混合、分析和過濾是生產過程中可以應用的一些操作。在數字生產環境中，每一項操作都需要計算服務。這些服務的一種方法是將它們分解爲可按需執行的可組合原子函數。對於全能的機器，假定每個函數執行時間爲零。
現代圖形處理單元（GPU）具有大規模並行處理能力，包含數百或數千個計算核心的許多臺式機和筆記本電腦可以將媒體處理任務分解爲執行每個階段所花費的時間趨於零的點。另一個替代方案是使用計算集羣和“函數即服務”（例如AWS Lambda），有趣的是可能會大規模擴展——轉碼整個電影即細分爲塊，且每個塊同時處理即可僅使用幾秒鐘完成。
存儲選擇
媒體存儲需要具有高性能，可靠性和可擴展性以滿足不斷增長的媒體數據量的需求。存儲通常是系統中的瓶頸，可選擇的視頻編解碼器是存儲帶寬/大小與持久性質量之間的平衡。憑藉無限的存儲容量和存儲帶寬，爲什麼不以最高質量存儲所有內容？或者甚至是任何可能的質量？是否媒體存儲只是以便再次需求，還是應用無限的計算能力來按需製作每種格式？
基於格式存儲媒體的選擇是可以利用機器學習來執行的操作。
集羣RAM緩存的應用解決了網站上的許多性能問題。RAM相對便宜，並且許多快速週轉媒體工作流程（例如新聞和體育製作），主要使用在過去24小時內創建的少量媒體剪輯。全能媒體計算機可以應用集羣RAM緩存來提供媒體池的高性能存儲，這可以通過長期存儲來補充，例如基於雲的對象存儲。
敏捷媒體藍圖
敏捷媒體藍圖（AMB）[1]將全能機器概念發展成技術計劃，媒體公司和供應商可以遵循這些技術計劃來構建能在和互聯網相同的平臺上運行的高度靈活和可擴展的系統。通過遵循該計劃，媒體公司能夠比使用傳統架構更有效地創建和貨幣化內容。AMB可以利用用於運行全球千兆系統（如Twitter）的所有硬件、軟件、網絡和相關組件。
敏捷媒體藍圖始於人、團隊、組織內和組織間。如圖1所示，它從這裏開始，不僅因爲人是我們技藝導向行業的關鍵組成部分，而且人們可以在一開始就解決安全問題。管理員可以爲人員分配角色，並根據業務需求，可以在組織中爲不同組織中的人員授予特定權限。例如，來自兩個遠程製作公司並使用兩個不同OB Vans的工作人員可以被賦予角色，允許他們協作進行一次性事項。此方法允許人們使用共享內容API進行安全協作，可以實現內容API互連相機、麥克風、揚聲器、多視圖和控制表面。
圖 1 人和各自的角色
雖然可以部署AMB以滿足專業媒體制作需求，但它也可以用於有效地生成需要與終端觀衆直接交互的新類型內容。如圖2所示，AMB通過廣播媒體、over-the-top流媒體（OTT）和移動設備來定位社交消費者。
圖 2 消費者與固定內容互動
傳統的廣播架構永遠無法向數萬（數百萬？）觀衆提供個性化內容——這是對廣播基本概念的“詛咒”。但是無論觀衆希望看到什麼，只要他們想，都意味着AMB架構的無縫擴展至關重要。在許多情況下，在個性化內容場景中，內容被緩存並作爲一次性事項流式傳輸給觀衆。許多廣播公司已經根據每個觀衆的成本按比例支付帶寬費用，而沒有受益於更緊密的雙向關係。
如圖3所示，AMB的核心是基於粒度的內容API，用於逐個元素訪問媒體，由最佳的雲適應技術支持，包括集羣RAM緩存、AI、對象存儲。微服務使新媒體元素按需訂購，不再需要通過創建媒體元素來浪費時間和資源“以防萬一”。
圖 3 常見的內容API提供了統一、開放的界面
AMB中的媒體傳輸在內容API之間，雙向鏈接並行運行，速度更快、更慢或與實時相當。如圖4所示，時間到字節的轉換接口（字節-時間組件）允許內容被讀取和寫入公用信號和文件格式，並且允許即時合成。
圖 4 字節轉換允許創建/消耗現有格式
文件和流的庫可以使用索引數據庫支持的字節-時間解包組件，即時或根據計劃遷移到AMB的實現中（參見圖5）。這允許媒體工廠輕鬆地從基於文件的架構遷移到基於API的架構。
圖 5 字節轉換和索引有助於創建公共媒體文件和流格式
衡量差距
理想主義全能機器與AMB提出的現有技術之間的差距是什麼？是否需要使用AMB技術處理媒體的時間趨於零？本節介紹在高速網絡、GPU和計算羣集上移動和處理視頻數據的一些初步測量。進行這些測量的主要目的是在行業中建立一個持續的過程，從而對機器的媒體能力進行常規基準測試，爲戰略和購買決策提供信息參考。
高速網絡
使用HTTP和HTTPS在網絡中移動高清視頻幀所需的速度測量是作爲測試雲適應的專業媒體的物聯網架構的一部分[2]。選擇該協議是因爲它可以使用商品互聯網技術進行擴展和保護。結果表明，在局域10Gbps網絡中，可以比實時更快地傳輸每幀視頻，同時通過TLS加密及通過TCP進行恢復。並行傳輸相同流的部分也是可能的，從而增加了最大吞吐量。
GPU並行處理
無壓縮的視頻幀是數百萬像素的陣列。現代PC連接到高分辨率屏幕（高清分辨率或更好），並用於視頻編輯、遊戲和設計等應用。爲了實現2D圖像和3D環境的實時渲染，現已開發了專用圖形處理芯片，其可以支持在數百個單獨的核上並行處理圖像的區域。最初，通過圖形處理語言（如OpenGL和DirectX）訪問這種專用加速器，2009年OpenCL語言[3]被髮布，以便於訪問GPU以執行以類C語言編程的一般處理任務。
對於無壓縮媒體的處理，GPU架構中的瓶頸一直是GPU專用隨機訪問存儲器（圖形RAM）。對於媒體制作任務，每個視頻幀必須從CPU RAM移動到GPU RAM、處理然後移回。複製媒體所花費的時間，以及在OpenCL出現之前將其轉換爲適合處理的格式，是資源密集且速度慢的。一旦在GPU上，就可以構建媒體處理流水線，其中每個階段在幾毫秒或更短的時間內運行。
2015年，英特爾推出了第9代圖形架構[4]以支持OpenCL語言的2.0版本。這包括一個稱爲共享虛擬內存（SVM）的工具，CPU和GPU可以在相同的內存區域上運行，一次鎖定一個塊（粗粒度）或協同工作——就好像GPU只是CPU的另一個核心（細粒度）。由於不必複製數據，這意味着可以在幾微秒內將一幀視頻傳送到CPU或從CPU傳送到GPU。當CPU和GPU位於同一處理器芯片上時，緩存存儲器也是共享的，這意味着GPU對存儲器的訪問不受PCI總線速度的限制。
圖6中的圖表顯示了將無壓縮的視頻幀移動到GPU，執行簡單操作並從GPU移回CPU的測量結果。結果比較使用數據複製（無）與使用三個不同GPU的SVM（精細/粗略）的模擬HD和4K有效負載的時間：
- 英特爾圖形HD520GPU與英特爾酷睿i7-6500CPU位於同一芯片。
- 英特爾圖形UHD630GPU與英特爾酷睿i3-8100CPU位於同一芯片（價格100英鎊）。
- nVidia Quadro M1000MGPU通過PCI連接到Intel Core i7-6700HQ CPU（細粒度SVM不支持，粗粒度SVM支持實驗）。
結果表明，低成本的共享存儲器架構可以加速媒體處理流水線，並且比實時更快地執行視頻圖像的複雜處理，即使對於以120幀/秒運行的無壓縮4K視頻也是如此。
圖 6 使用nodencl測量GPU媒體傳輸和處理速度
集羣鍵值緩存
爲了實現互聯網應用所需的規模和彈性水平，互聯網平臺的緩存層已得到增強，可以服務、管理和協調處理請求。通過將基於RAM的快速緩存與業務邏輯和用於擴展與彈性的集羣相結合，鍵值緩存（例如Memcached，Redis）承載了面向Internet的應用程序的大部分後端邏輯。這些緩存支持任意數據blob，那麼如果這些blob是媒體數據會發生什麼，例如視頻？
圖7中的圖表顯示了出入Redis集羣高速緩存的模擬HD和4K有效負載的讀寫時間的基本測試，每個操作都是串行和並行的。該緩存是AWS Elasticache服務中最小的緩存，它基於使用“最多10千兆位”網絡互連的r4.large實例。Node.JS在雲可用區域中與部分集羣並置，用作在另一個r4.large實例上運行的Redis集羣客戶端。對於高清媒體，幀出入集羣的速度快於或相當於實時（允許隔行掃描），顯示了這種集羣用於視頻處理的能力。對於4K無壓縮視頻，時序低於實時。未來的工作有很大的空間來探索更快、更大的集羣和優化的客戶端實現。
圖 7 使用redia測量模擬視頻有效負載的Redis集羣速度
存儲
作爲BBC研發雲計算項目的一部分，近期的工作採用了類似的方法來對媒體對象存儲進行基準測試[5]，結果顯示了無壓縮高清視頻的線性縮放。
分析
全能是一種理想主義的概念，即使有足夠的預算，雲數據中心的數萬臺計算機的性能也可能已經飽和。例如，爲使用無壓縮流的每一百萬觀衆提供一個獨特的4K流會使這樣一個數據中心的性能過載，甚至可能使媒體公司破產！然而這是一個極端的例子。對於要求較低的媒體工廠工作流程，通過創建在觀衆組之間共享的壓縮媒體片段來實現個性化，爲了複製現有工作流程，雲架構通過數百臺服務器的固定現場設備提供可用性能數量級的增加。換句話說，雖然不是真正的無限性能，但顯然全能可用於探索創新的可能性。本文介紹的全能媒體機的定義是能夠處理儘可能多的媒體，及工作流程需要的時間趨於零。持續的全能化工作基於多維改進：
- 機會靈活化：多租戶和按需擴展模型，以便工作流在需要時只租用所需的資源。
- 駕馭核心IT發展：IT技術發展包含了更高性能的雲產品、尖端的計算機科學和利用更快的硬件。
- 應用廣泛化：AMB的設計爲使用當今的集羣雲架構執行媒體工作流程提供了適當的框架。
- 軟件優化：開發利用多核系統和GPU加速的優化軟件，實現固有的可並行媒體處理。
上面提到的在適當的架構實例上運行的輕微優化軟件的測量顯示了無壓縮HD媒體的存儲、處理和傳輸時間優於實時，這意味着對於媒體工廠的跨維度操作處理時間趨於零。
是否應該調整雲架構以使其更接近現有內部架構，例如支持基於線路的時序，具有PTP時鐘並符合SMPTE2110-21的數據包間到達時間？理想情況下，是的，應創建一個可以從廣播車到雲架構使用的通用工具包。雲服務提供商的媒體公司對此項技術有需求並很快就會提供一些技術要點。然而，這種方法可能過度設計，因爲它將把順序SDI架構（例如，數據速率限於媒體實時，每個媒體元素的每個組成部分按順序處理）的設計選擇與其他異步雲計算機相結合，限制了計算集羣和/或流水線GPU處理的充分利用。可以說，遵循這條路徑——採用傳統架構的約束模型並將其轉移到雲端——將無法從增加性能的所有潛在維度中受益。
不應將傳統約束轉移到雲，而應採用與現代軟件開發實踐一致的方法。這從採用隱藏操作問題的技術開始，例如縮放、彈性和API背後的分佈式處理，然後在頂部添加媒體功能作爲包裝。這些API支持的技術體現在集羣或無服務器雲產品中，旨在提供易於部署、響應迅速的Web應用程序，可動態擴展到數百萬用戶。在降低項目風險的同時提供業務敏捷性，頂部的特定於媒體域的包裝可以採用AMB定義的可組合功能作爲微服務。
未來工作
AMB是一項技術計劃，需要通過規範、概念驗證活動、開發以及構建其組件的項目計劃進行開發。迄今爲止，AMB已作爲高級媒體工作流協會的討論文件出版，旨在促進從2018年秋季開始的討論。
開源物聯網框架動力學[2]的開發正在進行中，包括HTTP/S傳輸、媒體編碼和解碼、媒體轉型與合成、縮放和混合、媒體打包——不同的位模式和色彩空間翻譯、文件和流接口等等。目前這項工作的重點是通過內存高效的OpenCL[3]加速媒體處理來優化框架，從SD擴展到UHD/WCG內容。這些工具可通過軟件自動化進行部署，從RaspberryPi計算機、筆記本電腦、工作站擴展到GPU加速的雲服務器。該物聯網框架的模塊是AMB微服務的第一候選實現項目。
總結
將IT技術應用於專業媒體制作的戰略規劃可以從使用中的機器具有全能性、無處理和無傳輸延遲的角度出發。做出這樣的假設增加了新的通過雲計算規模和多維創新實現的創造機會，例如個性化生產。
不應試圖將當前的架構轉移到雲，系統可以設計爲儘可能接近理想主義的全能機器，敏捷媒體藍圖（AMB）則提供瞭如何實現這一目標的計劃。採用這種方法將實現利用計算集羣和無服務器架構的備選工作流程，並從敏捷性、高性能、並行和分佈式計算機技術中受益。基準測試速度和建模部署此類系統進行媒體處理的成本應該成爲所有媒體項目的持續活動。通過使用相同的架構並進行擴展以提供頂層（OTT）服務，並對如何提供媒體工作流程進行不同的思考，顯然可以使現有架構的媒體機性能大幅提升。
參考文獻
[1]. Cartwright, R. I. and Gilmer, B. 2018. Agile Media Blueprint – creating and monetizing content using the Internet technology platform. Discussion paper of the Advanced Media Workflow Association. Available:
https://www.amwa.tv/downloads/reference_documents/The_Agile_Media_Blueprint.pdf
[2]. Cartwright, R. I. 2018. An Internet of Things architecture for cloud-fit professional media workflow. SMPTE Motion Imaging Journal. June 2018.
[3]. The Khronos Group. 2009. The Open CL Specification. Version 1.0, rev 48 and subsequent versions. Khronos Group specification. Available: https://www.khronos.org/registry/OpenCL/ [4]. Junkins, S. 2015. The Compute Architecture of Intel Processor Graphics Gen9. Version 1.0. Intel whitepaper. Available:
https://software.intel.com/sites/default/files/managed/c5/9a/The-Compute-Architecture-ofIntel-Processor-Graphics-Gen9-v1d0.pdf
[5]. S. Nicholson, 2018. Beyond Streams and Files – Storing Frames in the Cloud. BBC R&D blog. Available:
https://www.bbc.co.uk/rd/blog/2018-03-cloud-video-productionstream-file-frame