Google剛剛結束了年度開發人員活動的第一天Google I/O，該活動短暫涉及了背後的技術Google Stadia。在填補三天活動的一個小時的同時，在此期間，一些Google的一些高級員工登上了舞台，概述了該公司將如何減少可觀的水平的潛伏期，並建立強大的流媒體來使用本地遊戲PC 。
隨著Google邁向雲遊戲的重大步伐，每個人的嘴唇上的問題是這種體驗是否值得或直接與當地硬件可比。為了說服Devs，Stadia是即將到來的遊戲的地方，Google的兩位首席工程師Rob McCool和Guru Somadder以及項目經理Khaled Abdel Rahman以及該平台的技術基礎都詳細闡述了。
而且，由於流媒體平台在GDC的公告中，Google希望清除有關流潛伏期的一些感知概念，這些概念可能或可能不正確。最值得注意的是，數據中心在整個方程中增加了多少延遲。
Somadder說：“從數據中心，數據包要花費的時間少於大腦命令到達您的手指所需的時間。”
遊戲的未來？這是我們對Google Stadia的了解
但是，儘管Google很快指出，以光速傳播的數據本身並不是問題，但任何額外的時間轉移和處理數據包都為遊戲玩家的體驗增加了延遲。
根據Google的說法，遊戲流的成功都取決於編解碼器，編碼器和解碼器，能夠最大程度地減少延遲 - 同時無情地達到了質量和延遲之間的正確平衡。畢竟，遊戲玩家不需要接收數據，而是將其迅速傳輸回服務器以響應玩家的操作。
麥考爾說：“流媒體是用於遊戲流的目的的交付引擎。” “這是一個與遊戲一起運行的程序。它從客戶和Google的內容交付網絡中獲取信息，並就如何最大化質量最大化，同時保持潛伏期不可察覺，並做出實時決策。
“沒有一個優化來製定完美的雲遊戲流技術。它總是平衡一系列交易折扣。因此，如果您改進一件事，通常會以另一件事為代價。因此，解決方案不是一種優雅的算法，您可以用幾行希臘符號來描述，也許會從中獲得碩士學位論文，它看起來截然不同。”
數據必須經過許多步驟才能到達您的家，Google認為它需要更改該數據在網絡上中繼以對抗緩衝的固有方式。因此，它在瓶頸帶寬和往返傳播時間（或簡單的BBR）擁塞控制算法上採用了自己的遊戲優化扭曲。
這是Google自己的嬰兒，據報導，它與Google Stadia的需求“非常接近”。 BBR是一種算法，試圖在發生之前減少擁塞和數據包的損失，尤其是在最後一英里，通常被稱為“ Blufferbloat”。那時，最重要的數據堆棧的數據包太深了，堵塞緩衝區，最終導致了不必要的大規模排隊。僅排隊通常是遊戲流的死刑。
“因此，在接收方面，我們使用瑞典團隊提供的WEBRTC擴展名來禁用緩衝，並在到達時立即顯示。對於我們的應用，控制擁塞以保持緩衝至少至關重要。”
通過優化的BBR算法和逐幀反饋循環，Google可以避免與視頻流和Laggy Web流媒體服務相關的一些陷阱。
麥考爾繼續說：“控制器正在根據從接收器設備到達的每個數據包反饋信號不斷調整目標比特率。” “控制器使用各種過濾器，模型和其他工具，然後將它們合成為可用帶寬的模型，並為視頻編碼器選擇目標比特率。
“ Google經驗豐富的設計算法建模非常複雜的情況和代碼，並且與毫秒延遲進行大規模合作，使我們處於為玩家提供這種體驗的理想位置。我們在毫秒（有時是微秒的毫秒）上收看，並及時地進行了知情選擇，以保持潛伏期不可察覺，同時最大程度地提高質量。我們將許多不同的信號模型，反饋，主動學習，傳感器和緊密的反饋循環融合在一起，以產生精確的調整體驗。”
Google還堅持使用包括VP9和AV1在內的最新編解碼器的採用，希望這將改善整個遊戲流，借用網絡需求的減少和質量提高。
為了吸引更多的野生開發服務，Stadia還將實施一個對開發人員友好的“可玩性工具包”。這套API套件允許開發人員修改並跟踪編碼器，實時指標，設備信息和延遲跟踪逐幀。
儘管我們仍然對Google Stadia的業務模型有很多問題，但Google I/O Talk卻有所了解，介紹了Google打算如何利用其相當大的重量和全球Web主導地位，以滿足其為玩家的雲遊戲服務。
如果只有幾個小時的談話，也許我們會有更多的答案。而且我會確定遊戲PC硬件的未來是否真的在危險中。
