Re: Network bandwidth and Latency consideration to support quality WebVR experience

Just few comments from my side:

- regarding implementations YouTube supports adaptive Streaming also for 360° videos in the same way as for normal videos .

One improvement for reducing bandwidth could be by applying adaptive streaming on the FOV and not on the whole video. This means you can stream the invisible part of the video with lower quality and the visible part with higher quality. The Bandwidth problem is related to 360° streaming in general and not only to WebVR. You need to deal with the same issue even if you use a native application and not WebVR in the Browser. Static assets and JS libs (three.js, a-frame, etc.) can be easily cached in the Browser.


Louay

________________________________
From: Kieran Farr <kieran.farr@gmail.com>
Sent: Wednesday, July 19, 2017 6:08:31 PM
To: Barry, Aguibou, Vodafone Group
Cc: public-webvr@w3.org
Subject: Re: Network bandwidth and Latency consideration to support quality WebVR experience

A quick attempt at thinking through some answers, but others please chime in with better responses:

  *   The library payload size is already larger than a standard web page (500kb for minified three.js alone, and then another webvr library like A-Frame adds another 500kb). Often the page will also still include other standard libraries like jquery, google analytics, etc.
  *   Obviously textures and objects in scene are larger than standard assets you'd see on a non WebVR web page, but the complexity of scenes varies widely so it's hard to know what is "normal" size at this early stage. It would be an interesting experiment to aggregate a bunch of webvr demos to get an average / median page size.
  *   Right now most WebVR scenes load everything up-front and there is no great implementations that I've seen (yet) of streaming assets with varying levels of detail, although that is totally possible and will just require some time for the libraries and third-party components to mature
  *   Most webvr 360º video implementations I've seen are very high bitrate (4Mbps and higher) with progressive (non HLS) streaming. Improvements will definitely be coming with both encoding and support for HLS and other multi-bitrate / segmented protocols.

So in summary - on the library / application layer it looks like there is significant room for improvement with streaming assets and 360º video compression improvements, and it sounds like on the mobile infrastructure side there will be improvements so maybe it will meet in the middle and everyone will be happy?

Kieran

On Wed, Jul 19, 2017 at 7:15 AM, Barry, Aguibou, Vodafone Group <Aguibou.Barry@vodafone.com<mailto:Aguibou.Barry@vodafone.com>> wrote:
Hi all,

Hope this email finds you well.

I understand that the group mostly focuses on exposing the VR hardware capabilities to the web browsers so please do let me know if the below matter would be better answered somewhere else (e.g. on WebVR’s or Aframe’s slack group).

I am looking into AR/VR at Vodafone Group from the device standpoint and I’d like to understand the WebVR group’s expectation from network operators (be it fixed or cellular), in particular what the network capability are needed to support a massive adoption of high quality WebVR experience by 2020/2021.

I have basically two questions:

-          Would you say that the bandwidth required by a high quality WebVR experience (in 2020/2021) will be compared to an image-intensive application e.g. Snapchat, Instagram or even Facebook that constantly download files or stream data to devices?

-          Or would a high quality WebVR experience already live with current 4G datarates i.e. below 15Mbps, or should we brace for really high data rate i.e. above 20Mbps (or even 1Gbps) and why?

I have the following assumptions in mind (those may be really bad assumptions though):

-          By 2020/2021, the first 5G networks and mobile chipsets will be available

-          By high quality I assume Stereoscopic view, 4K per eye

-          WebVR websites will mainly be hosted in public Clouds (e.g. Dublin’s or Virginia’s Amazon Cloud), sometimes in IPX endpoints (e.g. Netflix’s CDN) or maybe even mobile edge cloud in case ultra-low latency is required..

Kind Regards

Aguibou