Тормоза видео на HTTPS странице.

[alexosh]

Во время разработки сайт работает по HTTP соединению. К wsc подключается по secure портам (https/8888 и wss/8443), используется стандартный embed_player - видео показывается стабильно.

При деплое на сервер который обслуживает страницу по HTTPS, в этом же самом браузере видео 1) достаточно долго загружается и постоянно замораживается, потом опять на несколько секунд размораживается и опять.

По идее единственное отличие между страницами это то что в режиме разработки HTTP а в режиме продакшн HTTPS (это протоколы загрузки самой HTML странице, подключения к серверу совершенно одинаковые, т.е. страницы идентичны).


Доп вопрос по iOS Safari:

На HTTPS странице так и не начинает показывать видео в плеере на черном фоне крутится белый спиннер и всё, а на HTTP странице в режиме разработки с описанной выше конфигурацией вообще просто белый прямоугольник, т.е. плеер как бы не активируется.


Подскажите, где и что смотреть?

 

[Max]

Добрый день.

По идее единственное отличие между страницами это то что в режиме разработки HTTP а в режиме продакшн HTTPS (это протоколы загрузки самой HTML странице, подключения к серверу совершенно одинаковые, т.е. страницы идентичны).

Скорее всего development и production сервер расположены в разных датацентрах. По Вашему описанию, выглядит так, что канала до dev сервера хватает, а до production - нет. Попробуйте поиграть этот же поток в примере Media Devices, он покажет WebRTC-статистику во время проигрывания. Если битрейт прыгает, а показатели NACK count и Video lost растут, это означает, что для потока с данными параметрами (разрешение/битрейт) не хватает канала, либо канал широкий. но с потерями.
Канал можно протестировать при помощи iperf, как описано здесь.
Также Вы можете включить передачу на клиента текущего битрейта видео

outbound_video_rate_stat_send_interval=1

и проиграть поток в примере Media Devices. В этом случае пример отобразит качество канала: PERFECT, GOOD или BAD. При BAD с каналом есть какие-либо проблемы, приводящие к потерям и скачкам битрейта проигрывания.
Подробнее о контроле качества канала можно прочитать здесь.
Для того, чтобы решить проблемы с каналом, рекомендуем:
- использовать сервер ближе к зрителю (в другом датацентре)
- использовать более стабильную сеть (WiFi вместо 4G, проводное подключение вместо WiFi)
- включить TCP транспорт на сервере

ice_tcp_transport=true

- снизить разрешение/битрейт публикации (например, 640x360 700 кбит/с вместо 1920x1080 2500 кбит/с)

Доп вопрос по iOS Safari:
На HTTPS странице так и не начинает показывать видео в плеере на черном фоне крутится белый спиннер и всё, а на HTTP странице в режиме разработки с описанной выше конфигурацией вообще просто белый прямоугольник, т.е. плеер как бы не активируется.

В мобильных браузерах WebRTC не работает по HTTP, только по HTTPS, причем iOS Safari (и любые браузеры на iOS) требуют валидных SSL сертификатов, с самоподписанными также не будет работать.
А по HTTPS поток не проключается, скорее всего, по причинам, изложенным выше.

 

[alexosh]

> Скорее всего development и production сервер расположены в разных датацентрах.

Сервер один и тот же) клиент (компьютер, браузер один и тот же), открываем в соседних вкладка. По идее всё одно и тоже. Отличаются реально только протоколы самой страницы с которых просматривается видео. Еще раз, речь идет о протоколе загрузке самой страницы и а не видео, в параметрах iframe видео передаются одни и те же. Сертификат на сервере валидный (https страница отображается как безопасная, когда на сервере был не валидный, даже если сама страница загружена с валидным сертификатом, в хроме показывалось, что страница не безопасна, как только на WCS установили валидный серт, стало показываться что безопасно).

Т.е. в случае http://my-domain.com видео с нее показывается ок,если это https:/my-domain.com -показывается плохо. Тут явно получается что-то с клиентской стороной, браузер на странице https как-то по другому обрабатывает трафика, чем просто http, причем мне совершенно непонятно что это может быть.


UPD:

Та же самая ситуация наблюдается в интерфейсе управления сервером и с демо пелеерами:

Если заходить на wcs:9091 - на этих страницах видео показывается ок, на wcs:8888 (с валидным или нет сертификатом) - идут заморозки.

 

[Max]

Отличаются реально только протоколы самой страницы с которых просматривается видео.

Протокол, по которому открывается websocket соединение, никак не должен влиять на качество проигрывания: для передачи медиатрафика используются отдельные порты. Необходимо проверить в Вашем окружении.
Предоставьте, пожалуйста, доступ к серверу с возможностью публикации и проигрывания, используя эту форму.
Также уточните, как именно публикуется проигрываемый поток: из другой вкладки по WebRTC, с IP камеры по RTSP, из RTMP кодировщика, чтобы мы могли воспроизводить проблему.

 

