Hacker News Reader

For a low number of people in the room, WebRTC will work well in a fully P2P way. There's no need for a centralized server unless you have more than 10 users connected.

Also, in practice for a big number of users you won't need to encode the videos streams more than 10 times because most people have the same kind of characteristics (you'll have up to three level of network connectivity, and most of your users will have h264 support so you will have few codecs to support).

For instance, you could go for 720p h264, 480p h264, 240p h264, and audio only for people with too little bandwidth or no h264 support, and you'll be good for most use cases.

> WebRTC will work well in a fully P2P way. There's no need for a centralized server unless you have more than 10 users connected.

I wish. With 10 users you have 102 - 10 = 90 different (unidirectional) data flows.

Each of them can run into a different bottleneck where person X cannot hear Y and Y cannot hear W...

And they cannot be monitored centrally (!).

Compared to a centralized location where you would have 10 user-->server + 10 server-->user flows.

On top of that, ISPs care about bandwidth between customers and large services e.g. AWS and don't care about ISP-to-ISP traffic.

> I wish. With 10 users you have 102 - 10 = 90 different (unidirectional) data flows.

I don't understand your maths: in a p2p network with 10 clients, each clients ends up having 9(up) + 9(down) streams, with a centralized server, there is still 9 streams to download, but a single upload.

Of course it requires 9 times less upload bandwith with a centralized server (or you get 9 times better quality for the same bandwidth), but as long as you don't have too much clients, p2p works fine.

Keep in mind that for video chat, the biggest issue for QoS are latency and jitter. Using a centralized server won't help on those and if you have a good connection in terms of jitter and latency, you usually don't have throughput problems either.

> And they cannot be monitored centrally (!).

Why ? You definitely can push QoS metrics to a central serverif you want (but this server will have a much lower load to handle than if it had to centralize the video chat themselves)

> On top of that, ISPs care about bandwidth between customers and large services e.g. AWS and don't care about ISP-to-ISP traffic.

And AWS makes you pay a lot for every byte.

> That's because every video feed usually needs to be realtime, low-latency transcoded to match the receivers bandwidth requirements.

Scalable video (and audio) never seemed to have taken off:

> SVC standardizes the encoding of a high-quality video bitstream that also contains one or more subset bitstreams. A subset video bitstream is derived by dropping packets from the larger video to reduce the bandwidth required for the subset bitstream. The subset bitstream can represent a lower spatial resolution (smaller screen), lower temporal resolution (lower frame rate), or lower quality video signal.

* https://en.wikipedia.org/wiki/Scalable_Video_Coding

* https://en.wikipedia.org/wiki/Bitrate_peeling

Yes, but perhaps now is the time, given the circumstances.

What's the client support for it?

There does seem to be a general push for it, including AV1:

* https://www.w3.org/TR/webrtc-svc/

nitpick because the slant of your argument is correct, but in a self-hosted system you don't necessarily need a single machine to encode 10 video feeds, each client (assuming this is a P2P approach) only needs to encode one - the user's. It does need to transcode that to 9 outbound streams, which is asking quite a lot of even current high end laptop hardware, and basically impossible on a smartphone.

Add in the unrealistic upstream bandwidth needs and, yeah, your point still stands.

I think a lot of WebRTC video conferencing solutions don't do server side video encoding - the clients encode their own stream(s) for high/low bandwidth, and server side they have a selective-packet-forwarder, or SPF. The clients are usually smart enough to only send the high bandwidth stream when that speaker is in focus.

Modern video codecs support SVC which makes the computation of several lower quality levels computationally inexpensive.

Firstly, a client will have 10 outgoing video streams at most, not 100!

Secondly, if we consider receivers bandwidth, a client can encode 2 or 3 video streams, e.g. low, medium, and high quality video.

I think he's saying the server would have to handle 100 streams. 10 clients * 10 streams each.

Still, isn't it one stream per client? Why 10 streams each?

If you're all connecting directly to a streaming server (instead of using something p2p), the server will have 10 connections for inbound video feeds and then 10*9 open outbound video connections to send each video to each client connection.

> 100 outgoing video feeds. Not many machines can encode 100 video feeds in realtime

The server will send 9 video streams to each connection, but it has to process only 10 video streams since it will send the same video data to all clients, if we ignore client bandwidth.

agreed. do not agree with OP that all 100 require transcoding

> if we ignore client bandwidth.

The parent post explicitly took the client bandwidth into account, that's why it was 100 instead of 10.

But your point about 10 vs 9 still stands. Still, 81, and if you bucket into 3 tiers, that's still 27. Which at least scales linearly instead of quadratically.

Exactly. It scales linearly, not quadratically. I forgot to mention that since clients do the "original" encoding, the server actually does less work (regarding resolution tiers).

I wonder if OP meant "1 outgoing and 9 incoming" streams.

Is there no video compression algorithm that lets you drop every third "line" or something from a higher resolution feed, to let you downscale video efficiently for bandwidth savings, but using only little CPU, and providing okay-ish quality?

That's not really how video codecs work. Below is a gross oversimplification to bootstrap the parent's knowledge.

Video is usually both temporally compressed (across frames), and over frequency domain (ala jpeg) in the frame itself.

Transcoding is essentially what you're asking for, it downscales the video. It's the cheapest currently or we'd be using something else.

If you just dropped data you'd get that blocky square thing that you get when watching tv or satellite and the signal goes lossy.

There are, but they are not widely used.