IPTV в России

Один из потенциальным IPTV-операторов недавно попросил рассказать о том, как загружаются STB и в чём смысл «священной войны», которая и тут тоже есть своя.

Если вкратце, то есть два основных типа STB. Одни работают самостоятельно (та же Amino, например), другие при каждом включении загружаются из сети (самый популярный у нас из подобных — Motorola/Kreatel).

Начнём со второго типа, с тех, что грузятся из сети. Когда Kreatel включается, в нём нет практически никакого софта, кроме сетевого загрузчика, который подключает сетевой контроллер, получает по DHCP собственный адрес и начинает слушать multicast-группу, в которой вещается операционная система со всеми пирогами — драйверами, брузерами и кусками middleware. Занимает это в среднем минуты полторы. Выключение STB с пульта управления вводит устройство в спящий режим и прошивку он не теряет, однако, если «моргает» свет, то устройству придётся перегрузиться полностью, с самого начала. Это офигенный минус. Кроме того, нужен отдельный, довольно надёжный сервер, который будет постоянно вещать софт для желающих его загрузить. Но это мелочи.

Другой вариант STB, как, например, та же AmiNET, через сеть загружается лишь один раз. Вы покупаете «пустую» приставку, которая умеет только получить DHCP, в котором, кроме её собственного адреса, вещается ещё и адрес софта. Приставка получает собственный адрес и прошивается софтом, который вещается в указанной multicast-группе. Для того, чтобы приставка прошилась санкционированно, и не абы чем, вещаемые образы обычно шифруются, при этом ключи генерируются производителем для каждого оператора отдельно и жёстко прописываются в приставке (изменить их, впрочем, возможно с помощью совсем уж специальных утилит). Таким образом, приставка, выпущенная для оператора X, использоваться оператором Y не сможет, потому что свою версию софта последний «залить» не сможет. После этого STB работает самостоятельно. Системы поддержки AmiNET, Scientific Atlanta и некоторые другие, в целях большей гибкости, вещают отдельно загрузчик софта (bootstrap) и саму операционную систему с приложениями (software image).

Основной аргумент, который применяют производители первого типа устройств в пользу своей концепции — гибкость. Мол, при этой схеме функционирования оператор имеет возможность в любой момент времени обновить софт, полностью сменить middleware и, вообще, совершить любые необходимые манипуляции. На самом деле это не так. Точнее, ровно так, но применимо и к устройствам, способным включаться самостоятельно. Для всех этих устройств также существуют обслуживающие системы, которые включают инструментарий, обеспечивающий вещание необходимого софта и утилитки, которые позволяют «дёрнуть» любой конкретное устроёство или группу STB и либо просто «ребутнуть» их, либо обновить софт, либо сделать что-то ещё. То есть, возможности управления и администраторования STB никоим образом не страдают от того, загружается он из сети при каждом включении или лишь при инициализации в сети оператора.

Почему эти отличия важны? Причин две. Во-первых, в условиях российских городов, где скачки напряжения не являются исключительной редкостью, тот факт, что при каждом прерывании электропитания перерыв в обслуживании абонента составляет как минимум минуту-полторы, раздражает. Во-вторых, будьте внимательны. Отчего-то часто выходит так, что за необходимость загружать абонентскую приставку при каждом включении, нужно ещё и дополнительно платить. Так, один известный производитель не только продаёт сам сервер-вещатель за 700 с лишним евро, так ещё и каждый обслуживаемый им STB лицензирует ещё за некоторое количество евро. Оно вам нужно?!

Кстати, тот же Kreatel новые, ещё не выпущенные версии приставок будет делать как раз прошиваемыми единыжды, а затем обновляемыми по запросу.

