Для работы приложения NetUP.tv необходимо наличие сервера Midlleware в составе головной станции IPTV. Однако есть облегченная версия приложения - NetUP.tv Lite. Эта версия приложения не требует наличия сервера Middleware, вещаемый контент принимается из IP-сети по multicast напрямую с DVB-IP стримера. Таким образом, используя приложение NetUP.tv Lite, можно быстро и легко запустить IPTV решение с использованием приставок на базе Android.

Графический интерфейс приложения на Android

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

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

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

PCI-e карты

Профессиональные, высокопроизводительные PCI-e карты для приема спутникового, эфирного или кабельного телевизионного сигнала. Для кодирования и транскодирования видеопотоков в реальном времени для последующей передачи через локальные сети и Интернет.

Universal Dual DVB-CI- Универсальная карта с двумя DVB-C, DVB-C2, DVB-T, DVB-T2, DVB-S, DVB-S2 входами и двумя слотами Common Interface. Профессиональная DVB карта может применяться в DVB-IP шлюзах, системах спутникового интернета, домашних кинотеатрах и других решениях. Два универсальных DVB входа и два слота Common Interface (CI) расположены на одной PCI-e карте, что позволяет сохранить свободное место в сервере. Это особенно актуально в системах с ограниченным количеством свободных слотов. Например, стандартный сервер высотой 1U, с четырьмя слотами PCI-e, может принимать и декодировать контент с 8 транспондеров одновременно: NetUP IPTV Combine 8x или DVB-IP стример 8x.

Transcoder Card - NetUP Transcoder является профессиональным аппаратным решением для кодирования и транскодирования видеопотоков в реальном времени. Транскодер спроектирован для использования в головных станциях IPTV, а также в интернет-телевидении. Netup Transcoder представляет из себя PCI-e карту с двумя входами HDMI и двумя HD-SDI, либо четырьмя входами RCA/RF. Транскодер способен одновременно кодировать 2 HD или 4 SD видеопотока, а также одновременно транскодировать 2 HD или от 2 до 4 SD видеопотоков из MPEG-2 в H.264 и наоборот.

H.264 - высокоэффективный видео-кодек, позволяющий сжимать видео-потоки для передачи через сети с ограниченной пропускной способностью, при этом сохраняя высокое качество видео. Этот кодек удобен для применения, например, при транслировании IPTV через ADSL или беспроводные сети, а также в решениях интернет-телевидения, особенно при передаче видео-потоков в формате HD.

Open Source проекты в области IPTV, CAM-модули для дешифрации принимаемых со спутника каналов

Компания НетАП представляет Open Source проекты в области IPTV. Бесплатное распространение и развитие по лицензиям GPLv2, GPLv3 позволяет участвовать в разработке всем заинтересованным лицам.

NetUP IPTVProbe - система мониторинга

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

С помощью IPTVProbe можно проконтролировать структуру IPTV-потоков и оценить потери пакетов при передаче по сети.

Общая схема организации сети при проведении тестирования

Схема работы зонда (iptvprobe) и коллектора

Сборка и установка пакета

Весь пакет можно условно разделить на следующие составные части:

· Коллектор - собирает статистику с зондов. Статистика накапливается в базе данных (mysql)

· Зонд - удаленный "вынос", который фиксирует проходящие IP-пакеты и передает информацию по сети на коллектор. Зонд состоит из двух подчастей - модуль ядра linux netup_netprobe.ko и пользовательское приложение iptvprobe.

· Подсистема отчетов - Подключается к базе данных и выводит информацию в виде графиков и таблиц.

Сборка и запуск коллектора

Сборка коллектора:

cd iptvprobe/userver/cmake --debug-output. -DCMAKE_VERBOSE_MAKEFILE:BOOL=ONmake

Создание базы данных:

mysqladmin create iptvprobemysql iptvprobe < db.sql

Запуск коллектора:

./iptvprobe_server -l root -s 127.0.0.1

При таком запуске коллектор будет записывать информацию в базу данных "iptvprobe" на локальном хосте (127.0.0.1)

Сборка зонда

Сборка приложения под платформу x86:

cd iptvprobe/udaemon/cmake --debug-output. -DCMAKE_VERBOSE_MAKEFILE:BOOL=ONmake

Сборка модуля ядра под платформу x86:

cd iptvprobe/kmodule/make

Сборка модуля ядра под платформу sh4 (IP STB aminet 130):

cd iptvprobe/kmodule/export CROSS_COMPILE=sh4-unknown-linux-gnu-make ARCH=sh amino130

В директории aminet130_bin/ находятся уже собранные ядро и приложение для AmiNET 130 IP STB.

Запуск зонда

Загрузка модуля ядра linux:

cd iptvprobe/kmodule/insmod netup_netprobe.ko hook_position=0

При помощи параметра hook_position можно регулировать положение перехватчика пакетов:

0 - перехватчик фиксирует все входящие пакеты с сетевого интерфейса (PREROUTING), 1 - исходящие (POSTROUTING).