[alexosh]

> Протокол, по которому открывается websocket соединение, никак не должен влиять на качество проигрывания: для передачи медиатрафика используются отдельные порты. Необходимо проверить в Вашем окружении.

Речь идет не о протоколе веб-сокет соединения, а о протоколе загрузки страницы на которое помещается видео-плеер.

Данные отправили. Поток публикуется с камеры, адрес в комментарии отправлен. Если заходить в интерфейс по HTTPS/8888 будет видны тормоза. Если зайти через HTTP/9091 видео идет без тормозов.

 

[Max]

Мы проверили Ваш сервер.
Вы используете для тестов минимальную конфигурацию (1 CPU, 2 Gb RAM). В случае транскодинга потоков (судя по статистике, Вы играете потоки с RTSP камер 1920x1080) производительности этого сервера будет недостаточно. Для FullHD потоков рекомендуем минимум 4 CPU, 16 Gb RAM.
Кроме того, Вы используете устаревшую сборку WCS и WebSDK. Например, на нашем demo сервере потоки с Ваших камер нормально играют по WebRTC, с учетом использования TCP транспорта:

При использовании UDP транспорта мы наблюдаем значительный рост NACK:

Это говорит о том, что канал до камеры недостаточно хорош, чтобы передавать качественную 1080p картинку с битрейтом выше 3 Мбит/с
В связи с этим рекомендуем:
1. Использовать более мощный инстанс
2. Использовать более свежую сборку WCS (например, 5.2.971 или выше, т.к. по сравнению с Вашей сборкой были фиксы в том числе по проигрыванию RTSP потоков)
3. Использовать TCP транспорт
В этом случае по WebRTC поток играет плавно.
Когда Вы открываете страницу плеера по HTTP, WebRTC не используется: работает либо технология MSE, либо, на iOS Safari, WSPlayer. В обоих случаях, медиапоток идет по TCP через Websocket соединение, что и компенсирует потери. Однако в случае WSPlayer работает принудительный транскодинг в MPV, что дает нагрузку на сервер и в свою очередь приводит к артефактам при проигрывании либо вообще невозможности проиграть поток.

 

[alexosh]

Спасибо за проверку!

А каким образом использовать TCP соединение? Где это можно настраивать на сервере или клиенте? Немного не понятно, как внашем случае это делать.

У нас сейчас просто в embed player на сайте, в iframe передается вот такой параметр: mediaProviders=WebRTC,Flash,MSE,WSPlayer


> Когда Вы открываете страницу плеера по HTTP, WebRTC не используется: работает либо технология MSE, либо, на iOS Safari,

Сборку обновили. Не уж то уж для работы пары живых клиентов не хватает пусть даже небольшого сервера.

Так может и использовать MSE если WebRTC хуже работает? Все же отлично работает когда HTTP страница, почему надо использовать WebRTC?

 

[Max]

А каким образом использовать TCP соединение? Где это можно настраивать на сервере или клиенте? Немного не понятно, как внашем случае это делать.

TCP на клиенте
TCP на сервере

Код embed player открыт. Если менять на клиенте, надо внести в него необходимые изменения.

 

[alexosh]

TCP на клиенте
TCP на сервере

Если мы используем embed Player (через iframe) он ведь по умолчанию использует TCP для WebRTC или нет? Или для него как-то тоже можно настраивается через параметр?

Вообще получается в нашей конфигурации по умолчанию идет через TCP, если мы нечего на сервер или на клиенте не настраивали?

 

[Max]

Так может и использовать MSE если WebRTC хуже работает? Все же отлично работает когда HTTP страница, почему надо использовать WebRTC?

Можете MSE, если устраивает задержка и транскодинг звука на стороне сервера в AAC.

"mse" | Can I use... Support tables for HTML5, CSS3, etc

caniuse.com

Однако WebRTC TCP работает более стабильно и предсказуемо в нашем случае, по сравнению с MSE.

Если мы используем embed Player (через iframe) он ведь по умолчанию использует TCP для WebRTC или нет?

По-умолчанию всегда идет через UDP.
В embed Player нет специального параметра для указания протокола. Надо прописывать прямо в код.

https://demo.flashphoner.com/shared/examples/demo/streaming/embed_player/player.js

Т.е. вам надо открыть файл player.js и внести туда необходимые изменения, чтобы заработал TCP.

 

[alexosh]

Т.е. вам надо открыть файл player.js и внести туда необходимые изменения, чтобы заработал TCP.

Добавили в session.createStream options параметр `transport: "TCP"`

Стрим перестал открываться (в плеере пишет FAILED Failed by ICE timeout).

