fyi. Архитектура zoom.
От: Sharov Россия  
Дата: 02.06.20 19:22
Оценка: 6 (1)
Здравствуйте.

Не очень много в интернете инф-ии об архитектуре данного сервиса.
Вот блог highscalability собирал что мог по кусочкам -- http://highscalability.com/blog/2020/5/14/a-short-on-how-zoom-works.html


Zoom chose the SVC (Scalable Video Codec) codec over AVC. AVC is a protocol where you send a single stream and the single stream has a bitrate. If you want to send multiple bitrates you have to send multiple streams. This increases bandwidth utilization if you want to send multiple bitrates.

SVC is a single stream with multiple layers. That allows sending a 1.2 mbs stream that has every resolution and bitrate you may need to scale down to given network conditions. In the past you could only do SVC with an ASIC. Now, thanks to Moore’s law, SVC can be done in software.

Zoom created Multimedia Routing to solve the problems traditional vendors have with AVC. Cutting out transcoding got rid of latency and increased scale.
Multimedia routing takes user content into their cloud and when you as a client run into issues they switch a different video stream to you. When you want a different resolution you subscribe to a different layer of that person’s resolution.

Zoom does not transcode or mix anything or form any views. You are literally pulling multiple streams from multiple people directly from routing with zero processing. This is why you see such a great user switching and voice switching experience and low latency.

Zoom developed application layer QoS (Quality of Service) that works between the cloud and the client. Its job is to detect network conditions. Gathered telemetry data determines which stream is switched to a client. The algorithm looks at CPU, jitter, packet loss, etc.

Кодом людям нужно помогать!
Re: fyi. Архитектура zoom.
От: Sharov Россия  
Дата: 02.06.20 19:29
Оценка:

The client talks to the cloud. The cloud knows when it doesn't get certain packets back, so it will make decisions and switch a different stream down to you.

Зачем сразу поток переключать(?), может дело не в клиенте, а в облаке?
Кодом людям нужно помогать!
Re[2]: fyi. Архитектура zoom.
От: reversecode google
Дата: 02.06.20 22:38
Оценка: 5 (1)
если аск от клиента не пришел, значит поток сильно толстый и надо понижать битрейт кодека
Re: fyi. Архитектура zoom.
От: Pzz Россия https://github.com/alexpevzner
Дата: 03.06.20 00:49
Оценка:
Здравствуйте, Sharov, Вы писали:

S>

S>SVC is a single stream with multiple layers. That allows sending a 1.2 mbs stream that has every resolution and bitrate you may need to scale down to given network conditions. In the past you could only do SVC with an ASIC. Now, thanks to Moore’s law, SVC can be done in software.


Теперь я понимаю, зачем эта штуковина нагружает ядро процессора на 85% там, где гуглевому хангауту хватало 20%.
Re[2]: fyi. Архитектура zoom.
От: Pzz Россия https://github.com/alexpevzner
Дата: 03.06.20 00:53
Оценка: 6 (1)
Здравствуйте, Sharov, Вы писали:

S>Зачем сразу поток переключать(?), может дело не в клиенте, а в облаке?


Какая разница, в чем, в клиенте или в облаке? Если 1 мегабит не лезет, надо переходить на полмегабита, по какой бы причине он не лез.

Layered encoding, в принципе, здравая идея для передачи медиапотоков через интернет. Я всегда и всем это говорил
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.