При запуске модуля на абонентском устройстве (например, Aminet 130) необходимо использовать значение 0 (PREROUTING). В случае если запуск производится на сервере генерирующем мультикаст, необходимо использовать значение 1 (POSTROUTING).

После того как модуль ядра успешно загружен необходимо создать символьное устройство в папке /dev и запустить пользовательское приложение iptvprobe:

mknod /dev/iptvprobe c 61 0cd iptvprobe/udaemon/./iptvprobe -i 224.117.117.10 -s 10.1.4.242 -r 5 -p 7700

Параметры запуска приложения:

-i Sets the multicast address for monitoring-s Specifies the IP address of the collector-p Specifies the port for the collector to accept connections from probes-r Specifies a run identifier

Полностью строку запуска можно увидеть в подсистеме отчетов.

Подсистема отчетов

Для запуска подсистемы отчетов скопируйте веб-скрипты из папки iptvprobe/report_sys/ в папку с cgi-bin скриптами для вашей системы:

cd iptvprobe/report_sys/cp *.pl /var/www/localhost/cgi-bin/

В системе должны быть установлены perl, GD.

Далее необходимо на рабочей станции оператора запустить браузер и перейти по адресу:

http://address/cgi-bin/iptvprobe_runs.pl

где address - адрес сервера с подсистемой отчетов.

Стартовая страница содержит перечень запусков зондов:

В колонке "Command to run on probe" приводится строка запуска приложения-зонда со всеми необходимыми параметрами.

Пройдя по ссылке "UDP timeline graphic" либо "PCR Arrival Interval" можно увидеть графическое представление текущего мультикаст потока (на графике отображаются последние 30 секунд).

На следующих скриншотах отображены тестовые запуски ТВ-канала на Aminet 130, длительностью по 1 часу каждый. В первом случае использовался коммутатор Cisco Catalyst 2950T с поддержкой IGMP Snooping, а во втором случае использовался обычный коммутатор без поддержки IGMP snooping. Как видно во втором случае присутствует существенное количество потерянных IP-пакетов.

Описание графиков:

По оси x отложено время от текущего момента минус 15 секунд.

По оси y откладываются значения:

· Количество зафиксированных IP-пакетов с группировкой по 100 мсек.

· Количество зафиксированных килобайт с группировкой по 100 мсек.

· Красным цветом отмечена линия потери пакетов т.е. если зафиксирован сбой в счетчике "ID-пакета", то на графике рисуется пик. Если потерь нет, то рисуется прямая линия со значением 0.

Описание базы данных

SQL таблица	Описание
runs	Список запусков зонда. Каждый запуск имеет уникальный номер
data_ip	Список IP-пакетов зафиксированных зондом. Фиксируется время (timestamp) прихода пакета в наносекундах. Так же фиксируется ID-пакета (header_id ) для контроля целостности потока
data_ts	Информация о MPEG Transport Stream (TS) пакетах зафиксированных зондом. Для пакетов фиксируются значения PID, PTS/DTS/PCR и значение счетчика непрерывности (cont_counter)
stat_bandwidth	Сгруппированные данные для построения графиков

Мониторинг работы IGMP

В версии iptvprobe v0.3 появилась возможность отслеживать IGMP запросы отправляемые и принимаемые зондом на IP STB. При этом так же фиксируется время получения последнего группового пакета при выходе из группы и первого группового пакета, при вступлении в группу. Используя эти данные, можно судить о качестве работы сетевого оборудования осуществляющего обработку IGMP-запросов и обеспечивающих работу IGMP snooping.

Для примера, рассмотрим работу данного функционала, используя IP STB Aminet 130 и NetUP Middleware. В качестве коммутатора с поддержкой IGMP Snooping выступает Cisco Catalyst 3560, а в качестве IGMP querier выступает Cisco Catalyst C3550-12T.

Проведем переключение ТВ-каналов на IP STB. При этом приставка посылает IGMP-запрос о выходе из мультикаст-группы 224.121.0.4 и затем посылает запрос на вступление в группу 224.121.0.3. Эти запросы фиксируются зондом и отображаются в веб-интерфейсе подсистемы отчетов с указанием временных параметров:

Интересующие нас запросы выделены синей рамкой. Как видно, после отправки IGMP-запроса на выход из группы 224.121.0.4, приставка еще в течение 4996.2 мс получала пакеты для мультикаст-группы 224.121.0.4. Так же видно, что после отправки IGMP-запроса на вступление в группу 224.121.0.3 приставка ожидала 80 мс первый пакет в группу 224.121.0.3. Время между IGMP-запросами составило 12.0 мс (это время по большей части зависит от скорости работы ПО на приставке).

Как видно, для данной конфигурации общее время переключения ТВ-каналов на уровне IGMP-запросов составляет порядка 92 м/сек. Реальное же время появления изображения нового канала на экране телевизора зависит от многих параметров. В частности, от буферизации MPEG-потока, синхронизации аудио-видео и т.д., и может занимать до 1 секунды и более.

