技術沙龍|京東雲端到端多媒體關鍵技術揭秘

編者按：從帶來更高編碼效率、更好的使用者體驗的京享高畫質，到直播架構與網路演進最佳化，從而為使用者帶來更流暢的觀看體驗，以及運維繫統的異常自動修復和高彈性的多媒體儲存架構，一層一層展示出複雜而有序的多媒體技術框架。本文是對在LiveVideoStackCon 2019北京的京東雲技術專場的內容回顧。

AI和5G分別正在和即將改變著多媒體技術生態，當然這會給使用者帶來更好的甚至是全新的體驗。8月23日，在LiveVideoStackCon 2019北京的京東雲技術專場上，四名來自京東雲的技術專家分享了京東雲在多媒體技術的積累與技術突破，以及對未來5G+AI時代的展望。

01 複雜網路下底層編碼技術最佳化提升使用者體驗

張樹軍 京東雲架構師

複雜網路條件下如何為使用者帶來更優質的影片觀看體驗，這個問題一直是音影片技術領域中的關鍵和難點。對此京東雲從4個方面著手提升使用者體驗：從底層影片編碼，“京享超清”技術提供了高質量、低成本的影片轉碼效果；針對複雜網路，端到端多位元速率切換技術保障直播、點播影片做到無卡頓、無黑屏；舒適音訊讓使用者在多場景頻繁切換中保持平和的聽覺過渡，提升整體觀看體驗；並從檔案預處理做好質量檢測，減少無效轉碼，提前預知影片缺陷。

“京享超清”

張樹軍認為在當下影片清晰度不斷提升和網路複雜度導致的卡頓、丟包的情況下，如何做到保證相同觀看質量的同時儘量降低位元速率是音影片技術發展的趨勢和關鍵。針對於高質量、低成本的影片轉碼，京東雲在5個方面做了技術最佳化：影像和影片級的去噪、銳化，針對低位元速率影片的插幀處理，針對使用者感興趣區域的畫質增強，分類場景的編碼最佳化以及與AI結合的影片編解碼處理。

特別一提的是，通用的去噪都是針對於影像級和空域級，是在YUV和RGB上做處理，其實這種處理是對所有塊都適用的，然而影片是有塊屬性和運動屬性的，因此京東雲對指定的幀型別或宏塊型別的區域，結合現有的單通、雙通、DCT等去噪演算法做最佳化，實現對某一幀或宏塊型別的自適應去噪。除此以外，京東雲還結合AI技術，識別、分析影片場景和使用者感興趣區域，針對不同場景和區域採取不同的編碼和位元速率控制策略，達到在同等質量和觀看體驗的前提下，為使用者和客戶降低頻寬成本。

多位元速率切換

面對國內使用者複雜的觀看網路條件和裝置多樣化，尤其是使用者在不同網路間切換出現的網路抖動情況，很難採用統一的轉碼策略滿足所有使用者的觀看體驗需求。張樹軍表示京東雲目前採用端到端的多位元速率切換技術來解決這一痛點，包括點播和直播場景的多位元速率切換對齊。

常規的多位元速率切換對齊方式主要有Segment、GOP和幀級三種：Segment相對而言是最簡單的IDR對齊方式，在客戶端和Server端的處理最為方便，但同時也是切換速度最慢的；相對於Segment，GOP則可以做到更精細，切換速度也更快，但由於GOP固定，有人為因素干預編碼，從而導致最終質量下降；幀級切換鑑於是逐幀編碼，切換速度最快，但同時對使用者終端和網路要求也會更高。因此京東雲針對點播和直播場景做了最佳化。

對於點播一般會做2-pass編碼，第一pass資料會給第二pass資料做參考使用，而如果做多檔轉碼輸出——透過一檔的mbtree資料指導其他檔2-pass轉碼輸出實現各檔次幀型別和時間戳對齊，但由於是基於參考檔1-pass指導2-pass轉碼輸出，因此實際輸出質量並不高。京東雲在此基礎上，增加了下圖紫色模組（特定YUV）保證lookahead輸出的每一幀資料在多檔輸出統一、一致。

