По умолчанию certbot должен размещать файлы в каталоге
/etc/letsencrypt/live/<domain>/, например /etc/letsencrypt/live/mydomain.com/
хочу стать клиентом
- Thread starter Nikitos
- Start date
Посмотрите пожалуйста этот раздел документации. Там такие же имена файлов.
Вариант1
- cert.pem
- chain.pem
- privkey.pem
Вариант2
- fullchain.pem
- privkey.pem
Т.е. оба варианта импорта должны работать:
Вариант1
- cert.pem
- chain.pem
- privkey.pem
Вариант2
- fullchain.pem
- privkey.pem
Поясните, пожалуйста: Вы хотите подключаться к серверу из внешней сети и из локальной? В таком случае посмотрите, пожалуйста, эту тему
Nikitos
Member
Не совсем, смысл в том, что бы расширить пропускной канал, по одной витой паре скорость максимально 700-800 мбит сек, получается, что самым слабым звеном является сетевой интерфейс, по скольку при тесте сервера на 250 зриетелей нагрузка была всего лишь 5%
Может wcs сервер например разделить, первые 600 зрителей через один сетевой интерфейс, а вторые 600 через другой?
Обычно мы рекомендуем клиентам размещать сервер в датацентре или облачном хостинге, выбирая объем трафика в зависимости от задач, которые будет решать сервер. Посмотрите вот эти общие рекомендации (они касаются облачных серверов, но справедливы и для физических).
Если Вы размещаете сервер на собственной площадке, необходимо либо обеспечить канал, соответствующий планируемой нагрузке на сервер, либо планировать нагрузку, исходя из имеющихся ограничений.
1. Поднять бэкенд сервер (Apache, Nginx + PHP + что еще Вам для бэкенда понадобится)
2. Разобраться с этим примером, научиться считать подключенные сессии при помощи REST хука /connect
3. Добавить в скрипт бэкенда обработку REST хука /playStream, например
Code:
switch($api_method) {
case "connect":
...
break;
case "playStream":
players++;
if (players > 100) {
ubnormalResponse(403);
}
break;
}
header('Content-Type: application/json');
echo json_encode($incoming_data);
function ubnormalResponse($code) {
if ($code == 403) {
header('HTTP/1.1 403 Forbidden', true, $code);
} else {
header(':', true, $code);
}
die();
}Порты расходуются не только на подписчиков, но и на публикации
Управление битрейтом звука при публикации описано здесь (п 6). Битрейт необходимо задавать в битах в секунду, например 64000.
Вероятно, проблема в канале. Почитайте, пожалуйста, здесь, как проверить канал публикации/воспроизведения. Если по результатам тестирования необходимо настраивать битрейт видео, почитайте, как это можно сделать, здесь.
Точно так же, указывая битрейт в constraints при публикации
Code:
constraints.audio.bitrate = 64000
Code:
opus_formats=maxaveragebitrate=64000Nikitos
Member
Большое спасибо за помощь
Возник еще вопрос
Проблема с зависаниями видео затронула только телефоны, на стационарных компьютерах вроде как все работает без косяков
Решил воспользоваться плеером HLS -отчасти он решил проблему, ведь сама технология плеера как раз нацелена на воспроизведение видео без задержек с любой пропускной способностью
Но вот нагрузка на процессор возрасла в разы
Вопрос: вы проводили нагрузочные тесты для воспроизведения плеером HLS? у него больше ресурсопотребление? есть ли внем технология транскодинга?
Вопрос: Допустим, у меня 400 зрителей, из них 70% смотрят на смартфонах т.е. 280, остальные 120 на ПК. Мне выгоднее будет всех подключить к HLS? или например разделить: смартфоны на HLS а пк на Embed. Есть подозрение, что Embed потребляет меньше ресурсов
Возник еще вопрос
Проблема с зависаниями видео затронула только телефоны, на стационарных компьютерах вроде как все работает без косяков
Решил воспользоваться плеером HLS -отчасти он решил проблему, ведь сама технология плеера как раз нацелена на воспроизведение видео без задержек с любой пропускной способностью
Но вот нагрузка на процессор возрасла в разы
Вопрос: вы проводили нагрузочные тесты для воспроизведения плеером HLS? у него больше ресурсопотребление? есть ли внем технология транскодинга?
Вопрос: Допустим, у меня 400 зрителей, из них 70% смотрят на смартфонах т.е. 280, остальные 120 на ПК. Мне выгоднее будет всех подключить к HLS? или например разделить: смартфоны на HLS а пк на Embed. Есть подозрение, что Embed потребляет меньше ресурсов
Если публикуется, например, экран или вкладка браузера, развернутая на весь экран, получается FullHD поток. Если при этом мобильные устройства используют мобильную связь, скорее всего пропускной способности канала не хватает под этот поток. Поможет либо снижение разрешения публикации, либо транскодинг на сервере к меньшему разрешению.
По умолчанию, для HLS включается транскодинг к разрешению 640x480, для снижения нагрузки на канал с одной стороны и для совместимости с квадратными iPad с другой. Отключите транскодинг
Code:
hls_player_width=0
hls_player_height=0HLS дает задержку при трансляции, WebRTC задержку минимизирует. Поэтому имеет смысл там, где возможно, использовать WebRTC, если задержка критична. Кроме того, для плавного проигрывания по HLS необходим стабильный FPS публикации, а также регулярное поступление ключевых фреймов. Если публикация не обеспечивает ни того, ни другого, необходим транскодинг, который выровняет FPS и добавить регулярную отсылку ключевых фреймов.
Таким образом, Вы всегда вынуждены выбирать: либо повышение нагрузки на сервер (за счет транскодинга для адаптации к каналу пользователя и используемому протоколу трансляции), либо снижение качества картинки для того, чтобы пропихнуть поток в каналы всех пользователей.
Поэтому при большом количестве зрителей с разными каналами рекомендуется либо держать мощный сервер, либо разворачивать CDN и выносить задачу транскодинга на выделенные серверы. Подробнее об этом читайте здесь.