NB. Кстати, мы скоро поднимем ещё два сервиса на сайте — wiki (он уже есть, нужно только сделать «начальную набивку», если есть желающие поучаствовать в этом процессе, заходите на http://wiki.telecombuzz.ru/, через неделю-две он пойдёт в «продакшн» ) и новостная лента.

В связи с тем, что тема мониторинга достаточно актуальна, но практически не раскрыта на блоге, я решил написать немного на эту тему… Начать же хочу с описания самой распространенной на данный момент методики — RFC 4445.

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

В связи с этим был утвержден индекс MDI (Media Delivery Index) определенный в методике RFC 4445. Он основан на принципе формирования интегральной оценки качества по совокупности двух самых важных параметров качества на всех участках транспорта IPTV инфраструктуры — джиттера и количества потерянных пакетов. И логика метода MDI заключается в том, что если с транспортом пакетов проблем не будет, то не будет проблем и с контентом. Эти параметры определены как уровень задержки Delay Factor (DF) и уровень потерянных пакетов Media Loss Rate (MLR).

MDI вычисляется за произвольный промежуток времени, обычно это 1 секунда

• MDI-DF показывает наибольшее значение параметра джиттера пакетов за период измерения
• MDI-MLR показывает количество транспортных пакетов , потерянных за период измерения

И если с измерениями уровня MLR, выполняющимися методами пассивного мониторинга все предельно понятно, то с DF дело обстоит сложнее. Джиттером в MDI является задержка между ожидаемым и реальным временем приема пакета (см. рисунок).

где IAT — среднее время доставки соседних IP-фреймов.

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

MDI — это простой алгоритм мониторинга уровня транспорта для квалификации качества уровня услуг. За счет применения MDI можно осуществить мониторинг параметров качества на всех основных узлах транспорта начиная HeadEnd и заканчивая STB, выявить участок, где происходит ухудшение качества, и определить в какой степени это критично для услуги IPTV.

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

У меня есть ощущение, что слова презентаторов вроде: «интегрировать новую услугу просто! это же всё просто веб-приложение!» легли в уши не столько адресатам среди операторов, сколько разработчикам веб-приложений, типа CMS. Эти парни решили, что сейчас-то они возьмут свою зашибенскую CMS, которую писали для магазина подержанных автомобилей и, прикрутив тему под PAL-разрешение, охватят страшную толпу клиентов, которые не готовы будут платить за платформу услуг от десятков тысяч до миллионов долларов.

На нашем рынке обычно довольно неплохо срабатывала идея «народных» продуктов. Биллинги IP-телефонии и интернет за менее чем 10 тыс долларов, программные коммутаторы IP-телефонии за те же деньги. Есть ли перспективы у продукта с условным названием «народный middleware»?

Попробуем определить фундаментальные требования к middleware’у, который нужен оператору. Операторы, если у вас есть что добавить — не стесняйтесь.

• Операторского класса надёжность. Ожидания абонентов относительно надёжности телевизионного приёмника сформированы годами. Качество традиционной межгородской телефонной связи стало предметом массы классических шуток шутников и юмористов — от А. Райкина до безумцев из «Аншлага». Телевизор при этом, если уж работал, то работал.
• Функциональная расширяемость. Все кругом только и твердят о том, как просто разворачивать новые услуги на платформе IPTV. Платформа обязана обеспечивать возможность разработки приложений на её базе. Соответственно, иметь для этого открытый и документированный SDK.
• Широкие возможности по интеграции. Собственно, то, что делает middleware таковым. То есть, целая куча тщательно документированных API, которые позволят подключать новые услуги в BSS, провижнить их в middleware, а он, в свою очередь, будет проключать эти услуги в DRM, VoD, STB и рапортовать об успешности или неуспешности операций в OSS. Сюда же относится необходимость обеспечения максимально простой интеграции с STB.
• Достаточная интегрированность для начального запуска. То есть, система не должна быть «пустой», с торчащими наружу интерфейсами. Она должна успешно подставляться в матрицу компонентов решения, которую каждый оператор для себя составляет. Интегрироваться со всеми невозможно и не нужно, но интегрироваться с лидерами отрасли нужно обязательно.

Мы не говорим о базовых и очевидных требованиях, вроде «возможности импортировать EPG».

Сделать продукт дешёвым можно только за счёт унификации, создания из него «коробочного» решения. Код унифицирован, процесс его продажи тоже прост и понятен — полный вперёд. В случае с операторскими решениями IPTV такое получается крайне редко. Я б сказал, до сих пор ни у кого не получилось. IPTV пока ещё — штучный товар и довольно долгое время ещё будет им оставаться. Критическая масса операторов для того, чтобы решение стало commodity, в данном случае набираться будет довольно медленно — уж очень высока стоимость вхождения с качественным сервисом, если учесть затраты на апгрейд сети и закупку абонентских устройств. На эту «коммодитизацию» технологии и наработку бизнес-моделей для более явного окупания подобных проектов потребуется время, во время которого телекоммуникационный рынок, скорее всего, как раз консолидируется до того состояния, в котором он пребывает в большинстве цивилизованных стран. То есть, будет поделен между крупными игроками.

Это я к чему всё писал-то? Не к тому, чтобы все, кто берётся писать middleware сейчас, бросили это занятие, а к тому, чтобы операторы, которые озабочены выбором платформы сейчас, осознавали, с чем они могут столкнуться.

Тем не менее, рынок для небольших платформ IPTV, конечно же, есть. Я бы не рискнул, наверное, разворачивать на Anevia сеть IPTV в сотню тысяч абонентов, однако не могу представить более эффективного решения для организации, скажем, гостиничного сервиса IPTV. Разве что Nevotek. Кроме того, в предверии той же консолидации масса небольших операторов должна бы, по логике, бросится повышать собственную стоимость, в надежде продаться задорого. Небольшое решение IPTV и с шумом запущенная на его базе страшно модная услуга как нельзя лучше в этом смысле помогают.

И, не совсем в кассу, но мне напомнили, что мы обещали выдать PR-службе Корбины доступ к блогу в случае, если они запустят к марту сервис, а также съесть перед зайцем свой паспорт. Но объявлений о подобном запуске я не слышал. Так что дышу ровно. Справедливости ради замечу, что бурная движуха, которую развила Корбина, говорят, нашла подтверждение. Тот же ВимКом на CSTB, например, был полон оптимизма. Правда, отводя в сторону глаза, говорили, что во всём мире ставят MSTV 2, а в Россию привезли MSTV 1.3. Ну и вспоминали, что со времён DOS’а, у Microsoft всё окончательно налаживалось к версии 3 (вспоминаем историю MS DOS, MS Windows, MS Windows NT).

Tags: middleware, iptv, russian, market

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

На этот пост меня навело то, что вот уже год люди спрашивают меня: а в чем сила MPEG4? А в чем разница? А почему вы не сделали сразу MPEG4? А почему вы не делаете MPEG4? А почему…? Очень много “почему”. Ответы разные - и простые, и сложные. Но я решил изложить все монументально и по порядку. Я не буду вникать в глубину технологий, во первых не вижу особого смысла, во вторых - на мой взгляд, ответы на все эти вопросы лежат на поверхности. Вообще в IPTV очень много вещей, которые кажутся очень сложными… Они и есть сложные, однако в мире техники все поддается объяснению с точки зрения здравой логики. Итак…
 

MPEG4. Что же это такое?

Безусловно это новая технология компрессии видеопотоков. Чем он лучше MPEG2? Безусловно тем, что на нем можно добиться меньших скоростей этих самых потоков. Однако чудес на свете не бывает. Во первых. Не думайте что с помощью MPEG4 можно добиться большего качества при той же скорости по сравнению с MPEG2. Хочу вас расстроить. На скорости 3-4 МБит/сек MPEG4 будет давать изображение с качеством хуже, чем MPEG2. Это технология не для повышения качества. Она - для понижения скорости.

Разберемся почему.

В чем разница между этими технологиями? А ни в чем! Кроме одного. MPEG4 различает фоновые объекты в кадре, и объекты на переднем плане. И умеет объектам переднего плана давать больше полосы, чем объектам заднего. То есть фактически игнорировать “ненужные” детали изображения. Как результат - отсутствие “заквадрачивания” картинки на низких скоростях и при сильном изменении кадра с одной стороны и цветовое марево вместо фона с другой. Особенно хорошо результат деятельности MPEG4 видно на футболе - очень четкий мяч, игроки, но вместо травы на поле зеленая бурда, а вместо зрителей на трибунах - бурда разноцветная. Чего в общем то и хотелось.
 

А нужен ли MPEG4?

Теперь. Нужен ли MPEG4? Мой ответ - и да, и нет. Я считаю (это мое личное мнение)
что MPEG4 на SD абсолютно бессмысленнен, зато имеет огромный смысл для HD. Почему? Потому что для SD при современном уровне математики MPEG2 у таких грандов как Tandberg Television, Harmonic, Thomson и SciAtl требуется 3Мбит/сек для очень хорошей картинки. Это конечно не DVD, спору нет - фильтры срезают детали и шумы, под шумы попадают еще некоторые детали. Потом двухпроходная компрессия и выбор оптимальной схемы сжатия для того или иного кадра. Но тем не менее. MPEG2 на 3 Мбит/сек на _нормальном_ оборудовании компрессии - очень хорошо для ТВ каналов. MPEG4 даст вам (на сегодняшний день, по результатам реальных лабораторных тестов в реальных проектах, а не по данным маркетингового булшита разных поставщиков) 2 Мбит/сек. То есть экономия - 1Мбит/сек на поток. Теперь давайте попробуем понять, кому и где нужна эта экономия?

• Первый вариант - у вас узкая или настабильная последняя
  миля. То есть вы не можете сделать клиенту больше чем 3-4Мбит/сек. Например на ADSL. Но давайте разберемся более детально в выборе. Компрессия MPEG4 сегодня в 2-3 раза дороже, чем компрессия MPEG2. Возьмем некий условный headend на 100 каналов. Для MPEG2 в зависимости от… это будет около 1-2Млн $. Для MPEG4 это соответственно будет 2-6млн $. Разница - 1-3 миллионов этих самых $. То есть в вашем проекте оправданность MPEG4 наступит тогда, когда количество абонентов, которым вы не можете предоставить услугу на MPEG2 из за плохой последней мили, но могли бы, при использовании MPEG4 ее (услугу) предоставить, должно за разумный срок покрыть эти 1-3млн $.
  Я не буду вдаваться в примеры моделей расчета, думаю если это кому то потребуется, он сам справиться. Я хочу лишь предостеречь от внедрения ненужной технологии. Например для FTTH/ETTH ставить MPEG4 это полный трэш. Заметьте я не учитываю разницу в стоимости STB, потому что скоро ее уже и не будет, потому что не будет MPEG2 SD SetTopBox.
• Второй вариант - экономия полосы на магистрали - на 100 каналов мы съэкономим 100Мбит, то есть вместо 300Мбит/сек MPEG2 получим 200Мбит/сек MPEG4. Реальная экономия на магистрали IP будет что то в районе 150-200Мбит. Тоже трэш а не экономия.
• Третий вариант - наиболее реальный - экономия полосы на VoD. Здесь мы просто в 1.5 раза увеличиваем производительность VoD серверов с точки зрения количества одновременных сессий VoD. То есть на тех же процессорах, жестких дисках и памяти мы можем обслужить в 1.5 раза больше клиентов и записать в 1.5 больше программ. Вот только экономия в деньгах будет довольно малой - процессоры, диски и память дешевеют, а вот хитрые производители ПО для VoD лицензируют потоки, причем MPEG4 потоки, поскольку они более продвинутые (grin), у некоторых производителей могут стоить даже дороже…

MPEG4+HD 

Такое вот безрадостное на мой взгляд будущее у MPEG4 в SD. Зато вот в HD все
хорошо. Без MPEG4 сделать запуск какого либо продукта для массового пользователя HD сделать просто невозможно. Причина простая. HD на MPEG2 это 20-30Мбит/сек на поток, а в MPEG4 - 6-10. С развитием математики на компрессии и на декомпрессии думаю это будут уверенные 5-8Мбит/сек при нормальном качестве. Здесь уже другой разговор и на магистрали и последней миле для фиксированных сетей (и IP, и HFC), и даже для спутниковых (аренда транспондеров весьма дорогое удовольствие).
В качестве финала мое мнение про VC-1 от Микрософта. А нет у меня мнения, только
сухие факты. BT и DT потребовали от MSTV поддержки стандартного MPEG4. Хотя есть и проекты с VC-1, и производители аппаратной компрессии VC-1 тоже есть. Но я все же больше верю в открытые стандарты.

 В планах на будущее - опус о разных технологиях, используемых в IPTV для
пользовательского интерфейса.

Что же такое IPTV в смысле технологии? Давайте быстренько разберёмся, из чего всё это состоит и как устроено.

Собственно, компонентов не так уж и много. Изучим схемку.

Вообще-то там хорошо бы делать мультик, но пока обойдёмся без мультика. Итак, базовый, условно рабочий набор компонентов можно поделить вообще на следующие части:

• Головная станция (HeadEnd)
• Подсистема Видео по требованию (Video on Demand)
• Сервисная платформа (Middleware)
• Бизнес- и операционные системы (OSS/BSS)
• Абонентское оборудование (SetTopBox)

Есть ещё вся история «за кадром» — системы OSS/BSS — биллинг, системы мониторинга, управления и прочее-прочее-прочее. Телевизионщики часто делят это несколько иначе, объединяя все операторские компоненты в термин «головная станция» и выделяя только сеть и абонентское оборудование. Мы так поступать не будем, потому что эти компоненты для нас очень важны.

Да, сеть. Конечно же, сеть. Это IP-сеть, достаточно «умная» и функциональная для того, чтобы обеспечивать доступность и качество услуг. По поводу того, как нужно строить мультисервисную сеть, есть много разных концепций, но базовые требования можно сформулировать следующим образом.

• достаточная полоса пропускания — это от 4 Mbps для MPEG2 и от 2,5 Mbps для MPEG4. Естественно, для получения приемлимого качества изображения на среднестатистическом телевизоре.
• поддержка Multicast во всей сети. обязательное условие для реализации broadcast-услуг
• сквозная поддержка механизмов QoS. Я сталкивался с мнением, что если у нас будет достаточная полоса пропускания, то плевать мы хотели на QoS — всё пролезет и так. На самом деле в реальности это работает, конечно, потому что если в сеть Вы загоняете не только IPTV-трафик, но и голосовой, и данные и интернет, да ещё и там есть клиенты с договором, подразумевающим качество обслуживания.

Вообще говоря, роль сети довольно часто недооценивается, но вот эти простые три требования в реальности трансформируются в огромный геморрой — выясняется, что требование про multicast выливается в то, что хорошо бы иметь поддержку IGMP v3 или как минимум возможность трансляции из IGMP v2 в IGMP v3. Что время сходимости сети при авариях имеет большое значение (не столь значительное, впрочем, как обычно представляется). Ну и масса всяких других факторов, которые всё же подразумевают, что сеть у вас «умная». Строго говоря, в большинстве случаев именно сеть является основной статьёй расходов при запуске IPTV.

Итак, собственно, компоненты IPTV. Те, что не сеть :-)

