Настройки IP-input

[Oll]

Задача:
с точки А(комп.+програмный кодер) в точку В(форвард ТА FDOnAir ) передать сигнал по интернету. А и В получают интернет от разных провайдеров и не находятса в локальной сети .
Вопросы:
1. програмы SLStreamer Lite,SLStreamer Pro входят в комплекта продукта форвард ТА ?.
2. Для приема потока в точке В(FDOnAir ) нужен статичесий внешний IP адрес?
3.2. Для передачи потока из точки А нужен статичесий внешний IP адрес?

[Даниленко Сергей]

Рекомендовали бы использовать в этом месте передачу через HTTP Live Streaming. Это передача именно через интернет.
Документация:
http://www.softlab-nsk.com/rus/forward/ ... ts_hls.pdf

програмы SLStreamer Lite,SLStreamer Pro входят в комплекта продукта форвард ТА ?.

В базовом ПО Форвард ТА этих компонентов нет. Их можно доставить через плагины, например, IPCamera, IPOut.

[Oll]

Для использования данных программ, обязательно покупать плагины IPCamera, IPOut ? Или при установки можно использовать только SLStreamer Lite,SLStreamer Pro без покупки этих плагинов с функцией IPinput, что входит в бесплатное использование комплекта Форвард ТА ?

[Даниленко Сергей]

Для того, чтобы воспользоваться бесплатной опцией приёма IP-потока на полный экран, необходимо поверх основного ПО поставить плагин IPOut.
Об этом сказано в документации:
http://www.softlab-nsk.com/rus/forward/ ... pinput.pdf

Правда там эта опция по старинке называется IPOutOption - был такой продукт когда-то в виде отдельного инсталлятора. Сейчас это IPOut и ставится он серез общий инсталлятор плагинов.

[Oll]

То есть, мне достаточно скачать и установить плагин IPOut без его покупки, и это всё что мне нужно для бесплатного использования функции IP-потока? И более ничего не покупать и не устанавливать?
И дайте еще, пожалуйста, ответ на предыдущие вопросы:
(1. Для приема потока в точке В(FDOnAir ) нужен статичесий внешний IP адрес?
2. Для передачи потока из точки А нужен статичесий внешний IP адрес?)

[Даниленко Сергей]

То есть, мне достаточно скачать и установить плагин IPOut без его покупки, и это всё что мне нужно для бесплатного использования функции IP-потока? И более ничего не покупать и не устанавливать?

Да.

И дайте еще, пожалуйста, ответ на предыдущие вопросы:
(1. Для приема потока в точке В(FDOnAir ) нужен статичесий внешний IP адрес?
2. Для передачи потока из точки А нужен статичесий внешний IP адрес?)

Статический адрес можно в точке В.
Но в описанной вами схеме (два разных интернета и нет локальной сети), скорее всего , ничего работать не будет.

[Даниленко Сергей]

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

[Oll]

Для реализации приема на стороне FDOnAir HTTP Live Streaming
нужен media server или функция ip-input в FDOnAir принимает поток непосредственно ?
У HLS согласно даташиту задержка не меньше 10с. Возможен ли прием других типов потоков RTMP , RTSP c помощью функции ip-input и нужен ли для них media server ?

[Даниленко Сергей]

Для реализации приема на стороне FDOnAir HTTP Live Streaming
нужен media server или функция ip-input в FDOnAir принимает поток непосредственно ?

Принимает поток непосредственно, медиасервер (правда не понятно о чём идёт речь?) не нужен. При организации HLS-вещания нужен веб-сервер, но он работает на передающей стороне.

У HLS согласно даташиту задержка не меньше 10с.

Да. это так. Но это единственный надёжный способ распространения сигнала через публичный интернет.

Возможен ли прием других типов потоков RTMP ,

Нет

RTSP c помощью функции ip-input

Нужен дополнительно плагин IPCamera

и нужен ли для них media server ?

Нет.

Мы поддерживаем:

UDP/RTP (unicast/multicast) - на входе/выходе
RTSP - на входе (при наличии лицензии на IPCamera)
RTMP - на вызоде
HTTP Live - на входе/выходе (могут потребоваться дополнительные лицензии для формирования выходного потока)

[TeKiLLo]

У HLS согласно даташиту задержка не меньше 10с.

Да. это так. Но это единственный надёжный способ распространения сигнала через публичный интернет.

есть еще способа. Канал интернета нужен чуток понадежней, чем при HLS. Например UDP (ucast) в сторону приемника, или UDP-прокси на вещателе.

[Даниленко Сергей]

Для TeKiLLo:

Вас не смущает вот это:

А и В получают интернет от разных провайдеров и не находятса в локальной сети .

[Игорь Таранцев]

