Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

«Московский государственный технический университет

имени Н.Э. Баумана»
(МГТУ им. Н.Э. Баумана)

ФАКУЛЬТЕТ «РАДИОЭЛЕКТРОНИКА И ЛАЗЕРНАЯ ТЕХНИКА» (РЛ)

КАФЕДРА «РАДИОЭЛЕКТРОННЫЕ СИСТЕМЫ И УСТРОЙСТВА» (РЛ-1)

Реферат
ПО ДИСЦИПЛИНЕ:
«Основы телевидения»
На тему: Сжатие цифрового видеосигнала. Основные последствия сжатия.

Выполнил: Кукушкин В.А.

Группа РЛ1-103

Подпись:
Проверил: Ефремов В.А.
Подпись:

Москва 2020
Оглавление
Введение....................................................................................................................................................3
Характеристики видеопотока...................................................................................................................3
Почему видео нужно сжимать?................................................................................................................5
На чем можно сэкономить?..................................................................................................................5
Кодирование цвета................................................................................................................................5
Избыточность изображения.................................................................................................................6
Межкадровая разность.........................................................................................................................6
Организация последовательностей кадров........................................................................................8
Избыточность выходных данных..........................................................................................................9
Вывод........................................................................................................................................................10
Введение

Требования к качеству видео постоянно растут. При этом ширина

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

Характеристики видеопотока

Любое видео – это множество статичных картинок, которые сменяют

друг друга во времени – видеопоток, обладающий определенными
характеристиками.
Формат пикселя. Пиксель не дает нам никакой информации кроме его
цвета. Однако восприятие цвета сильно субъективно и были приложены
большие усилия для создания систем цветопредставления и цветопередачи,
которые были бы приемлемы для большинства людей. Так цвет, видимый
нами в реальном мире, является достаточно сложным по спектру частот
света, что передать его в цифровом виде крайне сложно, а отобразить еще
сложней. Однако было замечено, что все тремя точками в спектре можно
достаточно точно приблизить отображаемый цвет к настоящему в метрике
восприятия цвета обычным человеком. Эти три точки: красный, зеленый и
синий. То есть их линейной комбинацией мы можем покрыть большую часть
видимого спектра цветов. Поэтому самый простой способ представления
пикселя: RGB24, где под компоненты Red, Green и Blue отводится ровно по 8
бит информации. И так мы можем передать 256 градаций каждого цвета и
всего 16,777,216 всевозможных оттенков. Но на практике при хранении такое
цветопредставление практически не используется, не только потому что мы
тратим целых 3 байта на пиксель, но и по другим причинам, которые будут
рассмотрены далее.
Размер кадра. Кадр характеризуется: шириной, высотой, размерами
видимой части и форматом. Самые ходовые размеры: 640x480, 720x480,
720x576, 1280x720, 1920x1080, 3840x2160 и даже 7680x4320 - они
фигурируют в разных стандартах и соответствуют разрешающей
способности аппаратуры.
Формат кадра. Даже зная размеры кадра, мы не можем представить
массив пикселей в более удобной форме, не имея информации о способе
“упаковки” кадра. В простейшем случае берем строку пикселей и
выписываем подряд биты каждого закодированного пикселя и так строчку за
строчкой. То есть выписываем количество строк, количество пикселей в
строке по порядку. Такая развертка называется прогрессивной (Progressive).
Можно очень долго спорить о целесообразности чересстрочной (Interlaced)
развертки, но факт, что она осталась как пережиток прошлого от
традиционного телевидения. Отсюда и исходят обозначения: 576i, 720p,
1080i, 1080p, где указано количество строк (высота кадра) и тип развертки.
Частота кадров. Одни из стандартных значений: 23.976, 24, 25 и 29.97
кадров в секунду. Например, 25 к/с используется в европейском телевидении,
29.97 в американском, а с частотой 24 к/с снимают на кинопленку. Но откуда
взялись “странные” 23.976 и 29.97? Суть такова: 23.976 = 24/1.001, а 29.97 =
30/1.001, то есть в стандарт американского телевещания NTSC заложен
делитель 1.001. Соответственно при показе киноленты произойдет совсем
небольшое замедление, которое не будет заметно зрителю, но если это
музыкальный концерт, то скорость показа настолько критична, что лучше
изредка пропускать кадры и опять же зритель ничего не заметит. Хотя по
американскому телевизору никогда не показывается “24” кадра в секунду, а
показывается “30” чересстрочных кадров (и того 59.94 полукадра в секунду,
что соответствует частоте их электросети), но они получаются “методом
спуска” (3:2 pulldown). Суть метода состоит в том, что у нас есть 2 полных
кадра и 5 полукадров, и мы информацией из первого кадра заполним первые
3 полукадра, а из второго оставшиеся 2. То есть последовательность
полукадров такова: [1 top, 1 bottom], [1 top, 2 bottom], [2 top, 3 bottom], [3 top,
3 bottom], [4 top, 4 bottom] и т.д. Где top – верхние строки (поля, fields), а
bottom нижние, то есть, нечетные и четные начиная сверху соответственно.
Таким образом, пленочная картинка вполне смотрибельна на телевизоре, но
на динамичных сценах заметны подергивания. Частота кадров может быть и
переменной, но это достаточно сложно реализуется.
Глобальные характеристики. Все вышерассмотренное относится к
локальным свойствам, то есть тех, которые отражаются во время
воспроизведения. Но длительность видеопотока по времени, объем данных,
наличие дополнительной информации, зависимости и т.п. Например:
видеопоток может содержать в себе один поток, отвечающий левому глазу, а
другой поток некоторым образом будет хранить информацию об отличии
потока правого глаза от левого. Так можно передавать стерео видео или
всенародно известное “3D”.

