[SmokerMan]

А есть смысл в тазах? Вроде же есть приёмники нормальные?

Например ? Что модет быть дешевле ПК с astra с парой тройкой карт dvb s dvb t ?

Ну я собственно не утверждаю, а спрашиваю... приемники на 4isp стоят недорого, есть ли смысл заморачиваться с PC и возможными глюками?

[uk2558]

А есть смысл в тазах? Вроде же есть приёмники нормальные?

Например ? Что модет быть дешевле ПК с astra с парой тройкой карт dvb s dvb t ?

Ну я собственно не утверждаю, а спрашиваю... приемники на 4isp стоят недорого, есть ли смысл заморачиваться с PC и возможными глюками?

С Astra как раз глюков и нет, если использовать хорошие карты, которые, впрочем, не дорого стоят. А вот, например, с профессиональной системой EMR глюков как раз и хватает и стоимость её далеко за 200К.

Изменено 6 декабря, 2013 пользователем uk2558

[SmokerMan]

С Astra как раз глюков и нет, если использовать хорошие карты, которые, впрочем, не дорого стоят. А вот, например, с профессиональной системой EMR глюков как раз и хватает и стоимость её далеко за 200К.

А вот это не оно? http://shop.nag.ru/catalog/09663.Golovnye-stantsii-tsifrovye-PBI/09636.Priemniki-DCH/07396.DCH-5100P-44T2

[danilbal]

Тут каждый для себя выбирает:

кому-то удобней PBI, глюки которой тут тоже на 100 страниц почти расписаны и тема о них всегда в топе...

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

а кто побогаче - берут appertv вовсе:) там глюков совсем немного:)

[Ivan_83]

Преувеличивать сложность первоначальной настройки тазика линукс+астра не стоит.

Убунта сервер ставится аналогично венде, по сложности.

Отключить рп фильтер в сисцтл - просто.

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

Поставить астру - аналогично.

Настройка - просканить утилитой спутнег и вбить полученное в файл. Там уже автоконфигуратор с вебмордй почти доделали, скоро совсем для блондинок станет.

[uk2558]

Преувеличивать сложность первоначальной настройки тазика линукс+астра не стоит.

Убунта сервер ставится аналогично венде, по сложности.

Отключить рп фильтер в сисцтл - просто.

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

Поставить астру - аналогично.

Настройка - просканить утилитой спутнег и вбить полученное в файл. Там уже автоконфигуратор с вебмордй почти доделали, скоро совсем для блондинок станет.

Подскажите, зачем отключать RP_Filter ?

[Ivan_83]

От него никакой пользы, только зло. Особенно с мультикастом.

[sherwood]

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

наверное у всех по разному, но компания в которой я работаю не предоставляет iptv и не собирается, считает это отмирающим сервисом (у трех наших конкурентов это есть, но как бы не испытываем оттока абонентов или отсутствие роста абонент базы), потому как с ростом скорости в сети стали доступны сервисы лучше чем это iptv, которые например пишут в запись все каналы, а это уже не мало важно, потому как не всегда можно подстроится под время в которое например транслируют футбол. По месту жительства подключен к двум провайдерам у которых есть iptv, но его не использую, стоит HD триколор и пользуюсь kartina.tv

[disappointed]

считает это отмирающим сервисом

Помните как быстро мобилы с смс вытеснили пейджинг, за 2 года завалили этот бизнес в нерентабельность.

 

Интернет позволяет потреблять видеоконтент безо всяких особых проблем уже лет 5,

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

(ну или как телефон заменил телеграф).

 

А что я вижу в статистике, 12-15% из всех отключений идёт по причине "Конкурент предложил инет+аналоговое тв".

Из года в год вижу. Есть объяснение такой живучести этого отмирающего сервиса?

[sherwood]

Интернет позволяет потреблять видеоконтент безо всяких особых проблем уже лет 5

 

хорошо живете, у нас только второй год пошел как стали хорошие без лимитные тарифы.

 

А что я вижу в статистике, 12-15% из всех отключений идёт по причине "Конкурент предложил инет+аналоговое тв".

Из года в год вижу. Есть объяснение такой живучести этого отмирающего сервиса?

 

Пото что, мало еще народу кто может себе позволить хороший HD телик, думаю время придет. У нас еще и кабельным ТВ, люди занимаются и абонентская база у них есть и тарифы по 400р. Правильно Вы заметили, что примерно 10% нуждаются в iptv, так стоит ли игра свеч? Для меня важна не зависимость от времени, пришел вечером с работы и посмотрел интересующую передачу которая была днем, и нет проблем,а то у оператора света нет на промежуточной точки, то картинка распадается из-за кривых рук админа или оборудования, то кабель тракторист порвал и т.д., включил триколор и наслаждаешься контентом. Вообщем как написано при входе в Бухенвальд - Каждому свое.