Как следует из этих цифр, приставка в течение 4996.2 м/сек получала пакеты для двух мультикаст групп одновременно, что приводит к избыточному потреблению пропускной способности канала. Во избежание таких "накладок" необходимо установить режим моментального выхода из группы на коммутаторе. Для этого в режиме конфигурирования необходимо указать команду:

c3560(config)#ip igmp snooping vlan 1 immediate-leave

В результате такой настройки коммутатор моментально выключает поток для мультикаст-группы, из которой произведен выход. Результаты работы в этом режиме выделены на скриншоте красной рамкой. Как видно после отправки запроса "IGMPv2: Leave Group 224.121.0.11", приставка больше не получала пакетов для группы 224.121.0.11. Таким образом, в момент переключения ТВ-каналов приставка одновременно получает пакеты только для одного канала.

Для корректного фиксирования временных показателей IGMP-запросов на приставке перед запуском зонда необходимо перевести сетевой интерфейс в режим promisc:

# ifconfig eth0 promisc

TODO лист

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

· График "PCR jitter", другие графики

· Сборка зонда под различные IP STB

· Мониторинг доступности зондов для контроля работы сети

NetUP MultiFiles - система распространения файлов

NetUP MultiFiles - это система распространения файлов (прошивок) с использованием UDP multicast. Клиент может скачать новую версию ПО послав IGMP-запрос и подключившись к определенной multicast-группе. После получения файла происходит его проверка на целостность, разархивация и запуск скрипта обновления.

Использование multicast позволяет оперативно передать файл на любое количество клиентов, используя только один поток.

Механизм работы пакета multifiles

Распространяемый файл циклически передается в сеть в виде UDP multicast-потока на определенный multicast-адрес (по умолчанию - 224.2.2.4, порт 2222). При этом клиент, желающий скачать этот файл, подключается к этой группе, посылая IGMP-запрос, и начинает получать этот файл. Как только получен весь файл, клиент отключается от группы и проверяет целостность полученного файла. Если проверка прошла успешно, то производится разархивирование файла (формат.tar.gz) и запуск скрипта customup.sh, который находится внутри полученного архива. Скрипт customup.sh производит обновление нужных файлов, а также другие операции, необходимые для обновления.

Использование multicast позволяет оперативно передать файл на любое количество клиентов, используя только один поток.

Стоит отметить, что клиент не производит обновление, если текущая версия ПО на клиенте такая же, как передаваемая в потоке, или более свежая. В случае если на сервере указан ключ "force update", обновление производится принудительно, вне зависимости от версии ПО.

Схема сети при использовании пакета multifiles.

Описание потока

Поток представляет собой UDP-пакеты, которые содержат заголовок следующего формата:



struct mulfiles_header{

uint32_t message_type;

uint32_t flags;

uint32_t data_size;

uint32_t sequence_no;

uint32_t file_offset;};

message_type может принимать два значения:

#define MF_MTYPE_INFO 0x04030201

#define MF_MTYPE_DATA 0x04030202

Пакеты с типом MF_MTYPE_INFO представляют собой информационные пакеты и содержат информацию о передаваемом файле - в частности, следующую:

struct mulfiles_message_info{

uint32_t file_size;

uint32_t fw_version;

unsigned char md5sum[16];

char filename[1024];

};

Размер файла, версия прошивки, имя файла и MD5-сумма для контроля целостности передачи. Информационные пакеты по умолчанию передаются с интервалом в 2 секунды.

В пакетах с типом MF_MTYPE_DATA находится содержимое передаваемого файла. В заголовке таких пакетов содержится информация о смещении блока передаваемых данных относительно начала файла. Таким образом, клиент может принимать файл с любой удобной позиции, не дожидаясь следующего цикла передачи. Такая логика позволяет максимально быстро принять файл без дополнительных задержек на поиск начала и конца файла. Скорость передачи данных в сеть можно регулировать ключами запуска сервера. По умолчанию скорость равна 100 КБайт/сек.

Описание программы-сервера

Ключи запуска сервера:

multifiles #./mfsrv -h

NetUP's multicast file upload utility (server).

Copyright (c) 2001-2008 NetUP Inc. www.netup.tv.

Compile date: Nov 3 2008 13:22:49

Use this utility at your own risk.

usage:

options

[-i IP] Multicast IP address to use. Default: 224.2.2.4

[-p port] UDP port to use. Default: 2222

[-d] Enable debug messages. Default: disabled

[-f file] name of the file to send. Default: testfile.bin

[-s speed] Upload speed Kbytes/sec. Default: 100 Kbytes/sec

[-t delay] Prophylactic info messages delay, sec. Default: 2 sec

[-u] Setting force update flag. Default: force update flag not set

[-a version] Firmware version. Default: 0

[-h] This help

Пример запуска сервера:

multifiles #./mfsrv -i 224.5.6.7 -p 1111 -f./netup.tgz -s 100 -a 1104 -t 6

Using file:./netup.tgz file name:netup.tgz prophylactic_delay:6

Speed:102400 bytes/sec psleep: 13513

+ Sending file:netup.tgz sequence:1

