TGFC Lifestyle - Powered by Discuz! Board

标题: [新闻] ＭＳ串流游戏新武器，可节省５/６传输流量 [打印本页]

作者: cangying 时间: 2015-5-31 14:16 标题: ＭＳ串流游戏新武器，可节省５/６传输流量

正當許多遊戲廠商紛紛開始提供遊戲串流服務之際，Microsoft陣營在市場上並沒有太多動作，不過它們卻以技術進行反擊。不同於一般技術純粹將所有遊戲畫面透過影片串流方式傳送至終端裝置，Microsoft Kahawai技術能夠將部份畫面於終端裝置繪製，讓傳輸流量只需原本的1/6。

串流遊戲讓終端裝置突破極限

目前已經有多間廠商提供串流遊戲服務，其中比較知名的就是Sony的PlayStation Now與NVIDIA的Grid等服務，這類服務的原理是將遊戲程式放在雲端伺服器運算，將遊戲畫面「直播」至如PlayStation 4主機、Shield Tablet平板電腦等終端設備，並接受終端設備回傳的指令輸入讓玩家操作遊戲。這種服務最大的好處是玩家不必在終端設備安裝遊戲程式，而且遊戲畫質表現不受終端設備效能限制，舉個例子來說，能在平板電腦上玩到能夠媲美電腦版大作的頂級畫質遊戲。

Kahawai的目的是要讓如智慧型手機、平板電腦等行動裝置能享受高畫質串流服務，該技術由Microsoft與杜克大學（Duke University）、華盛頓大學（University of Washington）成員組成的研究團隊共同研發。Kahawai這個字來自夏威夷語，相當於英文的Stream，有流動、串流的意思。

Kahawai最大的特色，就是遊戲畫面會交由雲端伺服器與終端設備協同運算，這樣的好處是能夠在提供同等畫質表現的情況下，節省資料傳輸流量，如此一來就能提升串流遊戲的流暢度，或是降低行動通訊所占用的流量與傳輸費用。另一方面，支援Kahawai技術的遊戲也能離線執行，也就是說當玩家沒有連線到網路時，還是可以遊玩遊戲，只不過畫質會有所降低，相較之下傳統串流遊戲則是完全無法在離現環境執行。

▲串流遊戲是由雲端伺服器負責遊戲的運算工作。

▲PlayStation Now主要的服務內容為讓玩家在PlayStation 4執行PlayStation 3遊戲。

▲Grid的特色則是能在行動裝置上執行AAA級大作遊戲

協同運算降低傳輸需求

Kahawai在實作上使用2種不同的技術進行雲端與終端的協同運算，第一種是由終端裝置繪製每一幀低畫質遊戲畫面，雲端伺服器繪製高畫質部分，最後將兩邊的畫面合成顯示。舉個例子來說，如果要繪製森林的話，就把石頭、樹幹等構造較簡單的物件交由終端裝置負責，樹葉、草等複雜物件則交由雲端伺服器負責。

第二種方式則是由終端裝置繪製部份完整遊戲畫格，雲端伺服器繪製其他畫格。舉例來說，如果有款遊戲每秒顯示60幀畫格，其中10幀交由終端裝置負責，另外的50幀就交由雲端伺服器負責。上述這2種方式由雲端伺服器繪製的遊戲畫面，都會以H.264編碼壓縮並傳輸至終端裝置，由於絕大部份的行動裝置都支援H.264硬體解碼，所以效能不是問題。

目前研發團隊使用開源遊戲引擎idTech 4來進行Kahawai的技術試作，根據試作結果，Kahawai技術可在提供可接受的FPS（文件中沒有明講，但筆者推測為每秒30幀），與比單純使用終端裝置繪圖更高畫質的前提下，只需使用傳統串遊戲技術1/6的傳輸頻寬，就能維持相同的使用者體驗。

就目前的開發進度來看，Kahawai可能還需要一段不短的時間才能投入實際運作，而且這種方式會加重終端裝置運算的負擔，也就是說進行串流遊戲時將耗費更多電源，對於行動裝置來說將會成為另一個困擾。

想要進一步瞭解Kahawai的讀者，也可以參考Kahawai: High-Quality Mobile Gaming Using GPU Offload這份文件。

▲上述第一種方式會由終端裝置繪製低畫質遊戲畫面，雲端伺服器繪製高畫質遊戲畫面，並將高畫質畫面減去低畫質畫面成為差異畫面（即圖中Delta）。此時只需透過網路將差異畫面傳輸至終端裝置，並於顯示時與低畫質畫面合成即可。

▲第二種方式則是終端裝置只繪製部分遊戲畫格（影片編碼中的I Frame），雲端伺服器繪製所有遊戲畫面，並只傳輸中間空缺的畫格（影片編碼中的P Frame）。由於P Frame只記錄影片中有變動的部分，所以容量比I Frame小很多，因此可以節結省不少傳輸流量。

