СПОСОБЫ И УСТРОЙСТВА КОДИРОВАНИЯ ВИДЕО С ИСПОЛЬЗОВАНИЕМ ПРОГНОЗИРОВАНИЯ ВЕКТОРА ДВИЖЕНИЯ НА ОСНОВЕ ИСТОРИИ Российский патент 2021 года по МПК H04N19/52 H04N19/119 

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

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

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

Цифровое видео поддерживается различными электронными устройствами, такими как цифровые телевизоры, портативные или настольные компьютеры, планшетные компьютеры, цифровые камеры, цифровые записывающие устройства, цифровые медиаплееры, пульты для видеоигр, смартфоны, устройства для организации видео телеконференций, устройства для потоковой передачи видео и т.д. Электронные устройства передают, принимают, кодируют, декодируют и/или хранят цифровые видеоданные, реализуя стандарты сжатия/ восстановления видео, определенные в стандартах MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, часть 10, усовершенствованного кодирования видео (AVC), высокоэффективного кодирования видео (HEVC) и универсального кодирования видео (VVC). Сжатие видео обычно включает в себя выполнение пространственного (внутрикадрового) прогнозирования (внутреннего прогнозирования) и/или временного (межкадрового) прогнозирования (внешнего прогнозирования) для уменьшения или удаления избыточности, присущей видеоданным. Для кодирования видео на основе блоков видеокадр разбивается на один или более слайсов, причем каждый слайс имеет многочисленные видеоблоки, которые могут также упоминаться как единицы дерева кодирования (CTU). Каждая CTU может содержать одну единицу кодирования (CU) или рекурсивно разбиваться на более мелкие CU до тех пор, пока не будет достигнут заданный минимальный размер CU. Каждая CU (также называемая листовой CU) содержит один или более единиц преобразования (TU), и каждая CU также содержит один или более блоков прогнозирования (PU). Каждая CU может кодироваться в режимах интра, интер или IBC. Видеоблоки в интракодированном (I) слайсе видеокадра кодируются с использованием пространственного прогнозирования по отношению к эталонным выборкам в соседних блоках в одном и том же видеокадре. Видеоблоки в интеркодированном слайсе (Р или В) видеокадра могут использовать пространственное прогнозирование по отношению к эталонным выборкам в соседних блоках в пределах одного видеокадра или временного прогнозирования по отношению к эталонным выборкам в других предыдущих и/или будущих опорных видеокадрах.

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

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

При изменении качества цифрового видео от высокого до 4Kx2K или даже 8Kx4K объем видеоданных, подлежащих кодированию/декодированию, растет экспоненциально. Это является постоянной проблемой с точки зрения того, как можно более эффективно кодировать/декодировать видеоданные, сохраняя при этом качество изображения декодированных видеоданных.

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

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

Согласно первому аспекту настоящей заявки способ декодирования видеоданных выполняется в вычислительном устройстве, имеющем один или более процессоров и память, хранящую множество программ, которые должны исполняться одним или более процессорами. После получения битового потока видео вычислительное устройство начинает извлекать данные, ассоциированные с множеством кодированных изображений из битового потока видео, причем каждое изображение включает в себя множество строк единиц дерева кодирования (CTU), и каждая CTU включает в себя одну или более единиц кодирования (CU). Перед началом декодирования первой CU текущей строки CTU декодируемого текущего изображения, вычислительное устройство сбрасывает таблицу предикторов векторов движения на основе истории (HMVP). Затем при декодировании текущей строки CTU вычислительное устройство поддерживает множество предикторов векторов движения в таблице HMVP, причем каждый предиктор вектора движения использовался для декодирования по меньшей мере одной CU. Для текущей CU текущей строки CTU, подлежащей декодированию, вычислительное устройство извлекает режим прогнозирования из битового потока видео и создает список векторов-кандидатов движения в соответствии с режимом прогнозирования и на основе, по меньшей мере частично, предикторов векторов движения в таблице HMVP. После выбора предиктора вектора движения из списка векторов-кандидатов движения вычислительное устройство определяет вектор движения на основе, по меньшей мере частично, режима прогнозирования и выбранного предиктора вектора движения, декодирует текущую CU, используя определенный вектор движения, и обновляет таблицу HMVP на основе определенного вектора движения.

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

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

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

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

На фиг.1 показана блок-схема, иллюстрирующая примерную систему кодирования и декодирования видео в соответствии с некоторыми реализациями настоящего раскрытия.

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

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

На фиг.4A-4D показаны блок-схемы, иллюстрирующие, как кадр рекурсивно разбивается со структурой квадродерева на множество видеоблоков разных размеров в соответствии с некоторыми реализациями настоящего раскрытия.

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

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

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

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

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

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

В некоторых реализациях устройство-получатель 14 может принимать кодированные видеоданные, которые должны быть декодированы, через линию 16 связи. Линия 16 связи может содержать среду связи или устройство любого типа с возможностью перемещения кодированных видеоданных из устройства-источника 12 в устройство-получатель 14. В одном примере линия 16 связи может содержать среду связи, позволяющую устройству-источнику 12 передавать кодированные видеоданные напрямую в устройство-получатель 14 в реальном времени. Кодированные видеоданные могут быть промодулированы в соответствии со стандартом связи, таким как протокол беспроводной связи, и переданы в устройство-получатель 14. Среда связи может содержать любую беспроводную или проводную среду связи, такую как радиочастотный (RF) спектр или одна, или более физических линий передачи. Среда связи может формировать часть пакетной сети, такой как локальная вычислительная сеть, территориальная вычислительная сеть или глобальная вычислительная сеть, такая как Интернет. Среда связи может включать в себя маршрутизаторы, коммутаторы, базовые станции или любое другое оборудование, которое может быть полезным для обеспечения связи от устройства-источника 12 до устройства-получателя 14.

В некоторых других реализациях кодированные видеоданные могут быть переданы из интерфейса 22 вывода в запоминающее устройство 32. Затем устройство-получатель 14 может получить доступ к кодированным видеоданным в запоминающем устройстве 32 через интерфейс 28 ввода. Запоминающее устройство 32 может включать в себя любой из множества распределенных или локально доступных носителей хранения данных, таких как жесткий диск, диски Blu-ray, DVD, CD-ROM, флэш-память, энергозависимая или энергонезависимая память, или любые другие подходящие цифровые носители хранения данных для хранения кодированных видеоданных. В дополнительном примере запоминающее устройство 32 может соответствовать файловому серверу или другому промежуточному запоминающему устройству, которое может хранить кодированные видеоданные, выработанные устройством-источником 12. Устройство-получатель 14 может получать доступ к сохраненным видеоданным из запоминающего устройства 32 посредством потоковой передачи или загрузки. Файловый сервер может быть компьютером любого типа, способным хранить кодированные видеоданные и передавать кодированные видеоданные в устройство-получатель 14. Примеры файловых серверов включают в себя веб-сервер (например, для веб-сайта), FTP-сервер, подключенные к сети запоминающие устройства (NAS) или накопитель на локальном диске. Устройство-получатель 14 может получить доступ к кодированным видеоданным через любое стандартное соединение передачи данных, включая беспроводной канал (например, Wi-Fi соединение), проводное соединение (например, DSL, кабельный модем и т.д.) или комбинацию того и другого, которая подходит для доступа к кодированным видеоданным, сохраненным на файловом сервере. Передача кодированных видеоданных из запоминающего устройства 32 может быть потоковой передачей, передачей загрузки или их комбинацией.

Как показано на фиг.1, устройство-источник 12 включает в себя видеоисточник 18, видеокодер 20 и интерфейс 22 вывода. Видеоисточник 18 может включать в себя источник, такой как устройство видеозахвата, например, видеокамеру, видеоархив, содержащий ранее захваченное видео, интерфейс источника видеосигнала для приема видео от поставщика видеоконтента, и/или систему компьютерной графики для генерирования данных компьютерной графики в качестве источника видео или сочетание таких источников. В качестве одного примера, если видеоисточник 18 является видеокамерой системы охранного наблюдения, устройство-источник 12 и устройство-получатель 14 могут образовывать камерамифоны или видеотелефоны. Однако реализации, описанные в настоящей заявке, могут быть применимы к кодированию видео в целом и могут применяться к беспроводным и/или проводным приложениям.

Видеокодер 20 может кодировать захваченное, предварительно захваченное или сгенерированное компьютером видео. Кодированные видеоданные могут быть переданы напрямую в устройство-получатель 14 через интерфейс 22 вывода устройства-источника 12. Кодированные видеоданные могут также (или альтернативно) храниться в запоминающем устройстве 32 для последующего доступа со стороны устройства-получателя 14 или других устройств для декодирования и/или воспроизведения. Интерфейс 22 вывода может дополнительно включать модем и/или передатчик.

Устройство-получатель 14 включает в себя интерфейс 28 ввода, видеодекодер 30 и устройство 34 отображения. Интерфейс 28 ввода может включать в себя приемник и/или модем и принимать кодированные видеоданные по линии 16 связи. Кодированные видеоданные, переданные по линии 16 связи или предоставленные в запоминающее устройство 32, могут включать в себя множество синтаксических элементов, выработанных видеокодером 20, предназначенных для использования видеодекодером 30 при декодировании видеоданных. Такие синтаксические элементы могут быть включены в кодированные видеоданные, передаваемые в среде связи, сохраненные на носителе информации или хранящиеся на файловом сервере.

