![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Остальные части
Процесс кодирования видео в MPEG2 состоит из нескольких этапов, общей целью которых (как и любого сжатия вообще) является устранение избыточности информации. Применительно к видео избыточность бывает двух видов: пространственная (дублирование информации в пределах одного кадра) и временнАя (дублирование в последовательно расположенных кадрах).
Disclaimer: большинство теоретической и технической информации в этой части повествования может содержать ошибки. Перед практическим использованием перепроверьте самостоятельно.
Вкратце этапы кодирования таковы:
0) Оцифровка видео, если оно было в аналоговом виде, и масштабирование до нужного размера кадра. Эта часть к собственно процессу кодирования не относится.
1) Перевод изображения из цветового пространства RGB в YCbCr. На этом этапе может происходить некоторая потеря информации, связанная с разным цветовым охватом RGB и YCbCr и с округлением результатов до целых, но на глаз она обычно незаметна.
2) Анализ близкорасположенных кадров (не обязательно совсем смежных) на предмет совпадений с целью устранения временнОй избыточности. На этом этапе потерь информации не происходит.
3) Двумерное дискретное косинусное преобразование (DCT) (тут потерь тоже почти нет, только за счёт округления полученных коэффициентов ДКП до целых) и адаптивная квантизация этих коэффициентов. Вот как раз тут и происходит наибольшая потеря информации и вносятся наиболее сильные искажения.
4) Дальнейшее сжатие с помощью RLE и кодов Хаффмана. Без потерь.
К полученным закодированным кадрам добавляются служебные заголовки, и получается PES - Packetized Elementary Stream.
Дальше можно не читать, там эти этапы разжеваны немножко подробнее, а для общего понимания DVB оно не обязательно.
Основным параметром, который задаётся MPEG2-кодеру, является битрейт (объём выходного потока в битах за единицу времени). Чем он больше, тем [обычно] более качественной получается картинка, хотя, конечно, неумелым кодированием можно всё испортить.
Чисто для ориентировки, реальные случаи могут существенно отличаться в обе стороны:
352x288 (разрешение MPEG1, примерно соответствует качеству бытового видеомагнитофона) нормально смотрится при потоке примерно в 1500-2000 кбит/с.
720x576 (максимальный размер кадра для DVD) - 7000-8000 кбит/с.
Ориентируясь на заданный битрейт, кодер должен динамически подстраивать параметры алгоритмов, используемых на разных этапах, чтобы битрейт выходного потока был как можно ближе к этому значению, но при этом как можно меньше теряя в качестве. Задача однозначного решения не имеет, производители кодеров решают её по-разному.
1) Почему не RGB, а какой-то непонятный YCbCr?
Человеческий глаз гораздо более чувствителен к яркости изображения, чем к цвету. Соответственно, искажения яркостной составляющей картинки будут гораздо более заметны. Поэтому, если уж мы согласились на сжатие с потерями, то будет разумным разделить яркостную и цветовые компоненты и сжимать их по отдельности и с разными потерями.
Цветовое пространство YCbCr (оно же Y'CbCr, оно же YCC) - один из вариантов такого разделения. Y (luma) определяет яркость, а Cb и Cr (chroma, chrominance) - цвет.
Кроме того, реальные изображения обычно содержат взаимозависимости между цветами, а перевод в яркостно-цветовую модель позволяет эту избыточность частично устранить, а это уже и есть некоторое сжатие. На самом деле, взаимозависимость между компонентами в яркостно-цветовой модели для реальных изображений всё равно сохраняется, но меньшая, чем в RGB.
Строго говоря, пересчёт из RGB в YCbCr (и обратно) может производиться с несколькими разными наборами коэффициентов, но в эти дебри мы не полезем.
2) Кадры (frames) в MPEG2-видео бывают трёх видов: I, P и B.
I (intra coded): опорные, содержат полную версию исходных (несжатых) кадров. MPEG2 допускает видеопоток, состоящий только из таких кадров, но он получается очень большим.
P (predictive coded): содержат отличия от предыдущего I или P-кадра. P-кадры могут содержать как собственно вновь появившиеся части изображения, так и векторы смещения частей изображения из ближайшего предыдущего I или P-кадра.
Поскольку P-кадры не содержат полной информации из соответствующих исходных кадров, они занимают меньше места, чем I. Но при воспроизведении требуют наличия ближайшего предыдущего I-кадра и всех следующих за ним P-кадров вплоть до текущего.
B (bidirectionally-predicted coded): содержат отличия от ближайшего предыдущего и/или последующего P или I-кадра.
По объёму B-кадры самые маленькие, но для воспроизведения требуют предыдущего I- или P-кадра (а вместе с предыдущим P - и всех остальных P-кадров до ближайшего предыдущего I), а также, возможно, и ближайшего следующего P или I-кадра.
Это означает, что к моменту, когда надо воспроизводить B-кадр, декодер должен уже иметь все остальные кадры, от которых зависит этот B.
Для решения этой проблемы кодер меняет последовательность кадров в выходном потоке с тем, чтобы P и I-кадры попали в выходной поток (а следовательно, и в в декодер) раньше, чем все зависящие от них B-кадры, даже если воспроизводиться они должны позже B.
Очевидно, что чем меньше движения присутствует в кодируемой последовательности кадров, тем эффективнее использование P и B-кадров.
Группа кадров, начиная с I и включая все зависящие от него P и B, называется GOP (Group of Pictures).
Последовательно идущие GOP составляют выходной видеопоток.
С какой частотой в видеопотоке должны встречаться I-кадры, стандарт жестко не регламентирует, но обычно их вставляют не реже каждого 15-го, а также при резкой смене картинки, когда кодировать отличия становится невыгодно.
Стандарт допускает разные последовательности типов кадров в разных GOP в пределах одного потока. Кодер может пользоваться этим для улучшения параметров выходного потока.
Соотношение между разными типами кадров в GOP обычно выражают дробью, числитель которой обозначает расстояние между соседними I или P-кадрами, а знаменатель - расстояние между I-кадрами (то есть, длину GOP). Типичной является последовательность IBBPBBPBBPBB, обозначающаяся как 3/12.
Из этого описания должно стать понятно, почему в общем случае MPEG2-поток нельзя разрезать в видеоредакторе с точностью до произвольного кадра. Резать можно только по I-кадрам (или, что то же самое, с точностью до GOP). Все редакторы, которые позволяют резать MPEG2-поток по произвольному кадру (и MPEG4, кстати, тоже: там почти такие же типы кадров), вынуждены декодировать кадры в пределах разрезаемой GOP и кодировать нужные кадры обратно с тем, чтобы новая GOP начиналась с I-кадра. Повторное кодирование обычно приводит к внесению дополнительных искажений.
[Дальнейшая часть про макроблоки относится не только к MPEG2, а и к некоторым другим системам кодирования видео, использующим то же цветовое пространство.]
Для целей кодирования из исходного несжатого изображения выбираются блоки размером 8x8 чисел по каждой из компонент Y, Cb и Cr. Блоки всех трёх компонент, относящиеся к одной части исходного кадра размером 16x16 пикселов, объединяются в макроблок. Это объясняет, почему допустимые размеры кадров в MPEG2 и большинстве других систем кодирования цифрового видео должны быть кратны 16. Если они не, то перед кодированием кадр придётся дополнять по краям полосками, а после декодирования эти полоски отрезать, что приводит к необходимости кодирования, декодирования и передачи ненужной информации.
Теперь вспомним, зачем, собственно, изображение переводилось в YCbCr. А затем, чтобы можно было уменьшить количество информации о цветовых составляющих. Делается это простым способом: сокращением количества блоков в макроблоке.
В одном макроблоке всегда 4 Y-блока. А каждого из Cb и Cr в макроблоке может быть 1, 2 или 4, и данные в них получаются путем усреднения значений от соответствующих исходных пикселов.
Количеством блоков разных типов в макроблоке (chrominance) обычно записывают в виде тройного отношения. Причём, чтобы всех запутать, в другом порядке - Y:Cr:Cb.
4:4:4 означает, что мы решили не жертвовать цветовой информацией, и блоков Y, Cb, Cr будет поровну. Этот вариант лучше всего сохраняет исходное изображение, но, естественно, при прочих равных условиях даёт максимальный битрейт. MPEG2 этот вариант поддерживает, но на практике он не используется.
4:2:2: на 4 блока Y приходится по 2 блока Cb и Cr. Горизонтальное разрешение для Cb и Cr вдвое меньше, чем у Y. Этот вариант иногда применяется для перегонки [относительно] высококачественного MPEG2-видео по спутниковым каналам, но практически никогда не применяется для публичного вещания.
4:2:1: на 4 блока Y приходится 2 блока Cr (с вдвое меньшим горизонтальным разрешением) и 1 блок Cb (с еще вдвое меньшим горизонтальным разрешением). В этом варианте учитывается более низкая чувствительность человеческого глаза к синим оттенкам, чем к красным. Хотя формально такой вариант определён (но не для MPEG2), на практике он не используется ни в одной системе кодирования.
4:1:1: на 4 блока Y приходится по 1 блоку Cb и Cr с вчетверо меньшим горизонтальным разрешением. Используется в некоторых DV-камерах. В MPEG2 не поддерживается.
4:2:0: не значит, что Cb совсем нет. Это чтобы окончательно всех запутать, так обозначаются 4 блока Y и по 1 блоку Cb и Cr со вдвое меньшим разрешением как по горизонтали, так и по вертикали. Это и есть наиболее распространённый вариант, применяемый обычно в DVB, DVD и DV. И единственно возможный в MPEG1.
В каждом макроблоке вместо максимальных 12 остаётся всего 6 блоков, что уменьшает общее количество информации вдвое.
[Конец части про макроблоки]
Поскольку изображение двигается не обязательно макроблоками (кусочками 16x16 пикселов), в MPEG2 определяется понятие слоя (slice). Слои - это неперекрывающиеся последовательности из 1 или более идущих подряд макроблоков. Векторы смещения указываются применительно к слоям.
Исходный кадр можно заранее полностью поделить на кусочки 16x16 пикселов только в том случае, если кодер решил сделать из него I-кадр. Если же он решил, что будет делать P или B, то начинается кропотливая работа по сравнению кадра с предыдущим/последующим на предмет, что там повторяется, и осталось ли оно на том же месте или съехало в сторону. В последнем случае в выходной кадр пишется вектор смещения, который может быть достаточно произвольным. А сама смещённая часть изображения, соответственно, может располагаться в любом месте кадра, и её координаты совершенно не обязательно будут кратны 16.
Чем лучше кодер умеет выполнять эту работу, тем меньше информации можно будет положить в P или B-кадр, то есть, получить на выходе из этого этапа меньший поток, а значит, использовать полученный выигрыш для улучшения качества изображения на следующем этапе.
Но естественно, это требует либо бОльших вычислительных мощностей, либо процесс будет идти не в реальном времени. Как обычно, реальные решения используют компромиссный вариант: кодеру задаётся максимальная величина вектора смещения, и если часть изображения в очередном кадре уехала дальше, то она просто не найдется и будет считаться совсем новой.
Для чересстрочного видео полукадры (fields) могут кодироваться по вышеописанной схеме как по отдельности, без склеивания со своим вторым полукадром, так и после склеивания в целые кадры.
3) DCT
К каждому блоку 8x8 (отдельно по каждой яркостно-цветовой составляющей, естественно) применяется дискретное косинусное преобразование, которое на выходе даёт матрицу коэффициентов 8x8. Особых потерь информации при этом не происходит, разве только за счет округления до целых чисел. А потом к полученной матрице применяется квантизация, и от её параметров по большей части и зависит, насколько закодированная картинка будет отличаться от исходной. Эти параметры обычно не задаются кодеру в явном виде, а подстраиваются динамически в зависимости от заданного и реального получающегося битрейта.
4)Дальнейшее сжатие
На выходе предыдущего этапа получается матрица, один из углов которой по большей степени состоит из нулей. Чем сильнее квантизация, тем больше там нулей. Тем сильнее огрубился результат, тем сильнее искажена картинка, тем сильнее мы сможем сжать данные. Значения из этой матрицы выбираются в зигзагообразном порядке, начиная с противоположного нулям угла, так что все нули оказываются в конце. После чего к этой последовательности применяется RLE (run-length encoding) и сжатие по Хаффману.
Стандарт определяет, чтО должно получиться в результате вышеописанных действий (синтаксис и семантику потока), но оставляет большую свободу в части реализации. Поэтому MPEG2-кодеров много, как аппаратных, так и программных, с разными способностями и разными результатами.
Вот, собственно, и всё.
Нераскрытой осталась тема профилей (profiles) и уровней (levels) MPEG2.
Стандарт широк и разнообразен, и требовать полной его реализации от всех программ и железяк было бы неправильно. Поэтому он определяет несколько подмножеств ситнаксиса выходного потока (по типам кадров, возможным соотношениям блоков в макроблоке и т.п.), которые называются "профилями".
Кроме того, стандарт не накладывает явных ограничений на некоторые величины. В частности, когда я в прошлой части написал про допустимые размеры кадров, я несколько наврал. Стандарт вообще допускает изображения размером примерно до 2^14 на 2^14 пикселов, ограничение состоит лишь в разрядности соответствующих служебных полей в заголовках. Но реально оно вряд ли кому нужно, поэтому стандарт определяет ещё несколько групп ограничений (по размерам кадров, частоте кадров, максимальному битрейту) для разных применений. Они называются "уровнями" (levels), которые и задают приведенные ранее размеры кадров.
Про декодирование
С декодером дело обстоит проще, у него никаких параметров нет, а есть только входной поток. Декодер выполняет все вышеуказанные операции в обратную сторону и получает исходные кадры (с точностью до внесённых при кодировании искажений). Потом, если изображение надо вывести на аналоговое устройство (обычный телевизор), кадры пропускаются через цифроаналоговый преобразователь. А если у устройства отображения есть цифровой вход (а у приёмника, в состав которого входит MPEG-декодер, - соответствующий цифровой выход), то поток преобразуется в формат этого интерфейса и передаётся прямо в цифре.
При декодировании есть только одна существенная проблема: что делать, если часть данных была потеряна при передаче? Стандарт на эту тему чётких инструкций не даёт, поэтому авторы разных декодеров решают её по-разному. Некоторые заполняют отсутствующие в кадре блоки зелёным цветом (почему именно зелёным - не знаю, возможно, так выглядит матрица из нулей в YCbCr после преобразования в RGB), некоторые копируют соседние блоки (результат получается довольно глупый, зато не требуется дополнительных ресурсов), некоторые интерполируют отсутствующие блоки из соседних, а некоторые целиком пропускают кадры с отсутствующими блками, показывая вместо них предыдущие целые.
Процесс кодирования видео в MPEG2 состоит из нескольких этапов, общей целью которых (как и любого сжатия вообще) является устранение избыточности информации. Применительно к видео избыточность бывает двух видов: пространственная (дублирование информации в пределах одного кадра) и временнАя (дублирование в последовательно расположенных кадрах).
Disclaimer: большинство теоретической и технической информации в этой части повествования может содержать ошибки. Перед практическим использованием перепроверьте самостоятельно.
Вкратце этапы кодирования таковы:
0) Оцифровка видео, если оно было в аналоговом виде, и масштабирование до нужного размера кадра. Эта часть к собственно процессу кодирования не относится.
1) Перевод изображения из цветового пространства RGB в YCbCr. На этом этапе может происходить некоторая потеря информации, связанная с разным цветовым охватом RGB и YCbCr и с округлением результатов до целых, но на глаз она обычно незаметна.
2) Анализ близкорасположенных кадров (не обязательно совсем смежных) на предмет совпадений с целью устранения временнОй избыточности. На этом этапе потерь информации не происходит.
3) Двумерное дискретное косинусное преобразование (DCT) (тут потерь тоже почти нет, только за счёт округления полученных коэффициентов ДКП до целых) и адаптивная квантизация этих коэффициентов. Вот как раз тут и происходит наибольшая потеря информации и вносятся наиболее сильные искажения.
4) Дальнейшее сжатие с помощью RLE и кодов Хаффмана. Без потерь.
К полученным закодированным кадрам добавляются служебные заголовки, и получается PES - Packetized Elementary Stream.
Дальше можно не читать, там эти этапы разжеваны немножко подробнее, а для общего понимания DVB оно не обязательно.
Основным параметром, который задаётся MPEG2-кодеру, является битрейт (объём выходного потока в битах за единицу времени). Чем он больше, тем [обычно] более качественной получается картинка, хотя, конечно, неумелым кодированием можно всё испортить.
Чисто для ориентировки, реальные случаи могут существенно отличаться в обе стороны:
352x288 (разрешение MPEG1, примерно соответствует качеству бытового видеомагнитофона) нормально смотрится при потоке примерно в 1500-2000 кбит/с.
720x576 (максимальный размер кадра для DVD) - 7000-8000 кбит/с.
Ориентируясь на заданный битрейт, кодер должен динамически подстраивать параметры алгоритмов, используемых на разных этапах, чтобы битрейт выходного потока был как можно ближе к этому значению, но при этом как можно меньше теряя в качестве. Задача однозначного решения не имеет, производители кодеров решают её по-разному.
1) Почему не RGB, а какой-то непонятный YCbCr?
Человеческий глаз гораздо более чувствителен к яркости изображения, чем к цвету. Соответственно, искажения яркостной составляющей картинки будут гораздо более заметны. Поэтому, если уж мы согласились на сжатие с потерями, то будет разумным разделить яркостную и цветовые компоненты и сжимать их по отдельности и с разными потерями.
Цветовое пространство YCbCr (оно же Y'CbCr, оно же YCC) - один из вариантов такого разделения. Y (luma) определяет яркость, а Cb и Cr (chroma, chrominance) - цвет.
Кроме того, реальные изображения обычно содержат взаимозависимости между цветами, а перевод в яркостно-цветовую модель позволяет эту избыточность частично устранить, а это уже и есть некоторое сжатие. На самом деле, взаимозависимость между компонентами в яркостно-цветовой модели для реальных изображений всё равно сохраняется, но меньшая, чем в RGB.
Строго говоря, пересчёт из RGB в YCbCr (и обратно) может производиться с несколькими разными наборами коэффициентов, но в эти дебри мы не полезем.
2) Кадры (frames) в MPEG2-видео бывают трёх видов: I, P и B.
I (intra coded): опорные, содержат полную версию исходных (несжатых) кадров. MPEG2 допускает видеопоток, состоящий только из таких кадров, но он получается очень большим.
P (predictive coded): содержат отличия от предыдущего I или P-кадра. P-кадры могут содержать как собственно вновь появившиеся части изображения, так и векторы смещения частей изображения из ближайшего предыдущего I или P-кадра.
Поскольку P-кадры не содержат полной информации из соответствующих исходных кадров, они занимают меньше места, чем I. Но при воспроизведении требуют наличия ближайшего предыдущего I-кадра и всех следующих за ним P-кадров вплоть до текущего.
B (bidirectionally-predicted coded): содержат отличия от ближайшего предыдущего и/или последующего P или I-кадра.
По объёму B-кадры самые маленькие, но для воспроизведения требуют предыдущего I- или P-кадра (а вместе с предыдущим P - и всех остальных P-кадров до ближайшего предыдущего I), а также, возможно, и ближайшего следующего P или I-кадра.
Это означает, что к моменту, когда надо воспроизводить B-кадр, декодер должен уже иметь все остальные кадры, от которых зависит этот B.
Для решения этой проблемы кодер меняет последовательность кадров в выходном потоке с тем, чтобы P и I-кадры попали в выходной поток (а следовательно, и в в декодер) раньше, чем все зависящие от них B-кадры, даже если воспроизводиться они должны позже B.
Очевидно, что чем меньше движения присутствует в кодируемой последовательности кадров, тем эффективнее использование P и B-кадров.
Группа кадров, начиная с I и включая все зависящие от него P и B, называется GOP (Group of Pictures).
Последовательно идущие GOP составляют выходной видеопоток.
С какой частотой в видеопотоке должны встречаться I-кадры, стандарт жестко не регламентирует, но обычно их вставляют не реже каждого 15-го, а также при резкой смене картинки, когда кодировать отличия становится невыгодно.
Стандарт допускает разные последовательности типов кадров в разных GOP в пределах одного потока. Кодер может пользоваться этим для улучшения параметров выходного потока.
Соотношение между разными типами кадров в GOP обычно выражают дробью, числитель которой обозначает расстояние между соседними I или P-кадрами, а знаменатель - расстояние между I-кадрами (то есть, длину GOP). Типичной является последовательность IBBPBBPBBPBB, обозначающаяся как 3/12.
Из этого описания должно стать понятно, почему в общем случае MPEG2-поток нельзя разрезать в видеоредакторе с точностью до произвольного кадра. Резать можно только по I-кадрам (или, что то же самое, с точностью до GOP). Все редакторы, которые позволяют резать MPEG2-поток по произвольному кадру (и MPEG4, кстати, тоже: там почти такие же типы кадров), вынуждены декодировать кадры в пределах разрезаемой GOP и кодировать нужные кадры обратно с тем, чтобы новая GOP начиналась с I-кадра. Повторное кодирование обычно приводит к внесению дополнительных искажений.
[Дальнейшая часть про макроблоки относится не только к MPEG2, а и к некоторым другим системам кодирования видео, использующим то же цветовое пространство.]
Для целей кодирования из исходного несжатого изображения выбираются блоки размером 8x8 чисел по каждой из компонент Y, Cb и Cr. Блоки всех трёх компонент, относящиеся к одной части исходного кадра размером 16x16 пикселов, объединяются в макроблок. Это объясняет, почему допустимые размеры кадров в MPEG2 и большинстве других систем кодирования цифрового видео должны быть кратны 16. Если они не, то перед кодированием кадр придётся дополнять по краям полосками, а после декодирования эти полоски отрезать, что приводит к необходимости кодирования, декодирования и передачи ненужной информации.
Теперь вспомним, зачем, собственно, изображение переводилось в YCbCr. А затем, чтобы можно было уменьшить количество информации о цветовых составляющих. Делается это простым способом: сокращением количества блоков в макроблоке.
В одном макроблоке всегда 4 Y-блока. А каждого из Cb и Cr в макроблоке может быть 1, 2 или 4, и данные в них получаются путем усреднения значений от соответствующих исходных пикселов.
Количеством блоков разных типов в макроблоке (chrominance) обычно записывают в виде тройного отношения. Причём, чтобы всех запутать, в другом порядке - Y:Cr:Cb.
4:4:4 означает, что мы решили не жертвовать цветовой информацией, и блоков Y, Cb, Cr будет поровну. Этот вариант лучше всего сохраняет исходное изображение, но, естественно, при прочих равных условиях даёт максимальный битрейт. MPEG2 этот вариант поддерживает, но на практике он не используется.
4:2:2: на 4 блока Y приходится по 2 блока Cb и Cr. Горизонтальное разрешение для Cb и Cr вдвое меньше, чем у Y. Этот вариант иногда применяется для перегонки [относительно] высококачественного MPEG2-видео по спутниковым каналам, но практически никогда не применяется для публичного вещания.
4:2:1: на 4 блока Y приходится 2 блока Cr (с вдвое меньшим горизонтальным разрешением) и 1 блок Cb (с еще вдвое меньшим горизонтальным разрешением). В этом варианте учитывается более низкая чувствительность человеческого глаза к синим оттенкам, чем к красным. Хотя формально такой вариант определён (но не для MPEG2), на практике он не используется ни в одной системе кодирования.
4:1:1: на 4 блока Y приходится по 1 блоку Cb и Cr с вчетверо меньшим горизонтальным разрешением. Используется в некоторых DV-камерах. В MPEG2 не поддерживается.
4:2:0: не значит, что Cb совсем нет. Это чтобы окончательно всех запутать, так обозначаются 4 блока Y и по 1 блоку Cb и Cr со вдвое меньшим разрешением как по горизонтали, так и по вертикали. Это и есть наиболее распространённый вариант, применяемый обычно в DVB, DVD и DV. И единственно возможный в MPEG1.
В каждом макроблоке вместо максимальных 12 остаётся всего 6 блоков, что уменьшает общее количество информации вдвое.
[Конец части про макроблоки]
Поскольку изображение двигается не обязательно макроблоками (кусочками 16x16 пикселов), в MPEG2 определяется понятие слоя (slice). Слои - это неперекрывающиеся последовательности из 1 или более идущих подряд макроблоков. Векторы смещения указываются применительно к слоям.
Исходный кадр можно заранее полностью поделить на кусочки 16x16 пикселов только в том случае, если кодер решил сделать из него I-кадр. Если же он решил, что будет делать P или B, то начинается кропотливая работа по сравнению кадра с предыдущим/последующим на предмет, что там повторяется, и осталось ли оно на том же месте или съехало в сторону. В последнем случае в выходной кадр пишется вектор смещения, который может быть достаточно произвольным. А сама смещённая часть изображения, соответственно, может располагаться в любом месте кадра, и её координаты совершенно не обязательно будут кратны 16.
Чем лучше кодер умеет выполнять эту работу, тем меньше информации можно будет положить в P или B-кадр, то есть, получить на выходе из этого этапа меньший поток, а значит, использовать полученный выигрыш для улучшения качества изображения на следующем этапе.
Но естественно, это требует либо бОльших вычислительных мощностей, либо процесс будет идти не в реальном времени. Как обычно, реальные решения используют компромиссный вариант: кодеру задаётся максимальная величина вектора смещения, и если часть изображения в очередном кадре уехала дальше, то она просто не найдется и будет считаться совсем новой.
Для чересстрочного видео полукадры (fields) могут кодироваться по вышеописанной схеме как по отдельности, без склеивания со своим вторым полукадром, так и после склеивания в целые кадры.
3) DCT
К каждому блоку 8x8 (отдельно по каждой яркостно-цветовой составляющей, естественно) применяется дискретное косинусное преобразование, которое на выходе даёт матрицу коэффициентов 8x8. Особых потерь информации при этом не происходит, разве только за счет округления до целых чисел. А потом к полученной матрице применяется квантизация, и от её параметров по большей части и зависит, насколько закодированная картинка будет отличаться от исходной. Эти параметры обычно не задаются кодеру в явном виде, а подстраиваются динамически в зависимости от заданного и реального получающегося битрейта.
4)Дальнейшее сжатие
На выходе предыдущего этапа получается матрица, один из углов которой по большей степени состоит из нулей. Чем сильнее квантизация, тем больше там нулей. Тем сильнее огрубился результат, тем сильнее искажена картинка, тем сильнее мы сможем сжать данные. Значения из этой матрицы выбираются в зигзагообразном порядке, начиная с противоположного нулям угла, так что все нули оказываются в конце. После чего к этой последовательности применяется RLE (run-length encoding) и сжатие по Хаффману.
Стандарт определяет, чтО должно получиться в результате вышеописанных действий (синтаксис и семантику потока), но оставляет большую свободу в части реализации. Поэтому MPEG2-кодеров много, как аппаратных, так и программных, с разными способностями и разными результатами.
Вот, собственно, и всё.
Нераскрытой осталась тема профилей (profiles) и уровней (levels) MPEG2.
Стандарт широк и разнообразен, и требовать полной его реализации от всех программ и железяк было бы неправильно. Поэтому он определяет несколько подмножеств ситнаксиса выходного потока (по типам кадров, возможным соотношениям блоков в макроблоке и т.п.), которые называются "профилями".
Кроме того, стандарт не накладывает явных ограничений на некоторые величины. В частности, когда я в прошлой части написал про допустимые размеры кадров, я несколько наврал. Стандарт вообще допускает изображения размером примерно до 2^14 на 2^14 пикселов, ограничение состоит лишь в разрядности соответствующих служебных полей в заголовках. Но реально оно вряд ли кому нужно, поэтому стандарт определяет ещё несколько групп ограничений (по размерам кадров, частоте кадров, максимальному битрейту) для разных применений. Они называются "уровнями" (levels), которые и задают приведенные ранее размеры кадров.
Про декодирование
С декодером дело обстоит проще, у него никаких параметров нет, а есть только входной поток. Декодер выполняет все вышеуказанные операции в обратную сторону и получает исходные кадры (с точностью до внесённых при кодировании искажений). Потом, если изображение надо вывести на аналоговое устройство (обычный телевизор), кадры пропускаются через цифроаналоговый преобразователь. А если у устройства отображения есть цифровой вход (а у приёмника, в состав которого входит MPEG-декодер, - соответствующий цифровой выход), то поток преобразуется в формат этого интерфейса и передаётся прямо в цифре.
При декодировании есть только одна существенная проблема: что делать, если часть данных была потеряна при передаче? Стандарт на эту тему чётких инструкций не даёт, поэтому авторы разных декодеров решают её по-разному. Некоторые заполняют отсутствующие в кадре блоки зелёным цветом (почему именно зелёным - не знаю, возможно, так выглядит матрица из нулей в YCbCr после преобразования в RGB), некоторые копируют соседние блоки (результат получается довольно глупый, зато не требуется дополнительных ресурсов), некоторые интерполируют отсутствующие блоки из соседних, а некоторые целиком пропускают кадры с отсутствующими блками, показывая вместо них предыдущие целые.
Tags: