Комментарии 4
Проблемы, помимо совместимости кодеков, существуют прежде всего с масштабируемостью такого медиа сервера. То есть одновременно 100 родителей можно обслужить с одного серверского компьютера, а 500 – уже сложно.
для масштабируемости CDN придуманы в общем-то. камер по определению меньше, чем родителей, заведи их на ориджин, а родителям раздай потоки с эджей.
и, кстати, CDN не только WebRTCшные есть, просто у WebRTC задержка минимальная.
ведь сам WebRTC отводит отдельный порт на каждое соединение, так что провайдеру приходится открывать множество портов в firewall, что создает проблемы с безопасностью
только эти порты никто не слушает, пока ICE не прошел. поэтому особой проблемы нет. для
Всем привет! Я написал эту статью около двух лет назад, и только сейчас она вышла из песочницы. За два года мало что изменилось в мире WebRTC, да и других эффективных решений для стриминга в реальном времени в браузеры, больше не стало. WebRTC, как и два года назад, близок к стандартизации, и версия 1.0 «вот-вот», как и два года назад, должна выйти. Код WebRTC: webrtc.org/native-code стал еще более громоздким, и решения, которые принимает гугльская команда, все более и более настораживают. К примеру, прямо сейчас команда WebRTC
собирается запретить TCP кандидатов в локальной сети:
В Canary они уже это сделали. Мы их убеждаем этого не делать:
и вроде как они согласились запретить только кандидатов с портами ниже 1024.
По поводу масштабируемости, хочу добавить что в WebRTC загрузка процессора, из-за DTLS энкрипции, линейно растет с размером посылаемых данных, т.е. линейно зависит от битрейта. Поэтому для высоких битрейтов, неизбежных при HD и 4K контенте, WebRTC становится в 10-15 раз дороже чем RTMP. Масшатабируемость все-же достижима, но надо ставить либо больше ядер, либо больше серверов. Соответственно, решение гораздо более финансово дорогое.
Вот диаграмма роста загузки процессора с нарастанием числа одновременных плееров, по разным потоковым протоколам, взятая из документа описывающего основные возможности нашего сервера:
Тесты были произведены на 8-ядерном CPU. 16 ядер потянет в два раза больше.
И все же, разница с другими потоковыми протоколами колоссальная, и DTLS энкрипция здесь виновата только наполовину, ведь как видно из графика, Secure Websocket-MSE, также использующий TLS1.2 энкрипцию, в 2.5 раза менее затратный. Эти 2.5 раза, увы — следствие неэффективности кода WebRTC, даже после наших оптимизаций.
Основные оптимизации еще впереди. Ждем когда WebRTC 1.0 наконец выйдет, тогда будет иметь смысл радикально переработать гугльский код WebRTC.
собирается запретить TCP кандидатов в локальной сети:
В Canary они уже это сделали. Мы их убеждаем этого не делать:
и вроде как они согласились запретить только кандидатов с портами ниже 1024.
По поводу масштабируемости, хочу добавить что в WebRTC загрузка процессора, из-за DTLS энкрипции, линейно растет с размером посылаемых данных, т.е. линейно зависит от битрейта. Поэтому для высоких битрейтов, неизбежных при HD и 4K контенте, WebRTC становится в 10-15 раз дороже чем RTMP. Масшатабируемость все-же достижима, но надо ставить либо больше ядер, либо больше серверов. Соответственно, решение гораздо более финансово дорогое.
Вот диаграмма роста загузки процессора с нарастанием числа одновременных плееров, по разным потоковым протоколам, взятая из документа описывающего основные возможности нашего сервера:
Тесты были произведены на 8-ядерном CPU. 16 ядер потянет в два раза больше.
И все же, разница с другими потоковыми протоколами колоссальная, и DTLS энкрипция здесь виновата только наполовину, ведь как видно из графика, Secure Websocket-MSE, также использующий TLS1.2 энкрипцию, в 2.5 раза менее затратный. Эти 2.5 раза, увы — следствие неэффективности кода WebRTC, даже после наших оптимизаций.
Основные оптимизации еще впереди. Ждем когда WebRTC 1.0 наконец выйдет, тогда будет иметь смысл радикально переработать гугльский код WebRTC.
Совсем недавно наткнулся на один любопытный репозиторий — OBS.Ninja
Есть ли какие-то альтернативы?
Есть ли какие-то альтернативы?
Альтернативы есть. Вообще-то это идея довольно сумасшедшая — этот OBS.Ninja — ведь контент будет скомпрессирован перед отправкой из браузера по WebRTC, а потом декомпрессирован и подан в OBS, который его опять будет компрессировать. Зачем такие сложности? Куда по OBS вы собираетесь это стримить? С большой вероятностью туда же можно застримить прямо по WebRTC из браузера, так что этот промежуточный шаг с OBS — совершенно лишний.
Но уж если именно такое надо — пожалуйста, вот альтернатива:
stackoverflow.com/questions/59865405/use-webrtc-getusermedia-stream-as-input-for-ffmpeg/60143788#60143788
Надо поставить наш Unreal Media Server + WebRTC Source filter + Video mixer source filter.
Всего ничего :). Тогда любая программа по захвату, будь то OBS, ffmpeg и т.д., сможет получать видео от удаленного вебкама, как локальное, от Video mixer source filter.
Но уж если именно такое надо — пожалуйста, вот альтернатива:
stackoverflow.com/questions/59865405/use-webrtc-getusermedia-stream-as-input-for-ffmpeg/60143788#60143788
Надо поставить наш Unreal Media Server + WebRTC Source filter + Video mixer source filter.
Всего ничего :). Тогда любая программа по захвату, будь то OBS, ffmpeg и т.д., сможет получать видео от удаленного вебкама, как локальное, от Video mixer source filter.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация WebRTC в медиа сервере – практика и политика