Головная станция

Самая телевизионная часть всего решения, решает задачу, собственно, запихивания телевизионного сигнала в IP-сети. С помощью головной станции сигнал принимается из эфира, спутника или наземного источника, если необходимо, цифруется (кодер), декодируется (декодер) и в итоге ремультиплексируется (стример) в IP MPEG SPTS, каждая программа в отдельную multicast-группу. Современные тенденции таковы, что ASI-компоненты современных головных станций активно вытесняются IP-компонентами (иногда даже и SDI-компоненты во внутристудийном обмене). Основные игроки на рынке головных станций — Scientific Atlanta, Tandberg Television, Scopus, Minerva, OptiBase.

Часто в головную станцию относят (тёмное прошлое, когда головной станцией называли всё, что находится в одном месте :-) ещё и Системы защиты контента (CAS/DRM). Производителей этого хабара совсем-совсем немного. Не наберётся, в общем-то, и десятка. Суть здесь проста — весь контент необходимо шифровать. И, к сожалению, владельцы контента живут вообще в другом мире. Они не знают, что IP-сеть управляема, что Вы можете делать фильтрование по MAC-адресам и аутентификацию сессий с помощью токенов. Они знают, что если что-то зашифровать сумашедшими ключами, то это будет надёжно. Собственно, причина, по которой в мире IPTV производители этих систем не погибли, пожалуй, ровно в том, что наличие этих систем затребовано поставщиками контента. И, более того, наличие совершенно определённых систем, сертифицированных как надёжные. Список их невелик и среди наболее используемых Verimatrix, Irdeto, NDS, Widevine, Viaccess, Nagra. Системы могут работать как с карточками, так и без карточек (смарт-картами, в смысле).