В некоторых реализациях устройство-получатель 14 может включать в себя устройство 34 отображения, которое может быть встроенным в него устройством отображения и внешним по отношению к нему устройством отображения, которое выполнено с возможностью поддержания связи с устройством-получателем 14. Устройство 34 отображения отображает декодированные видеоданные пользователю и может содержать любое из разнообразных устройств отображения, таких как жидкокристаллический дисплей (LCD), плазменный дисплей, дисплей на органических светоизлучающих диодах (OLED) или устройство отображения другого типа.

Видеокодер 20 и видеодекодер 30 могут работать в соответствии с частными или отраслевыми стандартами, такими как VVC, HEVC, MPEG-4, часть 10, улучшенное кодирование видео (AVC) или расширенные версии таких стандартов. Следует понимать, что настоящая заявка не ограничена конкретным стандартом кодирования/декодирования видео и может быть применима к другим стандартам кодирования/декодирования видео. В общем, предполагается, что видеокодер 20 устройства-источника 12 может быть выполнен с возможностью кодирования видеоданных в соответствии с любым из этих текущих или будущих стандартов. Аналогичным образом, в общем, предполагается, что видеодекодер 30 устройства-получателя 14 может быть выполнен с возможностью декодирования видеоданных согласно любому из этих текущих или будущих стандартов.

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

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

Как показано на фиг.2, видеокодер 20 включает в себя память 40 видеоданных, блок 41 обработки прогнозирования, буфер 64 декодированных изображений (DPB), сумматор 50, блок 52 обработки преобразования, блок 54 квантования и блок 56 энтропийного кодирования. Блок 41 обработки прогнозирования дополнительно включает в себя блок 42 оценки движения, блок 44 компенсации движения, блок 45 разделения, блок 46 обработки внутреннего прогнозирования и блок 48 интраблочного копирования (BC). В некоторых реализациях видеокодер 20 также включает в себя блок 58 обратного квантования, блок 60 обработки обратного преобразования и сумматор 62 для восстановления видеоблока. Фильтр удаления блочности (не показан) может быть расположен между сумматором 62 и DPB 64 для фильтрации границ блоков с целью удаления артефактов блочности из восстановленного видео. Петлевой фильтр (не показан) также может использоваться в дополнение к фильтру удаления блочности для фильтрации выходного сигнала сумматора 62. Видеокодер 20 может иметь форму фиксированного или программируемого аппаратного блока или может быть разделен среди одного или более проиллюстрированных фиксированных или программируемых аппаратных блоков.

Память 40 видеоданных может хранить видеоданные, которые должны быть кодированы компонентами видеокодера 20. Видеоданные в памяти 40 видеоданных могут быть получены, например, из видеоисточника 18. DPB 64 представляет собой буфер, который хранит эталонные видеоданные, предназначенные для использования при кодировании видеоданных видеокодером 20 (например, в режимах кодирования с интра- или внутреннее прогнозированием). Память 40 видеоданных и DPB 64 могут быть образованы любым из множества запоминающих устройств. В различных примерах память 40 видеоданных может быть расположена на том же кристалле с другими компонентами видеокодера 20 или быть внешней по отношению к этим компонентам.

Как показано на фиг.2, после приема видеоданных блок 45 разделения в блоке 41 обработки прогнозирования разделяет видеоданные на видеоблоки. Это разделение может также включать в себя разделение видеокадра на слайсы, мозаичные элементы или другие более крупные единицы кодирования (CU) в соответствии с заданными структурами разделения, такими как структура квадродерева, ассоциированная с видеоданными. Видеокадр может быть разделен на несколько видеоблоков (или наборов видеоблоков, называемых тайлами). Блок 41 обработки прогнозирования может выбрать один из множества возможных режимов кодирования с прогнозированием, например, один из множества режимов кодирования с внешним прогнозированием или один из множества режимов кодирования с внешнее прогнозированием, для текущего видеоблока на основе результатов ошибок (например, скорости кодирования и уровня искажений). Блок 41 обработки прогнозирования может предоставить результирующий кодированный блок с интра- или внутреннее прогнозированием в сумматор 50 для генерирования остаточного блока и в сумматор 62, чтобы восстановить кодированный блок для дальнейшего использования в качестве части опорного кадра. Блок 41 обработки прогнозирования также предоставляет синтаксические элементы, например, векторы движения, индикаторы интрарежима, информацию о разделении и другую такую информацию синтаксиса, в блок 56 энтропийного кодирования.

Для того чтобы выбрать подходящий режим кодирования с внешним прогнозированием для текущего видеоблока, блок 46 обработки с внешним прогнозированием в блоке 41 обработки прогнозирования может выполнить кодирование с внешним прогнозированием текущего видеоблока по отношению к одному или нескольким соседним блокам в том самом же кадре, как и текущий блок, который нужно кодировать для обеспечения пространственного прогнозирования. Блок 42 оценки движения и блок 44 компенсации движения в блоке 41 обработки прогнозирования выполняют кодирование с внутренним прогнозированием текущего видеоблока по отношению к одному или нескольким блокам прогнозирования в одном или более опорных кадрах для обеспечения временного прогнозирования. Видеокодер 20 может выполнить несколько проходов кодирования, например, для выбора подходящего режима кодирования для каждого блока видеоданных.

В некоторых реализациях блок 42 оценки движения определяет режим внешнего прогнозирования для текущего видеокадра путем генерирования вектора движения, который указывает смещение единицы прогнозирования (PU) видеоблока в текущем видеокадре относительно блока прогнозирования в опорном видеокадре, в соответствии с заданным шаблоном в пределах последовательности видеокадров. Оценка движения, выполняемая блоком 42 оценки движения, представляет собой процесс генерирования векторов движения, которые оценивают движение для видеоблоков. Например, вектор движения может указывать на перемещение PU видеоблока в пределах текущего видеокадра или изображения относительно блока прогнозирования в пределах опорного кадра (или другой кодированной единицы) относительно текущего блока, кодируемого в пределах текущего кадра (или другой кодированной единицы). Заданный шаблон может обозначать видеокадры в последовательности как P-кадры или B-кадры. Блок 48 интра-BC может определять векторы, например, векторы блоков, для интра-BC кодирования способом, аналогичным определению векторов движения с помощью блока 42 оценки движения для внешнего прогнозирования, или может использовать блок 42 оценки движения для определения вектора блока.

Блок прогнозирования представляет собой блок опорного кадра, который считается наиболее соответствующим PU видеоблока, подлежащего кодированию, с точки зрения пиксельной разности, которая может быть определена суммой абсолютной разности (SAD), суммой разности квадратов (SSD) или других метрик разности. В некоторых реализациях видеокодер 20 может вычислять значения для позиций субцелого пикселя опорных кадров, хранящихся в DPB 64. Например, видеокодер 20 может интерполировать значения позиций четверти пикселя, позиций одной восьмой пикселя или других позиций дробного пикселя опорного кадра. Следовательно, блок 42 оценки движения может осуществлять поиск движения относительно позиций полных пикселей и позиций частичного пикселя и выводить вектор движения с точностью до частичного пикселя.

Блок 42 оценки движения вычисляет вектор движения для PU видеоблока в кодированном кадре с внутренним прогнозированием путем сравнения позиции PU с позицией блока прогнозирования опорного кадра, выбранного из первого списка опорных кадров (списка 0) или второго списка опорных кадров (списка 1), каждый из которых идентифицирует один или более опорных кадров, хранящихся в DPB 64. Блок 42 оценки движения отправляет вычисленный вектор движения в блок 44 компенсации движения и затем в блок 56 энтропийного кодирования.

Компенсация движения, выполняемая блоком 44 компенсации движения, может включать в себя выборку или выработку блока прогнозирования на основе вектора движения, определенного блоком 42 оценки движения. После приема вектора движения для PU текущего видеоблока блок 44 компенсации движения может найти блок прогнозирования, на который указывает вектор движения в одном из списков опорных кадров, извлечь блок прогнозирования из DPB 64 и направить блок прогнозирования в сумматор 50. Затем сумматор 50 формирует остаточный видеоблок значений пиксельной разности путем вычитания пиксельных значений блока прогнозирования, предоставленного блоком 44 компенсации движения, из пиксельных значений текущего кодируемого видеоблока. Пиксельные значения разности, образующие остаточный видеоблок, могут включать в себя компоненты разности яркости или цветности, или и то, и другое. Блок 44 компенсации движения также может выработать синтаксические элементы, ассоциированные с видеоблоками видеокадра, предназначенные для использования видеодекодером 30 при декодировании видеоблоков видеокадра. Синтаксические элементы могут включать в себя, например, синтаксические элементы, определяющие вектор движения, используемый для идентификации блока прогнозирования, любые флаги, указывающие режим прогнозирования, или любую другую информацию синтаксиса, описанную в данном документе. Следует отметить, что блок 42 оценки движения и блок 44 компенсации движения могут быть сильно интегрированы, но показаны отдельно для концептуальных целей.

В некоторых реализациях блок 48 интра-BC может генерировать векторы и производить выборку блоков прогнозирования способом, аналогичным тому, который описан выше в связи с блоком 42 оценки движения и блоком 44 компенсации движения, но с блоками прогнозирования, находящимися в том же кадре, что и кодируемый текущий блок, причем векторы называются векторами блоков, а не векторами движения. В частности, блок 48 интра-BC может определить режим внутреннего прогнозирования, предназначенный для использования при кодировании текущего блока. В некоторых примерах блок 48 интра-BC может кодировать текущий блок с использованием различных режимов внутреннего прогнозирования, например, во время отдельных проходов кодирования, и тестировать их производительность посредством анализа скорости кодирования и искажения. Затем блок 48 интра-BC может выбрать среди различных протестированных режимов внутреннего прогнозирования подходящий режим внутреннего прогнозирования для использования и, соответственно, сформировать индикатор интрарежима. Например, блок 48 интра-BC может вычислять значения скорости кодирования и искажения с использованием анализа скорости кодирования и искажения для различных протестированных режимов внутреннего прогнозирования и выбирать для использования режим внутреннего прогнозирования, имеющий наилучшие характеристики скорости кодирования и искажения среди тестируемых режимов, в качестве подходящего режима внутреннего прогнозирования. Анализ скорости кодирования и искажения обычно определяет величину искажения (или ошибки) между кодированным блоком и исходным некодированным блоком, который был кодирован для создания кодированного блока, а также битовую скорость (то есть количество битов), используемую для создания кодированного блока. Блок 48 интра-BC может вычислять коэффициенты из искажений и скоростей кодирования для различных кодированных блоков, чтобы определить, какой режим внутреннего прогнозирования имеет наилучшее значение скорости кодирования и искажения для блока.

В других примерах блок 48 интра-BC может использовать блок 42 оценки движения и блок 44 компенсации движения для выполнения, полностью или частично, таких функций для внутреннего прогнозирования BC согласно реализациям, описанным в данном документе. В любом случае для копии внутри блока блок прогнозирования может быть блоком, который считается наиболее совпадающим с блоком, который должен быть кодирован, с точки зрения пиксельной разности, которую можно определить с помощью суммы абсолютных разностей (SAD), суммы квадратов разностей (SSD) или других показателей разности, и идентификация блока прогнозирования может включать в себя вычисление значений для позиций субцелочисленных пикселей.

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

Блок 46 обработки внутреннего прогнозирования может выполнять внутреннее прогнозирование текущего видеоблока в качестве альтернативы внутреннему прогнозированию, выполняемому блоком 42 оценки движения и блоком 44 компенсации движения, или прогнозированию копии внутри блока, выполняемому блоком 48 интра-BC, как описано выше. В частности, блок 46 обработки внутреннего прогнозирования может определять режим внутреннего прогнозирования, который используется для кодирования текущего блока. С этой целью блок 46 обработки внутреннего прогнозирования может кодировать текущий блок с использованием различных режимов внутреннего прогнозирования, например, во время отдельных проходов кодирования, и блок 46 обработки внутреннего прогнозирования (или в некоторых примерах блок выбора режима) может выбрать для использования подходящий режим внутреннего прогнозирования из протестированных режимов внутреннего прогнозирования. Блок 46 обработки внутреннего прогнозирования может предоставлять информацию, указывающую выбранный режим внутреннего прогнозирования для блока, в блок 56 энтропийного кодирования. Блок 56 энтропийного кодирования может кодировать информацию, указывающую выбранный режим внутреннего прогнозирования в битовом потоке.

После того, как блок 41 обработки прогнозирования определяет блок прогнозирования для текущего видеоблока посредством внешнего прогнозирования или внутреннего прогнозирования, блок 50 суммирования формирует остаточный видеоблок путем вычитания блока прогнозирования из текущего видеоблока. Остаточные видеоданные в остаточном блоке могут быть включены в один или более блоков преобразования (TU) и предоставлены в блок 52 обработки преобразования. Блок 52 обработки преобразования преобразует остаточные видеоданные в остаточные коэффициенты преобразования с использованием преобразования, такого как дискретное косинусное преобразование (DCT) или концептуально похожее преобразование.

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

После квантования блок 56 энтропийного кодирования энтропийно кодирует квантованные коэффициенты преобразования в битовый поток видео, используя, например, контекстно-адаптивное кодирование переменной длины (CAVLC), контекстно-адаптивное двоичное арифметическое кодирование (CABAC), основанное на синтаксисе контекстно-адаптивное двоичное арифметическое кодирование (SBAC), энтропийное кодирование с разделением интервала вероятности (PIPE) или другой способ или способ энтропийного кодирования. Затем кодированный битовый поток может быть передан в видеодекодер 30 или заархивирован в запоминающем устройстве 32 для последующей передачи или извлечения видеодекодером 30. Блок 56 энтропийного кодирования может также энтропийно кодировать векторы движения и другие синтаксические элементы для текущего кодируемого видеокадра.

Блок 58 обратного квантования и блок 60 обработки обратного преобразования применяет обратное квантование и обратное преобразование, соответственно, для восстановления остаточного видеоблока в пиксельной области для генерирования опорного блока для прогнозирования других видеоблоков. Как отмечено выше, блок 44 компенсации движения может выработать блок прогнозирования с компенсацией движения из одного или более эталонных блоков кадров, хранящихся в DPB 64. Блок 44 компенсации движения может также применять один или более интерполяционных фильтров к блоку прогнозирования для вычисления субцелых значений пикселей для использования при оценке движения.

Сумматор 62 добавляет восстановленный остаточный блок к блоку прогнозирования с компенсацией движения, созданному блоком 44 компенсации движения, чтобы создать эталонный блок для хранения в DPB 64. Затем эталонный блок может использоваться блоком 48 интра-BC, блоком 42 оценки движения и блоком 44 компенсации движения в качестве блока прогнозирования для внешнего прогнозирования другого видеоблока в последующем видеокадре.

На фиг.3 показана блок-схема, иллюстрирующая примерный видеодекодер 30 в соответствии с некоторыми реализациями настоящей заявки. Видеодекодер 30 включает в себя память 79 видеоданных, блок 80 энтропийного декодирования, блок 81 обработки прогнозирования, блок 86 обратного квантования, блок 88 обработки обратного преобразования, сумматор 90 и DPB 92. Блок 81 обработки прогнозирования дополнительно включает в себя блок 82 компенсации движения, блок 84 обработки внутреннего прогнозирования и блок 85 интра-BC. Видеодекодер 30 может выполнять процесс декодирования, в целом обратный процессу кодирования, описанному выше в отношении видеокодера 20 со ссылкой на фиг.2. Например, блок 82 компенсации движения может генерировать данные прогнозирования на основе векторов движения, принятых из блока 80 энтропийного декодирования, в то время как блок 84 внутреннего прогнозирования может генерировать данные прогнозирования на основе индикаторов режима внутреннего прогнозирования, принятых из блока 80 энтропийного декодирования.

В некоторых примерах блоку видеодекодера 30 может быть поручено выполнять реализации настоящей заявки. Кроме того, в некоторых примерах реализации настоящего раскрытия могут быть разделены между одним или более блоками видеодекодера 30. Например, блок 85 интра-BC может выполнять реализации настоящей заявки, отдельно или в комбинации с другими блоками видеодекодера 30, такими как блок 82 компенсации движения, блок 84 обработки внутреннего прогнозирования и блок 80 энтропийного декодирования. В некоторых примерах видеодекодер 30 может не включать в себя блок 85 интра-BC, и функциональные возможности блока 85 интра-BC могут выполняться другими компонентами блока 81 обработки прогнозирования, такими как блок 82 компенсации движения.

Память 79 видеоданных может хранить видеоданные, такие как кодированный битовый поток видеоданных, для декодирования другими компонентами видеодекодера 30. Видеоданные, хранящиеся в памяти 79 видеоданных, могут быть получены, например, из запоминающего устройства 32, из локального видеоисточника, такого как камера, через проводную или беспроводную сетевую передачу видеоданных или путем доступа к физическим носителям информации (например, флэш-накопителю или жесткому диску). Память 79 видеоданных может включать в себя буфер кодированных изображений (CPB), в котором хранятся кодированные видеоданные из кодированного битового потока видеоданных. Буфер 92 декодированных изображений (DPB) видеодекодера 30 хранит эталонные видеоданные, предназначенный для использования при декодировании видеоданных видеодекодером 30 (например, в режимах кодирования с интра- или внутреннее прогнозированием). Память 79 видеоданных и DPB 92 могут быть образованы любым из множества запоминающих устройств, таких как динамическое оперативное запоминающее устройство (DRAM), в том числе синхронное DRAM (SDRAM), магниторезистивное RAM (MRAM), резистивное RAM (RRAM) или запоминающие устройства других типов. В иллюстративных целях память 79 видеоданных и DPB 92 изображены на фиг.3 как два отдельных компонента видеодекодера 30. Но для специалиста в данной области техники будет очевидно, что память 79 видеоданных и DPB 92 могут быть выполнены в виде одного и того же запоминающего устройства или отдельных запоминающих устройств. В некоторых примерах память 79 видеоданных может быть выполнена на кристалле с другими компонентами видеодекодера 30 или вне кристалла по отношению к этим компонентам.

Во время процесса декодирования видеодекодер 30 принимает кодированный битовый поток видеоданных, который представляет видеоблоки кодированного видеокадра и ассоциированных синтаксических элементов. Видеодекодер 30 может принимать синтаксические элементы на уровне видеокадра и/или на уровне видеоблока. Блок 80 энтропийного декодирования видеодекодера 30 энтропийно декодирует битовый поток для генерирования квантованных коэффициентов, векторов движения или индикаторов режима внутреннего прогнозирования и других синтаксических элементов. Затем блок 80 энтропийного декодирования направляет векторы движения и другие синтаксические элементы в блок 81 обработки прогнозирования.