對於直播場景可以借鑑點播的邏輯，但由於不同使用者的拉流時間點不同，因此只能在場景切換後的多檔直播流做到對齊，不過針對某些場景切換特別長的情況，相應對齊部分也被拉長，直接影響了使用者觀看體驗。京東雲在直播對齊中引入了一些同步機制，在拉流過程中將同步資訊加入到流中，這一操作並不會對轉碼效果產生影響，但收到同步資訊的每條轉碼流可以在一個時間點插入I幀對齊，在體驗和功能滿足性上得到提升。

舒適音訊

我們經常可以在體育賽事或者演唱會中遇到一種情況：多個不同環境下的場景頻繁切換導致音量忽高忽低，對於使用者的聽覺體驗造成極大影響。針對這種情況，單項增益和常規均衡化會導致原聲失真、低音效果差和失去原本聲音高低效果。京東雲對於多場景切換的音訊，首先會做音訊的整體分析，並根據自定義的舒適區判斷音訊是否需要動態調整使其達到較好的收聽體驗。

02 以儲存為中心提升高效能、高可用、低成本直播服務

崔燦 京東雲架構師

伴隨影片畫質和需求的不斷提升，影片容量、數量的增多以及容量和頻寬的彈性擴充套件成為影片雲服務廠商面臨的一大挑戰。與此同時，使用者對於高畫質、高流暢、無卡頓的觀看需求的提升，也對低延時線上上傳以及高吞吐的離線處理效能提出了更高要求，而由此帶來的資料成本與資料安全問題也不容忽視。

海量影片儲存系統

針對上面提到的挑戰，京東雲是如何做到百P級別儲存服務的？對於一個經典模型——一箇中央節點組成大目錄樹，下面是很多資料節點儲存資料，類似於HDFS，實際上這個架構就可以滿足影片儲存的基本需求——影片上傳、下載，但是在所承載的檔案數量和容量上仍是無法滿足，同時這種樹形結構在磁碟訪問、擴充套件性和中央節點管理磁碟能力上的表現並不好。

因此，京東雲構建了一套基於KV結構的影片儲存系統，對NameNode從功能上做簡化，將目錄拉平——每一個檔名對應檔案資料位置，用Meta Service管理檔名到檔案資料位置的對映，由此可以看作為一個有效陣列儲存在多個叢集中，後設資料透過Meta調取不同叢集中的資料，這種結構也更易於擴充套件。而在Data Service中，每個叢集中的每個資料都對應唯一的ID（這個ID儲存在後設資料中），相當於一個flv檔案對映為不同叢集中對應ID的資料。這種多後端叢集儲存還具有一個優勢——針對不同型別的資料可以在不同後端進行儲存，比如類似m3u8這種需要頻繁訪問的檔案可以放在SSD叢集，ts檔案可以放在標準儲存叢集，影片的冷備份可以放在EC叢集，轉碼的中間檔案可以放到RRS叢集。

以儲存為中心的處理框架

對於一個影片，儲存是基礎，處理是目的，在京東雲的資料處理框架中分為同步處理和非同步處理。同步處理——在資料下載時同步做處理，相當於用計算資源換儲存資源，它適用於一些圖片水印、剪裁等場景，京東雲同步處理框架提供了根據請求引數排程後端服務，以及同時支援傳資料和傳連結兩種方式的資料處理服務能力。對於非同步處理——基於存在資料離線做處理，整個非同步處理框架我們是透過多個訊息佇列實現的——即時處理和不同時間的延時處理訊息佇列，由此我們可以保證至少一次的鑑黃呼叫以及後端服務繁忙時指數退避。

基於公有云的點播服務

對於點播或者直播服務，高吞吐、低延時的效能、高可用性以及成本最佳化成為了關鍵。京東雲基於公有云的點播服務中，使用者從雲主機（業務系統）請求上傳連結，這個上傳連結對應儲存連結，使用者直接透過客戶端上傳資料到物件儲存服務，再透過非同步處理機制觸發業務邏輯（如轉碼、鑑黃），處理完成後上傳到物件儲存服務透過非同步處理機制觸發自有業務系統（如媒資管理等），最後生成連結透過CDN分發。