Почему видео необходимо сжимать?

Если мы будем передавать видео несжатым, то ни на что серьезное

нам не хватит ни каналов связи, ни места для хранения данных. Пусть мы
имеем HD поток с характеристиками: 1920x1080p, 24 к/с, RGB24 и
подсчитаем “вес” такого потока. 1920*1080*24*24 = 1139 Мегабит/с, а если
захотим записать 90 минутный фильм, то потребуется 90*60*1139 = 750
Гигабайт. Это при том, что видео фильма отличного качества с тем же
1920x1080p на Blu-Ray будет занимать 20-50 Гб, то есть разница почти в 15-
30 раз! Очевидно, что видео требует сжатия, особенно учитывая то, что
можно сократить размер в 15 и более раз, сохранив при этом очень хорошее
качество.

На чем можно сэкономить?

Кодирование цвета. Ранее телевидение было черно-белым, но

сегодняшнее телевидение целиком в цвете. Но черно-белый телевизор по-
прежнему может показывать передачи. Дело в том, что в телесигнале яркость
кодируется отдельно от цветных составляющих и представляется в формате
YUV (подробнее на википедии). Где Y компонента – это яркость, а U и V –
цветовые компоненты и все это вычисляется по формуле:
Y = 0.299 * R + 0.587 * G + 0.114 * B
U = -0.14713 * R - 0.28886 * G + 0.436 * B
V = 0.615 * R - 0.51499 * G - 0.10001 * B
Как видно, преобразование линейное и невырожденное.
Следовательно, мы можем с легкостью получать обратно значения R, G и B.
Допустим под хранение Y, U и V мы выделим по 8 бит, тогда было 24 бита
на пиксель и так и осталось. Никакой экономии. Но человеческий глаз
чувствителен к яркости, а вот к цвету он не сильно притязателен. Да и почти
на всех изображениях цвета сменяют друг друга не так часто. Если мы
условно разделим изображение на слои Y, U и V и яркостный слой оставим
без изменений, а слои U и V в два раза сократим по высоте и в два раза по
ширине и того в четыре раза. Если раньше на каждый пиксель тратили 24
бита, то теперь тратим 8*4+8+8=48 бит на 4 пикселя, то есть, грубо говоря,
12 бит на пиксель (именно поэтому данный формат кодирования называется
YV12). За счет цветового прореживания мы сжали поток в два раза без
особых потерь. Например, JPEG всегда выполняет подобное преобразование,
но по сравнению с другими возможными артефактами прореживание цвета
не несет никакого вреда.
Избыточность изображения. Здесь нет никаких отличий от
алгоритмов сжатия изображений. Тот же JPEG сжимает изображение за счет
его локальной избыточности методами дискретного косинусного
преобразования (DCT) и квантования. Встроенный в кодек алгоритм сжатия
статичных изображений должен хорошо сжимать даже отдаленно
напоминающее реальные изображения.
Межкадровая разность. Наверняка, любой, посмотрев любое видео,
заметит, что изображения не меняются резко, а соседние кадры достаточно
похожи. Конечно, резкие смены бывают, но они обычно происходят при
смене сцен. И тут возникает проблема: как компьютер должен представлять
все то многообразие возможных преобразований изображения? На помощь
приходит алгоритм компенсации движения. Изображение делится на блоки и
в окрестности каждого из них ищется похожий блок на другом кадре (motion
estimation), так получается поле векторов движения. А уже при компенсации
(motion compensation) учитываются вектора движения, и создается
изображение в целом похожее на исходный кадр.

