動機:
目前的視頻傳輸方法存在兩大缺陷:
- 沒有充分的利用客戶端的計算力:客戶端的計算力在逐年上升
- 當前視頻編碼能力受限制
很多視頻在較大的時間區域內存在較大的信息冗餘,而目前的視頻編碼只能減少小時間範圍(GOP)內的信息冗餘
目標:
提出一個新的視頻傳輸架構,以低分辨率視頻作爲傳輸,在客戶端通過DNN來提高視頻的分辨率以達到高分辨率的效果。
系統設計
服務端
當視頻上傳時,服務器爲其訓練content-aware DNNs,用於提升客戶端的視頻質量
客戶端
- 首先下載一個可用DNN文件列表(manifest list)
- 根據自身的計算力選擇一個合適的DNN(一個輕量級的客戶端處理器)
- 根據integrated adaptive bitrate (ABR) algorithm去下載相應DNN chunks和video chunks
- DNN chunks加載到DNN processor中
- video chunks加載到playback buffer中,準備播放
- 播放器同時將video chunks也放到DNN processor中去進行super-resolution,處理結束後放回playback buffer中替換原始video chunks
- 高分辨率的video被播放
對於DNN processor
- 將video chunks解碼成frames
- 對每一個frame應用super-resolution
- 重新編碼成video chunks
解碼,super-resolution,編碼 三個操作流水並行化處理,減少延遲
阿King說:1和3的編解碼過程是否可以通過調整架構去掉?
Content-aware DNN
NAS是基於MDSR的拓展
要求
- DNN必須滿足多分辨率輸入
- DNN的計算時間必須能夠滿足實時的要求
- 爲了滿足前兩條要求,DNN必須犧牲一些質量(layers和每個layer的通道數)來減少計算開銷,這需要我們均衡DNN的品質和計算開銷
MDSR的缺點
- MDSR通過一個簡單的網絡支持多分辨率輸入,並通過共享中間層來減少連接
- 不同的分辨率對MDSR的計算開銷影響非常大(高分辨率計算開銷大,對分辨率計算開銷小),爲了滿足高分辨率的實時要求,必須減小DNN的規模
- 由於MDSR共享中間層,在降低高分辨率的DNN規模時,同樣會影響低分辨率
提出
讓每個分辨率的DNN獨立開來
獨立開來的各網絡能夠滿足實時要求的最高配置如下表
參數爲(層數layors , 通道數channels , 連接權值大小footprints size)
阿King說:各高低分辨率對之間的映射是否有共同點?即是否存在權值共享?例如是否能在240p-1080p中間抽取一部分權值即可實現720p-1080p的映射?一對一對的訓練感覺好麻煩呀!!!
訓練
- 訓練數據:低分辨率-高分辨率 對(訓練DNN實際就是構造低分辨率到高分辨率的映射)
- 訓練目標:使得 DNN的輸入出 和 目標高分辨率 之間的差異最小化
- 爲了減少訓練開銷,使用微調(fine-tunning)策略
- 先訓練一個通用的DNN模型
- 再在通用DNN模型權值的基礎上爲每個video episode訓練Content-aware DNN模型
根據計算力適應性選擇DNN
服務端
提供四種DNN:Low,Medium,High,Ultra-high
客戶端
- 在提供的DNN文件列表中獲取四種DNN網絡信息(layors , channels)
- 根據DNN網絡信息以隨機權值初始化四種DNN
- 在四種初始化的DNN中選擇能夠滿足實時要求的最高品質的那個DNN
阿King說:當然不能把四種DNN都先下載下來,再計算最優,再選擇,這樣太慢了!!!
可擴展的DNN
服務端
- 完整的DNN較大,不可能全部下載下載後再去使用,可讓客戶端邊下邊播,已下載的DNN部分也可用於視頻的質量提升,隨着DNN的下載越來越完全,視頻的質量提升的也越來越高
- DNN的中間層由許多殘差塊(residual blocks)組成,每一個殘差塊都包含兩個卷積層,DNN計算運行的時候可以繞過連續的殘差塊
- 在訓練的時候:
- 我們以50%的概率訓練完整的DNN,另外50%的概率平均隨機選擇繞過路徑(Bypassing paths)來訓練DNN
- 計算DNN的輸出與目標高分辨率之間的error,通過反向重傳來更新權值
- 在傳輸的時候,將DNN分成許多塊(chunks)來傳輸,第一個DNN塊由基本層(base layers)組成,可接受多種分辨率的輸入
客戶端
- 下載第一個DNN塊(base layers)後,構造起DNN
- 隨着DNN塊的下載越來越完全,DNN的構造也越來越完全,視頻質量也越來越得到提升。
- DNN processor每個時間間隔(4s)會計算DNN的處理時間,計算滿足實時要求的最大可用DNN層數
ABR算法
作用
- 決定是取DNN chunk還是取video chunk
- DNN優先策略則會犧牲視頻流的質量
- 視頻流優先策略則會延遲DNN的下載
- 如果第一次決定是取視頻塊,則改爲取DNN塊
阿King說:尼瑪爲毛不一開始就規定先下載那個帶有base layor的DNN chunks,還要用算法取決定幹嘛?決定錯了還有修正回來???
採用A3C的增強學習框架RL
- 對於算法迭代次數,有針對來自環境的狀態做出相應的反應,隨後環境產生回報同時更新狀態爲
- 策略:定義一個函數,該函數計算對於狀態做出動作的概率。其中包含是下載DNN chunks還是下載video chunks?包含的內容如下表:(N=8)
- 目標:學習這個策略,使得未來的回報總和最大,其中表示回報係數,爲目標QoE的度量,定義如下
N是video chunks的數量
表示第N塊video chunk下載的比特率
表示第N塊video chunk下載後的rebuffering時間
表示rebuffering的懲罰
表示接受的比特率的質量 - 爲了表示在使用DNN後視頻質量的提升,我們定義一個來替代,即對每一個video
表示video chunk在下載DNN chunk 後的提升的質量
是平均結構相似性(average structural similarity),用來視頻的質量
將SSIM值由映射回視頻比特率了 - 訓練增強學習框架(RL framework)
- 兩個參數:actor和critic, actor表示策略,critic用於評估策略actor
- 使用策略梯度法(policy gradient method)去訓練actor和critic
例子
- player先下載一個manifest file
- DNN processor根據manifest file開始模擬四種DNN的開銷,並選擇一個可滿足實時要求的最優DNN;同時player持續下載video chunks,下載了video chunk1-7
- DNN processor做出決定後開始下載DNN chunk1,該chunk中爲DNN base layers
- video chunk1-5已經被播放,於是buffer中的chunk6-7使用已下載的部分DNN進行品質提升,效果爲DNN,此時爲24sec
- 隨後下載video chunk8-9和DNN chunk2
- 。。。
- 在32sec時達到DNN
- 在44sec時達到DNN
- 在52sec時達到DNN
- 在60sec時達到full DNN