03 多核心協同拓撲CDN分發網路架構演進

劉軍濤 京東雲架構師

影片直播不同於傳統的點播和網頁加速，它對延遲和卡頓更加敏感，並且具有極其明顯的流量突發特點而國內網路接入的又十分複雜，除了三大運營商，還要對小運營商、教育網等做CDN最佳化。下面將著重針對CDN網路架構實踐、演進與效能調優方面進行講解。

CDN網路架構演進

對於一個直播雲架構而言，核心訴求集中在高可用、易擴充套件、高效能三方面，在這一背景下，我們首先需要挖掘單機或單節點的效能潛力。京東雲會將每個節點抽象為虛擬的兩層，在節點內部的邊緣上透過輪詢的方式將流量打散接入，如果出現突發流量可以充分利用每個機器的能力，在流量打散後內部透過雜湊匯聚到內部邏輯的二級源，再由二級源做真正的回源。當有多路流時可以合併回源，減小回源頻寬，同時有效減少它們內部的互動成本。

在充分挖掘單機及單節點潛力的基礎上，我們進行CDN組網。在最初的單核心拓撲架構實踐中，我們發現存在兩個問題：首先是無法動態選路，其次核心叢集只有華北地區一個，存在明顯的單點問題。因此在這個基礎上我們設立了南方核心叢集形成雙核心協同架構，南北方核心叢集透過專線連線，由此也同時實現了異地災備，提升了整體可用性。但這套架構存在同樣的問題，也就是線路選擇仍舊依靠運維經驗手工配置，響應速度無法很好滿足。

伴隨京東雲核心叢集和邊緣節點的不斷建設擴充，京東雲透過流控中心實時探測網路情況，對回源線路進行統一排程，實現二級源之間回源、二級源和其他核心叢集回源等多種動態排程備線方案。當其中一個節點出現網路抖動或故障時，其他節點可以即時從備選線路回源。至此，各層級集 群 發展為“節點池”的概念，也就是不再依賴人工運維狀態下的以地域劃分叢集，而是形成核心叢集池、二級邊緣池和一級邊緣池，分發回源和推流回源透過流控中心實時探測生成最優線路及多條備線。特別一提的是，普通CDN是透過IDC到IDC進行網路質量探測，而京東雲基於京東商城配送站資源，將其模擬為一個端探測CDN邊緣節點質量，提升邊緣節點到使用者的最後一公里質量。

直播分發服務效能調優

我們知道直播雲質量評價核心指標包括首開時間、卡頓率、內容延遲和可用性，上面所講架構演進更多是圍繞可用性提升展開，京東雲在首開時間和卡頓率方面也做了很多最佳化工作。首開時間的消耗主要在DNS解析、TCP建連、應用層握手及協商、資料傳送等幾方面。要加速首開，最簡單可以想到的就是透過主動預熱把流提前拉到邊緣節點：影片資料距離使用者越近首開時間一定就快。但對於直播長尾效應而言，預熱這種手段對CDN來說無疑具有非常巨大的成本壓力，常態服務時無法使用。長尾效應下存在大量的直播冷起播放，針對冷起情況下的首開最佳化就尤為重要。在內部互動（一級邊緣到核心叢集）中我們透過“去DNS依賴”和維護“長連線的TCP連線池”的方式消除DNS解析和TCP建連的時間消耗，而一級邊緣到使用者端可以透過在Client端進行“DNS預解析”節省DNS解析時間（這部分需要Client進行最佳化）。於此同時，針對應用層握手及協商過程，京東雲放棄了原生的RTMP協議（需要5-7個RTT），內部使用私有KTMP協議（playload相容RTMP），在1個RTT完成握手及協商，這樣極大的降低了握手及協商過程的互動開銷。

其實針對首開時間的最佳化很多可以同時降低直播卡頓率，比如TCP連線池在網路發生抖動需要重新選路時可以更快速建立連線。但當CDN網路抖動導致丟包嚴重時，TCP表現就會有很大問題。京東雲自妍了進行RTMP和QUIC協議轉換的Converter，部署於上行邊緣和下行邊緣：在上行邊緣我們將RTMP轉換為QUIC在內部傳輸，而當一級邊緣分發給使用者時再把QUIC轉回為RTMP或FLV，這樣，CDN節點之間網路丟包引起的卡頓將極大降低當然，網路更多的抖動、丟包是發生在最後一公里，這就需要Client協同做一些工作進行QUIC推流接入及播放接入，以期降低更多延遲。