Да, конечно, можно передавать транспортный поток с видео и звуком как обычные UDP-пакеты. И даже в некоторых случаях все будет прекрасно работать. Но мы обычно предлагаем решения, которые будут работать надежно в стандартной ситуации, именно поэтому и справшиваем про локальную сеть, одного провайдера и так далее.
Попробую описать стандартные проблемы.
1) для стабильной передачи цифрового телевидения уровень потерь пакетов, передаваемых через сеть не должен превышать 1 пакет на каждые 1000000-1000000000 пакетов.
2) обычный интернет "нормально" работает при уровне потерь 1 пакет на каждые 100-1000 пакетов.
То есть если у Вас есть рабочий интернет, Вы реально принимаете на приемнике UDP-пакеты от передатчика и Вы попытаетесь начать по нему передавать цифровое телевидение, то с вероятностью 0.01%-0.0001% телевидение у Вас заработает (оценка конечно очень грубая, но по смыслу она верна). Причем я хочу обратить внимание, что даже видя "огромный" трафик (будет приходить 99% пакетов) Вы не увидите НИ ОДНОЙ картинки на приемнике, поскольку непрерывных данных не хватит для декодирования даже одного кадра. То есть с точки зрения пользователя телевидение будет совсем не работать при полностью работающем интернете.
Здесь достаточно часто решением проблемы является использвание FEC на передающей и приемной стороне. Если потери пакетов единичные (не более 10 пакетов подряд), то телевидение может успешно заработать.

3) Следующая проблема - как заставить UDP-пакеты доходить от передатчика до приемника.
В локальной сети проблем быть не должно. Во всяком случае по умолчанию UDP-пакеты в локальной сети обязаны доходить от передатчика до приемника.
А вот в глобальной сети есть горомное количество различных фильтров, натов, файерволов и прочей антивирусной "радости", которая призвана защищать Вас он чужих атак. И по умолчанию все они настроены очень решительно - обязательно будут обрезать Ваши UDP-пакеты. То есть по умолчанию с одного компьютера на другой компьютер, не находящийся в локальной сети (хотя и обладающий "белым" IP-адресом) не дойдет НИ ОДНОГО пакета. Вы обязаны разрешить передачу UDP-пакетов по всему тракту глобальной сети от передатчика до приемника. Очевидно, что с одним провайдером можно договориться о такой маршрутизации. А вот заставить разных провайдеров обеспечить для Вас надежный и стабильный канал передачи UDP-пакетов мне представляется непосильной задачей, в чем то схожей с решением задачи перехода от одного оператора сотовой связи к другому с сохранением старого номера телефона то есть даже и закон уже принят, а по прежнему большие проблемы и стабильной работы как-то не видно. Я подчеркиваю, что речь идет о НАДЕЖНОЙ и СТАБИЛЬНОЙ передаче трафика все время, а не только в момент настройки канала. Например, если кто-то из техников одного из провайдеров забудет внести правило передачи Ваших UDP-пакетов при очередной (или аварийной) замене оборудования, то Ваш трафик остановится и найти кто именно виноват у разных провайдеров Вам будет очень трудно. Потом, конечно, все решится, но неустойку за невыдачу рекламы в эфир прийдется платить Вам, а не виноватому провайдеру. Вы, конечно, можете пытаться заложить в договор с провайдерами соответствующие штрафные санкции, но я в это совсем не верю.

HLS работает через протокол HTTP, который по умолчанию разрешен практически везде. Во всяком случае тот самый "обычный интернет" проверяется именно интернет браузером, который использует протокол HTTP. Соответственно, простой телевещатель может договариваться с провайдером только о гарантированной пропуской способности интернет-канала, что является на сегодня стандартным условием договора.

Конечно за все нужно платить. Работа через HLS предполагает регулярную потерю данных, перезачитывание пакетов и т.д. Поэтому есть обязательные БОЛЬШИЕ задержки, равные длительности нескольких кусков (файлов, на которые режется поток с цифровым телевидением). Более того, в процессе аварийного переключения провайдер может значительно снижать скорость канала (например, в два раза) на длительный срок (например, на челый час), пока не будет устранена авария. В этой ситуации HLS может переключится на чтение другого потока ("потоньше", хотя и похуже качеством). Зритель, конечно, заметит ухудшение качества, но картинка будет идти, а в случае с UDP-пакетами картинка просто остановится.

Вот в итоге и остается два "простых" варианта:
1) если Вы можете организовать локальную сеть (реальную или виртуальную) с гарантированной пропускной сопсобностью, то мы рекомендуем UDP + FEC в пределах 50-90% этой пропускной способности.
2) иначе HLS (тоже в пределах 50-90% гарантированного трафика, но желательно с двумя-тремя разными по "толщине" потоками).

[Даниленко Сергей]

Достойный псто
Надо будет в "вопрос-ответ" отложить.

[TeKiLLo]

Вот в итоге и остается два "простых" варианта:
1) если Вы можете организовать локальную сеть (реальную или виртуальную) с гарантированной пропускной сопсобностью, то мы рекомендуем UDP + FEC в пределах 50-90% этой пропускной способности.
2) иначе HLS (тоже в пределах 50-90% гарантированного трафика, но желательно с двумя-тремя разными по "толщине" потоками).

Класс! жаль нет смайлика с поднятым вверх большим пальцем!

Сам видел, как работает HLS - он до сих пор вещает три потока: 0.5Mbit/s, 1Mbit/s, 3Mbit/s. Но задержка есть и как раз в районе длительности одного сегментного файла - 10 секунд. А для вещания, например, новостей, которые должны начинаться в 18-00 - это уже проблема.

А UDP-proxy - который кстати тоже http и TCP вы обошли. я как раз про него и говорил, что нужен канал понадежнее.

[vd]

А для вещания, например, новостей, которые должны начинаться в 18-00 - это уже проблема.

Такая ли уж это проблема? Уверены, что все зрители сидят с секундомером в руках и отсчитывают, насколько позже от 18:00 (да еще и точные часы надо иметь) в эфире пошли новости? Не сильно ошибусь, если предположу, что и задержку даже в минуту 99.9% зрителей не заметят вообще.