Оценка движения на основе блоков при сжатии видео

Question

Как мы знаем, почти все видеокодеры используют временное кодирование.Он использует оценку движения на основе блоков (прямоугольная область) для нахождения наилучшего значения блока пикселей для текущего кадра в ссылочных / предыдущих кадрах.Это дает вектор движения.Это хорошо, если движение является поступательным (т. Е. Если блок перемещается влево / вправо или вверх / вниз). Что если объект вращается и если объект имел прямоугольную форму и вращается, то оценка движения не будет такой точной и, следовательно,не приведет к наименьшей предварительной (первоначальный прогноз минус).

Итак, какие методы использует видеокодер, чтобы справиться с такими вращательными движениями. / Движения.

Обрабатывает ли он тогда такую ​​ситуацию, кодируя этот блок как внутриблочный (как есть код без какой-либо ссылки на предыдущий) в кадре P

или

какие-нибудь другие приемы под рукой, чтобы справиться с этим, кодируя его как сам макроблок P?

Answer 1

Насколько я знаю, у видеокодеров нет особого случая для вращательных движений. Во-первых, само обнаружение вращательного движения потребовало бы много времени. Кроме того, оценка движения выполняется на уровне макроблоков, и, следовательно, в кадре может быть довольно много макроблоков, которые не перемещаются вращательно, если только сам весь кадр не вращается.

Один «трюк», который я могу предложить, следующий:

Рассчитать PSNR между прогнозируемым кадром (P-кадром) и фактическим кадром. Если PSNR слишком низок, имеет смысл кодировать кадр как информационный кадр (I-кадр). Обратите внимание, что это не может быть сделано для прямых передач, потому что это займет много времени. Но это можно сделать, когда время кодирования не является фактором. В этом случае вы можете просто использовать полный поиск.

Answer 2

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

Если бы вы использовали кодирование на основе движения для чего-то вроде видео водопада, его было бы невозможно уменьшитьразмер.

Аналогичная концепция применима к фотографиям в формате JPEG.Сжатие JPEG работает только потому, что оно использует особую чувствительность человеческого глаза.

В конечном счете, данные - это данные, и вы не можете без потерь уменьшить их количество.Лучшее, что вы можете сделать, - это сделать некоторые предположения об источнике и месте назначения, а затем попытаться воссоздать что-то, что будет неразличимо для зрителя, но использует меньше данных.Вот почему оценка движения работает.99,99 процента фильмов, которые люди смотрят, содержат людей, которые движутся, как люди ... влево и вправо ... вверх и вниз.И «РАБОТЫ», я имею в виду, можно сделать за достаточно быстрое время, чтобы сделать это целесообразным для миллионов часов отснятого материала каждый год.

Это, конечно, имеет отношение к энтропии Шеннона1009 *http://en.wikipedia.org/wiki/Entropy_(information_theory), но эта статья заставляет мой мозг немного просачиваться сквозь мои глазницы ...

Answer 3

Во-первых, вычислительная сложность, которая резко увеличивается при каждом добавлении направления вращения. Например, время оценки движения составляет «х» секунд. После добавления говорят правая рука на 90 градусов, мы опять секунды «X», так как он должен проверить то же систему отсчета окна поиска снова с вращающимся блоком. Снова после добавления левого поворота на 90 градусов, снова это добавляет еще x секунд к оценке движения и так далее. И главная проблема здесь заключается в том, что во всем кодере, как правило, оценка движения является блоком, который потребляет большую часть времени кодирования.

Второй вопрос - сложность блока компенсации движения. Если у нас есть вращательный блок в оценке или предсказании, то мы должны сгенерировать то же преобразование для генерации скомпенсированного кадра, также в кодере и декодере. Хуже всего то, что это добавляет много сложности и на стороне декодера.

Третье - это модуль прогнозирования для поддержки переменного размера блока. Стандарт всегда определяет векторы движения для фиксированных размеров блока. Если предлагаются размеры блоков вращения, то направления также должны быть стандартизированы в декодере, где блок компенсации движения, энтропийный кодер / декодер и т. Д.

Четвертая вещь - это векторное кодирование движения. Так как мы добавляем векторы вращательного движения, нам нужно добавить дополнительные биты к векторам движения. Итак, поместите эти вещи в баланс луча - «добавление дополнительных битов для каждого MV» и «повышение эффективности сжатия с использованием векторов вращательного движения», который весит Больше. Если баланс сбалансирован или если «добавление дополнительных битов для каждого MV» весит больше, то использование вращательных MV не имеет смысла.

Пятое касается глубокого понимания блок-схемы кодера. Кодер, который мы используем, аналогичен адаптивному модулятору дифференциального импульсного кода или любому аналогичному типу с прогнозирующим кодированием. Видеосигнал всегда кодируется дифференциально. Когда видеосигнал или любой другой сигнал кодируются по-разному, разница во времени между предыдущей и текущей выборками бесконечно мала (здесь 1 / частота кадров), так что отдельные блоки всегда следуют поступательному направлению. Итак, мы используем, ротационные MV только в том случае, если мы используем несколько опорных кадров, когда опорный кадр больше, чем частота кадров, или, по крайней мере, больше, чем размер GOP. Таким образом, в этом случае вращающиеся MV могут дать очень небольшое улучшение PSNR или значительно увеличить время оценки движения.

Другое дело о субъективном и статистическом изучении направления движения.

Несмотря на все это, в JCT-VC есть некоторые предложения по реализации этого, но в конечном итоге они не утверждены в текущем стандарте HEVC. Может быть, они попытаются выяснить это и решить все проблемы в будущем.