На сервере тоже добавили опцию `ice_tcp_transport=true` она вообще необходима, или можно только на клиенте определять по каком протоколу будет обмен с сервером? (т.е. елси TCP то TCP, если нет то клиент будет использовать UPD)?

Где нам дальше посмотреть почему стрим FAILED Failed by ICE timeout?

 

[alexosh]

Также в документации написано

> Настройка на стороне сервера включает использование WebRTC через TCP по умолчанию для всех клиентов.

Т.е. нам не обязательно трогать клиентов в этом случае? Ну в общем когда мы включили эту настройку на сервере, стримы на клиентах не идут.

Что нам посмотреть? Если что, сервер все тот же.

 

[alexosh]

Подняли рекомендованный инстанс m5.xlarge - тоже самое по задержке на самом демо-сайте, такие же замирания.

1) Все-таки поясните для включения WebRTC по TCP достаточно на сервере прописать `ice_tcp_transport=true` или нужно все таки что-то на клиентах менять? На новом инстансе просто добавили эту настройку и клиенты не открывают стрим с ошибкой: FAILED Failed by ICE timeout


2) У нас есть подозрения на качество канала до камер. Каким образом это можно проверить?

Но вы говорите у вас нормально показывает. У нас на m5.xlarge те же самые замирания.

 

[Max]

Убедитесь что TCP порты 31000-32000 открыты на вашем сервере.
FAILED Failed by ICE timeout - указывает на то, что порты могут быть закрыты.

Проверка:

1. Запустите любое приложение на порту, например 31001
2. Выполните
telnet host 31001

 

[alexosh]

Спасибо! Все поехало даже на iOS.
30000-33000 в стандартной Security Group были открыты только для UDP. Она создавалась у нас может неск месяцев назад. Так что если у вас новых версия не сделано, добавьте.

Еще может быть следует добавить в стандартные правила 80-й порт, чтобы делать сертификаты через certbot, по крайней мере, в документации по сертификатом этого нет, а для людей будет неожиданностью что ничего не работает, там уже на AWS есть странный отзыв какого-то пользователя по поводу проблем с установкой сертификатов.

Еще вопрос все же по камерам и webRTC: по TCP проблем с замерзаниями не наблюдается. Почему могут идти задержки через UDP? Может быть связано с тем что камеры подключены по wi-fi, какие вообще рекомендации по подключению ip-камер, где-то можно об этом прочитать?

 

[Max]

30000-33000 в стандартной Security Group были открыты только для UDP. Она создавалась у нас может неск месяцев назад. Так что если у вас новых версия не сделано, добавьте.

В security group по умолчанию мы добавляем необходимый минимум портов, в целях безопасности. Кроме того, далеко не у всех клиентов такие толстые потоки с высоким битрейтом, как в Вашем случае.

Еще может быть следует добавить в стандартные правила 80-й порт, чтобы делать сертификаты через certbot, по крайней мере, в документации по сертификатом этого нет, а для людей будет неожиданностью что ничего не работает, там уже на AWS есть странный отзыв какого-то пользователя по поводу проблем с установкой сертификатов.

По умолчанию, WCS не слушает порты 80 и 443. При выкладывании образа в Marketplace это может быть расценено как уязвимость. Добавим замечание об открытии порта в документацию по сертификатам.
У клиента, который оставил отзыв, к сожалению, совсем не было навыков администрирования.

Еще вопрос все же по камерам и webRTC: по TCP проблем с замерзаниями не наблюдается. Почему могут идти задержки через UDP? Может быть связано с тем что камеры подключены по wi-fi, какие вообще рекомендации по подключению ip-камер, где-то можно об этом прочитать?

UDP как транспортный протокол дает меньшие задержки, по сравнению с TCP (и поэтому является предпочтительным транспортом для WebRTC)& но достигается это за счет того, что UDP пакеты отправляются без подтверждения их доставки. Это приводит к тому, что UDP транспорт более чувствителен к потерям пакетов. Потери и дают задержки и артефакты при проигрывании потока.
Причем в Вашем случае это зависит не только от канала между камерами и WCS сервером, но и между WCS сервером и зрителем.
Рекомендации будут стандартными:
1. Пропускная способность на участке камера-сервер должна быть достаточной для прохождения потока со всех камер. Например, если камера отдает поток 1080p с битрейтом 3 Мбит/с, значит, именно столько поток и займет в канале. У Ваших камер битрейт скачет и выше, поэтому рекомендуем закладывать 10 Мбит/с на одну камеру + 20% запаса к сумме всех камер. Т.е. на 10 камер потребуется канал минимум 120 Мбит/с
2. Пропускная способность на участке сервер-зритель должна быть достаточной для прохождения потока со всех камер, которые будет смотреть одновременно один зритель, также 10 Мбит/с на одну камеру.
3. На обоих участках канала потерь не должно быть.
При этих условиях потоки будут нормально играть по UDP. Если есть потери на канале, рекомендуется использовать TCP. Если не удается выделить нужную емкость канала, тогда только снижать битрейт и, возможно, разрешение.

 

