[Open source, Работа с видео, Nginx, Видеотехника, Видеоконференцсвязь] Видео трансляция с Oven Media Engine, до свидания nginx-rtmp-module,
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Роман Арутюнян (rarutyunyan) выпустил модуль nginx-rtmp-module, это сильно перевернуло взгляд на доступность организации видеовещания. До этого, это казалось каким-то дорогим и сложным делом. 31 декабря Adobe официально хоронит флешплеер и убирает ссылки на скачивание с сайта. Это, конечно, не может не радовать. Эти засранцы то и дело подсовывали включенные по умолчанию галочки, так что пользователю прилетал вместе с флешплеером еще и антивирус mcafee в лучшем случае. То, что это чудовище бесконечно просило обновлений ручками через браузер, знают все. Ходил даже анекдот, предлагающий создателям флешплеера законодательно ограничить паспорта сроком на 1 неделю с возможностью бесконечной перевыдачи.
Кому сдался флешплеер в конце 2020-го, вы хотите сказать? Да дело в том, что флеш плеер единственный поддерживал воспроизведение протокола rtmp в браузере с относительно низкой задержкой. Да и он не так уж и плох, учитывая, что по умолчанию все стриминговые сервисы, youtube или twitch из кодировщика просят передавать им видео по протоколу rtmp. Конечно, приходит более свежий SRT но разговор не об этом. Вы убрали возможность играть видео в браузере по rtmp, а где альтернативы-то? Форматы, работающие по http требуют хорошей буферизации. Задержка выливается в 15 секунд. Это неприемлемо, если вы общаетесь со своей аудиторией онлайн. WebRTC решения плохо дружат с реализацией один ко многим. Ну как плохо, плати, и будет хорошо. Cофт есть на рынке. Только беда еще с покрытием, по моим ощущениям, WebRTC только только нащупал какую-то стабильную фазу, при которой его можно использовать. Но все равно есть небольшие проблемы с форматами видео на разных платформах. Раньше все это выглядело так муторно, что проще было просить ставить флешплеер только ради малой задержки.
В issue к nginx-rtmp-module не я один оставлял вопросы о поддержке форматов передачи видео по http с низкой задержкой (2-3 секунды). Ведь если бы можно было вещать в формате dash и hls до 3 секунд на nginx-rtmp-module, меня бы это полностью устроило. Но ответов на эти вопросы нет. Низкая задержка нужна в 2020 году и без нее ну никак. К сожалению, проект c 2017 года не развивается.
Медиасервер OvenMediaEngine.
Прекрасной альтернативой, отвечающей порывам всех моих желаний, является корейская морковка опенсорсный проект OvenMediaEngine, предлагающий не только средства кодирования и кластеризации (как у nginx-rtmp-module) но и средства воспроизведения т.е. свой html5 плеер. Именно то, чего я так искал, зарелизили наши южнокорейские братья. С большим интересом я крутил его неделю и полностью перебрался на него.
Задержка по WebRTC полсекунды. Задержка по dash low latency 2 секунды. HLS low latency скоро обещают.
Возможности:
- RTMP Push, MPEG2-TS Push, RTSP Pull Input
- WebRTC sub-second streaming
- Embedded WebRTC Signalling Server (WebSocket based)
- ICE (Interactive Connectivity Establishment)
- DTLS (Datagram Transport Layer Security)
- SRTP (Secure Real-time Transport Protocol)
- ULPFEC (Forward Error Correction) with VP8, H.264
- In-band FEC (Forward Error Correction) with Opus
- Low-Latency MPEG-DASH streaming (Chunked CMAF)
- Legacy HLS/MPEG-DASH streaming
- Embedded Live Transcoder (VP8, H.264, Opus, AAC, Bypass)
- Origin-Edge structure
- Monitoring
- Experiment
- P2P Traffic Distribution
- RTSP Pull, MPEG-TS Push Input
Так как команда активно развивает медиасервер, для быстрых апгрейдов я решил использовать предложенную ими установку через докер, накатывая внутрь контейнера всего две вещи: сертификаты от Lets Encrypt и файл настройки сервера.
С моей точки зрения из-за свежести проекта, документация OvenMediaEngine не рассказывает о best default practice да и пока еще пролетают огрехи копипасты. Вникая во все это самостоятельно, выделил две проблемы с подачей материала и почувствовал что нужна статья.
- Показывают, как работают примеры по http и ws протоколу, хотя, очевидно, показывать нужно сразу, как работать на https и wss, все равно же придется заново все перенастраивать. К тому же, о прикреплении бесплатных сертификатов от Lets Encrypt в документации ни слова, хотя официально полностью поддерживают.
- Аналогично, после настройки и запуска сервера точка входа публично доступна для всех.(как и у nginx-rtmp-module) Нужно сразу показывать, как защищать точку входа.
Это все мелочи. Похвалю за очень удобные средства отладки. Они предлагают две страницы
http://demo.ovenplayer.com
https://demo.ovenplayer.com
http и https для отладки сервера. Более того, внесенные настройки сразу же отражаются как GET параметры в адресной строке — это чертовски удобно тестировать между браузерами. Поверьте, путаница в протоколах, портах, описках в урлах при первой подготовке сервера то еще занятие! А так, сохранил ссылку в браузере и возвращайся когда нужно к настройке с сохраненными настройками!
Установка. Быстрый старт
Итак, я возьму 20-ую Убунту.
https://airensoft.gitbook.io/ovenmediaengine/v/0.10.10/getting-started
docker run -d \
-p 1935:1935 -p 4000-4005:4000-4005/udp -p 3333:3333 -p 8080:8080 -p 9000:9000 -p 10000-10010:10000-10010/udp \
airensoft/ovenmediaengine:latest
После ставим certbot. Привязывайте ip к домену, получайте сертификаты.
Далее, получаем имя контейнера докера, например, 87b8610034bc
sudo docker container ls
Вытащим конфиг из контейнера для редактирования. (Ну мне удобнее в момент изучения конфига видеть его где-то с подсветкой синтаксиса, поэтому вытаскиваю файл)
sudo docker cp 87b8610034bc:/opt/ovenmediaengine/bin/origin_conf/Server.xml ./Server.xml
Старый добрый xml. (Мода же на json все дела… но благо это вообще не xml как в каком нибудь IIS, который, казалось бы, выступает какой то базой данных для миллиона кнопок в интерфейсе вебсервера.)
Выглядит конфиг так
https://github.com/AirenSoft/OvenMediaEngine/blob/master/misc/conf_examples/Server.xml
Раздел VirtualHost. Нам нужно задать имя сервера и указать пути к сертификатам внутри контейнера.
<Host>
<Names>
<Name>stream.***.ru</Name>
</Names>
<TLS>
<CertPath>/opt/ovenmediaengine/bin/cert.pem</CertPath>
<KeyPath>/opt/ovenmediaengine/bin/privkey.pem</KeyPath>
<ChainCertPath>/opt/ovenmediaengine/bin/chain.pem</ChainCertPath>
</TLS>
</Host>
Затем, нужно оставить только TLSPort порты.
<Publishers>
<HLS>
<TLSPort>${env:OME_HLS_STREAM_PORT:8080}</TLSPort>
</HLS>
<DASH>
<TLSPort>${env:OME_DASH_STREAM_PORT:8080}</TLSPort>
</DASH>
<WebRTC>
<Signalling>
<TLSPort>${env:OME_SIGNALLING_PORT:3333}</TLSPort>
</Signalling>
</WebRTC>
</Publishers>
Почему я рекомендую указывать те же порты, что и использовались для http? Сервер иначе не стартанет на одинаковых портах (не умеет), а выдумывать новые порты, когда при установке докера разработчики уже сделали в примере биндинги для контейнера, лишнее.
Заливаем конфиг обратно
sudo docker cp ./Server.xml 87b8610034bc:/opt/ovenmediaengine/bin/origin_conf/Server.xml
И, соответственно, по заданным путям мы кидаем наши ключи
docker cp /etc/letsencrypt/live/stream.****.ru/chain.pem 87b8610034bc:/opt/ovenmediaengine/bin/
docker cp /etc/letsencrypt/live/stream.****.ru/privkey.pem 87b8610034bc:/opt/ovenmediaengine/bin/
docker cp /etc/letsencrypt/live/stream.****.ru/cert.pem 87b8610034bc:/opt/ovenmediaengine/bin/
Перезапуск
sudo docker restart 87b8610034bc
Пробуем.
Урл вещания в obs
rtmp://stream.***.ru:1935/app
ключ ‘stream’
Линки для паблика
dash https://stream.***.ru:8080/app/stream/manifest.mpd
dash ll https://stream.***.ru:8080/app/stream/manifest_ll.mpd
hls https://stream.***.ru:8080/app/stream/playlist.m3u8
webrtc wss://stream.***.ru:3333/app/stream/
Если после запуска трансляции в obs все хорошо и по линкам отдается манифест, можете проверить видео на странице с плеером.
Подписывание ссылок
OME так устроен, что позволяет создать публичные линки с разными правами. Например, одну и туже ссылку можно ограничить ip диапазоном или временем работы по разному для разных людей. Они используют схожую логику как у гуглаSign Policy.
- Добавить блок SignedPolicy в секцию VirtualHost в Server.xml
<SignedPolicy>
<PolicyQueryKeyName>policy</PolicyQueryKeyName>
<SignatureQueryKeyName>signature</SignatureQueryKeyName>
<SecretKey>secretkey</SecretKey>
<Enables>
<Providers>rtmp</Providers>
<Publishers>webrtc,hls,dash,lldash</Publishers>
</Enables>
</SignedPolicy>
После этого, вы не сможете ни посылать поток по старой ссылке в OBS ни принимать трафик по публичным ссылкам без подписей.
- Запускаем signed_policy_url_generator.sh с параметрами, описанными внутри.
Например:
sudo bash ./signed_policy_url_generator.sh secretkey rtmp://stream.***.ru:1935/app/stream signature policy '{«url_expire»:8807083098927}'
url_expire — обязательный параметр, который просит в миллисекундах (это не unix timestamp, а currentmillis.com ) указать, когда истечет ссылка.
результат:
rtmp://stream.***.ru:1935/app/stream?policy=eyJ1cmxfZXhwaXJlIjo4ODA3MDgzMDk4OTI3fQ&signature=xjS7NY-l4lY1f9e9sOiRNhPtAqI
rtmp://stream.***.ru:1935/app — идет в OBS в Server, остальная часть — в «Stream key».
Если OBS стартанул трансляцию, теперь нужно обязательно подписать необходимые публичные ссылки. Например для WebRTC.
sudo bash ./signed_policy_url_generator.sh secretkey wss://stream.***.ru:3333/app/stream signature policy '{"url_expire":8807083098927}'
Таким образом, не имея доступа к секрету, получить какой либо доступ к OME из дефолтных настроек больше нельзя.
Остается, наверное, из настроек только прописать докер на автозапуск контейнера с системой. Ну и сертификаты на крон, со скриптом, копирующим в контейнер ключи и рестартующим его ну или как это там еще у вас принято.
sudo systemctl enable docker
sudo docker update --restart unless-stopped 87b8610034bc
О кодировании видео
Ребята считают OBS самым популярным кодировщиком для своего сервера. Поэтому как и в документации, так и более подробно в блоге можно найти подходящие настройки, максимально снижающие задержку в трансляции. Так же у них есть универсальный энкодер для андройда.
https://play.google.com/store/apps/details?id=com.airensoft.ovenstreamencoder.camera
Еще немного о корейской морковке
Когда пользователь выбирает в плеере в качестве источника webrtc, OME на лету конвертирует аудио в требуемый формат opus.(Это требования стандарта.)
По непонятным для меня причинам, WebRTC не может работать с mono звуком, поэтому не пытайтесь в настройках медиасервера переключать звук со стерео — он не запустится. Это не проблема OME.
Пожелания
- Система логов — это обычные txt файлики. Было бы очень круто иметь чуть более продвиную визуальную аналитику
- Я пробовал новый nginx-unit с его модным json-api в качестве команд управления/конфига. Суть в чем, обновляешь вебсервер, а он продолжает работать, заливаешь сертификаты, а ему не надо перезагружаться, домен, поддомен, добавить заголовки, убрать — все налету без перезагрузки. А поверх json-api появляется миллион офигенно удобных админок с UI. Хотя в OME и вроде бы и нет нужды в таком API, но наверняка кто-то что-то потом обязательно придумает)
Немного о ребятах. Они себя позиционируют как группа экспертов по медиа технологиям, ведут блогс довольно полезным контентом.
Судя по тому, что они плотно сотрудничают с местными телекомами и их компания на плаву уже лет 10 лет, чувствуется очень хороший бекграунд для поддержки опенсорса в области стриминга. Это замечательно. Я прикреплю несколько фоток их нового офиса.
===========
Источник:
habr.com
===========
Похожие новости:
- [Работа с видео, Бизнес-модели, Социальные сети и сообщества] Reddit купил сервис коротких видео Dubsmash
- [Настройка Linux, Open source, Разработка под Linux] Состоялся релиз ядра Linux 5.10
- [Open source, Конференции, DevOps, Kubernetes] [Анонс] 16 декабря 2020 — Воркшоп: Знакомство с архитектурой решения Traefik
- [Open source, Creative Commons, Открытые данные, Законодательство в IT, Копирайт] Встречайте Creative Commons Legal Database (перевод)
- [Open source, *nix] FOSS News №46 – дайджест новостей и других материалов о свободном и открытом ПО за 7-13 декабря 2020 года
- [Настройка Linux, Open source, IT-инфраструктура, DevOps, Облачные сервисы] Ламповая self-hosted инфраструктура на Vultr
- [Информационная безопасность, Open source, Совершенный код, Исследования и прогнозы в IT] Разработчики ПО с открытым исходным кодом уделяют вопросам безопасности менее 3% времени
- [Open source, IT-стандарты, Статистика в IT] Google предложил рейтинг критически важных Open-source проектов
- [Open source, Разработка игр, Финансы в IT, IT-компании] Верховный суд отказал Wargaming в иске к своим бывшим сотрудникам
- [Open source, Разработка под Android] Делюсь небольшим, но полезным плагином: Deeplink Helper для Android Studio
Теги для поиска: #_open_source, #_rabota_s_video (Работа с видео), #_nginx, #_videotehnika (Видеотехника), #_videokonferentssvjaz (Видеоконференцсвязь), #_nginxrtmpmodule, #_webrtc, #_dash, #_hsl, #_strimingovye_servisy (стриминговые сервисы), #_striming (стриминг), #_open_source, #_rabota_s_video (
Работа с видео
), #_nginx, #_videotehnika (
Видеотехника
), #_videokonferentssvjaz (
Видеоконференцсвязь
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 05:56
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Роман Арутюнян (rarutyunyan) выпустил модуль nginx-rtmp-module, это сильно перевернуло взгляд на доступность организации видеовещания. До этого, это казалось каким-то дорогим и сложным делом. 31 декабря Adobe официально хоронит флешплеер и убирает ссылки на скачивание с сайта. Это, конечно, не может не радовать. Эти засранцы то и дело подсовывали включенные по умолчанию галочки, так что пользователю прилетал вместе с флешплеером еще и антивирус mcafee в лучшем случае. То, что это чудовище бесконечно просило обновлений ручками через браузер, знают все. Ходил даже анекдот, предлагающий создателям флешплеера законодательно ограничить паспорта сроком на 1 неделю с возможностью бесконечной перевыдачи. Кому сдался флешплеер в конце 2020-го, вы хотите сказать? Да дело в том, что флеш плеер единственный поддерживал воспроизведение протокола rtmp в браузере с относительно низкой задержкой. Да и он не так уж и плох, учитывая, что по умолчанию все стриминговые сервисы, youtube или twitch из кодировщика просят передавать им видео по протоколу rtmp. Конечно, приходит более свежий SRT но разговор не об этом. Вы убрали возможность играть видео в браузере по rtmp, а где альтернативы-то? Форматы, работающие по http требуют хорошей буферизации. Задержка выливается в 15 секунд. Это неприемлемо, если вы общаетесь со своей аудиторией онлайн. WebRTC решения плохо дружат с реализацией один ко многим. Ну как плохо, плати, и будет хорошо. Cофт есть на рынке. Только беда еще с покрытием, по моим ощущениям, WebRTC только только нащупал какую-то стабильную фазу, при которой его можно использовать. Но все равно есть небольшие проблемы с форматами видео на разных платформах. Раньше все это выглядело так муторно, что проще было просить ставить флешплеер только ради малой задержки. В issue к nginx-rtmp-module не я один оставлял вопросы о поддержке форматов передачи видео по http с низкой задержкой (2-3 секунды). Ведь если бы можно было вещать в формате dash и hls до 3 секунд на nginx-rtmp-module, меня бы это полностью устроило. Но ответов на эти вопросы нет. Низкая задержка нужна в 2020 году и без нее ну никак. К сожалению, проект c 2017 года не развивается. Медиасервер OvenMediaEngine. Прекрасной альтернативой, отвечающей порывам всех моих желаний, является корейская морковка опенсорсный проект OvenMediaEngine, предлагающий не только средства кодирования и кластеризации (как у nginx-rtmp-module) но и средства воспроизведения т.е. свой html5 плеер. Именно то, чего я так искал, зарелизили наши южнокорейские братья. С большим интересом я крутил его неделю и полностью перебрался на него. Задержка по WebRTC полсекунды. Задержка по dash low latency 2 секунды. HLS low latency скоро обещают. Возможности:
Так как команда активно развивает медиасервер, для быстрых апгрейдов я решил использовать предложенную ими установку через докер, накатывая внутрь контейнера всего две вещи: сертификаты от Lets Encrypt и файл настройки сервера. С моей точки зрения из-за свежести проекта, документация OvenMediaEngine не рассказывает о best default practice да и пока еще пролетают огрехи копипасты. Вникая во все это самостоятельно, выделил две проблемы с подачей материала и почувствовал что нужна статья.
Это все мелочи. Похвалю за очень удобные средства отладки. Они предлагают две страницы http://demo.ovenplayer.com https://demo.ovenplayer.com http и https для отладки сервера. Более того, внесенные настройки сразу же отражаются как GET параметры в адресной строке — это чертовски удобно тестировать между браузерами. Поверьте, путаница в протоколах, портах, описках в урлах при первой подготовке сервера то еще занятие! А так, сохранил ссылку в браузере и возвращайся когда нужно к настройке с сохраненными настройками! Установка. Быстрый старт Итак, я возьму 20-ую Убунту. https://airensoft.gitbook.io/ovenmediaengine/v/0.10.10/getting-started docker run -d \
-p 1935:1935 -p 4000-4005:4000-4005/udp -p 3333:3333 -p 8080:8080 -p 9000:9000 -p 10000-10010:10000-10010/udp \ airensoft/ovenmediaengine:latest После ставим certbot. Привязывайте ip к домену, получайте сертификаты. Далее, получаем имя контейнера докера, например, 87b8610034bc sudo docker container ls
Вытащим конфиг из контейнера для редактирования. (Ну мне удобнее в момент изучения конфига видеть его где-то с подсветкой синтаксиса, поэтому вытаскиваю файл) sudo docker cp 87b8610034bc:/opt/ovenmediaengine/bin/origin_conf/Server.xml ./Server.xml
Старый добрый xml. (Мода же на json все дела… но благо это вообще не xml как в каком нибудь IIS, который, казалось бы, выступает какой то базой данных для миллиона кнопок в интерфейсе вебсервера.) Выглядит конфиг так https://github.com/AirenSoft/OvenMediaEngine/blob/master/misc/conf_examples/Server.xml Раздел VirtualHost. Нам нужно задать имя сервера и указать пути к сертификатам внутри контейнера. <Host>
<Names> <Name>stream.***.ru</Name> </Names> <TLS> <CertPath>/opt/ovenmediaengine/bin/cert.pem</CertPath> <KeyPath>/opt/ovenmediaengine/bin/privkey.pem</KeyPath> <ChainCertPath>/opt/ovenmediaengine/bin/chain.pem</ChainCertPath> </TLS> </Host> Затем, нужно оставить только TLSPort порты. <Publishers>
<HLS> <TLSPort>${env:OME_HLS_STREAM_PORT:8080}</TLSPort> </HLS> <DASH> <TLSPort>${env:OME_DASH_STREAM_PORT:8080}</TLSPort> </DASH> <WebRTC> <Signalling> <TLSPort>${env:OME_SIGNALLING_PORT:3333}</TLSPort> </Signalling> </WebRTC> </Publishers> Почему я рекомендую указывать те же порты, что и использовались для http? Сервер иначе не стартанет на одинаковых портах (не умеет), а выдумывать новые порты, когда при установке докера разработчики уже сделали в примере биндинги для контейнера, лишнее. Заливаем конфиг обратно sudo docker cp ./Server.xml 87b8610034bc:/opt/ovenmediaengine/bin/origin_conf/Server.xml
И, соответственно, по заданным путям мы кидаем наши ключи docker cp /etc/letsencrypt/live/stream.****.ru/chain.pem 87b8610034bc:/opt/ovenmediaengine/bin/
docker cp /etc/letsencrypt/live/stream.****.ru/privkey.pem 87b8610034bc:/opt/ovenmediaengine/bin/ docker cp /etc/letsencrypt/live/stream.****.ru/cert.pem 87b8610034bc:/opt/ovenmediaengine/bin/ Перезапуск sudo docker restart 87b8610034bc
Пробуем. Урл вещания в obs rtmp://stream.***.ru:1935/app
ключ ‘stream’ Линки для паблика dash https://stream.***.ru:8080/app/stream/manifest.mpd
dash ll https://stream.***.ru:8080/app/stream/manifest_ll.mpd hls https://stream.***.ru:8080/app/stream/playlist.m3u8 webrtc wss://stream.***.ru:3333/app/stream/ Если после запуска трансляции в obs все хорошо и по линкам отдается манифест, можете проверить видео на странице с плеером. Подписывание ссылок OME так устроен, что позволяет создать публичные линки с разными правами. Например, одну и туже ссылку можно ограничить ip диапазоном или временем работы по разному для разных людей. Они используют схожую логику как у гуглаSign Policy.
<SignedPolicy>
<PolicyQueryKeyName>policy</PolicyQueryKeyName> <SignatureQueryKeyName>signature</SignatureQueryKeyName> <SecretKey>secretkey</SecretKey> <Enables> <Providers>rtmp</Providers> <Publishers>webrtc,hls,dash,lldash</Publishers> </Enables> </SignedPolicy> После этого, вы не сможете ни посылать поток по старой ссылке в OBS ни принимать трафик по публичным ссылкам без подписей.
Например: sudo bash ./signed_policy_url_generator.sh secretkey rtmp://stream.***.ru:1935/app/stream signature policy '{«url_expire»:8807083098927}'
url_expire — обязательный параметр, который просит в миллисекундах (это не unix timestamp, а currentmillis.com ) указать, когда истечет ссылка. результат: rtmp://stream.***.ru:1935/app/stream?policy=eyJ1cmxfZXhwaXJlIjo4ODA3MDgzMDk4OTI3fQ&signature=xjS7NY-l4lY1f9e9sOiRNhPtAqI
rtmp://stream.***.ru:1935/app — идет в OBS в Server, остальная часть — в «Stream key». Если OBS стартанул трансляцию, теперь нужно обязательно подписать необходимые публичные ссылки. Например для WebRTC. sudo bash ./signed_policy_url_generator.sh secretkey wss://stream.***.ru:3333/app/stream signature policy '{"url_expire":8807083098927}'
Таким образом, не имея доступа к секрету, получить какой либо доступ к OME из дефолтных настроек больше нельзя. Остается, наверное, из настроек только прописать докер на автозапуск контейнера с системой. Ну и сертификаты на крон, со скриптом, копирующим в контейнер ключи и рестартующим его ну или как это там еще у вас принято. sudo systemctl enable docker
sudo docker update --restart unless-stopped 87b8610034bc
О кодировании видео Ребята считают OBS самым популярным кодировщиком для своего сервера. Поэтому как и в документации, так и более подробно в блоге можно найти подходящие настройки, максимально снижающие задержку в трансляции. Так же у них есть универсальный энкодер для андройда. https://play.google.com/store/apps/details?id=com.airensoft.ovenstreamencoder.camera Еще немного о корейской морковке Когда пользователь выбирает в плеере в качестве источника webrtc, OME на лету конвертирует аудио в требуемый формат opus.(Это требования стандарта.) По непонятным для меня причинам, WebRTC не может работать с mono звуком, поэтому не пытайтесь в настройках медиасервера переключать звук со стерео — он не запустится. Это не проблема OME. Пожелания
Немного о ребятах. Они себя позиционируют как группа экспертов по медиа технологиям, ведут блогс довольно полезным контентом. Судя по тому, что они плотно сотрудничают с местными телекомами и их компания на плаву уже лет 10 лет, чувствуется очень хороший бекграунд для поддержки опенсорса в области стриминга. Это замечательно. Я прикреплю несколько фоток их нового офиса. =========== Источник: habr.com =========== Похожие новости:
Работа с видео ), #_nginx, #_videotehnika ( Видеотехника ), #_videokonferentssvjaz ( Видеоконференцсвязь ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 05:56
Часовой пояс: UTC + 5