ОГРАНИЧЕНИЕ СОПОСТАВЛЕНИЯ ДЛЯ ВИРТУАЛЬНОГО БУФЕРА ВНУТРИБЛОЧНОГО КОПИРОВАНИЯ Российский патент 2024 года по МПК H04N19/593 H04N19/105 H04N19/176 H04N19/132 H04N19/11 

Область техники, к которой относится изобретение

Данный патентный документ относится к способам, устройствам и системам кодирования видео.

Уровень техники

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

Раскрытие сущности изобретения

Устройства, системы и способы, которые относятся к цифровому кодированию видео и, в частности, к общим виртуальным буферам для внутриблочного копирования (IBC). Описанные способы могут применяться как к существующим стандартам кодирования видео (например, высокоэффективное кодирование видео (HEVC)), так и к будущим стандартам кодирования видео или видеокодекам.

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

В другом примерном аспекте раскрыт способ обработки видео. Способ включает в себя этапы, на которых определяют, для преобразования между текущим видеоблоком видеоизображения видео и кодированным представлением видео, доступность одного или более опорных отсчетов опорного блока, используемого для предсказания текущего видеоблока, на основе правила, причем правило устанавливает использовать при указанном определении детализацию на уровне виртуального блока данных конвейера (VPDU); и выполняют, на основе указанного определения, преобразование между текущим блоком и кодированным представлением текущего блока.

В еще одном аспекте раскрыт другой способ обработки видео. Способ включает в себя этап, на котором выполняют преобразование между текущим видеоблоком видеоизображения видео и кодированным представлением видео в соответствии с правилом, причем текущий видеоблок представлен в кодированном представлении с использованием остатка предсказания от опорных отсчетов из опорной области в видеоизображениях, при этом правило устанавливает, что значения отсчетов в опорной области сбрасываются в начале обработки каждого виртуального блока данных конвейера (VPDU) во время преобразования на основе позиции текущего VPDU текущего видеоблока.

В еще одном аспекте раскрыт другой способ обработки видео. Способ включает в себя этапы, на которых определяют, для текущего видеоблока видеоизображения видео и кодированного представления видео, что отсчеты из текущего виртуального блока данных конвейера (VPDU) и трех дополнительных недавно обработанных VPDU в видеоизображении доступны как опорные отсчеты для выработки предсказания текущего видеоблока благодаря тому, что текущий видеоблок имеет размер больше, чем размер отсчетов яркости 64×64; и выполняют указанное преобразование на основе указанного определения.

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

В еще одном характерном аспекте вышеописанный способ воплощен в виде исполняемого процессором кода и хранится на машиночитаемом носителе программы.

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

В еще одном характерном аспекте устройство видеодекодера может реализовывать способ, который описан в данном документе.

Вышеупомянутые и другие аспекты и признаки раскрытой технологии более подробно представлены в подробном описании изобретения, на чертежах и в формуле изобретения.

Краткое описание чертежей

Фиг. 1 - пример обращения к текущему изображению;

фиг. 2 - пример динамической опорной области в JVET-M0407;

фиг. 3 - алгоритм потока декодирования с восстановлением формы;

фиг. 4 - пример для текущего блока CU (синий блок 602)), в котором блок, закрашенный красным цветом (604) является пересекающим опорным блоком столбца VPDU, и блок, закрашенный желтым цветом (606), является пересекающим опорным блоком строки VPDU. Каждый большой блок указывает VPDU 64×64, и зеленая область (608) указывает восстановленные пиксели, которые могут использоваться для ссылки на IBC;

фиг. 5 - блок-схема примера аппаратной платформы для реализации декодирования визуальных медиа или технологии кодирования визуальных медиа, описанной в настоящем документе;

фиг. 6 - блок-схема примерной системы обработки видео, в которой могут быть реализованы раскрытые технологии;

фиг. 7A, 7B и 7C - блок-схемы последовательностей операций примерных способов обработки видео на основе некоторых реализаций раскрытой технологии;

фиг. 8A-8D - блок-схемы последовательностей операций примерных способов обработки видео на основе некоторых реализаций раскрытой технологии.

Осуществление изобретения

Варианты осуществления раскрытой технологии могут применяться к существующим стандартам кодирования видео (например, HEVC, H.265) и будущим стандартам для улучшения характеристик сжатия. Заголовки разделов используются в данном документе для улучшения читаемости описания и никоим образом не ограничивают обсуждение или варианты осуществления (и/или реализации) только соответствующими разделами.

2. Введение в кодирование видео

В связи с растущим спросом на видео с более высоким разрешением в современных технологиях повсеместно используются способы и технические приемы кодирования видео. Видеокодеки, как правило, включают в себя электронную схему или программное обеспечение, которые сжимают или распаковывают цифровое видео, и они постоянно совершенствуются, чтобы обеспечить более высокую эффективность кодирования. Видеокодек преобразует несжатое видео в сжатый формат или наоборот. Существуют сложные соотношения между качеством видео, объемом данных, используемых для представления видео (определяется скоростью передачи данных), сложностью алгоритмов кодирования и декодирования, чувствительностью к потерям и ошибкам данных, простотой редактирования, произвольным доступом и сквозная задержка (запаздывание). Сжатый формат, как правило, соответствует стандартной спецификации сжатия видео, например, стандарту высокоэффективного кодирования видео (HEVC) (также известному как H.265 или MPEG-H, часть 2), стандарту универсального кодирования видео, который будет доработан, или другим текущим и/или будущим стандартам кодирования видео.

Стандарты кодирования видео развивались в основном благодаря развитию хорошо известных стандартов ITU-T и ISO/IEC. ITU-T выпустил H.261 и H.263, ISO/IEC выпустил MPEG-1 и MPEG-4 Visual, и две организации совместно выпустили стандарты H.262/MPEG-2 Video и усовершенствованного кодирования видео (AVC) H.264/MPEG-4 и H.265/HEVC. Начиная с H.262, стандарты кодирования видео основывались на структуре гибридного кодирования видео, в которой используется временное предсказание плюс кодирование с преобразованием. Чтобы исследовать будущие технологии кодирования видео за рамками HEVC, в 2015 году VCEG совместно с MPEG основали объединенную группу экспертов по видео (Joint Video Expert Team, JVET). С тех пор JVET были приняты многие новые способы и помещены в опорное программное обеспечение под названием модель совместных исследований (Joint Exploration Model, JEM). В апреле 2018 года была создана объединенная группа экспертов по видео (JVET) между VCEG (Q6/16) и ISO/IEC JTC1 SC29/WG11 (MPEG) для работы над стандартом VVC, нацеленным на снижение скорости передачи битов на 50% по сравнению с HEVC.

2.1. Межкадровое (inter) предсказание в HEVC/H.265

Каждый интер-предсказанный PU имеет параметры движения для одного или двух списков опорных изображений. Параметры движения включают в себя вектор движения и индекс опорного изображения. Использование одного из двух списков опорных изображений также может сигнализироваться с использованием inter_pred_idc. Векторы движения могут быть закодированы явным образом как разности (дельты) относительно предикторов.

Когда CU кодируется в режиме пропуска, один PU ассоциируется с CU, и отсутствуют какие-либо значимые остаточные коэффициенты, кодированная дельта векторов движения или индекс опорного изображения. Определен режим слияния, при котором параметры движения для текущего PU получаются из соседних PU, включая пространственные и временные кандидаты. Режим слияния может применяться к любому интер-предсказанному PU, а не только к режиму пропуска. Альтернативой режиму слияния является явная передача параметров движения, где вектор движения (точнее, разности векторов движения (MVD) по сравнению с предиктором вектора движения), соответствующий индекс опорного изображения для каждого списка опорных изображений и использование списка опорных изображений явно сигнализируются для каждого PU. В настоящем раскрытии такой режим называется усовершенствованным предсказанием вектора движения (AMVP).

Когда сигнализация указывает, что должен использоваться один из двух списков опорных изображений, PU создается из одного блока отсчетов. Это называется «однонаправленным предсказанием». Однонаправленное предсказание доступно как для P-слайсов, так и для B-слайсов.

Когда сигнализация указывает, что должны использоваться оба списка опорных изображений, PU создается из двух блоков отсчетов. Это называется «двунаправленным предсказанием». Двунаправленное предсказание доступно только для B-слайсов.

Следующий текст содержит подробную информацию о режимах межкадрового предсказания, указанных в HEVC. Описание начнется с режима слияния.

2.2. Привязка к текущему изображению

Привязка к текущему изображению (CPR), или когда-то названная как внутриблочное копирование (IBC), была принята в расширениях кодирования содержания экрана HEVC (HEVC-SCC) и текущей тестовой модели VVC (VTM-3.0). IBC расширяет концепцию компенсации движения от межкадрового кодирования до внутрикадрового кодирования. Как показано на фиг. 1, текущий блок предсказывается опорным блоком в одном и том же изображении, когда применяется CPR. Отсчеты в опорном блоке должны быть уже восстановлены до того, как текущий блок будет закодирован или декодирован. Хотя CPR не так эффективна для большинства последовательностей, захваченных камерой, она показывает значительный выигрыш при кодировании для содержания экрана. Причина состоит в том, что на изображении содержания экрана присутствует множество повторяющихся шаблонов, таких как значки и текстовые символы. CPR позволяет эффективно устранить избыточность между этими повторяющимися шаблонами. В HEVC-SCC интер-кодированный блок кодирования (CU) может применять CPR, если он выбирает текущее изображение в качестве опорного изображения. В этом случае MV переименовывается в блочный вектор (BV), и BV всегда имеет точность до целого пикселя. Чтобы быть совместимым с основным профилем HEVC, текущее изображение помечается как «долгосрочное» опорное изображение в буфере декодированных изображений (DPB). Следует отметить, что аналогичным образом в стандартах кодирования множественных ракурсов/3D видео опорное изображение между ракурсами также помечается как «долгосрочное» опорное изображение.

Следуя BV, чтобы найти его опорный блок, предсказание может быть выработано путем копирования опорного блока. Остаток может быть получен путем вычитания опорных пикселей из опорных сигналов. Затем можно применять преобразование и квантование, как и в других режимах кодирования.

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

2.3. CPR в расширениях кодирования содержания экрана HEVC

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

Переменные offsetX и offsetY получаются следующим образом:

offsetX = ( ChromaArrayType = = 0 ) ? 0 : ( mvCLX[ 0 ] & 0x7 ? 2 : 0 ) (8-104)

offsetY = ( ChromaArrayType = = 0 ) ? 0 : ( mvCLX[ 1 ] & 0x7 ? 2 : 0 ) (8-105)

Требование соответствия битового потока состоит в том, что, когда опорным изображением является текущее изображение, вектор mvLX движения яркости должен подчиняться следующим ограничениям:

- Когда процесс получения для доступности блока порядка z-сканирования, как указано в пункте 6.4.1, инициируется (xCurr, yCurr), установленным равным (xCb, yCb), и соседним местоположением яркости (xNbY, yNbY), установленным равным ( xPb + ( mvLX[ 0 ]>>2 ) - offsetX, yPb + ( mvLX[ 1 ]>>2 ) - offsetY ) в качестве входных значений, выходное значение должно быть равно значению «истина» (TRUE).

