Процесс кодирования видео на основе DCT

У меня есть некоторые вопросы, которые, я надеюсь, вы сможете прояснить. Я самостоятельно изучил процесс кодирования видео, аналогичный Mpeg2. Процесс выглядит следующим образом:

  1. Разделите изображение RGBA на 4 отдельных блока памяти данных канала. поэтому массив всех значений R, отдельный массив значений G и т. д.

  2. возьмите массив и возьмите блок данных 8x8 пикселей, чтобы преобразовать его с помощью дискретного косинусного преобразования (DCT).

  3. Проквантуйте этот блок 8x8, используя предварительно вычисленную матрицу квантования.

  4. Zigzag кодирует результат шага квантования. Так что я должен получить след последовательных чисел.

  5. Run Length Encode (RLE) результат зигзагообразного алгоритма.

  6. Код Хаффмана данные после этапа RLE. Использование подстановки значений из предварительно вычисленной таблицы Хаффмана.

  7. Вернитесь к шагу 2 и повторяйте до тех пор, пока данные всех каналов не будут закодированы.

  8. Вернитесь к шагу 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, которые помогли мне понять отдельные алгоритмы, но не то, как они все связаны вместе, чтобы сформировать процесс кодирования в коде.


c++ video-encoding run-length-encoding huffman-code dct
person Hinchy    schedule 18.01.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

(это больше похоже на JPEG, чем на MPEG-2 - видеоформаты больше связаны с сжатием различий между кадрами, а не просто сжатием изображения)

Если вы работаете в RGB, а не в YUV, вы, вероятно, не получите такой же степени сжатия и/или качества, но вы можете сделать это, если хотите. Преобразование цветового пространства вряд ли является большой рабочей нагрузкой по сравнению с остальной частью алгоритма.

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

И да, вы можете кодировать пары RLE как отдельные символы в кодировке Хаффмана.

person JasonD    schedule 18.01.2013
comment
Большое спасибо за быстрый и исчерпывающий ответ. 1) Да, я полагаю, вы можете сказать, что это больше похоже на JPEG, чем на MPEG-2, поскольку меня интересует только кодирование серии I-кадров, а не P/B-кадров. 2) Я выполнил профилирование, и используемый мной преобразователь YUV (полностью оптимизированная сборка SIMD MMX) оказался самой медленной функцией на моем процессоре. 3) Спасибо, что очистили для меня этап RLE/Huffman. Огромное спасибо. - person Hinchy; 18.01.2013

arrow_upward
1
arrow_downward

1) Да, вы захотите преобразовать в YUV... для достижения более высоких коэффициентов сжатия вам нужно воспользоваться способностью человеческого глаза «не обращать внимания» на значительную потерю цвета. Как правило, вы сохраняете плоскость Y с тем же разрешением (предположительно, и плоскость A), но уменьшаете разрешение плоскостей U и V на 2x2. Например. если вы делаете 640x480, Y - 640x480, а плоскости U и V - 320x240. Кроме того, вы можете выбрать другое квантование для плоскостей U/V. Стоимость этого преобразования невелика по сравнению с DCT или DFT.

2) Вам не нужно использовать RLE, вы можете просто написать код Хаффмана напрямую.

person mark    schedule 18.01.2013
comment
Я пытаюсь заменить используемый кодировщик, для которого у меня нет исходного кода. Я знаю, что он основан на MPEG-2. Я начал с кодека Schroedinger на основе вейвлетов ссылка. Я не хотел проблем с патентами. У меня он работал с альфа-каналом в VS2005. Я применил преобразователь RGBA->YUV+A для этой попытки кодирования. YUV имел форму YUV420. К сожалению, мне не удалось заставить этот кодировщик быть таким же производительным, как оригинал, как с точки зрения потребления памяти, так и с точки зрения скорости. поэтому я оставил его для более старой системы MPEG-2 и RGBA. Надеюсь, это объясняет, где лежат мои мысли. - person Hinchy; 18.01.2013
comment
Кстати, вы изучали кодек Google WebM/libvpx/VP8? Это отличный видеокодек (возможно, качество близкое к mpeg4), несколько платформ, с исходным кодом. Вы можете настроить его так, чтобы он выполнял все кадры I/Key, если хотите (в основном WebP)... - person mark; 18.01.2013
comment
Я посмотрел на WebM Mark. Похоже, что это следующая «большая вещь» для видеокодеров. Как и в случае с Schroedinger, я понимаю: он основан на вейвлетах и ​​предназначен для потоковой передачи больших (HD) файлов. Так что я полагаю, что у меня будут такие же проблемы с WebM, как и с Schroedinger. Следует отметить, что я потратил глупое количество времени на исправление Schroedinger для запуска через VS2005 и добавление в него поддержки альфа-канала. У меня нет времени решать те же проблемы с WebM. - person Hinchy; 21.01.2013