On 20/03/2020 8:34 am, Tom Worthington wrote:
> There is likely to be a high demand for Internet access over the next few 
> months due
> to COVID19. So I suggest that video products be set to limit bandwidth use by
> default. Video streaming and conference tools adjust to the bandwidth 
> available, but
> try to use *all* that bandwidth. This makes them poor online citizens, like 
> someone
> who fills their shopping trolley with toilet paper, if you let them. ;-)

With much respect, I'll take the contrarian view then.

Actually, videoconferencing systems (unlike one-way streaming media like 
youtube)
don't adjust to use all the bandwidth, and I'm not convinced its a problem 
these days
except for people forced to use older, slow links.  In a zoom call with ~10 
endpoints,
I see sustained downstream bandwidth use under 2 Mbps, only a few percent of the
available link capacity.

Auto-adjusting-quality video streams generally requires the video be 
pre-recorded and
stored with several different different quality/bandwidth encoding versions of 
the
whole video file stored in parallel, and the viewing client then selecting the
appropriate file according to its measurement of congestion at the time. That 
isn't
what is done with live video, as it isn't feasible to trans-code a stream after 
it has
been transmitted due to the inherent delays and perception of lag that would 
introduce.

Given the asymmetric nature of our broadband networks (and NBN incredibly 
wanting to
make its products *more* asymmetric rather than less), its generally the 
upstream
direction where congestion is apparent - and the user on the end of one of 
those links
can turn off their own video to free up capacity for the audio quality to 
improve. I
generally see this when a user is trying to use a cellular mobile connection - 
but
even then, in many cases the quality is good. Rarely is there a constraint in 
the
downstream direction, which is where making a blanket change for all VC 
endpoints
might improve.


> There were only a few brief dropouts in the audio (fewer than on ABC Radio 
> National
> that morning). This was with Zoom, which is not my favorite product, as there 
> is no
> way for participants to set the audio or video quality to reduce bandwidth. 
> But it
> is possible to reduce data use to around 220 to 300 kbps by making the video 
> window
> smaller.

I find Zoom works very well, and supports better quality and more users for a 
given
level of bandwidth than most, but horses-for-courses. 220, 300, or even 500 
kbps on
the network downstream, or even upstream, is not much these days, and not worth
optimising further. Several Mbps perhaps, 500 kbps no. If links cannot support 
500
kbps in either direction, then videoconferencing is not appropriate, and the 
user
should dial-in instead. (controversial point for discussion ahead) concerns 
about a
few hundred kilobits being meaningful represents 1990s thinking, not current 
network
capabiities. If the access networks this decade cannot support, then the 
networks need
to be improved, not pandering to last century expectations retained. It works 
fine on
access links with only a couple of Mbps in each direction, which is not an
unreasonable expectation for the 2020s.

> It would be good if the video products, such as Zoom, used a low bandwidth 
> mode with
> a small video window, by default.

With live video such as videoconferencing, bandwidth reduction is done by 
reducing
frame-rate rather than resolution or window size. Zoom does have controls to 
reduce
bandwidth (high-def can be turned off), and to reduce frame-rate, at least for
desktop-sharing presentations - again, to control for restricted upstream 
capacity of
the person doing the presenting.

In my experience, I often find the biggest constraint is not the network, but 
the
limited processing power of older devices, with sluggish videoconference 
performance
due to CPU is maxed out decoding and displaying the video without adequate GPU
assistance. We may get better improvements by upgrading people's equipment, 
instead of
their network connection.

>
> More at: 
> https://blog.tomw.net.au/2020/03/video-conference-on-covid-19-and.html
>
>
Paul.


_______________________________________________
Link mailing list
[email protected]
http://mailman.anu.edu.au/mailman/listinfo/link

Reply via email to