作者: mting 时间: 2015-5-31 15:14

posted by wap, platform: Android
请不要再催牛b啦

作者: 你老闆 时间: 2015-5-31 15:19

引用:

原帖由 mting 于 2015-5-31 15:14 发表
posted by wap, platform: Android
请不要再催牛b啦

這是微軟研究院的project之一而已

作者: madrista7 时间: 2015-5-31 15:23

posted by wap, platform: Lenovo
这两种方式都是云端运算一大部分，本机运算一小部分，很类似之前xone说的云计算……
这种对网络稳定性要求得是超高吧……

作者: tdkgtmb 时间: 2015-5-31 15:28

posted by wap, platform: nubia Z7 Mini
这技术只对带宽低延迟极其低的用户有效，问题是哪里去找这样的用户

作者: cc0128 时间: 2015-5-31 15:35

posted by wap, platform: Android

引用:

原帖由 @tdkgtmb 于 2015-5-31 15:28 发表
这技术只对带宽低延迟极其低的用户有效，问题是哪里去找这样的用户

至少把宽带要求降低了。。。

作者: 倍舒爽 时间: 2015-5-31 15:38

posted by wap, platform: 小米 4
云游戏是未来，不断有新尝试十分好…

作者: tdkgtmb 时间: 2015-5-31 15:53

posted by wap, platform: nubia Z7 Mini

引用:

原帖由 @cc0128 于 2015-5-31 15:35 发表
至少把宽带要求降低了。。。

对本地设备和延迟要求更高了，并不符合发展趋势，感觉完全没有实用领域

作者: himura 时间: 2015-5-31 19:00

posted by wap, platform: BlackBerry
那么X1的鸡能可以咸鱼大翻身了？

作者: 伪 时间: 2015-5-31 19:08

如果躺在床上可以用苏菲4玩PS4的游戏就好了。

作者: sceic 时间: 2015-5-31 20:25

posted by wap, platform: GOOGLE Nexus 5
这不就是当年ps上ff7一边放cg一边控制人物在cg里面移动的补完版？现在改成主机运算人物，云负责放cg，完全一个道理....

作者: u571 时间: 2015-5-31 20:42

想法很好，但是实际上做起来软件和网络开发成本会很高，应用也很复杂，很难说软件厂商会有多大兴趣。

此外PlayStation Now和Grid的1080P高画质带宽所需是40M，看起来貌似是一个很大的数字，其实过2年以后无论在北美还是在天朝这种等级带宽根本就不是问题。而且宽带运营商也会很欢迎这种下行大上行小的大带宽商业应用，so Kahawai这种技术能有什么前途真的很难说。

作者: veryend 时间: 2015-5-31 22:05

引用:

原帖由 u571 于 2015-5-31 20:42 发表
想法很好，但是实际上做起来软件和网络开发成本会很高，应用也很复杂，很难说软件厂商会有多大兴趣。

此外PlayStation Now和Grid的1080P高画质带宽所需是40M，看起来貌似是一个很大的数字，其实过2年以后无论在北 ...

1G带宽在TG再怎么也要8W一月，姑且不论40M是大B还是小B，我们先按小B算，1G带宽只能支持25人同时在线，假设一个游戏的售出价格是300元，平均游戏时间是30H，那么一个月1G带宽最大能支撑的游戏人数是600人，那么一条带宽满打满算产生的效益就是18W月，如果算上夜间和上班时间的空闲时间，估计这数字得打个对折，游戏相对来说还是很吃机能的，所以后面填的服务器不会少，算上服务器网络设备折旧，机房租赁，维护人员工资……
我觉得，至少得赔10年本

作者: 爱你一棒陲 时间: 2015-5-31 22:54

微软亚洲研究院的项目多数是前沿科技，不要随便脑补给游戏部门

作者: himura 时间: 2015-5-31 23:03

引用:

原帖由 u571 于 2015-5-31 20:42 发表
想法很好，但是实际上做起来软件和网络开发成本会很高，应用也很复杂，很难说软件厂商会有多大兴趣。

此外PlayStation Now和Grid的1080P高画质带宽所需是40M，看起来貌似是一个很大的数字，其实过2年以后无论在北 ...

美加澳宽带多限每月的流量.
有些不限上传, 但下载必定限制
超额则按G罚款.
少的流量有几十G一个月, 多的1,2,3百G一个月. 无限的流量套餐很贵.
玩个游戏分分钟破产.

像中国这样只讲带宽(速度)不讲总流量的, 不多见的.
但由于是中华局域网, 所以也算合理吧.

作者: DarthVadar 时间: 2015-6-1 14:51

posted by wap, platform: iPhone
然并卵

欢迎光临 TGFC Lifestyle (http://bbs.tgfcer.com/)