[uk2558]

Я тоже пытаюсь убедить руководство в бесполезности IP-TV. DVB-C лучше, да и телеки у народа уже в большом количестве с ресивером DVB-C. Если и нет, то приставка на DVB-C стоит намного дешевле, чем для IP-TV. И заморочек с СПД меньше, нежели со всей этой multicast ready шнягой. И траблшутинг в разы легче на DVB-C. Но.... "эффективные" манагеры "свистят" про IP-TV.

[danilbal]

Меньше заморочек с DVB-C?

Вот с этим утверждением я бы поспорил:)

1 - удваивается количество оборудования: кроме коммутаторов езернета в ящике добавляется еще и оптический приемник.

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

3 - опять-таки дополнительные кабели, как точки отказа и как дополнительные затраты: коаксиал тупо дороже витухи, как на него не смотри.

4 - специфика коаксиала тоже присутствует: начиная от необходимости проверять параметры раз в полгода и "подтягивать" разъемы и заканчивая вдруг "взглючившим" абонентским оборудованием, которое начинает в линию гадить.

 

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

 

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

В отдаленной перспективе (наверное лет этак 10) - достаточно большая часть телеприемников будет уметь ОТТ и прочие ютубы, с подписками онлайн на что хочешь (скорей всего и что-то типа нетфликса подтянется) и IPTV в том виде как есть сейчас наверное станет неактуальным.

Менее требовательным пользователям ("бабулькам") - останется достаточно двух мультиплексов от РТРС - все топовые каналы там уже есть и без дополнительных денег. И ОТТ и IPTV им не понадобиться в большинстве случаев.

Но! За этот десяток лет есть реальный шанс хорошенько этак подрастерять абонентов, для которых услуга нужна сейчас.

[SmokerMan]

Я тоже пытаюсь убедить руководство в бесполезности IP-TV. DVB-C лучше, да и телеки у народа уже в большом количестве с ресивером DVB-C. Если и нет, то приставка на DVB-C стоит намного дешевле, чем для IP-TV. И заморочек с СПД меньше, нежели со всей этой multicast ready шнягой. И траблшутинг в разы легче на DVB-C. Но.... "эффективные" манагеры "свистят" про IP-TV.

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

[uk2558]

Меньше заморочек с DVB-C?

Вот с этим утверждением я бы поспорил:)

1 - удваивается количество оборудования: кроме коммутаторов езернета в ящике добавляется еще и оптический приемник.

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

3 - опять-таки дополнительные кабели, как точки отказа и как дополнительные затраты: коаксиал тупо дороже витухи, как на него не смотри.

4 - специфика коаксиала тоже присутствует: начиная от необходимости проверять параметры раз в полгода и "подтягивать" разъемы и заканчивая вдруг "взглючившим" абонентским оборудованием, которое начинает в линию гадить.

1 - Не проблема, место в шкафах есть.

2 - Можно поставить железку, купленную у китайцев, которая будет по SNMP отдавать уровни с конвертера в шкафу.

3 - Топология с последовательным подключением нивелирует разницу в стоимости. Насчет точек отказа - иголки и в витую пару втыкают.

4 - Для проверки нужен линейный персонал, монтажник, техник. Дешевле, чем админа содержать.

 

Я тоже пытаюсь убедить руководство в бесполезности IP-TV. DVB-C лучше, да и телеки у народа уже в большом количестве с ресивером DVB-C. Если и нет, то приставка на DVB-C стоит намного дешевле, чем для IP-TV. И заморочек с СПД меньше, нежели со всей этой multicast ready шнягой. И траблшутинг в разы легче на DVB-C. Но.... "эффективные" манагеры "свистят" про IP-TV.

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

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

[Ivan_83]

И заморочек с СПД меньше, нежели со всей этой multicast ready шнягой. И траблшутинг в разы легче на DVB-C. Но.... "эффективные" манагеры "свистят" про IP-TV.

Ерундой не занимайтесь, пускайте по хттп, с ним проблем на порядок меньше.

Для старта вообще хватит одного тазика который отдавать будет.

[uk2558]

И заморочек с СПД меньше, нежели со всей этой multicast ready шнягой. И траблшутинг в разы легче на DVB-C. Но.... "эффективные" манагеры "свистят" про IP-TV.