Рисунок 1 - Поиск векторов движения для компенсации движения

Рисунок 2 - Разница до компенсации движения

 Рисунок 3 - Разница между оригиналом и скомпенсированным кадрами

Здесь четко видно, что исходная межкадровая разность значительно

больше, чем разность между исходным и скомпенсированным кадрами. С
учетом объемов информации при сжатии изображений мы можем сохранить
вектора движения почти “бесплатно”. Сделали это и потом сжали
изображение скомпенсированной межкадровой разности алгоритмом сжатия
статических изображений. В силу большой избыточности таких изображений
они сжимаются очень сильно. Но если кодек сжимает их слишком сильно, то
и возникает эффект блочности. Старые алгоритмы никак не учитывают
изменения объектов по яркости и именно поэтому по телевизору видно
блочность при резких изменениях яркости.
Организация последовательностей кадров. В первую очередь кодек
должен быть чувствителен к смене сцен. Определить это достаточно просто,
так как компенсация движения отработает в этом случае безобразно. Кадр
начала новой сцены логично сохранить “как есть”, поскольку он ни на что
ранее встречавшееся не похож. Такие кадры называют опорными (I-frame). А
далее идут кадры, к которым применялась компенсация движения, то есть
они зависят от опорного кадра и друг от друга. Это могут быть P-frame или
B-frame. Первые могут опираться только на предыдущие кадры, а последние
могут на левого и правого соседа. I-кадр и все его зависимые образуют GOP
(group of pictures). От использования би-кадров следует насколько
преимуществ: быстрая навигация (потому что предыдущие би-кадры не
нужно декодировать) и то, что они имеют самый маленький размер среди
всех кадров фильма, ну и немного более низкое качество (но быстрое
чередование с более качественными кадрами делает это малозаметным для
зрителя).
Избыточность выходных данных. Даже после выполнения всех
сжимающих процедур поток коэффициентов имеет избыточность. Далее
может применяться разные методы сжатия без потерь. В кодеке H.264,
например, используется контекстно-адаптивное двоичное арифметическое
кодирование, реализующие арифметическое сжатие с мощной вероятностной
моделью и реализующие метод Хаффмана.
Вывод

При использовании сжатия с потерями появляются характерные,

иногда отчётливо видные артефакты - например, блочность (разбиение
изображения на блоки 8x8 пикселей), замыливание (потеря мелких деталей
изображения) и другие. Но, как бы странно это не звучало, именно сжатие
позволяет улучшать качество видео. Устраняя избыточность данных, не
влияющую на конечное качество потока, и используя методы кодирования,
основанные на особенностях восприятия яркости и цветности человеческим
зрением мы высвобождаем ресурсы для улучшения прочих характеристик:
динамического диапазона (технологии HDR – High Dynamic Range),
увеличения разрешения (4K, 8K), увеличения частоты кадров (HFR – High
Frame Rate – до 120 к/c).
Улучшение методов сжатия непосредственно связано с
совершенствованием форматов – например, H.265 также известный как
HEVC (High Efficiency Video Coding), разработка которого началась в 2004
году ближе к своей финальной редакции (2013год) был оптимизирован для
работы с упомянутыми выше стандартами - HDR, 4K и 8K, HFR.
Использование этого формата позволило достичь существенного сокращения
размера файлов при сохранении субъективной оценки качества, либо либо
существенно нарастить качество при том же битрейте.
Приведем пример эффективности кодирования H.265 для контента,
использующего технологии HDR, HFR и разрешение 4K.
Фильм 2019 года Гемини (Gemini Man, режиссер Энг Ли) для
домашнего просмотра выпущен в двух версиях:
1 версия: разрешение: 1920х1080, частота кадров: 24 к/c, глубина цвета:
8 бит на канал, кодек H.264 High Profile 4.1, битрейт – 27256 кбит/c.
2 версия: разрешение: 3840x2160, частота кадров 60 к/c, глубина цвета:
10 бит на канал, кодек H.265 Main 10 (Level 5.1), битрейт – 80973 кбит/c.
 Попробуем примерно подсчитать битрейт 2 версии, если бы при
применялся кодек первой (H.264):
3840 ×2160 60 10
27256 × × × =340700 кбит/c
1920 ×1080 24 8
Таким образом, кодирование с помощью H.265 позволяет уменьшить
битрейт видеопотока в 4,2 раза. Естественно, на практике выигрыш был бы
несколько ниже, но в коммерческой применении для кодирования видео
разрешением 4К (и выше) применяется только H.265.