Буферизація даних прогнозування при кодуванні відео

Реферат: У прикладі аспекти цього розкриття стосуються способу кодування відеоданих, який загалом включає в себе визначення інформації прогнозування для блока відеоданих, при цьому блок включений в кодований елемент відеоданих і розташовується нижче верхнього рядка верхніх сусідніх блоків у кодованому елементі, і де інформація прогнозування для блока основана на інформації прогнозування від одного або декількох блоків у кодованому елементі, але не основана на інформації прогнозування з будь-якого з блоків верхнього рядка в кодованому елементі. Спосіб також загалом включає в себе кодування блока на основі визначеної інформації прогнозування. UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 За даною заявкою заявляється пріоритет відповідно до попередньої заявки на патент США № 61/509,933, поданої 20 липня 2011 року, і попередньої заявки на патент США № 61/522,136, поданої 10 серпня 2011 року, повний зміст кожної з яких включений сюди за допомогою посилання. ГАЛУЗЬ ТЕХНІКИ, ДО ЯКОЇ НАЛЕЖИТЬ ВИНАХІД Це розкриття стосується кодування відео і, точніше, ентропійного кодування відеоданих. РІВЕНЬ ТЕХНІКИ Можливості цифрового відео можуть застосовуватися для широкого спектра пристроїв, включаючи цифрове телебачення, цифрові системи прямого мовлення, бездротові системи мовлення, персональні цифрові помічники (PDA), портативні та настільні комп'ютери, планшетні комп'ютери, пристрої для читання електронних книг, цифрові камери, цифрові записуючі пристрої, цифрові медіаплеєри, пристрої для відеоігор, ігрові відеоприставки, стільникові або супутникові радіотелефони, так звані "смартфони", пристрої для відеоконференцзв'язку, пристрої для поширення потокового відео тощо. Цифрові відеопристрої реалізовують методики стиснення відео, такі як ті, що описуються в стандартах, визначених MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, Частина 10, стандарті вдосконаленого кодування відео (AVC), стандарті кодування відео високої ефективності (HEVC), що зараз знаходиться в розробці, і доповненнях до таких стандартів. Відеопристрої можуть передавати, приймати, кодувати, декодувати і/або зберігати цифрову відеоінформацію більш ефективно шляхом застосування таких методик стиснення відео. Методики стиснення відео здійснюють просторове (всередині зображення) прогнозування і/або часове (між зображеннями) прогнозування, щоб знизити або усунути надмірність, властиву відеопослідовностям. Для кодування відео на основі блоків відеофрагмент (тобто відеозображення або частина відеозображення) може бути розбитий на відеоблоки, які також можуть іменуватися деревоподібними блоками, елементами кодування (CU) і/або вузлами кодування. Відеоблоки у фрагменті зображення, який піддався внутрішньому кодуванню (I), кодуються з використанням просторового прогнозування відносно опорних вибірок у сусідніх блоках того самого зображення. Відеоблоки у фрагменті зображення, який піддався зовнішньому кодуванню (Р або В), можуть використовувати просторове прогнозування відносно опорних вибірок у сусідніх блоках того самого зображення або часове прогнозування відносно опорних вибірок в інших опорних зображеннях. Просторове або часове прогнозування одержує в результаті предиктивний блок для блока, що підлягає кодуванню. Залишкові дані відображають різниці пікселів між оригінальним блоком, що підлягає кодуванню, і предиктивним блоком. Блок, що піддався зовнішньому кодуванню, кодується відповідно до вектора руху, який вказує на блок опорних вибірок, що формують предиктивний блок, і залишкових даних, що відображають різницю між кодованим блоком і предиктивним блоком. Блок, що піддався внутрішньому кодуванню, кодується відповідно до режиму внутрішнього кодування і залишкових даних. Для додаткового стиснення залишкові дані можуть перетворюватися з піксельної ділянки в ділянку перетворення, даючи в результаті залишкові коефіцієнти перетворення, які можуть бути квантовані. Квантовані коефіцієнти перетворення, спочатку впорядковані в двомірний масив, можуть скануватися з метою створити одномірний вектор коефіцієнтів перетворення, а ентропійне кодування може застосовуватися, щоб досягнути ще більшого стиснення. СУТЬ ВИНАХОДУ Загалом, це розкриття описує методики для кодування відеоданих. Наприклад, методики за даним розкриттям включають в себе зменшення кількості даних, які буферизуються при виконанні методик прогнозування при кодуванні відео. Тобто просторове прогнозування (тобто внутрішнє прогнозування) або часове прогнозування (тобто зовнішнє прогнозування) може використовуватися для зниження або усунення надмірності у відеопослідовності. При кодуванні відео на основі блоків відеодані з одного блока можуть використовуватися як інформація прогнозування для одного або декількох блоків відеоданих. Інформація прогнозування, зв'язана з одним або декількома сусідніми блоками блока, що кодується в даний момент, може зберігатися (тобто буферизуватися) так, що інформація прогнозування доступна для кодування поточного блока. Методики цього розкриття стосуються обмеження кількості інформації прогнозування з сусідніх блоків, яка буферизується під час кодування. Відповідно до деяких аспектів цього розкриття пристрій для кодування відео може уникати використання інформації прогнозування з блоків відеоданих, які розташовуються над блоком відеоданих, який кодується в поточний момент (наприклад, які іменуються "верхні сусідні блоки"), при кодуванні поточного блока. 1 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 У прикладі аспекти цього розкриття стосуються способу кодування відеоданих, який включає в себе визначення інформації прогнозування для блока відеоданих, при цьому блок включений в кодований елемент відеоданих і розташовується нижче верхнього рядка верхніх сусідніх блоків у кодованому елементі, і при цьому інформація прогнозування для блока основана на інформації прогнозування від одного або декількох інших блоків у кодованому елементі, але не основана на інформації прогнозування з будь-якого з блоків верхнього рядка в кодованому елементі; і кодування блока на основі визначеної інформації прогнозування. В іншому прикладі аспекти цього розкриття стосуються пристрою для кодування відеоданих. У цьому прикладі пристрій включає в себе один або декілька процесорів, виконаних з можливістю визначати інформацію прогнозування для блока відеоданих, при цьому блок включений в кодований елемент відеоданих і розташовується нижче верхнього рядка верхніх сусідніх блоків у кодованому елементі, і при цьому інформація прогнозування для блока основана на інформації прогнозування від одного або декількох блоків у кодованому елементі, але не основана на інформації прогнозування з будь-якого з блоків верхнього рядка в кодованому елементі; і кодувати блок на основі визначеної інформації прогнозування. В іншому прикладі аспекти цього розкриття стосуються постійного машинозчитуваного носія, на якому зберігаються команди, які при виконанні приписують одному або декільком процесорам визначати інформацію прогнозування для блока відеоданих, при цьому блок включений в кодований елемент відеоданих і розташовується нижче верхнього рядка верхніх сусідніх блоків у кодованому елементі, і при цьому інформація прогнозування для блока основана на інформації прогнозування від одного або декількох інших блоків у кодованому елементі, але не основана на інформації прогнозування з будь-якого з блоків верхнього рядка в кодованому елементі; і кодувати блок на основі визначеної інформації прогнозування. В іншому прикладі аспекти цього розкриття стосуються пристрою для кодування відеоданих. У цьому прикладі пристрій включає в себе засіб для визначення інформації прогнозування для блока відеоданих, при цьому блок включений в кодований елемент відеоданих і розташовується нижче верхнього рядка верхніх сусідніх блоків у кодованому елементі, і при цьому інформація прогнозування для блока основана на інформації прогнозування від одного або декількох інших блоків у кодованому елементі, але не основана на інформації прогнозування з будь-якого з блоків верхнього рядка в кодованому елементі; і засіб для кодування блока на основі визначеної інформації прогнозування. Деталі одного або декількох аспектів розкриття викладаються в прикладених кресленнях і представленому нижче описі. Інші ознаки, задачі та переваги методик, описаних в цьому розкритті, будуть зрозумілі з опису і креслень, а також з формули винаходу. КОРОТКИЙ ОПИС КРЕСЛЕНЬ Фіг. 1 являє собою блок-схему, яка ілюструє зразкову систему кодування і декодування відео, яка може застосовувати методики, описані в цьому розкритті. Фіг. 2 являє собою блок-схему, яка ілюструє зразковий відеокодер, який може застосовувати методики, описані в цьому розкритті. Фіг. 3 являє собою блок-схему, яка ілюструє зразковий відеодекодер, який може застосовувати методики, описані в цьому розкритті. Фіг. 4А та фіг. 4В являють собою концептуальні схеми, які ілюструють зразкове квадрадерево і відповідний найбільший елемент кодування (LCU). Фіг. 5 являє собою схему, яка ілюструє зразкові сусідні блоки, на основі яких може бути визначений найбільш імовірний внутрішній режим. Фіг. 6 являє собою схему, яка ілюструє зразкові точки розташування для кандидатів для предиктора вектора руху. Фіг. 7 являє собою схему, яка ілюструє зразкові сусідні блоки, на основі яких може бути визначена інформація прогнозування для кодування блока. Фіг. 8 являє собою іншу схему, яка ілюструє зразкові сусідні блоки, на основі яких може бути визначена інформація прогнозування для кодування блока. Фіг. 9 являє собою іншу схему, яка ілюструє зразкові сусідні блоки, на основі яких може бути визначена інформація прогнозування для кодування блока. Фіг. 10 являє собою іншу схему, яка ілюструє зразкові сусідні блоки, на основі яких може бути визначена інформація прогнозування для кодування блока. Фіг. 11 являє собою концептуальну схему, яка ілюструє приклад обмеження інформації прогнозування одного або декількох сусідніх блоків. Фіг. 12 являє собою іншу концептуальну схему, яка ілюструє приклад обмеження інформації прогнозування одного або декількох сусідніх блоків. 2 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 Фіг. 13 являє собою блок-схему, яка ілюструє граничні елементи кодування найбільшого елемента кодування. Фіг. 14 являє собою блок-схему послідовності операцій, що ілюструє зразкові методики для скорочення кількості інформації прогнозування, яка буферизується під час кодування відео. Фіг. 15 являє собою блок-схему послідовності операцій, що ілюструє зразкові методики для скорочення кількості інформації прогнозування, яка буферизується при виконанні внутрішнього прогнозування. Фіг. 16 являє собою блок-схему послідовності операцій, що ілюструє зразкові методики для скорочення кількості інформації прогнозування, яка буферизується при виконанні внутрішнього прогнозування. Фіг. 17 являє собою блок-схему послідовності операцій, що ілюструє зразкові методики для скорочення кількості інформації прогнозування, яка буферизується при виконанні зовнішнього прогнозування. Фіг. 18 являє собою блок-схему послідовності операцій, що ілюструє зразкові методики для скорочення кількості інформації прогнозування, яка буферизується при виконанні зовнішнього прогнозування. ДОКЛАДНИЙ ОПИС Пристрій для кодування відео може намагатися стискувати відеодані шляхом використання просторової і/або часової надмірності. Наприклад, відеокодер може скористатися просторовою надмірністю шляхом кодування блока відносно сусідніх, раніше кодованих блоків. Подібним чином, відеокодер може скористатися часовою надмірністю шляхом кодування блока відносно даних раніше кодованих зображень. Зокрема, відеокодер може здійснювати прогнозування поточного блока виходячи з даних просторового сусіда або з даних раніше кодованого зображення. Потім відеокодер може обчислювати залишок для блока як різницю між дійсними значеннями пікселя для блока і прогнозованими значеннями пікселя для блока. Відповідно, залишок для блока може включати в себе значення різниці піксель-за-пікселем у піксельній (або просторовій) ділянці. Що стосується внутрішнього кодування, то відеокодер може генерувати предиктивний блок відповідно до визначеного заздалегідь режиму внутрішнього кодування. Відеокодер може відняти значення предиктивного блока із значення блока, що кодується в даний момент, щоб одержати блок залишкових даних. Відеокодер може передавати режим внутрішнього прогнозування і блок залишкових даних у кодованому бітовому потоці, який може бути декодованим декодером. Декодер може генерувати такий самий предиктивний блок (наприклад, використовуючи той самий режим внутрішнього прогнозування) і відтворювати кодований відеоблок шляхом комбінування залишкових даних з даними предиктивного блока. Новий стандарт HEVC може використовувати не менше тридцяти п'яти або більше режимів внутрішнього прогнозування. Щоб скоротити кількість бітів, необхідних для передачі режиму внутрішнього прогнозування, вибраного відеокодером, відеокодер може ідентифікувати режими внутрішнього прогнозування для вже кодованих відеоблоків, таких як один або декілька просторово сусідніх блоків. На основі режимів внутрішнього прогнозування цих сусідніх блоків відеокодер може ідентифікувати найбільш імовірний режим внутрішнього прогнозування для поточного відеоблока. Найбільш імовірний режим внутрішнього прогнозування являє собою режим внутрішнього прогнозування, який найбільш ймовірно буде використовуватися для кодування поточного відеоблока на основі контексту для поточного блока. Контекст може, наприклад, визначатися деякою комбінацією режимів внутрішнього прогнозування, що використовуються для сусідніх блоків, розміром поточного блока та іншими факторами. Фактори, що використовуються відеокодером, щоб визначити контекст для поточного відеоблока, також актуальні для відеодекодера. Так, найбільш імовірний режим внутрішнього прогнозування, визначений відеокодером, також може бути визначений відеодекодером без необхідності явно передаватися до відеодекодера. Найбільш імовірний режим внутрішнього прогнозування може бути, а може і не бути одним і таким самим, що і режим внутрішнього прогнозування, який фактично використовується, щоб кодувати поточний блок. Дійсний режим внутрішнього прогнозування може бути визначений відеокодером на основі того, який режим внутрішнього прогнозування формує кращу якість відновленого відео. Відеокодер може генерувати синтаксичний елемент для включення в бітовий потік, що відображає, чи є найбільш імовірний режим внутрішнього прогнозування таким самим, як і дійсний режим прогнозування для поточного відеоблока. Синтаксичний елемент може, наприклад, бути одним бітом, де "1" відображає, що дійсний режим внутрішнього прогнозування є найбільш імовірним режимом внутрішнього прогнозування, а "0" відображає, що дійсний режим внутрішнього прогнозування не є найбільш імовірним режимом внутрішнього 3 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 прогнозування. Так, коли дійсний режим внутрішнього прогнозування для поточного відеоблока є найбільш імовірним режимом внутрішнього прогнозування, дійсний режим внутрішнього прогнозування для поточного відеоблока може бути переданий від кодера до декодера при використанні одного біта ("1" в цьому прикладі). У прикладах, де дійсний режим внутрішнього прогнозування не є найбільш імовірним режимом внутрішнього прогнозування, дійсний режим внутрішнього прогнозування може бути переданий з кодовим словом, наступним за першим бітом (тобто перший біт "0", за яким йде кодове слово). Що стосується зовнішнього кодування, відеокодер може генерувати вектор руху, щоб ідентифікувати предиктивний блок відеоданих, наприклад, з іншого відеозображення або фрагмента, який може використовуватися для прогнозування значення блока, що кодується в даний момент. Відеокодер може відняти значення предиктивного блока із значень поточного блока, щоб створити блок залишкових даних. Загалом, відеокодер може передавати вектор руху і залишкові дані в кодованому бітовому потоці, який може бути декодований декодером. Декодер може розташовувати один і той самий предиктивний блок (наприклад, на основі вектора руху) серед групи декодованих блоків у декодованому буфері зображень і відновлювати кодований відеоблок шляхом поєднання залишкових даних з даними предиктивного блока. У деяких випадках кодування з прогнозуванням векторів руху також застосовується, щоб додатково скоротити кількість даних, необхідних для повідомлення вектора руху. У цьому випадку, замість кодування і передачі самого вектора руху, кодер кодує і передає різницю вектора руху (MVD) відносно відомого (або пізнаваного) вектора руху. Відомий вектор руху, який може використовуватися з MVD, щоб визначити поточний вектор руху, може бути визначений так званим предиктором вектора руху (MVP). Може застосовуватися процес, який називається в новому стандарті HEVC адаптивним прогнозуванням вектора руху (AMVP) і в якому група кандидатів векторів руху будується з декількох сусідніх блоків у просторовому і часовому напрямках. Група кандидатів векторів руху включає в себе множину кандидатів MVP. У цьому випадку відеокодер вибирає найбільш точний предиктор з групи кандидатів на основі аналізу швидкості кодування і спотворення (наприклад, використовуючи так званий аналіз витрат швидкості-спотворення). Індекс предиктора вектора руху (mvp_idx) може передаватися до відеодекодера, щоб повідомити декодеру, де розташувати MVP, тобто який з кандидатів MVP повинен використовуватися для декодування. MVD також передається. Декодер може комбінувати MVD з MVP (визначений індексом предиктора вектора руху), щоб відновити вектор руху. Так званий "режим злиття" також може бути доступний, в ньому інформація руху (наприклад, вектори руху, індекси опорного прогнозування, напрямки прогнозування або інша інформація) сусіднього відеоблока успадковується від поточного відеоблока, що піддається кодуванню. Значення індексу може використовуватися, щоб ідентифікувати сусіда, від якого поточний відеоблок успадковує інформацію руху (наприклад, від верхнього, верхнього правого, лівого або суміщеного з часово суміжним кадром). Режим злиття використовує інформацію руху одного з декількох блоків-кандидатів, але не покладається на MVD. Відповідно, це розкриття загалом іменує "інформацію прогнозування" інформацією внутрішнього прогнозування і/або інформацією зовнішнього прогнозування для генерації предиктивного блока відеоданих. Тобто, що стосується внутрішнього кодування, інформація прогнозування може відноситися до режиму внутрішнього кодування, що використовується, щоб кодувати блок відеоданих. Інформація прогнозування також може відноситися до режимів внутрішнього кодування сусідніх блоків, в яких у прикладах такі сусідні режими внутрішнього кодування використовуються для кодування блока (наприклад, з використанням процесу виведення найбільш імовірного режиму, описаного вище). Додатково або як альтернатива, для зовнішнього прогнозування інформація прогнозування може відноситися до інформації руху (наприклад, векторів руху, індексів опорного зображення, напрямків прогнозування або іншої інформації), що використовується, щоб кодувати блок відеоданих. Інформація прогнозування також може відноситися до інформації руху сусідніх блоків, в яких у прикладах така сусідня інформація руху використовується для кодування блока (наприклад, з використанням процесів AMVP і режиму злиття, описаних вище). У будь-якому випадку інформація прогнозування може зберігатися в так званому "лінійному буфері" - так, що інформація прогнозування доступна для посилання під час кодування. Що стосується внутрішнього кодування, то відеокодер може зберігати інформацію руху (наприклад, вектори руху (mvx, mvy), індекси опорного зображення (ref_idx), напрямки прогнозування (inter_dir) або іншу інформацію) для кожного з блоків. Лінійний буфер може зберігати 4 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 інформацію прогнозування, зв'язану з лінією блоків, розташованих над блоком або фрагментом, що кодується в поточний момент, і звичайно тягнеться по всій ширині зображення. Лінійний буфер може включати в себе пам'ять, до якої може мати доступ відеокодер. Лінійний буфер може підводити баланс між інформацією прогнозування буферизації для цілого кадру, яка може бути відносно великою кількістю даних, і інформацією прогнозування буферизації, яка має найвищий потенціал до того, щоб бути доступною під час кодування. Тобто в деяких прикладах тільки інформація прогнозування, що найчастіше використовується, теж зберігатися в лінійному буфері в межах можливого. Однак в міру того як розрізнення відео і ширина кадрів (наприклад, кількість пікселів праворуч наліво по заданому відеокадру) збільшуються, кількість даних, які зберігаються в лінійному буфері, також збільшується. У деяких прикладах блоки відеоданих у межах 4 × 4 пікселів можуть використовуватися, щоб кодувати зображення. Як приклад зображення 1920 × 1080 пікселів (наприклад, для відео 1080р) може включати в себе до 495 блоків 4 × 4 пікселя. Відповідно, якщо інформація прогнозування зберігається для кожного блока відеоданих, від відеокодера може бути потрібне зберігання відносно значної кількості даних для лінійного буфера. Методики цього розкриття загалом стосуються обмеження або скорочення кількості інформації прогнозування від сусідніх блоків, яка буферизується під час кодування. Наприклад, замість використання інформації прогнозування з верхніх сусідніх блоків при кодуванні поточного блока, в деяких прикладах пристрій для кодування відео може визначати інформацію прогнозування на основі інформації прогнозування з лівих сусідніх блоків. В інших прикладах пристрій для кодування відео може визначати інформацію прогнозування на основі даних з верхнього сусіднього блока, але тільки коли поточний блок є субблоком більшого розділу (наприклад, який називається в стандарті кодування відео високої ефективності (HEVC) найбільшим елементом кодування (LCU), що описується більш детально нижче), і такий субблок не межує з іншим LCU. Різноманіття інших методик, як описується нижче, також може використовуватися, щоб скоротити кількість предиктивної інформації, яка буферизується під час кодування відео. Обмеження кількості даних, яка буферизується, відповідно до методик цього розкриття, може зменшити складності, пов'язані з кодуванням відеоданих. Наприклад, аспекти цього розкриття можуть дозволити пристрою для кодування відео буферизувати менше даних, таким чином знижуючи вимоги допам'яті, зв'язані з такою буферизацією. Крім того, скорочення точок розташування, від яких можна одержати інформацію прогнозування, може збільшити ефективність ентропійного кодування і/або пропускну здатність. Наприклад, методики цього розкриття можуть застосовуватися, щоб поліпшити пропускну здатність при аналізі. Тобто в міру того як відеодані приймаються відеокодером, відеодані можуть бути проаналізовані (наприклад, зчитані та сегментовані) відповідно до конкретного процесу аналізу (наприклад, аналізу хвильового фронту). У деяких прикладах процес аналізу може включати в себе аналіз кожного LCU фрагмента після аналізу одного або декількох вихідних LCU (наприклад, верхнього і/або найлівішого LCU у фрагменті). Аналіз LCU може дозволити відеокодеру формувати множинні потоки обробки (наприклад, для паралельної обробки), при цьому кожний потік включає в себе один або декілька проаналізованих LCU. Внаслідок залежності інформації прогнозування, однак, визначені потоки можуть залежати від інших потоків, що може бути неоптимальним при застосуванні під час паралельної обробки. Наприклад, перший потік може залежати від даних, що обробляються другим, іншим потоком, що може змусити перший потік чекати, доки другий потік обробить дані. Тобто дані загалом аналізуються до моменту, коли стають корисними, і потім дані кодуються. У випадку з традиційними хвильовими фронтами відеокодер може сповільнитися, щоб кодувати дані першого (наприклад, верхнього) хвильового фронту. Це в свою чергу може змусити наступний потік зупинитися, що ініціює зупинку наступного потоку і так далі. Шляхом усунення залежності інформації прогнозування, відповідно до аспектів цього розкриття, один потік, що сповільнюється, не вплине на інші потоки, що знаходяться в обробці. Що стосується аналізу, цей засіб, в якому аналізатор для потоку не потребує того, щоб звертатися до інших потоків, але він може функціонувати незалежно для кожного потоку. В одному прикладі, в ілюстративних цілях припустимо, що LCU, що кодується в даний момент, розташовується під найбільш верхнім рядом фрагмента, при цьому один або декілька LCU цього фрагмента знаходяться над поточним фрагментом. У цьому прикладі інформація прогнозування для кодування поточного LCU може бути включена у верхній сусідній LCU (наприклад, LCU, розташований над поточним LCU). Тобто інформація прогнозування для кодування поточного LCU може залежати від одного або декількох значень (наприклад, режими 5 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 внутрішнього прогнозування, інформація руху тощо) верхнього сусіднього LCU. Відповідно, до того як поточний LCU може бути кодований, він, можливо, повинен чекати, доки кодується верхній сусідній LCU. Поява такої затримки може сповільнити процес кодування, зокрема реалізацію паралельної обробки. Аспекти цього розкриття можуть використовуватися, щоб знизити можливість описаних вище затримок. Фіг. 1 являє собою блок-схему, яка ілюструє зразкову систему 10 кодування і декодування відео, яка може застосовувати методики для ефективного зберігання інформації прогнозування. Як показано на фіг. 1, система 10 включає в себе пристрій 12 джерело, який забезпечує декодування кодованих відеоданих пізніше пристроєм 14 адресатом. Зокрема, пристрій 12 джерело забезпечує пристрою 14 адресату відеодані за допомогою машинозчитуваного носія 16. Пристрій 12 джерело і пристрій 14 адресат можуть містити будь-який з широкого діапазону пристроїв, включаючи настільні комп'ютери, ноутбуки (тобто портативні комп'ютери), планшетні комп'ютери, комп'ютерні приставки до телевізора, мікротелефонні трубки, такі як так звані "смартфони", так звані "смарт»-планшети, телевізори, камери, пристрої відображення, цифрові медіаплеєри, консолі для відеоігор, пристрої для передачі потокового відео тощо. В деяких випадках пристрій 12 джерело і пристрій 14 адресат можуть бути влаштовані для здійснення бездротового зв'язку. Пристрій 14 адресата може приймати кодовані відеодані, що підлягають декодуванню за допомогою машинозчитуваного носія 16. Машинозчитуваний носій 16 може містити будь-який тип носія або пристрою здатного переміщувати кодовані відеодані від пристрою 12 джерела до пристрою 14 адресату. В одному прикладі машинозчитуваний носій 16 може містити середовище зв'язку для забезпечення передачі пристроєм 12 джерелом кодованих відеоданих напряму до пристрою 14 адресату в реальному часі. Кодовані відеодані можуть модулюватися відповідно до стандарту зв'язку, такого як протокол бездротової передачі, і передаватися до пристрою 14 адресату. Середовище зв'язку може містити будь-яке бездротове або дротове середовище зв'язку, таке як радіочастотний (RF) спектр, або одна або більше фізичних ліній передачі. Середовище зв'язку може формувати частину мережі на основі пакетів, такій як локальна мережа, регіональна мережа або глобальна мережа, така як Інтернет. Середовище зв'язку може включати в себе роутери, комутатори, базові станції або будь-яке інше обладнання, яке може бути корисне для сприяння зв'язку пристрою 12 джерела з пристроєм 14 адресатом. У деяких прикладах кодовані дані можуть виводитися від вихідного інтерфейсу 22 до запам'ятовуючого пристрою. Подібним чином, доступ до кодованих даних може здійснюватися із запам'ятовуючого пристрою за допомогою вхідного інтерфейсу. Запам'ятовуючий пристрій може включати в себе будь-який з різноманіття розподілених або локально доступних засобів зберігання даних, таких як накопичувач на жорстких дисках, диски Blu-ray, DVD, CD-ROM, флеш-пам'ять, енергозалежна або енергонезалежна пам'ять, або будь-які інші підходящі цифрові носії даних для зберігання кодованих відеоданих. У додатковому прикладі запам'ятовуючий пристрій може відповідати файловому серверу або іншому проміжному запам'ятовуючому пристрою, який може зберігати кодоване відео, згенероване пристроєм 12 джерелом. Пристрій 14 адресата може здійснювати доступ до відеоданих із запам'ятовуючого пристрою, що зберігаються, за допомогою потокової передачі або завантаження. Файловий сервер може бути сервером будь-якого типу, здатним зберігати кодовані відеодані і передавати ці кодовані відеодані до пристрою 14 адресату. Зразкові файлові сервери включають в себе веб-сервер (наприклад, веб-сайт), FTP-сервер, пристрої зберігання даних (NAS), що підключаються до мережі, або локальний накопичувач на дисках. Пристрій 14 адресата може здійснювати доступ до кодованих відеоданих за допомогою будь-якого стандартного інформаційного з'єднання, включаючи інтернет-з'єднання. Це може включати в себе бездротовий канал (наприклад, Wi-Fi-з'єднання), дротове з'єднання (наприклад, DSL, кабельний модем тощо) або таку комбінацію обох, яка підходить для доступу до кодованих відеоданих, що зберігаються на файловому сервері. Передача кодованих відеоданих від запам'ятовуючого пристрою може бути потоковою передачею, передачею завантаження або їх комбінацією. Це розкриття може загалом відноситися до відеокодера 20, "що сигналізує" визначену інформацію до іншого пристрою, такого як відеодекодер 30. Потрібно розуміти, однак, що відеокодер 20 може сигналізувати інформацію шляхом з'єднання визначених синтаксичних елементів з різними кодованими частинами відеоданих. Тобто відеокодер 20 може "сигналізувати" дані шляхом зберігання визначених синтаксичних елементів для заголовків різних кодованих частин відеоданих. У деяких випадках такі синтаксичні елементи можуть кодуватися і зберігатися (наприклад, зберігатися на носій 34 даних файлового сервера 36) до того, як приймаються і декодуються відеодекодером 30. Так, термін "сигналізування" може 6 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 загалом відноситися до передачі синтаксису або інших даних для декодування стиснутих відеоданих, чи трапляється така передача в реальному або квазіреальному часі або протягом періоду часу, так, подібне може статися при збереженні синтаксичних елементів на носій запису під час кодування, що потім може бути знайдене декодуючим пристроєм в будь-який час після збереження на цей носій. Методики цього розкриття, які загалом стосуються ефективного зберігання даних прогнозування, не обов'язково повинні обмежуватися бездротовими варіантами застосування і установками. Методики можуть застосовуватися до кодування відео для забезпечення виконання будь-якого з різноманіття мультимедійних додатків, таких як ефірне телевізійне мовлення, передачі кабельного телебачення, передачі супутникового телебачення, передачі інтернет-потокового відео, як то динамічна адаптивна потокова передача по HTTP (DASH), цифрове відео, яке кодується на засобі зберігання даних, декодування цифрового відео, що зберігається на засобі зберігання даних, або інших додатків. У деяких прикладах система 10 може бути виконана з можливістю підтримувати односторонню або двосторонню передачу, щоб підтримувати такі додатки, як передача потокового відео, відтворення відеозапису, телевізійне мовлення і/або відеотелефонія. У прикладі з фіг. 1 пристрій 12 джерело включає в себе відеоджерело 18, відеокодер 20 і вихідний інтерфейс 22. Пристрій 14 адресата включає в себе вхідний інтерфейс 28, відеодекодер 30 і пристрій 32 відображення. Відповідно до даного розкриття відеокодер 20 пристрою 12 джерела може бути виконаний з можливістю застосовувати методики для кодування векторів руху і для виконання двостороннього прогнозування в HEVC і доповненнях до нього, таких як доповнення багаторакурсного або трьохмірного відео (3DV). В інших прикладах пристрій-джерело і пристрій-адресат можуть включати в себе інші компоненти та пристрої. Наприклад, пристрій 12 джерело може приймати відеодані від зовнішнього відеоджерела 18, такого як зовнішня камера. Подібним чином, пристрій 14 адресат може взаємодіяти із зовнішнім пристроєм відображення замість того, щоб включати в себе вбудований пристрій відображення. Проілюстрована система 10 з фіг. 1 - це тільки один приклад. Методики для ефективного зберігання даних прогнозування можуть реалізовуватися будь-яким пристроєм кодування і/або декодування цифрового відео. Хоча загалом методики цього розкриття виконуються пристроєм кодування відео, вони також можуть реалізовуватися кодером/декодером відео, що звичайно називається "CODEC". Більше того, методики цього розкриття також можуть реалізовуватися передпроцесором відео. Пристрій 12 джерело і пристрій 14 адресат - це тільки приклади таких пристроїв кодування, з яких пристрій 12 джерело генерує кодовані відеодані для передачі до пристрою 14 адресату. У деяких прикладах пристрою 12, 14 можуть функціонувати здебільшого симетрично, так, що кожний з пристроїв 12, 14 включає в себе компоненти кодування і декодування відео. Отже, система 10 може підтримувати односторонню або двосторонню передачу відео між відеопристроями 12, 14, наприклад, для передачі потокового відео, відтворення відеозапису, телевізійного мовлення і/або відеотелефонії. Відеоджерело 18 пристрою 12 джерела може включати в себе пристрій захоплення відеозображень, такий як відеокамера, відеоархів, що містить раніше захоплені відеозображення, і/або інтерфейс зовнішнього відеосигналу для прийому відео від провайдера відеоконтенту. Як додаткова альтернатива відеоджерело 18 може генерувати дані на основі комп'ютерної графіки, як відео від джерела, або комбінацію "живого" відео, архівованого відео і згенерованого комп'ютером відео. У деяких випадках, якщо відеоджерело 18 є відеокамерою, пристрій 12 джерело і пристрій 14 адресат можуть формувати так звані камерофони або відеофони. Як було згадано вище, однак методики, описані в цьому розкритті, можуть бути застосовні до кодування відео загалом і можуть бути застосовні до бездротових і/або дротових додатків. У кожному випадку захоплене, раніше захоплене або згенероване комп'ютером відео може бути кодоване відеокодером 20. Кодована відеоінформація потім може виводитися за допомогою вихідного інтерфейсу 22 на машинозчитуваний носій 16. Машинозчитуваний носій 16 може включати в себе часові носії, такі як передача бездротового мовлення або дротової мережі, або носії даних (тобто нечасові носії даних), такі як жорсткий диск, флеш-накопичувач, компакт-диск, цифровий відеодиск, диск Blu-ray, або інші машинозчитувані носії. У деяких прикладах мережний сервер (не показаний) може приймати кодовані відеодані від пристрою 12 джерела і надавати кодовані відеодані пристрою 14 адресату, наприклад, за допомогою мережної передачі. Подібним чином, обчислювальний пристрій виробничого обладнання носія, такий як обладнання для штампування дисків, може приймати кодовані відеодані від пристрою 12 джерела і створювати диск, що містить кодовані 7 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 відеодані. Отже, машинозчитуваний носій 16 може розумітися як такий, що включає в себе один або декілька машинозчитуваних носіїв різних форм, в різних прикладах. Вхідний інтерфейс 28 пристрою 14 адресата приймає інформацію від машинозчитуваного носія 16. Інформація машинозчитуваного носія 16 може включати в себе синтаксичну інформацію, визначену відеокодером 20, яка також використовується відеодекодером 30, яка включає в себе синтаксичні елементи, які описують характеристики і/або обробку блоків або інших кодованих елементів, наприклад, GOP. Зокрема, це розкриття називає "кодованим елементом" елемент даних, що включає в себе множинні блоки, такі як фрагмент, зображення, група хвильових фронтів або елемент мозаїчного зображення. Так, термін "кодований елемент" повинен розумітися як такий, що включає в себе множинні блоки, наприклад, множинні найбільші елементи кодування (LCU). Більше того, термін "кодований елемент" не треба плутати з термінами "елемент кодування" або CU, як використовується в HEVC. Пристрої 32 відображення відображають декодовані відеодані користувачу і може містити будь-який з різноманіття пристроїв відображення, як то електронно-променева трубка (CRT), рідкокристалічний дисплей (LCD), плазмовий дисплей, дисплей на органічних світлодіодах (OLED), або інший тип пристрою відображення. Відеокодер 20 і відеодекодер 30 можуть функціонувати відповідно до стандарту кодування відео, такого як стандарт кодування відео високої ефективності (HEVC), що в цей час знаходиться в розробці, і можуть відповідати тестовій моделі HEVC (НМ). Найостанніший робочий проект (WD) HEVC, що в подальшому називається HEVC WD7, доступний з http://phenix.int-evry.fr/jct/doc_end_user/documents/9_Geneva/wg11/JCTVC-I1003-v5.zip, при цьому новіша версія доступна з http://phenix.intevry.fr/jct/doc_end_user/documents/9_Geneva/wg11/JCTVC-I1003-v6.zip, обидва ці джерела, таким чином, включені за допомогою посилання, як якби були викладені тут в повному обсязі. Як альтернатива відеокодер 20 і відеодекодер 30 можуть функціонувати відповідно до інших корпоративних або промислових стандартів, таких як стандарт ITU-T H.264, який, як альтернатива, називається MPEG-4, частина 10, вдосконалене кодування відео (AVC), або доповненнями до цих стандартів. Методики цього розкриття, однак, не обмежуються якимнебудь конкретним стандартом кодування. Інші приклади стандартів кодування відео включають в себе MPEG-2 та ITU-T H.263. Стандарт ITU-T H.264/MPEG-4 (AVC) був сформульований групою експертів у сфері кодування відео ITU-T (VCEG) спільно з групою експертів у сфері рухомих зображень (MPEG) ISO/IEC як продукт колективного партнерства, відомого як об'єднана група з питань відео (JVT). У деяких аспектах методики, описані в цьому розкритті, можуть застосовуватися до пристроїв, які загалом відповідають стандарту Н.264. Стандарт Н.264 описується в рекомендації Н.264 ITU-T, про вдосконалене кодування відео для універсальних аудіовізуальних послуг дослідницькою групою ITU-T в березні 2005 року, що може називатися тут стандартом Н.264 або специфікацією Н.264 або стандартом або специфікацією Н.264/AVC. Об'єднана група з питань відео (JVT) продовжує працювати над доповненнями до Н.264/MPEG-4 AVC. JCT-VC працює над розвитком стандарту HEVC. Роботи зі стандартизації основуються на моделі пристрою для кодування відео, що розвивається, яка називається тестовою моделлю HEVC (НМ). НМ передбачає деякі додаткові можливості пристроїв для кодування відео відносно існуючих пристроїв відповідно до, наприклад, ITU-T Н.264/AVC. Наприклад, тоді як Н.264 передбачає дев'ять режимів кодування внутрішнього прогнозування, НМ може передбачати аж до тридцяти трьох режимів кодування внутрішнього прогнозування. Загалом, робоча модель НМ описує, що відеокадр зображення може бути розділений на послідовність деревоподібних блоків або найбільших елементів кодування (LCU), які включають в себе вибірки і яскравості, і кольоровості. Синтаксичні дані в межах бітового потоку можуть визначати розмір LCU, який є найбільшим елементом кодування з точки зору кількості пікселів. Фрагмент включає в себе деяку кількість послідовних деревоподібних блоків у порядку кодування. Відеозображення може бути розбите на один або декілька фрагментів. Кожний деревоподібний блок може бути розбитий на елементи кодування (CU) відповідно до квадрадерева. Загалом, структура даних квадрадерева включає в себе один вузол на CU, з кореневим вузлом, що відповідає деревоподібному блоку. Якщо CU розбивається на чотири суб-CU, вузол, що відповідає CU, включає в себе чотири кінцевих вузли, кожний з яких відповідає одному з суб-CU. Кожний вузол структури даних квадрадерева може забезпечувати синтаксичні дані для відповідного CU. Наприклад, вузол в квадрадереві може включати в себе прапор розбиття, що відображає, чи розбивається CU, що відповідає вузлу, на суб-CU. Якщо CU додатково не розбивається, він називається кінцевим CU. У цьому розкритті чотири суб-CU кінцевого CU 8 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 також будуть називатися кінцевими CU, навіть якщо немає явного розбиття оригінального кінцевого CU. Наприклад, якщо CU розміру 16 × 16 додатково не розбивається, чотири суб-CU 8 × 8 також будуть іменуватися кінцевими CU, хоча CU 16 × 16 ніколи не розбивався. CU має те саме призначення, що і макроблок стандарту Н.264, за винятком того, що CU не має розмірної відмінності. Наприклад, деревоподібний блок може розбиватися на чотири дочірніх вузли (які також іменуються суб-CU), і кожний дочірній вузол може в свою чергу бути батьківським вузлом і розбиватися на ще чотири дочірніх вузли. У результаті нерозбитий дочірній вузол, що називається кінцевим вузлом квадрадерева, містить вузол кодування, що також називається кінцевим CU. Синтаксичні дані, зв'язані з кодованим бітовим потоком, можуть визначати максимальну кількість разів, яку деревоподібний блок може розбиватися, що називається максимальною глибиною CU і також може визначати мінімальний розмір вузлів кодування. Відповідно, бітовий потік може також визначати найменший елемент кодування (SCU). Це розкриття використовує термін "блок" відносно будь-якого з CU, PU або TU в контексті HEVC або подібних структур даних в контексті інших стандартів (наприклад, макроблоки та їх субблоки в H.264/AVC). Крім того, це розкриття може використовувати термін "кодований елемент", щоб описувати заздалегідь визначену кількість відеоданих, яка може включати в себе два або більше блоків відеоданих. Тобто, наприклад, кодований елемент може відноситися до зображення, фрагмента, елемента мозаїчного зображення або групи елементів мозаїчного зображення, групи хвильових фронтів або будь-якого іншого заздалегідь визначеного елемента, який включає в себе відеодані. Відповідно, термін "кодований елемент" не треба плутати з термінами "елемент кодування" або CU. CU включає в себе вузол кодування та елементи прогнозування (PU), а також елементи перетворення (TU), зв'язані з вузлом кодування. Розмір CU відповідає розміру вузла кодування і повинен бути квадратом за формою. Розмір CU може варіюватися від 8 × 8 пікселів до розміру деревоподібного блока з максимумом в 64 × 64 пікселі або більше. Кожний CU може містити один або декілька PU і один або декілька TU. Синтаксичні дані, зв'язані з CU, можуть описувати, наприклад, розбиття CU на один або декілька PU. Режими розбиття можуть розрізнюватися як ті, де CU кодується в режимі пропускання або в прямому режимі, кодується в режимі внутрішнього прогнозування або кодується в режимі зовнішнього прогнозування. PU може розбиватися так, щоб бути за формою не квадратним. Синтаксичні дані, зв'язані з CU, також можуть описувати, наприклад, розбиття CU на один або декілька TU відповідно до квадрадерева. TU може бути квадратним або неквадратним (наприклад, прямокутним). Стандарт HEVC допускає перетворення відповідно до TU, які можуть бути різними для різних CU. Розміри TU звичайно визначаються на основі розміру PU в межах заданого CU, визначеного для розбитого LCU, хоча не завжди може бути так. TU звичайно того самого розміру, що і PU, або менше. У деяких прикладах залишкові зразки, що відповідають CU, можуть поділятися на менші елементи з використанням структури квадрадерева, відомої як "залишкове квадрадерево" (RQT). Кінцеві вузли RQT можуть називатися елементами перетворення (TU). Значення різниці пікселів, зв'язані з TU, можуть бути перетворені, щоб створити коефіцієнти перетворення, які можуть бути квантовані. Кінцевий CU може включати в себе один або декілька елементів прогнозування (PU). Загалом, PU відображає просторову ділянку, що відповідає всьому або частині відповідного CU, і включає в себе дані для відновлення опорної вибірки для PU. Крім того, PU включає в себе дані, що стосуються прогнозування. Наприклад, коли PU піддається кодуванню у внутрішньому режимі, дані для PU можуть бути включені в залишкове квадрадерево (RQT), яке може включати в себе дані, що описують режим внутрішнього прогнозування для TU, що відповідає PU. Як інший приклад, коли PU піддається кодуванню у зовнішньому режимі, PU може включати в себе дані, що визначають один або декілька векторів руху для PU. Дані, що визначають вектор руху для PU, можуть описувати, наприклад, горизонтальний компонент вектора руху, вертикальний компонент вектора руху, розрізнення для вектора руху (наприклад, з точністю до чверті пікселя або точністю до однієї восьмої пікселя), опорне зображення, на яке вказує вектор руху, і/або список опорних зображень (наприклад, Список 1, Список 2 або Список 3) для вектора руху. Кінцевий CU, що має один або декілька PU, також може включати в себе один або декілька елементів перетворення (TU). Елементи перетворення можуть визначатися з використанням RQT (що також називається структурою квадрадерева TU), як було розглянуто вище. Наприклад, прапор розділення може відображати, чи розбивається кінцевий CU на чотири елементи перетворення. Потім кожний елемент перетворення може бути розбитий додатково на додаткові суб-TU. Коли TU додатково не розбивається, він може іменуватися кінцевим TU. Загалом, для внутрішнього кодування всі кінцеві TU, що належать кінцевому CU, мають один і 9 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 той самий режим внутрішнього прогнозування. Тобто один і той самий режим внутрішнього прогнозування загалом застосовується для обчислення прогнозованих значень для всіх TU кінцевого CU. Для внутрішнього кодування відеокодер 20 може обчислювати залишкове значення для кожного кінцевого TU, що використовує режим внутрішнього прогнозування, як різницю між частиною CU, що відповідає TU, і оригінальним блоком. TU не обов'язково обмежується розміром PU. Так, TU може бути більше або менше, ніж PU. Для внутрішнього кодування PU може бути об'єднаний з відповідним кінцевим TU для одного і того самого CU. У деяких прикладах максимальний розмір кінцевого TU може відповідати розміру відповідного кінцевого CU. Крім того, TU кінцевих CU можуть також бути зв'язані з відповідними структурами даних квадрадерева, що іменуються залишковими квадрадеревами (RQT). Тобто кінцевий CU може включати в себе квадрадерево, що відображає, як кінцевий CU розбивається на TU. Кореневий вузол квадрадерева TU загалом відповідає деревоподібному блоку (або LCU). TU RQT, які не розбиваються, іменуються кінцевими TU. Загалом, це розкриття використовує терміни CU та TU у відношенні кінцевого CU і кінцевого TU відповідно, якщо не вказане зворотне. Відеопослідовність звичайно включає в себе серію відеозображень. Група зображень (GOP) загалом містить серію з одного або декількох відеозображень. GOP може включати в себе синтаксичні дані в заголовку GOP, заголовку одного або декількох зображень або де-небудь ще, які описують деяку кількість зображень, включених в GOP. Кожний фрагмент зображення може включати в себе синтаксичні дані фрагмента, які описують режим кодування для відповідного фрагмента. Відеокодер 20 звичайно діє на відеоблоки в межах окремих відеофрагментів, щоб кодувати відеодані. Відеоблок може відповідати вузлу кодування в межах CU. Відеоблоки можуть мати фіксовані або змінні розміри і можуть розрізнюватися за розміром відповідно до визначеного стандарту кодування. Як приклад НМ підтримує прогнозування в PU різних розмірів. Припускаючи, що розмір конкретного CU становить 2Nx2N, НМ підтримує внутрішнє прогнозування в PU розмірів 2Nx2N або NxN і зовнішнє прогнозування в симетричних PU розмірів 2Nx2N, 2NxN, Nx2N або NxN. НМ також підтримує асиметричне розбиття для зовнішнього прогнозування в PU розмірів 2NxU, 2NxD, nLx2N та nRx2N. При асиметричному розбитті один напрямок CU не розбивається, тоді як інший напрямок розбивається на 25 % та 75 %. Частина CU, що відповідає розбиттю в 25 %, позначається "n", за яким йде позначення "Вгору", "Вниз", "Ліворуч" або "Праворуч". Так, наприклад, "2NxU" відноситься до CU в 2Nx2N, який розбивається горизонтально з PU в 2Nx0,5 N вгорі і PU в 2Nx1,5 N внизу. У цьому розкритті "NxN" та "N на N" можуть використовуватися взаємозамінно у відношенні до вимірювань пікселів відеоблока в показниках вертикального і горизонтального вимірювань, наприклад, 16 × 16 пікселів або 16 на 16 пікселів. Загалом, блок 16 × 16 буде мати 16 пікселів у вертикальному напрямку (у=16) і 16 пікселів в горизонтальному напрямку (х=16). Подібним чином, блок NxN загалом має N пікселів у вертикальному напрямку і N пікселів у горизонтальному напрямку, де N являє собою ненегативне ціле значення. Пікселі в блоці можуть бути розподілені в рядки і стовпці. Крім того, блоки не обов'язково повинні мати однакову кількість пікселів у горизонтальному напрямку і вертикальному напрямку. Наприклад, блоки можуть містити пікселі NxM, де M не обов'язково дорівнює N. Після кодування з внутрішнім прогнозуванням або кодування із зовнішнім прогнозуванням з використанням блоків PU з CU відеокодер 20 може обчислювати залишкові дані для блоків TU з CU. PU можуть містити синтаксичні дані, що описують спосіб або режим генерації піксельних даних прогнозування в просторовій ділянці (яка також називається піксельною ділянкою), а TU можуть містити коефіцієнти в ділянці перетворення після здійснення перетворення, наприклад, дискретного косинусного перетворення (DCT), перетворення цілого, вейвлетного перетворення або концептуально подібного перетворення залишкових відеоданих. Залишкові дані можуть відповідати різницям пікселів між пікселями некодованого зображення і значеннями прогнозування, що відповідають PU. Відеокодер 20 може формувати TU, що включають в себе залишкові дані для CU і потім перетворювати TU для створення коефіцієнтів перетворення для CU. Після будь-яких перетворень для створення коефіцієнтів перетворення відеокодер 20 може виконувати квантування коефіцієнтів перетворення. Квантування загалом відноситься до процесу, в якому коефіцієнти перетворення квантуються, щоб, можливо, скоротити кількість даних, що використовуються для вираження коефіцієнтів, забезпечуючи додаткове стиснення. Процес квантування може зменшити бітову глибину, зв'язану з деякими або всіма коефіцієнтами. Наприклад, значення n-біта може бути округлене до значення m-біта під час квантування, де n більше m. 10 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 Після квантування відеокодер може сканувати коефіцієнти перетворення, створюючи одномірний вектор з двомірної матриці, що включає в себе квантовані коефіцієнти перетворення. Сканування може бути направлене на приміщення коефіцієнтів більшої енергії (і, отже, меншої частоти) в передній частині масиву і вміщення коефіцієнтів меншої енергії (і, отже, більшої частоти) в задній частині масиву. У деяких прикладах відеокодер 20 може використовувати заздалегідь визначений порядок сканування, щоб сканувати квантовані коефіцієнти перетворення для створення впорядкованого вектора, який може бути підданий ентропійному кодуванню. В інших прикладах відеокодер 20 може здійснювати адаптивне сканування. Після сканування квантованих коефіцієнтів перетворення для формування одномірного вектора відеокодер 20 може здійснювати ентропійне кодування одномірного вектора, наприклад, відповідно до контекстно-адаптивного кодування із змінною довжиною (CAVLC), контекстно-адаптивного двійкового арифметичного кодування (САВАС), контекстноадаптивного двійкового арифметичного кодування на основі синтаксису (SBAC), ентропійного кодування розбиття інтервалу імовірності (PIPE) або іншою методологією ентропійного кодування. Відеокодер 20 також може здійснювати ентропійне кодування відносно синтаксичних елементів, зв'язаних з кодованими відеоданими, для використання відеодекодером 30 при декодуванні відеоданих. Загалом, процес декодування відео, здійснюваний відеодекодером 30, може включати в себе методики, зворотні методикам кодування, що реалізовуються відеокодером 20. Відеодекодер 30 в деяких випадках може реалізовувати методики подібні тим, що виконуються відеокодером 20. Відеодекодер 30 також може спиратися на синтаксичні елементи або інші дані, що містяться в прийнятому бітовому потоці, який включає в себе дані, описані у відношенні відеокодера 20. Відповідно до аспектів цього розкриття відеокодер 20 і/або відеодекодер 30 можуть реалізовувати методики цього розкриття для обмеження кількості даних із сусідніх блоків, які буферизуються під час кодування, наприклад, в лінійному буфері. Наприклад, відеокодер 20 і/або відеодекодер 30 можуть обмежувати кількість інформації прогнозування із сусідніх блоків, яка буферизується під час кодування. Як було зазначено вище, інформація прогнозування може включати в себе інформацію внутрішнього прогнозування (наприклад, режим внутрішнього кодування) або інформацію руху (наприклад, вектори руху, індекси опорного зображення, напрямки прогнозування та інша інформація). Відповідно до аспектів цього розкриття, замість використання інформації прогнозування верхніх сусідніх блоків при кодуванні поточного блока в деяких прикладах відеокодер 20 і/або відеодекодер 30 можуть визначати інформацію прогнозування на основі інформації прогнозування з лівих сусідніх блоків. В інших прикладах відеокодер 20 і/або відеодекодер 30 можуть визначати інформацію прогнозування на основі даних з верхнього сусіднього блока, але тільки коли поточний блок - це субблок більшого розбиття (наприклад, який називається в стандарті кодування відео високої ефективності (HEVC), що розвивається, найбільшим елементом кодування (LCU), як описується більш детально нижче), і такий субблок не межує з іншим LCU. Різноманіття інших методик, як описується нижче, також може використовуватися, щоб скоротити кількість інформації прогнозування, яка буферизується відеокодером 20 і/або відеодекодером 30 під час кодування відео. Кожний з відеокодера 20 і відеодекодера 30 може бути реалізований як будь-яка з різноманіття підходящих схем кодера або декодера відповідно, як то один або декілька мікропроцесорів, цифрових процесорів сигналів (DSP), спеціалізованих інтегральних схем (ASIC), програмованих користувачем вентильних матриць (FPGA), схем дискретної логіки, програмного забезпечення, апаратного забезпечення, програмно-апаратного забезпечення або будь-яких їх комбінацій. Кожний з відеокодера 20 і відеодекодера 30 може бути включений в один або декілька кодерів або декодерів, кожний з яких може бути інтегрований як частина комбінованого кодера/декодера (CODEC). Пристрій, що включає в себе відеокодер 20 і/або відеодекодер 30, може містити інтегральну схему, мікропроцесор і/або бездротовий пристрій зв'язку, такий як стільниковий телефон. Хоча це і не показано на фіг. 1, в деяких аспектах відеокодер 20 і відеодекодер 30 - кожний з них - можуть з'єднуватися з аудіокодером і декодером і можуть включати в себе відповідні модулі MUX-DEMUX або інше апаратне і програмне забезпечення, щоб здійснити кодування як аудіо, так і відео в загальному потоці даних або окремих потоках даних. Якщо можливо, модулі MUX-DEMUX можуть підкорятися протоколу мультиплексування ITU H.223 або іншим протоколам, таким як протокол користувацьких дейтаграм (UDP). Фіг. 2 являє собою блок-схему, яка ілюструє зразковий відеокодер 20, який може застосовувати методики, описані в цьому розкритті для ефективного зберігання інформації 11 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 прогнозування. Відеокодер 20 може здійснювати внутрішнє і зовнішнє кодування відеоблоків у межах відеофрагментів. Внутрішнє кодування основане на часовому прогнозуванні для зниження або виключення часової надмірності у відео в межах суміжних зображень відеопослідовності. Внутрішній режим (I режим) може відноситься до будь-яких з декількох просторових режимів стиснення. Зовнішні режими, такі як однонаправлене прогнозування (Р режим) або двонаправлене прогнозування (В режим) можуть відноситься до будь-якого з часових режимів стиснення. Як показано на фіг. 2, відеокодер 20 приймає відеодані, що підлягають кодуванню. У прикладі з фіг. 2 відеокодер 20 включає в себе модуль 40 вибору режиму, суматор 50, модуль 52 обробки перетворення, модуль 54 квантування, модуль 56 ентропійного кодування і пам'ять 64 опорних зображень. Модуль 40 вибору режиму в свою чергу включає в себе модуль 42 оцінки руху, модуль 44 компенсації руху, модуль 46 внутрішнього прогнозування і модуль 48 розбиття. Для відновлення відеоблока відеокодер 20 також включає в себе модуль 58 оберненого квантування, модуль 60 обробки оберненого перетворення і суматор 62. Деблокуючий фільтр (не показаний на фіг. 2) також може бути включений в межі блока фільтра для усунення дефектів блочності з відновленого відео. Якщо це бажано, деблокуючий фільтр звичайно буде фільтрувати вихід суматора 62. Додаткові циклічні фільтри (внутрішньоциклічні або постциклічні) також можуть використовуватися додатково до деблокуючого фільтра. Такі фільтри не показані з метою лаконічності викладу, але якщо це бажано, можуть фільтрувати вихід суматора 50 (як внутрішньоциклічний фільтр). Під час процесу кодування відеокодер 20 приймає відеозображення або фрагмент, що підлягає кодуванню. Зображення або фрагмент можуть розділятися на множину відеоблоків. Модуль 42 оцінки руху і модуль 44 компенсації руху здійснюють кодування із зовнішнім прогнозуванням прийнятого відеоблока відносно одного або декількох блоків в одному або декількох опорних зображеннях, щоб забезпечити часове стиснення. Модуль 46 внутрішнього прогнозування може як альтернатива здійснювати кодування з внутрішнім прогнозуванням прийнятого відеоблока відносно одного або декількох сусідніх блоків в одному і тому самому зображенні або фрагменті, як блок, що підлягає кодуванню, щоб забезпечити просторове стиснення. Відеокодер 20 може здійснювати кодування декілька разів, наприклад, щоб вибрати належний режим кодування для кожного блока відеоданих. Більше того, модуль 48 розбиття може розбивати блоки відеоданих на субблоки на основі оцінки попередніх схем розбиття в попередніх сеансах кодування. Наприклад, модуль 48 розбиття може спочатку розбивати зображення або фрагмент на блоки LCU і розбивати кожний з LCU на суб-CU на основі аналізу залежності швидкості передачі від спотворень (наприклад, оптимізації залежності швидкості передачі від спотворень). Модуль 40 вибору режиму може додатково створювати структуру даних квадрадерева, що відображає розбиття LCU на суб-CU. CU кінцевого вузла квадрадерева можуть включати в себе один або декілька PU і один або декілька TU. Модуль 40 вибору режиму може вибирати один з режимів кодування, внутрішнього або зовнішнього, наприклад, на основі результатів помилок, і надає підданий внутрішньому або зовнішньому кодуванню блок суматору 50, що одержаний в результаті, щоб генерувати дані залишкового блока, і суматору 62, щоб відновити кодований блок для використання як опорного зображення. Модуль 40 вибору режиму також надає синтаксичні елементи, такі як вектори руху, інформація розбиття або інша подібна синтаксична інформація, модулю 56 ентропійного кодування. Модуль 42 оцінки руху і модуль 44 компенсації руху можуть бути значною мірою об'єднані, але проілюстровані окремо один від одного в концептуальних цілях. Оцінка руху, що виконується модулем 42 оцінки руху, є процесом генерації векторів руху, які оцінюють рух відеоблоків. Вектор руху, наприклад, може відображати зміщення PU відеоблока в межах поточного відеозображення відносно блока прогнозування в межах опорного зображення (або іншого кодованого елемента) відносно поточного блока, що піддається кодуванню в межах поточного зображення (або іншого кодованого елемента). Як було зазначено вище, вектори руху можуть складати інформацію прогнозування. Блок прогнозування - це блок, який знаходиться близько відповідно до блока, що підлягає кодуванню, з точки зору різниці пікселів, яка може бути визначена сумою абсолютної різниці (SAD), сумою різниці квадратів (SSD) або інших метрик різниці. У деяких прикладах відеокодер 20 може обчислювати значення положень субцілого пікселя опорних зображень, що зберігаються в пам'яті 64 опорних зображень. Наприклад, відеокодер 20 може інтерполювати значення положень чверті пікселя, положення однієї восьмої пікселя або інші положення часткового пікселя опорного зображення. Отже, модуль 42 оцінки руху може здійснювати пошук 12 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 руху відносно положень повного пікселя і положень часткового пікселя і виводити вектор руху з точністю до часткового пікселя. Модуль 42 оцінки руху обчислює вектор руху для PU відеоблока у фрагменті, що піддався зовнішньому кодуванню, шляхом порівняння положення PU з положенням блока прогнозування опорного зображення. Опорне зображення може вибиратися з першого списку опорних зображень (Список 0) і другого списку опорних зображень (Список 1), кожний з яких ідентифікує одне або декілька опорних зображень, що зберігаються в пам'яті 64 опорних зображень. Модуль 42 оцінки руху відправляє обчислений вектор руху до модуля 56 ентропійного кодування і модуля 44 компенсації руху. У деяких прикладах замість відправки актуального вектора руху для поточного PU модуль 42 оцінки руху може прогнозувати вектор руху, щоб додатково скоротити кількість даних, необхідних для передачі вектора руху. У цьому випадку замість кодування і передачі самого вектора руху модуль 42 оцінки руху може генерувати різницю вектора руху (MVD) відносно відомого (або пізнаваного) вектора руху. Відомий вектор руху, який може використовуватися з MVD, щоб визначити поточний вектор руху, може бути визначений так званим предиктором вектора руху (MVP). Загалом, щоб бути дійсним MVP, вектор руху, що використовується для прогнозування, повинен вказувати на те саме опорне зображення, що вектор руху, який кодується в поточний момент. У деяких прикладах модуль 42 оцінки руху може вистроювати список кандидатів для предиктора вектора руху, який включає в себе декілька сусідніх блоків у просторовому і/або часовому напрямках як кандидатів MVP. Коли доступні множинні кандидати для предиктора вектора руху (для множини блоків-кандидатів), модуль 42 оцінки руху може визначати предиктор вектор руху для поточного блока відповідно до визначених заздалегідь критеріїв вибору. Наприклад, модуль 42 оцінки руху може вибирати найбільш точний предиктор з групи кандидатів на основі аналізу швидкості кодування і спотворення (наприклад, використовуючи так званий аналіз витрат швидкості-спотворення або інший аналіз ефективності кодування). В інших прикладах модуль 42 оцінки руху може генерувати середній з кандидатів для предиктора вектора руху. Інші способи вибору предиктора вектора руху також можливі. Після вибору предиктора вектора руху модуль 42 оцінки руху може визначити індекс предиктора вектора руху (mvp_flag), який може використовуватися, щоб повідомити відеодекодеру (такому, наприклад, як відеодекодер 30), де розташувати MVP в списку опорних зображень, що містить блоки-кандидати MVP. Модуль 42 оцінки руху також може визначати MVD між поточним блоком і вибраним MVP. Індекс MVP та MVD можуть використовуватися, щоб відновити вектор руху. У деяких прикладах модуль 42 оцінки руху може замість перерахованого застосовувати так званий "режим злиття", в якому модуль 42 оцінки руху може "об'єднувати" інформацію руху (таку як вектори руху, індекси опорного зображення, напрямки прогнозування, або іншу інформацію) відеоблока прогнозування з поточним відеоблоком. Відповідно, що стосується режиму злиття, то поточний відеоблок успадковує інформацію руху від іншого відомого (або пізнаваного) відеоблока. Модуль 42 оцінки руху може вистроювати список кандидатів для режиму злиття, який включає в себе декілька сусідніх блоків у просторовому і/або часовому напрямках як кандидатів для режиму злиття. Модуль 42 оцінки руху може визначати значення індексу (наприклад, merge_idx), що може використовуватися, щоб повідомити відеодекодеру (такому, наприклад, як відеодекодер 30), де розташувати відеоблок злиття, тобто блок, від якого виходить інформація руху, в списку опорних зображень, що містить блоки-кандидати для злиття. Відповідно до аспектів цього розкриття модуль 42 оцінки руху може обмежувати кількість інформації руху, наприклад, векторів руху, індексів опорного зображення, напрямків прогнозування, або іншої інформації, від сусідніх блоків, яка буферизується під час кодування. Наприклад, замість визначення MVP або кандидата злиття для поточного блока на основі інформації руху від верхніх сусідніх блоків модуль 42 оцінки руху може визначати інформацію руху для кодування поточного блока на основі інформації руху від лівих сусідніх блоків. В інших прикладах модуль 42 оцінки руху може визначати інформацію руху для поточного блока на основі даних з верхнього сусіднього блока, але тільки коли поточний блок - це субблок LCU і верхній сусідній блок - з того самого LCU. Ще в інших прикладах модуль 42 оцінки руху може застосовувати інші методики (наприклад, субдискретизація, інтерполяція тощо, що більш детально описується нижче), щоб скоротити кількість інформації руху, яка буферизується під час кодування. Компенсація руху, що виконується модулем 44 компенсації руху, може включати в себе вибірку або генерацію предиктивного блока на основі вектора руху, визначеного модулем 42 13 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 оцінки руху. Ще модуль 42 оцінки руху і модуль 44 компенсації руху можуть функціонально об'єднуватися в деяких прикладах. Після прийому вектора руху для PU поточного відеоблока модуль 44 компенсації руху може розташовувати блок прогнозування, на який вказує вектор руху, в одному зі списків опорних зображень. Суматор 50 формує залишковий відеоблок шляхом віднімання значень пікселя блока прогнозування із значень пікселя поточного відеоблока, що піддається кодуванню, формуючи значення різниці пікселя, як розглядається нижче. Загалом, модуль 42 оцінки руху здійснює оцінку руху відносно компонентів яскравості, а модуль 44 компенсації руху використовує вектори руху, обчислені на основі компонентів яскравості, і для компонентів кольоровості, і для компонентів яскравості. Модуль 40 вибору режиму також може генерувати синтаксичні елементи, зв'язані з відеоблоками і відеофрагментом, для використання відеодекодером 30 при декодуванні відеоблоків відеофрагмента. Модуль 46 внутрішнього прогнозування може здійснювати внутрішнє прогнозування поточного блока як альтернативу зовнішньому прогнозування, що виконується модулем 42 оцінки руху і модулем 44 компенсації руху, як описується вище. Зокрема, модуль 46 внутрішнього прогнозування може визначати режим внутрішнього прогнозування для використання з метою кодування поточного блока. У деяких прикладах модуль 46 внутрішнього прогнозування може кодувати поточний блок, використовуючи різні режими внутрішнього прогнозування, наприклад, під час окремих сеансів кодування модуль 46 внутрішнього прогнозування (або модуль 40 вибору режиму в деяких прикладах) може вибирати належний режим внутрішнього прогнозування, щоб використовувати починаючи з протестованих режимів. Наприклад, модуль 46 внутрішнього прогнозування може обчислювати значення швидкостіспотворення з використанням аналізу швидкості-спотворення для різних протестованих режимів внутрішнього прогнозування і вибирати режим внутрішнього прогнозування, що має кращі характеристики швидкості-спотворення серед протестованих режимів. Аналіз швидкостіспотворення загалом визначає обсяг спотворення (або помилки) між кодованим блоком і оригінальним, некодованим блоком, який був кодований, щоб створити кодований блок, як і бітрейтом (тобто кількість бітів), що використовується, щоб створити кодований блок. Модуль 46 внутрішнього прогнозування може обчислювати співвідношення спотворень і швидкостей для різних кодованих блоків, щоб визначити, який режим внутрішнього прогнозування демонструє краще значення швидкості-спотворення для блока. У деяких прикладах модуль 46 внутрішнього прогнозування може відображати вибраний режим внутрішнього прогнозування, використовуючи так званий найбільш імовірний режим. Наприклад, модуль 46 внутрішнього прогнозування може відображати режим внутрішнього прогнозування для поточного блока на основі моделі контексту, яка включає в себе раніше кодовані блоки. У прикладі модуль 46 внутрішнього прогнозування може визначати найбільш імовірний режим на основі раніше кодованих блоків, які межують з поточним блоком відносно зверху і відносно зліва, передбачаючи порядок кодування зліва-направо, зверху-вниз. У цих блоків з високою імовірністю той самий режим внутрішнього кодування, що і у поточного блока. В одному прикладі, якщо блоки зверху і зліва від поточного блока кодуються з використанням різних режимів, модуль 46 внутрішнього прогнозування може вибирати режим внутрішнього прогнозування, який має більш низький чисельний ранг як найбільш імовірний режим, відповідно до визначеного заздалегідь ранжуванням внутрішніх режимів, що підтримуються модулем 46 внутрішнього прогнозування (наприклад, чисельне ранжування внутрішніх режимів відповідно до номерів режимів). В іншому прикладі, якщо блоки зверху і зліва від поточного блока кодуються з використанням різних режимів, модуль 46 внутрішнього прогнозування може вибирати визначений заздалегідь режим за умовчанням, такий як внутрішній режим DC, як найбільш імовірний режим. Процес вибору найбільш імовірного режиму, коли контекст поточного блока включає в себе більше одного внутрішнього режиму, однак, передбачений тільки як приклад, і модуль 46 внутрішнього прогнозування може бути виконаний з можливістю визначати найбільш імовірний режим множиною інших способів. Після визначення найбільш імовірного внутрішнього режиму модуль 46 внутрішнього прогнозування може встановлювати прапор (наприклад, прапор most_probable_mode) на основі порівняння найбільш імовірного режиму з вибраним внутрішнім режимом, що використовується, щоб кодувати поточний блок. Наприклад, якщо найбільш імовірний режим є таким самим, як і вибраний внутрішній режим для поточного блока, модуль 46 внутрішнього прогнозування може встановлювати прапор найбільш імовірного режиму на значення 1, який відображає, що вибраний внутрішній режим і найбільш імовірний режим - однакові. У цьому прикладі для сигналізування вибраного режиму не потрібно додаткових бітів. Тобто після прийому прапора найбільш імовірного режиму, який був встановлений на 1, відеодекодер (такий як відеодекодер 14 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 30) може відтворювати ту саму процедуру для визначення найбільш імовірного режиму, наприклад, як та, що використовується кодером, і потім використовувати найбільш імовірний режим, щоб декодувати прийнятий блок. Якщо найбільш імовірний режим - не той самий, що вибраний внутрішній режим для поточного блока, модуль 46 внутрішнього прогнозування може встановлювати прапор найбільш імовірного режиму на значення 0, який відображає, що режими не однакові. У цьому прикладі можуть бути потрібні додаткові біти, щоб сигналізувати актуальний внутрішній режим, що використовується, щоб кодувати поточний блок, або напряму, або за допомогою індексу, що вказує на іншій із сусідніх блоків. Відповідно до деяких прикладів модуль 46 внутрішнього прогнозування може підтримувати чисельне ранжування внутрішніх режимів, де внутрішні режими, що найчастіше використовуються, мають найнижчий чисельний ранг. У таких прикладах модуль 46 внутрішнього прогнозування може сигналізувати актуальний внутрішній режим, що використовується, щоб кодувати поточний блок, на основі чисельного рангу або іншого чисельного ідентифікатора. Відповідно до аспектів цього розкриття модуль 46 внутрішнього прогнозування може обмежувати кількість інформації прогнозування, наприклад, даних внутрішнього режиму, від сусідніх блоків, яка буферизується під час кодування. Наприклад, замість визначення найбільш імовірного внутрішнього режиму для поточного блока на основі даних внутрішнього режиму від верхніх сусідніх блоків модуль 46 внутрішнього прогнозування може визначати найбільш імовірний внутрішній режим для кодування поточного блока на основі внутрішніх режимів від лівих сусідніх блоків. Тобто, наприклад, модуль 46 внутрішнього прогнозування може визначати найбільш імовірний внутрішній режим для декодування поточного блока тільки на основі внутрішніх режимів лівих сусідніх блоків, без визначення внутрішніх режимів верхніх сусідніх блоків. В інших прикладах модуль 46 внутрішнього прогнозування може визначати найбільш імовірний внутрішній режим для поточного блока на основі даних з одного або декількох лівих сусідніх блоків і верхнього сусіднього блока, але тільки коли поточний блок - це субблок LCU і верхній сусідній блок - з того самого LCU. Ще в інших прикладах модуль 46 внутрішнього прогнозування може застосовувати інші методики (наприклад, субдискретизація, інтерполяція тощо, що більш детально описується нижче), щоб скоротити кількість даних внутрішнього режиму, які буферизуються під час кодування. Відеокодер 20 формує залишковий відеоблок шляхом віднімання даних прогнозування модуля 40 вибору режиму з оригінального відеоблока, що піддається кодуванню. Суматор 50 являє собою компонент або компоненти, які виконують цю операцію віднімання. Модуль 52 обробки перетворення застосовує перетворення, таке як дискретне косинусне перетворення (DCT) або концептуально подібне перетворення, відносно залишкового блока, створюючи відеоблок, що містить значення залишкових коефіцієнтів перетворення. Модуль 52 обробки перетворення може виконувати інші перетворення, які концептуально подібні до DCT. Вейвлетні перетворення, перетворення цілого, субсмугові перетворення і перетворення інших типів також можуть використовуватися. У будь-якому випадку модуль 52 обробки перетворення застосовує перетворення до залишкового блока, створюючи блок залишкових коефіцієнтів перетворення. Перетворення можуть перетворювати залишкову інформацію з ділянки значень пікселя в ділянку перетворення, таку як частотна ділянка. Модуль 52 обробки перетворення може відправляти коефіцієнти перетворення, що одержали в результаті, до модуля 54 квантування. Модуль 54 квантування квантує коефіцієнти перетворення, щоб додатково знизити бітрейт. Процес квантування може зменшити бітову глибину, зв'язану з деякими або усіма коефіцієнтами. Ступінь квантування може змінюватися шляхом регулювання параметра квантування. У деяких прикладах модуль 54 квантування може потім здійснювати сканування матриці, що включає в себе квантовані коефіцієнти перетворення. Як альтернатива модуль 56 ентропійного кодування може здійснювати сканування. Після квантування модуль 56 ентропійного кодування здійснює ентропійне кодування квантованих коефіцієнтів перетворення. Наприклад, модуль 56 ентропійного кодування може виконувати контекстно-адаптивне кодування із змінною довжиною (CAVLC), контекстноадаптивне двійкове арифметичне кодування (САВАС), контекстно-адаптивне двійкове арифметичне кодування на основі синтаксису (SBAC), ентропійне кодування розбиття інтервалу імовірності (PIPE) або іншу методику ентропійного кодування. У випадку ентропійного кодування на основі контексту контекст може бути на основі сусідніх блоків. Що стосується САВАС, то модуль 56 ентропійного кодування може вибирати модель контексту, яка впливає на контекст, щоб кодувати символи, зв'язані з блоком відеоданих. Наприклад, модуль 56 ентропійного кодування може вибирати здійснювати ентропійне 15 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 кодування кожного синтаксичного елемента для блока відеоданих, використовуючи оцінки імовірності для кожного синтаксичного елемента. Оцінки імовірності можуть відображати імовірність елемента, що має задане значення. Оцінки імовірності можуть бути включені в модель імовірності, що також називається моделлю контексту. Модуль 56 ентропійного кодування може вибирати модель контексту шляхом визначення інформації контексту (або просто "контексту") для синтаксичного елемента. Для кожного контексту визначається інша модель імовірності. Після кодування синтаксичного елемента модуль 56 ентропійного кодування може оновлювати вибрану модель контексту на основі актуального значення синтаксичного елемента, щоб відобразити найостанніші оцінки імовірності. Тобто, наприклад, модуль 56 ентропійного кодування може оновлювати спосіб, яким вибирається модель контексту, для переходу до нової моделі контексту. Після ентропійного кодування модулем 56 ентропійного кодування кодований бітовий потік може передаватися до іншого пристрою (наприклад, відеодекодера 30) або архівуватися, наприклад, на носії запису для передачі або відтворення пізніше. Модуль 58 оберненого квантування і модуль 60 обробки оберненого перетворення застосовують обернене квантування і обернене перетворення відповідно, щоб відновити залишковий блок в піксельній ділянці, наприклад, щоб потім використовувати його як опорний блок. Модуль 44 компенсації руху може обчислювати опорний блок шляхом додавання залишкового блока до блока прогнозування одного із зображень з пам'яті 64 опорних зображень. Модуль 44 компенсації руху також може застосовувати один або декілька інтерполяційних фільтрів до відновленого залишкового блока, щоб обчислити значення субцілого пікселя для використання при оцінці руху. Суматор 62 додає відновлений залишковий блок до блока прогнозування з компенсацією руху, створеного модулем 44 компенсації руху, щоб створити відновлений відеоблок для зберігання в пам'яті 64 опорних зображень. Відновлений відеоблок може використовуватися модулем 42 оцінки руху і модулем 44 компенсації руху як опорний блок, щоб здійснити зовнішнє кодування блока в наступному відеозображенні. Таким чином, відеокодер 20 є прикладом відеокодера, який може реалізовувати спосіб, що включає в себе визначення інформації прогнозування для першого блока відеоданих, при цьому перший блок включається в кодований елемент відеоданих, де перший блок розташовується нижче верхнього рядка блоків у кодованому елементі, визначення інформації прогнозування для другого блока відеоданих нижче верхнього рядка блоків у кодованому елементі на основі інформації прогнозування для першого блока відеоданих і не основуючись на інформації прогнозування з верхнього рядка блоків у кодованому елементі, і кодування другого блока на основі визначеної інформації прогнозування для другого блока. Фіг. 3 являє собою блок-схему, яка ілюструє зразковий відеодекодер 30, який може застосовувати методики, описані в цьому розкритті, для ентропійного кодування відеоданих. У прикладі з фіг. 3 відеодекодер 30 включає в себе модуль 80 ентропійного декодування, модуль 81 прогнозування, модуль 86 оберненого квантування, модуль 88 оберненого перетворення, суматор 90 і пам'ять 92 опорних зображень. Модуль 81 прогнозування включає в себе модуль 82 компенсації руху і модуль 84 внутрішнього прогнозування. Під час процесу декодування відеодекодер 30 приймає бітовий потік кодованого відео, який являє собою відеоблоки кодованого відеофрагмента і зв'язані з ними синтаксичні елементи, від відеокодера 20. Модуль 80 ентропійного декодування відеодекодера 30 здійснює ентропійне декодування бітового потоку, щоб генерувати квантовані коефіцієнти, вектори руху та інші синтаксичні елементи. Відеодекодер 30 може приймати синтаксичні елементи на рівні відеофрагмента і/або рівні відеоблока. Наприклад, у вигляді фону відеодекодер 30 може приймати стиснуті відеодані, які були стиснуті для передачі по мережі в так звані "елементи рівня абстракції мережі" або елементи NAL. Кожний елемент NAL може включати в себе заголовок, який ідентифікує тип даних, що зберігаються в елементі NAL. Існує два типи даних, які звичайно зберігаються в елементах NAL. Перший тип даних, що зберігаються в елементі NAL, - це дані рівня кодування відео (VCL), які включають в себе стиснуті відеодані. Другий тип даних, що зберігаються в елементі NAL, називається даними не-VCL, які включають в себе додаткову інформацію, таку як настройки параметрів, які визначають дані заголовка, характерні для великої кількості елементів NAL, і додаткову інформацію розширення (SEI). Наприклад, настройки параметрів можуть містити інформацію заголовка рівня послідовності (наприклад, в групах параметрів послідовності (SPS)) і інформацію заголовка рівня зображення, що рідко міняється, (наприклад, в групах параметрів зображення (PPS)). Інформація, що рідко міняється, яка міститься в групах параметрів, не потребує повторення для кожної послідовності або кожного зображення, таким чином підвищуючи ефективність кодування. Крім того, 16 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 використання груп параметрів робить можливою позасмугову передачу інформації заголовка, таким чином уникаючи потреби в зайвих передачах, сприяючих стійкості до помилок. Модуль 80 ентропійного декодування може бути сконфігурований подібно до модуля 56 ентропійного кодування, як описується вище у відношенні відеокодера 20 з фіг. 2. Наприклад, модуль 80 ентропійного кодування може вибирати модель контексту, яка впливає на контекст, щоб декодувати символи, зв'язані з блоком відеоданих. Тобто модуль 80 ентропійного декодування може здійснювати ентропійне декодування кожного синтаксичного елемента для блока відеоданих, використовуючи оцінки імовірності для кожного синтаксичного елемента. Модуль 80 ентропійного декодування пересилає вектори руху та інші декодовані синтаксичні елементи до модуля 81 прогнозування. Коли відеофрагмент кодується як фрагмент, що піддався внутрішньому кодуванню (I), модуль 84 внутрішнього прогнозування модуля 81 прогнозування може генерувати дані прогнозування для відеоблока поточного відеофрагмента на основі повідомленого режиму внутрішнього прогнозування (наприклад, повідомленого як найбільш імовірний режим, напряму або за допомогою індексу, що вказує на іншій із сусідніх блоків) і даних від раніше декодованих блоків поточного зображення. Коли відеозображення кодується як фрагмент, що піддався внутрішньому кодуванню (тобто В, Р GBP), модуль 82 компенсації руху модуля 81 прогнозування створює блоки прогнозування для відеоблока поточного відеофрагмента на основі векторів руху та інших синтаксичних елементів, прийнятого від модуля 80 ентропійного декодування. Блоки прогнозування можуть одержуватися з одного з опорних зображень в межах списків опорних зображень. Відеодекодер 30 може вистроювати списки опорних зображень, Список 0 і Список 1, використовуючи методики побудови за умовчанням на основі опорних зображень, що зберігаються в пам'яті 92 опорних зображень. Модуль 82 компенсації руху визначає інформацію прогнозування для відеоблока поточного відеофрагмента шляхом аналізу векторів руху та інших синтаксичних елементів і використовує інформацію прогнозування, щоб створити блоки прогнозування для поточного відеоблока, що піддається декодуванню. Наприклад, модуль 82 компенсації руху використовує деякі з прийнятих синтаксичних елементів, щоб визначити режим прогнозування (наприклад, внутрішнє або зовнішнє прогнозування), що використовується, щоб кодувати відеоблоки відеофрагмента, тип фрагмента зовнішнього прогнозування (наприклад, фрагмент В, фрагмент Р або фрагмент GBP), інформацію побудови для одного або декількох списків опорних зображень для фрагмента, вектори руху для кожного фрагмента відеоблока, що піддався зовнішньому кодуванню, статус зовнішнього прогнозування для кожного фрагмента відеоблока, що піддався зовнішньому кодуванню, і іншу інформацію, щоб декодувати відеоблоки в поточному відеофрагменті. Модуль 82 компенсації руху також може виконувати інтерполяцію на основі інтерполяційних фільтрів. Модуль 82 компенсації руху може використовувати інтерполяційні фільтри, як ті, що використовуються відеокодером 20, під час кодування відеоблоків, щоб обчислити інтерпольовані значення для субцілих пікселів опорних блоків. У цьому випадку модуль 82 компенсації руху може визначати інтерполяційні фільтри, що використовуються відеокодером 20, виходячи з прийнятих синтаксичних елементів, і застосовувати інтерполяційні фільтри, щоб створити блоки прогнозування. Відповідно до аспектів цього розкриття модуль 82 компенсації руху може обмежувати кількість інформації руху, наприклад, векторів руху, індексів опорного зображення, напрямків прогнозування, або іншої інформації, від сусідніх блоків, яка буферизується під час декодування. Наприклад, замість визначення MVP або кандидата злиття для поточного блока на основі інформації руху від верхніх сусідніх блоків модуль 82 компенсації руху може визначати інформацію руху для декодування поточного блока на основі інформації руху від лівих сусідніх блоків. В інших прикладах модуль 82 компенсації руху може визначати інформацію руху для поточного блока на основі даних з верхнього сусіднього блока, але тільки коли поточний блок - це субблок LCU і верхній сусідній блок - з того самого LCU. Ще в інших прикладах модуль 82 компенсації руху може застосовувати інші методики (наприклад, субдискретизація, інтерполяція тощо, що більш детально описується нижче), щоб скоротити кількість інформації руху, яка буферизується під час декодування. Відповідно до аспектів цього розкриття модуль 84 внутрішнього прогнозування може обмежувати кількість інформації прогнозування, наприклад, даних внутрішнього режиму, від сусідніх блоків, яка буферизується під час декодування. Наприклад, замість визначення найбільш імовірного внутрішнього режиму для поточного блока на основі даних внутрішнього режиму від верхніх сусідніх блоків модуль 84 внутрішнього прогнозування може визначати найбільш імовірний внутрішній режим для декодування поточного блока на основі внутрішніх режимів від лівих сусідніх блоків. Тобто, наприклад, модуль 84 внутрішнього прогнозування 17 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 може визначати найбільш імовірний внутрішній режим для декодування поточного блока тільки на основі внутрішніх режимів лівих сусідніх блоків, без визначення внутрішніх режимів верхніх сусідніх блоків. В інших прикладах модуль 84 внутрішнього прогнозування може визначати найбільш імовірний внутрішній режим для поточного блока на основі даних з одного або декількох лівих сусідніх блоків і верхнього сусіднього блока, але тільки коли поточний блок - це субблок LCU і верхній сусідній блок - з того самого LCU. Ще в інших прикладах модуль 84 внутрішнього прогнозування може застосовувати інші методики (наприклад, субдискретизація, інтерполяція тощо, що більш детально описується нижче), щоб скоротити кількість даних внутрішнього режиму, які буферизуються під час декодування. Модуль 86 оберненого квантування здійснює обернене квантування, тобто він деквантує квантовані коефіцієнти перетворення, представлені в бітовому потоці і декодовані модулем 80 ентропійного декодування. Процес оберненого квантування може включати в себе використання параметра квантування, обчисленого відеокодером 20 для кожного відеоблока у відеофрагменті, щоб визначити ступінь квантування і, подібним чином, ступінь оберненого квантування, яка повинна застосовуватися. Модуль 88 обробки оберненого перетворення здійснює обернене перетворення, наприклад, обернене DCT, обернене перетворення цілого або концептуально подібний процес оберненого перетворення, щоб перетворити коефіцієнти з метою створити залишкові блоки в піксельній ділянці. Відповідно до аспектів цього розкриття модуль 88 обробки оберненого перетворення може визначати спосіб, за допомогою якого здійснювалися перетворення відносно залишкових даних. Тобто, наприклад, модуль 88 обробки оберненого перетворення може визначати RQT, яке відображає спосіб, за допомогою якого здійснювалися перетворення (наприклад, DCT, перетворення цілого, вейвлетне перетворення або одне або декілька інших перетворень) відносно залишкових зразків яскравості і залишкових зразків кольоровості, зв'язаних з блоком прийнятих відеоданих. Після того як модуль 82 компенсації руху генерує предиктивний блок для поточного відеоблока на основі векторів руху та інших синтаксичних елементів, відеодекодер 30 формує декодований відеоблок шляхом підсумовування залишкових блоків від модуля 88 обробки оберненого перетворення з відповідними предиктивними блоками, згенерованими модулем 82 компенсації руху. Суматор 90 являє собою компонент або компоненти, які виконують цю операцію підсумовування. Якщо це бажано, деблокуючий фільтр може також застосовуватися, щоб фільтрувати декодовані блоки з метою усунути дефекти блочності. Інші циклічні фільтри (або в циклі кодування, або після циклу кодування) також можуть використовуватися, щоб згладжувати переміщення пікселів або іншим чином поліпшувати якість відео. Потім декодовані відеоблоки в заданому зображенні зберігаються в пам'ять 92 опорних зображень, яка зберігає опорні зображення, що використовуються для подальшої компенсації руху. Пам'ять 92 опорних зображень також зберігає декодоване відео для презентації пізніше на пристрої відображення, такому як пристрій 32 відображення з фіг. 1. Таким чином, відеодекодер 30 є прикладом відеодекодера, який може реалізовувати спосіб, що включає в себе визначення інформації прогнозування для першого блока відеоданих, при цьому перший блок включається в кодований елемент відеоданих, де перший блок розташовується нижче верхнього рядка блоків у кодованому елементі, визначення інформації прогнозування для другого блока відеоданих нижче верхнього рядка блоків у кодованому елементі на основі інформації прогнозування для першого блока відеоданих і не основуючись на інформації прогнозування з верхнього рядка блоків у кодованому елементі, і кодування другого блока на основі визначеної інформації прогнозування для другого блока. Фіг. 4А та фіг. 4В являють собою концептуальні схеми, що ілюструють зразкове квадрадерево 150 і відповідний найбільший елемент 172 кодування. Фіг. 4А зображає зразкове квадрадерево 150, яке включає в себе вузли, розподілені ієрархічно. Квадрадерево 150 може бути зв'язане з, наприклад, деревоподібним блоком відповідно до стандарту HEVC, що пропонується. Кожний вузол в квадрадереві, такому як квадрадерево 150, може бути кінцевим вузлом без потомків або може мати чотири дочірніх вузли. У прикладі з фіг. 4А квадрадерево 150 включає в себе кореневий вузол 152. Кореневий вузол 152 має чотири дочірніх вузли, включаючи кінцеві вузли 156А-156С (кінцеві вузли 156) і вузол 154. Оскільки вузол 154 не є кінцевим вузлом, він включає в себе чотири дочірніх вузли, які в цьому прикладі є кінцевими вузлами 158А-158D (кінцевими вузлами 158). Квадрадерево 150 може включати в себе дані, що описують характеристики відповідного найбільшого елемента кодування (LCU), такого як LCU 172 в цьому прикладі. Наприклад, квадрадерево 150, за допомогою своєї структури, може описувати розбиття LCU на суб-CU. Припустимо, що LCU 172 має розмір 2Nx2N. LCU 172 в цьому прикладі має чотири суб-CU 18 UA 111216 C2 5 10 1520 25 30 35 40 45 50 55 60 176А-176С (суб-CU 176) і 174, кожний розміру NxN. Суб-CU 174 додатково розбивається на чотири суб-CU 178А-178D (суб-CU 178), кожний розміру N/2xN/2. Структура квадрадерева 150 відповідає розбиттю LCU 172 в цьому прикладі. Тобто кореневий вузол 152 відповідає LCU 172, кінцеві вузли 156 відповідають суб-CU 176, вузол 154 відповідає суб-CU 174, а кінцеві вузли 158 відповідають суб-CU 178. Дані для вузлів квадрадерева 150 можуть описувати, чи розбивається CU, що відповідає вузлу. Якщо CU розбивається, чотири додаткових вузли можуть бути представлені в квадрадереві 150. У деяких прикладах вузол квадрадерева може реалізовуватися подібно до наступного псевдокоду: quadtree_node { boolean split_flag(1); //signaling data if (split_flag) { quadtree_node child1; quadtree_node child2; quadtree_node child3; quadtree_node child4; } } Значення split_flag може бути однобітовим значенням, яке відображає, чи розбивається CU, що відповідає поточному вузлу. Якщо CU не розбивається, значення split_flag може бути "0", тоді як якщо CU розбивається, значення split_flag може бути "1". З посиланням на приклад квадрадерева 150 масив значень прапора розбиття може бути 101000000. Як було зазначено вище, глибина CU може відноситися до величини, на яку був розділений LCU 172. Наприклад, кореневий вузол 152 може відповідати глибині CU нуль, тоді як вузол 154 і кінцеві вузли 156 можуть відповідати глибині CU один. Крім того, кінцеві вузли 158 можуть відповідати глибині CU два. Відповідно до аспектів цього розкриття глибина CU і/або TU може використовуватися як контекст для ентропійного кодування визначених синтаксичних елементів. У прикладі в роз'яснювальних цілях один або більше синтаксичних елементів, зв'язаних з кінцевим вузлом 156А, можуть зазнавати ентропійного кодування з використанням моделі контексту, відмінної від тієї, що використовується для кінцевого вузла 158А, оскільки кінцевий вузол 156А розташовується на глибині один, тоді як кінцевий вузол 158А знаходиться на глибині два. При тому, що фіг. 4А ілюструє приклад квадрадерева CU, потрібно розуміти, що подібне квадрадерево може застосовуватися до TU з CU кінцевого вузла. Тобто CU кінцевого вузла може включати в себе квадрадерево TU (що називається залишковим квадрадеревом (RQT)), яке описує розбиття блоків TU для CU. Квадрадерево TU загалом може нагадувати квадрадерево CU, за винятком того, що квадрадерево TU може сигналізувати режими внутрішнього прогнозування для блоків TU з CU окремо. Відповідно до деяких аспектів цього розкриття відеокодер (такий як відеокодер 20 і/або відеодекодер 30) може визначати інформацію прогнозування для поточного блока на основі інформації прогнозування з визначених сусідніх CU. Наприклад, як описується нижче більш детально, відеокодер може визначати інформацію прогнозування для суб-CU 178С на основі сусідніх CU, таких як суб-CU 176А. У деяких прикладах відеокодер може уникати визначення інформації прогнозування на основі визначених сусідніх CU, таких як верхній сусідній суб-CU 178. Однак відповідно до аспектів цього розкриття, як описується більш детально нижче, відеокодер може визначати інформацію прогнозування, використовуючи верхні сусідні CU, якщо інформація для верхніх сусідніх CU не вимагає зберігання в лінійному буфері. Наприклад, відповідно до аспектів цього розкриття відеокодер може визначати інформацію прогнозування для суб-CU 178С на основі верхнього сусіднього суб-CU 178А, оскільки верхній сусідній суб-CU 178А розташовується в тому самому LCU (тобто LCU 172), що і суб-CU 178С. У деяких прикладах дані, зв'язані з усіма CU в LCU, доступні (наприклад, без зовнішньої буферизації) при кодуванні LCU. Відповідно, відповідно до аспектів цього розкриття відеокодер може використовувати інформацію прогнозування, зв'язану з блоками LCU, без буферизації інформації прогнозування. Тобто, відповідно до аспектів цього розкриття відеокодер може визначати інформацію прогнозування для суб-CU 178С на основі верхнього сусіднього суб-CU 178А без буферизації інформації прогнозування суб-CU 178А в лінійному буфері. Фіг. 5 являє собою схему, яка ілюструє зразкові сусідні блоки, на основі яких може бути визначений найбільш імовірний внутрішній режим при внутрішньому кодуванні блока. Наприклад, в роз'яснювальних цілях припустимо, що відеодекодер (такий як відеодекодер 30) в 19 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 поточний момент декодує синтаксичні елементи, що відображають конкретний режим прогнозування (наприклад, режим внутрішнього прогнозування) пікселів у межах поточного блока 180. У цьому прикладі відеодекодер 30 може ідентифікувати режими внутрішнього прогнозування з верхнього сусіднього блока 182 і лівого сусіднього блока 184, щоб визначити контекст для поточного синтаксичного елемента. Відповідно, модель контексту, що використовується для ентропійного декодування поточного синтаксичного елемента, може залежати від режимів внутрішнього прогнозування верхнього сусіднього блока 182 і лівого сусіднього блока 184. У цьому прикладі відеодекодер 30 може зберігати або буферизувати дані, що відображають режими внутрішнього прогнозування верхнього сусіднього блока 182 і лівого сусіднього блока 184, так, що такі дані доступні при виконанні внутрішнього прогнозування. Наприклад, відеодекодер 30 може зберігати режим внутрішнього прогнозування верхнього сусіднього блока 182 в лінійному буфері, який збільшує ширину зображення, що містить блоки 180-184, так, що режим внутрішнього прогнозування доступний для використання як контекст для кодування поточного блока 180. Однак в міру того як розрізнення відео і ширина кадрів (наприклад, кількість пікселів праворуч наліво упоперек заданого відеокадру) зростають, кількість даних, яка зберігається в лінійному буфері, також збільшується. У деяких прикладах, як зазначено вище, блоки даних до 4 × 4 пікселя можуть використовуватися, щоб кодувати зображення. Як приклад зображення 1920 × 1080 пікселів (наприклад, відео 1080р) може включати в себе ширину, що має не менше за 495 блоків 4 × 4 пікселя. Кожний блок може мати відповідний режим внутрішнього прогнозування. З 35 потенційними режимами внутрішнього прогнозування відеодекодер 30 може зберігати до шести бітів інформації прогнозування для кожного з 495 блоків. Відповідно, якщо режими внутрішнього прогнозування для кожного блока зображення зберігаються в лінійному буфері (який в прикладі, показаному на фіг. 5, включає в себе блок 182), від відеодекодера 30 може бути потрібне зберігання відносно значної кількості даних в лінійному буфері. Методики цього розкриття загалом стосуються обмеження кількості даних внутрішнього режиму із сусідніх блоків, які буферизуються під час кодування. Тобто аспекти цього розкриття стосуються обмеження кількості даних внутрішнього режиму із сусідніх блоків, які зберігаються в лінійному буфері для використання при виведенні найбільш імовірного режиму. Як описується більш детально нижче з посиланням на фіг. 7 і де-небудь ще в цьому розкритті, відповідно до аспектів цього розкриття відеокодер (такий як відеокодер 20 або відеодекодер 30) може визначати найбільш імовірний внутрішній режим для поточного блока 180 на основі лівого сусіднього блока 184 (як і одного або більше інших лівих сусідніх блоків, як показано в прикладі з фіг. 8), але не основуючись на верхньому сусідньому блоці 182. У цьому прикладі відеокодер може уникати зберігання внутрішнього режиму верхнього сусіднього блока 182 в лінійному буфері, оскільки внутрішній режим не використовується для визначення найбільш імовірного внутрішнього режиму для поточного блока 180. В інших прикладах відеокодер може визначати внутрішній режим поточного блока 180 на основі верхнього сусіднього блока 182, але тільки коли верхній сусідній блок - з того самого LCU, що і поточний блок 180. У такому прикладі внутрішній режим для верхнього сусіднього блока 182 може бути доступний (без зберігання в лінійному буфері), оскільки вся інформація з LCU звичайно доступна під час кодування LCU. Якщо ж верхній сусідній блок 182 з іншого LCU, дані, зв'язані з верхнім сусіднім блоком 182, можуть бути включені в інший LCU (наприклад, в кодованому бітовому потоці). Відповідно, в тому прикладі відеокодеру може бути треба буферизувати внутрішній режим, який вимагає ресурсів пам'яті і може також запобігти паралельному кодуванню різних LCU, як описується вище. Різноманіття інших методик, як описується нижче, також може використовуватися, щоб скоротити кількість предиктивної інформації, яка буферизується під час кодування відео. Фіг. 6 являє собою схему, яка ілюструє потенційних кандидатів для предиктора вектора руху при здійсненні прогнозування вектора руху (включаючи AMVP і режим злиття). Тобто для блока 188, що кодується в поточний момент, інформація руху (наприклад, вектор руху, що містить горизонтальний компонент і вертикальний компонент, індекси вектора руху, напрямки прогнозування або іншу інформацію) із сусідніх блоків А0, А1, В0, В1 та В2 може використовуватися для прогнозування інформації руху для блока 188. Крім того, інформація руху, зв'язана з часовим спільно розміщеним блоком COL, також може використовуватися для прогнозування інформації руху для блока 188 (наприклад, спільно розміщеного блока в опорному зображенні). Сусідні блоки А0, А1, В0, В1 та В2 і спільно розміщений блок COL в 20 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 контексті прогнозування вектора руху можуть загалом називатися далі кандидатами для предиктора вектора руху. У деяких прикладах кандидати для предиктора вектора руху, показані на фіг. 6, можуть бути ідентифіковані при виконанні прогнозування вектора руху (наприклад, чи буде це генерація MVD або виконання режиму злиття). В інших прикладах різні кандидати можуть бути ідентифіковані при виконанні режиму злиття і прогнозування вектора руху. Тобто відеокодер (такий як відеокодер 20 або відеодекодер 30) може ідентифікувати іншу групу кандидатів для предиктора вектора руху для виконання режиму злиття, ніж для виконання прогнозування вектора руху. Щоб виконувати режим злиття, в одному прикладі відеокодер (такий як відеокодер 20) може спочатку визначати, які вектори руху з кандидатів для предиктора вектора руху доступні для злиття з блоком 188. Тобто в деяких випадках інформація руху від одного або декількох кандидатів для предиктора вектора руху може бути недоступна внаслідок того, наприклад, що кандидат для предиктора вектора руху піддається внутрішньому кодуванню, ще не кодується або не існує (наприклад, один або декілька кандидатів для предиктора вектора руху знаходяться в іншому зображенні або фрагменті). Відеокодер 20 може створювати список кандидатів для предиктора вектора руху, який включає в себе кожний з блоків кандидатів для предиктора вектора руху. Після створення списку кандидатів відеокодер 20 може вибирати вектор руху зі списку кандидатів для використання як вектора руху для поточного блока 100. У деяких прикладах відеокодер 20 може вибирати той вектор руху зі списку кандидатів, який максимально співпадає з вектором руху для блока 188. Тобто відеокодер 20 може вибирати вектор руху зі списку кандидатів відповідно до аналізу швидкості-спотворення. Відеокодер 20 може забезпечувати індикацію того, що блок 188 кодується з використанням режиму злиття. Наприклад, відеокодер 20 може задавати прапор або інший синтаксичний елемент, який відображає, що вектор руху для блока 188 прогнозується з використанням режиму злиття. У прикладі відеокодер 20 може відображати, що параметри зовнішнього прогнозування для блока 188 виводяться на основі кандидата для предиктора вектора руху шляхом встановлення merge_flag [x0][y0]. У цьому прикладі індекси масиву x0, y0 можуть визначати місцеположення (x0, y0) верхнього лівого зразка яскравості блока прогнозування відносно верхнього лівого зразка яскравості зображення (або фрагмента). Додатково до цього в деяких прикладах відеокодер 20 може забезпечувати індекс, що відображає кандидата для злиття, від якого блок 188 успадковує свій вектор руху. Наприклад, merge_idx [x0][y0] може визначати індекс кандидата для злиття, який ідентифікує зображення в списку кандидатів для злиття і де x0, y0 визначає місцеположення (x0, y0) верхнього лівого зразка яскравості блока прогнозування відносно верхнього лівого зразка яскравості зображення (або фрагмента). Відеодекодер (такий як відеодекодер 30) може виконувати схожі етапи, щоб ідентифікувати належного кандидата для злиття при декодуванні блока 188. Наприклад, відеодекодер 30 може приймати індикацію того, що блок 188 прогнозується з використанням режиму злиття. У прикладі відеодекодер 30 може приймати merge_flag [x0][y0], де x0, y0 визначають місцеположення (x0, y0) верхнього лівого зразка яскравості (що відповідає пікселю в блоці) блока прогнозування відносно верхнього лівого зразка яскравості зображення (або фрагмента). Описані відносно зразків яскравості, методики, представлені вище, також можуть виконуватися для зразків кольоровості. У деяких прикладах відеодекодер 30 може масштабувати предиктор вектора руху до об'єднання інформації руху блока-кандидата з блоком 188. Наприклад, якщо предиктор вектора руху відноситься до предиктивного блока в опорному зображенні, яке розташовується в іншій часовій точки, ніж предиктивний блок, до якого відноситься блок 188 (наприклад, актуальний вектор руху для блока 188), відеодекодер 30 може масштабувати предиктор вектора руху. Наприклад, відеодекодер 30 може масштабувати предиктор вектора руху так, що той відноситься до того самого опорного зображення, що і опорне зображення для блока 188. У деяких прикладах відеодекодер 30 може масштабувати предиктор вектора руху відповідно до значень підрахунку порядку зображень (РОС). Після вибору предиктора вектора руху відеодекодер 30 може об'єднувати інформацію руху, зв'язану з предиктором вектора руху, з інформацією руху для блока 188. Крім того, відеодекодер 30 може створювати список кандидатів для злиття. Наприклад, відеодекодер 30 може приймати один або декілька синтаксичних елементів (наприклад, прапорів), що відображають відеоблоки, які доступні для прогнозування вектора руху. Відеодекодер 30 може створювати список кандидатів для злиття на основі прийнятих прапорів. 21 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 Якщо деякі кандидати для злиття мають однакові вектори руху та однакові опорні індекси, деякі з надмірних кандидатів для злиття можуть бути видалені (тобто прибрані) зі списку. Відеодекодер 30 може ідентифікувати належного кандидата для злиття відповідно до прийнятого індексу. Наприклад, відеодекодер 30 може приймати індекс, що ідентифікує кандидата для злиття, від якого блок 188 успадковує свій вектор руху. Наприклад, merge_idx [x0][y0] може визначати індекс кандидата для злиття, який ідентифікує зображення в списку кандидатів для злиття і де x0, y0 визначає місцеположення (x0, y0) верхнього лівого зразка яскравості блока прогнозування відносно верхнього лівого зразка яскравості зображення (або фрагмента). Схожий процес може здійснюватися відеокодером 20 і відеодекодером 30, щоб виконати прогнозування вектора руху для поточного блока відеоданих. Наприклад, відеокодер 20 може спочатку визначати, які вектори руху з кандидатів для предиктора вектора руху доступні для використання як MVP. Інформація руху від одного або декількох кандидатів для предиктора вектора руху може бути недоступна внаслідок того, наприклад, що кандидат для предиктора вектора руху піддається внутрішньому кодуванню, ще не кодується або не існує (наприклад, не включений в зображення або фрагмент, як то блоки над верхнім рядком блоків у зображенні або фрагменті). Щоб визначити, які з кандидатів для предиктора вектора руху доступні, відеокодер 20 може аналізувати кожний з кандидатів для предиктора вектора руху по черзі відповідно до визначеної заздалегідь схеми на основі пріоритетів. Наприклад, для кожного кандидата для предиктора вектора руху відеокодер 20 може визначати, чи відноситься предиктор вектора руху до того самого опорного зображення, що і актуальний вектор руху для блока 188. Якщо предиктор вектора руху відноситься до того самого опорного зображення, відеокодер 20 може додати кандидата для предиктора вектора руху в список кандидатів MVP. Якщо предиктор вектора руху не відноситься до того самого опорного зображення, він може бути масштабований (наприклад, масштабований на основі відстаней РОС, як розглядається вище) до того, як буде доданий до списку кандидатів MVP. Що стосується спільно розміщеного блока COL, якщо спільно розміщений блок включає в себе більше одного предиктора вектора руху (наприклад, COL прогнозується як В-кадр), відеокодер 20 може вибирати один з часових предикторів вектора руху відповідно до поточного списку і поточного опорного зображення (для блока 188). Відеокодер 20 потім може додавати вибраний часовий предиктор вектора руху в список кандидатів для предиктора вектора руху. Відеокодер 20 може сигналізувати, що один або декілька предикторів вектора руху доступні, шляхом встановлення enable_temporal_mvp_flag. Після створення списку кандидатів відеокодер 20 може вибирати вектор руху серед кандидатів для використання як предиктора вектора руху для блока 100. У деяких прикладах відеокодер 20 може вибирати кандидата для вектора руху відповідно до аналізу швидкості-спотворення. Відеокодер 20 може сигналізувати вибраний предиктор вектора руху з використанням індексу MVP (mvp_flag), який ідентифікує MVP в списку кандидатів. Наприклад, відеокодер 20 може встановлювати mvp_10_flag[x0][y0], щоб визначити індекс предиктора вектора руху в списку 0, де x0, y0 визначають місцеположення (x0, y0) верхнього лівого зразка яскравості блока-кандидата відносно верхнього лівого зразка яскравості зображення. В іншому прикладі відеокодер 20 може встановлювати mvp_11_flag[x0][y0], щоб визначити індекс предиктора вектора руху в списку 1, де x0, y0 визначають місцеположення (x0, y0) верхнього лівого зразка яскравості блока-кандидата відносно верхнього лівого зразка яскравості зображення. Ще в одному прикладі відеокодер 20 може встановлювати mvp_1с_flag[x0][y0], щоб визначити індекс предиктора вектора руху в списку з, де x0, y0 визначають місцеположення (x0, y0) верхнього лівого зразка яскравості блока-кандидата відносно верхнього лівого зразка яскравості зображення. Відеокодер 20 також може генерувати значення різниці вектора руху (MVD). MVD може становити різницю між вибраним предиктором вектора руху та актуальним вектором руху для блока 188. Відеокодер 20 може сполучати MVD з індексом MVP. Відеодекодер 30 може здійснювати схожі операції, щоб визначити вектор руху для поточного блока з використанням предиктора вектора руху. Наприклад, відеодекодер 30 може приймати індикацію в групі параметрів (наприклад, групі параметрів зображення (PPS)), яка відображає, що прогнозування вектора руху можливо для одного або декількох зображень. Тобто в прикладі відеодекодер 30 може приймати enable_temporal_mvp_flag в PPS. Коли конкретне зображення спирається на PPS, що має enable_temporal_mvp_flag, рівний нулю, опорні зображення в пам'яті опорних зображень можуть бути помічені як "невикористовувані для часового прогнозування вектора руху". 22 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 Якщо прогнозування вектора руху здійснюється, після прийому блока 188 відеодекодер 30 може створювати список кандидатів MVP. Відеодекодер 30 може використовувати ту саму схему, що була описана вище у відношенні відеокодера 20 при створенні списку кандидатів MVP. У деяких випадках відеодекодер 30 може здійснювати масштабування вектора руху подібно до того, як було описано вище у відношенні відеокодера 20. Наприклад, якщо предиктор вектора руху не відноситься до того самого опорного зображення, що і блок 188, він може бути масштабований (наприклад, масштабований на основі відстаней РОС, як розглядається вище) до того, як буде доданий до списку кандидатів MVP. Відеодекодер 30 може ідентифікувати належний предиктор вектора руху для блока 188, використовуючи прийнятий індекс MVP (mvp_flag), який ідентифікує MVP в списку кандидатів. Потім відеодекодер 30 може генерувати вектор руху для блока 100, використовуючи MVP і прийняту MVD. Потрібно розуміти, що блоки-кандидати для предиктора вектора руху, показані на фіг. 6, пропонуються лише для прикладу і що більше, менше блоків або інші блоки можуть використовуватися з метою прогнозування інформації руху. У будь-якому випадку відеокодер (такий як відеокодер 20 або відеодекодер 30) може зберігати або буферизувати інформацію руху для А0, А1, В0, В1 та В2 і спільно розміщеного блока COL так, що дані доступні при генерації MVD або виконанні режиму злиття. Наприклад, відеокодер може зберігати інформацію руху (наприклад, вектори руху, індекси опорних зображень, напрямки прогнозування або інша інформація) верхніх сусідніх блоків В0, В1 та В2 в лінійному буфері, який збільшує ширину зображення, що містить блоки, так, що інформація руху доступна під час внутрішнього прогнозування блока 188. Однак, як зазначено вище, кількість даних, що зберігаються в лінійному буфері, може відносно великою. Наприклад, зображення 1920 × 1080 пікселів (наприклад, відео 1080р) може включати в себе ширину, що має не менше 495 блоків 4 × 4 пікселя, при цьому кожний блок потенційно має свою власну інформацію руху. Крім того, може бути до 16 опорних зображень, доступних для кодування кожного зображення. Відповідно, коли вся інформація руху для кожного блока зображення в лінійному буфері зберігається, від відеокодера може бути потрібне зберігання відносно значної кількості даних в лінійному буфері. Відповідно до аспектів цього розкриття відеокодер (такий як відеокодер 20 або відеодекодер 30) може обмежувати кількість точок, з яких визначається інформація руху для блока 188, щоб скоротити кількість даних, що зберігаються в лінійному буфері під час кодування. Тобто, наприклад, замість визначення інформації руху (наприклад, MVP або кандидата для злиття) для кодування блока 188 з усіх А0, А1, В0, В1 та В2 відеокодер може визначати інформацію руху для блока 188 на основі тільки підгрупи кандидатів. Відповідно до аспектів цього розкриття відеокодер може визначати інформацію руху для блока 188 на основі лівих сусідніх блоків А0 та А1 і спільно розміщеного блока COL, але не на основі верхніх сусідніх блоків В0, В1 або В2. Тобто, наприклад, відеокодер може визначати інформацію руху для блока 188 тільки основуючись на лівих сусідніх блоках А0 та А1 і спільно розміщеному блоці COL. У цьому прикладі відеокодер може уникати збереження інформації руху, зв'язаної з верхніми сусідніми блоками В0, В1 або В2 в лінійному буфері, оскільки інформація руху не використовується для визначення MVP або кандидата для злиття для блока 188. В інших прикладах відеокодер може визначати інформацію руху для блока 188 на основі одного або декількох верхніх сусідніх блоків В0, В1 або В2 (наприклад, додатково до А0 та А1 і спільно розміщеному блока COL), але тільки коли верхні сусідні блоки - з того самого LCU, що і поточний блок 188. У такому інформація руху для верхніх сусідніх блоків В0, В1 або В2 може бути доступна (без зберігання в лінійному буфері), оскільки вся інформація з LCU звичайно доступна під час кодування LCU. Різноманіття інших методик, як описується нижче, також може використовуватися, щоб скоротити кількість інформації прогнозування, яка буферизується під час кодування відео. Фіг. 7 являє собою схему, яка ілюструє зразкові сусідні блоки, на основі яких може бути визначена інформація прогнозування відповідно до аспектів цього розкриття. Приклад, показаний на фіг. 7, загалом описується як такий, що реалізовується відеокодером. Потрібно розуміти, що в деяких прикладах методика з фіг. 7 може виконуватися відеокодером 20 (фіг. 1 та фіг. 2) або відеодекодером 30 (фіг. 1 та фіг. 3), описаними вище. В інших прикладах методика з фіг. 7 може реалізовуватися множиною інших процесорів, модулів обробки, модулів кодування на основі апаратного забезпечення, таких як кодер/декодери (CODEC), тощо. Відеокодер може в поточний момент кодувати (наприклад, здійснювати зовнішнє кодування або внутрішнє кодування) поточний блок 190 кодованого елемента 191. Кодований елемент 191 загалом може включати в себе визначену заздалегідь кількість відеоданих, що включає в себе 23 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 множинні блоки, такі як, наприклад, LCU, фрагмент, елемент мозаїчного зображення, група елементів мозаїчного зображення, група хвильових фронтів, або будь-який інший заздалегідь визначений елемент, який включає в себе множинні блоки відеоданих. При тому що верхні сусідні блоки 194, ліві сусідні блоки 192 і блоки 196 загалом показані як неподілені блоки в прикладі з фіг. 7, потрібно розуміти, що такі блоки можуть бути розділені на один або декілька менших блоків. Відповідно до аспектів цього розкриття, замість використання інформації прогнозування з верхніх сусідніх блоків 194 для кодування блока 190 відеокодер може використовувати тільки інформацію прогнозування (наприклад, інформацію внутрішнього або зовнішнього прогнозування) з лівих сусідніх блоків 192. Наприклад, відеокодер може не використовувати дані з верхніх сусідніх блоків 194 або раніше кодованих блоків 196, які не розташовуються по сусідству з поточним блоком 190, при здійсненні зовнішнього прогнозування або внутрішнього прогнозування для поточного блока 190. У цьому прикладі відеокодер може буферизувати менше даних, ніж коли інформація прогнозування для всіх сусідніх блоків (наприклад, як показано на фіг. 5 та фіг. 6) використовується під час кодування. Наприклад, припускаючи, що розмір максимального LCU-64 × 64 пікселя, розмір найменшого CU-4 × 4 пікселя, відеодекодер 30 може потенційно буферизувати дані, зв'язані тільки з 16 блоками відеоданих (наприклад, 64/4=16 потенційних лівих сусідніх блоків). Шляхом обмеження точок, з яких виводиться інформація контексту, як показано та описано в прикладі з фіг. 7, відеокодер може скоротити кількість даних, які буферизуються з метою прогнозування. Крім того, відеокодер може збільшити аналітичну продуктивність. Наприклад, як зазначено вище, відеодекодер (такий як відеодекодер 30) може аналізувати прийняті відеодані відповідно до конкретного процесу аналізу (наприклад, аналіз хвильового фронту). У прикладах, в яких відеодекодер 30 не визначає інформацію прогнозування з визначених сусідніх блоків, таких як верхні сусідні блоки 194, відеодекодер 30 може усувати залежність, щоб поліпшити аналітичну продуктивність і можливість обробляти відеодані паралельно. Крім того, усунення залежності може знизити потенціал для помилок виведення прогнозувань, таким чином додатково вдосконалюючи процес аналізу. Фіг. 8 являє собою іншу блок-схему, яка ілюструє зразкові сусідні блоки, на основі яких може бути визначена інформація прогнозування для кодування блока. У прикладі, показаному на фіг. 8, відеокодер (такий як відеокодер 20 або відеодекодер 30) може визначати інформацію прогнозування для блока 200, що кодується в даний момент, на основі лівого сусіднього блока L і нижнього лівого сусіднього блока BL. У порівнянні з прикладом, показаним на фіг. 7, приклад з фіг. 8 додає додатковий лівий сусідній блок, на основі якого можна вивести інформацію прогнозування. У прикладі, показаному на фіг. 8, як і в прикладі, продемонстрованому на фіг. 7, лінійний буфер для зберігання інформації прогнозування (наприклад, внутрішніх режимів або інформації руху) для верхніх сусідніх блоків відносно поточного блока 200 може зовсім бути не потрібен. Як пояснюється вище, LCU може розбиватися на різне компонування CU. Так, блоки L та BL з фіг. 8 можуть відрізнятися від блоків CU одного і того самого LCU. Що стосується внутрішнього прогнозування, обидва: блок L і блок BL - можуть кодуватися з використанням одного і того самого режиму внутрішнього прогнозування, але в деяких випадках вони можуть кодуватися з використанням різних режимів внутрішнього прогнозування. На основі режиму внутрішнього прогнозування блока L і режиму внутрішнього прогнозування блока BL може бути визначений найбільш імовірний режим внутрішнього прогнозування для поточного блока 200. Наприклад, якщо обидва: блок L і блок BL - були кодовані з використанням Режиму 6 (із заздалегідь визначеної кількості внутрішніх режимів), найбільш імовірний режим внутрішнього прогнозування для поточного блока 200 також може бути Режимом 6. Ще Режим 6 може не бути актуальним режимом прогнозування для блока 200, але може бути статистично найбільш імовірним режимом для блока 200 з урахуванням контексту для блока 200 (тобто режимів прогнозування блоків, сусідніх з блоком 200). В іншому прикладі, з метою підвищити ефективність кодування і уникнути надмірності, якщо блоки L та BL мають один і той самий режим внутрішнього прогнозування, третій блок зліва від поточного блока 200 також може використовуватися при визначенні найбільш імовірного режиму. Потрібно зазначити, що блоки L та BL (або третій лівий блок) не обов'язково повинні бути напряму прямо суміжними з блоком 200, а можуть бути одним або декількома стовпцями зліва від блока 200. Якщо блок L і блок BL кодуються з використанням Режимів 3 та 8 відповідно, то найбільш імовірним режим для блока 200 може бути Режим 3, Режим 8 або інший режим. Найбільш імовірний режим для конкретного контексту може вибиратися шляхом ідентифікації режиму внутрішнього прогнозування, який статистично більш імовірний для цього 24 UA 111216 C2 5 10 15 контексту. Шляхом уникнення використання верхнього блока для визначення найбільш імовірного режиму потреба в лінійному буфері для зберігання режимів внутрішнього прогнозування для верхніх блоків може бути усунена. Що стосується зовнішнього прогнозування, інформація руху, що включає в себе відображаючі вектор руху (mvx, mvy) координати х і у вектора руху, опорний індекс (ref_idx), що вказує на опорне зображення в списку опорних кадрів, і напрямок прогнозування (inter_dir), що відображає, який список опорних кадрів використовувати (наприклад, L0 або L1), може зберігатися для блоків, сусідніх з блоком 200. У деяких прикладах вся інформація руху може зберігатися у відповідних лінійних буферах. Відповідно до аспектів цього розкриття відеокодер може зберігати інформацію руху тільки для блока L і блока BL і виключати інформацію руху для верхніх сусідніх блоків. Відповідно до деяких прикладів можлива втрата продуктивності, зв'язана з скороченням кількості кандидатів для прогнозування вектора руху, може компенсуватися генерацією додаткових кандидатів руху. Наприклад, як показано в зразковій таблиці 1 нижче, відеокодер може генерувати додаткових кандидатів руху, використовуючи доступну інформацію руху, таку як інформація руху блоків L та BL. Таблиця 1 Merge idx 0 1 2 3 4 20 25 30 35 40 45 50 Згенеровані кандидати руху L0 L1 mvL0_A, ref0 mvL1_B, ref0 mvL0_A, ref0 mvL1_B, ref0 mvL0_A, ref0 mvL0’_A, ref0’ mvL1’_B, ref0’ mvL1_B, ref0 Від L Від BL Згенерований Згенерований Згенерований Як показано в прикладі з таблиці 1, відеокодер може генерувати кандидати для злиття руху (2), (3) та (4), використовуючи інформацію руху з блоків L та BL. Тобто інформація руху (inter_dir, ref_dir та mv) кандидатів L та BL може використовуватися, щоб генерувати нові кандидати руху. У цьому прикладі mvLX_Y може відображати вектор руху списку X в Y-ому кандидаті, mvLX'_Y може відображати оброблений вектор руху LX_Y, refN в N-ому опорному зображенні в списку посилань. Згенерована інформація руху, показана в таблиці 1, може бути створена шляхом масштабування, зміщення, обмеження або іншого модифікування існуючої інформації руху. При тому, що приклад з фіг. 8 описується з посиланням на L та BL, як зазначено вище, інші блоки також можуть використовуватися (наприклад, додаткові блоки, блоки, не сусідні з блоком 200, тощо). Крім того, методики, описані відносно режиму злиття (наприклад, як показано в таблиці 1), можуть подібним чином застосовуватися відносно прогнозування вектора руху з використанням MVD. Фіг. 9 являє собою іншу схему, яка ілюструє зразкові сусідні блоки, на основі яких може бути визначена інформація прогнозування для кодування блока. Наприклад, аспекти цього розкриття включають в себе визначення інформації прогнозування для поточного блока 205 на основі множини лівих сусідніх блоків L00-L0N, L10-L1N, L20-L2N, BL0-BLN і так далі. У деяких прикладах відеокодер може визначати інформацію прогнозування на основі блоків з одного або декількох стовпців зліва від блока, що піддається кодуванню. Тобто відносно зовнішнього кодування фінальний список кандидатів для вектора руху може бути створений за допомогою блоків, вибраних з множини лівих сусідніх блоків. Що стосується внутрішнього кодування, внутрішні режими з множини лівих сусідніх блоків можуть використовуватися для виведення найбільш імовірного режиму. Додаткові ліві сусідні блоки (наприклад, зліва від граничних блоків LN0), як показано в прикладі з фіг. 9, можуть використовуватися для компенсації втрати продуктивності, зв'язаної з відсутністю буферизації інформації прогнозування лівих сусідніх блоків. Наприклад, в деяких випадках внутрішній режим верхнього сусіднього блока може співпадати з тим, що використовується для блока 205. В інших випадках вектор руху, зв'язаний з верхнім сусіднім блоком, може співпадати або майже співпадати з вектором руху блока 205. У цих випадках запобігання пошуку відеокодером даних з верхніх сусідніх блоків під час кодування може призвести до втрати продуктивності кодування, оскільки відеокодер може бути змушений шукати менш точний предиктор. Однак шляхом збільшення кількості лівих сусідніх блоків, на основі яких відеокодером можуть відшукуватися дані для визначення інформації прогнозування, потенціал знаходження предиктора відносно високої якості може зрости. 25 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 У деяких прикладах ліві сусідні блоки, показані на фіг. 9, можуть бути різними CU, які формують один і той самий LCU. В інших прикладах ліві сусідні блоки можуть бути включені в різні LCU. Фіг. 10 являє собою іншу схему, яка ілюструє зразкові сусідні блоки, на основі яких може бути визначена інформація прогнозування для кодування блока. Наприклад, на відміну від того щоб утримуватися від зберігання яких-небудь даних, зв'язаних з верхніми сусідніми блоками, іншим способом скорочення кількості даних лінійного буфера з метою прогнозування (наприклад, зовнішнього кодування або внутрішнього кодування) є скорочення кількості блоків, які зберігаються в лінійному буфері. У прикладі, показаному на фіг. 10, блок 210 кодується в даний момент, тоді як блоки 212 були кодовані раніше. У деяких прикладах інформація прогнозування (наприклад, внутрішні режими або інформація руху), зв'язана з блоками 214А та 214В (разом - блоки 214), може зберігатися в лінійному буфері. Відповідно до аспектів цього розкриття, однак тільки підгрупа даних, зв'язаних з блоками 214, може зберігатися в лінійному буфері. Тобто в прикладі, показаному на фіг. 10, інформація прогнозування, зв'язана з блоками 214А, може зберігатися в лінійному буфері, тоді як інформація прогнозування, зв'язана з блоками 214В, може бути видалена з лінійного буфера. При тому, що приклад з фіг. 10 демонструє блоки 214А та 214В, що мають рівний розмір, в інших прикладах може застосовуватися інша схема субдискретизації, яка дозволяє тільки частині інформації прогнозування з блоків 214 зберігатися в лінійному буфері. Тобто в інших прикладах блоки 214А можуть бути більше або менше, ніж блоки 214В. У прикладі, показаному на фіг. 10, якщо відеокодеру (такому як відеокодер 20 або відеодекодер 30) треба визначити інформацію прогнозування з одного з блоків 214А, він може зчитувати інформацію прогнозування з лінійного буфера. Тобто, наприклад, якщо один з блоків 214А включає в себе контекст для визначення найбільш імовірного режиму для блока 210, відеокодер може зчитувати внутрішній режим з лінійного буфера. Як альтернатива, якщо відеокодеру треба визначити інформацію прогнозування з одного з блоків 214В, він може виводити інформацію прогнозування для блока на основі підгрупи інформації прогнозування, що зберігається в буфері. Виведення може, наприклад, бути основане на копіюванні інформації прогнозування для одного або декількох ближніх блоків 214А, яка зберігається в буфері, інтерполюванні інформації руху, яка зберігається в буфері, або виведення інформації прогнозування яким-небудь іншим способом на основі інформації прогнозування, що зберігається для блоків 214А. Фіг. 11 являє собою концептуальну схему, яка ілюструє приклад обмеження (наприклад, зменшення бітової глибини) векторів руху, що зберігаються в буфері. Тобто, наприклад, іншим способом скоротити кількість інформації прогнозування, яка зберігається в лінійному буфері (і, зокрема, векторів руху для зовнішнього прогнозування), може бути скорочення кількості бітів, які використовуються при зберіганні кожного компонента кожного вектора руху. У цьому прикладі, як показано на фіг. 11, кожний вектор руху, який зберігається в лінійному буфері (наприклад, вектори руху, зв'язані з верхніми сусідніми блоками), може бути обмежений до N бітів, де кожний вектор руху спочатку становить М бітів (М більше N). У прикладі з фіг. 11 М дорівнює 12, а N дорівнює 8, хоча інші варіанти кількості бітів також можуть застосовуватися. Потрібно розуміти, що конкретний вираз цілого, показаний на фіг. 11, може не відповідати фізичному виразу (відомому як арифметика кодів з доповненням до двох), але пропонується з метою пояснення. При зразковому обмеженні бітів, показаному на фіг. 11, максимальний діапазон вектора руху без точності до субпікселя ("субпела»/«sub-pel") становить 64. Коли рух невеликий, обмеження може мати відносно малий вплив або відсутність впливу на ефективність кодування. Фіг. 12 являє собою іншу концептуальну схему, яка ілюструє приклад обмеження векторів руху, що зберігаються в лінійному буфері. Наприклад, якщо релевантний вектор руху відносно великий, менше значущих бітів може бути обмежено. Тобто в прикладі з фіг. 12 найбільш значущі біти і один з бітів субпікселя були обмежені. Точніше, в прикладі з фіг. 12 усувається точність до ¼-пікселя або субпікселя і видаляються 3 найбільш значущих біти, хоча може застосовуватися і інша конфігурація. Кількість бітів, що видаляються з найбільш або найменш значущих бітів (наприклад, як показано на фіг. 11 та фіг. 12), може бути визначена в групі параметрів, такій як SPS або PPS. Фіг. 13 являє собою блок-схему, яка ілюструє граничні CU з LCU. Наприклад, LCU 240 межує з блоками 242, які можуть включати в себе один або декілька інших LCU. У прикладі, показаному на фіг. 13, LCU 240 включає в себе граничні CU 244, які ділять межу з блоками 242, і внутрішніми CU 246, які не межують з блоками 242. Кожний з CU в LCU 240 може мати відповідні PU. 26 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 60 У деяких прикладах, як описується вище, відеокодер може кодувати PU з LCU 240, використовуючи інформацію прогнозування (наприклад, внутрішні режими або інформацію руху) з верхніх сусідніх блоків. Інформація прогнозування для верхніх сусідніх PU з CU 246 може бути легкодоступною, оскільки такі PU включені в один і той самий LCU 242. Однак з метою одержати доступ до інформації прогнозування з верхніх сусідніх блоків 242 при кодуванні граничних PU з CU 244 відеокодер повинен здійснювати доступ до такої інформації з іншого LCU, відмінного від LCU 240, що піддається кодуванню. Щоб бути доступним, наприклад, без здійснення доступу до пам'яті, зовнішньої по відношенню до відеокодера, відеокодер може зберігати таку верхню сусідню інформацію прогнозування в лінійному буфері. Застосування цієї уніфікованої схеми для всіх PU з LCU 240 (який включає в себе буфер для зберігання інформації для граничних CU 244) може допомогти в справі спрощення застосування апаратного забезпечення. Тобто всі PU можуть здійснювати доступ до інформації прогнозування з одних і тих самих зв'язаних точок. Однак виключення даних з верхніх сусідніх блоків 242 в LCU, відмінному від LCU, що містить блоки 244, 246, з можливості бути знайденими під час кодування також може мінімізувати вплив неточностей, які можуть з'являтися при розрахунку на CU за межами LCU 240, таким чином підвищуючи продуктивність кодування. Тобто якщо дані з верхніх сусідніх блоків 242 формують частину іншого фрагмента, який втрачається або інакше руйнується, відеокодер все ще може кодувати граничні CU 244. Відповідно, методики, описані в цьому описі, можуть застосовуватися тільки відносно підгрупи PU з LCU. Тобто, наприклад, методики обмеження кількості даних, що зберігаються в лінійному буфері, можуть застосовуватися тільки у відношенні граничних CU 244 з LCU 240, для чого може знадобитися доступ до лінійного буфера. Фіг. 14 являє собою блок-схему послідовності операцій, що ілюструє зразкові методики для скорочення кількості інформації прогнозування, яка буферизується під час кодування відео. Приклад, показаний на фіг. 14, загалом описується як такий, що реалізовується відеокодером. Потрібно розуміти, що в деяких прикладах методика з фіг. 14 може виконуватися відеокодером 20 (фіг. 1 та фіг. 2) або відеодекодером 30 (фіг. 1 та фіг. 3), описаними вище. В інших прикладах методика з фіг. 14 може реалізовуватися множиною інших процесорів, модулів обробки, модулів кодування на основі апаратного забезпечення, таких як кодер/декодери (CODEC), тощо. Відеокодер може прийняти блок відеоданих кодованого елемента (наприклад, зображення, фрагмента, елемента мозаїчного зображення, групи хвильових фронтів тощо) для ентропійного кодування (260). Відповідно до аспектів цього розкриття блок відеоданих може розташовуватися нижче верхнього рядка блоків у кодованому елементі. У деяких прикладах блок, що кодується в поточний момент, може бути суб-CU, який включений в той самий LCU, що і верхні сусідні суб-CU. В інших прикладах блок може розташовуватися на межі LCU так, що верхні сусідні блоки стосуються LCU, відмінного від поточного блока. Потім відеокодер може визначати інформацію прогнозування для блока на основі інформації прогнозування одного або декількох інших блоків у кодованому елементі, але не на основі блоків з верхнього рядка кодованого елемента (262). Наприклад, якщо перший блок піддається зовнішньому прогнозуванню, відеокодер може визначати інформацію руху (наприклад, вектори руху, індекси опорного зображення, напрямки прогнозування або інша інформація), зв'язану з першим блоком. Як альтернатива, якщо перший блок піддається внутрішньому прогнозуванню, відеокодер може визначати внутрішній режим першого блока. У деяких прикладах, відповідно до аспектів цього розкриття, замість визначення інформації прогнозування для блока на основі верхніх сусідніх блоків, відеокодер може використовувати інформацію прогнозування з лівих сусідніх блоків. У деяких прикладах ліві сусідні блоки можуть бути включені в той самий LCU, що і блок, що кодується в поточний момент. В інших прикладах ліві сусідні блоки можуть бути включені в LCU, відмінний від того, в який включений блок, що кодується в поточний момент. Як зазначено вище, в деяких прикладах один або декілька інших блоків можуть розташовуватися прямо поруч з блоком, що кодується в поточний момент, або можуть знаходитися в декількох блоках від блока. В іншому прикладі блок відеоданих може включати в себе один або декілька блоків LCU, і блоки верхнього рядка можуть включати в себе один або декілька інших LCU. У такому прикладі відповідно до аспектів цього розкриття відеокодер може визначати інформацію прогнозування для блока, використовуючи інформацію прогнозування, зв'язану з іншими блоками LCU, за винятком верхнього рядка верхніх сусідніх блоків (включених в інші LCU). У прикладі в ілюстративних цілях блок, що піддається кодуванню, може включати в себе перший суб-CU LCU, верхні сусідні блоки можуть включати в себе один або декілька інших LCU. Припустимо, що другий суб-CU розташовується над першим суб-CU (в одному і тому самому LCU). У цьому прикладі відеокодер може визначати інформацію прогнозування для першого суб-CU, 27 UA 111216 C2 5 10 15 20 25 30 35 40 45 50 55 використовуючи інформацію на основі другого суб-CU, який розташовується над першим субCU. Потім відеокодер може кодувати блок на основі визначеної інформації прогнозування (264). Наприклад, як описується більш детально з посиланням на фіг. 15 та фіг. 16 нижче, якщо блок це блок, що піддався внутрішньому кодуванню, відеокодер може кодувати блок шляхом визначення найбільш імовірного режиму для блока на основі режимів внутрішнього прогнозування з одного або декількох інших блоків. Як альтернатива, як описується більш детально з посиланням на фіг. 17 та фіг. 18 нижче, якщо поточний блок - це блок, який піддався зовнішньому кодуванню, відеокодер може кодувати блок шляхом визначення MVD (або інформації злиття) на основі інформації руху з одного або декількох інших блоків. Потрібно розуміти, що етапи, показані та описані з посиланням на фіг. 14, являють собою лише один приклад. Тобто етапи способу з фіг. 14 не обов'язково повинні виконуватися в порядку, показаному на фіг. 14, і може виконуватися менша кількість етапів, можуть виконуватися додаткові або альтернативні етапи. Фіг. 15 являє собою блок-схему послідовності операцій, що ілюструє зразкові методики для скорочення кількості інформації прогнозування, яка буферизується при виконанні внутрішнього прогнозування при кодуванні відео. При тому, що йде опис у відношенні відеокодера 20, потрібно розуміти, що методики, описані з посиланням на фіг. 15, можуть реалізовуватися множиною інших процесорів, модулів обробки, модулів кодування на основі апаратного забезпечення, таких як кодер/декодери (CODEC), тощо. У прикладі, показаному на фіг. 15, відеокодер 20 може визначити режим внутрішнього прогнозування для першого блока відеоданих (270). Відеокодер 20 також може визначити режим внутрішнього прогнозування для другого блока відеоданих (272). Відповідно до аспектів цього розкриття відеокодер 20 може визначити режим внутрішнього прогнозування для другого блока на основі режиму внутрішнього прогнозування для першого блока, але тільки якщо перший блок не є верхнім сусіднім блоком другого блока (274). Якщо перший блок єверхнім сусіднім блоком, відеокодер 20 може визначати найбільш імовірний внутрішній режим для другого блока на основі одного або декількох інших блоків. Тобто верхній сусідній блок може бути виключений з числа таких, що розглядаються як перший блок. У деяких прикладах відеокодер 20 може застосовувати обмеження на верхній сусідній блок, тільки якщо перший блок з іншого LCU, ніж другий блок. Відеокодер 20 може визначати, чи є визначений найбільш імовірний внутрішній режим таким самим, як визначений внутрішній режим для другого блока (276). Якщо найбільш імовірний внутрішній режим є таким самим, як визначений внутрішній режим для другого блока (гілка ТАК (YES) етапу 276), відеокодер може забезпечити індикацію найбільш імовірного режиму в кодованому бітовому потоці (278). Відповідно до деяких прикладів відеокодер 20 може встановлювати прапор найбільш імовірного режиму в кодованому бітовому потоці, таким чином відображаючи, що найбільш імовірний режим використовувався для здійснення внутрішнього кодування другого блока. У цьому прикладі, як описується більш детально з посиланням на фіг. 16 нижче, після декодування прапора найбільш імовірного режиму відеодекодер (такий як відеодекодер 30) може відтворювати процес виведення найбільш імовірного режиму, щоб визначити внутрішній режим, що використовується для кодування другого блока. Якщо найбільш імовірний внутрішній режим не є таким самим, як внутрішній режим для другого блока (гілка НІ (NO) етапу 276), відеокодер 20 може забезпечити індикацію внутрішнього режиму, що використовується, щоб кодувати блок, в кодованому бітовому потоці (280). Потрібно розуміти, що етапи, показані та описані з посиланням на фіг. 15, являють собою лише один приклад. Тобто етапи способу з фіг. 15 не обов'язково повинні виконуватися в порядку, показаному на фіг. 15, і може виконуватися менша кількість етапів, можуть виконуватися додаткові або альтернативні етапи. Фіг. 16 являє собою блок-схему послідовності операцій, що ілюструє зразкові методики для скорочення кількості інформації прогнозування, яка буферизується при виконанні внутрішнього прогнозування при декодуванні відео. При тому, що йде опис у відношенні відеодекодера 30, потрібно розуміти, що методики, описані з посиланням на фіг. 16, можуть реалізовуватися множиною інших процесорів, модулів обробки, модулів кодування на основі апаратного забезпечення, таких як кодер/декодери (CODEC), тощо. Відеодекодер 30 може визначити режим внутрішнього прогнозування для першого блока відеоданих (290). Відеодекодер 30 також може приймати індикацію найбільш імовірного внутрішнього режиму другого блока (292). Наприклад, відеодекодер 30 може в деяких прикладах приймати прапор найбільш імовірного режиму, який відображає, чи був найбільш 28