[alexosh]

Спасибо.

Т.е. при использовании TCP требования повышаются к чему? К серверу? В чем минус использования всегда TCP вместо UDP?
В нашем случае что-то UDP совсем плохо, то вообще не может подключиться, то сплошной фриз, как-то можно более или менее четко диагностировать где это горлышко, что не проходит?



Еще такие вопросы:

#1

На клиенте можно как-то программного диагностировать качество и состояние потока в плеере? Знать когда поток начал показываться, или когда он преравался, затормозил, есть вообще такая возможность? Какие-то события через web sdk api или анализ состояния трафика, в общем хотелось бы понять существует ли какой-то способ.

#2

Если мы хотим снизить потенциальную нагрузку на сервер, какие у нас есть варианты, где об этом нужно почитать? Допустим на сервер с камеры пусть приходит толстый поток, который мы будем может быть ретранслировать на youtube, а клиентам отдавать что-то более простое с более низким битрейтом. Так же возможно отдавать каким-то клиентом с задежкой (5-10 секунд не реал тайм).

 

[Max]

Т.е. при использовании TCP требования повышаются к чему? К серверу? В чем минус использования всегда TCP вместо UDP?

TCP дает задержку. Если WebRTC по UDP дает задержку меньше 1 секунды при трансляции, то TCP может давать до 3 секунд.

В нашем случае что-то UDP совсем плохо, то вообще не может подключиться, то сплошной фриз, как-то можно более или менее четко диагностировать где это горлышко, что не проходит?

Проверьте два участка канала - между камерой и сервером и между играющим клиентом и сервером:
1. С одной стороны поднимаем iperf сервер (порт должен быть открыт)

iperf3 -s -p 5201

2. С другой стороны тестируем исходящий

iperf3 -c server_address -p 5201 -t 60

и входящий канал

iperf3 -c server_address -p 5201 -t 60 -R

Такой тест покажет и пропускную способность канала, и процент потерь.

На клиенте можно как-то программного диагностировать качество и состояние потока в плеере? Знать когда поток начал показываться, или когда он преравался, затормозил, есть вообще такая возможность? Какие-то события через web sdk api или анализ состояния трафика, в общем хотелось бы понять существует ли какой-то способ.

Можно настроить контроль качества канала по видео битрейту. В этом случае можно переподключать подписчика к потоку, если качество канала устойчиво снизилось в BAD, или заказывать транскодинг потока к более низком разрешению и битрейту.
Если поток прервался вообще, то клиент получит событие STREAM_STATUS.FAILED, в этом случае можно возобновить воспроизведение, см пример.

Если мы хотим снизить потенциальную нагрузку на сервер, какие у нас есть варианты, где об этом нужно почитать? Допустим на сервер с камеры пусть приходит толстый поток, который мы будем может быть ретранслировать на youtube, а клиентам отдавать что-то более простое с более низким битрейтом. Так же возможно отдавать каким-то клиентом с задежкой (5-10 секунд не реал тайм).

Вы можете снизить нагрузку на канал зрителя, если будете транскодировать поток на сервере к меньшему разрешению/битрейту, например

session.createStream({
     name:"stream1",
     constraints: {
           audio: true,
           video: {
                 width: 640,
                 height: 360,
                 bitrate: 500
           }
     }
     ...
}).play();

Подробнее о транскодинге можно прочитать здесь.
Обратите внимание, что транскодинг требует больше ресурсов сервера (1 CPU на 2 потока, кодируемых в 720p, или на 3 потока, кодируемых в 480p). То есть требования к серверу зависят от количества зрителей, одновременно играющих потоки в различных разрешениях.

 

[alexosh]

Можно настроить контроль качества канала по видео битрейту.

Спасибо за подробный ответ, будем пробовать!

 

[alexosh]

Добрый день!

Такой вопрос.

Для начала трансляции создается сессия `Flashphoner.createSession` затем на сессии создается стрим `session.createStream`


Вопрос: необходимо ли для каждого стрима на странице создавать свою сессию? Вроде бы сессия подразумевает множественные потоки. Но в текущий момент, когда пытаемся создать стрим с точно такими же опциями на уже существующей сессии в консоль (бесконечно) валятся ошибки:

Uncaught (in promise) TypeError: Cannot set property 'muted' of null

Новый поток не показывается, а старый замирает. Если создавать новую сессию и то и первый и второй поток играет.

В чем тут проблема? Вообще хотелось бы понять взаимотношение сессиий и потоков, как их правильно использовать, т.е. когда создавать новую сессию.