Подсистема Видео по требованию

Подсистема видео по требованию выполняет простую функцию — отдаёт или записывает по требованию (запрос пользователя, программированное событие, etc)
видеоматериалы. Отдаёт по протоколу RTSP, а записывает путём перехвата multicast-групп, таким образом реализуется пауза «живого» эфира и сетевой видеомагнитофон. Сервер подключается к каналу, начинает запись и запись кладёт в список доступных для Видео по требованию материалов.

Когда кто-то хочет посмотреть контент, сервер отдаёт его либо в Unicast (в большинстве случаев) с адреса rtsp://server_adderss:port/asset, либо в Multicast, скажем, для реализации Near Video on Demand. (об услугах мы ещё поговорим отдельно :-)) Услуги как таковые VOD не предоставляет, он просто отдаёт файлы и иногда записывает потоки. Основные производители этих систем — Kasenna, Arroyo, C-COR (бывш. NCube), Concurrent, SeaChange, BitBand.

Сервисная платформа

Более всего на Middleware похожи IP-телефонные Class 5 softswitch’и. Это штука, которая реализует услугу — предоставляет интерфейс пользователя и осуществляет интеграцию всех компонентов. Работает это, например, так. Абонент включает телевизор, ему на экране показывается меню работы с услугами. Это меню взято с сервера middleware. Выбирая просмотр какого-то фильма, middleware обращается в сторону BSS и OSS систем, спрашивая у них, можно ли абоненту посмотреть фильм, есть ли у него для этого средства, подписан ли он на услугу, есть ли ресурсы сервера VoD и сети для предоставления этой услуги. Получив положительные ответы, middleware отдаст адрес фильма на сервере VOD, с этого адреса абонент получит искомый фильм, а middleware снимет деньги со счёта. Примерно так.

