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

Hello everybody,

Having worked on 360° video distribution for a year, I'll give my 2-cents.

   - To begin with, 360° video streaming is easily doable through HLS.
   Given the good encoding parameters, I managed to have a good streaming
   experience at 3840x1920 on 4G and correct Wi-FI. So I guess it should only
   improved from now on.
   - As Louay said, there will be new ways to stream 360° videos. As the
   content cannot be seen all at once, stream bits are downloaded for nothing.
   Some companies are already looking into it, most known would be Pixvana (
   https://pixvana.com/vr-video-lab-field-of-view-adaptive-streaming/)

So, from my own experience, to answer to your question of "WebVR group’s
expectation from network operators", I'd say that what we need for today's
experiments is a reliable network to download 15Mo in less than 3sec, and
improve from there.
I'm based in France and such a network isn't easy to find everywhere, good
4G isn't widespread yet, and some wired Internet connection are stuck to
1Mo second. Dunno how it is in the US but I guess that once you leave the
Silicon Valley, you'll find lots of places like that. And I'm not even
speaking of less developed countries, where a simple connection can be hard
to find.

Hope that helps!

2017-07-19 23:14 GMT+02:00 Bassbouss, Louay <
louay.bassbouss@fokus.fraunhofer.de>:

> 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> 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
>>
>>
>>
>
>


-- 
====================
Thomas BALOUET
Freelance Web&VR Creative Engineer
https://www.tbaloo.com