- Когда процесс получения для доступности блока порядка z-сканирования, как указано в пункте 6.4.1, инициируется (xCurr, yCurr), установленным равным (xCb, yCb), и соседним местоположением яркости (xNbY, yNbY), установленным равным ( xPb + ( mvLX[ 0 ]>>2 ) + nPbW - 1 + offsetX, yPb + ( mvLX[ 1 ]>>2 ) + nPbH - 1 + offsetY ) в качестве входных значений, выходное значение должно быть равно значению «истина» (TRUE).

- Должны выполняться одно или оба из следующих условий:

- Значение ( mvLX[ 0 ]>>2 ) + nPbW + xB1 + offsetX меньше или равно 0.

- Значение ( mvLX[ 1 ]>>2 ) + nPbH + yB1 + offsetY меньше или равно 0.

- Должно выполняться следующее условие:

(xPb + (mvLX[ 0]>>2) + nPbSw - 1 + offsetX) / CtbSizeY - xCb / CtbSizeY <= yCb/CtbSizeY - (yPb + ( mvLX[ 1]>>2) + nPbSh - 1 + offsetY) / CtbSizeY (8-106)

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

2.4. CPR/IBC в тестовой модели VVC

В текущей тестовой модели VVC, то есть в проекте VTM-3.0, весь опорный блок должен соответствовать текущей единице дерева кодирования (CTU) и не перекрываться с текущим блоком. Таким образом, нет необходимости дополнять опорный блок или блок предсказания.

Когда двойственное дерево включено, структура разделения может отличаться от CTU яркости до CTU цветности. Таким образом, для цветового формата 4:2:0 один блок цветности (например, CU) может соответствовать одной совмещенной области яркости, которая была разделена на несколько CU яркости.

Блок цветности может быть закодирован в режиме CPR только тогда, когда будут истинными следующие условия:

(1) каждый CU яркости в совместно расположенном блоке яркости должен быть закодирован в режиме CPR.

(2) каждый из BV блока 4×4 яркости сначала преобразуется в BV блока цветности, и BV блока цветности является действительным BV.

Если любое из двух условий является ложным, блок цветности не должен кодироваться в режиме CPR.

Следует отметить, что определение «действительный BV» имеет следующие ограничения:

(1) все отсчеты в опорном блоке, идентифицированном BV, должны находиться в пределах ограниченного диапазона поиска (например, должны находиться в пределах одной и той же CTU в текущем проекте VVC).

(2) все отсчеты в опорном блоке, идентифицированные BV, были восстановлены.

2.5. CPR/IBC в JVET-L0297/JVET-M0407/JVET-M0408

В VTM3.0 опорная зона для CPR/IBC ограничена текущей CTU, которая составляет до 128×128. JVET-L0297/JVET-M0407/JVET-M0408 представляют способы динамического изменения опорной зоны для повторного использования памяти для хранения опорных отсчетов для CPR/IBC, чтобы блок CPR/IBC мог иметь больше опорных кандидатов, в то время как опорный буфер для CPR/IBC может быть сохранен или сокращен из одной CTU.

На фиг. 2 показан способ, в котором блок имеет размер 64×64, и CTU содержит 4 блока 64×64. При кодировании блоков размером 64×64 предыдущие 3 блока 64×64 могут использоваться в качестве опорных. Таким образом, декодеру достаточно сохранить 4 блока 64×64 для поддержки CPR/IBC. Вышеупомянутый способ был принят в VTM4.0.

Предположим, что текущей позицией CU яркости относительно верхнего левого угла изображения является (x, y), и текущей позицией блочного вектора является (BVx, BVy). В текущем проекте, если BV действителен, можно утверждать на основе этого, что позиция яркости ((x+BVx)>>6<<6+(1<<7), (y+BVy)>>6<<6) не была восстановлена, и ((x+BVx)>>6<<6+(1<<7), (y+BVy)>>6<<6) не равно (x>>6<<6, у>>6<<6).

2.6. Виртуальный буфер IBC, предложенный в JVET-O1170

Концепция виртуального буфера введена для того, чтобы помочь описать опорную область для режима предсказания IBC. Для размера CTU ctbSize мы обозначаем wIbcBuf=128*128/ctbSize и определяем виртуальный буфер IBC как ibcBuf с шириной wIbcBuf и высотой ctbSize. Таким образом,

- для CTU размером 128×128 размер ibcBuf также равен128×128.

- для CTU размером 64×64 размер ibcBuf равен 256×64.

- для CTU размером 32×32 размер ibcBuf равен 512×32.

Следует отметить, что ширина и высота VPDU равны min(ctbSize, 64). Обозначим Wv=min (ctbSize, 64).

Виртуальный буфер IBC ibcBuf, поддерживается следующим образом.

(1) В начале декодирования каждой строки CTU обновить весь ibcBuf на значение (-1).

(2) В начале декодирования VPDU (xVPDU, yVPDU) относительно верхнего левого угла изображения установить ibcBuf [x][y]=-1, при x=xVPDU% wIbcBuf,…, xVPDU% wIbcBuf+Wv - 1; y=yVPDU% ctbSize,…, yVPDU% ctbSize+Wv - 1.

(3) После декодирования CU содержит (x, y) относительно левого верхнего участка изображения, установить

ibcBuf [x% wIbcBuf][y% ctbSize]=recSample [x][y]

Таким образом, ограничение битового потока можно просто описать как

Требование соответствия битового потока для bv: ibcBuf [(x+bv [0])% wIbcBuf][(y+bv [1])% ctbSize] не должно быть равным -1.

Благодаря концепции опорного буфера IBC, упрощается также текст для процесса декодирования за счет предотвращения ссылок на межкадровую интерполяцию и процесс компенсации движения, включая процесс, выполняемый в отношении подблока.

2.7. VPDU

Виртуальные блоки данных конвейера (VPDU) определяются как неперекрывающиеся единицы на изображении. В аппаратных декодерах последовательные блоки VPDU обрабатываются одновременно на нескольких стадиях конвейера. Размер VPDU примерно пропорционален размеру буфера на большинстве стадий конвейера, поэтому важно, чтобы размер VPDU был маленьким. В большинстве аппаратных декодеров размер VPDU может быть установлен на максимальный размер блока преобразования (ТБ). Однако в VVC разделение на троичное дерево (TT) и двоичное дерево (BT) может привести к увеличению размера VPDU.

Чтобы сохранить размер VPDU в виде отсчетов яркости 64×64, в VTM5 применяются следующие нормативные ограничения разделения (с модификацией сигнализации синтаксиса):

- Разделение TT не разрешено для CU с шириной или высотой или одновременно с шириной и высотой, равными 128.

- Для CU 128×N при N ≤ 64 (то есть ширина равна 128, и высота меньше 128) не разрешено горизонтальное BT.

- Для N×128 CU при N ≤ 64 (то есть высота равна 128, и ширина меньше 128) не разрешено вертикальное BT.

В VVC, как правило, принято, что ширина и высота VPDU в отсчетах яркости равны min(64, CtbSizeY). Таким образом, для CTB/CTU размером 64×64, 128×128 или 256×256 размер VPDU составляет 64×64. Если размер CTB/CTU равен 32×32, размер VPDU составляет 32×32.

2.8. Управление буфером и кодирование блочных векторов для внутриблочного копирования

Различные функции буфера IBC и подробности для его соответствующего управления описаны в документе PCT/CN2019/093552, который включен в данный документ в качестве ссылки.

2.9. Внутриконтурное восстановление формы (ILR) в JVET-M0427

Основная идея внутриконтурного восстановления формы (ILR) состоит в том, чтобы преобразовать исходный (в первой области) сигнал (сигнал предсказания/восстановления) во второй области (восстановленной области).

Внутриконтурный формирователь яркости реализован в виде пары справочных таблиц (LUT), но только одна из двух LUT должна сигнализироваться, так как другая может быть вычислена из просигнализированной LUT. Каждая LUT представляет собой одномерную 10-битовую таблицу сопоставлений с 1024 записями (1D-LUT). Одна LUT является прямой LUT FwdLUT, которая сопоставляет входные значения Y_i кода яркости с измененными значениями Y_r: . Другая LUT является обратной LUT InvLUT, которая сопоставляет измененные значения кода Y_i с . ( представляет собой восстановление значений Y_i).

2.9.1. Модель PWL

Концептуально кусочно-линейная (PWL) модель реализуется следующим образом:

Пусть ×1, ×2 будут двумя входными точками вращения, и y1, y2 будут их соответствующими выходными точками вращения для одного фрагмента. Выходное значение y для любого входного значения x между ×1 и ×2 может быть интерполировано с помощью следующего уравнения:

y = ((y2-y1)/(x2-x1)) * (x-x1) + y1

В реализации с фиксированной точкой уравнение можно переписать как:

y = ((m * x + 2FP_PREC-1) >> FP_PREC) + c

В данном документе m - скалярная величина, c - смещение, и FP_PREC - постоянное значение, определяющее точность.

Следует отметить, что в программном обеспечении CE-12 модель PWL используется для предварительного вычисления таблиц сопоставления FwdLUT и InvLUT с 1024 записями; но модель PWL также позволяет реализациям вычислять идентичные значения сопоставления «на лету» без предварительного вычисления LUT.

2.9.2. Тест CE12-2

2.9.2.1. Восстановление формы сигнала яркости

Тест 2 внутриконтурного восстановления формы яркости (то есть CE12-2 в предложении) обеспечивает конвейер меньшей сложности, который также устраняет задержку при декодировании для блочного внутрикадрового предсказания при восстановлении внутрикадровых слайсов. Внутрикадровое предсказание выполняется в восстановленной по форме области как для межкадровых, так и для внутрикадровых слайсов.

Внутрикадровое предсказание всегда выполняется восстановленной по форме области, независимо от типа слайса. При таком размещении внутрикадровое предсказание может начаться сразу после выполнения предыдущего восстановления TU. Такое размещении позволяет также обеспечить унифицированный процесс для внутрикадрового режима вместо того, чтобы зависеть от слайса. На фиг. 3 показана блок-схема процесса декодирования CE12-2 в зависимости от режима.

CE12-2 также тестирует 16-сегментные кусочно-линейные (PWL) модели для масштабирования яркости и цветности вместо 32-сегментнных PWL-моделей CE12-1.

Восстановление межкадрового слайса с внутриконтурным формирователем яркости в CE12-2 (слегка затененные блоки указывают сигнал в восстановленной по форме области: остаток яркости; предсказанная внутрикадровая яркость, и восстановленная внутрикадровая яркость)

2.9.2.2. Масштабирование остатка цветности в зависимости от яркости

Масштабирование остатка цветности в зависимости от яркости представляет собой мультипликативный процесс, реализованный с помощью целочисленной операции с фиксированной точкой. Масштабирование остатка цветности компенсирует взаимодействие сигнала яркости с сигналом цветности. Масштабирование остатка цветности применяется на уровне TU. В частности, применяется следующее:

- Для внутрикадрового предсказания усредняется восстановленная яркость.

- Для межкадрового предсказанная усредняется яркость.

Среднее значение используется для определения индекса в модели PWL. Индекс определяет коэффициент масштабирования cScaleInv. Остаток цветности умножается на это число.

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

2.9.2.3. Сигнализация информации на стороне ILR

Параметры отправляются (в настоящее время) в заголовке группа тайлов (аналогично ALF). Сообщается, что они занимают 40-100 битов.

Следующая спецификация основана на версии 9 JVET-L1001. Добавленный синтаксис имеет префикс «++».

sps_reshaper_enabled_flag, равный 1, определяет, что формирователь используется в кодированной видеопоследовательности (CVS). sps_reshaper_enabled_flag, равный 0, определяет, что формирователь не используется в CVS.

++ В синтаксисе заголовка группа тайлов добавить следующую семантику

tile_group_reshaper_model_present_flag, равный 1, определяет, что tile_group_reshaper_model() присутствует в заголовке группа тайлов. tile_group_reshaper_model_present_flag, равный 0, определяет, что tile_group_reshaper_model() не присутствует в заголовке группа тайлов. Когда tile_group_reshaper_model_present_flag отсутствует, предполагается, что он равен 0.

tile_group_reshaper_enabled_flag, равный 1, определяет, что восстановление формы включено для текущей группы тайлов. tile_group_reshaper_enabled_flag, равный 0, определяет, что формирователь не включен для текущей группы тайлов. Когда tile_group_reshaper_enable_flag отсутствует, предполагается, что он равен 0.

tile_group_reshaper_chroma_residual_scale_flag, равный 1, определяет, что масштабирование остатка цветности включено для текущей группы тайлов. tile_group_reshaper_chroma_residual_scale_flag, равный 0, определяет, что масштабирование остатка цветности не включено для текущей группы тайлов. Когда tile_group_reshaper_chroma_residual_scale_flag отсутствует, предполагается, что он равен 0.

++ Добавить синтаксис tile_group_reshaper_model()

reshape_model_min_bin_idx определяет минимальный индекс интервала (или участка), который будет использоваться в процессе построения формирователя. Значение reshape_model_min_bin_idx должно находиться в диапазоне от 0 до MaxBinIdx включительно. Значение MaxBinIdx должно быть равным 15.

reshape_model_delta_max_bin_idx определяет максимально разрешенный индекс MaxBinIdx интервала (или участка) за вычетом максимального индекса интервала, который будет использоваться в процессе построения формирователя. Значение reshape_model_max_bin_idx устанавливается равным MaxBinIdx - reshape_model_delta_max_bin_idx.

reshaper_model_bin_delta_abs_cw_prec_minus1 плюс 1 определяет количество битов, используемых для представления синтаксиса reshape_model_bin_delta_abs_CW[ i ].

reshape_model_bin_delta_abs_CW[ i ] определяет абсолютное дельта-значение кодового слова для i-го интервала.

reshaper_model_bin_delta_sign_CW_flag[ i ] определяет знак reshape_model_bin_delta_abs_CW[ i ] следующим образом:

- Если reshape_model_bin_delta_sign_CW_flag[ i ] равен 0, соответствующая переменная RspDeltaCW[ i ] имеет положительное значение.

- В противном случае (reshape_model_bin_delta_sign_CW_flag[ i ] не равен 0) соответствующая переменная RspDeltaCW[ i ] имеет отрицательное значение.

Когда reshape_model_bin_delta_sign_CW_flag[ i ] отсутствует, предполагается, что он равен 0.

Переменная RspDeltaCW[ i ] = (1 2*reshape_model_bin_delta_sign_CW [ i ]) * reshape_model_bin_delta_abs_CW [ i ];

Переменная RspCW[ i ] получается следующим образом:

Переменная OrgCW устанавливается равной (1<< BitDepth_Y)/(MaxBinIdx+1).

- Если reshaper_model_min_bin_idx < = i <= reshaper_model_max_bin_idx,

RspCW[ i ] = OrgCW + RspDeltaCW[ i ].

- В противном случае RspCW[ i ]=0.

Значение RspCW[ i ] должно находиться в диапазоне от 32 до 2*OrgCW - 1, если значение BitDepth_Y равно 10.

Переменные InputPivot[ i ], где i находится в диапазоне от 0 до MaxBinIdx+1 включительно, получаются следующим образом.

InputPivot[ i ]=i*OrgCW

Переменная ReshapePivot[ i ], где i находится в диапазоне от 0 до MaxBinIdx+1 включительно, переменная ScaleCoef[ i ] и InvScaleCoeff[ i ], где i находится в диапазоне от 0 до MaxBinIdx включительно, получаются следующим образом:

shiftY = 14

ReshapePivot[ 0 ] = 0;

for( i = 0; i <= MaxBinIdx ; i++) {ReshapePivot[ i + 1 ] = ReshapePivot[ i ] + RspCW[ i ]

ScaleCoef[ i ] = ( RspCW[ i ] * (1 << shiftY) + (1 << (Log2(OrgCW) - 1))) >> (Log2(OrgCW))

if ( RspCW[ i ] == 0 )

InvScaleCoeff[ i ] = 0

else

InvScaleCoeff[ i ] = OrgCW * (1 << shiftY) / RspCW[ i ]}

Переменная ChromaScaleCoef[ i ], где i находится в диапазоне от 0 до MaxBinIdx включительно, получаются следующим образом:

ChromaResidualScaleLut[64] = {16384, 16384, 16384, 16384, 16384, 16384, 16384, 8192, 8192, 8192, 8192, 5461, 5461, 5461, 5461, 4096, 4096, 4096, 4096, 3277, 3277, 3277, 3277, 2731, 2731, 2731, 2731, 2341, 2341, 2341, 2048, 2048, 2048, 1820, 1820, 1820, 1638, 1638, 1638, 1638, 1489, 1489, 1489, 1489, 1365, 1365, 1365, 1365, 1260, 1260, 1260, 1260, 1170, 1170, 1170, 1170, 1092, 1092, 1092, 1092, 1024, 1024, 1024, 1024};

shiftC = 11

- если (RspCW[ i ] == 0)

ChromaScaleCoef[ i ]=(1<<shiftC)

- В противном случае (RspCW[ i ]!=0), ChromaScaleCoef[ i ]=ChromaResidualScaleLUT [RspCW[ i ]>>1]

2.9.2.4. Использование ILR

На стороне кодера каждое изображение (или группа тайлов) сначала преобразуется в восстановленную по форме область. И весь процесс кодирования выполняется в восстановленной по форме области. Для внутрикадрового предсказания соседний блок находится в восстановленной по форме области; для межкадрового предсказания опорные блоки (выработанные из исходной области из буфера декодированного изображения) сначала преобразуются в восстановленную по форме область. Затем вырабатываются остатки, и они кодируются в битовый поток.

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

Прямое изменение формы сигнала предсказания выключено в следующих случаях:

○ Текущий блок является интра-кодированным

○ Текущий блок кодируется как CPR (привязка к текущему изображению, также известное как внутриблочное копирование, IBC)

○ Текущий блок кодируется как комбинированный межкадровый-внутрикадровый режим (CIIP), и прямое восстановление формы выключено для блока внутрикадрового предсказания

3. Недостатки существующих реализаций

В текущем проекте виртуального буфера IBC существуют некоторые проблемы.

(1) То, как поддерживать виртуальный буфер IBC, когда размер CTU больше 128×128, не определено.

(2) Соотношение между размером виртуального буфера и размером опорных отсчетов не ясно.

(3) Строчный буфер для режима IBC и BV для строки CTU может быть уменьшен.

(4) Подызображение может быть слишком ограниченным.

(5) Может быть неправильно спроектирована таблица QP цветности.

4. Примеры способов для общих виртуальных буферов для IBC

Обозначим ширину и высоту VPDU как vSize, например, vSize=min (64, ctbSizeY), где ctbSizeY - ширина/высота CTB/CTU яркости.

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

Связанный с этим буфер IBC

1. Размер виртуального буфера IBC (например, который используется для определения действительности блочного вектора или сопоставленного отсчета) может зависеть от размера VPDU и размера CTB/CTU.

а. В одном примере ширина, умноженная на высоту виртуального буфера, может быть фиксированной, однако ширина и/высота виртуального буфера могут зависеть от размера VPDU и/или размера CTB/CTU.

b. В одном примере высота виртуального буфера может быть равна высоте CTB/CTU.

1) Альтернативно или дополнительно, ширина виртуального буфера может быть установлена на (размер виртуального буфера IBC/высоту CTB).

c. В одном примере ширина виртуального буфера может быть равна ширине CTB/CTU.

d. В одном примере ширина виртуального буфера может быть в один или несколько раз больше ширины VPDU.

е. В одном примере высота виртуального буфера может быть в один или несколько раз больше высоты VPDU.

2. Предлагается выделить больший размер виртуального буфера IBC по сравнению с требуемым размером памяти для области поиска IBC BV.

а. В одном примере размер виртуального буфера IBC может быть больше, чем общий размер памяти VPDU, используемой для IBC.

1) В одном примере еще одна CTU может быть выделена виртуальному буферу IBC.

b. В одном примере ширина виртуального буфера IBC может быть равна (128*128/ctbSizeY+ctbSizeY).

c. В одном примере ширина размера виртуального буфера IBC может быть равна (128*128/ctbSizeY+ctbSizeY), и высота размера виртуального буфера IBC может быть равна ctbSizeY.

d. В одном примере ширина виртуального буфера IBC может быть равна (256*128/ctbSizeY). Альтернативно или дополнительно, высота виртуального буфера IBC может быть равна ctbSizeY.

е. В одном примере виртуальный буфер IBC большего размера может быть выделен для большего CTU/CTB.

1) В одном примере, когда размер CTU не меньше, чем K (например, K=128), ширина виртуального буфера IBC может быть равна(128*128/ctbSizeY+ctbSizeY). Альтернативно или дополнительно, высота виртуального буфера IBC может быть равна ctbSizeY.

2) В одном примере, когда размер CTU меньше K (например, K=128), ширина виртуального буфера IBC может быть равна (128*128/ctbSizeY). Альтернативно или дополнительно, высота виртуального буфера IBC может быть равна ctbSizeY.

3. Опорный блок для блока IBC может быть ограничен, чтобы полностью находиться в определенной строке VPDU или столбце VPDU.

а. В одном примере опорному блоку может быть запрещено пересекать разные строки VPDU.

b. В одном примере опорному блоку может быть запрещено пересекать разные столбцы VPDU.

c. В одном примере указанная выше строка или столбец VPDU может относиться к изображению.

d. В одном примере указанная выше строка или столбец VPDU может относиться к виртуальному буферу IBC.

