Общие вопросы про поддержку ios, galaxy, задержку и возможность записи

[inpost]

Здравствуйте.
Я бы хотел узнать о возможностях Flashphoner прежде, чем приступить к его тестированию, так как я не уверен подходит ли он мне. Тех.поддержка по почте направила меня написать эти вопросы на форуме. Я извиняюсь, если на ответы на некоторые вопросы я мог найти на форуме или в документации.

Я программист, сейчас я пользуюсь nginx-rtmp для видео-чата на сайте знакомств, захват видео встроен на сайте из флэш-плеера , сервер принимает видео, может сохранять записи видео и раздаёт. Одно маленькое дополнение (в вопросе понадобится) - на сайте нужен захват только видео, без аудио. Как можно понимать из рассказа, это всё старый век, хотелось бы перейти на более свежий продукт с большим функционалом и лучшей поддержкой (ios, android, low latency).
Я думал своими силами связать webrtc-rtmp и т.д, но не вышло, поэтому решил приобрести готовый продукт и появились следующие вопросы. Уточню, меня интересует именно трансляции через сервер (посредник) user-server-user , чтобы можно было всегда контроллировать и следить за цензурой на сайте.

1) Я читал, что в ios11 уже встроена поддержка webrtc захвата камеры, это значит, что теперь из браузера без необходимости устанавливать приложения можно транслировать видео с камеры (для чата). На сколько эта информация актуальна по отношению к Вашему продукту? Я видел на habrahabr, что Вы писали о возможности захвата, является ли информация актуальной и рабочей? Какая в таком случае примерная задержка видео? Получается и ios и andoid поддерживают webrtc захват камеры, значит сейчас можно с любого современного и обновленного устройства стримить камеру и пользоваться видео-чатом на сайте без необходимости приложений?

2) HLS для отдачи видео пользователю создаёт большие задержки, хотелось бы более быстрый функционал вроде websockets, mpeg-dash. Предположим, что посетитель с PC версии запустил трансляцию, пользователи с iphone, ipad и Galaxy решили посмотреть эту трансляцию. Какая прогнозируемая задержка будет?

3) Вопрос по функционалу. Я могу в любой момент времени включать/выключать запись на стороне сервера? Допустим в какой-то момент происходит подозрение, что пользователь Х крутит записанный ролик и для анализа мне надо активировать "запись" конкретно для данного пользователя, и когда в следующий раз данный пользователь запустит трансляцию, его видео будет сохранено у нас на сервере. Уточню, в nginx-rtmp это можно было сделать вызвав одну команду:
http://localhost:81/control/record/'.$action.'?app=live&name='.$streamname.'&rec=rec1
В action я передавал start или stop.

4) Плеер для трансляции с сервера видео входит в стоимость услуг?

5) Работая через flash захват камеры я стал замечать, порой, уменьшение FPS и заниженное качество камеры, если транслировать через OBS, xSplit, то качество значительно выше идёт. Будет ли занижение качества, если я буду пользоваться вашим плеером для захвата камеры, или нет?

6) Так же есть вопрос, можно ли организовать на сервере декодирование видео под разные разрешения и 720p и 480p, к примеру, для разных пользователей? И ещё, сюда же, в плеере есть возможность включить авто-переключение качества видео на случай, если тот же 720p будет лагать?

7) Последний вопрос, но не менее важный. Сервер располагается в США, а посетитель может быть один из Европы, а второй из России. Пользуясь nginx-rtmp и трасляцией из флэша я даже не замечал в этом проблем, возможно просто задержка была на пол секунды/секунду дольше, то есть работает без проблем. Уточните, что и с Вашим продуктом так же будет работать без сбоев при условии стабильного соединения у пользователей (это я понимаю).

Спасибо.

 

[Max]

Здравствуйте

Я читал, что в ios11 уже встроена поддержка webrtc захвата камеры, это значит, что теперь из браузера без необходимости устанавливать приложения можно транслировать видео с камеры (для чата). На сколько эта информация актуальна по отношению к Вашему продукту?

Актуально.

Я видел на habrahabr, что Вы писали о возможности захвата, является ли информация актуальной и рабочей? Какая в таком случае примерная задержка видео?

200 - 500 миллисекунд

Получается и ios и andoid поддерживают webrtc захват камеры, значит сейчас можно с любого современного и обновленного устройства стримить камеру и пользоваться видео-чатом на сайте без необходимости приложений?

Да, верно.

HLS для отдачи видео пользователю создаёт большие задержки, хотелось бы более быстрый функционал вроде websockets, mpeg-dash. Предположим, что посетитель с PC версии запустил трансляцию, пользователи с iphone, ipad и Galaxy решили посмотреть эту трансляцию. Какая прогнозируемая задержка будет?

Websocket работает через TCP. Поэтому задержка будет ниже чем HLS, но все равно далекой от реалтайма. Будет 3-5 секунд.
Websocket player есть смысл использовать только на iOS 9, 10, где нет поддержки WebRTC как в iOS 11.
MPEG DASH тоже врядли будет быстрее HLS, т.к. там тот же принцип сегментирования и загрузки по HTTP.

Предположим, что посетитель с PC версии запустил трансляцию, пользователи с iphone, ipad и Galaxy решили посмотреть эту трансляцию. Какая прогнозируемая задержка будет?

Будут те же 200-500 ms в Safari 11 под iphone, ipad
Будут те же 200-500 ms в Chrome под Galaxy
Будет задержка 3-5 секунд при использовании Websocket Player в Safari 9. 10 под iPhone iPad и более высокий расход батареи за счет декодирования на Javascript

Вопрос по функционалу. Я могу в любой момент времени включать/выключать запись на стороне сервера?

Запись пока можно включить только в начале трансляции.
На стороне клиента выглядит так:

session.createSteram({record:true}).publish();

Можно также форсировать запись трансляции для конкретного пользователя на стороне сервера, передав в REST hooks этот же флаг record=true.
Но сама запись начентся только тогда, когда пользователь начнет трансляцию. Нельзя подключиться к потоку в середине трансляции и начать его записывать.

Плеер для трансляции с сервера видео входит в стоимость услуг?

Да, лицензия на WCS сервер покрывает Web SDK, iOS SDK, Android SDK и все идущие с ними примеры, в том числе и пример плеера. Вы можете также кастомизировать плеер на Javascript. Код всех примеров есть на гитхабе: https://github.com/flashphoner/flashphoner_client

Работая через flash захват камеры я стал замечать, порой, уменьшение FPS и заниженное качество камеры, если транслировать через OBS, xSplit, то качество значительно выше идёт. Будет ли занижение качества, если я буду пользоваться вашим плеером для захвата камеры, или нет?

Поправка. Вы будете пользоваться нашим Web SDK для захвата с камеры.
Наше SDK использует технологи браузера WebRTC.
WebRTC может занижать FPS, разрешение и битрейт, если видит, что мощности устройства для кодирования видео недостаточно либо если интернет-полоса до сервера нестабильна. В этом случае без занижения качества не получится таргетировать задержку. Поэтому да, возможно занижение качества, но для отдельных подключений.

Так же есть вопрос, можно ли организовать на сервере декодирование видео под разные разрешения и 720p и 480p, к примеру, для разных пользователей?

Да, можно. Достаточно при подключении указать разрешение, например width:640, height:480, в этом случае будет заведена группа транскодинга и пользователь будет смотреть поток из этой группы. Следующий пользователь, который задал тоже самое разрешение 640x480 попадет в эту же группу.

И ещё, сюда же, в плеере есть возможность включить авто-переключение качества видео на случай, если тот же 720p будет лагать?

Плеер получает нотификации о проценте потерь на стриме. Разработчик обрабатывает эти нотификации и при превышении порога может переключить плеер на другой поток с более низким разрешением. Автоматически это не работает.

Последний вопрос, но не менее важный. Сервер располагается в США, а посетитель может быть один из Европы, а второй из России. Пользуясь nginx-rtmp и трасляцией из флэша я даже не замечал в этом проблем, возможно просто задержка была на пол секунды/секунду дольше, то есть работает без проблем. Уточните, что и с Вашим продуктом так же будет работать без сбоев при условии стабильного соединения у пользователей (это я понимаю).

Соединение должно быть не только стабильным, но и вмещать в себя поток. Например, до серверов в США иногда реальная скорость может падать до 2 Mbps, несмотря на то, что локальный провайдер дает тариф 50 Mbps. В этом случае поток 720p уже не пролезет в полосу и будет автоматически ужиматься по разрешениям и FPS.
В случае работы NGINX RTMP это будет компенсировано увеличением задержки.
В случае WebRTC это будет компенсировано понижением разрешения и/или FPS на стороне публикующего.
Наш продукт также поддерживает RTMP, т.е. при желании можно будет переключиться на RTMP соединение и компенсировать просадки сети задержкой.

 

[inpost]

Спасибо за ответы, один вопрос остался не ясен по поводу сохранения на уровне сервера записи трансляции.
Итак, предположим я хочу сохранить запись от пользователя Х на сервере. Значит на стороне клиента в момент начала трансляции указать "record:true"? Если трансляция идёт, но мне надо запись организовать, значит я посылаю запрос к клиенту, чтобы он остановил трансляцию и вновь запустил с параметрами "record:true"?

Для двустороннего чата необходимо будет разместить 2 плеера.
1) Один будет отвечать за трансляцию на сервер. В окне отображать видео, которое транслируется сейчас на сервер.
2) Второй будет для приёма потока другого пользователя.
Все верно?

 

[Max]

Если трансляция идёт, но мне надо запись организовать, значит я посылаю запрос к клиенту, чтобы он остановил трансляцию и вновь запустил с параметрами "record:true"?

Да.

Для двустороннего чата необходимо будет разместить 2 плеера.
1) Один будет отвечать за трансляцию на сервер. В окне отображать видео, которое транслируется сейчас на сервер.
2) Второй будет для приёма потока другого пользователя.
Все верно?

В общем верно.
Неверно называть это плеерами.
Это работает так. Вы размещаете на странице два HTML <div> элемента.

<div id="streamer" style="width:640;height:480"></div>
<div id="player" style="width:640;height:480"></div>

Первый элемент будет показывать видео, захваченное с камеры, второй видео другого пользователя.
Далее публикуете поток на сервер:

session.createStream({display:"streamer",name:"stream1"}).publish();

Далее играете второй поток с сервера:

session.createStream({display:"player",name:"stream2"}).play();

Таким образом, вы используете не два разных плеера, а одно API, которое вставляет видео в ваши div-элементы.
Пример Two Way Streaming здесь:
https://wcs5-eu.flashphoner.com/cli...ming/two_way_streaming/two_way_streaming.html
Документация по Two Way Streaming:
https://flashphoner.com/vstraivaem-videotranslyaciyu-s-veb-kam/?lang=ru