Ерундой не занимайтесь, пускайте по хттп, с ним проблем на порядок меньше.

Для старта вообще хватит одного тазика который отдавать будет.

Сейчас так и делаем, раздаем по http. "Эффективный мАнагер", с зарплатой как у всего тех отдела в сумме, прочитал слово multicast в интернете. Теперь поставлена задача изучить вопрос и запустить в тесте.

Изменено 12 декабря, 2013 пользователем uk2558

[EDA_SPB]

Ерундой не занимайтесь, пускайте по хттп, с ним проблем на порядок меньше.

Для старта вообще хватит одного тазика который отдавать будет.

 

Оффтопик.

Давно хотел спросить, но стеснялся.

А почему меньше проблем с http?

Интерес не праздный, хотим 60-70 каналов в сеть запустить.

Из них штук 6 HD. Пользователей около 10 тысяч за 3 года планируется.

Как представлю, какие полосы нужны будут, нехорошо становится.

Http прокси городить - доп. затраты.

Мультикаст как-то интереснее выглядит.

Все оборудование его поддерживает.

[uk2558]

Ерундой не занимайтесь, пускайте по хттп, с ним проблем на порядок меньше.

Для старта вообще хватит одного тазика который отдавать будет.

 

Оффтопик.

Давно хотел спросить, но стеснялся.

А почему меньше проблем с http?

Интерес не праздный, хотим 60-70 каналов в сеть запустить.

Из них штук 6 HD. Пользователей около 10 тысяч за 3 года планируется.

Как представлю, какие полосы нужны будут, нехорошо становится.

Http прокси городить - доп. затраты.

Мультикаст как-то интереснее выглядит.

Все оборудование его поддерживает.

Http абсолютно прозрачно ходит поверх существующей СПД. Обычный OTT. Не нужно городить огород с CPE у клиента. Любая приставка, любой плеер, любой роутер.

Ограничивать услугу проще простого (включение отключение) и делается это централизованно. По поводу все оборудование поддерживает multicast - имейте ввиду, что это предполагает ISM или MVR, IGMP Snooping, MR и т.п. То есть на доступе нужно держать продвинутое и типизированное железо. По поводу полосы - все зависит от топологии сети и , если у вас гирлянда из свечей на доступе, то придется ставить прокси по ближе к агрегации, если правильная звезда - то все так же как и про мультикасте. Стоимость железа доя прокси - копеечная. И траблшутить http unicast проще. И гарантированная доставка пакета по TCP. И много чего еще.

[sherwood]

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

Изменено 12 декабря, 2013 пользователем sherwood

[Ivan_83]

Позволю себе процитировать самого себя. :)

Надеюсь услышать конструктивную критику, особенно от тех кто уже внедрил у себя мультикаст.

 

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

 

Udpxy - больше 50 клиентов тянет не очень, крутилок там почти нет.

Relaying - закрытые исходники, не всего его находят и обновляется очень редко.

Vlc - не все осилили, у многих текло.

Астра - пару месяцев как она научилась по хттп отдавать, при этом крутилок там почти нет и с нагрузками пока не известно.

Ещё я видел пару очень специфичных прокси udp->http, они скорее в состоянии макета для пробы взлетит/не взлетит.

 

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

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

 

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

На практике сеть нужна вылизанная, иногда и прошивки подбирать придётся к некоторым моделям коммутаторов, чтобы мультикаст нормально ходил. Чуть что мультикаст теряется и никто его не переотправит.

 

 

Но, у мультикаста есть слабые стороны.

 

Не все плееры его понимают, некоторые в принципе только хттп (например DLNA есть много где, но он везде только http ссылки понимает).

 

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

 

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

 

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

 

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

 

Те тут со стороны провайдера мультикаст как бы просто и легко: отправил в сеть и забыл, но со стороны абонента он малопригоден.

 

 

Проблему с задержками при открытии по хттп моя софтина решает в принципе, мультикаст тут и близко не стоял.

Мониторинг и возможность продавать каналы раздельно/по штучно разным абонентам - без проблем.

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

[EDA_SPB]

Мониторинг и возможность продавать каналы раздельно/по штучно разным абонентам - без проблем.

Расскажите, пожалуйста, как осуществляется. Сейчас крутим middleware stalker, стоит вопрос об интеграции с биллингом.

[Ivan_83]

