SmokerMan Опубликовано 5 декабря, 2013 · Жалоба А есть смысл в тазах? Вроде же есть приёмники нормальные? Например ? Что модет быть дешевле ПК с astra с парой тройкой карт dvb s dvb t ? Ну я собственно не утверждаю, а спрашиваю... приемники на 4isp стоят недорого, есть ли смысл заморачиваться с PC и возможными глюками? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uk2558 Опубликовано 6 декабря, 2013 (изменено) · Жалоба А есть смысл в тазах? Вроде же есть приёмники нормальные? Например ? Что модет быть дешевле ПК с astra с парой тройкой карт dvb s dvb t ? Ну я собственно не утверждаю, а спрашиваю... приемники на 4isp стоят недорого, есть ли смысл заморачиваться с PC и возможными глюками? С Astra как раз глюков и нет, если использовать хорошие карты, которые, впрочем, не дорого стоят. А вот, например, с профессиональной системой EMR глюков как раз и хватает и стоимость её далеко за 200К. Изменено 6 декабря, 2013 пользователем uk2558 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SmokerMan Опубликовано 6 декабря, 2013 · Жалоба С Astra как раз глюков и нет, если использовать хорошие карты, которые, впрочем, не дорого стоят. А вот, например, с профессиональной системой EMR глюков как раз и хватает и стоимость её далеко за 200К. А вот это не оно? http://shop.nag.ru/catalog/09663.Golovnye-stantsii-tsifrovye-PBI/09636.Priemniki-DCH/07396.DCH-5100P-44T2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
danilbal Опубликовано 6 декабря, 2013 · Жалоба Тут каждый для себя выбирает: кому-то удобней PBI, глюки которой тут тоже на 100 страниц почти расписаны и тема о них всегда в топе... кому-то охота повозиться с астрой, с которой первоначальная настройка несколько не очевидна, да и внятные карты подбирать надо. Глючить-то она может потом и не будет, но для начала надо заставить корректно работать, при чем тут разговор не про непосредственно астру а про платформу полностью... а кто побогаче - берут appertv вовсе:) там глюков совсем немного:) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 6 декабря, 2013 · Жалоба Преувеличивать сложность первоначальной настройки тазика линукс+астра не стоит. Убунта сервер ставится аналогично венде, по сложности. Отключить рп фильтер в сисцтл - просто. Опционально дрова к тюнерам - строчек 8 копи-пасты. Поставить астру - аналогично. Настройка - просканить утилитой спутнег и вбить полученное в файл. Там уже автоконфигуратор с вебмордй почти доделали, скоро совсем для блондинок станет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uk2558 Опубликовано 7 декабря, 2013 · Жалоба Преувеличивать сложность первоначальной настройки тазика линукс+астра не стоит. Убунта сервер ставится аналогично венде, по сложности. Отключить рп фильтер в сисцтл - просто. Опционально дрова к тюнерам - строчек 8 копи-пасты. Поставить астру - аналогично. Настройка - просканить утилитой спутнег и вбить полученное в файл. Там уже автоконфигуратор с вебмордй почти доделали, скоро совсем для блондинок станет. Подскажите, зачем отключать RP_Filter ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 7 декабря, 2013 · Жалоба От него никакой пользы, только зло. Особенно с мультикастом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sherwood Опубликовано 11 декабря, 2013 · Жалоба Это значит, что можно просто сворачивать ласты и ложиться по "большого дядю-конкуретна"? Потому как конкурировать с теми, у кого есть IPTV (да ещё и с кучей сервисов) становиться на порядок труднее. наверное у всех по разному, но компания в которой я работаю не предоставляет iptv и не собирается, считает это отмирающим сервисом (у трех наших конкурентов это есть, но как бы не испытываем оттока абонентов или отсутствие роста абонент базы), потому как с ростом скорости в сети стали доступны сервисы лучше чем это iptv, которые например пишут в запись все каналы, а это уже не мало важно, потому как не всегда можно подстроится под время в которое например транслируют футбол. По месту жительства подключен к двум провайдерам у которых есть iptv, но его не использую, стоит HD триколор и пользуюсь kartina.tv Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 11 декабря, 2013 · Жалоба считает это отмирающим сервисом Помните как быстро мобилы с смс вытеснили пейджинг, за 2 года завалили этот бизнес в нерентабельность. Интернет позволяет потреблять видеоконтент безо всяких особых проблем уже лет 5, фактически произошло тоже самое как смс в мобилах заменили пейджинг, одна услуга вобрала в себя старую (ну или как телефон заменил телеграф). А что я вижу в статистике, 12-15% из всех отключений идёт по причине "Конкурент предложил инет+аналоговое тв". Из года в год вижу. Есть объяснение такой живучести этого отмирающего сервиса? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sherwood Опубликовано 11 декабря, 2013 · Жалоба Интернет позволяет потреблять видеоконтент безо всяких особых проблем уже лет 5 хорошо живете, у нас только второй год пошел как стали хорошие без лимитные тарифы. А что я вижу в статистике, 12-15% из всех отключений идёт по причине "Конкурент предложил инет+аналоговое тв". Из года в год вижу. Есть объяснение такой живучести этого отмирающего сервиса? Пото что, мало еще народу кто может себе позволить хороший HD телик, думаю время придет. У нас еще и кабельным ТВ, люди занимаются и абонентская база у них есть и тарифы по 400р. Правильно Вы заметили, что примерно 10% нуждаются в iptv, так стоит ли игра свеч? Для меня важна не зависимость от времени, пришел вечером с работы и посмотрел интересующую передачу которая была днем, и нет проблем,а то у оператора света нет на промежуточной точки, то картинка распадается из-за кривых рук админа или оборудования, то кабель тракторист порвал и т.д., включил триколор и наслаждаешься контентом. Вообщем как написано при входе в Бухенвальд - Каждому свое. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uk2558 Опубликовано 12 декабря, 2013 · Жалоба Я тоже пытаюсь убедить руководство в бесполезности IP-TV. DVB-C лучше, да и телеки у народа уже в большом количестве с ресивером DVB-C. Если и нет, то приставка на DVB-C стоит намного дешевле, чем для IP-TV. И заморочек с СПД меньше, нежели со всей этой multicast ready шнягой. И траблшутинг в разы легче на DVB-C. Но.... "эффективные" манагеры "свистят" про IP-TV. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
danilbal Опубликовано 12 декабря, 2013 · Жалоба Меньше заморочек с DVB-C? Вот с этим утверждением я бы поспорил:) 1 - удваивается количество оборудования: кроме коммутаторов езернета в ящике добавляется еще и оптический приемник. 2 - сложности с удаленным мониторингом этих оптических приемников: определить качество можно лишь у абонента. коммутаторы все же позволяют мониторить достаточно чтоб найти проблемы. 3 - опять-таки дополнительные кабели, как точки отказа и как дополнительные затраты: коаксиал тупо дороже витухи, как на него не смотри. 4 - специфика коаксиала тоже присутствует: начиная от необходимости проверять параметры раз в полгода и "подтягивать" разъемы и заканчивая вдруг "взглючившим" абонентским оборудованием, которое начинает в линию гадить. Так что по моему мнению все же проще и дешевле одну сеть держать, а на освободившиеся от "непостройки" коаксиальной сети деньги - ставить нормальные коммутаторы с нормальной поддержкой мультикаста и внятной магистралью. А вот про то нужно ли вообще внедрять телевидение или, как считает sherwood, предоставлять только телематику - уже чуть сложнее. В отдаленной перспективе (наверное лет этак 10) - достаточно большая часть телеприемников будет уметь ОТТ и прочие ютубы, с подписками онлайн на что хочешь (скорей всего и что-то типа нетфликса подтянется) и IPTV в том виде как есть сейчас наверное станет неактуальным. Менее требовательным пользователям ("бабулькам") - останется достаточно двух мультиплексов от РТРС - все топовые каналы там уже есть и без дополнительных денег. И ОТТ и IPTV им не понадобиться в большинстве случаев. Но! За этот десяток лет есть реальный шанс хорошенько этак подрастерять абонентов, для которых услуга нужна сейчас. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SmokerMan Опубликовано 12 декабря, 2013 · Жалоба Я тоже пытаюсь убедить руководство в бесполезности IP-TV. DVB-C лучше, да и телеки у народа уже в большом количестве с ресивером DVB-C. Если и нет, то приставка на DVB-C стоит намного дешевле, чем для IP-TV. И заморочек с СПД меньше, нежели со всей этой multicast ready шнягой. И траблшутинг в разы легче на DVB-C. Но.... "эффективные" манагеры "свистят" про IP-TV. Ммм... У вопрошающего уже есть ip-сеть, скорее всего работающая и обслуживаемая без проблем. Вы считаете, что выгоднее построить и оьслуживать полностью новую сеть, чем использовать имеющиеся ресурсы?.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uk2558 Опубликовано 12 декабря, 2013 · Жалоба Меньше заморочек с 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-сеть, скорее всего работающая и обслуживаемая без проблем. Вы считаете, что выгоднее построить и оьслуживать полностью новую сеть, чем использовать имеющиеся ресурсы?.. Вопрос в масштабах рассматриваемой организации, нам дешевле коаксиал растянуть, чем менять оборудование на доступе, например. С волокнами проблем нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 12 декабря, 2013 · Жалоба И заморочек с СПД меньше, нежели со всей этой multicast ready шнягой. И траблшутинг в разы легче на DVB-C. Но.... "эффективные" манагеры "свистят" про IP-TV. Ерундой не занимайтесь, пускайте по хттп, с ним проблем на порядок меньше. Для старта вообще хватит одного тазика который отдавать будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uk2558 Опубликовано 12 декабря, 2013 (изменено) · Жалоба И заморочек с СПД меньше, нежели со всей этой multicast ready шнягой. И траблшутинг в разы легче на DVB-C. Но.... "эффективные" манагеры "свистят" про IP-TV. Ерундой не занимайтесь, пускайте по хттп, с ним проблем на порядок меньше. Для старта вообще хватит одного тазика который отдавать будет. Сейчас так и делаем, раздаем по http. "Эффективный мАнагер", с зарплатой как у всего тех отдела в сумме, прочитал слово multicast в интернете. Теперь поставлена задача изучить вопрос и запустить в тесте. Изменено 12 декабря, 2013 пользователем uk2558 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EDA_SPB Опубликовано 12 декабря, 2013 · Жалоба Ерундой не занимайтесь, пускайте по хттп, с ним проблем на порядок меньше. Для старта вообще хватит одного тазика который отдавать будет. Оффтопик. Давно хотел спросить, но стеснялся. А почему меньше проблем с http? Интерес не праздный, хотим 60-70 каналов в сеть запустить. Из них штук 6 HD. Пользователей около 10 тысяч за 3 года планируется. Как представлю, какие полосы нужны будут, нехорошо становится. Http прокси городить - доп. затраты. Мультикаст как-то интереснее выглядит. Все оборудование его поддерживает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uk2558 Опубликовано 12 декабря, 2013 · Жалоба Ерундой не занимайтесь, пускайте по хттп, с ним проблем на порядок меньше. Для старта вообще хватит одного тазика который отдавать будет. Оффтопик. Давно хотел спросить, но стеснялся. А почему меньше проблем с http? Интерес не праздный, хотим 60-70 каналов в сеть запустить. Из них штук 6 HD. Пользователей около 10 тысяч за 3 года планируется. Как представлю, какие полосы нужны будут, нехорошо становится. Http прокси городить - доп. затраты. Мультикаст как-то интереснее выглядит. Все оборудование его поддерживает. Http абсолютно прозрачно ходит поверх существующей СПД. Обычный OTT. Не нужно городить огород с CPE у клиента. Любая приставка, любой плеер, любой роутер. Ограничивать услугу проще простого (включение отключение) и делается это централизованно. По поводу все оборудование поддерживает multicast - имейте ввиду, что это предполагает ISM или MVR, IGMP Snooping, MR и т.п. То есть на доступе нужно держать продвинутое и типизированное железо. По поводу полосы - все зависит от топологии сети и , если у вас гирлянда из свечей на доступе, то придется ставить прокси по ближе к агрегации, если правильная звезда - то все так же как и про мультикасте. Стоимость железа доя прокси - копеечная. И траблшутить http unicast проще. И гарантированная доставка пакета по TCP. И много чего еще. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sherwood Опубликовано 12 декабря, 2013 (изменено) · Жалоба Вот по http было бы не плохо услышать хотя бы на пальцах как оно. то есть я так понимаю нужен тазик с linux в него какая то карта нужна для приема сигнала со спутника (например с какого нибудь без платного), далее какие то настройки на тазике и вещаем в сеть которая уже имеется? помнится давным давно так пробовали, но на сколько я помню таким макаром можно вещать один канал для всех или каждый может выбирать свой канал? или не все так просто? :) Изменено 12 декабря, 2013 пользователем sherwood Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 12 декабря, 2013 · Жалоба Позволю себе процитировать самого себя. :) Надеюсь услышать конструктивную критику, особенно от тех кто уже внедрил у себя мультикаст. Просто потому что в открытом доступе почти ничего нет для вещания по HTTP в масштабах больше домашнего. Udpxy - больше 50 клиентов тянет не очень, крутилок там почти нет. Relaying - закрытые исходники, не всего его находят и обновляется очень редко. Vlc - не все осилили, у многих текло. Астра - пару месяцев как она научилась по хттп отдавать, при этом крутилок там почти нет и с нагрузками пока не известно. Ещё я видел пару очень специфичных прокси udp->http, они скорее в состоянии макета для пробы взлетит/не взлетит. Вторая причина в том, что у многих плееров специфичная реализация, при которой у них с мультикаста старт картинки быстрее, чем по хттп. При этом, все выше описанные софтины отдают данные не сразу после подключения, а после того как они накопят данные на отправку. В итоге по хттп получается более тормозное переключение каналов, на некоторых плеерах. Третья причина в картинках вендоров, где мультикаст благодаря снупингу весьма оптимально распространяется по сети, исключая дублирование одних и тех же каналов для разных абонентов в одном коммутаторе. На практике сеть нужна вылизанная, иногда и прошивки подбирать придётся к некоторым моделям коммутаторов, чтобы мультикаст нормально ходил. Чуть что мультикаст теряется и никто его не переотправит. Но, у мультикаста есть слабые стороны. Не все плееры его понимают, некоторые в принципе только хттп (например DLNA есть много где, но он везде только http ссылки понимает). Мультикаст и вайфай плохо дружат, особенно когда к точке доступа подключено несколько устройств. Мультикаст пропускают не все роутеры, а некоторым требуется доп настройки. Поэтому многие роутеры содержат udpxy, который даёт задержку переключения каналов, а на слабом железе и тормозить может, снижая удовольствие от просмотра. Со стороны провайдера, в случае мультикаста, нет средств мониторинга, и не возможно понять сколько устройств его получает и насколько битым он к ним приходит. Так же, для мультикаста есть вроде только у длинков ограничение доступа, чтобы можно было продавать каналы раздельно/по штучно разным абонентам. Те тут со стороны провайдера мультикаст как бы просто и легко: отправил в сеть и забыл, но со стороны абонента он малопригоден. Проблему с задержками при открытии по хттп моя софтина решает в принципе, мультикаст тут и близко не стоял. Мониторинг и возможность продавать каналы раздельно/по штучно разным абонентам - без проблем. Разгрузить магистрали тоже можно, достаточно раздавать с районных узлов по хттп, а забирать из центра можно так же по хттп. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EDA_SPB Опубликовано 12 декабря, 2013 · Жалоба Мониторинг и возможность продавать каналы раздельно/по штучно разным абонентам - без проблем. Расскажите, пожалуйста, как осуществляется. Сейчас крутим middleware stalker, стоит вопрос об интеграции с биллингом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 12 декабря, 2013 · Жалоба Я планировал в свою софтину радиус добавить, авторизацию и аккаунтинг. Чтобы дополнительно различать клиентов авторизации планирую туда включать юзер агента, тогда будет видно сколько устройств у абонента дома за NAT спрятано и в принципе можно даже где то в биллинге для них разные тп делать, ну там детям только детское и только днём, взрослые и развлекательные каналы на основном ящике на день блокировать, пока родителей дома нет и прочие "шалости". И может даже отдавать на режект поток "дай денег / время не детское". В качестве альтернатив можно попробовать прикрутить радиус на луа к астре. Либо более простой вариант - гнать всё через nginx, там либо проксировать либо редиректить (но это могут не все клиенты понять). Списки доступа можно сделать через map - прописать ip клиентов и урлы в файлы, иногда дёргать нгинх для перечитывания конфигов, он вроде умеет. Ну или ещё как то скриптами, нгинх гибкий. Совсем шустрый вариант - рассадить пакеты каналов на разные порты и в фаервол скармливать правила. Авторизация через хттп (логин+пароль стандартными средствами протокола хттп) - ИМХО не удобна для тв, думаю не все плееры это поймут. Да и неудобно это, корячится в телике или приставке с вводом с пульта. А если оно ещё и запоминать не будет или на каждый канал раздельно то вообще труба. PS: мониторинг у меня есть, правда не сильно удобный: отдаётся по хттп текстовик где все источники с инфой по ним + к ним подцепленные клиенты со статой. Переделать это относительно легко под что угодно, только идей пока нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
danilbal Опубликовано 13 декабря, 2013 · Жалоба Ну у всего есть как преимущества так и недостатки. HTTP все же очень быстро ест трафик. Вот для EDA_SPB, с задачей включить 10 тысяч абонентов - на мой взгляд все же мультикаст будет удобней. При HTTP даже если по 1 устройству на абонента в ЧНН и по 1 мегабиту на канал зажать (что в среднем уже качеством не очень) - то становится нужна ферма серверная, способная 10 Гбит отдать (а если считать "нормальное" качество 2 Мб SD и 10 для HD то уже более 20 Гбит). Что уже несколько нетривиально. Нет, я не говорю что невыполнимо, но нетривиально. Кроме того, в ядре и агрегации должна быть эта полоса резервирована под это дело, что уже совсем нехило денег добавляет... Мультикаст же при этом суммироваться будет не из 10 000 абонентов а из 70 каналов, то есть 100-200 мегабит. При подключении доступа на гигабите и поддержке ISM - почти и незаметно будет. На практике: Пока услугой активно пользовалось 500 человек, в тестовом режиме, работало http с несколькими серверами и VLC на них (не помню точно, но вроде до 10-20 каналов на сервер тянуло). Когда услуга стала расти и стали возникать проблемы с нагрузкой, добавили мультикаст. На фоне того что гигабит до коммутатора доступа ВСЕ РАВНО надо тащить - заменилось старое говно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 13 декабря, 2013 · Жалоба Вот для 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 коммутаторов которые не приджойнены? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxlapshin Опубликовано 13 декабря, 2013 · Жалоба Я немного хочу дополнить Ивана. С HTTP проблема в том, что из-за TCP в клиенте приходится делать буфер, компенсирующий лаги. Для того, что бы старт был быстрым, надо этот буфер быстро наполнять. prepush есть мало где. Например, в эрливидео над препушем, работающем в разных протоколах, пришлось много и долго поработать. В итоге несколько тысяч клиентов сейчас эрливидео по HTTP обслуживает. Ещё проблему можно решать с помощью HLS: чанки самостоятельно оседают в промежуточных прокси серверах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...