TR 101 290¶

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

Для того, чтобы выработать общие правила оказания услуг и получить общие измеримые показатели качества в DVB разработали набор инструментальных проверок, показывающих корректность формирования потока байт в MPEG-TS и этот документ называется ETSI TR 101 290

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

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

Аналогом этого документа мог бы быть документ, по которому написан mediastreamvalidator от Apple для протокола HLS или расширенный валидатор XML+MP4 для DASH.

Та часть TR101290, которая описывает сами байты, состоит из трех глав, отсортированных по критичности, называемых приоритетами. Кроме этой части есть ещё описание проверок в различных средах, например DVB-T/T2, DVB-C/S

Применимость норматива¶

Сам по себе документ важен только для цифрового телевидения (DVB) и прежде всего для сред без IP, т.е. кабель/эфир/спутник. Там он очень осмысленнен и важен.

Однако он не является неотъемлемой частью самого MPEG-TS, поскольку в том же HLS его требования совершенно бессмысленны. Так, например, в HLS не используется вообще PCR, что для обычного телевизионщика является крамолой.

1 приоритет¶

Пункт 5.2.1 First priority: necessary for de-codability (basic monitoring) описывает самые грубые проблемы, которые делают невозможным распаковку транспортного потока. Это:

TS_sync_loss, Sync_byte_error: отсутствие возможности синхронизации по байту 0x47
PAT_error, PAT_error_2 на пиде 0 отсутствует PAT или регулярно теряется (информация со списком телеканалов в потоке)
PMT_error, PMT_error_2 на перечисленных в PAT пидах недостаточно часто повторяются таблицы PMT (описание каждого телеканала)
PID_error какие-то пиды заявлены, но на них нет пакетов в течении желаемого времени (тут стандарт плавает, оставляя выбор за пользователем)
Continuity_count_error CC ошибки, что на самом деле является индикатором потерь, дублирования или перестановки пакетов. Чаще всего конечно потери.

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

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

2 приоритет¶

Следующая глава 5.2.2 Second priority: recommended for continuous or periodic monitoring описывает корректность генерации данных той программой, которая формировала поток байт. В DVB мире часто используется понятие ремультиплексинга, когда транспортные потоки не полностью распаковываются до кадров и обратно, а лишь частично переписываются, сохраняя неизмененной часть данных. В процессе этих перепаковок могут быть допущены ошибки, которые тоже отслеживаются этой частью документа. Так же любая из ошибок ниже (и выше) может появиться из-за того, что биты поменялись при доставке и получатель увидел не то, что отправлял источник.

Transport_error какая-то программа слева по тракту поставила индикатор поломанного потока. Например этим можно пользоваться чтобы специально поднять алерт только у мониторинга, не разламывая проигрывание на телевизорах
CRC_error одну из служебных таблиц поправили, а забыли пересчитать контрольную сумму
PCR_error слишком большое расстояние между соседними метками времени потока
PCR_repetition_error слишком редкая маркировка времени потока, надо чаще
PCR_discontinuity_indicator_error время потока скакнуло, а индикатора разрыва/переключения между источниками не стояло
PCR_accuracy_error самая загадочная ошибка для тех, кто думает, что PCR связан с реальным временем. Неоднородность маркировки времени потока
PTS_error слишком редко ставят PTS. Это ошибка из тех времен, когда в MPEGTS вообще можно было не ставить таймстемпы кадров PTS/DTS. В том же HLS без этих меток ничего не будет играть, зато можно не ставить PCR.
CAT_error проблема с дешифровкой потока

PCR¶

PCR, он же время потока - это один самых устойчивых мифов, особенно на фоне пугающего требования в 500 наносекунд точности. Ему приписывают связь с абсолютно точным временем, распускаются мифы о том, что компьютер не может выдать PCR, а волшебный железный мультиплексор сделанный на очень дорогих израильских (почему бы и нет) FPGA картах - сможет, потому что нужно точное время.

PCR - это просто номер пакета, пересчитанный по линейной формуле: PCR = PCR_initial + (N*188*8) / Bitrate

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

Наш медиа сервер Flussonic генерирует MPEG-TS поток самостоятельно, все метки времени проставляет сам, упаковывает в CBR и выдает нулевой джиттер PCR.

3 приоритет¶

NIT_error, NIT_actual_error, NIT_other_error, SI_repetition_error, TDT_error, RST_error, SDT_other_error проверки на частоту и корректность информационных пакетов (таблиц), в которых рассказывается, что это вообще за транспортный поток и что в нём можно посмотреть
Unreferenced_PID - жалоба на то, что пид есть, но он ничейный, ни в какой таблице он не перечислен. Такое бывает, когда подмешивают левые пиды и с другой стороны их забирают, т.е. когда заменяют инструментальное оформление структуры потока на голосовое.
Buffer_error, Empty_buffer_error - ошибки HRD буфера попавшие в 3-й приоритет, хотя скорее им место во 2-м.
EIT_error, EIT_actual_error, EIT_other_error, EIT_PF_error - всё что касается расписания, чтобы оно приходило вовремя и актуальное

HRD Buffer error¶

Непросто найти детали об этой простой штуке, так что рассказываем здесь.

Кадр с каким-то PTS (указанным в PES заголовке кадр) начинает передаваться получателю и тот накапливает его в буфер. Буфер растет с каждым пришедшим пакетом. Как только время потока PCR превышает указанный PTS, фрейм выкидывается из буфера целиком уменьшая его наполнение. Получается пилообразный график.

Он не должен выходить за верхнюю границу (определенную) и не опустошаться «ниже нуля», т.е. кадр должен прийти полностью к тому моменту, когда наступит указанное время потока. За это как раз отвечает транскодер, который должен достаточно ужать кадр.

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