е. Альтернативно или дополнительно, вышеупомянутые способы могут быть задействованы, когда опорный блок, на который указывает BV, пересекает две или более CTU/CTB.

4. Опорный блок для блока IBC может пересекать несколько VPDU/различные строки VPDU/столбцы VPDU. Однако могут потребоваться дополнительные операции для заполнения некоторых значений предсказания в опорном блоке.

а. В одном примере некоторые значения по умолчанию могут использоваться для заполнения некоторых значений предсказания.

5. Ограничение диапазона может применяться к векторам блоков (BV) и/или разностям блочных векторов (BVD), используемым в режиме IBC.

а. В одном примере разрешенный диапазон BV/BVD может зависеть от местоположения текущего кодированного блока IBC, например, координаторов, относительно CTU/CTB, покрывающего текущий блок.

b. В одном примере блочные векторы могут быть ограничены диапазоном [-2m, 2m-1].

c. В одном примере разности блочных векторов после преобразования точности могут быть ограничены диапазоном [-2n, 2n-1].

d. В одном примере разности блочных векторов после преобразования точности могут быть ограничены диапазоном [-2n+1,2n-1].

е. В одном примере разности блочных векторов, передаваемые в потоках битов, могут быть ограничены диапазоном [-2n, 2n-1].

f. В одном примере разности блочных векторов, передаваемые в потоках битов, могут быть ограничены в диапазоне [-2n+1,2n-1].

g) В одном примере m установлено на 18, 17 или 15.

h) В одном примере n установлено на 17, 16 или 14.

1) В одном примере m и/или могут зависеть от точности для хранения BV/вектора движения и/или точности, ассоциированной с разностями блочных векторов.

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

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

l. В одном примере битовый поток соответствия должен удовлетворять указанным выше подпунктам.

1) В качестве альтернативы, процесс отсечения по отношению к BV/BVD может применяться к декодированным BV/BVD до того, как BV/BVD будут использоваться для кодирования/декодирования блока.

6. Количество доступных отсчетов, сопоставленных с виртуальным буфером IBC, может быть ограничено.

а. В одном примере максимальное количество доступных отсчетов, сопоставленных с буфером, может быть меньше, чем размер виртуального буфера IBC.

b. В одном примере максимальное количество доступных отсчетов, сопоставленных с виртуальным буфером IBC, может быть фиксированным, когда размер CTB/CTU больше 64×64.

c. В одном примере количество доступных отсчетов, сопоставленных с виртуальным буфером IBC, может быть ограничено таким образом, чтобы быть меньшим в одни или несколько раз или равным количеству отсчетов в VPDU.

1) В одном примере количество доступных отсчетов, сопоставленных с виртуальным буфером IBC, может быть ограничено таким образом, чтобы быть меньшим в три раза или равным количеству отсчетов в VPDU, когда размер CTU/CTB больше 64×64.

7. Маркировка недоступности для опорных отсчетов IBC, сопоставленных с виртуальным буфером IBC, может выполняться с детализацией VPDU.

а. В одном примере, когда отсчеты необходимо пометить как недоступные, отсчеты в том же VPDU также могут быть помечены как недоступные.

b. В одном примере один или несколько блоков VPDU могут быть одновременно помечены как недоступные.

c. В одном примере отсчеты VPDU, помеченные как недоступные, могут зависеть от позиции текущего VPDU.

d. В одном примере отсчеты VPDU, помеченные как недоступные, могут зависеть от позиции предыдущего или самого последнего декодированного VPDU.

8. Маркировка недоступности для опорных отсчетов IBC, сопоставленных с виртуальным буфером IBC, может выполняться непосредственно перед кодированием/декодированием единицы видео (например, CU/PU/TU). В одном примере для видеоблока W×H с позицией верхнего левого угла (X, Y), относящейся к левому верхнему углу слайса/тайла/блока/подызображения/изображения, содержащему видеоблок, может применяться следующее.

а. В одном примере прямо перед кодированием/декодированием видеоблока соответствующая область в виртуальном буфере может быть помечена как недоступная.

b. В приведенном выше примере соответствующая виртуальная буферная область IBC может быть областью яркости при x=(X%IBC_buf_width)..(X%IBC_buf_width)+W-1, и y=(Y%IBC_buf_height)..(Y%IBC_buf_height)+H-1.

c. В приведенных выше примерах соответствующая виртуальная буферная область IBC может быть областью цветности при x=(X%IBC_buf_width)/SubWidthC..((X%IBC_buf_width)+W-1)/SubWidthC, и y=(Y%IBC_buf_height)/SubHeightC..((Y%IBC_buf_height)+H-1)/SubHeightC.

d. В приведенных выше примерах IBC_buf_width относится к ширине виртуального буфера IBC; IBC_buf_height относится к высоте виртуального буфера IBC.

е. В качестве альтернативы, маркировка недоступности для опорных отсчетов IBC, сопоставленных с виртуальным буфером IBC, может выполняться непосредственно перед кодированием/декодированием K*L отсчетов/пикселей в видеоблоке.

1) В одном примере K и/или L оба равны 1.

2) В одном примере K и/или L установлены равными размеру подблока, используемому в CU/PU.

9. Когда размер CTU/CTB больше 64×64, привязкой IBC может быть текущий VPDU и три последних декодированных VPDU.

а. В одном примере может поддерживаться индекс для каждого VPDU, сопоставленного с виртуальным буфером IBC, чтобы отслеживать порядок декодирования каждого VPDU.

10. Счетчик может поддерживаться для отслеживания количества доступных блоков VPDU, сопоставленных с буфером.

а. В одном примере счетчик сбрасывается на 0 в начале декодирования каждой строки CTU и увеличивается на единицу после того, как был декодирован один VPDU, сопоставленный с буфером.

b. В одном примере, когда значение счетчика больше определенного значения, например 3, отсчеты одного VPDU, сопоставленного с буфером, могут быть помечены как недоступные, и счетчик может быть уменьшен на 1.

11. Когда размер CTU/CTB составляет 128×128, соответствующий виртуальный буфер IBC может иметь размер 256×128.

а. В качестве альтернативы, виртуальный буфер IBC может иметь размер (k*64) ×128, где k>2.

12. Когда размер CTU/CTB равен 256×256, соответствующий виртуальный буфер IBC может иметь размер 64×256 для отслеживания доступности опорных отсчетов, то есть ibcBufW=64, ibcBufH=256.

а. В одном примере перед декодированием VPDU с верхней левой позицией (x0, y0) соответствующая строка VPDU (0, y0% 256) в буфере IBC будет установлена на -1.

13. Когда размер CTU/CTB равен 256×256, соответствующий виртуальный буфер IBC может иметь размер 128×256 для отслеживания доступности опорных отсчетов, то есть ibcBufW=128, ibcBufH=256.

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

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

14. Буфер IBC не может быть сброшен в начале строки CTU.

а. В одном примере виртуальный буфер IBC, унаследованный от указанной выше строки CTU, может использоваться в качестве начала текущей строки CTU.

b. В качестве альтернативы, виртуальный буфер IBC может быть частично сброшен в начале строки CTU.

1) В одном примере VPDU в указанной выше строке CTU может быть унаследован в текущем буфере IBC, в то время как другая область буфера может быть сброшена.

2) В одном примере самый нижний левый VPDU указанной выше строки CTU может быть унаследован в текущем буфере IBC, в то время как другая область буфера может быть сброшена.

15. То, помечать ли отсчеты в буфере как недоступные и/или как это делать, может не зависеть от позиции блока цветности.

а. В одном примере, только тогда, когда блок яркости относится к 1-му блоку в VPDU, соответствующие отсчеты в буфере IBC могут быть помечены как недоступные.

b. В одном примере может быть запрещено сбрасывать или отмечать отсчеты в буфере как недоступные при декодировании единицы кодирования цветности.

16. Предлагается, что в начале декодирования каждого VPDU, соответствующая виртуальная буферная область IBC может быть сброшена на основе текущей позиции VPDU.

а. В одном примере виртуальная буферная область IBC, соответствующая (xVPDU+ctbSizeY, yVPDU), будет сброшена, где (xVPDU, yVPDU) обозначает текущую позицию VPDU относительно левого верхнего участка изображения.

17. То, помечать ли отсчеты в виртуальном буфере IBC как недоступные и/или как это делать, может зависеть от позиции самого последнего декодированного VPDU и размера VPDU.

а. В одном примере то, помечать ли отсчеты в виртуальном буфере IBC как недоступные и/или как это сделать, может зависеть от позиции блока/слайса/тайла/изображения самого последнего декодированного VPDU.

b. В одном примере то, помечать ли отсчеты в виртуальном буфере IBC как недоступные и/или как это делать, может зависеть от позиции самого последнего декодированного VPDU в строке CTU блока/слайса/тайла/изображения.

c. В одном примере то, какие отсчеты в виртуальном буфере IBC должны быть помечены как недоступные, может не зависеть от позиции текущего блока.

Связанный с этим строчный буфер IBC

18. Предсказание блочного вектора в строке CTU может быть запрещено

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

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

а. В одном примере, когда два блока имеют разные строки CTU, и один блок кодируется в режиме IBC, а другой в режиме IBC или межкадровом режиме, устойчивость границ деблокирования всегда может быть установлена равной 1.

b. В одном примере, когда два блока имеют разные строки CTU, и один блок кодируется в режиме IBC, а другой в режиме IBC или межкадровом режиме, устойчивость границ деблокирования всегда может быть установлена равной 0.

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

а. В одном примере, когда два блока имеют разные строки CTU, и один блок кодируется в режиме IBC, а другой не кодируется в внутрикадровом режиме, устойчивость границ деблокирования всегда может быть установлена равной 1.

Связанное с этим подызображение

21. Предлагается при определенных условиях сделать возможным предсказание (например, предсказание движения/отсчета) между двумя подызображениеми.

а. В одном примере, если граница первого подызображения совпадает с границей изображения (или границей окна соответствия), может быть разрешено использовать информацию из второго подызображения.

1) Альтернативно или дополнительно, граница подызображения является левой или правой границей подызображения.

2) Альтернативно или дополнительно, граница изображения является левой или правой границей изображения.

3) В одном примере левая (или правая) граница второго подызображения может совпадать с левой (или правой) границей изображения.

b. Условие истинно только в том случае, если разрешен перенос изображения (например, sps_ref_wraparound_enabled_flag равен 1)

22. Перенос изображения исключает подызображения.

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

b. В одном примере подызображения нельзя использовать, если включен перенос изображения.

c. В качестве альтернативы, можно включить перенос изображения при использовании подызображения.

4) В одном примере перенос изображения может быть разрешен для подызображения, граница которого совпадает с границей изображения.

Связанная с этим таблица QP цветности

23. Наименьший индекс таблицы QP цветности может не зависеть от битовой глубины для компонента цветности.

а. В одном примере наименьший индекс таблицы QP цветности может зависеть от битовой глубины компонента яркости.

b. В одном примере наименьший индекс таблицы QP цветности может быть QpBdOffsetY, то есть 6*bit_depth_luma_minus8.