Когда видеокадр закодирован как кодированный с внешним прогнозированием (I) кадр или для блоков с внешним прогнозированием в других типах кадров, блок 84 обработки с внешним прогнозированием блока 81 обработки прогнозирования может выработать данные прогнозирования для видеоблока текущего видеокадра на основе сигнализируемого режима внутреннего прогнозирования и эталонных данных из ранее декодированных блоков текущего кадра.

Когда видеокадр закодирован как кодированный с внутренним прогнозированием (то есть B или P) кадр, блок 82 компенсации движения блока 81 обработки прогнозирования создает один или более блоков прогнозирования для видеоблока текущего видеокадра на основе векторов движения и других синтаксических элементов, принятых из блока 80 энтропийного декодирования. Каждый из блоков прогнозирования декодирования может быть получен из опорного кадра в одном из списков опорных кадров. Видеодекодер 30 может создавать списки опорных кадров, список 0 и список 1, используя технологии построения по умолчанию на основе опорных кадров, хранящихся в DPB 92.

В некоторых примерах, когда видеоблок закодирован в соответствии с режимом интра-BC, описанным в данном документе, блок 85 интра-BC блока 81 обработки прогнозирования создает блоки прогнозирования для текущего видеоблока на основе векторов блоков и других синтаксических элементов, принятых из блока 80 энтропийного декодирования. Блоки прогнозирования могут находиться в восстановленной области того же изображения, что и текущий видеоблок, определенный видеокодером 20.

Блок 82 компенсации движения и/или блок 85 интра-BC определяет информацию прогнозирования для видеоблока текущего видеокадра путем синтаксического анализа векторов движения и других синтаксических элементов и затем использует информацию прогнозирования для создания блоков прогнозирования для текущего декодируемого видеоблока. Например, блок 82 компенсации движения использует некоторые из принятых синтаксических элементов для определения режима прогнозирования (например, интра- или внешнего прогнозирования), используемого для кодирования видеоблоков видеокадра, типа кадра внешнего прогнозирования (например, B или P), информации о построении для одного или более списков опорных кадров для кадра, векторов движения для каждого видеоблока, кодированного с внутреннее прогнозированием, статуса внешнего прогнозирования для каждого видеоблока, кодированного с внутреннее прогнозированием, и другой информации, предназначенной для декодирования видеоблоков в текущем кадре видео.

Аналогичным образом, блок 85 интра-BC может использовать некоторые из принятых синтаксических элементов, например, флаг, чтобы определить, что текущий видеоблок был спрогнозирован с использованием режима интра-BC, информацию построения, указывающую какие видеоблоки кадра находятся в восстановленной области и должны быть сохранены в DPB 92, векторы блоков для каждого интра-BC спрогнозированного видеоблока, статус интра-BC прогнозирования для каждого интра-BC спрогнозированного видеоблока и другую информацию, предназнченную для декодирования видеоблоков в текущем видеокадре.

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

Блок 86 обратного квантования осуществляет обратное квантование квантованных коэффициентов преобразования, предоставленных в битовом потоке, и энтропийно декодированных блоком 80 энтропийного декодирования, используя один и тот же параметр квантования, вычисленный видеокодером 20 для каждого видеоблока в видеокадре, чтобы определить степень квантования. Блок 88 обработки обратного преобразования применяет обратное преобразование, например, обратное DCT, обратное целочисленное преобразование или концептуально аналогичный процесс обратного преобразования, к коэффициентам преобразования, чтобы восстановить остаточные блоки в пиксельной области.

После того, как блок 82 компенсации движения или блок 85 интра-BC выработает блок прогнозирования для текущего видеоблока на основе векторов и других синтаксических элементов, сумматор 90 восстанавливает декодированный видеоблок для текущего видеоблока путем суммирования остаточного блока из блока 88 обработки обратного преобразования и соответствующего блока прогнозирования, выработанного блоком 82 компенсации движения и блоком 85 интра-BC. Внутриконтурный фильтр (не изображен) может быть расположен между сумматором 90 и DPB 92 для дальнейшей обработки декодированного видеоблока. Декодированные видеоблоки в данном кадре затем сохраняются в DPB 92, который хранит опорные кадры, используемые для последующей компенсации движения следующих видеоблоков. DPB 92 или запоминающее устройство, расположенное отдельно от DPB 92, также может хранить декодированное видео для последующего представления на устройстве отображения, таком как устройство 34 отображения, показанное на фиг.1.

В типичном процессе видеокодирования видеопоследовательность обычно включает в себя упорядоченный набор кадров или изображений. Каждый кадр может включать в себя три массива выборок, обозначенных SL, SCb и SCr. SL представляет собой двумерный массив выборок яркости. SCb представляет собой двумерный массив выборок цветности Cb. SCr представляет собой двумерный массив выборок цветности Cr. В других случаях кадр может быть монохромным и поэтому включает в себя только один двумерный массив выборок яркости.

Как показано на фиг.4A, видеокодер 20 (или, более конкретно, блок 45 разделения) вырабатывает кодированное представление кадра, сначала разбивая кадр на набор единиц дерева кодирования (CTU). Видеокадр может включать в себя целое число CTU, упорядоченных последовательно в порядке растрового сканирования слева-направо и сверху-вниз. Каждая CTU является самой большой единицей логического кодирования, и ширина и высота CTU сигнализируются видеокодером 20 в наборе параметров последовательности, поэтому все CTU в видеопоследовательности имеют одинаковый размер, равный 128×128, 64×64, 32×32 и 16×16. Но следует отметить, что настоящая заявка не обязательно ограничивается конкретным размером. Как показано на фиг.4B, каждая CTU может содержать один блок дерева кодирования (CTB) выборок яркости, два соответствующих блока дерева кодирования выборок цветности и синтаксические элементы, используемые для кодирования выборок блоков дерева кодирования. Синтаксические элементы описывают свойства различных типов единиц кодированного блока пикселей и то, как видеопоследовательность может быть восстановлена в видеодекодере 30, включая интер- или внешнее прогнозирование, режим внутреннего прогнозирования, векторы движения и другие параметры. В монохромных изображениях или изображениях, имеющих три отдельные цветовые плоскости, CTU может содержать один блок дерева кодирования и синтаксические элементы, используемые для кодирования выборок блока дерева кодирования. Блок дерева кодирования может быть блоком N×N выборок.

Для достижения лучшей производительности видеокодер 20 может рекурсивно выполнять разделение дерева, такое как разделение двоичного дерева, разделение квадродерева или их комбинацию, на блоки дерева кодирования CTU и разделять CTU на меньшие единицы кодирования (CU). Как показано на фиг.4C, CTU 400 размером 64×64 сначала делится на четыре меньших CU, каждая из которых имеет размер блока 32×32. Среди четырех меньших CU каждая CU 410 и CU 420 разделена на четыре CU с размером блока 16×16. Каждый из двух блоков 430 и 440 16×16 дополнительно делится на четыре блока CU с размером блока 8×8. На фиг.4D показана структура данных квадродерева, иллюстрирующая конечный результат процесса разделения CTU 400, который показан на фиг.4C, при этом каждый листовой узел квадродерева соответствует одной CU соответствующего размера в диапазоне от 32×32 до 8×8. Подобно CTU, изображенной на фиг.4B, каждая CU может содержать блок кодирования (CB) выборок яркости и два соответствующих блока кодирования выборок цветности кадра одинакового размера и синтаксические элементы, используемые для кодирования выборок блоков кодирования. В монохромных изображениях или изображениях, имеющих три отдельные цветовые плоскости, CU может содержать один блок кодирования и синтаксические структуры, используемые для кодирования выборок блока кодирования.

В некоторых реализациях видеокодер 20 может дополнительно разделить блок кодирования CU на один или более блоков прогнозирования (PB) размером M×N. Блок прогнозирования представляет собой прямоугольный (квадратный или неквадратный) блок выборок, к которому применяется одно и то же интра- или внутреннее прогнозирование. Блок прогнозирования (PU) CU может содержать блок прогнозирования выборок яркости, два соответствующих блока прогнозирования выборок цветности и синтаксические элементы, используемые для прогнозирования блоков прогнозирования. В монохромных изображениях или изображениях, имеющих три отдельные цветовые плоскости, PU может содержать один блок прогнозирования и синтаксические структуры, используемые для прогнозирования блока прогнозирования. Видеокодер 20 может выработать блоки прогнозирования яркости, Cb и Cr для блоков прогнозирования яркости, Cb и Cr каждого PU из CU.

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

После того, как видеокодер 20 выработает блоки прогнозирования яркости, Cb и Cr для одного или более PU из CU, видеокодер 20 может выработать остаточный блок яркости для CU путем вычитания блоков прогнозирования яркости CU из его исходного блока кодирования яркости таким образом, чтобы каждая выборка в остаточном блоке яркости CU указывала разницу между выборкой яркости в одном из блоков прогнозирования яркости CU и соответствующей выборкой в исходном блоке кодирования яркости CU. Аналогичным образом, видеокодер 20 может выработать остаточный блок Cb и остаточный блок Cr для CU, соответственно, так что каждая выборка в остаточном блоке Cb CU указывает разницу между выборкой Cb в одном из блоков прогнозирования Cb CU и соответствующей выборкой в исходном блоке кодирования Cb CU, и каждая выборка в остаточном блоке Cr CU может указывать на разницу между выборкой Cr в одном из блоков прогнозирования Cr CU и соответствующей выборкой в исходном блоке кодирования Cr CU.