04 大規模、高可用直播平臺架構：提升效能+降低成本

王孝慶 京東雲架構師

直播平臺是基於端到端的處理，京東雲是如何基於前面提到的底層高效能影片編解碼、大規模儲存、效能保障和CDN鏈路最佳化之上構建更友好的直播服務？下面將透過直播產品化高可用方案和效能提升詳細講解。

直播產品高可用方案

在推流質量和穩定性保障方面，京東雲在鏈路選擇、推流加速、多源站部署、穩流/預處理和多種推流模式5個方向最佳化，首先在推流鏈路選擇上提供應用更為廣泛的邊緣CDN節點和質量更高的源站直推兩種，邊緣收流後會透過CDN加速中轉到源站，並且透過多源站部署保證源站穩定性，同時提升推流效能，而穩流和預處理則更好的保證了生產系統和輸出流的穩定性，以及對不規範的流進行規範化處理和修復。

除了推流質量保障，如何透過技術手段保證系統生產過程的穩定性？從設計體系角度我們透過模組化、配置化和監控體系來完成直播流的穩定生產。目前京東雲採用微服務架構，每個模組獨立部署，高內聚低耦合，當某些模組出現故障時，內部會採取服務降級或熔斷機制，從而縮小故障帶來的影響範圍。在服務模組層，透過標準化+配置化設計滿足不同需求，比如轉碼位元速率、解析度等；在業務層也可以基於不同服務模組的能力進行封裝達到不同應用、不同場景的定製化。而一個穩定的系統離不開完備的監控體系，當出現問題時如何快速發現、快速定位、快速修復。對於直播平臺下的生產叢集使用任務的方式管理，我們把某一任務的輸入、處理過程和輸出採用配置引數，透過排程系統將這個任務下發給一臺機器進行生產，而生產的健康狀況可以透過這臺機器上報的資料進行實時監測、追蹤和修復。

降低資源成本，提升平臺效能

在底層技術最佳化基礎上，從平臺層角度，如何更充分利用資源，如何合理排程任務完成生產，讓整個系統吞吐更大、速度更快、利用率更高，同樣是“降低成本，提升效能”的重要一環。

下圖是資源排程系統架構，它包括對伺服器、節點、網路、排程等的管理，以及伺服器和資源利用率的監控，它實時監測內部執行狀態和使用情況，比如哪個節點出現問題、哪臺伺服器利用率比較低等等，當某一節點長時間利用率較高，我們就需要判斷是否需要擴容或排程策略需要調整，從而達到利用率最大化和排程均衡的平衡關係。

在排程中，不同任務消耗的資源重心也會不同，比如轉碼對CPU消耗較多，而另一種業務對頻寬消耗較多，因此我們抽象了一個load的概念，用它表示任務在機器上的綜合指標，我們透過演算法不斷最佳化load值從而提升整體資源利用率。而在排程過程中可能出現由於資訊延遲導致一個任務分配到一臺機器之後發現資源不夠的情況，這裡我們引入了超頻的概念，如果當前任務所需資源超出部分在這臺機器可承受範圍內（我們設定一個百分比的過載保護機制），則不需要再進行二次排程。

儘管針對“京東雲影片雲端到端產品技術實踐”的精彩技術分享已暫時告一段落，但關於音影片編解碼、海量資料儲存、高可用CDN網路架構等諸多問題依舊被火熱探討中，未來敬請關注京東雲開發者社群（ID：JDC_Developers），瞭解最新技術活動。

依託京東集團的業務實踐和技術沉澱，京東雲影片雲提供了端到端一體化服務，打通採、編、制、錄、存、管、播等環節，讓影片的生產和流轉更容易，透過積木化的方式各項能力自由組合，滿足客戶對於影片業務的不同場景和需求。

歡迎點選“ 京東雲 ”瞭解更多精彩內容