Вибір єдиних кандидатів режиму злиття і адаптивного режиму прогнозування вектора руху
Формула / Реферат
1. Спосіб кодування вектора руху в процесі кодування відео, який включає:
визначення одного з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих, які повинні бути закодовані; і
виконання процесу прогнозування вектора руху для поточного блока відеоданих, використовуючи визначений режим і набір блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів.
причому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху, і
причому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат.
2. Спосіб за п. 1, в якому визначений режим є режимом злиття, і в якому спосіб також включає:
визначення вектора-кандидата руху з набору блоків-кандидатів, який задовольняє поріг "спотворення-швидкість", і
сигналізацію індексу, що ідентифікує вектор-кандидат руху.
3. Спосіб за п. 1, в якому визначеним режимом є адаптивний режим прогнозування вектора руху, і в якому спосіб також включає:
визначення вектора-кандидата руху для кожного блока-кандидата в наборі блоків-кандидатів;
обчислення різниці векторів руху між вектором руху для поточного блока і вектором-кандидатом руху для кожного з блоків-кандидатів згідно з шаблоном перевірки;
вибір одного з векторів-кандидатів руху на основі обчислених різниць вектора руху; і
сигналізацію індексу, що ідентифікує вибраний один з векторів-кандидатів руху, причому різницю векторів руху обчислюють відносно вибраного одного з векторів-кандидатів руху, опорного кадру і напряму прогнозування.
4. Спосіб за п. 3, в якому шаблон перевірки відбувається в порядку, починаючи з лівого блока-кандидата.
5. Спосіб за п. 3, в якому шаблон перевірки відбувається в наступному порядку: від лівого блока-кандидата переходять до нижнього лівого блока-кандидата, від верхнього блока-кандидата переходять до правого верхнього блока-кандидата.
6. Спосіб за п. 3, в якому шаблон перевірки відбувається в наступному порядку: лівий блок-кандидат, нижній лівий блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий верхній блок-кандидат, часовий блок-кандидат.
7. Пристрій, сконфігурований, щоб кодувати вектор руху в процесі кодування відео, який містить:
відеокодер, сконфігурований щоб:
визначати один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих, які повинні бути закодовані; і
виконувати процес прогнозування вектора руху для поточного блока відеоданих, використовуючи визначений режим і набір блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів,
при цьому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху, і
при цьому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат.
8. Пристрій за п. 7, в якому визначений режим є режимом злиття, і в якому відеокодер додатково сконфігурований щоб:
визначати вектор-кандидат руху з набору блоків-кандидатів, який задовольняє поріг "спотворення-швидкість"; і
сигналізувати індекс, що ідентифікує вектор-кандидат руху.
9. Пристрій за п. 7, в якому визначений режимом є адаптивний режим прогнозування вектора руху, і в якому відеокодер додатково сконфігурований, щоб:
визначати вектор-кандидат руху для кожного блока-кандидата в наборі блоків-кандидатів;
обчислювати різницю векторів руху між вектором руху для поточного блока і вектором-кандидатом руху для кожного з блоків-кандидатів згідно з шаблоном перевірки;
вибирати один з векторів-кандидатів руху на основі обчислених різниць вектора руху; і
сигналізувати індекс, що ідентифікує вибраний один з векторів-кандидатів руху, причому різниця векторів руху обчислена відносно вибраного одного з векторів-кандидатів руху, опорного кадру і напряму прогнозування.
10. Пристрій за п. 9, в якому шаблон перевірки відбувається в порядку, починаючи з лівого блока-кандидата.
11. Пристрій за п. 9, в якому шаблон перевірки відбувається в наступному порядку: від лівого блока-кандидата переходять до нижнього лівого блока-кандидата, від верхнього блока-кандидата переходять до правого верхнього блока-кандидата.
12. Пристрій за п. 9, в якому шаблон перевірки відбувається в наступному порядку: лівий блок-кандидат, нижній лівий блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий верхній блок-кандидат, часовий блок-кандидат.
13. Пристрій, сконфігурований, щоб кодувати вектор руху в процесі кодування відео, який містить:
засіб для того, щоб визначити один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих, які повинні бути закодовані; і
засіб для того, щоб виконати процес прогнозування вектора руху для поточного блока відеоданих, використовуючи визначений режим і набір блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів,
при цьому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху, і
при цьому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат.
14. Зчитуваний комп'ютером носій даних, що зберігає інструкції, які, коли виконуються, змушують процесор пристрою для кодування відеоданих:
визначати один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих, які повинні бути закодовані; і
виконувати процес прогнозування вектора руху для поточного блока відеоданих, використовуючи визначений режим і набір блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів,
при цьому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху, і
при цьому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат.
15. Спосіб декодування вектора руху в процесі кодування відео, який включає:
визначення одного з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих; і
визначення блока-кандидата з набору блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів, і в якому інформація, асоційована з блоком-кандидатом, використовується, щоб декодувати вектор руху для поточного блока,
при цьому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху, і
при цьому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат.
16. Спосіб за п. 15, який додатково включає:
прийом елемента синтаксису, що вказує процес прогнозування вектора руху, в якому прийнятий елемент синтаксису вказує, що процес прогнозування вектора руху є режимом злиття;
прийом індексу, що вказує блок-кандидат;
витягання вектора руху, опорного кадру і напряму прогнозування, асоційованих з блоком-кандидатом, що має прийнятий індекс; і
виконання процесу зовнішнього прогнозування відносно поточного блока, використовуючи витягнуті вектор руху, опорний кадр і напрям прогнозування.
17. Спосіб за п. 15, який додатково включає:
прийом елемента синтаксису, що вказує процес прогнозування вектора руху, в якому прийнятий елемент синтаксису вказує, що процес прогнозування вектора руху є адаптивним режимом прогнозування вектора руху;
прийом індексу, що вказує блок-кандидат;
прийом індексу опорного кадру, різниці векторів руху і елемента синтаксису, що вказує напрям прогнозування;
витягання вектора-кандидата руху, асоційованого з блоком-кандидатом, що має прийнятий індекс;
обчислення вектора руху для поточного блока, використовуючи вектор-кандидат руху і різницю векторів руху; і
виконання процесу зовнішнього прогнозування, використовуючи обчислений вектор руху, прийнятий індекс опорного кадру і прийнятий напрям прогнозування.
18. Спосіб за п. 17, в якому шаблон перевірки відбувається в порядку, починаючи з лівого блока-кандидата.
19. Спосіб за п. 17, в якому шаблон перевірки відбувається в наступному порядку: від лівого блока-кандидата переходять до нижнього лівого блока-кандидата, від верхнього блока-кандидата переходять до правого верхнього блока-кандидата.
20. Спосіб за п. 17, в якому шаблон перевірки відбувається в наступному порядку: лівий блок-кандидат, нижній лівий блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий верхній блок-кандидат, часовий блок-кандидат.
21. Пристрій, сконфігурований, щоб декодувати вектор руху в процесі кодування відео, який містить:
відеодекодер, сконфігурований щоб:
визначати один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих; і
визначати блок-кандидат з набору блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів, і при цьому інформація, асоційована з блоком-кандидатом, використовується, щоб декодувати вектор руху для поточного блока,
при цьому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху,
при цьому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат.
22. Пристрій за п. 21, в якому відеодекодер додатково сконфігурований щоб:
прийняти елемент синтаксису, що вказує процес прогнозування вектора руху, при цьому прийнятий елемент синтаксису вказує, що процес прогнозування вектора руху є режимом злиття;
прийняти індекс, що вказує блок-кандидат;
витягнути вектор руху, опорний кадр і напрям прогнозування, асоційовані з блоком-кандидатом, що має прийнятий індекс; і
виконувати процес зовнішнього прогнозування відносно поточного блока, використовуючи витягнуті вектор руху, опорний кадр і напрям прогнозування.
23. Пристрій за п. 21, в якому відеодекодер додатково сконфігурований щоб:
прийняти елемент синтаксису, що вказує процес прогнозування вектора руху, в якому прийнятий елемент синтаксису вказує, що процес прогнозування вектора руху є адаптивним режимом прогнозування вектора руху;
прийняти індекс, що вказує блок-кандидат;
прийняти індекс опорного кадру, різницю векторів руху і елемент синтаксису, що вказує напрям прогнозування;
витягнути вектор-кандидат руху, асоційований з блоком-кандидатом, що має прийнятий індекс;
обчислювати вектор руху для поточного блока, використовуючи вектор-кандидат руху і різницю векторів руху; і
виконувати процес зовнішнього прогнозування, використовуючи обчислений вектор руху, прийнятий індекс опорного кадру і прийнятий напрям прогнозування.
24. Пристрій за п. 23, в якому шаблон перевірки відбувається в порядку, починаючи з лівого блока-кандидата.
25. Пристрій за п. 23, в якому шаблон перевірки відбувається в наступному порядку: від лівого блока-кандидата переходять до нижнього лівого блока-кандидата, від верхнього блока-кандидата переходять до правого верхнього блока-кандидата.
26. Пристрій за п. 23, в якому шаблон перевірки відбувається в наступному порядку: лівий блок-кандидат, нижній лівий блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий верхній блок-кандидат, часовий блок-кандидат.
27. Пристрій, сконфігурований, щоб декодувати вектор руху в процесі кодування відео, який містить:
засіб для того, щоб визначити один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих; і
засіб для того, щоб визначити блок-кандидат з набору блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів, і при цьому інформація, асоційована з блоком-кандидатом, використовується, щоб декодувати вектор руху для поточного блока,
при цьому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху,
при цьому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат.
28. Зчитуваний комп'ютером носій даних, що зберігає інструкції, які, коли виконуються, змушують процесор пристрою для декодування відеоданих:
визначати один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих; і
визначати блок-кандидат з набору блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів, і в якому інформація, асоційована з блоком-кандидатом, використовується, щоб декодувати вектор руху для поточного блока,
при цьому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху,
при цьому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат.
Текст
Реферат: Запропонований об'єднаний набір блоків-кандидатів і для режиму адаптивного прогнозування вектора руху (AMVP), і для режиму злиття для використання у зовнішньому прогнозуванні. Загалом, один і той же набір блоків-кандидатів використовується незалежно від того, який використовуються режим прогнозування вектора руху (наприклад, режим злиття або режим AMVP). У інших прикладах цього розкриття один блок-кандидат в наборі блоків-кандидатів визначається як додатковий блок-кандидат. Додатковий блок-кандидат використовується, якщо один з інших блоків-кандидатів недоступний. Крім того, розкриття пропонує шаблон перевірки, де лівий блок-кандидат перевіряється перед нижнім лівим блоком-кандидатом. Крім того, верхній блок-кандидат перевіряється перед правим верхнім блоком-кандидатом. UA 111971 C2 (12) UA 111971 C2 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 Ця заявка вимагає пріоритет попередньої заявки на патент США № 61/506,558, поданої 11 липня 2011 р., попередньої заявки на патент США № 61/499,114, поданої 20 червня 2011 р., і попередньої заявки на патент США № 61/509,007, поданої 18 липня 2011 р., всі з яких тим самим включені в даний опис по посиланню у всій їх повноті. ГАЛУЗЬ ТЕХНІКИ Дане розкриття стосується кодування відео і, більш конкретно, способів для вибору блоківкандидатів прогнозування вектора руху в процесі прогнозування вектора руху. РІВЕНЬ ТЕХНІКИ Цифрові можливості відео можуть бути включені в широкий діапазон пристроїв, включаючи цифрові телевізори, цифрові системи прямого мовлення, бездротові системи мовлення, персональні цифрові помічники (PDAs), портативні або настільні комп'ютери, цифрові камери, цифрові пристрої запису, цифрові медіаплеєри, відеоігрові пристрої, пульти відеоігор, стільникові або супутникові радіотелефони, пристрої організації відеотелеконференцій і т. п. Цифрові відеопристрої реалізовують способи стиснення відео, такі, як описані в стандартах, визначених MPEG-2, MPEG-4, ITU-T H.264/MPEG-4, Part 10, Advanced Video Coding (AVC), стандарті високоефективного кодування відео (HEVC), що розвивається на даний час, і розширеннях таких стандартів, щоб передавати, приймати і зберігати цифрову відеоінформацію більш ефективно. Способи стиснення відео виконують просторове (всередині картинки) прогнозування і/або часове (між картинками) прогнозування, щоб зменшити або видалити надмірність, властиву відеопослідовностям. Для основаного на блоках кодування відео кадр відео або вирізка можуть бути розділені на блоки. Кожний блок може бути далі розділений. Відеоблоки у внутрішньокодованій (I) вирізці картинки кодують, використовуючи просторове прогнозування відносно опорних вибірок в сусідніх блоках в тому ж самому кадрі або вирізці. Блоки у зовнішньокодованому (Р або В) кадрі або вирізці можуть використовувати просторове прогнозування відносно опорних вибірок в сусідніх блоках в тому ж самому кадрі або вирізці або часове прогнозування відносно опорних вибірок в інших опорних кадрах. Просторове або часове прогнозування приводить до прогнозуючого блока для блока, який повинен бути кодований. Залишкові дані представляють пікселні різниці між первинним блоком, який повинен бути закодований, і прогнозуючим блоком. Зовнішньокодований блок кодують згідно з вектором руху, який вказує на блок опорних вибірок, що формують прогнозуючий блок, і залишковими даними, що вказують різницю між кодованим блоком і прогнозуючим блоком. Внутрішньокодований блок кодують згідно з режимом внутрішнього кодування і залишковими даними. Для подальшого стиснення залишкові дані можуть бути перетворені з пікселної області в область перетворення, приводячи до залишкових коефіцієнтів перетворення, які потім можуть квантуватися. Квантовані коефіцієнти перетворення, спочатку розміщені в двовимірному масиві, можуть бути скановані в конкретному порядку, щоб сформувати одновимірний вектор коефіцієнтів перетворення для ентропійного кодування. СУТЬ ВИНАХОДУ Загалом дане розкриття описує способи для кодування відеоданих. Дане розкриття описує способи для вибору блоків-кандидатів прогнозування вектора руху в процесі прогнозування вектора руху. У одному прикладі розкриття спосіб кодування вектора руху в процесі кодування відео включає визначення одного з множини режимів для процесу прогнозування вектора руху і виконання процесу прогнозування вектора руху для поточного блока відеоданих, використовуючи визначений режим і набір блоків-кандидатів, в якому набір блоків-кандидатів є одним і тим же для кожного з множини режимів. У іншому прикладі розкриття спосіб декодування вектора руху в процесі кодування відео включає визначення одного з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих і визначення блока-кандидата з набору блоків-кандидатів, в якому набір блоків-кандидатів є однаковим для кожного з множини режимів, і в якому інформація, асоційована з блоком-кандидатом, використовується, щоб декодувати вектор руху для поточного блока. У іншому прикладі розкриття спосіб кодування вектора руху в процесі кодування відео включає визначення одного з множини режимів для процесу прогнозування вектора руху і виконання процесу прогнозування вектора руху для поточного блока відеоданих, використовуючи визначений режим і набір блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів, в якому один блок-кандидат в наборі блоків 1 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 60 кандидатів визначається як додатковий блок-кандидат, і в якому додатковий блок-кандидат використовується, якщо інший з блоків-кандидатів набору блоків-кандидатів недоступний. У іншому прикладі розкриття спосіб декодування вектора руху в процесі кодування відео включає прийом елемента синтаксису, що вказує один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих, і прийом індексу, що вказує блоккандидат з набору блоків-кандидатів, в якому набір блоків-кандидатів є однаковим для кожного з множини режимів, в якому один блок-кандидат в наборі блоків-кандидатів визначається як додатковий блок-кандидат, в якому цей додатковий блок-кандидат використовується, якщо інший з блоків-кандидатів набору блоків-кандидатів недоступний, і в якому інформація, асоційована з блоком-кандидатом, використовується, щоб декодувати вектор руху для поточного блока. Деталі одного або більше прикладів сформульовані в супроводжуючих кресленнях і описі нижче. Інші ознаки, об'єкти і переваги будуть очевидні з опису і креслень і з формули винаходу. КОРОТКИЙ ОПИС КРЕСЛЕНЬ Фіг. 1A є концептуальним кресленням, що ілюструє блоки-кандидати для прогнозування вектора руху згідно з режимом адаптивного прогнозування вектора руху (AMVP). Фіг. 1B є концептуальним кресленням, що ілюструє блоки-кандидати для прогнозування вектора руху згідно з режимом злиття. Фіг. 2 є блок-схемою, що ілюструє зразкову систему кодування і декодування відео. Фіг. 3 є блок-схемою, що ілюструє зразковий кодер відео. Фіг. 4A є концептуальним кресленням інформації сигналізації для режиму злиття. Фіг. 4B є концептуальним кресленням інформації сигналізації для режиму AMVP. Фіг. 5A є концептуальним кресленням, що ілюструє блоки-кандидати для AMVP і режиму злиття відповідно до одного прикладу розкриття. Фіг. 5B є концептуальним кресленням, що ілюструє блоки-кандидати для AMVP і режиму злиття відповідно до іншого прикладу розкриття. Фіг. 6 є концептуальним кресленням, що ілюструє блоки-кандидати для AMVP і режиму злиття відповідно до іншого прикладу розкриття. Фіг. 7 є концептуальним кресленням, що ілюструє блоки-кандидати і шаблон перевірки для AMVP і режиму злиття відповідно до іншого прикладу розкриття. Фіг. 8 є блок-схемою, що ілюструє зразковий декодер відео. Фіг. 9 є послідовністю операцій, що ілюструє зразковий спосіб кодування відео. Фіг. 10 є послідовністю операцій, що ілюструє зразковий спосіб кодування відео в режимі злиття. Фіг. 11 є послідовністю операцій, що ілюструє зразковий спосіб кодування відео в режимі AMVP. Фіг. 12 є послідовністю операцій, що ілюструє зразковий спосіб декодування відео. Фіг. 13 є послідовністю операцій, що ілюструє зразковий спосіб декодування відео в режимі злиття. Фіг. 14 є послідовністю операцій, що ілюструє зразковий спосіб декодування відео в режимі AMVP. Фіг. 15 є послідовністю операцій, що ілюструє інший зразковий спосіб кодування відео. Фіг. 16 є послідовністю операцій, що ілюструє інший зразковий спосіб декодування відео. Фіг. 17 є послідовністю операцій, що ілюструє інший зразковий спосіб декодування відео в режимі злиття. Фіг. 18 є послідовністю операцій, що ілюструє інший зразковий спосіб декодування відео в режимі AMVP. ДЕТАЛЬНИЙ ОПИС Загалом дане розкриття описує способи для кодування відеоданих. Дане розкриття описує способи для вибору блоків-кандидатів прогнозування вектора руху в процесі прогнозування вектора руху. У одному прикладі дане розкриття пропонує, щоб кожний з множини режимів прогнозування вектора руху використовував один і той же набір блоків-кандидатів, щоб прогнозувати вектор руху для поточного блока. У іншому прикладі дане розкриття пропонує, щоб один блок-кандидат в наборі блоків-кандидатів визначався як додатковий блок-кандидат. Цей додатковий блок-кандидат використовується, якщо інший один з блоків в наборі недоступний. Цифрові відеопристрої реалізовують способи стиснення відео, щоб кодувати і декодувати цифрову відеоінформацію більш ефективно. Стиснення відео може застосовувати способи прогнозування з просторовим (внутрішньокадровим) і/або часовим (міжкадровим) прогнозуванням, щоб зменшити або видалити надмірність, властиву відеопослідовностям. 2 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 60 Для кодування відео згідно зі стандартом високоефективного кодування відео (HEVC), що на даний час розвивається об'єднаною спільною командою для кодування відео (JCT-VC), відеокадр може бути розділений на одиниці кодування. Одиниця кодування (CU) звичайно належить до області зображення, яка служить базовою одиницею, до якої різні інструменти кодування застосовуються для стиснення відео. CU звичайно має компоненту яскравості, позначену як Y, і дві компоненти кольоровості, позначені як U і V. Залежно від формату дискретизації відео розмір компонент U і V, в термінах кількості вибірок, може бути таким же або відмінним від розміру компоненти Y. CU є типово квадратною, і, як можна вважати, подібна так званому макроблоку, наприклад, в інших стандартах кодування відео, таких як ITU-T H.264. Щоб досягнути кращої ефективності кодування, одиниця кодування може мати змінні розміри залежно від відеоконтенту. Крім того, одиниця кодування може бути розділена на менші блоки для прогнозування або перетворення. Зокрема, кожна одиниця кодування може бути далі розділена на одиниці прогнозування (PUs) і одиниці перетворення (TUs). Одиниці прогнозування можуть розглядатися як аналогічні так званому розділенню в інших стандартах кодування відео, таких як H.264. Одиниці перетворення (TUs) належать до блоків залишкових даних, до яких застосоване перетворення, щоб сформувати коефіцієнти перетворення. Кодування згідно з деякими з на даний час запропонованих аспектів розвитку стандарту HEVC буде описано в цій заявці з метою ілюстрації. Однак, способи, описані в цьому розкритті, можуть бути корисними для інших процесів кодування відео, таких, як визначені згідно з H.264 або іншими стандартними або процесами кодування відео, що складають власність. Зусилля по стандартизації HEVC основані на моделі пристрою кодування відео, званій Тестовою Моделлю HEVC (HM). HM передбачає декілька додаткових можливостей пристроїв кодування відео перед існуючими пристроями згідно, наприклад, з ITU-T H.264/AVC. Наприклад, тоді як H.264 забезпечує дев'ять режимів кодування з внутрішнім прогнозуванням, HM забезпечує цілих тридцять чотири режими кодування з внутрішнім прогнозуванням. Згідно з HM, CU може включати в себе одну або більше одиниць прогнозування (PUs) і/або одну або більше одиниць перетворення (TUs). Дані синтаксису в межах потоку бітів можуть визначати найбільшу одиницю кодування (LCU), яка є найбільшою CU в термінах кількості пікселів. Звичайно, CU має аналогічну макроблоку H.264 мету, за винятком того, що CU не має різниці в розмірах. Таким чином, CU може бути розділена на суб-CUs. Звичайно, посилання в цьому розкритті на CU можуть стосуватися найбільшої одиниці кодування картинки або суб-CU в LCU. LCU може бути розділена на суб-CU, і кожна суб-CU може бути далі розділена на субCU. Дані синтаксису для потоку бітів можуть визначити максимальну кількість разів, скільки LCU може бути розділена, що називається глибиною CU. Відповідно, потік бітів може також визначати найменшу одиницю кодування (SCU). Дане розкриття також використовує термін "блок" або "частина", щоб стосуватися будь-якої з CU, PU або TU. Звичайно, "частина" може стосуватися будь-якого піднабору відеокадру. LCU може бути асоційована зі структурою даних квадродерева. Звичайно структура даних квадродерева включає в себе один вузол для кожної CU, де кореневий вузол відповідає LCU. Якщо CU розділена на чотири суб-CU, вузол, відповідний CU, включає в себе чотири листових (кінцевих) вузли, кожний з яких відповідає одній з суб-CU. Кожний вузол структури даних квадродерева може забезпечити дані синтаксису для відповідної CU. Наприклад, вузол в квадродереві може включати в себе прапор розділення, що вказує, чи розділена CU, відповідна вузлу, на суб-CU. Елементи синтаксису для CU можуть бути визначені рекурсивно і можуть залежати від того, чи розділена CU на суб-CU. Якщо CU не розділена далі, на неї посилаються як на листову (кінцеву) CU. Крім того, одиниці TU листових CU можуть також бути асоційовані з відповідними структурами даних квадродерева. Таким чином, листова CU може включати в себе квадродерево, що вказує, як листова CU розділена на одиниці TU. Дане розкриття стосується квадродерева, що вказує, як LCU розділена як квадродерево CU, і це квадродерево вказує, як листова CU розділена на одиниці TU як квадродерево TU. Кореневий вузол квадродерева TU звичайно відповідає листовій CU, в той час як кореневий вузол квадродерева CU звичайно відповідає LCU. Одиниці TU квадродерева TU, які не розділені, згадуються як листові (кінцеві) TU. Листова CU може включати в себе одну або більше одиниць прогнозування (PU). Звичайно PU представляє всю або частину відповідної CU і може включати в себе дані для того, щоб витягнути опорну вибірку для PU. Наприклад, коли PU є кодованою у зовнішньому режимі, PU може включати в себе дані, що визначають вектор руху для PU. Дані, що визначають вектор руху, можуть описувати, наприклад, горизонтальний компонент вектора руху, вертикальний компонент вектора руху, розрізнення для вектора руху (наприклад, пікселну точність в одну 3 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 60 чверть або пікселну точність в одну восьму), опорний кадр, на який вказує вектор руху і/або опорний список (наприклад, Список 0 або Список 1) для вектора руху. Дані для листової CU, що визначають одиницю(і) PU, можуть також описувати, наприклад, розділення CU на одну або більше PU. Режими розділення можуть відрізнятися залежно від того, чи не є CU кодованою з прогнозуванням, кодованою в режимі внутрішнього прогнозування або кодованою в режимі зовнішнього прогнозування. Для внутрішнього кодування PU може бути оброблена так само, як одиниця перетворення листа, як описано нижче. Щоб закодувати блок (наприклад, одиницю прогнозування (PU) відеоданих), спочатку одержують прогнозувач для блока. Прогнозувач може бути одержаний за допомогою будь-якого із внутрішнього (I) прогнозування (тобто просторове прогнозування) або зовнішнього (Р або В) прогнозування (тобто часове прогнозування). Отже, деякі блоки прогнозування можуть бути внутрішньокодовані (I), використовуючи просторове прогнозування відносно сусідніх опорних блоків в тому ж самому кадрі, і інші блоки прогнозування можуть бути зовнішньокодовані (Р або В) відносно опорних блоків в інших кадрах. Після ідентифікації прогнозувача обчислюють різницю між первинним відеоблоком даних і його прогнозувачем. Ця різниця також називається залишком прогнозування і належить до різниць пікселних значень між пікселами блока, який повинен бути кодований, і відповідними пікселами опорного блока, тобто прогнозувача. Щоб досягнути кращого стиснення, залишок прогнозування (тобто масив значень пікселної різниці) звичайно перетворюють, наприклад, використовуючи дискретне косинусне перетворення (DCT), цілочислове перетворення, перетворення Кархунена-Лоева (Karhunen-Loeve) (K-L) або інше перетворення. Кодування PU з використанням зовнішнього прогнозування використовує обчислення вектора руху між поточним блоком і блоком в опорному кадрі. Вектори руху обчислюють за допомогою процесу, названого оцінкою руху (або пошуком руху). Вектор руху, наприклад, може вказувати зміщення блока прогнозування в поточному кадрі відносно опорної вибірки опорного кадру. Опорна вибірка може бути блоком, який, як знаходять, близько відповідає частині CU, включаючи PU, кодовану в термінах пікселної різниці, яка може бути визначена сумою абсолютних різниць (SAD), сумою різниць квадратів (SSD) або іншими метриками різниці. Опорна вибірка може мати місце де-небудь в межах опорного кадру або опорної вирізки. У деяких прикладах опорна вибірка може мати місце у фракційній позиції піксела. Після виявлення частини опорного кадру, яка найкраще співпадає з поточною частиною, кодер визначає поточний вектор руху для поточної частини як різницю в місцеположенні від поточної частини до співпадаючої частини в опорному кадрі (тобто від центра поточної частини до центра співпадаючої частини). У деяких прикладах кодер може сигналізувати вектор руху для кожної частини в закодованому відеопотоці бітів. Сигналізований вектор руху використовується декодером, щоб виконати компенсацію руху, щоб декодувати відеодані. Однак, сигналізація первинного вектора руху безпосередньо може привести до менш ефективного кодування, оскільки велика кількість бітів звичайно необхідна, щоб передати інформацію. У деяких випадках замість безпосередньої сигналізації первинного вектора руху, кодер може прогнозувати вектор руху для кожного розділення, тобто для кожної PU. При виконанні цього прогнозування вектора руху кодер може вибрати набір векторів-кандидатів руху, визначених з просторово сусідніх блоків в тому ж самому кадрі, що поточна частина, або вектор-кандидат руху, визначений зі спільно розташованого блока в опорному кадрі. Кодер може виконати прогнозування вектора руху і, якщо потрібно, сигналізувати різницю прогнозування, замість того, щоб сигналізувати первинний вектор руху, щоб зменшити частоту проходження бітів в сигналізації. Вектори вектора-кандидата руху з просторово сусідніх блоків можуть називатися як просторові MVP-кандидати, тоді як вектор-кандидат руху зі спільно розташованого блока в іншому опорному кадрі може згадуватися як часовий MVP-кандидат. Два різних режими або типи прогнозування вектора руху запропоновані в поточному робочому проекті стандарту HEVC. Один режим згадується як режим "злиття". Інший режим згадується як адаптивне прогнозування вектора руху (AMVP). У режимі злиття кодер інструктує декодер, за допомогою сигналізації потоку бітів синтаксису прогнозування, скопіювати вектор руху, опорний індекс (ідентифікуючий опорний кадр в заданому списку опорних картинок, на який вектор руху вказує) і напрям прогнозування руху (що ідентифікує список опорних картинок (Список 0 або Список 1), тобто в термінах того, чи передує опорний кадр у часі або іде за поточним кадром) від вибраного вектора-кандидата руху для поточної частини кадру. Це досягається за допомогою сигналізації в потоці бітів індексу в список векторів-кандидатів руху, ідентифікуючий вибраний вектор-кандидат руху (тобто конкретний просторовий MVP-кандидат або часовий MVP-кандидат). Таким чином, для режиму злиття синтаксис прогнозування може 4 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 включати в себе прапор, що ідентифікує режим (в цьому випадку режим "злиття"), і індекс, що ідентифікує вибраний вектор-кандидат руху. У деяких випадках вектор-кандидат руху буде в причинній частині в посиланні на поточну частину. Таким чином, вектор-кандидат руху буде вже декодований декодером. Як такий, декодер вже прийняв і/або визначив вектор руху, опорний індекс і напрям прогнозування руху для причинної частини. Як такий, декодер може просто витягнути вектор руху, опорний індекс і напрям прогнозування руху, асоційовані з причинною частиною, з пам'яті і копіювати ці значення як інформацію руху для поточної частини. Щоб відновити блок в режимі злиття, декодер одержує прогнозуючий блок, використовуючи одержану інформацію руху для поточної частини, і додає залишкові дані до прогнозуючого блока, щоб відновити закодований блок. У AMVP кодер інструктує декодер, через сигналізацію потоку бітів, тільки скопіювати вектор руху з частини кандидата і використовувати скопійований вектор як прогнозувач для вектора руху поточної частини, і сигналізує різницю векторів руху (MVD). Опорний кадр і напрям прогнозування, асоційовані з вектором руху поточної частини, повідомляються по окремості. MVD є різницею між поточним вектором руху для поточної частини і прогнозувачем вектора руху, одержаним з частини кандидата. У цьому випадку, кодер, використовуючи оцінку руху, визначає фактичний вектор руху для блока, який повинен бути закодований, і потім визначає різницю між фактичним вектором руху і прогнозувачем вектора руху як значення MVD. Таким чином, декодер не використовує точну копію вектора-кандидата руху як поточний вектор руху, як в режимі злиття, але може замість цього використовувати вектор-кандидат руху, який може бути "близьким" по значенню до поточного вектора руху, визначеного з оцінки руху, і додати MVD, щоб відновити поточний вектор руху. Щоб відновити блок в режимі AMVP, декодер додає відповідні залишкові дані, щоб відновити закодований блок. При більшості обставин MVD вимагає менше бітів сигналізації, ніж весь поточний вектор руху. Також, AMVP забезпечує більш точну сигналізацію поточного вектора руху, в той же час підтримуючи ефективність кодування по відправленню всього вектора руху. Навпаки, режим злиття не забезпечує специфікацію MVD, і, як такий, режим злиття жертвує точністю сигналізації вектора руху для збільшеної ефективності сигналізації (тобто менше бітів). Синтаксис прогнозування для AMVP може включати в себе прапор для цього режиму (в цьому випадку прапор AMVP), індекс для частини кандидата, MVD між поточним вектором руху і прогнозуючим вектором руху від частини кандидата, опорний індекс і напрям прогнозування руху. Як тільки оцінка руху виконана, щоб визначити вектор руху для поточної частини, кодер порівнює співпадаючу частину в опорному кадрі з поточною частиною. Це порівняння типово застосовує віднімання частини (яка звичайно згадується як "опорна вибірка") в опорному кадрі з поточної частини і приводить до так званих залишкових даних, як згадано вище. Залишкові дані вказують значення пікселної різниці між поточною частиною і опорною вибіркою. Кодер потім перетворює ці залишкові дані з просторової області в область перетворення, таку як частотна область. Звичайно кодер застосовує дискретне косинусне перетворення (DCT) до залишкових даних, щоб досягнути цього перетворення. Кодер виконує це перетворення, щоб полегшити стиснення залишкових даних, оскільки результуючі коефіцієнти перетворення представляють різні частоти, в якому більшість енергії звичайно концентрується на декількох низькочастотних коефіцієнтах. Як правило, результуючі коефіцієнти перетворення групуються способом, який допускає кодування довжин серій, особливо, якщо коефіцієнти перетворення спочатку квантуються (округлюються). Кодер виконує це кодування довжин серій квантованих коефіцієнтів перетворення і потім виконує статистичне кодування без втрат (або так зване "ентропійне"), щоб додатково стиснути кодовані по довжинах серій квантовані коефіцієнти перетворення. Після виконання ентропійного кодування без втрат кодер генерує потік бітів, який включає в себе закодовані відеодані. Цей потік бітів також включає в себе кількість елементів синтаксису прогнозування в деяких випадках, які задають, чи було, наприклад, прогнозування вектора руху виконане, режим вектора руху і індекс прогнозувача вектора руху (MVP) (тобто індекс частини кандидата з вибраним вектором руху). Індекс MVP може також згадуватися його ім'ям "mvp idx" змінної елемента синтаксису. У поточній структурі, пропонованій для прийняття ITU-T/ISO/IEC об'єднаною спільною командою відносно кодування відео (JCT-VC), званого високоефективним кодуванням відео (HEVC), кодер виконує ряд режимів прогнозування вектора руху, щоб прогнозувати вектор руху для поточної частини, включаючи 1) AMVP і 2) режим злиття, описаний вище. Ці два режими аналогічні, хоч AMVP передбачає більше гнучкості в термінах здатності визначити MVDs, напрями прогнозування руху і опорні індекси, в той час як режим злиття просто копіює цю 5 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 60 інформацію вектора руху (тобто вектор руху, напрям прогнозування руху і опорний індекс) і не враховує підвищену точність MVD. Фіг. 1A показує набір блоків-кандидатів 100 (або частини/блоки в PU), на даний час запропонований в стандарті HEVC для використання в режимі AMVP, в той час як Фіг. 1B показує набір блоків-кандидатів 110, на даний час запропонований в стандарті HEVC для використання в режимі злиття. Режим AMVP використовує шість блоків-кандидатів: нижній лівий (BL) блок 101, лівий (L) блок 102, правий верхній (RA) блок 103, верхній (А) блок 104, лівий верхній (LA) блок 105 і часовий блок (Т) 106. Потрібно зазначити, що на доповнення до набору блоків-кандидатів режим AMVP також визначає порядок відносно перевірки блоків-кандидатів. У прикладі на Фіг. 1A, шаблон перевірки відбувається таким чином: BL-L-RA-A-LA-T. Як показано на Фіг. 1B, режим злиття використовує п'ять блоків-кандидатів: нижній лівий (BL) блок 111, лівий (L) блок 112, правий верхній (RA) блок 113, верхній (А) блок 114 і часовий (Т) блок 115. Вектори руху, асоційовані з цими блоками-кандидатами, використовуються для того, щоб визначити прогнозувач вектора руху в режимі злиття і режимі AMVP. Режим злиття може використовувати аналогічний шаблон перевірки як AMVP або може використовувати інший шаблон перевірки. Як описано вище, режим AMVP використовує шість блоків-кандидатів, в той час як режим злиття використовує п'ять блоків-кандидатів. Крім того, крім правого верхнього (RA), нижнього лівого (BL) і часового (Т) блоків, блоки-кандидати для режиму AMVP і режиму злиття знаходяться в різних місцеположеннях. Як така, велика кількість блоків-кандидатів повинна бути збережена і розглянута і під час процесу кодування, і під час процесу декодування. Крім того, шаблон перевірки для AMVP може бути неоптимальним, оскільки нижній лівий блок може бути недоступний у всіх обставинах. Такі обставини включають в себе такі, коли нижній лівий блок ще не був закодований (наприклад, він перетинає границю вирізки або CU), або якщо дані для нижнього лівого блока пошкоджені. У цьому розкритті запропонований об'єднаний набір блоків-кандидатів і для режиму AMVP, і для режиму злиття. Звичайно один і той же набір блоків-кандидатів використовується, незалежно від того, який використовується режим прогнозування вектора руху (наприклад, режим злиття або режим AMVP). Також, менше пам'яті необхідно для того, щоб зберегти вектора руху і іншу інформацію що стосується зовнішнього прогнозування (наприклад, опорний кадр, напрям прогнозування і т. д.). У інших прикладах цього розкриття запропоновані способи для того, щоб використовувати набір блоків-кандидатів, який включає в себе додатковий блоккандидат. Крім того, також розкриті способи для більш оптимального шаблона перевірки. Фіг. 2 є блок-схемою, що ілюструє зразкову систему 10 кодування і декодування відео, яка може конфігуруватися, щоб використовувати способи для прогнозування вектора руху відповідно до прикладів цього розкриття. Як показано на Фіг. 2, система 10 включає в себе пристрій-джерело 12, який передає кодоване відео на пристрій 14 призначення через канал зв'язку 16. Закодовані відеодані можуть також зберігатися на носії даних 34 або файловому сервері 36 і можуть бути доступні пристрою 14 призначення за необхідності. Коли збережені на носій даних або файловий сервер, відеокодер 20 може видати кодовані відеодані іншому пристрою, такому як мережевий інтерфейс, пристрою пропалювання або штампування компактдиска (CD), Blu-ray або цифрового відеодиска (DVD), або інші пристрої, для того, щоб зберегти закодовані відеодані на носій даних. Аналогічно, пристрій, окремий від відеодекодера 30, такий як мережевий інтерфейс, CD або зчитувач DVD, або подібне, може витягнути кодовані відеодані з носія даних і подати витягнуті дані до відеодекодера 30. Пристрій-джерело 12 і пристрій 14 призначення можуть містити будь-який з широкої різноманітності пристроїв, включаючи настільні комп'ютери, портативні комп'ютери (тобто ноутбуки), планшетні комп'ютери, телевізійні приставки, телефонні трубки, такі як так звані "смартфони", телевізори, камери, пристрої відображення, цифрові медіаплеєри, відеоігрові пульти або подібне. У багатьох випадках такі пристрої можуть бути обладнані для бездротового зв'язку. Отже, канал зв'язку 16 може містити бездротовий канал, дротовий канал або комбінацію бездротових і дротових каналів, придатних для передачі закодованих відеоданих. Точно так само, до файлового сервера 36 може одержати доступ пристрій 14 призначення через будь-яке стандартне з'єднання даних, включаючи Інтернет-з'єднання. Воно може включати в себе бездротовий канал (наприклад, з'єднання Wi-Fi), дротове з'єднання (наприклад, DSL, кабельний модем і т. д.) або комбінацію обох, яка є придатною для того, щоб одержати доступ до закодованих відеоданих, збережуваних на файловому сервері. Способи для прогнозування вектора руху, відповідно до прикладів цього розкриття, можуть бути застосовані до кодування відео на підтримання будь-якого з множини мультимедійних додатків, таких як передачі телевізійного мовлення, передачі кабельного телебачення, передачі супутникового телебачення, потокові передачі відео, наприклад через Інтернет, кодування 6 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 60 цифрового відео для зберігання на запам'ятовуючому носії даних, декодування цифрового відео, збереженого на запам'ятовуючому носії даних, або інші додатки. У деяких прикладах система 10 може конфігуруватися, щоб підтримувати односторонню або двосторонню передачу відео, щоб підтримувати додатки, такі як потокова передача відео, відтворення відео, мовлення відео і/або відеотелефонія. У прикладі на Фіг. 2 пристрій-джерело 12 включає в себе відеоджерело 18, відеокодер 20, модулятор/демодулятор 22 і передавач 24. У вихідному пристрої 12 відеоджерело 18 може включати в себе джерело, таке як пристрій захоплення відео, такий як відеокамера, відеоархів, що містить раніше захоплене відео, інтерфейс подачі відео, щоб прийняти відео від постачальника відеоконтенту, і/або систему комп'ютерної графіки для того, щоб генерувати дані комп'ютерної графіки як вихідне відео, або комбінація таких джерел. Як один приклад, якщо відеоджерело 18 є відеокамерою, пристрій-джерело 12 і пристрій 14 призначення можуть сформувати так звані камерофони або відеотелефони. Однак, способи, описані в цьому розкритті, можуть бути застосовними звичайно до кодування відео і можуть бути застосовані до бездротових і/або дротових додатків або додатка, в якому кодовані відеодані зберігаються на локальному диску. Захоплене, попередньо захоплене, або генероване комп'ютером відео може бути закодоване відеокодером 20. Кодована відеоінформація може модулюватися модемом 22 згідно зі стандартом зв'язку, таким як протокол бездротового зв'язку, і передана на пристрій 14 призначення через передавач 24. Модем 22 може включати в себе різні змішувачі, фільтри, підсилювачі або інші компоненти, розроблені для модуляції сигналу. Передавач 24 може включати в себе схеми, розроблені для того, щоб передавати дані, включаючи підсилювачі, фільтри і одну або більше антен. Захоплене, попередньо захоплене або генероване комп'ютером відео, яке кодоване відеокодером 20, може також бути збережене на носії даних 34 або файловому сервері 36 для більш пізнього використання. Носій даних 34 може включати в себе диски Blu-ray, DVD, CDROM, флеш-пам'ять або будь-які інші придані цифрові носії даних для того, щоб зберігати кодоване відео. До кодованого відео, збереженого на носії даних 34, може потім одержати доступ пристрій 14 призначення для декодування і відтворення. Файловий сервер 36 може бути будь-яким типом сервера, здатного до зберігання кодованого відео і передачі цього кодованого відео на пристрій 14 призначення. Файлові сервери як приклад включають в себе web-сервер (наприклад, для веб-сайта), сервер FTP, пристрої мережевих систем зберігання (NAS), локальний дисковий накопичувач або будь-який інший тип пристрою, здатного до того, щоб зберігати закодовані відеодані і передавати їх на пристрій призначення. Передача закодованих відеоданих від файлового сервера 36 може бути потоковою передачею, передачею завантаження або комбінацією обох. До файлового сервера 36 може одержати доступ пристрій 14 призначення через будь-яке стандартне з'єднання даних, включаючи Інтернет-з'єднання. Воно може включати в себе бездротовий канал (наприклад, з'єднання Wi-Fi), дротове з'єднання (наприклад, DSL, кабельний модем, Ethernet, USB і т. д.) або комбінацію обох, яка є придатною для того, щоб одержати доступ до закодованих відеоданих, збережуваних на файловому сервері. Пристрій 14 призначення в прикладі на Фіг. 2 включає в себе приймач 26, модем 28, відеодекодер 30 і пристрій 32 відображення. Приймач 26 з пристрою 14 призначення приймає інформацію по каналу 16, і модем 28 демодулює інформацію, щоб сформувати демодульований потік бітів для відеодекодера 30. Інформація, передана по каналу 16, може включати в себе різноманітну інформацію синтаксису, генеровану відеокодером 20 для використання відеодекодером 30 при декодуванні відеоданих. Такий синтаксис може також бути включений із закодованими відеоданими, що зберігаються на носії даних 34 або файловому сервері 36. Кожний відеокодер 20 і відеодекодер 30 може бути частиною відповідного декодеракодера (кодек), який здатний до кодування або декодування відеоданих. Пристрій 32 відображення може інтегруватися з, або бути зовнішнім до, пристроєм 14 призначення. У деяких прикладах пристрій 14 призначення може включати в себе інтегрований пристрій відображення і також конфігуруватися, щоб сполучатися із зовнішнім пристроєм відображення. У інших прикладах пристрій 14 призначення може бути пристроєм відображення. Звичайно, пристрій 32 відображення відображає декодовані відеодані користувачу і може містити будь-який з множини пристроїв відображення, таких як рідкокристалічний дисплей (LCD), плазмовий дисплей, дисплей на органічних світлодіодах (OLED) або інший тип пристрою відображення. У прикладі на Фіг. 2 канал зв'язку 16 може містити будь-який бездротовий або дротовий комунікаційний носій, такий як радіочастотний (РЧ) спектр або одну або більше фізичних ліній 7 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 60 передачі, або будь-яку комбінацію бездротового і дротового носіїв. Канал зв'язку 16 може бути частиною основаної на передачі пакетів мережі, такої як локальна мережа, регіональна мережа або глобальна мережа, така як Інтернет. Канал зв'язку 16 звичайно представляє будь-який придатний комунікаційний носій або комбінацію різних комунікаційних носіїв для того, щоб передавати відеодані від вихідного пристрою 12 на пристрій 14 призначення, включаючи будьяку придатну комбінацію дротового або бездротового носіїв. Канал зв'язку 16 може включати в себе маршрутизатори, комутатори, базові станції або будь-яке інше обладнання, яке може бути корисним, щоб полегшити зв'язок від вихідного пристрою 12 до пристрою 14 призначення. Відеокодер 20 і відеодекодер 30 можуть працювати згідно зі стандартом стиснення відео, таким як стандарт високоефективного кодування відео (HEVC), що знаходиться в розвитку, і можуть відповідати Тестовій Моделі HEVC (HM). Альтернативно, відеокодер 20 і відеодекодер 30 можуть працювати згідно з іншими стандартами, що складають власність, або стандартами промисловості, такими як стандарт ITU-T H.264, альтернативно названий MPEG-4, Частина 10, Вдосконалене відеокодування (AVC), або розширеннями таких стандартів. Способи цього розкриття, однак, не обмежені ніяким конкретним стандартом кодування. Інші приклади включають в себе MPEG-2 і ITU-T H.263. Хоч не показано на Фіг. 2, в деяких аспектах відеокодер 20 і відеодекодер 30 можуть, кожний, інтегруватися з аудіокодером і декодером і можуть включати в себе відповідні блоки MUX-DEMUX (мультиплексорів-демультиплексорів) або інше апаратне забезпечення і програмне забезпечення, щоб виконувати кодування як аудіо так і відео в загальному потоці даних або окремих потоках даних. Якщо застосовно, блоки MUX-DEMUX можуть відповідати протоколу мультиплексора ITU H.223 або іншим протоколам, таким як протокол дейтаграм користувача (UDP). Відеокодер 20 і відеодекодер 30, кожний, можуть бути реалізовані як будь-яка з множини придатних схем кодера, таких як один або більше мікропроцесорів, цифрових сигнальних процесорів (DSPs), спеціалізованих інтегральних схем (ASIC), програмованих користувачем вентильних матриць (FPGA), дискретної логіки, програмного забезпечення, апаратного забезпечення, програмно-апаратних засобів або будь-яких їх комбінацій. Коли способи реалізовуються частково в програмному забезпеченні, пристрій може зберігати інструкції для програмного забезпечення у придатному постійному зчитуваному комп'ютером носії і виконувати інструкції в апаратному забезпеченні, використовуючи один або більше процесорів, щоб виконати способи даного розкриття. Кожний з відеокодера 20 і відеодекодера 30 може бути включений в один або більше кодерів або декодерів, будь-який з яких може бути інтегрованим як частина об'єднаного кодера/декодера (кодек) у відповідному пристрої. Відеокодер 20 може реалізувати будь-які зі способів цього розкриття для прогнозування вектора руху в процесі кодування відео. Аналогічно, відеодекодер 30 може реалізувати будьякий або всі з цих способів прогнозування вектора руху в процесі кодування відео. Відеокодер, як описано в цьому розкритті, може належати до відеокодера або відеодекодера. Точно так само, пристрій кодування відео може належати до відеокодера або відеодекодера. Аналогічно, кодування відео може належати до кодування відео або декодування відео. У одному прикладі розкриття відеокодер 20 з вихідного пристрою 12 може конфігуруватися, щоб визначити один з множини режимів для процесу прогнозування вектора руху, і виконати процес прогнозування вектора руху для поточного блока відеоданих, використовуючи визначений режим і набір блоків-кандидатів, в якому набір блоків-кандидатів є однаковим для кожного з множини режимів. У іншому прикладі розкриття відеокодер 20 з вихідного пристрою 12 може конфігуруватися, щоб визначити один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих, і виконати процес прогнозування вектора руху для поточного блока, використовуючи визначений режим і набір блоків-кандидатів, в якому набір блоків-кандидатів є однаковим для кожного з множини режимів, і в якому один блок-кандидат в наборі блоківкандидатів визначається як додатковий блок-кандидат, і в якому додатковий блок-кандидат використовується, якщо інший з блоків-кандидатів набору блоків-кандидатів недоступний. У іншому прикладі розкриття відеодекодер 30 з пристрою 14 призначення може конфігуруватися, щоб приймати елемент синтаксису, що вказує один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих, і приймати індекс, що вказує блок-кандидат з набору блоків-кандидатів, в якому набір блоків-кандидатів є однаковим для кожного з множини режимів, і в якому інформація, асоційована з блоком-кандидатом, використовується, щоб декодувати вектор руху для поточного блока. У іншому прикладі розкриття відеодекодер 30 з пристрою 14 призначення може конфігуруватися, щоб приймати елемент синтаксису, що вказує один з множини режимів для 8 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 60 процесу прогнозування вектора руху для поточного блока відеоданих, і приймати індекс, що вказує блок-кандидат з набору блоків-кандидатів, в якому набір блоків-кандидатів є однаковим для кожного з множини режимів, в якому один блок-кандидат в наборі блоків-кандидатів визначається як додатковий блок-кандидат, при цьому цей додатковий блок-кандидат використовується, якщо інший з блоків-кандидатів набору блоків-кандидатів недоступний, і в якому інформація, асоційована з блоком-кандидатом, використовується, щоб декодувати вектор руху для поточного блока. Фіг. 3 є блок-схемою, що ілюструє приклад відеокодера 20, який може використовувати способи для прогнозування вектора руху, як описано в цьому розкритті. Відеокодер 20 буде описаний в контексті кодування HEVC з метою ілюстрації, але без обмеження цього розкриття відносно інших стандартів або способів кодування, які можуть вимагати сканування коефіцієнтів перетворення. Відеокодер 20 може виконувати внутрішнє і зовнішнє кодування одиниць CU в межах відеокадрів. Внутрішнє кодування покладається на просторове прогнозування, щоб зменшити або видалити просторову надмірність у відеоданих в межах заданого відеокадру. Зовнішнє кодування покладається на часове прогнозування, щоб зменшити або видалити часову надмірність між поточним кадром і раніше закодованими кадрами відеопослідовності. Внутрішній режим (I-режим) може належати до будь-яких з декількох на основі просторового стиснення режимів відео. Зовнішні режими, такі як однонаправлене прогнозування (Р-режим) або двонаправлене прогнозування (В-режим), можуть належати до будь-якого з декількох на основі часового стиснення режимів відео. Як показано на Фіг. 3, відеокодер 20 приймає поточний відеоблок в межах відеокадру, який повинен бути закодований. У прикладі на Фіг. 3 відеокодер 20 включає в себе блок 44 компенсації руху, блок 42 оцінки руху, блок 46 внутрішнього прогнозування, буфер 64 опорних кадрів, суматор 50, модуль 52 перетворення, блок 54 квантування і блок 56 ентропійного кодування. Модуль 52 перетворення, ілюстрований на Фіг. 3, є структурою або пристроєм, що застосовує фактичне перетворення або комбінацію перетворень до блока залишкових даних, і не повинен бути переплутаний з блоком коефіцієнтів перетворення, який може згадуватися як одиниця перетворення (TU) в CU. Для реконструкції блока відео, відеокодер 20 також включає в себе блок 58 зворотного квантування, модуль 60 зворотного перетворення і суматор 62. Фільтр видалення блоковості (не показаний на Фіг. 3) може також бути включений, щоб фільтрувати границі блока, щоб видалити артефакти блоковості з відновленого відео. Якщо бажано, фільтр видалення блоковості типово може фільтрувати вихідний сигнал суматора 62. Під час процесу кодування відеокодер 20 приймає відеокадр або вирізку, яка повинна бути закодована. Кадр або вирізка можуть бути розділені на множинні відеоблоки, наприклад найбільші одиниці кодування (LCUs). Блок 42 оцінки руху і блок 44 компенсації руху виконують зовнішнє прогнозуюче кодування прийнятого відеоблока відносно одного або більше блоків в одному або більше опорних кадрах, щоб забезпечити часове стиснення. Блок 46 внутрішнього прогнозування може виконати внутрішнє прогнозуюче кодування прийнятого відеоблока відносно одного або більше сусідніх блоків в тому ж самому кадрі або вирізці як блока, який повинен бути закодований, щоб забезпечити просторове стиснення. Блок 40 вибору режиму може вибрати один з режимів кодування, внутрішній або зовнішній, наприклад, на основі результатів помилки (тобто спотворення) для кожного режиму, і видає результуючий внутрішньо або зовнішньо прогнозований блок (наприклад, одиницю прогнозування (PU)) до суматора 50, щоб генерувати залишкові дані блока, і до суматора 62, щоб відновити закодований блок для використання в опорному кадрі. Суматор 62 об'єднує прогнозований блок із зворотно квантованими зворотно перетвореними даними з модуля 60 зворотного перетворення для цього блока, щоб відновити закодований блок, як описано більш детально нижче. Деякі відеокадри можуть визначатися як I-кадри, де всі блоки в I-кадрі кодовані в режимі внутрішнього прогнозування. У деяких випадках блок 46 внутрішнього прогнозування може виконати кодування з внутрішнім прогнозуванням блока в Р- або В-кадрі, наприклад, коли пошук руху, виконаний блоком 42 оцінки руху, не приводить до достатнього прогнозування блока. Блок 42 оцінки руху і блок 44 компенсації руху можуть бути високоінтегрованими, але ілюстровані по окремості в концептуальних цілях. Оцінка руху (або пошук руху) є процесом генерування векторів руху, які оцінюють рух для відеоблоків. Вектор руху, наприклад, може вказувати зміщення блока прогнозування в поточному кадрі відносно опорної вибірки опорного кадру. Блок 42 оцінки руху обчислює вектор руху для блока прогнозування зовнішньокодованого кадру, порівнюючи блок прогнозування з опорними вибірками опорного кадру, збереженого в буфері 64 опорних кадрів. Опорна вибірка може бути блоком, який, як знаходять, близько відповідає частині CU, включаючи PU, кодованій в термінах пікселної різниці, яка може бути 9 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 60 визначена сумою абсолютних різниць (SAD), сумою різниць квадратів(SSD) або іншими метриками різниці. Опорна вибірка може знаходитися де-небудь в межах опорного кадру або опорної вирізки. У деяких прикладах опорна вибірка може знаходитися у фракційному місцеположенні піксела. Частина опорного кадру, ідентифікована вектором руху, може згадуватися як опорна вибірка. Блок 44 компенсації руху може обчислити значення прогнозування для одиниці прогнозування поточної CU, наприклад, витягуючи опорну вибірку, ідентифіковану вектором руху для PU. У деяких способах кодування відеоблок 42 оцінки руху посилає обчислені вектор руху, опорний кадр і напрям прогнозування (тобто напрям в термінах того, чи передує опорний кадр у часі або іде за поточним кадром) до блока 56 ентропійного кодування і блока 44 компенсації руху. Інші способи кодування відео використовують процес прогнозування вектора руху, щоб кодувати вектор руху. Процес прогнозування вектора руху може бути вибраний з числа множини режимів, включаючи режим злиття і режим AMVP. У режимі злиття кодер розглядає набір блоків-кандидатів і вибирає блок, який має ті ж самі (або найбільш близько відповідає) вектор руху, опорний кадр і напрям прогнозування, що і поточний блок. Це досягають перевіркою кожного блока-кандидата по черзі і вибираючи той, який приводить до найкращої ефективності "швидкість передачі-спотворення", як тільки його вектор руху, опорний кадр і напрям прогнозування скопійовані в поточний блок. Потім, замість того, щоб сигналізувати цю інформацію вектора руху (тобто вектор руху, опорний кадр і напрям прогнозування) в закодованому відеопотоці бітів, кодер сигналізує номер індексу для вибраного блока-кандидата. Декодер може скопіювати інформацію вектора руху з блока-кандидата, вказаного сигналізованим індексом, і використовувати скопійовану інформацію вектора руху для поточного блока. Фіг. 4A показує приклад сигналізації режиму злиття. Прапор 201 злиття вказує, що використовується режим злиття. Індекс 202 блока-кандидата вказує, який з блоківкандидатів з набору блоків-кандидатів, визначених для режиму злиття, повинен використовуватися, щоб витягнути інформацію вектора руху для поточного блока. Потрібно зазначити, що в деяких випадках, щоб задовольнити конкретну кількість кандидатів для набору кандидатів режиму злиття, деяка "штучна" інформація вектора руху може генеруватися, щоб заповнити набір кандидатів. Ця "штучна" інформація вектора руху може генеруватися за допомогою часткових комбінацій інформації вектора руху з різних блоківкандидатів. Наприклад, вектор руху Списку 0 з блока-кандидата 1 може бути об'єднаний з вектором руху Списку 1 з кандидата 2, разом з індексом опорного кадру і напрямом прогнозування, щоб сформувати нову інформацію вектора руху в наборі кандидатів. У деяких інших прикладах можуть також бути додані нульові вектори руху як додаткова інформація вектора руху, щоб заповнити набір кандидатів. Однак, незалежно від того, як набір кандидатів сформований, в режимі злиття тільки індекс в наборі кандидата повинен бути сигналізований до декодера, щоб указати, який кандидат вибраний, щоб надати інформацію вектора руху для поточного блока. На стороні декодера формується той же набір кандидатів, і інформація вектора руху може бути ідентифікована через сигналізований індекс в набір кандидатів. У режимі AMVP кодер розглядає набір блоків-кандидатів і вибирає блок, який формує різницю векторів руху (тобто різницю між вектором руху відповідного блока-кандидата і фактичним вектором руху поточного блока), яка приводить до найкращого значення "спотворення-швидкість передачі" або задовольняє деякий попередньо визначений поріг (наприклад, поріг "спотворення-швидкість передачі"). Режим AMVP може розглянути блокикандидати в шаблоні перевірки, поки задовільний кандидат не буде знайдений і вибраний. Альтернативно, в деяких прикладах всі блоки-кандидати можуть бути перевірені, і блоккандидат, що приводить до кращого результату, вибраний як MVP для блока, який повинен бути закодований. Кодер може потім сигналізувати індекс для блока-кандидата, використаного для формування різниці векторів руху, нарівні з різницею векторів руху. Декодер може потім оновити вектор руху для поточного блока, підсумовуючи прийняту різницю векторів руху з вектором руху, витягнутим з блока-кандидата, вказаного сигналізованим індексом. Фіг. 4B показує приклад сигналізації режиму AMVP. Прапор 205 режиму AMVP вказує, що використовується режим AMVP. Індекс 206 блока-кандидата вказує, який з блоків-кандидатів з набору блоківкандидатів, визначених длярежиму AMVP, повинен використовуватися, щоб витягнути вектор руху. Режим AMVP також сигналізує різницю 207 векторів руху, опорний кадр 208 і напрям прогнозування 209. У деяких прикладах замість того, щоб явно сигналізувати опорний кадр і напрям прогнозування, опорний кадр і напрям прогнозування замість цього витягують з інформації вектора руху, асоційованої з блоком-кандидатом. У прикладах, описаних вище, сигналізація інформації вектора руху в закодованому потоці бітів не вимагає передачі в реальному часі таких елементів від кодера до декодера, а замість 10 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 60 цього означає, що така інформація закодована в потік бітів і зроблена доступною для декодера будь-яким способом. Це може включати в себе передачу в реальному часі (наприклад, у відеоконференцзв'язку), так само як збереження закодованого потоку бітів на зчитуваному комп'ютером носії для майбутнього використання декодером (наприклад, в потоковій передачі, завантаженні, дисковому доступі, доступі до карти, DVD, Blu-ray і т. д.). Відповідно до прикладів цього розкриття режим злиття і режим AMVP використовують один і той же набір блоків-кандидатів (тобто і в термінах кількості, і в термінах місцеположення блоків). Також, і кодер, і декодер можуть зменшити об'єм пам'яті, необхідний для зберігання інформації вектора руху для блоків-кандидатів. Це може також зменшити вимогу смуги пропускання пам'яті при відновленні таких векторів руху під час процесу кодування поточного блока. У першому прикладі розкриття режим злиття і режим AMVP обидва використовують один і той же набір 120 блоків-кандидатів, показаний на Фіг. 5A. В цьому прикладі режим злиття тепер буде використовувати шість блоків-кандидатів замість п'яти. Однак, загальна кількість блоківкандидатів і для режиму злиття, і для режиму AMVP зменшена, оскільки обидва режими використовують блоки-кандидати в одних і тих же місцеположеннях. У цьому прикладі блокикандидати знаходяться в нижній лівій (BL) 121, лівій (L) 122, лівій верхній (LA) 125, верхній (А) 124, правій верхній (RA) 123 і часовій (Т) 126 позиціях, як показано на Фіг. 5A. В цьому прикладі лівий блок-кандидат 122 є суміжним з лівим краєм поточного блока 127. Нижній край лівого блока 122 вирівняний з нижнім краєм поточного блока 127. Вищезазначений блок 124 є суміжним з верхнім краєм поточного блока 127. Правий край вищезазначеного блока 124 вирівняний з правим краєм поточного блока 127. У другому прикладі розкриття режим AMVP і режим злиття використовують набір 130 блоківкандидатів, показаний на Фіг. 5B. В цьому прикладі кількість блоків-кандидатів для режиму AMVP скорочена до 5. Подальше скорочення блоків-кандидатів досягнуто, оскільки і режим злиття, і режим AMVP тепер використовують блоки-кандидати в одних і тих же місцеположеннях. У цьому прикладі блоки-кандидати знаходяться в нижньому лівому (BL) 131, лівому (L) 132, верхньому (А) 134, правому верхньому (RA) 133 і часовому (Т) 135 місцеположеннях. Потрібно зазначити, що місцеположення вищезазначеного блока 134 і лівого блока 132 відрізняються від місцеположень вищезазначеного блока 124 і лівого блока 122 в прикладі на Фіг. 5A. В цьому прикладі лівий блок-кандидат 132 є суміжним з лівим краєм поточного блока 137. Верхній край лівого блока 132 вирівняний з верхнім краєм поточного блока 137. Вищезазначений блок 134 є суміжним з верхнім краєм поточного блока 137. Лівий край вищезазначеного блока 134 вирівняний з лівим краєм поточного блока 137. У одному прикладі шаблон перевірки для режиму AMVP є наступним: BL-L-RA-T. У третьому прикладі розкриття режим злиття і режим AMVP використовують набір 140 блоків-кандидатів, показаний на Фіг. 6. У цьому прикладі скорочена кількість блоків-кандидатів; обидва зі зменшенням загальну кількість для кожного режиму до 5, а також об'єднуючи місцеположення блоків-кандидатів для обох режимів. У цьому прикладі блоки-кандидати знаходяться в нижньому лівому (BL) 141, лівому (L) 142, верхньому (А) 143, правому верхньому (RA) 144 і часовому (Т) 145. У цьому прикладі лівий блок-кандидат 142 є суміжним з лівим краєм поточного блока 147. Нижній край лівого блока 142 вирівняний з нижнім краєм поточного блока 147. Вищезазначений блок 143 є суміжним з верхнім краєм поточного блока 147. Правий край вищезазначеного блока 143 вирівняний з правим краєм поточного блока 147. У іншому прикладі розкриття описує поліпшений шаблон перевірки для режиму AMVP. Як показано на Фіг. 7, наприклад, шаблон перевірки є наступним: L-BL-A-RA-LA-T. Замість того, щоб починатися в блоці-кандидаті BL, як показано на Фіг. 1A, приклад на Фіг. 7 починається в блоці-кандидаті L. Блоки з лівої сторони звичайно більше корельовані до поточного блока, оскільки відеоконтент типово переміщується в горизонтальному напрямі. Блок-кандидат L перевіряється першим, оскільки блок-кандидат BL може бути недоступний (тобто, можливо, не був вже закодований) у всіх ситуаціях. Крім того, блок-кандидат А перевіряється перед блокомкандидатом RA, оскільки вектор руху блока-кандидата А, як було показано, має більш високу статистичну кореляцію до вектора руху поточного блока, ніж такий блока-кандидата RA. Режим злиття може використовувати один і той же шаблон перевірки, показаний на Фіг. 7, або може використовувати різні шаблони перевірки. Як один приклад, шаблон перевірки для режиму злиття може бути наступним: L-A-RA-BL-(LA)-Т. У цьому прикладі включення блока LA є необов'язковим або адаптивним залежно від того, якщо один з перших чотирьох блоківкандидатів недоступний. Приклад на Фіг. 7 показаний відносно набору блоків-кандидатів на Фіг. 5A. Однак, цей шаблон перевірки може бути застосовним з будь-яким набором кандидатів. Звичайно лівий блок-кандидат повинен перевіряється перед нижнім лівим блоком-кандидатом. Потім 11 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 60 вищезазначений блок-кандидат повинен бути перевірений перед правим верхнім блокомкандидатом. Будь-які блоки-кандидати, що залишилися, можуть потім бути перевірені в будьякому порядку. У деяких прикладах часовий блок-кандидат може бути перевірений останнім. У іншому прикладі розкриття розкриті гнучкі додаткові кандидати і для режиму злиття, і для режиму AMVP. Як показано в прикладі на Фіг. 5A, є п'ять просторових блоків-кандидатів (тобто L, BL, А, RA і LA) і один часовий блок-кандидат (тобто Т), для загалом шести блоків-кандидатів. У попередній пропозиції до стандарту HEVC максимальна кількість блоків-кандидатів для режиму злиття дорівнює п'яти. Також, один з блоків-кандидатів, показаних на Фіг. 5A, може бути видалений для режиму злиття. У одному прикладі блок-кандидат LA може бути визначений як додатковий блок-кандидат (тобто він спочатку не розглядається як частина набору блоківкандидатів для режиму злиття). Однак, як згадано вище, не всі блоки-кандидати доступні у всіх ситуаціях. Наприклад, блоккандидат BL може бути ще не закодований в той час, коли поточний блок кодується. Крім того, дані для деяких блоків-кандидатів можуть стати пошкодженими або можуть не бути прийняті взагалі (наприклад, при декодування в реальному часі). Також, дане розкриття пропонує використовувати додаткові блоки-кандидати в ситуаціях, коли знайдено, що блок-кандидат в наборі недоступний. Таким чином, загальна кількість кандидатів збережена рівною максимальній межі, не витрачаючи даремно перевірку відносно недоступного кандидата. У одному прикладі кандидати L і BL спочатку перевіряються кодером або декодером, як застосовні. Якщо один з цих блоків-кандидатів не є дійсним (наприклад, пошкоджений) або недоступний, додатковий блок-кандидат (наприклад, LA) може використовуватися замість нього. Якщо обидва блоки-кандидати L і BL дійсні, блоки-кандидати А і RA перевіряються. Якщо один з цих блоків-кандидатів недійсний або недоступний, блок-кандидат LA може використовуватися замість нього. Якщо обидва блоки-кандидати А і RA будуть дійсні, то блоккандидат LA не буде використовуватися. У цьому прикладі блок-кандидат LA використовується як додатковий блок-кандидат. Однак, будь-який додатковий блок-кандидат в будь-якій причинній позиції (тобто в позиції, відносно поточного блока, де блок-кандидат був вже закодований) відносно поточного блока може використовуватися. У іншому прикладі будуть використовуватися всі блоки-кандидати, показані на Фіг. 5A. Для режиму злиття, де максимальна кількість блоків-кандидатів дорівнює N (де N менше ніж 6), перші N доступних блоків-кандидатів в шаблоні перевірки будуть використовуватися як блокикандидати для режиму злиття. У прикладі на Фіг. 5A є шість блоків-кандидатів з шаблоном перевірки L-RA-BL-LA-T. Перші N доступних блоків-кандидатів в шаблоні перевірки будуть формувати фінальний набір блоків-кандидатів для режиму злиття. У цьому прикладі шаблон перевірки фіксований. У іншому прикладі шаблон перевірки може бути вибраний на основі розміру блока, розміру розділення і/або індексу розділення. У іншому прикладі шаблон перевірки може бути оновлений адаптивно під час кодування і декодування. Оновлення може залежати від індексу злиття, режиму прогнозування вектора руху, розміру розділення, індексу розділення і/або інформації вектора руху (наприклад, опорний індекс, різниця векторів руху, прогнозувач вектора руху) раніше закодованих/декодованих блоків. Згідно з іншим прикладом, способи використання додаткового блока-кандидата можуть бути також застосовані до режиму AMVP. Режим AMVP в поточному робочому проекті стандарту HEVC вже враховує перевірку всіх шести блоків-кандидатів, показаних на Фіг. 5A. Однак, як згадано вище, деякі з цих блоків-кандидатів можуть бути недоступними або недійсними. У такому випадку може бути визначений додатковий кандидат злиття. Такий кандидат злиття може бути в будь-якій позиції, яка є причинною до поточної PU. Повертаючись до Фіг. 3, блок 46 внутрішнього прогнозування може виконати внутрішнє прогнозування відносно прийнятого блока, як альтернативу зовнішньому прогнозуванню, виконаному блоком 42 оцінки руху і блоком 44 компенсації руху. Блок 46 внутрішнього прогнозування може прогнозувати прийнятий блок відносно сусідніх, раніше кодованих блоків, наприклад блоків вище, вище і праворуч, вище і зліва або зліва від поточного блока, приймаючи порядок кодування зліва направо і зверху вниз для блоків. Блок 46 внутрішнього прогнозування може бути сконфігурований за допомогою множини різних режимів внутрішнього прогнозування. Наприклад, блок 46 внутрішнього прогнозування може бути сконфігурований за допомогою деякого числа направлених режимів прогнозування, наприклад тридцяти чотирьох направлених режимів прогнозування, на основі розміру кодованої CU. Блок 46 внутрішнього прогнозування може вибрати режим внутрішнього прогнозування, наприклад, обчислюючи значення помилки прогнозування для різних режимів внутрішнього прогнозування і вибираючи режим, який приводить до найбільш низького значення помилки. Направлені режими прогнозування можуть включати в себе функції для того, щоб об'єднувати 12 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 значення просторово сусідніх пікселів і застосовувати об'єднані значення до однієї або більше пікселних позицій в PU. Як тільки значення для всіх пікселних позицій в PU були обчислені, блок 46 внутрішнього прогнозування може обчислити значення помилки для режиму прогнозування на основі пікселних різниць між обчисленими або прогнозованими значеннями PU і прийнятого первинного блока, який повинен бути кодований. Блок 46 внутрішнього прогнозування може продовжити перевіряти режими внутрішнього прогнозування до режиму внутрішнього прогнозування, поки не буде виявлене прийнятне значення помилки. Блок 46 внутрішнього прогнозування може потім послати PU в суматор 50. Відеокодер 20 формує залишковий блок, віднімаючи дані прогнозування, обчислені блоком 44 компенсації руху або блоком 46 внутрішнього прогнозування, з первинного закодованого блока відео. Суматор 50 представляє компонент або компоненти, які виконують цю операцію віднімання. Залишковий блок може відповідати двовимірній матриці значень пікселної різниці, де кількість значень в залишковому блоці є такою ж, як кількість пікселів в PU, відповідній залишковому блоку. Значення в залишковому блоці можуть відповідати різницям, тобто помилці, між значеннями спільно розташованих пікселів в PU і в первинному блоці, який повинен бути закодований. Така операція застосовується до компонентів і яскравості, і кольоровості, так що різниці можуть бути різницями кольоровості або яскравості залежно від типу блока, який закодований. Модуль 52 перетворення може сформувати одну або більше одиниць перетворення (одиниці TU) із залишкового блока. Модуль 52 перетворення вибирає перетворення з числа множини перетворень. Перетворення може бути вибране на основі однієї або більше характеристик кодування, таких як розмір блока, режим кодування або подібне. Модуль 52 перетворення потім застосовує вибране перетворення до TU, виробляючи відеоблок, що містить двовимірний масив коефіцієнтів перетворення. Модуль 52 перетворення може послати результуючі коефіцієнти перетворення в блок 54 квантування. Блок 54 квантування може потім квантувати коефіцієнти перетворення. Блок 56 ентропійного кодування може потім виконати сканування квантованих коефіцієнтів перетворення в матриці згідно з режимом сканування. Дане розкриття описує блок 56 ентропійного кодування як такий, що виконує сканування. Однак, треба мати на увазі, що в інших прикладах інші блоки обробки, такі як блок 54 квантування, можуть виконати сканування. Як тільки коефіцієнти перетворення скановані в одновимірний масив, блок 56 ентропійного кодування може застосувати ентропійне кодування, таке як контекстно-адаптивне кодування із змінною довжиною коду (CAVLC), контекстно-адаптивне двійкове арифметичне кодування (CABAC), основане на синтаксисі контекстно-адаптивне двійкове арифметичне кодування (SBAC) або інший спосіб ентропійного кодування, до коефіцієнтів. Ентропійне кодування може також бути застосоване до елементів синтаксису, таких як елементи синтаксису, використовувані в режимі злиття і режимі AMVP. Щоб виконати CAVLC, блок 56 ентропійного кодування може вибрати код із змінною довжиною коду для символу, який повинен бути переданий. Кодові слова в VLC можуть бути побудовані таким чином, що відносно більш короткі коди відповідають більш вірогідним символам, в той час як більш довгі коди відповідають менш вірогідним символам. Таким чином, використання VLC може досягнути економії бітів, наприклад, використовуючи кодові слова рівної довжини для кожного символу, який повинен бути переданий. Щоб виконати CABAC, блок 56 ентропійного кодування може вибрати контекстну модель для застосування до деякого контексту, щоб закодувати символи, які повинні бути передані. У випадку коефіцієнтів перетворення контекст може стосуватися, наприклад, того, чи є сусідні значення ненульовими, чи ні. Блок 56 ентропійного кодування може також ентропійно кодувати елементи синтаксису, такі як сигнал, що представляє вибране перетворення. Відповідно до способів цього розкриття, блок 56 ентропійного кодування може вибрати контекстну модель, використовувану, щоб кодувати ці елементи синтаксису, на основі, наприклад, напряму внутрішнього прогнозування для режимів внутрішнього прогнозування, позиції сканування коефіцієнтів, відповідних елементам синтаксису, типу блока і/або типу перетворення, серед інших факторів, використовуваних для вибору контекстної моделі. Після ентропійного кодування блоком 56 ентропійного кодування, результуюче закодоване відео може бути передане на інший пристрій, такий як відеодекодер 30, або заархівоване для більш пізньої передачі або пошуку. У деяких випадках блок 56 ентропійного кодування або інший блок відеокодера 20 може конфігуруватися, щоб виконати інші функції кодування на доповнення до ентропійного кодування. Наприклад, блок 56 ентропійного кодування може бути сконфігурований, щоб 13 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 визначити значення шаблона кодованих блоків (CBP) для одиниць CU і PU. Крім того, в деяких випадках блок 56 ентропійного кодування може виконати кодування довжин серій коефіцієнтів. Блок 58 зворотного квантування і модуль 60 зворотного перетворення застосовують зворотне квантування і зворотне перетворення, відповідно, щоб відновити залишковий блок в пікселній області, наприклад, для більш пізнього використання при відновленні опорного блока. Блок 44 компенсації руху може обчислити опорний блок, підсумовуючи залишковий блок з прогнозуючим блоком, сформованим з одного з кадрів буфера 64 опорних кадрів. Блок 44 компенсації руху може також застосувати один або більше фільтрів інтерполяції до відновленого опорного блока, щоб обчислити субцілочислові пікселні значення для використання при оцінці руху. Суматор 62 підсумовує відновлений залишковий блок з блоком прогнозування зі скомпенсованим рухом, сформованим блоком 44 компенсації руху, щоб сформувати відновлений відеоблок для збереження в буфері 64 опорних кадрів. Відновлений відеоблок може використовуватися блоком 42 оцінки руху і блоком 44 компенсації руху як опорний блок, щоб зовнішньо кодувати блок в подальшому відеокадрі. Фіг. 8 є блок-схемою, що ілюструє приклад відеодекодера 30, який декодує закодовану відеопослідовність. У прикладі на Фіг. 8 відеодекодер 30 включає в себе блок 70 ентропійного декодування, блок 72 компенсації руху, блок внутрішнього 74 прогнозування, блок 76 зворотного квантування, модуль 78 зворотного перетворення, буфер 82 опорних кадрів і суматор 80. Відеодекодер 30 в деяких прикладах може виконати прохід декодування, звичайно зворотний до проходу кодування, описаного відносно відеокодера 20 (див. Фіг. 3). Блок 70 ентропійного декодування виконує процес ентропійного декодування відносно кодованого потоку бітів, щоб витягнути одновимірний масив коефіцієнтів перетворення. Використовуваний процес ентропійного декодування залежить від ентропійного кодування, використовуваного відеокодером 20 (наприклад, CABAC, CAVLC і т. д.). Процес ентропійного кодування, використовуваний кодером, може бути сигналізований в закодованому потоці бітів або може бути попередньо визначеним процесом. У деяких прикладах блок 70 ентропійного декодування (або блок 76 зворотного квантування) може сканувати прийняті значення, використовуючи сканування, що відображає режим сканування, використовуваний блоком 56 ентропійного кодування (або блоком 54 квантування) відеокодера 20. Хоч сканування коефіцієнтів може бути виконане в блоці 76 зворотного квантування, сканування буде описане з метою ілюстрації, як виконуване блоком 70 ентропійного декодування. Крім того, хоч показані як окремі функціональні блоки для простоти ілюстрації, структура і функціональні можливості блока 70 ентропійного декодування, блока 76 зворотного квантування і інших блоків відеодекодера 30 можуть бути високоінтегровані одне з одним. Блок 76 зворотного квантування зворотно квантує, тобто деквантує, квантовані коефіцієнти перетворення, надані в потоці бітів і декодовані блоком 70 ентропійного декодування. Процес зворотного квантування може включати в себе звичайний процес, наприклад, подібний процесам, запропонованим для HEVC, або визначений за допомогою стандарту декодування H.264. Процес зворотного квантування може включати в себе використання параметра квантування QP, обчисленого відеокодером 20 для CU, щоб визначити міру квантування і, аналогічно, міру зворотного квантування, яке повинно бути застосоване. Блок 76 зворотного квантування може зворотно квантувати коефіцієнти перетворення або раніше, або після того, як коефіцієнти перетворені з одновимірного масиву в двовимірний масив. Модуль 78 зворотного перетворення застосовує зворотне перетворення до зворотно квантованих коефіцієнтів перетворення. У деяких прикладах модуль 78 зворотного перетворення може визначити зворотне перетворення, на основі сигналізації від відеокодера 20 або логічно виводячи перетворення з однієї або більше характеристик кодування, таких як розмір блока, режим кодування або подібне. У деяких прикладах модуль 78 зворотного перетворення може визначити перетворення, щоб застосувати до поточного блока, на основі сигналізованого перетворення в кореневому вузлі квадродерева для LCU, що включає поточний блок. Альтернативно, перетворення може бути повідомлене в корені квадродерева TU для листового вузла CU в квадродереві LCU. У деяких прикладах модуль 78 зворотного перетворення може застосувати каскадне зворотне перетворення, в якому модуль 78 зворотного перетворення застосовує два або більше зворотних перетворень до коефіцієнтів перетворення поточного декодованого блока. Блок 74 внутрішнього прогнозування може генерувати дані прогнозування для поточного блока поточного кадру, на основі сигналізованого режиму внутрішнього прогнозування і даних від раніше декодованих блоків поточного кадру. 14 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 60 Згідно з прикладами цього розкриття, відеодекодер 30 може прийняти з кодованого потоку бітів синтаксис прогнозування, який ідентифікує режим прогнозування вектора руху і асоційовану інформацію вектора руху (наприклад, див. Фіг. 4A і 4B і опис, що стосується цього). Зокрема, відеодекодер 30 може прийняти індекс, що вказує блок-кандидат з набору блоківкандидатів, в якому набір блоків-кандидатів є однаковим для кожного з множини режимів, і в якому інформація, асоційована з блоком-кандидатом, використовується, щоб декодувати вектор руху для поточного блока. Набір блоків-кандидатів може бути наборами, показаними на Фіг. 5A, Фіг. 5B або Фіг. 6, або будь-яким іншим набором блоків-кандидатів, причинних до поточного блока. У випадку, коли елемент синтаксису вказує режим злиття, відеодекодер далі конфігурується, щоб витягнути вектор руху, опорний кадр і напрям прогнозування, асоційовані з блокомкандидатом, що має прийнятий індекс, і виконати процес зовнішнього прогнозування для поточного блока, використовуючи витягнутий вектор руху, опорний кадр і напрям прогнозування. У випадку, коли елемент синтаксису вказує режим адаптивного прогнозування вектора руху (AMVP), відеодекодер далі конфігурується, щоб прийняти індекс опорного кадру, різницю векторів руху і елемент синтаксису, що вказує напрям прогнозування, щоб витягнути векторкандидат руху, асоційований з блоком-кандидатом, що має прийнятий індекс, обчислити вектор руху для поточного блока, використовуючи вектор-кандидат руху і різницю векторів руху, і виконувати процес зовнішнього прогнозування, використовуючи обчислений вектор руху, прийнятий індекс опорного кадру і прийнятий напрям прогнозування. Незалежно від режиму прогнозування, як тільки напрям прогнозування, індекс опорного кадру і вектор руху визначені для поточного блока, блок компенсації руху формує блок зі скомпенсованим рухом для поточного блока. Ці блоки зі скомпенсованим рухом по суті створюють наново прогнозуючий блок, використовуваний для формування залишкових даних. Блок 72 компенсації руху може сформувати блоки зі скомпенсованим рухом, можливо виконуючи інтерполяцію, основану на фільтрах інтерполяції. Ідентифікатори для фільтрів інтерполяції, які повинні використовуватися для оцінки руху з субпікселною точністю, можуть бути включені в елементи синтаксису. Блок 72 компенсації руху може використовувати фільтри інтерполяції, які використовуються відеокодером 20 під час кодування відеоблока, щоб обчислити інтерпольовані значення для субцілочислових пікселів опорного блока. Блок 72 компенсації руху може визначити фільтри інтерполяції, використовувані відеокодером 20, згідно з прийнятою інформацією синтаксису, і використовувати ці фільтри інтерполяції, щоб сформувати прогнозуючі блоки. Додатково, блок 72 компенсації руху і блок 74 внутрішнього прогнозування, в прикладі HEVC, можуть використовувати деяку з інформації синтаксису (наприклад, надану квадродеревом), щоб визначити розміри одиниць LCU, що використовуються, щоб кодувати кадр(и) кодованої відеопослідовності. Блок 72 компенсації руху і блок 74 внутрішнього прогнозування можуть також використовувати інформацію синтаксису, щоб визначити інформацію розділення, яка описує, як кожна одиниця CU кадру закодованої відеопослідовності розділена (і, аналогічно, як розділені суб-CU). Інформація синтаксису може також включати в себе режими, що вказують, як кожна CU кодована (наприклад, з внутрішнім або зовнішнім прогнозуванням, і для внутрішнього прогнозування режим кодування з внутрішнім прогнозуванням), один або більше опорних кадрів (і/або опорні списки, що містять ідентифікатори для опорних кадрів) для кожної зовнішньокодованої PU і іншу інформацію, щоб декодувати закодовану відеопослідовність. Суматор 80 об'єднує залишкові блоки з відповідними блоками прогнозування, генерованими блоком 72 компенсації руху або блоком 74 внутрішнього прогнозування, щоб сформувати декодовані блоки. Декодовані блоки, насправді, відновлюють спочатку закодовані блоки, що зазнають втрати через квантування або інші аспекти кодування. Якщо бажано, фільтр видалення блоковості може також бути застосований, щоб фільтрувати декодовані блоки, щоб видалити артефакти блоковості. Декодовані відеоблоки потім зберігаються в буфері 82 опорних кадрів, який забезпечує опорні блоки для подальшої компенсації руху і також формує декодоване відео для представлення на пристрої відображення (такому як пристрій 32 відображення згідно з Фіг. 2). Як згадано вище, способи цього розкриття застосовні і для кодера, і для декодера. Звичайно, і відповідно до опису вище, кодер використовує один і той же набір блоків-кандидатів, щоб виконати процес прогнозування вектора руху (наприклад, режим злиття і режим AMVP). Декодер може потім декодувати вектор руху на основі елементів синтаксису, прийнятих, використовуючи той же набір блоків-кандидатів, що використовуються кодером. Об'єднуючи 15 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 блоки-кандидати для всіх режимів прогнозування вектора руху, об'єм пам'яті, який повинен зберігати інформацію вектора руху (наприклад, вектор руху, напрям прогнозування, індекси опорного кадру і т. д.), зменшується. Вимога смуги пропускання пам'яті при відновленні інформації вектора руху від цих блоків-кандидатів може також бути зменшена. Фіг. 9 є послідовністю операцій, що ілюструє зразковий спосіб кодування відео, який може бути виконаний відеокодером, таким як відеокодер 20 згідно з Фіг. 3. Відеокодер 20 може бути сконфігурований, щоб визначити вектор руху відносно опорного кадру для поточного блока відеоданих (900). Відеокодер 20 може також визначити один з множини режимів (наприклад, режим злиття або AMVP) для процесу прогнозування вектора руху (901) і виконати процес прогнозування вектора руху для поточного блока відеоданих, використовуючи визначений режим і набір блоків-кандидатів. Набір блоків-кандидатів є однаковим для кожного з множини режимів. Множина режимів може включати в себе режим злиття і адаптивний режим прогнозування вектора руху. Фіг. 10 ілюструє зразковий спосіб кодування відео, коли процес прогнозування вектора руху знаходиться в режимі злиття. У цьому випадку відеокодер далі конфігурується, щоб визначити вектор-кандидат руху з набору блоків-кандидатів, який приводить до задовільної ефективності "спотворення-швидкість передачі", коли його вектор руху, опорний кадр і напрям прогнозування скопійовані в поточний блок (1001), і сигналізує індекс, що ідентифікує векторкандидат руху (1002). У одному прикладі набір блоків-кандидатів може включати в себе верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блоккандидат. Лівий блок-кандидат є суміжним з лівим краєм поточного блока і верхній край лівого блока-кандидата вирівняний з головного краю поточного блока. Вищезазначений блок-кандидат є суміжним з верхнім краєм поточного блока і лівий край вищезазначеного блока-кандидата вирівняний з лівим краєм поточного блока. У іншому прикладі лівий блок-кандидат є суміжним з лівим краєм поточного блока і нижній край лівого блока-кандидата вирівняний з нижнім краєм поточного блока. Вищезазначений блок-кандидат є суміжним з верхнім краєм поточного блока і правий край вищезазначеного блока-кандидата вирівняний з правим краєм поточного блока. У іншому прикладі набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блоккандидат і часовий блок-кандидат. Фіг. 11 ілюструє зразковий спосіб кодування відео, коли процес прогнозування вектора руху знаходиться в режимі AMVP. У цьому випадку, відеокодер конфігурується, щоб визначити вектор-кандидат руху з кожного блока-кандидата в наборі блоків-кандидатів (1101) і обчислити різницю векторів руху між вектором руху для поточного блока і вектором руху кандидата від кожного з блоків-кандидатів згідно з шаблоном перевірки (1102). Відеокодер також конфігурується, щоб вибрати один з векторів-кандидатів руху, на основі обчислених різниць вектора руху (1103), і сигналізувати індекс, що ідентифікує блок-кандидат, який має вибраний один з векторів-кандидатів руху, щоб сигналізувати різницю векторів руху, обчислену відносно вибраного одного з векторів-кандидатів руху, щоб сигналізувати опорний кадр, і сигналізувати напрям прогнозування (1104). У одному прикладі набір блоків-кандидатів включає в себе верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блоккандидат. У цьому прикладі шаблон перевірки відбувається в наступному порядку: нижній лівий блок-кандидат, лівий блок-кандидат, правий верхній блок-кандидат, верхній блок-кандидат, часовий блок-кандидат. У іншому прикладі набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блоккандидат і часовий блок-кандидат. Шаблон перевірки відбувається в наступному порядку: лівий блок-кандидат, нижній лівий блок-кандидат, верхній блок-кандидат, правий верхній блоккандидат, лівий верхній блок-кандидат, часовий блок-кандидат. Фіг. 12 є послідовністю операцій, що ілюструє зразковий спосіб декодування відео, який може бути виконаний відеодекодером, таким як відеодекодер 30 згідно з Фіг. 3. Відеодекодер 30 може бути сконфігурований, щоб прийняти елемент синтаксису, що вказує один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих (1201), і прийняти індекс, що вказує блок-кандидат з набору блоків-кандидатів (1202), в якому набір блоків-кандидатів є однаковим для кожного з множини режимів, і в якому інформація, асоційована з блоком-кандидатом, використовується, щоб декодувати вектор руху для 16 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 60 поточного блока. Множина режимів може включати в себе режим злиття і адаптивний режим прогнозування вектора руху. Фіг. 13 є послідовністю операцій, що ілюструє зразковий спосіб декодування відео у випадку, коли процес прогнозування вектора руху є режимом злиття. У цьому випадку відеодекодер далі конфігурується, щоб витягнути вектор руху, опорний кадр і напрям прогнозування, асоційовані з блоком-кандидатом, що має прийнятий індекс (1301), і виконати процес зовнішнього прогнозування відносно поточного блока, використовуючи витягнуті вектор руху, опорний кадр і напрям прогнозування (1302). У одному прикладі набір блоків-кандидатів включає в себе верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блоккандидат. Лівий блок-кандидат є суміжним з лівим краєм поточного блока і верхній край лівого блока-кандидата вирівняний з верхнім краєм поточного блока. Верхній блок-кандидат є суміжним з верхнім краєм поточного блока і лівий край верхнього блока-кандидата вирівняний з лівим краєм поточного блока. У іншому прикладі лівий блок-кандидат є суміжним з лівим краєм поточного блока і нижній край лівого блока-кандидата вирівняний з нижнім краєм поточного блока. Верхній блоккандидат є суміжним з верхнім краєм поточного блока і правий край верхнього блока-кандидата вирівняний з правим краєм поточного блока. У іншому прикладі набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блоккандидат і часовий блок-кандидат. Фіг. 14 є послідовністю операцій, що ілюструє зразковий спосіб декодування відео у випадку, коли процес прогнозування вектора руху є режимом AMVP. У цьому випадку відеодекодер конфігурується, щоб прийняти індекс опорного кадру, різницю векторів руху і елемент синтаксису, що вказує напрям прогнозування (1401), і витягувати вектор-кандидат руху, асоційований з блоком-кандидатом, що має прийнятий індекс (1402). Відеодекодер далі конфігурується, щоб обчислити вектор руху для поточного блока, використовуючи векторкандидат руху і різницю векторів руху (1403), і виконати процес зовнішнього прогнозування, використовуючи обчислений вектор руху, прийнятий індекс опорного кадру і прийнятий напрям прогнозування (1404). У одному прикладі набір блоків-кандидатів включає в себе верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блоккандидат, і шаблон перевірки для набору блоків-кандидатів має місце в наступному порядку: нижній лівий блок-кандидат, лівий блок-кандидат, правий верхній блок-кандидат, верхній блоккандидат, часовий блок-кандидат. У іншому прикладі набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блоккандидат і часовий блок-кандидат, і шаблон перевірки для набору блоків-кандидатів має місце в наступному порядку: лівий блок-кандидат, нижній лівий блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий верхній блок-кандидат, часовий блок-кандидат. Фіг. 15 є послідовністю операцій, що ілюструє інший зразковий спосіб кодування відео, яке може бути виконане відеокодером, таким як відеокодер 20 згідно з Фіг. 3. Відеокодер 20 може бути сконфігурований, щоб визначити вектор руху відносно опорного кадру для поточного блока відеоданих (1501), визначити один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих (1502) і виконати процес прогнозування вектора руху для поточного блока, використовуючи визначений режим і набір блоків-кандидатів, в якому набір блоків-кандидатів є однаковим для кожного з множини режимів, і в якому один блок-кандидат в наборі блоків-кандидатів визначається як додатковий блок-кандидат (1503). Додатковий блоккандидат використовується, якщо інший з блоків-кандидатів набору блоків-кандидатів недоступний. Відеокодер 20 може далі конфігуруватися, щоб оновити шаблон перевірки, на основі одного або більше з індексу злиття, визначеного режиму, розміру розділення, індексу опорного кадру, різниці векторів руху і прогнозування (1504) вектора руху. Згадана множина режимів може включати в себе режим злиття і адаптивний режим прогнозування вектора руху. Режим злиття може мати максимальну кількість N блоківкандидатів для використання при виконанні процесу прогнозування вектора руху. У цьому випадку процес прогнозування вектора руху виконується згідно з шаблоном перевірки, причому шаблон перевірки визначає порядок для перевірки кожного з блоків-кандидатів в наборі блоківкандидатів. Набір блоків-кандидатів визначений як перші N доступних блоків-кандидатів в наборі блоків-кандидатів вздовж шаблона перевірки. Шаблон перевірки може бути оснований на одному або більше з розміру блока, розміру розділення і індексу розділення. Більш конкретно, 17 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 60 наприклад, шаблон перевірки для кожного відмінного розміру блока, розміру розділення або індексу розділення може бути оновлений або змінений на основі статистики вибору кандидата в багатьох попередніх закодованих блоках, що мають один і той же розмір блока, розмір розділення або індекс розділення, і т. д. У іншому прикладі набір блоків-кандидатів включає в себе нижній лівий блок-кандидат, лівий блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий верхній блоккандидат і часовий блок-кандидат. У цьому прикладі додатковим блоком-кандидатом є лівий верхній блок-кандидат. Однак, додатковий блок-кандидат може бути будь-яким блокомкандидатом, який знаходиться в причинних відношеннях до поточного блока. Фіг. 16 є послідовністю операцій, що ілюструє інший зразковий спосіб декодування відео, який може бути виконаний відеодекодером, таким як відеодекодер 30 згідно з Фіг. 3. Відеодекодер 30 може бути сконфігурований, щоб прийняти елемент синтаксису, що вказує один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих (1601), і прийняти індекс, що вказує блок-кандидат з набору блоків-кандидатів, в якому набір блоків-кандидатів є однаковим для кожного з множини режимів, в якому один блоккандидат в наборі блоків-кандидатів визначається як додатковий блок-кандидат (1602). Додатковий блок-кандидат використовується, якщо інший з блоків-кандидатів набору блоківкандидатів недоступний. Інформація, асоційована з блоком-кандидатом, використовується, щоб декодувати вектор руху для поточного блока. Множина режимів може включати в себе режим злиття і адаптивний режим прогнозування вектора руху. Фіг. 17 зображає спосіб декодування у випадку, коли прийнятий елемент синтаксису вказує, що використовується режим злиття. У цьому випадку відеодекодер далі конфігурується, щоб витягнути вектор руху, опорний кадр і напрям прогнозування, асоційовані з блоком-кандидатом, що має прийнятий індекс (1701), і виконати процес зовнішнього прогнозування відносно поточного блока, використовуючи витягнутий вектор руху, опорний кадр і напрям прогнозування (1702). Режим злиття може бути визначений як такий, що має максимальну кількість N блоківкандидатів для використання при виконанні процесу прогнозування вектора руху. У цьому випадку процес прогнозування вектора руху може бути виконаний згідно з шаблоном перевірки, причому шаблон перевірки визначає порядок відносно перевірки кожного з блоків-кандидатів в наборі блоків-кандидатів. Набір блоків-кандидатів визначається як перші N доступних блоківкандидатів в наборі блоків-кандидатів вздовж шаблона перевірки. Шаблон перевірки оснований на одному або більше з розміру блока, розміру розділення і індексу розділення. У іншому прикладі, як для режиму злиття, так і для режиму AMVP, набір блоків-кандидатів може включати в себе нижній лівий блок-кандидат, лівий блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий верхній блок-кандидат і часовий блок-кандидат. Додатковий блок-кандидат є лівим верхнім блоком-кандидатом. Однак, додатковий блоккандидат може бути будь-яким блоком-кандидатом, який знаходиться в причинних відношеннях до поточного блока. Фіг. 18 зображає спосіб декодування у випадку, коли прийнятий елемент синтаксису вказує, що режим AMVP використовується. У цьому випадку відеодекодер далі конфігурується, щоб прийняти індекс опорного кадру, різницю векторів руху і елемент синтаксису, що вказує напрям прогнозування (1801), і витягувати вектор-кандидат руху, асоційований з блоком-кандидатом, що має прийнятий індекс (1802). Відеодекодер далі конфігурується, щоб обчислити вектор руху для поточного блока, використовуючи вектор-кандидат руху і різницю векторів руху (1803), і виконувати процес зовнішнього прогнозування, використовуючи обчислений вектор руху, прийнятий індекс опорного кадру і прийнятий напрям прогнозування (1804). У одному або більше прикладах описані функції можуть бути реалізовані в апаратному забезпеченні, програмному забезпеченні, програмно-апаратних засобах або будь-якій їх комбінації. Якщо реалізовані в програмному забезпеченні, функції можуть бути збережені або передані на, як одна або більше інструкцій або код, зчитуваний комп'ютером носій і виконані основаним на апаратному забезпеченні блоком обробки. Зчитуваний комп'ютером носій може включати в себе зчитувані комп'ютером носії даних, які відповідають матеріальному носію, такому як запам'ятовуючі носії даних, або комунікаційні носії, включаючи будь-який носій, який полегшує передачу комп'ютерної програми від одного місця до іншого, наприклад, згідно з протоколом зв'язку. У цьому способі зчитуваний комп'ютером носій звичайно може відповідати (1) матеріальним зчитуваним комп'ютером носіям даних, які є постійними, або (2) комунікаційному носію, такому як сигнал або несуча. Запам'ятовуючі носії даних можуть бути будь-яким доступним носієм, до якого можуть одержати доступ один або більше комп'ютерів або один або більше процесорів, щоб витягнути інструкції, код і/або структури даних для 18 UA 111971 C2 5 10 15 20 25 30 35 40 реалізації способів, описаних в цьому розкритті. Комп'ютерний програмний продукт може включати в себе зчитуваний комп'ютером носій. За допомогою прикладу, а не обмеження, такі зчитувані комп'ютером носії даних можуть містити RAM, ROM, EEPROM, CD-ROM або інший оптичний дисковий запам'ятовуючий пристрій, магнітний дисковий запам'ятовуючий пристрій або інші магнітні пристрої зберігання, флеш-пам'ять або будь-який інший носій, який може використовуватися, щоб зберегти бажаний програмний код в формі інструкцій або структур даних і до якого може одержати доступ комп'ютер. Також, будь-яке з'єднання належно називають зчитуваним комп'ютером носієм. Наприклад, якщо інструкції передані від веб-сайта, сервера або іншого віддаленого джерела, використовуючи коаксіальний кабель, волоконно-оптичний кабель, виту пару, цифрову абонентську лінію (DSL) або бездротові технології, такі як інфрачервона, радіо- і мікрохвильова, то цей коаксіальний кабель, волоконно-оптичний кабель, вита пара, DSL або бездротові технології, такі як інфрачервона, радіо- і мікрохвильова, включені у визначення носія. Треба мати на увазі, однак, що зчитувані комп'ютером носії даних і запам'ятовуючі носії даних не включають в себе з'єднання, несучі, сигнали або інші тимчасові носії, але замість цього направлені на постійні матеріальні носії даних. Диск і диск, як використовується тут, включають в себе компакт-диск (CD), лазерний диск, оптичний диск, цифровий універсальний диск (DVD), дискету і диск blu-ray, де диски (disks) звичайно відтворюють дані магнітним чином, в той час як диски (disсs) відтворюють дані оптично за допомогою лазерів. Комбінації вищезазначеного повинні також бути включені в рамки зчитуваного комп'ютером носія. Інструкції можуть бути виконані одним або більше процесорами, такими як один або більше цифрових сигнальних процесорів (DSPs), мікропроцесори загального призначення, спеціалізовані інтегральні схеми (ASIC), програмовані користувачем логічні матриці (FPGA) або інші еквівалентні інтегральні або дискретні логічні схеми. Відповідно, термін "процесор", як використовується тут, може стосуватися будь-якої відомої структури або будь-якої іншої структури, придатної для реалізації способів, описаних тут. Також, в деяких аспектах функціональні можливості, описані тут, можуть бути надані в межах спеціалізованого апаратного забезпечення і/або програмних модулів, сконфігурованих для кодування і декодування, або вбудованих в об'єднаний кодек. Також, способи могли бути повністю реалізовані в одній або більше схемах або логічних елементах. Способи даного розкриття можуть бути реалізовані в широкій різноманітності пристроїв або апаратів, включаючи бездротову телефонну трубку, інтегральну схему (IC) або набір IC (наприклад, мікропроцесорний набір). Різні компоненти, модулі або блоки описані в даному розкритті, щоб підкреслити функціональні аспекти пристроїв, конфігурованих, щоб виконувати розкриті способи, але не обов'язково вимагати реалізації різними блоками апаратного забезпечення. Замість цього, як описано вище, різні блоки можуть бути об'єднані в блоці апаратного забезпечення кодека або надані колекцією взаємодіючих блоків апаратного забезпечення, включаючи один або більше процесорів, як описано вище, в сполученні з придатним програмним забезпеченням і/або програмно-апаратними засобами. Були описані різні приклади. Ці і інші приклади знаходяться в рамках нижченаведеної формули винаходу. ФОРМУЛА ВИНАХОДУ 45 50 55 1. Спосіб кодування вектора руху в процесі кодування відео, який включає: визначення одного з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих, які повинні бути закодовані; і виконання процесу прогнозування вектора руху для поточного блока відеоданих, використовуючи визначений режим і набір блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів. причому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху, і причому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блоккандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат. 2. Спосіб за п. 1, в якому визначений режим є режимом злиття, і в якому спосіб також включає: визначення вектора-кандидата руху з набору блоків-кандидатів, який задовольняє поріг "спотворення-швидкість", і сигналізацію індексу, що ідентифікує вектор-кандидат руху. 19 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 3. Спосіб за п. 1, в якому визначеним режимом є адаптивний режим прогнозування вектора руху, і в якому спосіб також включає: визначення вектора-кандидата руху для кожного блока-кандидата в наборі блоків-кандидатів; обчислення різниці векторів руху між вектором руху для поточного блока і вектором-кандидатом руху для кожного з блоків-кандидатів згідно з шаблоном перевірки; вибір одного з векторів-кандидатів руху на основі обчислених різниць вектора руху; і сигналізацію індексу, що ідентифікує вибраний один з векторів-кандидатів руху, причому різницю векторів руху обчислюють відносно вибраного одного з векторів-кандидатів руху, опорного кадру і напряму прогнозування. 4. Спосіб за п. 3, в якому шаблон перевірки відбувається в порядку, починаючи з лівого блокакандидата. 5. Спосіб за п. 3, в якому шаблон перевірки відбувається в наступному порядку: від лівого блока-кандидата переходять до нижнього лівого блока-кандидата, від верхнього блокакандидата переходять до правого верхнього блока-кандидата. 6. Спосіб за п. 3, в якому шаблон перевірки відбувається в наступному порядку: лівий блоккандидат, нижній лівий блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий верхній блок-кандидат, часовий блок-кандидат. 7. Пристрій, сконфігурований, щоб кодувати вектор руху в процесі кодування відео, який містить: відеокодер, сконфігурований щоб: визначати один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих, які повинні бути закодовані; і виконувати процес прогнозування вектора руху для поточного блока відеоданих, використовуючи визначений режим і набір блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів, при цьому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху, і при цьому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блоккандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат. 8. Пристрій за п. 7, в якому визначений режим є режимом злиття, і в якому відеокодер додатково сконфігурований, щоб: визначати вектор-кандидат руху з набору блоків-кандидатів, який задовольняє поріг "спотворення-швидкість"; і сигналізувати індекс, що ідентифікує вектор-кандидат руху. 9. Пристрій за п. 7, в якому визначений режимом є адаптивний режим прогнозування вектора руху, і в якому відеокодер додатково сконфігурований, щоб: визначати вектор-кандидат руху для кожного блока-кандидата в наборі блоків-кандидатів; обчислювати різницю векторів руху між вектором руху для поточного блока і векторомкандидатом руху для кожного з блоків-кандидатів згідно з шаблоном перевірки; вибирати один з векторів-кандидатів руху на основі обчислених різниць вектора руху; і сигналізувати індекс, що ідентифікує вибраний один з векторів-кандидатів руху, причому різниця векторів руху обчислена відносно вибраного одного з векторів-кандидатів руху, опорного кадру і напряму прогнозування. 10. Пристрій за п. 9, в якому шаблон перевірки відбувається в порядку, починаючи з лівого блока-кандидата. 11. Пристрій за п. 9, в якому шаблон перевірки відбувається в наступному порядку: від лівого блока-кандидата переходять до нижнього лівого блока-кандидата, від верхнього блокакандидата переходять до правого верхнього блока-кандидата. 12. Пристрій за п. 9, в якому шаблон перевірки відбувається в наступному порядку: лівий блоккандидат, нижній лівий блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий верхній блок-кандидат, часовий блок-кандидат. 13. Пристрій, сконфігурований, щоб кодувати вектор руху в процесі кодування відео, який містить: засіб для того, щоб визначити один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих, які повинні бути закодовані; і засіб для того, щоб виконати процес прогнозування вектора руху для поточного блока відеоданих, використовуючи визначений режим і набір блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів, 20 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 60 при цьому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху, і при цьому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блоккандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат. 14. Зчитуваний комп'ютером носій даних, що зберігає інструкції, які, коли виконуються, змушують процесор пристрою для кодування відеоданих: визначати один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих, які повинні бути закодовані; і виконувати процес прогнозування вектора руху для поточного блока відеоданих, використовуючи визначений режим і набір блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів, при цьому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху, і при цьому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блоккандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат. 15. Спосіб декодування вектора руху в процесі кодування відео, який включає: визначення одного з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих; і визначення блока-кандидата з набору блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів, і в якому інформація, асоційована з блокомкандидатом, використовується, щоб декодувати вектор руху для поточного блока, при цьому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху, і при цьому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блоккандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат. 16. Спосіб за п. 15, який додатково включає: прийом елемента синтаксису, що вказує процес прогнозування вектора руху, в якому прийнятий елемент синтаксису вказує, що процес прогнозування вектора руху є режимом злиття; прийом індексу, що вказує блок-кандидат; витягання вектора руху, опорного кадру і напряму прогнозування, асоційованих з блокомкандидатом, що має прийнятий індекс; і виконання процесу зовнішнього прогнозування відносно поточного блока, використовуючи витягнуті вектор руху, опорний кадр і напрям прогнозування. 17. Спосіб за п. 15, який додатково включає: прийом елемента синтаксису, що вказує процес прогнозування вектора руху, в якому прийнятий елемент синтаксису вказує, що процес прогнозування вектора руху є адаптивним режимом прогнозування вектора руху; прийом індексу, що вказує блок-кандидат; прийом індексу опорного кадру, різниці векторів руху і елемента синтаксису, що вказує напрям прогнозування; витягання вектора-кандидата руху, асоційованого з блоком-кандидатом, що має прийнятий індекс; обчислення вектора руху для поточного блока, використовуючи вектор-кандидат руху і різницю векторів руху; і виконання процесу зовнішнього прогнозування, використовуючи обчислений вектор руху, прийнятий індекс опорного кадру і прийнятий напрям прогнозування. 18. Спосіб за п. 17, в якому шаблон перевірки відбувається в порядку, починаючи з лівого блока-кандидата. 19. Спосіб за п. 17, в якому шаблон перевірки відбувається в наступному порядку: від лівого блока-кандидата переходять до нижнього лівого блока-кандидата, від верхнього блокакандидата переходять до правого верхнього блока-кандидата. 20. Спосіб за п. 17, в якому шаблон перевірки відбувається в наступному порядку: лівий блоккандидат, нижній лівий блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий верхній блок-кандидат, часовий блок-кандидат. 21. Пристрій, сконфігурований, щоб декодувати вектор руху в процесі кодування відео, який містить: відеодекодер, сконфігурований щоб: 21 UA 111971 C2 5 10 15 20 25 30 35 40 45 50 55 визначати один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих; і визначати блок-кандидат з набору блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів, і при цьому інформація, асоційована з блокомкандидатом, використовується, щоб декодувати вектор руху для поточного блока, при цьому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху, при цьому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блоккандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат. 22. Пристрій за п. 21, в якому відеодекодер додатково сконфігурований, щоб: прийняти елемент синтаксису, що вказує процес прогнозування вектора руху, при цьому прийнятий елемент синтаксису вказує, що процес прогнозування вектора руху є режимом злиття; прийняти індекс, що вказує блок-кандидат; витягнути вектор руху, опорний кадр і напрям прогнозування, асоційовані з блоком-кандидатом, що має прийнятий індекс; і виконувати процес зовнішнього прогнозування відносно поточного блока, використовуючи витягнуті вектор руху, опорний кадр і напрям прогнозування. 23. Пристрій за п. 21, в якому відеодекодер додатково сконфігурований, щоб: прийняти елемент синтаксису, що вказує процес прогнозування вектора руху, в якому прийнятий елемент синтаксису вказує, що процес прогнозування вектора руху є адаптивним режимом прогнозування вектора руху; прийняти індекс, що вказує блок-кандидат; прийняти індекс опорного кадру, різницю векторів руху і елемент синтаксису, що вказує напрям прогнозування; витягнути вектор-кандидат руху, асоційований з блоком-кандидатом, що має прийнятий індекс; обчислювати вектор руху для поточного блока, використовуючи вектор-кандидат руху і різницю векторів руху; і виконувати процес зовнішнього прогнозування, використовуючи обчислений вектор руху, прийнятий індекс опорного кадру і прийнятий напрям прогнозування. 24. Пристрій за п. 23, в якому шаблон перевірки відбувається в порядку, починаючи з лівого блока-кандидата. 25. Пристрій за п. 23, в якому шаблон перевірки відбувається в наступному порядку: від лівого блока-кандидата переходять до нижнього лівого блока-кандидата, від верхнього блокакандидата переходять до правого верхнього блока-кандидата. 26. Пристрій за п. 23, в якому шаблон перевірки відбувається в наступному порядку: лівий блоккандидат, нижній лівий блок-кандидат, верхній блок-кандидат, правий верхній блок-кандидат, лівий верхній блок-кандидат, часовий блок-кандидат. 27. Пристрій, сконфігурований, щоб декодувати вектор руху в процесі кодування відео, який містить: засіб для того, щоб визначити один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих; і засіб для того, щоб визначити блок-кандидат з набору блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів, і при цьому інформація, асоційована з блоком-кандидатом, використовується, щоб декодувати вектор руху для поточного блока, при цьому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху, при цьому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блоккандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат. 28. Зчитуваний комп'ютером носій даних, що зберігає інструкції, які, коли виконуються, змушують процесор пристрою для декодування відеоданих: визначати один з множини режимів для процесу прогнозування вектора руху для поточного блока відеоданих; і визначати блок-кандидат з набору блоків-кандидатів, при цьому набір блоків-кандидатів є однаковим для кожного з множини режимів, і в якому інформація, асоційована з блокомкандидатом, використовується, щоб декодувати вектор руху для поточного блока, 22 UA 111971 C2 5 при цьому множина режимів включає в себе режим злиття і адаптивний режим прогнозування вектора руху, при цьому набір блоків-кандидатів включає в себе лівий верхній блок-кандидат, верхній блоккандидат, правий верхній блок-кандидат, лівий блок-кандидат, нижній лівий блок-кандидат і часовий блок-кандидат. 23 UA 111971 C2 24 UA 111971 C2 25 UA 111971 C2 26 UA 111971 C2 27 UA 111971 C2 28
ДивитисяДодаткова інформація
Назва патенту англійськоюUnified merge mode and adaptive motion vector prediction mode candidates selection
Автори англійськоюZheng, Yunfei, Wang, Xianglin, Karczewicz, Marta
Автори російськоюЧжен Юньфей, Ван Сянлинь, Карчевич Марта
МПК / Мітки
МПК: H04N 19/40, H04N 19/52, H04N 19/51
Мітки: єдиних, руху, режиму, злиття, кандидатів, адаптивного, вибір, прогнозування, вектора
Код посилання
<a href="https://ua.patents.su/39-111971-vibir-ehdinikh-kandidativ-rezhimu-zlittya-i-adaptivnogo-rezhimu-prognozuvannya-vektora-rukhu.html" target="_blank" rel="follow" title="База патентів України">Вибір єдиних кандидатів режиму злиття і адаптивного режиму прогнозування вектора руху</a>
Виконання прогнозування вектора руху для відеокодування
Номер патенту: 107152
Опубліковано: 25.11.2014
Автори: Чіень Вей-Цзюн, Чень Пейсун, Кобан Мухаммед Зейд, Карчевіч Марта
МПК: H04N 7/00
Мітки: прогнозування, руху, вектора, відеокодування, виконання
Формула / Реферат:
1. Спосіб кодування відеоданих, причому спосіб включає етапи, на яких:визначають просторові вектори руху-кандидати, пов'язані з поточною ділянкою поточного відеокадру, при цьому просторові вектори руху-кандидати містять вектори руху, визначені для сусідніх ділянок поточного відеокадру, прилеглих до поточної ділянки;визначають часовий вектор руху-кандидат, пов'язаний з поточною ділянкою поточного відеокадру, при цьому часовий...
Кодування відео, використовуючи адаптивне розрізнення вектора руху
Номер патенту: 110981
Опубліковано: 10.03.2016
Автори: Карчєвіч Марта, Чіень Вей-Цзюн, Чень Пейсун
МПК: H04N 19/61, H04N 19/513, H04N 19/52, H04N 19/13, H04N 19/70
Мітки: розрізнення, кодування, відео, руху, вектора, адаптивне, використовуючи
Формула / Реферат:
1. Спосіб ентропійного кодування відеоданих, причому спосіб включає: коли абсолютне значення -компоненти значення різниці векторів руху для поточного блока більше ніж нуль, і коли абсолютне значення -компоненти значення різниці векторів руху для поточного блока більше ніж нуль, ентропійне кодування...
Система еволюційного прогнозування синергетичного ефекту злиття та поглинання підприємств
Номер патенту: 104435
Опубліковано: 25.01.2016
Автори: Іванченко Геннадій Федорович, Іванченко Надія Олександрівна, Бадер Омар Ахмад Далайін
МПК: G06Q 50/00, G06Q 90/00
Мітки: еволюційного, поглинання, підприємств, синергетичного, ефекту, злиття, прогнозування, система
Формула / Реферат:
Система еволюційного прогнозування синергетичного ефекту злиття та поглинання підприємств, що містить арифметичні блоки для розрахунку числових значень динаміки доходів популяцій в трофічній мережі відносин, вихід кожного арифметичного блока з'єднано з входом одного інтегруючого блока, вихід кожного інтегруючого блока з'єднано через пропорційний блок з входом власного арифметичного блока, вихід якого було подано на вхід цього інтегруючого...
Спосіб прогнозування вектора стану центра мас космічного апарата на орбіті
Номер патенту: 104485
Опубліковано: 10.02.2014
Автори: Озеряний Сергій Анатолійович, Іванов Володимир Іванович
МПК: B64G 1/24
Мітки: прогнозування, стану, космічного, мас, апарата, вектора, центра, орбіти, спосіб
Формула / Реферат:
Спосіб прогнозування вектора стану центра мас космічного апарата на орбіті, який полягає у тому, що система диференціальних рівнянь руху центра мас космічного апарата вирішують методом чисельного інтегрування Рунге-Кута, який відрізняється тим, що інтегрування проводиться з кроком більшим, ніж потрібний крок формування вектора стану КА, а для його визначення з потрібним кроком застосовується екстраполяція поліноміальною функцією, яка...
Вказівка вибору режиму внутрішнього прогнозування для відеокодування з використанням cabac
Номер патенту: 108684
Опубліковано: 25.05.2015
Автори: Чіень Вей-Цзюн, Карчевіч Марта, Ван Сянлінь
МПК: H04N 7/24
Мітки: вказівка, використанням, внутрішнього, вибору, режиму, cabac, прогнозування, відеокодування
Формула / Реферат:
1. Спосіб декодування відеоданих, причому спосіб включає:визначення першого найбільш ймовірного режиму внутрішнього прогнозування і другого найбільш ймовірного режиму внутрішнього прогнозування для поточного блока відеоданих на основі контексту для поточного блока,виконання процесу контекстно-адаптивного двійкового арифметичного кодування (САВАС) для визначення прийнятого кодового слова, що відповідає модифікованому індексу...
Попередній патент: Пристрій для проходки дробленням скельної породи, мінералів або інших матеріалів
Наступний патент: Вагінальна таблетка, яка містить рифаксимін, спосіб її виготовлення та застосування для лікування вагінальних інфекцій
Випадковий патент: Пристрій вакуумування матриці-гайки для формування зовнішньої різьби на кінці склопластикової труби