Системы middleware очень сложны, обязаны обладать возможностями расширения, написания дополнительных услуг, реализации собственного интерфейса пользователя и прочее-прочее. Собственно, это должна быть платформа, на которой оператор связи напишет собственный пользовательский портал, собственные подпрограммы для реализации своих услуг, прикрутит систему к собственному биллингу, системам проключения услуг (service provisioning), СRM? мониторингу и прочее. Таких систем, к сожалению, очень мало. В большинстве случаев производители middleware постараются «подсадить» клиентов на собственный сервис, дальнейшую поддержку и разработку дополнительных элементов. Это, в свою очередь, привело к большому распространению собственноручно созданных сервисных платформ. Многие из которых, в свою очередь, выделились в отдельные продукты.

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

Производителей этих систем много. Больше, чем кого бы то ни было. Самые именитые — Microsoft, Orca, Minerva, Myrio. Есть и российский производитель — компания Netris (бывший IPSoft, отдел разработки компании CTI). Её решение используется в проекте Стрим-ТВ компании МТУ-Интел.

Системы OSS/BSS

Собственно говоря, тут всё понятно. Как ни крути, в большой сети Вам понадобится система управления услугами, система мониторинга доступности ресурсов, хранилище ресурсов, автоматизированное проключение услуг, биллинг, CRM и всё прочее-прочее. Вот это всё оно и есть.