Я планировал в свою софтину радиус добавить, авторизацию и аккаунтинг. Чтобы дополнительно различать клиентов авторизации планирую туда включать юзер агента, тогда будет видно сколько устройств у абонента дома за NAT спрятано и в принципе можно даже где то в биллинге для них разные тп делать, ну там детям только детское и только днём, взрослые и развлекательные каналы на основном ящике на день блокировать, пока родителей дома нет и прочие "шалости". И может даже отдавать на режект поток "дай денег / время не детское".

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

Либо более простой вариант - гнать всё через nginx, там либо проксировать либо редиректить (но это могут не все клиенты понять). Списки доступа можно сделать через map - прописать ip клиентов и урлы в файлы, иногда дёргать нгинх для перечитывания конфигов, он вроде умеет. Ну или ещё как то скриптами, нгинх гибкий.

Совсем шустрый вариант - рассадить пакеты каналов на разные порты и в фаервол скармливать правила.

 

Авторизация через хттп (логин+пароль стандартными средствами протокола хттп) - ИМХО не удобна для тв, думаю не все плееры это поймут. Да и неудобно это, корячится в телике или приставке с вводом с пульта. А если оно ещё и запоминать не будет или на каждый канал раздельно то вообще труба.

 

PS: мониторинг у меня есть, правда не сильно удобный: отдаётся по хттп текстовик где все источники с инфой по ним + к ним подцепленные клиенты со статой.

Переделать это относительно легко под что угодно, только идей пока нет.

[danilbal]

Ну у всего есть как преимущества так и недостатки.

HTTP все же очень быстро ест трафик.

Вот для EDA_SPB, с задачей включить 10 тысяч абонентов - на мой взгляд все же мультикаст будет удобней.

При HTTP даже если по 1 устройству на абонента в ЧНН и по 1 мегабиту на канал зажать (что в среднем уже качеством не очень) - то становится нужна ферма серверная, способная 10 Гбит отдать (а если считать "нормальное" качество 2 Мб SD и 10 для HD то уже более 20 Гбит). Что уже несколько нетривиально. Нет, я не говорю что невыполнимо, но нетривиально.

Кроме того, в ядре и агрегации должна быть эта полоса резервирована под это дело, что уже совсем нехило денег добавляет...

Мультикаст же при этом суммироваться будет не из 10 000 абонентов а из 70 каналов, то есть 100-200 мегабит. При подключении доступа на гигабите и поддержке ISM - почти и незаметно будет.

 

 

На практике: Пока услугой активно пользовалось 500 человек, в тестовом режиме, работало http с несколькими серверами и VLC на них (не помню точно, но вроде до 10-20 каналов на сервер тянуло). Когда услуга стала расти и стали возникать проблемы с нагрузкой, добавили мультикаст.

На фоне того что гигабит до коммутатора доступа ВСЕ РАВНО надо тащить - заменилось старое говно.

[Ivan_83]

Вот для EDA_SPB, с задачей включить 10 тысяч абонентов - на мой взгляд все же мультикаст будет удобней.

Тут бы в сумме всё считать.

Я полностью согласен с тем что провайдеру мультикаст максимально удобен, в случае если его не интересует как оно долетает абонента (потери пакетов: да/нет) и то как потом абонент этот мультикаст дальше wan порта своего роутера гонит и кто его там показывает.

Абонента мало интересует что творится за его роутером, а с мультикастом дома уже не очень.

Переключение каналов (про сложности с вафлей я писал), по хттп с прекешем в 2-4 мегабайта (это то что прилетает сразу после подключения, те в первые ~0,05 с) мой телек начинает показывать через 1,5 - 2,5 секунды. Любой плеер с такой схемой будет начинать показывать канал настолько быстро, насколько быстро он может инициализировать себя.

Этот же самый телек мультикаст запускает 6 секунд. Это при том, что у меня тут всего один коммутатор и igmp join не нужно разлетаться на цепочку коммутаторов и ждать их реакции.

 

HTTP все же очень быстро ест трафик.

Относительно мультикаста - скорее всего да.

Есть "переключальщики", сколько их % - я пока хз.

Из того что я видел - обычно большинство смотрит несколько каналов и тут получается экономия магистралей.

Те может и нет смысла их экономить.

 

При HTTP даже если по 1 устройству на абонента в ЧНН и по 1 мегабиту на канал зажать (что в среднем уже качеством не очень) - то становится нужна ферма серверная, способная 10 Гбит отдать (а если считать "нормальное" качество 2 Мб SD и 10 для HD то уже более 20 Гбит).

Не нужно ничего жать, наоборот нужно больше ХД. Хотя бы в офисе где бывают абоненты постоянно крутить.

Юзер видит ХД и понимает что такого качества он ни в эфире ни в кабеле не получит.