o Prophylactic info: 1068 bytes from 1068 send to socket:3

o Prophylactic info: 1068 bytes from 1068 send to socket:3

o Prophylactic info: 1068 bytes from 1068 send to socket:3

o Prophylactic info: 1068 bytes from 1068 send to socket:3

o Prophylactic info: 1068 bytes from 1068 send to socket:3

o Prophylactic info: 1068 bytes from 1068 send to socket:3

o Prophylactic info: 1068 bytes from 1068 send to socket:3

o Prophylactic info: 1068 bytes from 1068 send to socket:3

o File:netup.tgz successfully sent

+ Sending file:netup.tgz sequence:2

Как видно из этого примера, производится передача файла netup.tgz в мультикаст-группу 224.5.6.7:1111 со скоростью 100 КБайт/сек. Версия прошивки 1104.

Описание программы-клиента

Ключи запуска клиента:

multifiles #./mfcln -h

NetUP's multicast file upload utility (client).

Copyright (c) 2001-2008 NetUP Inc. www.netup.tv.

Compile date: Nov 3 2008 13:22:48

Use this utility at your own risk.

usage:

options

[-i IP] Multicast IP address to use. Default: 224.2.2.4

[-p port] UDP port to use. Default: 2222

[-t socket wait timeout] UDP socket timeout, sec. Default: 10 sec.

[-d] Enable debug messages. Default: disabled

[-f file] name of the file to save.

Default: using filename coming from server

[-s stat_file] name of the file to save stats in.

Default: /tmp/mfstat.log

[-a fw_version] current fw version. Download is started only

if the received version is newer than current.

Default: 0

[-h] This help

Пример запуска клиента:

Info message received.

sequence:9240

filename:netup.tgz

outfilename:netup.tgz.9240

size:5741931 bytes

Receiving data...

Filling file to required 5741931 bytes, blocks size is:1048576

File filled. Size is:5741931 requested size is:5741931.

Starting write into

First offset:1379

Prophylactic info message received.

filename:netup.tgz

offset:208380

size:5741931 bytes

force update:0

fw_version:1104

Prophylactic info message received.

filename:netup.tgz

offset:615480

size:5741931 bytes

force update:0

fw_version:1104

Prophylactic info message received.

filename:netup.tgz

offset:1022580

size:5741931 bytes

force update:0

fw_version:1104

Prophylactic info message received.

filename:netup.tgz

offset:1431060

size:5741931 bytes

force update:0

fw_version:1104

Prophylactic info message received.

filename:netup.tgz

offset:1838160

size:5741931 bytes

force update:0

fw_version:1104

Prophylactic info message received.

filename:netup.tgz

offset:2245260

size:5741931 bytes

force update:0

fw_version:1104

Prophylactic info message received.

filename:netup.tgz

offset:2653740

size:5741931 bytes

force update:0

fw_version:1104

Prophylactic info message received.

filename:netup.tgz

offset:3060840

size:5741931 bytes

force update:0

fw_version:1104

Prophylactic info message received.

filename:netup.tgz

offset:3467940

size:5741931 bytes

force update:0

fw_version:1104

Prophylactic info message received.

filename:netup.tgz

offset:3875040

size:5741931 bytes

force update:0

fw_version:1104

Prophylactic info message received.

filename:netup.tgz

offset:4283520

size:5741931 bytes

force update:0

fw_version:1104

Prophylactic info message received.

filename:netup.tgz

offset:4690620

size:5741931 bytes

force update:0

fw_version:1104

Prophylactic info message received.

filename:netup.tgz

offset:5097720

size:5741931 bytes

force update:0

fw_version:1104

Prophylactic info message received.

filename:netup.tgz

offset:5506200

size:5741931 bytes

force update:0

fw_version:1104

Prophylactic info message received.

filename:netup.tgz

offset:69000

size:5741931 bytes

force update:0

fw_version:1104

File 'netup.tgz.9240' received. Checking...

e7a646426d66b5df3318ba09f1ae33d2 - our file md5. size:5741931

e7a646426d66b5df3318ba09f1ae33d2 - received md5

MD5 check success

File 'netup.tgz.9240' checked. Success.

Как видно из этого примера, производится прием файла netup.tgz из мультикаст-группы 224.5.6.7:1111. Текущая версия файла 1100, а передаваемая с сервера - 1104.

Создание прошивки

Содержимое папки scripts:

multifiles # ls -al scripts/

total 16

drwxr-xr-x 4 root root 84 Oct 27 13:51.

drwxr-xr-x 5 root root 4096 Oct 27 15:36..

-rwxr-xr-x 1 root root 115 Oct 27 13:51 createfw.sh

-rwxr-xr-x 1 root root 187 Oct 27 13:42 customup.sh

drwxr-xr-x 3 root root 35 Oct 27 13:51 firmware

-rwxr-xr-x 1 root root 889 Oct 27 13:39 update.sh

Скрипт createfw.sh используется для создания прошивки. Пример такого скрипта:

multifiles # cat scripts/createfw.sh

FWPATH="firmware"

