Iptv отстает от аналогового ТВ

Содержание

Дейта Плюс
+7 (916) 296-38-88
123007, Москва, 2й Силикатный пр-д,
д.14, корп.2,стр.14

Качество IPTV услуг

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

Определение QoE и QoS

Одним из ключевых требований к сети IPTV, обеспечивающей высокий уровень качества, является внедрение системы измерений качества услуг (qualitu of experience, QoE), которая будет четко отслеживать и измерять восприятие услуг абонентами. Это относится не только к качеству картинки, но может также охватывать другие области, такие как удобство использования, быстрота реагирования на запрос абонента и т.п. . Другие факторы, такие как плохое качество сжатия исходного сигнала, проблемы с IP пакетами, задержки, неправильные настройки сети, также могут влиять на уровень QoE и приводить к увеличению недовольства абонентов.

Как самому создать IPTV плейлист с нуля!?

Наиважнейшей целью QoS, относящейся к сетевой инфраструктуре, в отличие от QoE, является обеспечение приоритетов, включая выделения полосы (необходимо учитывать разные методы сжатия, разрешение картинки и т.п.), контролируемого джиттера, задержек (время с начала отправки пакета с головной станции до поступления в абонентский приемник) и уменьшение потерь пакетов (как часто пакеты теряются, сколько пакетов теряется). Распределение приоритетов не должно вести к тому, что сервисы с более низким уровнем приоритета будут недоступны в сети. Рассмотрим некоторые факторы, приводящие к уменьшению уровня QoE и QoS.

Очередность пакетов

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

Предположим, сервер IP вещания посылает мультикаст пакеты ТВ программы, сжатой в H.264, с постоянным битрейтом (constant bitrate, CBR) 2.5 Мб/с. Некоторые возможные узкие места сети показаны на рис.1

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

Smart TV BOX или DVB-T2 тюнер. Что выбрать после отключения Аналогового ТВ сигнала?

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

Третий сценарий более близок к тому, что происходит в реальной IP сети, используемой для предоставления triple-play IP услуг. При этом сценарии VoIP, IPTV и WEB одновременно присутствуют в сети. В такой сети межпакетные интервалы всех трех потоков, приходящих на маршрутизатор, более менее одинаковы.

Т.к. маршрутизатор не может обрабатывать все пакеты одновременно, то формируется очередь, и пакеты помещаются в буферную память, до момента, когда по ним будет принято решение об отправке на нужный порт. В этом примере очередь переполняет буфер, и пакеты, относящиеся к данным Internet, отбрасываются. В свою очередь, потоки VoIP и IPTV услуг сохранят межпакетные интервалы.

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

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

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

Джиттер пакетов видео услуг

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

Это достигается усложненной синхронизацией между декодером в абонентском устройстве и кодером в IPTV головной станции. Отклонения фактического от ожидаемого времени поступления пакета (раньше или позже) называют джиттером (jitter). Рисунок 2 показывает к чему может приводить эффект джитерра для IPTV потока.

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

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

Еще по теме: Как обновить gs 8306 по Триколор ТВ

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

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

Рассмотрим более детально задержки и джиттер. К примеру, возьмем поток видео SPTS с

полосой 4.7 Mbps.
на 1 кадр Ethernet пакет приходится 7 DVB пакетов, т.е. 7 х 188 = 1316 байт
инкапсуляция IP/UDP/RTP потребует еще 54 байта на заголовки
теоретически 1 Ethernet кадр длиной 1370 байт дает полосу 4.886 Mbps
поток Ethernet (кадров в секунду) = 4.886.000 (битрейт) / 8 (бит в байте) * 1370 (байт в кадре) = 445.8 кадров в секунду
интервал между кадрами 1/445.8 = 0.00224 секунды

В идеале видео пакеты должены поступать в декодер с интервалом 2.24 мсек. Любое отклонение от этого идеала ведет к необходимости применения буфера. Если с фиксированным отклонением еще можно бороться, то с переменным отклонением (джиттером) не все так просто. На него влияет структура IP сети, размер буферов маршрутизаторов, а так же степень поддержки QoS абонентским устройством.

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

Буферы абонентских устройств

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

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

Источник: shs-systems.ru

Как организовать IPTV-трансляцию?

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

Аренда выделенного сервера

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

Intel® Xeon® E3-1230 v2, 3,3 GHz/4core
3.3 , 4 ядра
8Gb DDR3
2 x SSD: 480Gb, Ent
2 x SATA3: 1 TB

Недорогой, выделенный сервер, для задач средней сложности.

Intel® Xeon® E3-1270 v2, 3,5 GHz/4core
3.5 , 4 ядра
32Gb DDR3
2 x SSD: 480Gb, Ent
2 x SATA3: 1 TB

Хорошее решение, для задач средней ложности.
Любой выбранный сервер, всегда можно улучшить в процессе работы, если вы поймете что вам не достаточно производительности.