Абонентские устройства

SetTopBox (буквально, «находящийся сверху») — устройство отображения IPTV на телевизоре. Больше всего похоже на приставку для кабельного или спутникового телевидения, только на задней панели разъём для ethernet, а не коаксиального кабеля. Представляет из себя маленький компьютер под управлением Linux или Windows, с TCP-стеком, браузером или клиентом middleware и MPEG-декодером. Производителей этого хабара огромное количество, наиболее известны в России приставки Amino и Kreatel (ныне Motorola), вообще же в мире хорошо известны также Thomson, Pace, Scientific Atlanta/KiSS, Tilgin (экс-i3micro) и некоторые другие.

Нюанс в использовании STB (так его будем звать) состоит в том, что устройство должно быть тесно интегрировано со всеми компонентами, в используемом ПО должны быть клиенты для Системы защиты контента, для Video on Demand, для сервисной платформы и, возможно, какие-то дополнительные модули, необходимые для работы решения в целом. То есть, это штука изготавливаемая (обычно в смысле софта, по-крайней мере) под конкретный проект. В этом обычно кроется некоторый «облом» — купить на рынке какой-нибудь STB и применить его в проекте не получается. Это не сотовый телефон.

Собственно, техническое введение на этом можно и закончить пока, увидимся через некоторое время, поговорим о том, какие услуги можно развернуть в сети IPTV. Зачем-то люди же всё это затевают?!