5. Примеры реализации раскрытой технологии

5.1. Вариант 1 осуществления

Когда размер CTU равен 256×256, поддерживается виртуальный буфер IBC 64×256 ibcBuf, то есть IbcBufW=64, ibcBufH=256. Размер VPDU составляет 64×64, и, помимо текущего VPDU, для хранения опорных отсчетов IBC используются 3 дополнительных встроенных в ИС памяти VPDU.

Буфер ibcBuf сбрасывается до -1 в начале декодирования строки CTU.

В начале декодирования нового VPDU с верхней левой позицией (x0, y0) относительно верхнего левого угла изображения применяется следующее

1) Для x=x0..x0+63, y=y0..y0+63, ibcBuf [x%IBCBufW][y%IBCBufH]=-1

2) После декодирования CU для (x, y) в этом CU относительно верхнего левого угла изображения установить ibcBuf [x%IBCBufW][y%IBCBufH] как восстановленное значение отсчета (x, y) перед внутриконтурной фильтрацией, например, SAO, деблокирование, ALF.

3) Для bv ссылка на (x, y) представляет собой ibcBuf [(x+bv [0])%IBCBufW][(y+bv [1])%IBCBufH]

Это является ограничением битового потока, при котором должны выполняться следующие два условия.

1) Для блока WxH с верхней левой позицией (x, y) относительно верхнего левого угла изображения (y%IBCBufH)+H <= ibcBufH

2) ibcBuf [(x+bv [0])%IBCBufW][(y+bv [1])%IBCBufH] не должен содержать недопустимое значение пикселя, например -1, для x=0..W-1, y=0 .., H-1

5.2 Вариант 2 осуществления

Когда размер CTU равен 256×256, поддерживается виртуальный буфер IBC 128×256 ibcBuf, то есть IbcBufW=128, ibcBufH=256. Размер VPDU составляет 64×64, и, помимо текущего VPDU, для хранения опорных отсчетов IBC используются 3 дополнительных встроенных в ИС памяти VPDU.

Буфер ibcBuf сбрасывается до -1 в начале декодирования строки CTU. xPrevVPDU=0 и yPrevVPDU=0.

В начале декодирования нового VPDU с верхней левой позицией (x0, y0) относительно верхнего левого угла изображения применяется следующее

1) Если (yPrevVPDU+64)%IBCBufH не равно 0,

для x=x0..x0+63, y=y0..y0+63, ibcBuf [(x+xPrevVPDU- 64)%IBCBufW][(y+yPrevVPDU)%IBCBufH]=-1

2) В противном случае ((yPrevVPDU+64)%IBCBufH равно 0),

для x=x0..x0+63, y=y0..y0+63, ibcBuf [(x+xPrevVPDU)%IBCBufW][(y+yPrevVPDU)%IBCBufH]=-1

3) xPrevVPDU=x0 и yPrevVPDU=y0

Это является ограничением битового потока, при котором должны выполняться следующие два условия.

1) Для блока WxH с верхней левой позицией (x, y) относительно верхнего левого угла изображения (y%IBCBufH)+H <= ibcBufH

2) ibcBuf [(x+bv [0])%IBCBufW][(y+bv [1])%IBCBufH] не должен содержать недопустимое значение пикселя, например -1, для x=0..W-1, y=0 .., H-1

5.3. Вариант 3 осуществления

В этом варианте осуществления отражен пункт 2. Изменения, выделенный жирным курсивом, основаны на документе VVC JVET-O2001-vE проект 6.

log2_min_luma_coding_block_size_minus2 плюс 2 определяет минимальный размер блока кодирования яркости.

Переменные CtbLog2SizeY, CtbSizeY, MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC и Vsize получаются следующим образом:

CtbLog2SizeY = log2_ctu_size_minus5 + 5 … (7-15)

CtbSizeY = 1 << CtbLog2SizeY … (7-16)

MinCbLog2SizeY = log2_min_luma_coding_block_size_minus2 + 2 … (7-17)

MinCbSizeY = 1 << MinCbLog2SizeY … (7-18)

IbcBufWidthC = IbcBufWidthY / SubWidthC … (7-20)

VSize = Min( 64, CtbSizeY ) … (7-21)

5.4. Вариант 4 осуществления

Этот вариант отражает пункт 3.

Обозначить (xCb, yCb) как верхняя левая позиция текущего блока относительно верхнего левого угла изображения. Ширина и высота блока равны W и H соответственно. Блочный вектор для блока представляет собой (xBv, yBv).

Ограничение строки VPDU относительно изображения:

Это ограничение битового потока, которое (xCb+xBv)/vSize должно быть равным (xCb+xBv+W-1/vSize).

Ограничение столбца VPDU относительно изображения:

Это ограничение битового потока, которое (yCb+yBv)/vSize должно быть равным (yCb+yBv+H-1/vSize).

Ограничение строки VPDU относительно буфера IBC:

Это ограничение битового потока, которое ((xCb+xBv)%IBCBufWidthY)/vSize должно быть равным (((xCb+xBv+W-1)%IBCBufWidthY)/vSize).

Ограничение столбца VPDU относительно буфера IBC:

Это ограничение битового потока, которое ((yCb+yBv)%IBCBufHeightY)/vSize должно быть равным (((yCb+yBv+H-1)%IBCBufHeightY)/vSize).

5.5. Вариант 5 осуществления

Этот вариант осуществления отражает то, что маркировка отсчетов в виртуальном буфере IBC как недоступных не должна зависеть от блоков цветности.

Изменения, выделенные жирным шрифтом и курсивом, основаны на JVET-O2001-vE. Удаленный текст помечен двойными скобками (например, [[a]] означает удаление символа «a»).

…

Когда ResetIbcBuf равен 1, применяется следующее:

- Для x x = 0..IbcBufWidthY - 1 и y = 0..CtbSizeY - 1 присваиваются следующие значения:

IbcVirBuf [0][x][y]=-1 (7-153)

- Переменная ResetIbcBuf устанавливается равной 0.

Когда x0% VSize равно 0, и y0% VSize равно 0 для x=x0..x0+VSize - 1 и y=y0..y0+VSize - 1 присваиваются следующие значения:

IbcVirBuf [0][x%IBCBufWidthY][y% CtbSizeY]=-1 (7-154)

5.6. Вариант 6 осуществления

…

Когда ResetIbcBuf равно 1, применяется следующее:

- Для x=0..IbcBufWidthY - 1 и y=0..CtbSizeY - 1 присваиваются следующие значения:

IbcVirBuf [0][x][y]=-1 (7-153)

- Переменная ResetIbcBuf устанавливается равной 0.

5.7. Вариант 7 осуществления

В этом варианте осуществления представлен пример разрешения предсказания подызображения. Изменения по сравнению с JVET-O2001-vE выделены жирным шрифтом и курсивом.

Входными значениями в этом процессе являются:

- местоположение яркости в единицах полного отсчета (xInt_L, yInt_L),

- массив опорных отсчетов яркости refPicLX_L,

Результатом этого процесса является предсказанное значение отсчета яркости predSampleLXL.

Переменный сдвиг устанавливается равным Max (2, 14 - BitDepth_Y).

Переменная picW устанавливается равной pic_width_in_luma_samples, и переменная picH устанавливается равной pic_height_in_luma_samples.

Местоположения яркости в единицах полного отсчета (xInt, yInt) получаются следующим образом:

- Если subpic_treated_as_pic_flag[SubPicIdx] равен 1, применяется следующее:

yInt=Clip3 (SubPicTopBoundaryPos, SubPicBotBoundaryPos, yInt) (8 782)

- Иначе:

xInt = Clip3( 0, picW - 1, sps_ref_wraparound_enabled_flag ? … (8-782)

ClipH( ( sps_ref_wraparound_offset_minus1 + 1 ) * MinCbSizeY, picW, xInt_L ) : xInt_L )

yInt = Clip3( 0, picH - 1, yInt_L ) … (8-783)

Предсказанное значение отсчета яркости predSampleLXL выводится следующим образом:

predSampleLX_L = refPicLX_L[ xInt ][ yInt ] << shift3 … (8-784)

5.8. Вариант 8 осуществления

В этом варианте осуществления показан примерный проект таблицы QP цветности. Изменения, выделенные жирным шрифтом и курсивом, основаны на JVET-O2001-vE. Удаленный текст помечен двойными скобками (например, [[a]] означает удаление символа «a»).

…

1-я таблица сопоставления QP цветности ChromaQpTable[ i ] для i=0..same_qp_table_for_chroma? 0: 2 получается следующим образом:

qpInVal[ i ][ 0 ] = + delta_qp_in_val_minus1[ i ][ 0 ] qpOutVal[ i ][ 0 ] = -QpBdOffset_C + delta_qp_out_val[ i ][ 0 ] for( j = 1; j <= num_points_in_qp_table_minus1[ i ]; j++ ) { qpInVal[ i ][ j ] = qpInVal[ i ][ j - 1 ] + delta_qp_in_val_minus1[ i ][ j ] + 1 qpOutVal[ i ][ j ] = qpOutVal[ i ][j - 1] + delta_qp_out_val[ i ][ j ]}
ChromaQpTable[ i ][ qpInVal[ i ][ 0 ] ] = qpOutVal[ i ][ 0 ] for( k = qpInVal[ i ][ 0 ] - 1; k >= ; k - - )

ChromaQpTable[ i ][ k ] = Clip3( -QpBdOffset_C, 63, ChromaQpTable[ i ][ k + 1 ] - 1 ) (7-31)
for( j = 0; j < num_points_in_qp_table_minus1[ i ]; j++ ) {

sh = ( delta_qp_in_val_minus1[ i ][j + 1] + 2 ) >> 1

for( k = qpInVal[ i ][ j ] + 1, m = 1; k <= qpInval[ i ][ j + 1 ]; k++, m++ )

ChromaQpTable[ i ][ k ] = ChromaQpTable[ i ][ qpInVal[ i ][ j ] ] +

( delta_qp_out_val[ i ][j + 1] * m + sh ) / ( delta_qp_in_val_minus1[ i ][j + 1] + 1 ) } for( k = qpInVal[ i ][ num_points_in_qp_table_minus1[ i ] ] + 1; k <= 63; k++ )

ChromaQpTable[ i ][ k ] = Clip3( -QpBdOffset_C, 63, ChromaQpTable[ i ][ k - 1 ] + 1 )

Когда same_qp_table_for_chroma равно 1, ChromaQpTable[1][k] и ChromaQpTable[2][k] устанавливаются равными ChromaQpTable[0][k] для k = .63.

Требованием для соответствия битового потока является то, что значения qpInVal[ i ][ j ] и qpOutVal[ i ][ j ] должны находиться в диапазоне от -QpBdOffsetC до 63, включительно для i=0..same_qp_table_for_chroma? 0: 2 и j = 0..num_points_in_qp_table_minus1[ i ].

…

5.9. Вариант 9 осуществления

