Jump to content
Калькуляторы

Доставка multicast через интернет

Всех приветствую!

 

Периодически тут всплывает тема касательно передачи IPTV/multicast через публичный интернет, в том числе для резервирования.

 

Предлагаем протестировать новый софт для этого. Он гарантированно доставляет сигнал до вашего узла при количестве потерь в канале до 20% и RTT до 600 мс. Данный софт ставится на вашем сервере, получает потоки со станции, и далее ретранслирует их мультикастом или юникастом по вашей сети. При этом пережатие, снижение битрейта и прочие ухудшающие качество вещи не происходят.

 

В настоящее время таким образом можем доставить сигнал с нескольких спутников в любую точку мира, при наличии у вас прямого лицензионного договора - наземный сигнал телеканалов от нескольких вещателей, а также сигнал Home-IPTV - более 200 каналов, если у вас есть или планируется с ними договор. В настоящее время протестирован стабильный прием в нескольких городах России, а также в Германии, Англии и США.

 

Особенно удобно использовать эту систему в связке с astra - просто прописываете резервный источник в виде http-ссылки на localhost для каждого канала - в результате получаем всегда стабильный прием канала, вне зависимости от наличия сигнала на спутнике. При этом интернет-полоса расходуется только при реальной потребности - когда основной источник канала со спутника недоступен. Такую же схему можно использовать и с Home-IPTV - если пропадает их сигнал с основного канала (мегафон), можно получить его через любой другой интернет, хоть домашний PON от Ростелекома :)

 

Также возможен круглосуточный прием сигнала, с передачей его напрямую в мультикаст. Это удобно, если какие-либо спутники не ловятся в вашем регионе. Если Home-IPTV раньше не мог подать сигнал в вашем городе - теперь и это возможно.

 

Требования к системе - любой linux x64, оперативки - 10 мб на канал. Скорость интернета - в зависимости от количества и типа запрошенных потоков. При желании протестировать софт, а также по всем остальным вопросам - просьба писать в личку.

Edited by vladd

Share this post


Link to post
Share on other sites

Какой latency добавляется?

2-3 секунды.

Share this post


Link to post
Share on other sites

Эт хорошо.

 

Мы уже долго ковыряемся с правильной реализацией udp push, потому что ньюансов очень много и непросто добиться действительно монотонной выдачи.

Share this post


Link to post
Share on other sites
Он гарантированно доставляет сигнал до вашего узла при количестве потерь в канале до 20% и RTT до 600 мс.
Требования к системе - любой linux x64, оперативки - 10 мб на канал.

Как то с натяжкой даже для SD.

 

Чем это всё лучше TCP с cc=hybla?

Share this post


Link to post
Share on other sites

Реально.

HD с сибири с ним идёт без стабильно, с htcp иногда затыкается, с кубиком часто затыкается.

Share this post


Link to post
Share on other sites
Требования к системе - любой linux x64, оперативки - 10 мб на канал.

Как то с натяжкой даже для SD.

 

Очень даже не с натяжкой, а наоборот много для SD - это целых 20-25 секунд буфера. Сделано с запасом для HD, бывают битрейты до 20 мбит/с.

 

Чем это всё лучше TCP с cc=hybla?

 

Тем, что пофиг на non-congestion loss. Пофиг до такой степени, что когда падают все аплинки кроме одного, трафик упирается в жуткую полку, и сайты открываются по полчаса - HD каналы продолжают спокойно идти без каких-либо затыков.

 

Это все на основе собственной эксплуатации в течение двух лет. Перегоняем 400 мбит мультикаста через дешевый, но не очень качественный канал ростелекома на 2000 км. Плюс еще несколько операторов в разные места. Теперь решили поделиться, если кому надо.

Share this post


Link to post
Share on other sites

Теперь решили поделиться, если кому надо.

так выкладывайте ее нашару, чего нычковать? или подписываете бинарники на каждого юзера?)))

Share this post


Link to post
Share on other sites

так выкладывайте ее нашару, чего нычковать? или подписываете бинарники на каждого юзера?)))

 

Смысл подписывать клиентскую часть? Это не только софт, но и куча разных потоков с разных мест, как и было написано в оригинальном сообщении. Весьма неплохой резерв, особенно в свете последних проблем с разными спутниками. Cинтеpрa например за такое хочет на порядки большую кучу денег. И latency там не 2-3 секунды, а 20-30.

Share this post


Link to post
Share on other sites

это услуга не софт? тогда в оригинальном сообщении вам надо слишком много слов зачеркнуть

Share this post


Link to post
Share on other sites

это услуга не софт?

Услуга на основе софта. Просто потоки можно много где взять по http, но работать будут не всегда стабильно.

Share this post


Link to post
Share on other sites

Не, самое очевидное решение, которое мы будем делать — это забить болт на TCP и гнать по UDP с лимитированным окном ретрансмита.

Share this post


Link to post
Share on other sites

Я как то баловался, заворачивал мультик в udp на netgraph и гнал, из сибири в сибирь через москву, нормально шло.

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

 

Учитывая описание, очень смахивает на RTCP + RTP.

Если взглянуть на проблему шире, то RTCP + RTP это в принципе тот же TCP только со специфичным CC.

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

В данном случае заранее известно что полоса достаточна и можно долго мозг не ломать ограничивая скорость отправки, по сути взять htcp и выкинуть снижение скорости из него.

Share this post


Link to post
Share on other sites

> RTCP + RTP это в принципе тот же TCP только со специфичным CC.

 

и с правом на «сдаться и не просить перепослать устаревший пакет»

Share this post


Link to post
Share on other sites

Это оч редко актуально, когда где то некоторый пакет с определённым содержимым ну никак не проходит. Такое упоминалось для глючащих медиаконвертеров.

Но в шапке было слово "гарантированно".

А если не гарантированно - можно и обычным udp, разница не велика будет.

 

Для клиента модифицированный СС удобен тем, что на клиенте практически ничего трогать не нужно, только убедится что некоторые стандартные настройки tcp включены/настроены, софт дополнительный не нужен, модификации настроек в софте тоже не нужны.

Share this post


Link to post
Share on other sites

Это оч редко актуально, когда где то некоторый пакет с определённым содержимым ну никак не проходит. Такое упоминалось для глючащих медиаконвертеров.

 

Вы реально думаете, что между AS-ками стоят медиаконвертеры? Нет, конечно где-то остались мелкие провайдеры, подключаешиеся гигом в супер-пупер-маршрутизатор cisco 3550 без оптических портов (хотя все адекватные люди давно отказались от медика для подключения к аплинку), но на транзите вы такой порнографии не найдёте.

 

Ну и вообще, ситуацию "некоторый пакет с определённым содержимым ну никак не проходит" можно описать как 100% потерю, а в посте речь идёт о 20% и очевидно, что говорится о потерях независимо от их содержимого, а не об экзотических медиках, дропающих определённую последовательность байт

 

Суть идеи понятна и как оно работает тоже понятно. Вопрос лишь в том, что это не софт, а услуга, что сразу же добавляет огромное кол-во бизнес-рисков. И при том услуга довольно уникальая, это не просто взять и поменять интернет-аплинка

Share this post


Link to post
Share on other sites

Список каналов и условия - в личку плиз. Очень интересно.

Share this post


Link to post
Share on other sites

Список каналов и условия - в личку плиз. Очень интересно.

Странная они контора. Сами представится не желают, никаких сведений о себе не предоставляют, но затребуют всю информацию о вас. Без этого коммерческое не дадут.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this