Intel® Xeon® E3-1240 v6, 3,7 GHz/4core
3.7 , 4 ядра
32Gb DDR4
2 x SSD: 480Gb, Ent
2 x SATA3: 2 TB

Аренда сервера для удаленного доступа и 1С.
Позволит экономить и безопасно работать на арендованном сервере, через удаленный рабочий стол и Веб браузер.

Что было дано?

Как организовать IPTV-трансляцию

Спутниковые ресиверы от PBI (DCH4000Р) мы использовали, как потоковый источник. Поскольку при использовании одного такого ресивера можно получать только 6 выходных каналов мультикаста, возникла необходимость в дополнительном железе. Выбор пал на девайс производства СпецТВ IP StreamerIPS01 (Одесса). Таким образом, поток предполагалось брать с ASI-выхода, но не по IP.

Представленный девайс оснащен шестью ASI-входами, на которые было решено организовать подачу шести потоков с PBI-ресиверов. Поскольку все каналы у нас находятся в рамках потока, а порт стримера на выходе рассчитан на гигабайт, пришлось подумать о том, как организовать для пользователя подачу ограниченного числа каналов (то есть не всех 60) на интерфейс сети, что естественным образом при потоке примерно в 300Мбит/сек «забило» бы целиком пропускную способность. То есть, по сути, должен был выводиться только один канал, который будет запрашивать пользователь клиентской машины.

Вообще имелась возможность реализовать подобное, используя D-Link-коммутаторы, однако имея прецеденты с их недостаточно удовлетворительной работой в качестве querier, приняли решение обзавестись для этих целей коммутатором FoxGateS6224(S2).

Передача абонентам должна осуществляться посредством D-Link DES3526-коммутатора. Общую схему коммутации можно на скорую руку обрисовать примерно так:
6 DCH-4000P-ресиверов, идут параллельным подключением к ASI (IPS01), далее -> Ethernet (FoxGateS6224(S2) -> коммутатор D-Link(DES3526) -> параллельное распределение на несколько клиентских машин).

Проведение настройки

Для настройки ресиверов была использована самая обычная схема отладки ресиверов сигнала со спутников. Стример настраивали «ручками» — выбирали в браузере каждый канал и присваивали ему мультикастовый адрес (239.255.Х.Х). В данном случае считаем бессмысленным подробное описание процесса настройки оборудования.

Конфигурируем Querier FoxgateS6224-S2. 10.0.0.10 — адрес используемого коммутатора. Здесь необходимо выполнить следующие процедуры:

1. Создание отдельного vlan-а:

2. Включение контроля мультикастового потока:

3. Настройка соответствующих портов:

Intеrface Ethеrnet0/0/2
switchpоrt аccеss vlаn 382
.
.
.
!
Inteеrface Ethеrnet0/0/24
switchpоrt accеss vlаn 382

Еще по теме: 7 ТВ как найти

4. Порт 25 обращен к стримеру, когда 26-порт – к коммутатору. Исходя из этого необходимо произвести следующие настройки:

Intеrface Ethеrnet0/0/25
switchpоrt accеss vlаn 382
!
Interfаce Ethеrnet0/0/26
switchpоrt mоde trunk

5. Теперь переходим к включению igmp snooping. Здесь необходимо указать, что порт vlan, который мы создали функционирует как мультикастовый:

iр igmр snооping
iр igmр snооping vlаn 382

6. Далее потребуется включить фнкцию querier с указанием источника, которым является непосредственно устройство-коммутатор:

iр igmр snооping vlаn 382 l2-gеnеral-quеrier
iр igmр snооping vlаn 382 l2-genеral-quеrier-source 10.0.0.10

Теперь можно сказать, что мы завершили настройку querier. Далее переходим к конфигу нашего коммутатор D-Link (с использованием портов 25,26 для uplink):

1. Для начала необходимо включить igmp snоорing и сообщить о том, что созданный и vlan 382 функционирует, как мультикастовый:
enable igmp_snooping
creаte igmр_snооping multicаst_vlаn multicаst 382

2. Теперь укажем на то, что порты с 1 по 24 являются абонентскими, а порты 25 и 26 задействуются, как источник:

cоnfig igmр_snооping multicаst_vlаn multicаst stаte enаble replаce_sоurce_iр 0.0.0.0 mеmber_pоrt 1-24 sоurce_pоrt 25-26

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

cоnfig igmр_snооping multicаst hоst_timeоut 260 rоuter_timeоut 260 leаve_timеr 2 stаte enаble
cоnfig igmр_snооping quеrier multicаst quеry_intеrval 125 mаx_respоnse_timе 10 rоbustness_variаble 2
cоnfig igmр_snoоping quеrier multicаst last_mеmber_quеry_intеrval 1 stаte disаble