В этом варианте осуществления показана примерная конструкция увеличенного виртуального буфера IBC. Изменения, выделенные курсивом и жирным шрифтом, основаны на JVET-O2001-vE. Удаленный текст помечен двойными скобками (например, [[a]] означает удаление символа «a»).

7.4.3.3. Семантика RBSP набора параметров последовательности

…

Переменные CtbLog2SizeY, CtbSizeY, MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC и Vsize получаются следующим образом:

CtbLog2SizeY = log2_ctu_size_minus5 + 5 … (7-15)

CtbSizeY = 1 << CtbLog2SizeY … (7-16)

MinCbLog2SizeY = log2_min_luma_coding_block_size_minus2 + 2 … (7-17)

MinCbSizeY = 1 << MinCbLog2SizeY … (7-18)

IbcBufWidthY = 128 * 128 / CtbSizeY + … (7-19)

IbcBufWidthC = IbcBufWidthY / SubWidthC … (7-20)

VSize = Min( 64, CtbSizeY ) …

…

Когда x0% VSize равно 0, и y0% VSize равно 0, для x=x0..x0+VSize - 1 и y=y0..y0+VSize - 1 присваиваются следующие значения:

IbcVirBuf[ 0 ][ ( x + ) % IbcBufWidthY ][ y % CtbSizeY ] = -1 … (7-154)

5.10. Вариант 10 осуществления

В этом варианте осуществления показана примерная конструкция увеличенного виртуального буфера IBC. Изменения, выделенные курсивом и жирным шрифтом, основаны на JVET-O2001-vE. Удаленный текст помечен двойными скобками (например, [[a]] означает удаление символа «a»).

7.4.3.3. Семантика RBSP набора параметров последовательности

…

Переменные CtbLog2SizeY, CtbSizeY, MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC и Vsize получаются следующим образом:

CtbLog2SizeY = log2_ctu_size_minus5 + 5 … (7-15)

CtbSizeY = 1 << CtbLog2SizeY … (7-16)

MinCbLog2SizeY = log2_min_luma_coding_block_size_minus2 + 2 … (7-17)

MinCbSizeY = 1 << MinCbLog2SizeY … (7-18)

W

IbcBufWidthY = W[[128]] * 128 / CtbSizeY … (7-19)

IbcBufWidthC = IbcBufWidthY / SubWidthC … (7-20)

VSize = Min( 64, CtbSizeY )…

…

Когда x0% VSize равно 0, и y0% VSize равно 0, для x=x0..x0+VSize - 1 и y=y0..y0+VSize - 1 присваиваются следующие значения:

IbcVirBuf[ 0 ][ ( x + ) % IbcBufWidthY ][ y % CtbSizeY ] = -1 … (7-154)

5.11. Вариант 11 осуществления

Изменения, выделенные жирным шрифтом и курсивом, основаны на JVET-O2001-vE. Удаленный текст помечен двойными скобками (например, [[a]] означает удаление символа «a»).

…

Переменные CtbLog2SizeY, CtbSizeY, MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC и Vsize получаются следующим образом:

CtbLog2SizeY = log2_ctu_size_minus5 + 5 … (7-15)

CtbSizeY = 1 << CtbLog2SizeY … (7-16)

MinCbLog2SizeY = log2_min_luma_coding_block_size_minus2 + 2 … (7-17)

MinCbSizeY = 1 << MinCbLog2SizeY … (7-18)

IbcBufWidthY = 128 * 128 / CtbSizeY + … (7-19)

IbcBufWidthC = IbcBufWidthY / SubWidthC … (7-20)

VSize = Min( 64,

CtbSizeY )

…

…

Когда x0% VSize равно 0, и y0 % VSize равен 0, для x=x0..x0+VSize - 1 и y=y0..y0+VSize - 1 присваиваются следующие значения:

IbcVirBuf[ 0 ][ (x + ) % IbcBufWidthY ][ y % CtbSizeY ] = -1

(7-154)

На фиг. 4 показаны примеры опорных блоков, пересекающих столбец VPDU и строку VPDU. Как показано на фиг. 4, для текущего CU (синий блок 602), блок, закрашенный красным (604), является пересекающим опорным блоком столбца VPDU, и блок, закрашенный желтым цветом (606), является пересекающим опорным блоком строки VPDU. Каждый большой блок указывает VPDU 64×64, и зеленая зона (608) указывает восстановленные пиксели, которые можно использовать для ссылки на IBC.

На фиг. 5 показана блок-схема устройства 500 обработки видео. Устройство 500 может использоваться для реализации одного или нескольких способов, описанных в данном документе. Устройство 500 может быть воплощено в смартфоне, планшете, компьютере, приемнике Интернета вещей (IoT) и т.д. Устройство 500 может включать в себя один или несколько процессоров 502, одно или несколько запоминающих устройств 504 и аппаратные средства 506 для обработки видео. Процессор (процессоры) 502 может быть выполнен с возможностью реализации одного или нескольких способов (включая, но без ограничения, способ 400), описанных в данном документе. Память (запоминающие устройства) 504 может использоваться для хранения данных и кода, используемых для реализации способов и технологий, описанных в данном документе. Аппаратные средства 506 для обработки видео могут использоваться для реализации, в аппаратных схемах, некоторых технологий, описанных в данном документе.

На фиг. 6 показана блок-схема, иллюстрирующая примерную систему 1900 обработки видео, в которой могут быть реализованы различные технологии, раскрытые в данном документе. Различные реализации могут включать в себя некоторые или все компоненты системы 1900. Система 1900 может включать в себя вход 1902 для приема видеосодержания. Видеосодержание может приниматься в необработанном или несжатом формате, например, с 8- или 10-битовыми многокомпонентными пиксельными значениями, или может быть в сжатом или кодированном формате. Вход 1902 может представлять собой сетевой интерфейс, интерфейс периферийной шины или интерфейс запоминающего устройства. Примеры сетевого интерфейса включают в себя проводные интерфейсы, такие как Ethernet, пассивная оптическая сеть (PON) и т.д., и беспроводные интерфейсы, такие как Wi-Fi или интерфейсы сотовой связи.

Система 1900 может включать в себя компонент 1904 кодирования, который может реализовывать различные способы кодирования или шифрования, описанные в настоящем документе. Компонент 1904 кодирования может уменьшать среднюю скорость битовую скорость видео от входа 1902 до выхода компонента 1904 кодирования для создания кодированного представления видео. Таким образом, технологии кодирования иногда называют технологиями сжатия видео или транскодирования видео. Выходной сигнал компонента 1904 кодирования может быть либо сохранен, либо передан через коммуникационное соединение, как представлено компонентом 1906. Сохраненное или переданное (или кодированное) представление битового потока видео, принятого на входе 1902, может использоваться компонентом 1908 для выработки пиксельных значений или отображаемого видео, которое отправляется в интерфейс 1910 дисплея. Процесс выработки видео для просмотра пользователем из представления битового потока иногда называется распаковкой видео. Более того, хотя некоторые операции обработки видео называются операциями или средствами «кодирования», следует принимать во внимание, что средства или операции кодирования используются в кодере, и соответствующие средства или операции декодирования, которые выполняют обратные действия над результатами кодирования, будут выполняться с помощью декодера.

Примеры интерфейса периферийной шины или интерфейса дисплея могут включать в себя универсальную последовательную шину (USB) или мультимедийный интерфейс высокого разрешения (HDMI) или интерфейс Displayport и т.д. Примеры интерфейсов запоминающих устройств включают в себя SATA (последовательное соединение по передовой технологии), PCI, интерфейс IDE и т.п. Способы, описанные в настоящем документе, могут быть воплощены в различных электронных устройствах, таких как мобильные телефоны, ноутбуки, смартфоны или другие устройства, которые способны выполнять обработку цифровых данных и/или отображение видео.

В некоторых вариантах осуществления способы кодирования видео могут быть реализованы с использованием устройства, которое реализовано на аппаратной платформе, как описано со ссылкой на фиг. 5 или 6.

Примеры, описанные выше, могут быть включены в контекст способов, описанных ниже, например, способов с 710 по [], которые могут быть реализованы в видеодекодере или видеокодере.

На фиг. 7A показана блок-схема последовательности операций примерного способа 710 обработки видео. Способ 710 включает в себя, на этапе 712, принятие решения, на основе размера виртуального буфера, ассоциированного с текущим блоком, который кодируется на основе пикселей в опорном блоке, относительно действительности блочного вектора или одной или нескольких отсчетов, сопоставленных с виртуальным буфером, текущего изображения, содержащего текущий блок и опорный блок, и размера виртуального буфера, основанного на размере виртуального блока данных конвейера (VPDU), размере блока дерева кодирования (CTB) или размере единицы дерева кодирования (CTU). Способ 700 включает в себя, на этапе 714, выполнение, на основе принятого решения, преобразования между текущим блоком и представлением битового потока текущего блока.

На фиг. 7B показана блок-схема последовательности операций примерного способа 720 обработки видео. Способ 720 включает в себя, на этапе 722, назначение, для текущего блока, который кодируется на основе пикселей в опорном блоке, одной или нескольких опорных отсчетов опорного блока как недоступных, причем каждая из одной или более опорных отсчетов сопоставляется с виртуальным буфером и имеет соответствующий отсчет по меньшей мере в текущем виртуальном блоке данных конвейера (VPDU), ассоциированном с опорным блоком, и текущее изображение содержит текущий блок и опорный блок. Способ 720 включает в себя, на этапе 724, выполнение, на основе назначения, преобразования между текущим блоком и представлением битового потока текущего блока.

На фиг. 7C показана блок-схема последовательности операций примерного способа 730 обработки видео. Способ 730 включает в себя, на этапе 732, определение, для текущего блока, который кодируется на основе пикселей в опорном блоке, размера виртуального буфера, ассоциированного с опорным блоком, на основе размера блока дерева кодирования (CTB) или размера единицы дерева кодирования (CTU) текущего блока, причем текущее изображение содержит текущий блок и опорный блок. Способ 730 включает в себя, на этапе 734, выполнение, на основе определения, преобразования между текущим блоком и представлением битового потока текущего блока.

На фиг. 8A показана блок-схема последовательности операций примерного способа 810 обработки видео. Способ 810 включает в себя, на этапе 812, определение, для преобразования между текущим видеоблоком видеоизображения видео и кодированным представлением видео, количества опорных отсчетов в опорной области видеоизображения, используемого для предсказания текущего видеоблока на основе правила, причем правило точно определяет то, что количество опорных отсчетов ограничивается определенным диапазоном. Способ 810 включает в себя, на этапе 814, выполнение, на основе определения, преобразования.

На фиг. 8B показана блок-схема последовательности операций примерного способа 820 обработки видео. Способ 820 включает в себя, на этапе 822, определение, для преобразования между текущим видеоблоком видеоизображения видео и кодированным представлением видео, доступности одной или нескольких опорных отсчетов опорного блока, используемого для предсказания текущего видеоблок на основе правила, причем правило предписывает использовать при определении детализацию на уровне виртуального блока данных конвейера (VPDU). Способ 820 включает в себя, на этапе 824, выполнение, на основе определения, преобразования между текущим блоком и кодированным представлением текущего блока.