Кроме того, как показано на фиг.4C, видеокодер 20 может использовать разбиение квадродерева, чтобы разложить остаточные блоки яркости, Cb и Cr CU на один или более блоков преобразования яркости, Cb и Cr. Блок преобразования представляет собой прямоугольный (квадратный или неквадратный) блок выборок, к которому применяется одно и то же преобразование. Единица преобразования (TU) CU может содержать блок преобразования выборок яркости, два соответствующих блока преобразования выборок цветности и синтаксические элементы, используемые для преобразования выборок блока преобразования. Таким образом, каждая TU в CU может ассоциироваться с блоком преобразования яркости, блоком преобразования Cb и блоком преобразования Cr. В некоторых примерах блок преобразования яркости, ассоциированный с TU, может быть подблоком остаточного блока яркости CU. Блок преобразования Cb может быть подблоком остаточного блока Cb CU. Блок преобразования Cr может быть подблоком остаточного блока Cr CU. В монохромных изображениях или изображениях, имеющих три отдельные цветовые плоскости, TU может содержать единственный блок преобразования и синтаксические структуры, используемые для преобразования выборок блока преобразования.

Видеокодер 20 может применять одно или более преобразований к блоку преобразования яркости TU, чтобы выработать блок коэффициентов яркости для TU. Блок коэффициентов может быть двумерным массивом коэффициентов преобразования. Коэффициент преобразования может быть скалярной величиной. Видеокодер 20 может применить одно или более преобразований к блоку преобразования Cb TU, чтобы выработать блок коэффициентов Cb для TU. Видеокодер 20 может применить одно или более преобразований к блоку преобразования Cr TU, чтобы выработать блок коэффициентов Cr для TU.

После генерирования блока коэффициентов (например, блока коэффициентов яркости, блока коэффициентов Cb или блока коэффициентов Cr) видеокодер 20 может квантовать блок коэффициентов. Квантование обычно относится к процессу, в котором коэффициенты преобразования квантуются для возможного уменьшения объема данных, используемых для представления коэффициентов преобразования, обеспечивая дополнительное сжатие. После того, как видеокодер 20 выполнит квантование блока коэффициентов, видеокодер 20 может энтропийно кодировать синтаксические элементы, указывающие квантованные коэффициенты преобразования. Например, видеокодер 20 может выполнять контекстно-адаптивное двоичное арифметическое кодирование (CABAC) над синтаксическими элементами, указывающими квантованные коэффициенты преобразования. Наконец, видеокодер 20 может выводить битовый поток, который включает в себя последовательность битов, которая формирует представление кодированных кадров и ассоциированных данных, которые либо сохраняются в запоминающем устройстве 32, либо передаются в устройство-получатель 14.

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

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

Но при постоянно улучшающейся технологии захвата видеоданных и более точном размере видеоблока для сохранения деталей в видеоданных объем данных, необходимых для представления векторов движения для текущего кадра, также существенно увеличивается. Один из способов преодоления этой проблемы состоит в том, чтобы извлечь выгоду из того факта, что не только группа соседних CU как в пространственной, так и во временной областях имеет аналогичные видеоданные для целей прогнозирования, но и векторы движения между этими соседними CU также являются аналогичными. Таким образом, можно использовать информацию о движении пространственно соседних CU и/или совместно расположенных во времени CU в качестве аппроксимации информации о движении (например, вектора движения) текущей CU, исследуя их пространственную и временную корреляцию, которая также упоминается как "предиктор вектора движения" (MVP) текущей CU.

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

Как и в процессе выбора блока прогнозирования в опорном кадре во время внешнего прогнозирования кодового блока, набор правил должен быть принят как видеокодером 20, так и видеодекодером 30 для построения списка векторов-кандидатов движения для текущей CU, использующей те потенциальные векторы-кандидаты движения, которые ассоциируются с пространственно соседними CU и/или совместно расположенными во времени CU текущей CU, и затем выбора одного элемента из списка векторов-кандидатов движения в качестве предиктора вектора движения для текущей CU. Таким образом, нет необходимости передавать непосредственно список векторов-кандидатов движения между видеокодером 20 и видеодекодером 30, и индекса выбранного предиктора вектора движения в списке векторов-кандидатов движения достаточно для того, чтобы видеокодер 20 и видеодекодер 30 использовали один и тот же предиктор вектора движения в списке векторов-кандидатов движения для кодирования и декодирования текущей CU.

В некоторых реализациях каждая CU внешнего прогнозирования имеет три режима прогнозирования вектора движения, в том числе режим внешнего прогнозирования (который также упоминается как "усовершенствованное прогнозирование вектора движения" (AMVP)), режим пропуска и режим слияния для построения списка векторов-кандидатов движения. В каждом режиме один или более векторов-кандидатов движения могут быть добавлены в список векторов-кандидатов движения согласно алгоритмам, описанным ниже. В конечном итоге один из них в списке кандидатов используется в качестве лучшего предиктора вектора движения для CU с внутреннее прогнозированием, который должен быть кодирован в битовый поток видео видеокодером 20 или декодирован из битового потока видео видеодекодером 30. Чтобы найти лучший предиктор вектора движения из списка кандидатов, вводится схема конкуренции векторов движения (MVC) для выбора вектора движения из заданного набора кандидатов векторов движения, то есть из списка векторов-кандидатов движения, который включает в себя пространственные и временные векторы-кандидаты движения.

В дополнение к извлечению предикторов векторов-кандидатов движения из пространственно соседних или совместно расположенных во времени CU, кандидаты-предикторы векторов движения также могут быть получены из так называемой таблицы "прогнозирования вектора движения на основе истории" (HMVP). Таблица HMVP содержит заданное количество предикторов векторов движения, каждый из которых использовался для кодирования/декодирования конкретной CU одной и той же строки CTU (или иногда одной и той же CTU). Из-за пространственной/временной близости этих CU существует высокая вероятность того, что один из предикторов векторов движения в таблице HMVP может быть повторно использован для кодирования/декодирования разных CU в одной строке CTU. Таким образом, можно достичь более высокой эффективности кода путем включения таблицы HMVP в процесс построения списка векторов-кандидатов движения.

В некоторых реализациях таблица HMVP имеет фиксированную длину (например, 5), и ее управление осуществляется по принципу квази-первый пришел - первый вышел (FIFO). Например, вектор движения восстанавливается для CU при декодировании одного интеркодированного блока CU. Таблица HMVP обновляется "на лету" с помощью восстановленного вектора движения, так как такой вектор движения может быть предиктором вектора движения для последующего CU. При обновлении таблицы HMVP существует два сценария: (1) восстановленный вектор движения отличается от других существующих векторов движения в таблице HMVP, или (2) восстановленный вектор движения совпадает с одним из существующих векторов движения в таблице HMVP. Для первого сценария восстановленный вектор движения добавляется в таблицу HMVP как самый новый, если таблица HMVP не заполнена. Если таблица HMVP уже заполнена, самый старый вектор движения в таблице HMVP необходимо сначала удалить из таблицы HMVP, прежде чем восстановленный вектор движения будет добавлен как самый новый. Другими словами, таблица HMVP в этом случае похожа на буфер FIFO, так что информация о движении, расположенная в заголовке буфера FIFO и ассоциированная с другим ранее кодированным блоком, смещается из буфера, так что восстановленный вектор движения добавляется в конец буфера FIFO как самый новый элемент в таблице HMVP. Для второго сценария существующий вектор движения в таблице HMVP, который по существу идентичен восстановленному вектору движения, удаляется из таблицы HMVP до того, как восстановленный вектор движения добавляется в таблицу HMVP как самый новый. Если таблица HMVP также поддерживается в виде буфера FIFO, предикторы вектора движения после идентичного вектора движения в таблице HMVP сдвигаются вперед на один элемент, чтобы занять пространство, оставленное удаленным вектором движения, и восстановленный вектор движения затем добавляется в конец буфера FIFO как самый новый элемент в таблице HMVP.

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

После того, как один кандидат MVP выбран в данном наборе векторов-кандидатов движения для текущей CU, видеокодер 20 может выработать один или более синтаксических элементов для соответствующего кандидата MVP и закодировать их в битовый поток видео, так что декодер 30 видео может получить кандидата MVP из битового потока видео, используя синтаксические элементы. В зависимости от конкретного режима, используемого для построения набора векторов-кандидатов движения, разные режимы (например, режим AMVP, режим слияния, режим пропуска и т.д.) имеют разные наборы синтаксических элементов. Для режима AMVP синтаксические элементы включают в себя индикаторы внешнего прогнозирования (список 0, список 1 или двунаправленное прогнозирование), эталонные индексы, индексы векторов-кандидатов движения, остаточный сигнал прогнозирования вектора движения и т.д. Для режима пропуска и режима слияния в битовый поток кодируются только индексы слияния, так как текущая CU наследует другие синтаксические элементы, включая индикаторы внешнего прогнозирования, эталонные индексы и векторы движения, из соседней CU, на которую ссылается кодированный индекс слияния. В случае пропуска кодированной CU также опускается остаточный сигнал прогнозирования вектора движения.

На фиг.5A показана блок-схема, иллюстрирующая позиции пространственно соседних и совместно расположенных во времени блоков текущей CU, подлежащей кодированию/декодированию в соответствии с некоторыми реализациями настоящего раскрытия. Для данного режима список кандидатов прогнозирования вектора движения (MVP) составляется путем первой проверки наличия векторов движения, ассоциированных с пространственно левыми и верхними соседними позициями блоков, и наличия векторов движения, ассоциированных с совместно расположенными во времени позициями блоков, и затем векторов движения в таблице HMVP. В процессе построения списка кандидатов MVP некоторые избыточные кандидаты MVP удаляются из списка кандидатов и, при необходимости, добавляется вектор движения с нулевым значением, чтобы список кандидатов имел фиксированную длину (следует обратить внимание на то, что разные режимы могут иметь разные фиксированные длины). После создания списка кандидатов MVP видеокодер 20 может выбрать лучший предиктор вектора движения из списка кандидатов и кодировать соответствующий индекс, указывающий выбранного кандидата, в битовый поток видео.

Используя фиг.5A в качестве примера, и предполагая, что список кандидатов имеет фиксированную длину, равную двум, список кандидатов предиктора вектора движения (MVP) для текущей CU может быть построен путем выполнения следующих этапов по порядку в режиме AMVP:

1) выбор кандидатов MVP из пространственно соседних CU:

a) получить до одного немасштабированного кандидата MVP из одного из двух левых пространственных соседних CU, начиная с A0 и заканчивая A1;

b) если на предыдущем этапе немасштабированные кандидаты MVP слева недоступны, получить до одного масштабированного кандидата MVP из одного из двух левых пространственных соседних CU, начиная с A0 и заканчивая A1;

c) получить до одного немасштабированного кандидата MVP из одного из трех пространственных соседних CU, начиная с B0, затем B1 и заканчивая B2;

d) если A0 и A1 недоступны, или если они закодированы в интрарежимах, получить до одного масштабированного кандидата MVP из одного из трех вышеуказанных пространственных соседних CU, начиная с B0, затем B1 и заканчивая B2;

2) если на предыдущих этапах были обнаружены два кандидата MVP, и они идентичны, удалить один из двух кандидатов из списка кандидатов MVP;

3) выбор кандидатов MVP из совместно расположенных во времени CU:

a) если список кандидатов MVP после предыдущего этапа не включает двух кандидатов MVP, получить до одного кандидата MVP из совместно расположенных во времени CU (например, T0)

4) выбор кандидатов MVP из таблицы HMVP:

a) если список кандидатов MVP после предыдущего этапа не включает двух кандидатов MVP, получить до двух MVP на основе истории из таблицы HMVP; и

5) если список кандидатов MVP после предыдущего этапа не включает двух кандидатов MVP, добавить до двух MVP с нулевым значением в список кандидатов MVP.

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

В некоторых реализациях список кандидатов MVP для текущей CU в режиме пропуска или слияния может быть построен путем выполнения аналогичного набора этапов в порядке, подобно тому, который приведен выше. Следует отметить, что один специальный вид кандидата слияния, называемого "кандидатом парного слияния", также включен в список кандидатов MVP для режима пропуска или слияния. Кандидат парного слияния вырабатывается путем усреднения MV двух ранее полученных векторов-кандидатов движения в режиме слияния. Размер списка кандидатов MVP слияния (например, от 1 до 6) сообщается в заголовке слайса текущей CU. Для каждой CU в режиме слияния индекс лучшего кандидата слияния кодируется с использованием усеченной унарной бинаризации (TU). Первый бин индекса слияния кодируется контекстом, и обходное кодирование используется для других бинов.

Как упомянуто выше, MVP на основе истории могут быть добавлены либо в список кандидатов MVP в режиме AMVP, либо в список кандидатов MVP слияния после пространственного MVP и временного MVP. Информация о движении ранее кодированной CU сохраняется в таблице HMVP и используется в качестве кандидата MVP для текущей CU. Таблица HMVP поддерживается в процессе кодирования/декодирования. Всякий раз, когда имеется внешне кодированная CU не подблока, ассоциированная информация вектора движения добавляется к последней записи таблицы HMVP в качестве нового кандидата, в то время как информация вектора движения, сохраненная в первой записи таблицы HMVP, удаляется из нее (если таблица HMVP уже заполнена, и в таблице нет идентичного дубликата ассоциированной информации вектора движения). В качестве альтернативы, идентичный дубликат ассоциированной информации вектора движения удаляется из таблицы перед добавлением ассоциированной информации вектора движения к последней записи таблицы HMVP.

Как отмечено выше, внутри блочное копирование (IBC) может значительно повысить эффективность кодирования материалов экранного содержания. Так как режим IBC реализован как режим кодирования на уровне блоков, сопоставление блоков (BM) выполняется в видеокодере 20 для того, чтобы найти оптимальный вектор блоков для каждой CU. В данном документе вектор блока используется для указания перемещения из текущего блока в эталонный блок, который уже был восстановлен в пределах текущего изображения. IBC-кодированная CU обрабатывается как третий режим прогнозирования, отличный от режимов интра- или внешнего прогнозирования.

На уровне CU режим IBC может сигнализироваться как режим AMVP IBC или режим пропуска/слияния IBC следующим образом:

- режим AMVP IBC: разность векторов блоков (BVD) между фактическим вектором блока CU и предиктором вектора блока CU, выбранным из кандидатов векторов блоков CU, кодируется таким образом, как кодируется разность векторов движения в описанном выше режиме AMVP. Способ прогнозирования вектора блока использует два кандидата вектора блока в качестве предикторов, один от левого соседа, и другой от вышележащего соседа (в случае IBC-кодирования). Когда любой из соседей недоступен, вектор блока по умолчанию будет использоваться в качестве предиктора вектора блока. Двоичный флаг сигнализируется, чтобы указать индекс предиктора вектора блока. Список кандидатов AMVP IBC состоит из пространственных кандидатов и кандидатов HMVP.

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

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

На фиг.5B показана блок-схема, иллюстрирующая многопоточное кодирование множества строк CTU изображения с использованием параллельной обработки волнового фронта (WPP) в соответствии с некоторыми реализациями настоящего раскрытия. Когда WPP включен, можно параллельно обрабатывать несколько строк CTU в режиме волнового фронта, где может быть задержка в две CTU между началом двух соседних волновых фронтов. Например, чтобы кодировать изображение 500 с использованием WPP, видеокодер, такой как видеокодер 20 и видеодекодер 30, может разделить единицы дерева кодирования (CTU) изображения 500 на множество волновых фронтов, причем каждый волновой фронт соответствует соответствующей строке CTU на изображении. Видеокодер может начать кодирование верхнего волнового фронта, например, с использованием первого ядра или потока кодера. После того, как видеокодер закодировал две или более CTU верхнего волнового фронта, видеокодер может начать кодирование второго волнового фронта параллельно с кодированием верхнего волнового фронта, например, с использованием второго параллельного ядра или потока кодера. После того, как видеокодер закодировал две или более CTU от второго до верхнего волнового фронта, видеокодер может начать кодирование волнового фронта от третьего до верхнего волнового фронта параллельно с кодированием более высоких волновых фронтов, например, используя третье, параллельное ядро или поток кодера. Этот шаблон может продолжить вниз волновые фронты на изображении 500. В настоящем раскрытии набор блоков CTU, которые видеокодер одновременно кодирует с использованием WPP, называется "группой CTU". Таким образом, когда видеокодер использует WPP для кодирования изображения, каждая CTU из группы CTU может принадлежать уникальному волновому фронту изображения, и CTU может быть смещена относительно CTU в соответствующем, расположенном выше волновом фронте по меньшей мере на два столбца CTU изображения.

Видеокодер может инициировать контекст для текущего волнового фронта для выполнения контекстно-адаптивного двоичного арифметического кодирования (CABAC) текущего волнового фронта на основе данных первых двух блоков вышеуказанного волнового фронта, а также одного или более элементов заголовка слайса для слайса, включающего в себя первый кодовый блок текущего волнового фронта. Видеокодер может выполнять инициирование CABAC последующего волнового фронта (или строки CTU) с использованием состояний контекста после кодирования двух CTU из строки CTU выше следующей строкой CTU. Другими словами, перед началом кодирования текущего волнового фронта видеокодер (или, более конкретно, поток видеокодера) может кодировать по меньшей мере два блока волнового фронта выше текущего волнового фронта, предполагая, что текущий волновой фронт не является верхней строкой CTU изображения. Затем видеокодер может инициировать контекст CABAC для текущего волнового фронта после кодирования по меньшей мере двух блоков волнового фронта выше текущего волнового фронта. В этом примере каждая строка CTU изображения 500 является отдельным разбиением и имеет ассоциированный поток (поток 1 WPP, поток 2 WPP,…), поэтому количество строк CTU в изображении 500 можно кодировать параллельно.

Так как в текущей реализации таблицы HMVP используется буфер глобального вектора движения (MV) для хранения ранее восстановленных векторов движения, эта таблица HMVP не может быть реализована в схеме параллельного кодирования с включенной функцией WPP, описанной выше со ссылкой на фиг.5B. В частности, тот факт, что глобальный буфер MV совместно используется всеми потоками процесса кодирования/декодирования видеокодера, предотвращается запуск потоков WPP после первого потока WPP (то есть потока 1 WPP), так как эти потоки WPP должны дождаться завершения обновления таблицы HMVP из последней CTU (то есть крайней правой CTU) первого потока WPP (то есть первой строки CTU).

Чтобы решить эту проблему, предлагается заменить глобальный буфер MV, совместно используемый потоками WPP, на несколько буферов, выделенных для строк CTU, таким образом, чтобы каждый волновой фронт строки CTU имел свой собственный буфер для хранения таблицы HMVP, соответствующей строке CTU, обрабатываемой соответствующим потоком WPP, когда WPP включен в видеокодер. Следует отметить, что каждая строка CTU, имеющая свою собственную таблицу HMVP, эквивалентна сбросу таблицы HMVP перед кодированием первой CU строки CTU. Сброс таблицы HMVP предназначен для удаления всех векторов движения в таблице HMVP, полученных в результате кодирования другой строки CTU. В одной реализации операция сброса состоит в том, чтобы установить размер доступных предикторов векторов движения в таблице HMVP на нуль. В еще одной реализации операции сброса могут заключаться в установке опорного индекса всех записей в таблице HMVP на недопустимое значение, такое как -1. Таким образом, создание списка кандидатов MVP для текущей CTU в конкретном волновом фронте, независимо от того, какой из трех режимов (режим AMVP, режим слияния и режим пропуска) зависит от таблицы HMVP, ассоциированной с потоком WPP, обрабатывающим конкретный волновой фронт. Между разными волновыми фронтами нет никакой взаимозависимости, кроме задержки с двумя CTU, описанной выше, и построение списков кандидатов векторов движения, связанных с разными волновыми фронтами, может происходить параллельно, как процесс WPP, изображенный на фиг.5B. Другими словами, в начале обработки конкретного волнового фронта таблица HMVP сбрасывается и становится пустой, не влияя на кодирование другого волнового фронта CTU другим потоком WPP. В некоторых случаях таблицу HMVP можно сбросить таким образом, чтобы она стала пустой перед кодированием каждого отдельного CTU. В этом случае векторы движения в таблице HMVP ограничены определенной CTU, и, вероятно, существует более высокая вероятность того, что вектор движения в таблице HMVP будет выбран в качестве вектора движения текущей CU в конкретной CTU.

На фиг.6 показана блок-схема, иллюстрирующая примерный процесс, посредством которого видеокодер, такой как видеокодер 20 или видеодекодер 30, реализует способы построения списка предикторов векторов-кандидатов движения с использованием по меньшей мере таблицы HMVP в соответствии с некоторыми реализациями настоящего раскрытия. В иллюстративных целях блок-схема изображает процесс декодирования видео. Сначала видеодекодер 30 получает (610) кодированный битовый поток видео, включающий в себя данные, ассоциированные с множеством кодированных изображений. Как показано на фиг.4A и 4C, каждое изображение включает в себя несколько строк единиц дерева кодирования (CTU), и каждая CTU включает в себя одну или более единиц кодирования (CU). Видеодекодер 30 извлекает различные части информации из битового потока видео, такие как синтаксические элементы и значения пикселей, для построчного восстановления.

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

При декодировании текущей строки CTU (630) видеодекодер 30 поддерживает (630-1) множество предикторов векторов движения в таблице HMVP. Как отмечено выше, каждый предиктор вектора движения, хранящийся в таблице HMVP, использовался для декодирования по меньшей мере другой CU в текущей строке CTU. Тот факт, что предиктор вектора движения присутствует в таблице HMVP, объясняется тем, что он может снова использоваться для прогнозирования другой CU в текущей строке CTU, когда таблица HMVP участвует в процессе построения списка векторов-кандидатов движения, как описано выше.

Для текущей CU текущей строки CTU видеодекодер 30 сначала извлекает (630-3) режим прогнозирования из битового потока видео. Как отмечено выше, CU может иметь несколько типов режимов прогнозирования, включая режим усовершенствованного прогнозирования вектора движения (AMVP), режим слияния, режим пропуска, режим AMVP IBC и режим слияния IBC. Как только видеокодер 20 выберет подходящий режим прогнозирования для CU, выбранный режим прогнозирования сигнализируется в битовом потоке. Как отмечено выше, существуют разные наборы этапов, исполняемых в разном порядке для построения списка векторов-кандидатов движения. В данном документе видеодекодер 30 создает (630-5) список векторов-кандидатов движения в соответствии с режимом прогнозирования и на основе, по меньшей мере частично, множества средств прогнозирования вектора движения в таблице HMVP. Другие источники, из которых список векторов-кандидатов движения включает в себя предикторы вектора движения из пространственно соседних CU и/или совместно расположенных во времени CU текущей CU (когда режимом прогнозирования является один из режима AMVP, режима AMVP IBC и режима слияния IBC) и, возможно, парные предикторы вектора движения (когда режимом прогнозирования является один из режима слияния и режима пропуска). При необходимости, когда список векторов-кандидатов движения не достигает заданной длины, в список векторов-кандидатов движения могут быть добавлены один или более предикторов векторов движения с нулевым значением.

Затем видеодекодер 30 выбирает (630-7) из списка векторов-кандидатов движения предиктор вектора движения для текущей CU и определяет (630-9) вектор движения на основе, по меньшей мере частично, режима прогнозирования и выбранного предиктора вектора движения. Как отмечено выше, в зависимости от того, является или нет режим прогнозирования режимом AMVP, выбранный предиктор вектора движения может быть оценен или не может быть оценен вектором движения для текущей CU. Например, если режимом прогнозирования является режим AMVP, оцененный вектор движения определяется путем добавления разности векторов движения, восстановленных из битового потока, к выбранному предиктору вектора движения, и текущая CU затем декодируется с использованием, по меньшей мере частично, оцененного вектора движения и соответствующей CU в качестве опорного изображения. Но если режимом прогнозирования является режим слияния или режим пропуска, выбранный предиктор вектора движения является уже оцененным вектором движения, который может быть использован для декодирования текущей CU вместе с соответствующей CU в пределах опорного изображения. Наконец, видеодекодер 30 обновляет (630-11) таблицу HMVP на основе определенного вектора движения. Как отмечалось выше, каждый элемент в таблице HMVP ранее использовался для декодирования по меньшей мере другой CU и сохраняется в таблице HMVP для построения списка векторов-кандидатов движения до тех пор, пока он не будет удален из таблицы HMVP либо путем сброса таблицы, либо путем вставки вектора движения, используемого для декодирования другой последующей CU в текущей строке CTU.

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

Как отмечено выше, две или более из нескольких строк CTU могут кодироваться/декодироваться параллельно, например, с использованием WPP, причем каждая строка CTU имеет ассоциированную таблицу HMVP для хранения множества используемых предикторов векторов движения на основе истории для кодирования/декодирования соответствующей строки CTU. Например, поток назначается для декодирования конкретной строки CTU текущего декодируемого изображения, так что разные строки CTU имеют разные ассоциированные потоки и могут декодироваться параллельно, как описано выше со ссылкой на фиг.5B. В некоторых примерах видеодекодер 30 определяет один или более предикторов векторов движения в списке векторов-кандидатов движения как избыточные и удаляет их из списка векторов-кандидатов движения, чтобы дополнительно повысить эффективность кодирования.

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

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

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

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

Изобретение относится к кодированию и декодированию видеоданных и, в частности, к способу и системе кодирования видео с использованием прогнозирования вектора движения на основе истории. Техническим результатом является повышение эффективности кодирования/декодирования видеоданных, сохраняя при этом качество изображения декодированных видеоданных. Предложено вычислительное устройство, которое выполняет способ декодирования видеоданных путем получения битового потока видео, включающего в себя данные, ассоциированные с множеством кодированных изображений, причем каждое изображение включает в себя множество строк единиц дерева кодирования (CTU), и каждая CTU включает в себя одну или более единиц кодирования (CU). Буфер данных, хранящий множество предикторов векторов движения на основе истории, используется для кодирования строк CTU, и процесс декодирования сбрасывает буфер перед декодированием первого CU текущей строки CTU. Для текущей CU строки CTU список векторов-кандидатов движения строится на основе использования пространственной и временной корреляции векторов движения соседних кодовых единиц, а также предикторов векторов движения на основе истории в буфере. Из списка векторов-кандидатов движения выбирается один предиктор вектора движения для декодирования текущей CU, и буфер обновляется на основе выбранного предиктора вектора движения. 3 н. и 24 з.п. ф-лы, 10 ил.

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

получают битовый поток видео, включающий в себя данные, ассоциированные с множеством кодированных изображений, причем каждое изображение включает в себя множество строк единиц дерева кодирования (CTU) и каждая CTU включает в себя одну или более единиц кодирования (CU);

сбрасывают таблицы предиктора вектора движения на основе истории (HMVP) перед декодированием первой CU текущей строки CTU декодируемого текущего изображения;

при декодировании текущей строки CTU:

поддерживают множество предикторов векторов движения в таблице HMVP, причем каждый предиктор вектора движения в таблице HMVP используется для декодирования по меньшей мере одной CU текущей строки CTU;

для текущей CU текущей строки CTU, подлежащей декодированию:

извлекают режим прогнозирования из битового потока видео;

создают список векторов-кандидатов движения в соответствии с режимом прогнозирования и на основе, по меньшей мере частично, множества предикторов векторов движения в таблице HMVP;

выбирают из списка векторов-кандидатов движения предиктор вектора движения;

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

обновляют таблицу HMVP на основе определенного вектора движения.

2. Способ по п.1, в котором этап обновления таблицы HMVP на основе определенного вектора движения дополнительно содержит этапы, на которых:

сравнивают множество предикторов векторов движения в таблице HMVP с определенным вектором движения;

в соответствии с определением того, что ни один из множества предикторов векторов движения в таблице HMVP не идентичен определенному вектору движения:

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