Если жать - картинка получится говно, а если ещё и мультикаст долго переключатся будет он плюнет и будет смотреть аналог с эфира :)

Отдавать 10гб - вообще не проблема, по вычислительной сложности можете считать что вы раздаёте статику через nginx с рам диска.

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

Что до проксирования на узлах - лучше конечно потестить в реальных условиях, но думаю что современные атомы и ноутбучные аналоги от амд с приличными сетёвками - гиг вывезут с запасом, особенно если с центра будут забирать по хттп.

 

 

 

Вы наверное тв не смотрите :) - у вас подход к этому с точки зрения дать абоненту тв с минимальными затратами и пусть платит.

Я смотрю тв и у меня дома его смотрят. И мне не всё равно как оно работает, потому что для себя.

Поэтому когда меня что то начинает напрягать в этом процессе - я решаю проблему: эффективное проксирование udp->http с прекешем и прочими плюшками, замена igmp proxy на netgraph, переписать nStremLmod чтобы без мусора и быстрее переключал каналы, DLNA сервер...

Ещё тут некоторые товарищи высказывались что ТВ без перемотки вообще должно умереть, у них там hls насколько я понял уже внедрён. Я чуток попробовал - мне показалось удобным, но конкретная реализация была не очень удобна.

 

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

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

Мой провайдер даёт бесплатно каналов 41 канал сд качества по хттп. Я включаю их плей лист только когда у меня торренты на полную качают: у них влц раздаёт без прекеша и они переключаются долго, у них всего пара интересных каналов. А через инет у по тому же хттп с прекешем пара шикарных плей листов, переключается всё как будто и не через инет.

 

Тут спорят: IPTV vs DVB-C.

Между тем, нужно понимать, что для конечного пользователя DVB-C скорее всего удобнее чем IPTV multicast.

DVB-C - воткнул кабель в телек и оно работает. Поставил разветвитель и второй телек подключил. Всё капец как просто. Даже для правообладателей можно модули с карточками для доступа к каналам продавать. Минусом что оно намертво привязано к кабелю, те не потаскаешь по квартире.

IPTV multicast - нужно специально подбирать роутер, тонкости=сложности в настройке роутера, привязан к проводам (если в проутере не настроть udpxy (если оно там есть) + ручная правка плей листа), переключается долго, скорее всего потребует ещё и приставку/плеер к телеку, можно долго рассказывать ТП что у тебя "квадратит" особенно вечерами. + можно смотреть на стационарном компе или ноуте по проводам.

IPTV http - роутер любой, настройка обычная, работает через вафлю без проблем = к проводам не привязан, переключается быстро, скорее всего потребует приставку/плеер но очень не плохие шансы что уже имеющееся дома сможет прожевать. Можно сюда же добавить возможность перемотки, но это точно требует спец приставки или виджета в ящик заточенного под оператора. Провайдеру долго доказывать что у тебя лагает не нужно, с той стороны это легко отмониторить. + можно смотреть на всё что подключено в домашнему роутеру, хоть на планшете, хоть на ноуте хоть на стационаре или даже на всяких игровых консолях. + я выше писал что можно выпендрится и ввести для абонента в лк родительский контроль за тв. Мне это скоро станет актуально :)

 

Те я не вижу вообще ни одного плюса для абонента в мультикасте, сплошные неудобства. И такое решение проигрывает DVB-C по юзабилити/удобству для абонента.

 

 

 

На практике: Пока услугой активно пользовалось 500 человек, в тестовом режиме, работало http с несколькими серверами и VLC на них (не помню точно, но вроде до 10-20 каналов на сервер тянуло). Когда услуга стала расти и стали возникать проблемы с нагрузкой, добавили мультикаст. На фоне того что гигабит до коммутатора доступа ВСЕ РАВНО надо тащить - заменилось старое говно.

Лучше расскажите о косяках мультикаста :)

За сколько включается канал?

На чём смотрят абоненты?

Как боритесь с рассыпаниями у клиентов?

На сколько быстро начинает лится мультикаст после igmp join если в цепочке 5 коммутаторов которые не приджойнены?

[maxlapshin]

Я немного хочу дополнить Ивана.

 

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

 

prepush есть мало где. Например, в эрливидео над препушем, работающем в разных протоколах, пришлось много и долго поработать.

В итоге несколько тысяч клиентов сейчас эрливидео по HTTP обслуживает.

 

Ещё проблему можно решать с помощью HLS: чанки самостоятельно оседают в промежуточных прокси серверах.