Процесс кодирования видео на основе DCT
У меня есть некоторые вопросы, которые, я надеюсь, вы сможете прояснить. Я сам учил себя процессу кодирования видео, похожему на Mpeg2. Процесс выглядит следующим образом:
-
Разделите изображение RGBA на 4 отдельных блока памяти данных канала. таким образом, массив всех значений R, отдельный массив значений G и т. д.
-
возьмите массив и возьмите блок данных размером 8×8 пикселей, чтобы преобразовать его с помощью дискретного косинусного преобразования (DCT).
-
Квантовать этот блок 8×8, используя предварительно рассчитанную матрицу квантования.
-
Зигзагообразное кодирование выводит шаг квантования. Таким образом, я должен получить след последовательных чисел.
-
Run Length Encode (RLE) — вывод алгоритма зигзага.
-
Код Хаффмана данные после этапа RLE. Использование подстановки значений из предварительно вычисленной таблицы Хаффмана.
-
Вернитесь к шагу 2 и повторяйте, пока все данные каналов не будут закодированы.
-
Вернитесь к шагу 2 и повторите для каждого канала
Первый вопрос: нужно ли преобразовывать значения RGBA в значения YUV + A (YCbCr + A), чтобы процесс работал, или он может продолжать использовать RGBA? Я спрашиваю, поскольку преобразование RGBA-> YUVA — это большая рабочая нагрузка, которую я хотел бы избежать, если это возможно.
Следующий вопрос. Мне интересно, должно ли хранилище RLE работать только для 0 или это может быть распространено на все значения в массиве? Смотрите примеры ниже:
440000000111 == [2,4][7,0][3,1] // RLE for all values
or
440000000111 == 44[7,0]111 // RLE for 0's only
Последний вопрос: каким должен быть один символ на сцене Хаффмана? будет ли символ, который будет заменен, значением 2 или 4, или символ будет парой уровня выполнения [2,4], например.
Спасибо, что нашли время, чтобы прочитать и помочь мне здесь. Я прочитал много статей и посмотрел много видео на YouTube, которые помогли мне понять отдельные алгоритмы, но не то, как они все связаны друг с другом, чтобы сформировать процесс кодирования в коде.
Решение
(это больше похоже на JPEG, чем на MPEG-2 — форматы видео больше сжимают различия между кадрами, а не просто сжимают изображения)
Если вы работаете в RGB, а не в YUV, вы, вероятно, не получите такую же степень сжатия и / или качество, но вы можете сделать это, если хотите. Преобразование цветового пространства вряд ли является тяжелой рабочей нагрузкой по сравнению с остальной частью алгоритма.
Обычно в такого рода приложениях вы RLE нули, потому что это элемент, который вы получаете много повторений (и, надеюсь, также хорошее число в конце каждого блока, который может быть заменен одним значением маркера), в то время как другие коэффициенты не так много повторений, но если вы ожидаете повторения других значений, я думаю, YMMV.
И да, вы можете кодировать пары RLE как отдельные символы в кодировании Хаффмана.
Другие решения
1) Да, вы хотите конвертировать в YUV … для достижения более высоких коэффициентов сжатия вам нужно воспользоваться способностью человеческого глаза «пропустить» значительную потерю цвета. Как правило, вы сохраняете плоскость Y в том же разрешении (предположительно, также в плоскости A), но уменьшаете выбор плоскостей U и V на 2×2. Например. если вы делаете 640×480, Y — 640×480, а плоскости U и V — 320×240. Кроме того, вы можете выбрать другое квантование для плоскостей U / V. Стоимость такого преобразования мала по сравнению с DCT или DFT.
2) Вам не нужно связывать его, вы можете просто кодировать Хаффмана напрямую.
detector