Цифровое телевидение¶

Цифровое телевидение на замену аналоговому сигналу развивалось паралелльно развитию интернета и длительное время имело характеристики, недостижимые на обычном подключении к интернету. В связи с этим в DVB (digital video broadcasting) системах сильно развились решения, которые были необходимы в своё время, не очень нужны в интернете, но всё ещё актуальны, потому что они повсеместно используются.

В этой статье будут рассмотрены особенности DVB (включая распространение по IP сетям, т.е. IPTV) в контексте отличия от OTT доставки и UGC сервисов типа youtube или twitch.

В мире есть несколько разных наборов стандартов, описывающих цифровое телевидение, это DVB, ATSC, ISDB-T.

Все они на сегодняшний день технически описывают как именно упаковать телевизионный поток в MPEG-TS с соблюдением норм TR 101 290

Где живет DVB?¶

DVB используется в 4 случаях:

Спутниковое ТВ, DVBS (Satellite)
Кабельное ТВ, DVBC (Cable)
Эфирное ТВ, DVBT (Terrestial)
Кабельное ТВ по IP сетям, IPTV

IPTV часто не включают в DVB, но по своему смыслу, технической, кадровой организации это в чистом виде DVB.

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

DVB в IP¶

Почему IPTV вне всяких сомнений относится к DVB? Потому что суть услуги ровно такая же: однонаправленная низкоинтерактивная раздача телеканалов по заранее спроектированной собственной сети доставки.

Приставки и телевизоры те же, что для DVB-C, тот же набор сервисов и т.п.

Некоторое отличие есть только с HbbTV. Это технология, позволяющая добавить немного онлайн-интерактивности, но в 20-х годах очень тяжело внедрять инновационную концепцию веб-сайта уровня ранних 90-х, так что технология всё ещё перспективная.

интерактивность DVB¶

За такое прекрасное инженерное достижение (полностью защитить себя от скачков нагрузки) приходится платить жуткой неинтерактивностью сервиса. Спутниковые ТВ сервисы вынуждены просить клиентов не выключать надолго приставку, чтобы она не пропустила сеанс приема ключей, а монтажник такого сервиса дозванивается в офис и просит прям сейчас отправить для новой приставки ключи в космос, чтобы она включилась. Монтажникам нетфликса этого не понять.

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

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

Инженерные особенности DVB¶

Однонаправленные среды доставки DVB, как то спутник, кабель и эфир задают следующие технические особенности:

Постоянная скорость передачи данных. Например спутниковый передатчик на нужной частоте передает 48 мегабит и это значит ровно 48 миллионов бит в секунду: не больше и не меньше. Если на передатчике ПО решило заняться сборкой мусора на пару секунд, у потребителей будет потеря сигнала. Для инженеров это означает необходимость создавать системы мягкого реального времени (soft real time) с жесточайшим требованием по стабильности битрейта.
Пуш модель всех сервисов. Хочется передать витрину контента или расписание передач? Это будут не страницы на веб-сайте, а специальным образом подготовленные данные, которые регулярно отправляются всем-всем даже если они не нужны потребителям. Это означает, что под все сервисы канал ограниченный, а значит их сложно наращивать.
Исторически сложившаяся зарегламентированность всех протоколов и сервисов. В то время, как на онлайн кинотеатре могут несколько раз в день менять что угодно, DVB оказался зарегламентирован комитетами и государственными регуляторами на уровне протоколов. Это значит, что в целом работать будет любой телевизор, но перечень всех возможных сервисов крайне ограничен и не менялся годами. По сути в DVB есть только витрина контента в виде перечня телеканалов и расписание передач на этих телеканалах в довольно ограниченном виде. HBBTV, попытка нарисовать хоть какие-то кнопки поверх обычного ТВ, это опоздавшая попытка добавить интерактивности и разнообразия в стандарты, забронзовевшие пару десятилетий назад.

Для доставки телевидения по DVB используется формат упаковки MPEG-TS. Называть его протоколом неправильно, потому что в этом стандарте нет описания взаимодействия клиента и сервера, да и в большинстве случаев нет этого взаимодействия.

MPEG-TS очень хорошо подходит под задачи DVB, потому что рассчитан на использование вне IP, когда нет никаких границ пакетов, адресов, портов. Просто поток байт, в котором надо как-то найти границы пакетов и начать показывать видео предельно быстро.

Практика использования MPEG-TS такая, что картинка начнет показываться в течении пары секунд.

MPEG-TS¶

В контексте DVB про MPEG-TS необходимо знать следующие темы:

Что такое пиды (PID), CC
Таблицы PAT, PMT, NIT - всё это нужно для организации списка телеканалов
Таблицы EIT для передачи расписания EPG
CBR кодирование контента, которое очень условно CBR, но уж так называют
PCR, на который сегодня обращают сильно больше внимания, чем это на самом деле нужно

PID, CC¶

MPEG-TS проектировался под упаковку в один толстый физический канал множества параллельных потоков данных.

В IP сетях параллельные потоки данных разделяются IP адресами и портами на обоих концах соединения. В MPEG-TS это разделение делается указанием 13-битного номера канала внутри общего потока в начале каждого пакета. Все пакеты одного размера: 188 байт, с 4-х байтным заголовков. В этих 4 байтах первый байт отведен под фиксированное число 0x47, которое используется чтобы найти в потоке байт границы пакетов (3-х байт 0x47 идущих через 187 байт точно достаточно для синхронизации). Оставшиеся 3 байта используются под PID (program identifier), Continuity Counter и прочие флажки, которые чуть менее важны, а некоторые вообще уже забыты.

Continuity Counter - это дешевый 4-битовый способ понять, что пакеты не пропущены. DVB не очень подразумевает перестановку пакетов местами (в отличие от RTP), так что проследить, что пара пакетов потерялась, CC очень помогает. Отличить потерю одного пакета от 17 уже сильно сложнее.

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

PAT, PMT и т.п.¶

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

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

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

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

EIT¶

EIT - это способ передать Electronic Program Guide в отдельном пиде.

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

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

CBR кодирование¶

С этим искуственным термином есть очень много придумок и непониманий. Во-первых, CBR в бытовом понимании есть только у звука. Это mpeg2 audio позволяет кодировать каждый фрейм в одинаковое фиксированное количество байт. У видео CBR существует разве что у тех, кто гоняет по 300-3000 мегабит на поток в сыром кодеке или с раздельной компрессией кадров. H264 это всегда VBR, хотя конечно сделать выморочную ситуацию с сжатием каждого кадра в свой размер можно.

Если взять VBR поток и посмотреть на часовые файлы, то они будут примерно одинакового размера. Это тоже в каком-то смысле CBR, просто с большим окном. В DVB это окно по стандарту — 1 секунда. Т.е. каждые 25 (или сколько у вас fps) кадров идущие подряд, не превышают в сумме нужное количество байт.

Энкодеров, которые попадают ровно в нужный битрейт нет, но если открыть DVB Analyzer, то можно увидеть красивые графики с идеально ровным битрейтом. Как же получаются красивые графики идеального CBR битрейта в анализаторе?

Вся хитрость в скрытом стафинге. В MPEGTS есть добивка до нужного трафика нуль пакетами, идущими на строго выделенном порту, а есть стафинг в H264 NAL юнитах и вот его уже анализаторы не показывают.

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

Учитывая, что Flussonic Media Server поддерживает работу с разными энкодерами, мы можем транскодировать видео с необходимым для DVB качеством.

PCR¶

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

PCR - это прошитое в поток время. Просто референсное время, на которое должен ориентироваться плеер. Пришел кадр, у него есть PTS (Presentation TimeStamp), когда показывать? Да когда нужный PCR покажется в потоке, тогда и показывай. Фазовые подстройки - это всё про старые приставки, у которых собственные часы гуляли так, что рассчитывать на PCR было очень разумно.

Вокруг PCR accuracy и jitter существуют устойчивые мифы, что для его формирования нужны какие-то прецизионные часы, системы реального времени и на «обычном сервере» его не проставить. Это красивые образы уровня «железное надежнее софтверного» и не имеет никакой связи с реальностью. Формирование потока не требует систем жесткого реального времени, просто нужен софт, который учитывает сразу несколько требований из стандарта DVB и позволяет при выкидывании любого пида сохранить равномерность остальных.

PCR accuracy - это просто замер, который говорит о том, насколько не совпадает линейность роста номера пакетов и роста PCR.

Flussonic полностью выбрасывает все входящие метки PCR (и в большинстве случаев их игнорирует, потому что они не особо нужны) и правильно с нулевым джиттером проставляет их на выходе.