добавляют определенный вектор движения в качестве самого нового в таблицу HMVP;

в соответствии с определением того, что один из множества предикторов векторов движения в таблице HMVP идентичен определенному вектору движения:

удаляют один идентичный предиктор вектора движения из таблицы HMVP;

перемещают каждый из предикторов векторов движения после удаленного предиктора вектора движения вперед в таблице HMVP;

добавляют определенный вектор движения в качестве самого нового в таблицу HMVP.

3. Способ по п.1, в котором этап сброса таблицы HMVP содержит подэтап, на котором: устанавливают количество доступных предикторов векторов движения в таблице HMVP в ноль.

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

5. Способ по п.4, в котором режим прогнозирования является одним из режима внешнего кодирования, режима внешнего IBC и режима слияния IBC, а этап декодирования текущей CU дополнительно содержит этапы, на которых:

восстанавливают из битового потока видео разность векторов движения для текущей CU;

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

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

6. Способ по п.4, в котором режим прогнозирования является одним из режима внешнего копирования, режима внешнего IBC и режима слияния IBC, а этап создания списка векторов-кандидатов движения дополнительно содержит этапы, на которых:

добавляют от нуля или более предикторов векторов движения из пространственно соседних CU и/или совместно расположенных во времени CU текущей CU в список векторов-кандидатов движения;

добавляют от нуля или более предикторов векторов движения на основе истории из таблицы HMVP в список векторов-кандидатов движения, пока текущая длина списка векторов-кандидатов движения не достигнет первого заданного порогового значения; и

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

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

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

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

8. Способ по п.4, в котором режим прогнозирования является одним из режима слияния и режима пропуска, а этап создания списка векторов-кандидатов движения дополнительно содержит этапы, на которых:

добавляют от нуля или более предикторов векторов движения из пространственно соседних CU и/или совместно расположенных во времени CU текущей CU в список векторов-кандидатов движения;

добавляют от нуля или более предикторов векторов движения на основе истории из таблицы HMVP в список векторов-кандидатов движения, пока текущая длина списка векторов-кандидатов движения не достигнет второго заданного порогового значения;

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

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

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

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

11. Способ по п.1, дополнительно содержащий этап, на котором:

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

12. Вычислительное устройство, содержащее:

один или более процессоров;

память, соединенную с одним или более процессорами; и

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

получение битового потока видео, включающего в себя данные, ассоциированные с множеством кодированных изображений, причем каждое изображение включает в себя множества строк единиц дерева кодирования (CTU), а каждая CTU включает в себя одну или более единиц кодирования (CU);

сброс таблицы предиктора вектора движения на основе истории (HMVP) перед декодированием первой CU текущей строки CTU декодируемого текущего изображения;

при декодировании текущей строки CTU:

поддержание множества предикторов векторов движения в таблице HMVP, причем каждый предиктор вектора движения в таблице HMVP используется для декодирования по меньшей мере одной CU текущей строки CTU;

для текущей CU текущей строки CTU, подлежащей декодированию:

извлечение режима прогнозирования из битового потока видео;

создание списка векторов-кандидатов движения в соответствии с режимом прогнозирования и на основе, по меньшей мере частично, множества предикторов векторов движения в таблице HMVP;

выбор из списка векторов-кандидатов движения предиктора вектора движения;

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

обновление таблицы HMVP на основе определенного вектора движения.

13. Вычислительное устройство по п.12, в котором обновление таблицы HMVP на основе определенного вектора движения дополнительно содержит:

сравнение множества предикторов векторов движения в таблице HMVP с определенным вектором движения;

в соответствии с определением, что ни один из множества предикторов векторов движения в таблице HMVP не идентичен определенному вектору движения:

удаление самого раннего предиктора вектора движения из таблицы HMVP, когда таблица HMVP заполнена; и

добавление определенного вектора движения в качестве самого нового в таблицу HMVP;

в соответствии с определением того, что один из множества предикторов векторов движения в таблице HMVP идентичен определенному вектору движения:

удаление одного идентичного предиктора вектора движения из таблицы HMVP;

перемещение каждого из предикторов векторов движения после удаленного предиктора вектора движения вперед в таблице HMVP;

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

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

15. Вычислительное устройство по п.14, в котором режим кодирования является одним из режима внешнего кодирования, режима внешнего внутриблочного кодирования (IBC) и режима слияния IBC, при этом декодирование текущей CU дополнительно содержит:

восстановление из битового потока видео разности векторов движения для текущей CU;

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

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

16. Вычислительное устройство по п.14, в котором режим прогнозирования является одним из режима внешнего кодирования, режима внешнего IBC и режима слияния IBC, при этом построение списка векторов-кандидатов движения дополнительно содержит:

добавление от нуля или более предикторов векторов движения из пространственно соседних CU и/или совместно расположенных во времени CU текущей CU в список векторов-кандидатов движения;

добавление от нуля или более предикторов векторов движения на основе истории из таблицы HMVP в список векторов-кандидатов движения, пока текущая длина списка векторов-кандидатов движения не достигнет первого заданного порогового значения; и

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

17. Вычислительное устройство по п.14, в котором режим прогнозирования является одним из режима слияния и режима пропуска, при этом декодирование текущей CU дополнительно содержит:

использование выбранного предиктора вектора движения в качестве определенного вектора движения; и

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

18. Вычислительное устройство по п.14, в котором режим прогнозирования является одним из режима слияния и режима пропуска, при этом создание списка векторов-кандидатов движения дополнительно содержит:

добавление от нуля или более предикторов векторов движения из пространственно соседних CU и/или совместно расположенных во времени CU текущей CU в список векторов-кандидатов движения;

добавление от нуля или более предикторов векторов движения на основе истории из таблицы HMVP в список векторов-кандидатов движения, пока текущая длина списка векторов-кандидатов движения не достигнет второго заданного порогового значения;

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

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

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

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

получение битового потока видео, включающего в себя данные, ассоциированные с множеством кодированных изображений, причем каждое изображение включает в себя множества строк единиц дерева кодирования (CTU), а каждая CTU включает в себя одну или более единиц кодирования (CU);

сброс таблицы предиктора вектора движения на основе истории (HMVP) перед декодированием первой CU текущей строки CTU декодируемого текущего изображения;

при декодировании текущей строки CTU:

поддержание множества предикторов векторов движения в таблице HMVP, причем каждый предиктор вектора движения в таблице HMVP используется для декодирования по меньшей мере одной CU текущей строки CTU;

для текущей CU текущей строки CTU, подлежащей декодированию:

извлечение режима прогнозирования из битового потока видео;

создание списка векторов-кандидатов движения в соответствии с режимом прогнозирования и на основе, по меньшей мере частично, множества предикторов векторов движения в таблице HMVP;

выбор из списка векторов-кандидатов движения предиктора вектора движения;

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

обновление таблицы HMVP на основе определенного вектора движения.

21. Энергонезависимый машиночитаемый носитель информации по п.20, в котором обновление таблицы HMVP на основе определенного вектора движения дополнительно содержит:

сравнение множества предикторов векторов движения в таблице HMVP с определенным вектором движения;

в соответствии с определением, что ни один из множества предикторов векторов движения в таблице HMVP не идентичен определенному вектору движения:

удаление самого раннего предиктора вектора движения из таблицы HMVP, когда таблица HMVP заполнена; и

добавление определенного вектора движения в качестве самого нового в таблицу HMVP;

в соответствии с определением, что один из множества предикторов векторов движения в таблице HMVP идентичен определенному вектору движения:

удаление одного идентичного предиктора вектора движения из таблицы HMVP;

перемещение каждого из предикторов векторов движения после удаленного предиктора вектора движения вперед в таблице HMVP;

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

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

23. Энергонезависимый машиночитаемый носитель информации по п.22, в котором режим прогнозирования является одним из режима внешнего предсказания, режима внешнего IBC и режима слияния IBC, причем декодирование текущей CU дополнительно содержит:

восстановление из битового потока видео разности векторов движения для текущей CU;

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

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

24. Энергонезависимый машиночитаемый носитель информации по п.22, в котором режим прогнозирования является одним из режима внешнего кодирования, режима внешнего IBC и режима слияния IBC, причем построение списка векторов-кандидатов движения дополнительно содержит:

добавление от нуля или более предикторов векторов движения из пространственно соседних CU и/или совместно расположенных во времени CU текущей CU в список векторов-кандидатов движения;

добавление от нуля или более предикторов векторов движения на основе истории из таблицы HMVP в список векторов-кандидатов движения, пока текущая длина списка векторов-кандидатов движения не достигнет первого заданного порогового значения; и

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

25. Энергонезависимый машиночитаемый носитель информации по п.22, в котором режим прогнозирования является одним из режима слияния и режима пропуска и декодирование текущей CU дополнительно содержит:

использование выбранного предиктора вектора движения в качестве определенного вектора движения; и

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

26. Энергонезависимый машиночитаемый носитель информации по п.22, в котором режим прогнозирования является одним из режима слияния и режима пропуска, при этом создание списка векторов-кандидатов движения дополнительно содержит:

добавление от нуля или более предикторов векторов движения из пространственно соседних CU и/или совместно расположенных во времени CU текущей CU в список векторов-кандидатов движения;

добавление от нуля или более предикторов векторов движения на основе истории из таблицы HMVP в список векторов-кандидатов движения, пока текущая длина списка векторов-кандидатов движения не достигнет второго заданного порогового значения;

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

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

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