FWNAME="mf_fw.tgz"

(cd $FWPATH; tar cvfz../$FWNAME./*)

echo "Firmware created. File: $FWNAME"

Cкрипт архивирует содержимое папки firmware в файл mf_fw.tgz. Этот файл в дальнейшем будет передаваться через мультикаст, как описано выше.

Папка scripts/firmware/ содержит файлы, необходимые для обновления, и скриптcustomup.sh, который выполняет необходимые действия на стороне клиента после скачивания. Простой пример такого скрипта:

multifiles # cat scripts/firmware/customup.sh

echo "Running custom upgrade shell script... Please, wait"

echo "Copying new files... "

cp stb_client/bin/stb_client /netup/stb_client/bin/stb_client

echo "Updating config files... "

Cкрипт копирует новые файлы и при необходимости обновляет конфигурационные файлы.

Работа с прошивкой на клиенте

Пример скрипта, организующего прием и обработку прошивки на клиенте (пример приведен для IP STB):

multifiles # cat scripts/update.sh

MFPATH="/mfupdater"

NEPATH="/netup"

DSTPATH=$MFPATH/dst

STATFILE="/tmp/mfstat.log"

# Show update splash screen

cat $MFPATH/updatesp.bmp > /dev/fb0 2>/dev/null

# get current ver

if [ -f $NEPATH/version ]; then

export CURVER=`cat $NEPATH/version`

else

export CURVER=0

fi

$MFPATH/mfcln -s $STATFILE -t 3 -i 224.5.6.7 -p 1111

-f $MFPATH/download.bin -a $CURVER

if [ $? -eq 0 ]; then

echo "Updating software... "

# Create dst path

mkdir $DSTPATH 2>/dev/null



# unbzip received file into /netup

cd $DSTPATH

cat $MFPATH/download.bin | tar -xz

# run custom script in received file

cd $DSTPATH

sh customup.sh

# save new version

if [ -f $STATFILE ]; then

cat $STATFILE > $NEPATH/version

fi

# cleanup dst dir if required. You can do this in customup.sh

echo "Update done. New fw version:"

cat $NEPATH/version

fi

Cкрипт выполняет следующие шаги:

· Получает текущую версию ПО. Версия хранится в файле /netup/version;

· Запускает получение прошивки из мультикаст-группы;

· Если файл получен успешно, то производится его разархивирование и запуск скрипта customup.sh, находящегося в этом архиве. Этот скрипт производит необходимые действия по копированию файлов, обновлению конфигурации и т.д. (пример такого скрипта приведён выше);

· Новый номер версии сохраняется в файл /netup/version. Следующее обновление произойдет в случае имзенения версии прошивки на сервере либо если указан ключ "force update" на сервере.

Бинарные сборки

В архиве доступны готовые бинарные сборки для следующих платформ:

· SH-4

· Mipsel uclibc

· ARM9

· PPC

· x86

Производителям IP STB

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

CAM-модули

CAM-модуль содержит алгоритм дешифрации принимаемых со спутника каналов. Он характеризуется количеством одновременно раскодируемых телевизионных каналов и перечнем поддерживаемых систем сокрытия.

PowerCam Pro (v. 4.3)

Тестирование PowerCam Pro подтвердило способность одновременного раскрытия 12-ти каналов одним модулем такого типа. Суммарный битрейт составляет около 34 МБит/сек. На данный момент это один из лучших показателей производительности среди CAM-модулей. Данный модуль условного доступа позволяет раскрыть все каналы с одного транспондера.

Поддерживаемые системы сокрытия:

· Viaccess (CAID: 0x500);

· Irdeto (CAID: 0x600, 0x601, 0x602, 0x603, 0x626, 0x606, 0x608, 0x620, 0x622, 0x624, 0x604, 0x628, 0x614, 0x668, 0x619);

· CryptoWorks (CAID: 0xd00, 0xd01, 0xd02, 0xd03, 0xd04, 0xd05, 0xd06, 0xd07, 0xd08, 0xd0c, 0xd0f, 0xd22, 0xd70);

· BetaTechnik (CAID: 0x1702, 0x1722, 0x1762);

· Norwegian Telekom (CAID: 0xb00, 0xb01, xb02);

· SIDSA (CAID: 0x4aa0, 0x4aa1);

· Canal Plus (CAID: 0x100).

SMiT Irdeto Pro 8

CAM - модуль условного доступа для приема каналов в кодировке Irdeto (Орион Экспресс, Радуга-ТВ) под ресиверы с Common Interface. Стандарт PCMCIA. Способен открывать до 8 каналов.

Лицензионный профессиональный CAM - модуль условного доступа (CA-модуль) для приема каналов в кодировке Irdeto (Орион Экспресс, Радуга-ТВ) под ресиверы с Common Interface. Стандарт PCMCIA. Способен открывать до 8 каналов (до 20 pid).

CAM - модуль полностью совместим с кодировкой: Irdeto/Irdeto 2, включая Irdeto M-Crypt. Полная поддержка смарт-карт кодировки Ирдето: Epsilon Irdeto card, Delta Irdeto card, Zeta Irdeto Card (включая и более ранние).

Поддержка скоростей потока до 44950 при 7/8.

SMiT Viaccess Pro 8

CAM - модуль условного доступа для приема каналов в кодировке Viaccess (НТВ-Плюс) под ресиверы с Common Interface. Стандарт PCMCIA. Способен открывать до 8 каналов.

Лицензионный профессиональный CAM - модуль условного доступа (CA-модуль) для приема каналов в кодировке Viaccess (НТВ-Плюс) под ресиверы с Common Interface. Стандарт PCMCIA. Способен открывать до 8 каналов (до 20 pid).

6. Протоколы IP-TV

RTSP (Real-Time Streaming Protocol) -- это протокол, с возможностью контролируемой передачи видео-потока в интернете. Протокол обеспечивает пересылку информации в виде пакетов между сервером и клиентом. При этом получатель может одновременно воспроизводить первый пакет данных, декодировать второй и получать третий.

Протокол из этой же группы RTP (Real-time transport protocol) определяет и компенсирует потерянные пакеты, обеспечивает безопасность передачи контента и распознавание информации. Вместе с RTP работает протокол RTCP (Real-Time Control Protocol). Он отвечает за проверку идентичности отправленных и полученных пакетов, идентифицирует отправителя и контролирует загруженность сети.

Для присоединения к сети или выхода из группы рассылки используется стандартный протокол IGMP (Internet Group Membership Protocol).

Сформированный IPTV головной станцией поток телевизионных каналов представляет собой поток IP-пакетов, передаваемых в сети по отдельному групповому IP-адресу, соответствующему данному телеканалу. Таким образом, вещание нескольких каналов представляет собой формирование нескольких потоков multicast-трафика, когда каждый из каналов однозначно определяется уникальным адресом групповой рассылки. При использовании MPEG-2 как наиболее распространенного формата цифрового сжатия видео-данных, каждый телевизионный канал занимает в IP-сети от 3,5 до 6 Мбит/с. Сеть оператора загружается телевизионным каналом только в том случае, если имеется подписчик на этот канал, который выбрал его для просмотра, то есть запросил его просмотр в данный момент. Передача выбранного абонентом IP-сети телевизионного канала реализуется на базе технологии IP-multicast или для случая просмотра видео по заказу на базе IP-unicast.

Для обеспечения минимальных задержек и гарантированной скорости передачи видеоданных в IP-сети используется поддержка Quality of Service (QoS), для чего может использоваться, например, известный протокол RSVP (Resource Reservation Protocol), который обеспечивает резервирование необходимой ширины полосы в канале. Используется предоставление маршрутизаторам сети общих характеристики трафика (например, скорость передачи данных, вариабельность). Маршрутизаторы сводят затем воедино запросы на выделение ресурсов на общих участках маршрутов движения видеотрафика.



7. Структура пакета для видеопотока

Структура IP пакета

Internet Protocol (IP, досл. «межсетевой протокол») -- маршрутизируемый протокол сетевого уровня стека TCP/IP. Именно IP стал тем протоколом, который объединил отдельные компьютерные сети во всемирную сеть Интернет. Неотъемлемой частью протокола является адресация сети.

IP объединяет сегменты сети в единую сеть, обеспечивая доставку пакетов данных между любыми узлами сети через произвольное число промежуточных узлов (маршрутизаторов). Он классифицируется как протокол третьего уровня по сетевой модели OSI. IP не гарантирует надёжной доставки пакета до адресата -- в частности, пакеты могут прийти не в том порядке, в котором были отправлены, продублироваться (приходят две копии одного пакета), оказаться повреждёнными (обычно повреждённые пакеты уничтожаются) или не прийти вовсе. Гарантию безошибочной доставки пакетов дают некоторые протоколы более высокого уровня --транспортного уровня сетевой модели OSI, -- например, TCP, которые используют IP в качестве транспорта.

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

· Версия -- для IPv4 значение поля должно быть равно 4.

· IHL -- (Internet Header Length) длина заголовка IP-пакета в 32-битных словах (dword). Именно это поле указывает на начало блока данных в пакете. Минимальное корректное значение для этого поля равно 5.

· Длина пакета -- длина пакета в октетах, включая заголовок и данные. Минимальное корректное значение для этого поля равно 20, максимальное -- 65 535.

· Идентификатор -- значение, назначаемое отправителем пакета и предназначенное для определения корректной последовательности фрагментов при сборке пакета. Для фрагментированного пакета все фрагменты имеют одинаковый идентификатор.

· 3 бита флагов. Первый бит должен быть всегда равен нулю, второй бит DF (don't fragment) определяет возможность фрагментации пакета и третий бит MF (more fragments) показывает, не является ли этот пакет последним в цепочке пакетов.

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

· Время жизни (TTL) -- число маршрутизаторов, которые может пройти этот пакет. При прохождении маршрутизатора это число уменьшается на единицу. Если значение этого поля равно нулю, то пакет должен быть отброшен, и отправителю пакета может быть послано сообщение Time Exceeded (ICMP тип 11 код 0).

· Протокол -- идентификатор интернет-протокола следующего уровня указывает, данные какого протокола содержит пакет, например, TCP или ICMP (см. IANA protocol numbers и RFC 1700). В IPv6 называется «Next Header».

· Контрольная сумма заголовка -- вычисляется в соответствии с RFC 1071

8. Видеопоток

Видеопоток - это временная последовательность кадров определенного формата, закодированная в битовый поток. Скорость передачи несжатого видеопотока с чересстрочной разверткой разрядностью 10 бит и цветовой субдискретизацией 4:2:2 стандартной четкости будет составлять 270 Мбит/с. Такой поток получается, если сложить произведения частоты дискретизации на разрядность каждой компоненты: 10 Ч 13,5 + 10 Ч 6,75 Ч 2 = 270 Мбит/с. Однако, расчет размера получаемого файла, содержащего несжатый видеопоток, производится несколько иначе. Сохраняется только активная часть строки видеосигнала. Для представления в пространстве Y', Cr, Cb рассчитываются следующие составляющие:

· количество пикселей в кадре для яркостной компоненты = 720 Ч 576 = 414 720

· количество пикселей в кадре для каждой цветностной компоненты = 360 Ч 576 = 207 360

· число битов в кадре = 10 Ч 414 720 + 10 Ч 207 360 Ч 2 = 8294400 = 8,29 Мбит

· скорость передачи данных (BR) = 8,29 Ч 25 = 207,36 Мбит / сек

· размер видео = 207,36 Мбит / сек * 3600 сек = 746 496 Мбит = 93 312 Мбайт = 93,31 Гбайт = 86,9 ГиБ

Расчёт скорости передачи данных:

Для формата 4:2:2

BR = BD Ч (W + 0,5 Ч W Ч 2) Ч H Ч FR = BD Ч 2 Ч W Ч H Ч FR

Для формата 4:1:1



BR = BD Ч (W + 0,25 Ч W Ч 2) Ч H Ч FR = BD Ч 1,5 Ч W Ч H Ч FR

Для формата 4:2:0

BR = BD Ч (W Ч H + 0,5 Ч W Ч 0,5 Ч H Ч 2) Ч FR = BD Ч 1,5 Ч W Ч H Ч FR

Для формата 4:4:4

BR = BD Ч 3 Ч W Ч H Ч FR

BR - скорость передачи данных, бит/с,

W и H - ширина и высота кадра в пикселях,

BD - разрядность для каждой компоненты, бит на пиксель

FR - кадровая частота, кадров/с

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

Скорость передачи несжатого видеопотока

Размер кадра (пикселей)	Глубина цвета (бит)	Дискретизация	Кадровая частота (Гц)	Битрейт (Мбит/с)	Требуемая ёмкость (ГиБ/час)
720 Ч 576	10	4:2:2	25	207	86.9
720 Ч 576	8	4:1:1, 4:2:0	25	124	52.1
1280 Ч 720	8	4:2:2	25	369	154.5
1280 Ч 720	8	4:2:2	50	737	309
1280 Ч 720	10	4:2:2	25	461	193.1
1920 Ч 1080	10	4:2:2	25	1037	434.5

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

Сжатие видео -- технология цифровой компрессии телевизионного сигнала, позволяющая сократить количество данных, используемых для представления видеопотока. Сжатие видео позволяет эффективно уменьшать поток, необходимый для передачи видео по каналам радиовещания, уменьшать пространство, необходимое для хранения данных на носителе. Недостатки: при использовании сжатия с потерями появляются характерные, иногда отчётливо видные артефакты -- например, блочность (разбиение изображения на блоки 8x8 пикселей), замыливание (потеря мелких деталей изображения) и т. д. Существуют и способы сжатия видео без потерь, но на сегодняшний день они уменьшают данные недостаточно.

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

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

Помимо сжатия с потерями видео также можно сжимать и без потерь. Это означает, что при декомпрессии результат будет в точности (бит к биту) соответствовать оригиналу. Однако при сжатии без потерь невозможно достигнуть высоких коэффициентов сжатия на реальном (не искусственном) видео. По этой причине практически всё широко используемое видео является сжатым с потерями (в том числе на потребительских цифровых видеодисках, видео хостингах, в спутниковом вещании). На веб-сайтах для маленьких роликов без звука иногда используются простые форматы GIF и APNG.

Одна из наиболее мощных технологий, позволяющая повысить степень сжатия, -- это компенсация движения. При любой современной системе сжатия видео последующие кадры в потоке используют похожесть областей в предыдущих кадрах для увеличения степени сжатия. Однако, из-за движения каких-либо объектов в кадре (или самой камеры) использование подобия соседних кадров было неполным. Технология компенсации движения позволяет находить похожие участки, даже если они сдвинуты относительно предыдущего кадра.

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

Съемка и доставка программных материалов

Видеоданные, полученные при съемке, могут компрессироваться для упрощения устройств записи и хранения и систем передачи. Эта компрессия является компрессией первого поколения.

Требования:

- кодирование - внутрикадровое;

- структура дискретизации - YCrCb 4:2:2;

- квантование - 8 или 10 бит на отсчет одного компонента изображения;

- пространственное разрешение - 1280Ч720p, 1920Ч1080i или 1920Ч1080p;

- целевая скорость потока - 100…300 Мбит/с.

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

Требования:

- кодирование - внутрикадровое или межкадровое;

- структура дискретизации - YCrCb 4:2:2 или 4:2:0;

- квантование - 8 или 10 бит на отсчет одного компонента изображения;

- пространственное разрешение - 1280Ч720p, 1440Ч1080i, 1920Ч1080i;

- целевая скорость потока - 25…150 Мбит/с.

IPTV и загрузка контента через Интернет

Сохранение качества изображения полного разрешения на удовлетворительном уровне при передаче по сетям передачи данных, использующих стек протоколов TCP/IP, - одна из трудных, но достижимых задач.

Загружаемые видеоматериалы могут наблюдаться на экране телевизора, подключенного к компьютеру. Уже появляются телевизоры с интерфейсом Ethernet для прямого воспроизведения медиаданных, получаемых из сетевых источников (например, YouTube). Применяемые системы компрессии должны допускать программную реализацию и обладать наивысшей эффективностью, это - компрессия пятого поколения.

Требования:

- кодирование - межкадровое;

- структура дискретизации - YCrCb 4:2:0;

- квантование - 8 бит на отсчет одного компонента изображения;

- пространственное разрешение - 1280Ч720p, 1440Ч1080i, 1920Ч1080i;

- целевая скорость потока - 1…14 Мбит/с.

9. Мобильное телевидение

Устройства воспроизведения мобильного телевидения (сотовые телефоны, карманные компьютеры) имеют экраны небольшого разрешения, например CIF, QCIF, QVGA. Применяемые системы компрессии должны обладать очень высокой эффективностью, работать при малых скоростях потока видеоданных и поддерживать масштабирование.

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

Требования:

- кодирование - межкадровое;

- структура дискретизации - YCrCb 4:2:0;

- квантование - 8 бит на отсчет одного компонента изображения;

- сокращенное пространственное разрешение;

- целевая скорость потока - менее 1 Мбит/с.

Данные о поддержке разных форматов представления изображения и использовании разных видов кодирования в кодеках различных систем видеокомпрессии приведены в табл. 1. Были рассмотрены следующие системы видеокомпрессии:

DV, MPEG-2, MPEG-4 - ASP (Advanced Simple Profile), AVC, H.264, AVS, VC-1, JPEG2000. Сопоставляя параметры систем компрессии и требования рассмотренных выше технологических процессов, можно оценить области применения кодеков разных систем (табл. 2). Как видно из данных таблиц, все системы могут применяться в нескольких технологических процессах. Очевидно, что нет системы компрессии, которая могла бы применяться абсолютно во всех сферах современного цифрового телевидения и кинематографа. Однако можно отметить, что наиболее длинным рядом возможных прикладных областей обладают кодеки системы H.264/AVC.

Важнейшей частью программно-аппаратного комплекса IPTV является система Middleware, рис №4, так как именно с ее графическим интерфейсом приходится взаимодействовать абоненту услуг интерактивного телевидения. Существует два основных варианта реализации этой системы с точки зрения взаимодействия с конечным оборудованием клиента. Самый простой - это использовать встроенный в клиентскую приставку веб-браузер. Отсюда вытекают ограничения наложенные этим самым браузером, - неполное использование возможностей IP- STB и, следовательно, снижение быстродействия. Другой вариант - низкоуровневая система Middleware (на C/С++), использующая возможности IP-STB по максимуму. Базовый графический интерфейс и разнообразный программный функционал находятся на самой приставке, а не на сервере. Этим снимаются проблемы скудных возможностей браузера, и значительно улучшается быстродействие того же интерфейса

Система сокрытия, CAS/DRM, рис №5, позволяет производить шифрование мультимедийных потоков и затем передавать их по незащищенным каналам связи. Только авторизованные абоненты, подписанные на данную услугу, смогут воспроизводить такие потоки. Именно благодаря системе сокрытия, оператор IPTV может четко контролировать доступ к контенту и строить финансовые взаимоотношения с абонентами. Система условного доступа состоит из двух компонентов - серверного и клиентского. Клиентская часть загружается в IP-STB и осуществляет дешифрование потока. Параллельно ведется процесс обновления ключей с серверной части. Серверная часть занимается шифрованием и контролем IP-потоков, генерацией разовых ключей и управлением подписками.



Литература

1. Барсков А.Г. ТВ в сетях IP // Сети и системы связи. 2004. №11

2. Кузовкова Т.А. Состояние и перспективы развития рынка услуг связи в области телерадиовещания // Вестник связи. 2004. №1.

3. Песков С.Н. Интерактивные мультимедийные кабельные сети // ИКС. 2004. №1

Размещено на Allbest.ru