На фиг. 8C показана блок-схема последовательности операций примерного способа 830 обработки видео. Способ 830 включает в себя, на этапе 832, выполнение преобразования между текущим видеоблоком видеоизображения видео и кодированным представлением видео. В некоторых реализациях преобразование выполняется в соответствии с правилом, в котором текущий видеоблок представлен в кодированном представлении с использованием остатка предсказания из опорных отсчетов из опорной области в видеоизображениях, и где правило точно определяет эти значения отсчетов в опорной области, которые сбрасываются в начале обработки каждого виртуального блока данных конвейера (VPDU) во время преобразования на основе позиции текущего VPDU текущего видеоблока. В некоторых реализациях преобразование содержит использование подсчета количества доступных текущих виртуальных блоков данных конвейера (VPDU), которые сопоставляются с опорной областью видеоизображения, из которой одна или несколько опорных отсчетов используются для предсказания текущего видеоблока.

На фиг. 8D показана блок-схема последовательности операций примерного способа 840 обработки видео. Способ 840 включает в себя, на этапе 842, определение, для текущего видеоблока видеоизображения видео и кодированного представления видео, того, что отсчеты из текущего виртуального блока данных конвейера (VPDU) и трех дополнительных недавно обработанных VPDU в видеоизображение доступны в качестве опорных отсчетов для выработки предсказания текущего видеоблока в связи с тем, что текущий видеоблок имеет размер больше, чем размер отсчетов яркости 64×64. Способ 840 включает в себя, на этапе 844, выполнение, на основе определения, преобразования.

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

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

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

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

1. Способ обработки видео, содержащий: принятие решения, на основе размера виртуального буфера, ассоциированного с текущим блоком, который кодируется на основе пикселей в опорном блоке, относительно действительности блочного вектора или одной или нескольких отсчетов, сопоставленных с виртуальным буфером, где текущее изображение содержит текущий блок и опорный блок, и где размер виртуального буфера основан на размере виртуального блока данных конвейера (VPDU), размере блока дерева кодирования (CTB) или размере дерева кодирования блок (CTU); и выполнение, на основе принятого решения, преобразования между текущим блоком и представлением битового потока текущего блока.

2. Способ по п. 1, в котором произведение высоты и ширины виртуального буфера является фиксированным, и высота или ширина зависят от размера VPDU, размера CTB или размера CTU.

3. Способ по п. 1, в котором ширина виртуального буфера равна ширине CTB или ширине CTU.

4. Способ по п. 1, в котором ширина или высота виртуального буфера в N раз больше ширины или высоты VPDU, соответственно, и где N ≥ 1 и является целым числом.

5. Способ по п. 1, в котором максимальное количество одной или нескольких отсчетов меньше размера виртуального буфера.

6. Способ по п. 1, в котором максимальное количество одной или нескольких отсчетов фиксируется после определения того, что размер CTB или размер CTU больше 64×64.

7. Способ по п. 1, в котором количество одной или нескольких отсчетов меньше или равно произведению N на количество отсчетов в VPDU, и где N ≥ 1 и является целым числом.

8. Способ по п. 7, в котором N=3 после определения того, что размер CTB или размер CTU больше 64×64.

9. Способ обработки видео, содержащий: обозначение, для текущего блока, который кодируется на основе пикселей в опорном блоке, одной или нескольких опорных отсчетов опорного блока как недоступных, причем каждая из одной или более опорных отсчетов сопоставляются с виртуальным буфером и имеет соответствующий отсчет по меньшей мере в текущем виртуальном блоке данных конвейера (VPDU), ассоциированном с опорным блоком, при этом текущее изображение содержит текущий блок и опорный блок; и выполнение, на основе назначения, преобразования между текущим блоком и представлением битового потока текущего блока.

10. Способ по п. 9, дополнительно содержащий: обозначение соответствующего отсчета в текущем VPDU как недоступной.

11. Способ по п. 10, в котором обозначение соответствующего отсчета основано на позиции текущего VPDU.

12. Способ по п. 10, в котором обозначение соответствующего отсчета основано на позиции предыдущего VPDU или недавно декодированного VPDU.

13. Способ по п. 9, в котором каждая из одной или нескольких опорных отсчетов имеет соответствующий отсчет в каждом из трех последних декодированных блоков VPDU.

14. Способ обработки видео, содержащий: определение, для текущего блока, который кодируется на основе пикселей в опорном блоке, размера виртуального буфера, ассоциированного с опорным блоком, на основе размера блока дерева кодирования (CTB) или размера единицы дерева кодирования (CTU) текущего блока, причем текущее изображение содержит текущий блок и опорный блок; и выполнение, на основе определения, преобразования между текущим блоком и представлением битового потока текущего блока.

15. Способ по п. 14, в котором размер виртуального буфера составляет 256×128 после определения того, что размер CTB или CTU равен 128×128.

16. Способ по п. 14, в котором размер виртуального буфера составляет 64×256 после определения того, что размер CTB или CTU равен 256×256.

17. Способ по п. 14, в котором размер виртуального буфера составляет 128×256 после определения того, что размер CTB или CTU равен 256×256.

18. Способ по любому из пп. 1-17, в котором кодирование текущего блока на основе пикселей в опорном блоке в текущем изображении, содержащем текущий блок, является операцией внутриблочного копирования (IBC), и в котором виртуальный буфер представляет собой виртуальный буфер IBC.

19. Способ обработки видео, содержащий: выделение, для преобразования между представлением битового потока текущего блока видео и текущим блоком, размера виртуального буфера внутреннего блочного кодирования (IBC), который больше минимального размера зоны поиска блочного вектора для преобразования; и выполнение преобразования на основе выделения.

20. Способ по п. 19, в котором размер буфера IBC больше, чем общий размер памяти виртуального блока данных конвейера, используемой для преобразования.

21. Способ по любому из пп. 19-20, в котором ширина размера виртуального буфера IBC составляет (128 * 128/ctbSizeY+ctbSizeY).

22. Способ обработки видео, содержащий: определение, для преобразования между представлением битового потока текущего блока видео и текущим блоком, размера опорного блока для преобразования на основе кодирования с предсказанием блока на основе правила; и выполнение, на основе определения, преобразования; причем правило ограничивает опорный блок, чтобы он находился в пределах столбца виртуального блока данных конвейера (VPDU) или строки виртуального блока данных конвейера.

23. Способ по п. 22, в котором правило не позволяет опорному блоку находиться в разных строках VPDU.

24. Способ по п. 22, в котором правило не позволяет опорному блоку находиться в разных столбцах VPDU.

25. Способ по любому из пп. 22-24, в котором столбец VPDU или строка VPDU относятся к изображению, содержащему текущий блок.

26. Способ по любому из пп. 22-24, в котором столбец VPDU или строка VPDU относятся к виртуальному буферу внутриблочного копирования.

27. Способ по любому из пп. 1-26, в котором преобразование содержит кодирование видео для выработки представления битового потока из текущего блока.

28. Способ по любому из пп. 1-26, в котором преобразование содержит декодирование видео для выработки текущего блока из представления битового потока.

29. Устройство, действующее в видеосистеме, содержащее процессор и невременную память с хранящимися на ней инструкциями, причем инструкции после исполнения процессором предписывают процессору реализовать способ по любому из пп. 1-28.

30. Компьютерный программный продукт, хранящийся на невременном машиночитаемом носителе информации, причем компьютерный программный продукт включает в себя программный код для выполнения способа по любому из пп. 1-28.

31. Способ, устройство или система, описанные в данном документе.

Второй набор пунктов описывает определенные признаки и аспекты раскрытых технологий, описанных в предыдущем разделе, например, пп. 2-5, 8 и 16 примеров.

1. Способ обработки видео, содержащий: определение, для преобразования между текущим видеоблоком видеоизображения видео и кодированным представлением видео, количества опорных отсчетов в опорной области видеоизображения, используемой для предсказания текущего видеоблока, на основе правила, причем правило точно определяет то, что количество опорных отсчетов ограничивается определенным диапазоном; и выполнение, на основе определения, преобразования.

2. Способ по п. 1, в котором правило точно определяет то, что максимальное количество опорных отсчетов меньше размера опорной области.

3. Способ по п. 1, в котором правило точно определяет то, что максимальное количество опорных отсчетов является фиксированным в том случае, если размер блока дерева кодирования (CTB) или размер единицы дерева кодирования (CTU) больше 64×64.

4. Способ по п. 1, в котором правило точно определяет то, что количество опорных отсчетов меньше или равно произведению N на количество отсчетов в виртуальном блоке данных конвейера (VPDU), и где N ≥ 1 и является целым числом.

5. Способ по п. 4, в котором N=3 в случае, когда определение того, что размер блока дерева кодирования (CTB) или размер единицы дерева кодирования (CTU) больше, чем размер отсчетов яркости 64×64.

6. Способ обработки видео, содержащий: определение, для преобразования между текущим видеоблоком видеоизображения видео и кодированным представлением видео, доступности одной или нескольких опорных отсчетов опорного блока, используемых для предсказания текущего видеоблока на основе правила, причем правило точно определяет использовать при определении детализацию на уровне виртуального блока данных конвейера (VPDU); и выполнение, на основе определения, преобразования между текущим блоком и кодированным представлением текущего блока.

7. Способ по п. 6, в котором определение определяет то, что одна или несколько опорных отсчетов недоступны, и в котором способ дополнительно содержит определение одной или нескольких соответствующих отсчетов в текущем VPDU как недоступных.

8. Способ по п. 6, дополнительно содержащий: определение доступности одного или нескольких блоков VPDU как недоступных.

9. Способ по п. 7, в котором определение одной или нескольких соответствующих отсчетов основано на позиции текущего VPDU.

10. Способ по п. 7, в котором определение одной или нескольких соответствующих отсчетов основано на позиции предыдущего VPDU или недавно декодированного VPDU.

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

12. Способ по п. 11, в котором перед кодированием или декодированием видеоблока соответствующая зона в опорной области помечается как недоступная.

13. Способ по п. 11, в котором соответствующая зона в опорной области соответствует зоне яркости при x=(X%IBC_buf_width)..(X%IBC_buf_width)+W-1 и y=(Y%IBC_buf_height)..(Y %IBC_buf_height)+H-1, причем видеоблок имеет размер WxH, IBC_buf_width и IBC_buf_height указывают ширину и высоту виртуального буфера, соответственно, и верхняя левая позиция видеоблока представляет собой (X, Y).

14. Способ по п. 11, в котором соответствующая зона в опорной области соответствует зоне цветности при x=(X%IBC_buf_width)/SubWidthC..((X%IBC_buf_width)+W-1)/SubWidthC и y=(Y%IBC_buf_height)/SubHeightC..((Y%IBC_buf_height)+H-1)/SubHeightC, причем размер видеоблока равен WxH, IBC_buf_width и IBC_buf_height указывают ширину и высоту виртуального буфера, соответственно, и верхняя левая позиция видеоблока представляет собой (X, Y).

15. Способ по п. 6, в котором определение выполняется непосредственно перед кодированием или декодированием отсчетов KxL или пикселей KxL, которые включены в видеоблок, включающий в себя текущий видеоблок.

16. Способ по п. 15, в котором по меньшей мере один из K и L равен 1.

17. Способ по п. 15, в котором по меньшей мере один из K и L устанавливается равным размеру подблока, используемому в видеоблоке.

18. Способ обработки видео, содержащий: выполнение преобразования между текущим видеоблоком видеоизображения видео и кодированным представлением видео в соответствии с правилом, причем текущий видеоблок представлен в кодированном представлении с использованием остатка предсказания из опорных отсчетов из опорной области в видеоизображениях, и где правило точно определяет то, что значения отсчетов в опорной области сбрасываются в начале обработки каждого виртуального блока данных конвейера (VPDU) во время преобразования на основе позиции текущего VPDU текущего видеоблока.

19. Способ по п. 18, в котором опорная область находится в позиции (xVPDU+ctbSizeY, yVPDU), где (xVPDU, yVPDU) обозначает позицию текущего VPDU относительно левого верхнего участка изображения, включая текущий видеоблок. и ctbSizeY представляет собой ширину или высоту блока дерева кодирования яркости (CTB) или блока дерева кодирования яркости (CTU).

20. Способ обработки видео, содержащий: определение, для текущего видеоблока видеоизображения видео и кодированного представления видео, того, что отсчеты из текущего виртуального блока данных конвейера (VPDU) и трех дополнительных недавно обработанных VPDU в видеоизображения доступны в качестве опорных отсчетов для выработки предсказания текущего видеоблока в связи с тем, что текущий видеоблок имеет размер больше, чем размер отсчетов яркости 64×64; и выполнение, на основе определения, преобразования.

21. Способ по п. 20, в котором текущий видеоблок соответствует блоку дерева кодирования (CTB) или единице дерева кодирования (CTU).

22. Способ по п. 20, в котором индекс поддерживается для каждого VPDU, сопоставленного с опорной областью видеоизображения.

23. Способ обработки видео, содержащий: выполнение преобразования между текущим видеоблоком видеоизображения видео и кодированным представлением видео, и где преобразование содержит использование подсчета количества доступных текущих виртуальных блоков данных конвейера (VPDU), которые сопоставляютя с опорной областью видеоизображения, из которой одна или несколько опорных отсчетов используются для предсказания текущего видеоблока.

24. Способ по п. 23, в котором счетчик сбрасывается в ноль в начале декодирования каждой строки CTU и увеличивается на единицу при декодировании VPDU, сопоставленного с опорной областью.

25. Способ по п. 23, в котором значение счетчика больше определенного значения и в котором отсчеты в VPDU, сопоставленные с опорной областью, помечаются как недоступные, и значение счетчика уменьшается на единицу.

26. Способ по любому из пп. 1-25, в котором преобразование включает в себя кодирование текущего видеоблока в кодированное представление.

27. Способ по любому из пп. 1-25, в котором преобразование включает в себя декодирование кодированного представления из текущего видеоблока.

28. Устройство обработки видео, содержащее процессор, выполненный с возможностью реализации способа по любому одному или нескольким из пп. 1-27.

29. Машиночитаемый носитель информации, хранящий программный код, который при его исполнении предписывает процессору реализовывать способ по любому одному или нескольким из пп. 1-27.

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

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

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

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

Процессоры, подходящие для исполнения компьютерной программы, включают в себя, например, микропроцессоры как общего, так и специального назначения, и любые один или несколько процессоров цифрового компьютера любого типа. Как правило, процессор будет получать инструкции и данные из постоянного запоминающего устройства или оперативного запоминающего устройства или одновременно из того и другого. Существенными элементами компьютера являются процессор для исполнения инструкций и одно или несколько запоминающих устройств для хранения инструкций и данных. Как правило, компьютер также может включать в себя или может быть функционально подключен для приема данных или передачи данных из/в одно или оба устройства для хранения данных, например, магнитные, магнитооптические диски или оптические диски. Однако компьютер необязательно должен иметь такие устройства. Машиночитаемые носители информации, подходящие для хранения инструкций и данных компьютерных программ, включают в себя все виды энергонезависимой памяти, носителей информации и запоминающих устройств, включая, например, полупроводниковые запоминающие устройства, например, EPROM, EEPROM и устройства флэш-памяти. Процессор и память могут быть дополнены специальной логической схемой или включены в нее.

Предполагается, что описание вместе с чертежами должно рассматриваться только в качестве примера, где примерный означает пример. В данном контексте использование «или» включает в себя «и/или», если в контексте явным образом не указано иное.

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

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

Описано только несколько реализаций и примеров, и другие реализации, улучшения и вариации могут быть сделаны на основе того, что описано и проиллюстрировано в данном патентном документе.

Изобретение относится к средствам для кодирования видео. Технический результат заключается в повышении эффективности кодирования видео. Определяют, для преобразования между текущим видеоблоком видеоизображения видео и битовым потоком видео, количество опорных отсчетов в виртуальном буфере, содержащем опорные отсчеты, полученные из видеоизображения, на основе правила. Правило устанавливает, что максимальное количество доступных опорных отсчетов в виртуальном буфере меньше размера виртуального буфера. Выполняют преобразование на основе указанного определения. Текущий видеоблок кодирован в режиме предсказания, в котором отсчеты предсказания получаются из блоков доступных опорных отсчетов в виртуальном буфере на основе блочного вектора. Опорные отсчеты, помеченные как недоступные, имеют местоположение (m, n) в виртуальном буфере, причем m = (x + ( IbcBufWidthY >> 1)) % IbcBufWidthY, а n = y % CtbSizeY, где (x, y) обозначает местоположение отсчета на видеоизображении, IbcBufWidthY обозначает ширину виртуального буфера, CtbSizeY обозначает размер CTB яркости, содержащего текущий видеоблок. 4 н. и 9 з.п. ф-лы, 13 ил.

1. Способ обработки видеоданных, содержащий этапы, на которых:

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

выполняют преобразование на основе указанного определения,

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

при этом правило устанавливает, что опорные отсчеты, помеченные как недоступные, имеют местоположение (m, n) в виртуальном буфере,

причем m = (x + ( IbcBufWidthY >> 1)) % IbcBufWidthY, а n = y % CtbSizeY,

где (x, y) обозначает местоположение отсчета на видеоизображении,

IbcBufWidthY обозначает ширину виртуального буфера,

CtbSizeY обозначает размер CTB яркости, содержащего текущий видеоблок,

>> обозначает оператор сдвига вправо, и % обозначает оператор модуля.

2. Способ по п.1, в котором режимом предсказания является режим внутриблочного копирования (IBC), а виртуальным буфером является виртуальный буфер IBC.

3. Способ по п.1 или 2, в котором (x,y) определяются на основе min(CtbSizeY, 64).

4. Способ по любому из пп.1-3, в котором IbcVirBuf[ 0 ][ (x + ( IbcBufWidthY >> 1)) % IbcBufWidthY ][ y % CtbSizeY ] = -1,

где IbcVirBuf [ 0 ][ m ][ n ] обозначает опорный отсчет, помеченный недоступным в виртуальном буфере.

5. Способ по любому из пп.1-4, в котором в начале декодирования каждой строки CTU значения опорных отсчетов в виртуальном буфере сбрасываются в -1.

6. Способ по любому из пп.1-5, в котором произведение высоты на ширину виртуального буфера является фиксированным, и ширина виртуального буфера определяется на основе CtbSizeY.

7. Способ по любому из пп.1-6, в котором высота виртуального буфера равна высоте CTB яркости, а ширина виртуального буфера устанавливается на значение, полученное путем деления площади виртуального буфера на высоту CTB яркости.

8. Способ по любому из пп.1-7, в котором площадь виртуального буфера равна 256*128, высота виртуального буфера равна ctbSizeY, и ширина виртуального буфера равна 256*128/ctbSizeY.

9. Способ по любому из пп.1-8, в котором на этапе преобразования кодируют текущий видеоблок в битовый поток.

10. Способ по любому из пп.1-8, в котором на этапе преобразования декодируют текущий видеоблок из битового потока.

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

определения, для преобразования между текущим видеоблоком видеоизображения видео и битовым потоком видео, количества опорных отсчетов в виртуальном буфере, содержащем опорные отсчеты, полученные из видеоизображения, на основе правила, причем правило устанавливает, что максимальное количество доступных опорных отсчетов в виртуальном буфере меньше размера виртуального буфера; и

выполнения преобразования на основе указанного определения,

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

при этом правило устанавливает, что опорные отсчеты, помеченные как недоступные, имеют местоположение (m, n) в виртуальном буфере,

причем m = (x + ( IbcBufWidthY >> 1)) % IbcBufWidthY, а n = y % CtbSizeY,

где (x, y) обозначает местоположение отсчета на видеоизображении,

IbcBufWidthY обозначает ширину виртуального буфера,

CtbSizeY обозначает размер CTB яркости, содержащего текущий видеоблок,

>> обозначает оператор сдвига вправо, и % обозначает оператор модуля.

12. Энергонезависимый машиночитаемый носитель информации, на котором хранятся инструкции, которые вызывают выполнение процессором:

определения, для преобразования между текущим видеоблоком видеоизображения видео и битовым потоком видео, количества опорных отсчетов в виртуальном буфере, содержащем опорные отсчеты, полученные из видеоизображения, на основе правила, причем правило устанавливает, что максимальное количество доступных опорных отсчетов в виртуальном буфере меньше размера виртуального буфера; и

выполнения преобразования на основе указанного определения,

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

при этом правило устанавливает, что опорные отсчеты, помеченные как недоступные, имеют местоположение (m, n) в виртуальном буфере,

причем m = (x + ( IbcBufWidthY >> 1)) % IbcBufWidthY, а n = y % CtbSizeY,

где (x, y) обозначает местоположение отсчета на видеоизображении,

IbcBufWidthY обозначает ширину виртуального буфера,

CtbSizeY обозначает размер CTB яркости, содержащего текущий видеоблок,

>> обозначает оператор сдвига вправо, и % обозначает оператор модуля.

13. Способ сохранения битового потока видео, содержащий этапы, на которых:

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

вырабатывают битовый поток на основе указанного определения, и

сохраняют битовый поток на энергонезависимом машиночитаемом носителе для записи информации,

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

при этом правило устанавливает, что опорные отсчеты, помеченные как недоступные, имеют местоположение (m, n) в виртуальном буфере,

причем m = (x + ( IbcBufWidthY >> 1)) % IbcBufWidthY, а n = y % CtbSizeY,

где (x, y) обозначает местоположение отсчета на видеоизображении,

IbcBufWidthY обозначает ширину виртуального буфера,

CtbSizeY обозначает размер CTB яркости, содержащего текущий видеоблок,

>> обозначает оператор сдвига вправо, и % обозначает оператор модуля.