Привет, хабарчане! Это третья статья про разработку RUSEON-core, Zero-Copy сервера потокового видео для AI-платформ и Edge-видеоинфраструктуры. В предыдущих статьях (первая и вторая), были разобраны моменты с оптимизацией раздачи потоков при больших одновременных нагрузках, а также узкие места ОС в контексте потоковой записи на диск. В этой же статье, я хочу рассказать, о другой более специфичной проблеме – HLS-мультиплексировании.
Если кто то, когда-либо занимался видеопотоками поверх интернета, т.е использовал классический медиасервер работающий по принципу RTSP to HLS (или ему подобные протоколы) тогда он знает какие проблемы возникают. Для примера возьмем двух гигантов, Flussonic и Wowza. В документации Flussonic`a есть четкие аппаратные характеристики при которых ЦП начнет долбиться в сотку: 250 камер с битрейтом 2 Мбит/c, на Xeon E3-1230v5 3.4 GHz + 32 GB RAM. У Wowza же четких примеров нет, но если немного «экстраполировать», то у нее на том же железе около 350-400 камер с битрейтом 2 Мбит/c, загружают процессор на сотку. Давайте внесу оговорку: я понимаю, что указанное железо довольно старое. Но 80% малого и среднего бизнеса на +/- таком работают, я имею ввиду тех, кто не пользуется облачной инфраструктурой или не арендует железо в ДЦ. Так вот, казалось бы, ну такая вот нагрузка, что с ней поделать? Проблема в том, что в моменте эти потоки никто не смотрит. Условный «охранник» залипает в телефоне, пьет кофе – а сервак 24/7 продолжает нарезать сырые кадры в…
Решение на…
В…