4. Теперь в качестве профилактики для магистральных портов нужно отключить функцию фильтеринга:

cоnfig limitеd_multicаst_аddr pоrts 25-26 аccess dеnу stаte disаble

5. Далее необходимо перекрыть клиентам доступ к вещанию своих каналов (то есть эти каналы никому не будут доступны для просмотра):

cоnfig multicаst pоrt_filtеring_mоdе 1-24 filtеr_unrеgistered_grоups
cоnfig multicаst pоrt_filtеring_mоdе 25-26 forwаrd_unrеgistered_grоups

В сущности настройка коммутатора окончена. После этого необходимо будет создать плейлист channеls.m3u, который будет заполнен следующим образом:

Теперь можно открыть этот список, к примеру, vlс и получать удовольствие от просмотра.

Как смотреть IPTV на конфиге: сервер под Ubuntu, внешний IP-адрес с точкой доступа, используемый в качестве сетевого роутера

Для этих целей прекрасно подошел igmproxy, только изначально возник ряд неприятных проблем, таких как рассыпание картинки или невозможность просмотра с использованием wi-fi (при наличии среднескоростной точки доступа мультикаст создает перегрузку).
Лучшим решением данной проблемы стало преобразование потока UDP в НТТР, что можно осуществить посредством такой программки, как udprxy.
Алгоритм действий в данном случае следующий:

1. Необходимо установить и создать скрипт для старта:

if [ -n «`pidоf udpxу`» ] ;thеn
/usr/bin/killаll udpху > /dev/null 2>https://www.depohost.ru/news/7822/» target=»_blank»]www.depohost.ru[/mask_link]

Анализ времени переключения каналов iptv Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Али Раад А.М.

Цифровое телевидение в сетях передачи данных по протоколу IP (технология IPTV — Internet Protocol Television) находит все более широкое применение по всему миру, в том числе, в России. Главным достоинством IPTV является интерактивность и возможность предоставления пользователям широкого набора дополнительных услуг, связанных с потреблением контента.

При просмотре телевизионной программы во время рекламной паузы пользователь может переключаться на просмотр программ по другим каналам. Технология использует многоадресную передачу и проблема заключается в том, что в приставках STB (Set-Top-Box) пользователю немедленно доступно только часть каналов и задержки при переключении каналов неизбежны, когда пользователь выбирает новый канал. Форум DSL (Digital Subscriber Line) рекомендовал, чтобы время переключения каналов не превышало двух секунд. Pассмотрены схема и алгоритм переключения каналов , процедура обмена сигнальными сообщениями, параметры задержек на различных участках тракта, процедура оценки суммарной задержки при переключении каналов . По результатам расчетов построены зависимости длительности переключения каналов от таких параметров, как число пользователей, которые одновременно просматривают один и тот же канал, размер групп видеокадров, доля потока IPTV в общем трафике в сети доступа.

i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Анализ времени переключения каналов iptv»

Анализ времени переключения каналов IPTV

Ключевые слова: протокол IP, телевизионные каналы, задержки, переключение каналов.

При просмотре телевизионной программы во время рекламной паузы пользователь может переключаться на просмотр программ по другим каналам. Технология использует многоадресную передачу и проблема заключается в том, что в приставках STB (Set-Top-Box) пользователю немедленно доступно только часть каналов и задержки при переключении каналов неизбежны, когда пользователь выбирает новый канал. Форум DSL (Digital Subscriber Line) рекомендовал, чтобы время переключения каналов не превышало двух секунд. Pассмотрены схема и алгоритм переключения каналов, процедура обмена сигнальными сообщениями, параметры задержек на различных участках тракта, процедура оценки суммарной задержки при переключении каналов. По результатам расчетов построены зависимости длительности переключения каналов от таких параметров, как число пользователей, которые одновременно просматривают один и тот же канал, размер групп видеокадров, доля потока IPTV в общем трафике в сети доступа.

Еще по теме: Заставка на ТВ пример

Быстрое распространение высокоскоростного доступа в Интернет на базе широкополосных сетевых технологий разрушает стену между телекоммуникациями и вещанием [1]. IPTV является одним из ключевых приложений на телекоммуникационном рынке, которое позволяет телефонным компаниям извлекать доходы из доставки видео по 1Р-сетям. В настоящее время идет активное коммерческое внедрение IPTV по всему миру [2].

IPTV представляет собой новую форму цифровых технологий телевидения [3]. В этой системе услуги цифрового телевидения доставляются потребителям через сеть инфраструктуры с использованием Интернет-протокола. IPTV относится к классу мультимедийных услуг, таких как телевидение, видео, аудио, текст, графика, данные.

