從技術(shù)上看，一個完整的VR直播解決方案一般含有以下幾個板塊：采集端設(shè)備，上傳網(wǎng)絡(luò)，直播后臺，分發(fā)網(wǎng)絡(luò)，以及播放端。這些板塊可以說是環(huán)環(huán)相扣。

　　下圖是當初公司決定要做VR時，我一個月內(nèi)吧國內(nèi)做VR還叫得上號的廠商走了個遍。之后形成的一個框架概念。歡迎大家共同交流。

　　環(huán)節(jié)一：采集端

　　設(shè)備：

　　現(xiàn)在市面上的VR設(shè)備從幾百到幾千價位不等，質(zhì)量也是層次不齊。VR攝像頭本身制造的技術(shù)含量并不高，很多家就是拿了幾個魚眼攝像頭組成了VR設(shè)備?；蛘呤侵苯訉讉€Gopro拼在一起，這種類型的我們俗稱“狗籠”。

　　處理：

　　但是在攝像頭端完成的不止是采集內(nèi)容這一步而已。設(shè)備里面一般會配套搭載的軟件和算法才是重中之重（也有的是直接連在控制臺上完成的，那些一般就會需要人工參與，相對的，拼接等質(zhì)量也會比較好）。在VR直播中，所有的拼接都是直接即刻完成的，例如縫合、映射、美顏、編碼、特效（白平衡，曝光等）。而在設(shè)備內(nèi)部的縫合合成、映射的算法，目前絕大多數(shù)家用的也是開源的算法，只有極少數(shù)的團隊能做到自研。像facebook就將他的transform方案開源了部分代碼。

　　還有一個限制VR直播的問題在于碼流。因為VR視頻內(nèi)容在映射后，肉眼可視的分辨率會下降很多。所以對原始視頻的畫質(zhì)要求就比較高，一般都要求在4K，甚至有些家能達到8K。4K分辨率下，碼流接近20M。假如此處H.265能夠在采集端得到大范圍的推廣，可以大幅降低此處的帶寬壓力。但是H.265受限于專利費，目前看來大幅應用于采集端還有很長的路要走。

　　環(huán)節(jié)二：云端

　　CDN：

　　目前國內(nèi)傳統(tǒng)的 CDN廠商，網(wǎng)宿、藍汛，以及一些較大的云廠商：金山、阿里、騰訊（也有在自建CDN）都是大家可以選擇的平臺。其實后面的價格云廠商他們的CDN節(jié)點也并不是完全自建，一般是自建+傳統(tǒng)廠商。接觸VR早期的時候我還陷入過誤區(qū)，以為VR直播內(nèi)容是放在云端進行拼接合成。但的確就帶寬層面，以及在云端進行同步也基本是不可能的（目前一般都是在設(shè)備上直接硬同步）。一般廠商是在采集端完成了拼接映射后將VR內(nèi)容，成一個球形一起傳到云端。CDN處咱們可喜可賀的是，目前的廠商對上行都是不收費的。不然此處又是一筆天價的費用。

　　處理：

　　云端的轉(zhuǎn)碼、存儲和分發(fā)都是直接可以適用VR的。具體技術(shù)其實和一般的視頻并無區(qū)別。比較大的亮點，就是各家H.265的技術(shù)。例如金山的H.265，在H.265生態(tài)鏈打通后，H.265和VR結(jié)合能夠成為一個很大的優(yōu)勢點。畢竟在確保畫質(zhì)更優(yōu)情況下，帶寬的節(jié)省可是實打?qū)嵉摹?/p>

　　環(huán)節(jié)三：播放端

　　播放端和采集端對應的是還有一個逆映射的過程。通用的方案一般是Equiretangular，也有采用facebook transform的方案的。有了解到現(xiàn)在商用的VR播放器大多都是在unity引擎基礎(chǔ)上做的。整體的開發(fā)技術(shù)難度也比較低。

　　從這樣看來，樓主的問題就很簡單了。VR直播的內(nèi)容都是在采集端完成拼接合成再上傳到云端。不管后期如何發(fā)展，將多路內(nèi)容上傳到云端進行合成我個人覺得還是不可能的。尤其是在直播中。