В IP-сетях удалось обеспечить требуемый уровень качества обслуживания и восприятия, безопасность, интерактивность и надежность [4]. IPTV использует многоадресную передачу и основная проблема заключается в том, что все каналы не могут быть одновременно переданы из-за нехватки пропускной способности сети между последним маршрутизатором и домашними шлюзами [5]. Таким образом, только часть каналов сразу же доступна на STB и задержки неизбежны, когда пользователь выбирает новый канал.

Общая процедура переключения каналов

Качество восприятия определяется как общая приемлемость приложения или службы, субъективно воспринимаемых конечным пользователем [6]. Клиенты хотят, чтобы переключение каналов IPTV было быстрым, без блокировок и каких-либо перерывов. С этой точки зрения качество восприятия (Quality of experience — QoE) является наиболее важ-

ным параметром для IPTV-услуг. Время переключения каналов рассматривается как ключевой элемент мегрической группы качества восприятия IPTV [7].

В соответствии с требованиями QoE DSL Forum, время переключения должно быть ограничено максимум 2 секундами [8-12]. ITU-T FG IPTV также рассматривает его как одну из QoE-метрик. Время переключения каналов, как правило, занимает до 1 секунды для MPEG-2 и целых 2 секунды -для H.264/MPEG-4 AVC. Время переключения каналов может быть определено как разница во времени между текущим просмотром канала и отображением первого кадра нового канала на экране телевизора. Таким образом, быстрое и надежное время переключения каналов является важным фактором в качестве восприятия в групповых системах 1PTV.

Время переключения канала состоит из времени обработки команды на переключение канала, сетевой задержки, STB задержки буфер-джитгера и задержки декодирования видео (рис. 1).

Время обработки команды — это задержка между моментом времени, когда пользователь начинает процесс выбора нового канала и моментом времени, когда сообщение IGMP (Internet Group Management Protocol) будет передано в сеть.

Сетевая шдержки — это время, необходимое для передачи запрошенного потока после передачи сигнала IGMP-регистрацня сообщения.

Задержка в буфере джиттера STB необходима, чтобы удалить запаздывания при передачи фреймов через Интернет.

Задержка декодирования видео вызвана тем, что сжатое видео не может быть расшифровано без 1-кадров при кодировании структуры групп видеокадров GoP (Group of Pictures).

Запрос на переключение канала преобразуется в STB в адрес группы многоадресной рассылки, который содержится в сообщении IGMP. При переключении канала процесс запускается конечным пользователем, если новый канал не доступен в домашнем шлюзе (HG — Home Gateway).

Процесс переключения каналов в традиционных вещательных службах, таких как спутниковые, кабельные или наземные, телевизор или STB может сразу отобразить вы-

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

Рис. 1. Общая процедура переключения каналов

В системах IPTV все каналы одновременно не могут быть переданы IPTV-клиентам из-за отсутствия пропускной способности сети доступа. Использование различных мультимедийных услуг, таких как видео по запросу (VoD), с оплатой за просмотр (PPV) и других индивидуальных услуг видео требует увеличения пропускной способности сети доступа. Таким образом, пропускная способность сети доступа должна управляться эффективно, потому что для каждого канала требуется высокая пропускная способность.

Алгоритм переключения каналов IPTV

Основная идея алгоритма переключения каналов заключается в том, что когда пользователь переключается на другой канал и смотрит его менее одной минуты, от узла агрегации к пользователю снижается качество передачи. Через 1 минуту начинается передача видео высокого качества [5]. Алгоритм переключения каналов представлен на рис. 2.

Оценка времени переключения каналов IPTV

Архитектура сети IPTV приведена на рис. 3. Для оценки времени переключения каналов процесс был разделен на две части: выбор канала вне потока в узле агрегации и внутри потока. Внутри потока в узле доступа (Intra-stream) для переключения канала требуется лишь интервал времени для обработки команды, чтобы изменить указатель канала в узле доступа, используя менее качественное видео. Для поиска канала вне потока (Inter-stream) переключение каналов осуществляется обычным групповым методом.

Поток можно определить как последовательность пакетов с конкретного узла источника к конкретному узлу назначения. Так, в одно соединение TCP, TCP-пакеты данных представляют собой один поток, а ТСР-АСК-пакеты-второй поток.

Для оценки времени переключения каналов зададимся значениями следующих двух вероятностей: Р0- вероятность взаимодействия внутри потока каналов (intra-stream), Pi — вероятность того, что канал находится вне потока каналов в узле агрегации (inter-stream). Время переключения каналов можно оценить по следующей формуле:

^пер. Ро ‘ ^AS ^буф. дж.

Где Опср — время переключения каналов; Д.,х — общая задержка переключения каналов с использованием обычных передач; Ц,ф. — задержки переключения каналов при скачивании потока из узла агрегации; Дъф.д*. — задержка в буфере джиттера.

Отправка ыаео высокого качеств а в буфер STB

Рис 2. Алгоритм переключения каналов

Источник: cyberleninka.ru