Повідомлення додаткової інформації розширення точки відновлення і періоду буферизації

Реферат: Пристрій кодування відео, такий як відеодекодер, може бути сконфігурований, щоб декодувати повідомлення додаткової інформації розширення (SEI) періоду буферизації, асоційоване з одиницею доступу (AU). Відеодекодер також сконфігурований, щоб декодувати тривалість між часом видалення з буфера кодованих картинок (СРВ) першої одиниці декодування (DU) в AU і часом видалення з СРВ другої DU з повідомлення SEI періоду буферизації, в якому AU має TemporalId, що дорівнює 0. Відеодекодер конфігурується, щоб визначити час видалення першої DU на основі, щонайменше частково, декодованої тривалості і декодувати відеодані першої DU на основі, щонайменше частково, часу видалення. UA 114004 C2 (12) UA 114004 C2 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 60 [0001] Дана заявка вимагає пріоритет попередньої заявки на патент США № 61/705,119, поданої 24 вересня 2012 і попередньої заявки на патент США № 61/708,475, поданої 1 жовтня 2012, зміст кожної з яких включений по посиланню в їх повноті. ГАЛУЗЬ ТЕХНІКИ [0002] Дане розкриття стосується кодування відео. РІВЕНЬ ТЕХНІКИ [0003] Цифрові відеоздатності можуть бути включені в широкий діапазон пристроїв, включаючи цифрові телевізори, цифрові системи прямого мовлення, бездротові системи мовлення, персональні цифрові помічники (PDAs), ноутбуки або настільні комп'ютери, планшетні комп'ютери, зчитувачі електронних книг, цифрові камери, пристрої цифрового запису, цифрові медіаплеєри, пристрої відеоігор, пульти відеоігор, стільникові або супутникові радіотелефони, так звані "смартфони", пристрої організації відеотелеконференцій, пристрої потокової передачі відео і т. п. Цифрові відеопристрої реалізовують способи стиснення відео, такі, як описані в стандартах, визначених за допомогою MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, Частина 10, Вдосконалене відеокодування (AVC), стандарт високоефективного кодування відео (HEVC), і розширеннях таких стандартів. Відеопристрої можуть передавати, приймати, кодувати, декодувати, і/або зберігати цифрову відеоінформацію більш ефективно, реалізовуючи такі способи стиснення відео. [0004] Способи стиснення відео виконують просторове (всередині картинки) прогнозування і/або часове (між картинками) прогнозування, щоб зменшити або видалити надмірність, властиву відеопослідовностям. Для основаного на блоках кодування відеовирізка (тобто відеокадр або частина відеокадру) може бути розділена на блоки відео, які можуть також згадуватися як блоки дерева, одиниці кодування (CUs) і/або вузли кодування. Блоки відео у кодованій внутрішньо (I) вирізці картинки закодовані, використовуючи просторове прогнозування відносно опорних вибірок в сусідніх блоках в тій же самій картинці. Блоки відео у кодованій зовнішньо (Р або В) вирізці картинки можуть використовувати просторове прогнозування відносно опорних вибірок в сусідніх блоках в тій же самій картинці або часове прогнозування відносно опорних вибірок в інших опорних картинках. Картинки можуть згадуватися як кадри, і опорні картинки можуть згадуватися як опорні кадри. [0005] Просторове або часове прогнозування приводить до прогнозуючого блока для блока, який повинен бути закодований. Залишкові дані представляють піксельні різниці між первинним блоком, який повинен бути закодований, і прогнозуючим блоком. Кодований зовнішньо блок закодований згідно з вектором руху, який вказує на блок опорних вибірок, що формують прогнозуючий блок, і залишковими даними, що вказують різницю між закодованим блоком і прогнозуючим блоком. Кодований внутрішньо блок закодований згідно з режимом внутрішнього кодування і залишковими даними. Для подальшого стиснення залишкові дані можуть бути перетворені з піксельної області в область перетворення, приводячи до залишкових коефіцієнтів перетворення, які потім можуть бути квантовані. Квантовані коефіцієнти перетворення, спочатку розміщені в двовимірному масиві, можуть скануватися, щоб сформувати одновимірний вектор коефіцієнтів перетворення, і ентропійне кодування може бути застосоване, щоб досягнути навіть більшої міри стиснення. СУТЬ ВИНАХОДУ [0006] Загалом, способи, описані в даному розкритті, стосуються сигналізації і виведення часів видалення з буфера кодованих картинок при кодуванні відео. [0007] У одному прикладі способи, описані в даному розкритті, стосуються способу для декодування відеоданих. Спосіб може включати в себе декодування повідомлення додаткової інформації розширення (SEI) періоду буферизації, асоційованого з одиницею доступу (AU). Спосіб може також включати в себе декодування тривалості між часом видалення збуфера кодованих картинок (CPB) першої одиниці декодування (DU) в AU і часом видалення з CPB другої DU з повідомлення SEI періоду буферизації, в якому AU має TemporalId, що дорівнює 0. Спосіб може також включати в себе визначення часу видалення першої DU на основі, щонайменше частково, декодованої тривалості. Далі, спосіб може включати в себе декодування відеоданих першої DU на основі, щонайменше частково, часу видалення. [0008] У ще одному прикладі наданий пристрій кодування відео, який містить відеодекодер. Відеодекодер конфігурується, щоб декодувати повідомлення додаткової інформації розширення (SEI) періоду буферизації, асоційоване з одиницею доступу (AU), і декодувати тривалість між часом видалення з буфера кодованих картинок (CPB) першої одиниці декодування (DU) в AU і часом видалення з CPB другої DU з повідомлення SEI періоду буферизації, в якому AU має TemporalId, що дорівнює 0. Відеодекодер також сконфігурований, щоб визначити час видалення першої DU на основі, щонайменше частково, декодованої 1 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 тривалості, і декодувати відеодані першої DU на основі, щонайменше частково, часу видалення. [0009] Способи, описані в даному розкритті, також включають в себе приклад зчитуваного комп'ютером запам'ятовуючого носія, що має збережені на ньому інструкції, які, коли виконуються, змушують процесор пристрою для кодування відеоданих декодувати повідомлення додаткової інформації розширення (SEI) періоду буферизації, асоційоване з одиницею доступу (AU), і декодувати тривалість між часом видалення з буфера кодованих картинок (CPB) першої одиниці декодування (DU) в AU і часом видалення з CPB другої DU з повідомлення SEI періоду буферизації, в якому AU має TemporalId, що дорівнює 0. Інструкції можуть далі змусити процесор визначати час видалення першої DU на основі, щонайменше частково, декодованої тривалості, і декодувати відеодані першої DU на основі, щонайменше частково, часу видалення. [0010] У іншому прикладі способи, описані в даному розкритті, стосуються пристрою декодування відео. Пристрій декодування відео може включати в себе засіб для декодування повідомлення додаткової інформації розширення (SEI) періоду буферизації, асоційоване з одиницею доступу (AU), і засіб для декодування тривалості між часом видалення з буфера кодованих картинок (CPB) першої одиниці декодування (DU) в AU і часом видалення з CPB другої DU з повідомлення SEI періоду буферизації, в якому AU має TemporalId, що дорівнює 0. Пристрій декодування відео може також включати в себе засіб для того, щоб визначити час видалення першої DU на основі, щонайменше частково, декодованої тривалості, і засіб для декодування відеоданих першої DU на основі, щонайменше частково, часу видалення. [0011] У іншому прикладі способи, описані в даному розкритті, стосуються способу для кодування відеоданих. Спосіб може включати в себе визначення тривалості між часом видалення з буфера кодованих картинок (CPB) першої одиниці декодування (DU) в одиниці доступу (AU) і часом видалення з CPB другої DU в AU, при цьому AU має TemporalId, що дорівнює 0. Спосіб може також включати в себе кодування повідомлення додаткової інформації розширення (SEI) періоду буферизації, асоційованого з одиницею доступу (AU), в якому тривалість закодована в повідомленні SEI періоду буферизації. [0012] У ще одному прикладі наданий пристрій кодування відео, який містить відеокодер. Відеокодер конфігурується, щоб визначити тривалість між часом видалення з буфера кодованих картинок (CPB) першої одиниці декодування (DU) в одиниці доступу (AU) і часом видалення з CPB другої DU в AU, при цьому AU має TemporalId, що дорівнює 0. Відеокодер також сконфігурований, щоб закодувати повідомлення додаткової інформації розширення (SEI) періоду буферизації, асоційоване з одиницею доступу (AU), в якому тривалість закодована в повідомленні SEI періоду буферизації. [0013] Способи, описані в даному розкритті, також включають в себе приклад зчитуваного комп'ютером запам'ятовуючого носія, що має збережені на ньому інструкції, які, коли виконуються, змушують процесор пристрою для кодування відеоданих визначити тривалість між часом видалення з буфера кодованих картинок (CPB) першої одиниці декодування (DU) в одиниці доступу (AU) і часом видалення з CPB другої DU в AU, при цьому AU має TemporalId, що дорівнює 0. Інструкції також змушують процесор кодувати повідомлення додаткової інформації розширення (SEI) періоду буферизації, асоційоване з одиницею доступу (AU), в якому тривалість закодована в повідомленні SEI періоду буферизації. [0014] У іншому прикладі способи, описані в даному розкритті, стосуються пристрою кодування відео. Пристрій кодування відео може включати в себе засіб для визначення тривалості між часом видалення з буфера кодованих картинок (CPB) першої одиниці декодування (DU) в одиниці доступу (AU) і часом видалення з CPB другої DU в AU, при цьому AU має TemporalId, що дорівнює 0. Пристрій кодування відео може також включати в себе засіб для кодування повідомлення додаткової інформації розширення (SEI) періоду буферизації, асоційованого з одиницею доступу (AU), в якому тривалість закодована в повідомленні SEI періоду буферизації. [0015] Ці зразкові способи можуть бути реалізовані разом або окремо. Способи даного розкриття також описані в термінах пристроїв, конфігурованих, щоб реалізувати способи, так само, як зчитуваних комп'ютером запам'ятовуючих носіїв, що зберігають інструкції, які примушують один або більше процесорів виконувати ці способи. [0016] Подробиці одного або більше прикладів сформульовані в супровідних кресленнях і описі нижче. Інші ознаки, задачі і переваги будуть очевидні з опису і креслень і з формули винаходу. 60 2 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 60 КОРОТКИЙ ОПИС КРЕСЛЕНЬ [0017] Фіг. 1 є блок-схемою, що ілюструє зразкову систему кодування і декодування відео, яка може використовувати способи, описані в даному розкритті. [0018] Фіг. 2 є блок-схемою, що ілюструє зразковий кодер відео, який може реалізувати способи, описані в даному розкритті. [0019] Фіг. 3 є блок-схемою, що ілюструє зразковий декодер відео, який може реалізувати способи, описані в даному розкритті. [0020] Фіг. 4 є концептуальною діаграмою, що ілюструє дві одиниці доступу (AU) в послідовному порядку декодування, які можуть мати часи декодування, визначені згідно зі способами, описаними в даному розкритті. [0021] Фіг. 5 є послідовністю операцій, що ілюструє спосіб для визначення часу видалення з буфера кодованих картинок (CPB) першої одиниці декодування (DU) в AU на основі часу видалення з CPB для другої DU AU згідно зі способами, описаними в даному розкритті. [0022] Фіг. 6 є послідовністю операцій, що ілюструє інший спосіб для визначення часу видалення з буфера кодованих картинок (CPB) першої одиниці декодування в одиниці доступу на основі часу видалення з CPB для другої одиниці декодування одиниці доступу згідно зі способами, описаними в даному розкритті. [0023] Фіг. 7 є послідовністю операцій, що ілюструє спосіб для виведення часу видалення з CPB першої DU на основі, щонайменше частково, повідомлення SEI тактування субкартинок згідно зі способами, описаними в даному розкритті. [0024] Фіг. 8 є послідовністю операцій, що ілюструє інший спосіб для виведення часу видалення з CPB першої DU на основі, щонайменше частково, кодування повідомлення SEI тактування субкартинок згідно зі способами, описаними в даному розкритті. [0025] Фіг. 9 є послідовністю операцій, що ілюструє спосіб для декодування прапора рівня послідовності для параметра буфера кодованих картинок рівня субкартинки згідно зі способами, описаними в даному розкритті. [0026] Фіг. 10 є послідовністю операцій, що ілюструє спосіб для кодування прапора рівня послідовності для параметра буфера кодованих картинок рівня субкартинки згідно зі способами, описаними в даному розкритті. [0027] Фіг. 11 є послідовністю операцій, що ілюструє спосіб для декодування DU, що має розширене визначення, згідно зі способами, описаними в даному розкритті. [0028] Фіг. 12 є послідовністю операцій, що ілюструє спосіб для кодування DU, що має розширене визначення, згідно зі способами, описаними в даному розкритті. [0029] Фіг. 13 є послідовністю операцій, що ілюструє спосіб для декодування періоду буферизації згідно зі способами, описаними в даному розкритті. [0030] Фіг. 14 є послідовністю операцій, що ілюструє спосіб для кодування періоду буферизації згідно зі способами, описаними в даному розкритті. [0031] Фіг. 15 є послідовністю операцій, що ілюструє спосіб для декодування часу надходження і номінального часу видалення буфера кодованих картинок згідно зі способами, описаними в даному розкритті. [0032] Фіг. 16 є послідовністю операцій, що ілюструє спосіб для кодування часів надходження і номінальних часів видалення буфера кодованих картинок і згідно зі способами, описаними в даному розкритті. ДОКЛАДНИЙ ОПИС [0033] Дане розкриття описує способи для стійкої до помилок і ефективної сигналізації і виведення часів видалення з буфера кодованих картинок (CPB) закодованих одиниць даних при кодуванні відео. Часи видалення (витягання) з CPB також відомі як часи декодування. Розкриття забезпечує способи для визначення часу видалення з CPB для одиниці декодування (DU) одиниці доступу (AU), який є незалежним від часів видалення будь-якої іншої AU. Наприклад, часи видалення з CPB для поточної DU в AU будуть сигналізовані на основі або тривалості між часом видалення з CPB наступної DU в порядку декодування в AU і поточної DU, або тривалості між часом видалення з CPB останньої DU в AU і поточної DU. У іншому прикладі виведення часу видалення з CPB визначене таким способом, який використовує інформацію, яку переносять в повідомленні додаткової інформації розширення (SEI) тактування субкартинок. Тривалість між часом видалення з CPB останньої DU в AU в порядку декодування і DU, асоційованої з повідомленням (SEI) тактування субкартинок, сигналізується. [0034] Далі, надані способи для включення прапора рівня послідовності, який може бути сигналізований, щоб вказувати, чи контролюють параметри CPB субкартинки тільки в одному з повідомлень SEI тактування картинок або повідомлень SEI тактування субкартинок, але ніколи в обох, згідно зі способами, описаними в даному документі. Прапор, що дорівнює 1, вказує, що 3 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 параметри затримки видалення з CPB на рівні субкартинок присутні в повідомленнях SEI тактування картинок і не присутні в повідомленнях SEI тактування субкартинок. Прапор, що дорівнює 0, вказує, що параметри затримки видалення з CPB на рівні субкартинок присутні в повідомленнях SEI тактування субкартинок і повідомлення SEI тактування картинок не включають в себе параметри затримки видалення з CPB на рівні субкартинок. [0035] Дане розкриття також забезпечує способи для розширення визначення одиниці декодування. Дане розкриття далі забезпечує способи для обмеження повідомлень SEI періоду буферизації і повідомлень SEI точки відновлення таким чином, що вони не можуть бути асоційовані з одиницями AU із змінною, TemporalId, більшою ніж 0. Змінна TemporalId виводиться з елемента синтаксису, асоційованого з кожною AU. Дане розкриття також забезпечує способи для забезпечення прапора, щоб сигналізувати, чи виводити часи видалення з CPB на рівні AU або рівні субкартинок. [0036] Способи, описані в даному документі, можуть належати до різних стандартів кодування відео. Стандарти кодування відео включають в себе ITU-T H.261, ISO/IEC MPEG-1 Visual, ITU-T H.262 або ISO/IEC MPEG-2 Visual, ITU-T H.263, ISO/IEC MPEG-4 Visual і ITU-T H.264 (також відомий як ISO/IEC MPEG-4 AVC), включаючи його розширення масштабоване кодування відео (SVC) і кодування відео з множинними видами (MVC). [0037] Крім того, є новий стандарт кодування відео, а саме високоефективне кодування відео (HEVC), що розвивається об'єднаною командою співпраці по кодуванню відео (JCT-VC) групи експертів по кодуванню відео ITU-T (VCEG) і ISO/IEC групи експертів по рухомих зображеннях (MPEG). Нещодавній робочий проект (WD) HEVC Working Draft 8, і згаданий надалі як HEVC WD8. Bross et. al., High Efficiency Video Coding (HEVC) Text Specification Draft 8, July 2012, Stockholm, available as of May 2, 2013 from http://phenix.intevry.fr/jct/doc_end_user/documents/10_Stockholm/wg11/JCTVC-J1003-v8.zip. [0038] HEVC WD8 включений по посиланню повністю в даний опис. Крім того, хоч способи, описані в даному розкритті, описані відносно стандарту HEVC, аспекти даного розкриття цим не обмежені і можуть бути розширені на інші стандарти кодування відео так само, як способи кодування відео, що складають власність. [0039] Відеокодер може генерувати потік бітів, який включає в себе закодовані відеодані. Потік бітів може містити послідовність одиниць рівня абстракції мережі (NAL). Одиниці NAL потоку бітів можуть включати в себе одиниці NAL рівня кодування відео (VCL) і одиниці NAL неVCL. Одиниці NAL VCL можуть включати в себе закодовані вирізки картинок. Одиниця NAL неVCL може включати в себе набір параметрів відео (VPS), набір параметрів послідовності (SPS), набір параметрів картинки (PPS), додаткову інформацію розширення (SEI) або інші типи даних. VPS є синтаксичною структурою, яка може містити елементи синтаксису, які застосовуються до нуля або більше повністю закодованих відеопослідовностей. SPS є синтаксичною структурою, яка може містити елементи синтаксису, які застосовуються до нуля або більше повністю закодованих відеопослідовностей. Єдиний VPS може бути застосовним до множинних SPS. PPS є синтаксичною структурою, яка може містити елементи синтаксису, які застосовуються до нуля або більше повністю закодованих картинок. Єдиний SPS може бути застосовним до множинних PPS. Різні аспекти VPS, SPS і PPS можуть бути сформовані, взагалі, як визначено по стандарту HEVC. [0040] Одиниці NAL можуть включати в себе елемент синтаксису, який указує значення змінної TemporalId. Це значення TemporalId одиниці NAL задає часовий ідентифікатор одиниці NAL. Якщо часовий ідентифікатор першої одиниці NAL менше, ніж часовий ідентифікатор другої одиниці NAL, дані, інкапсульовані першою одиницею NAL, можуть бути декодованінезалежно від даних, інкапсульованих другою одиницею NAL. [0041] Кожний стандарт кодування відео звичайно включає в себе специфікацію моделі буферизації відео. У AVC і HEVC модель буферизації згадується як гіпотетичний опорний декодер (HRD), який описує, як дані повинні бути буферизовані для декодування і як декодовані дані буферизуються для виведення. HRD включає в себе модель буферизації як буфера кодованих картинок (CPB), так і буфера декодованих картинок (DPB). CPB є буфером "перший увійшов - перший вийшов", що містить одиниці доступу в порядку декодування, заданому за допомогою HRD. DPB є буфером, що зберігає декодовані картинки для посилання на них, переупорядковування виведення або затримки виведення, заданих за допомогою HRD. Параметри гіпотетичного опорного декодера математично задають поведінки CPB і DPB. HRD може безпосередньо накласти обмеження на різні параметри, включаючи тактування, розміри буфера і частоти проходження бітів, і може непрямо накласти обмеження на характеристики потоку бітів і статистику. У деяких прикладах повний набір параметрів HRD може включати в 4 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 60 себе п'ять основних параметрів: початкову затримку видалення з CPB, розмір CPB, частоту проходження бітів, початкову затримку виведення DPB і розмір DPB. [0042] У AVC і HEVC відповідність потоку бітів і відповідність декодера задані як частина специфікації HRD. Хоч назва гіпотетичного опорного декодера стосується роду декодера, HRD типово необхідний на стороні кодера для забезпечення відповідності потоку бітів, в той час як не є обов'язково необхідним на стороні декодера. Однак, аспекти даного розкриття цим не обмежені, і HRD може бути також частиною сторони декодера. AVC і HEVC можуть задавати два типи потоку бітів або відповідності HRD, а саме Тип I і Тип II. Крім того, AVC і HEVC задають два типи відповідності декодера: відповідність декодера тактуванню виведення і відповідність декодера порядку виведення. [0043] У моделях HRD в AVC і HEVC декодування або видалення з CPB основане на одиницях доступу, і стандарти передбачають, що декодування картинок є миттєвим. У практичних застосуваннях, якщо відповідний декодер суворо додержується сигналізованих часів декодування (наприклад, в повідомленнях додаткової інформації розширення (SEI)), щоб почати декодування одиниці доступу, то найбільш ранній час, щоб вивести конкретну декодовану картинку, дорівнює часу декодування цієї конкретної картинки плюс час, необхідний для того, щоб декодувати цю конкретну картинку. Таким чином, найбільш ранній час, щоб вивести декодовану картинку, є часом декодування плюс час, щоб декодувати картинку. Однак, час, необхідний для того, щоб декодувати картинку, в практичних застосуваннях не може дорівнювати нулю. [0044] У HEVC WD8 гіпотетичний опорний декодер (HRD) заданий в Додатку С. HRD використовує параметри HRD, які можуть бути надані в потоці бітів в синтаксичній структурі hrd_parameters() (в наборі параметрів відео (VPS) і/або наборі параметрів послідовності (SPS)), повідомленнях SEI періоду буферизації і повідомленнях SEI тактування картинок. Попередня заявка на патент США № 61/705,102, подана 24 вересня 2012 року, пропонує розширену сигналізацію і вибір параметрів HRD. [0045] Можуть мати місце проблеми, асоційовані з існуючими способами для сигналізації і виведення часів видалення з CPB, також відомих як часи декодування. Нижченаведене описує деякі з цих проблем. [0046] Часи видалення з CPB одиниці декодування можуть не бути стійкими до помилок, коли часи видалення з CPB для одиниць декодування в межах одиниці доступу залежать від інформації тактування від попередньої одиниці доступу. Одиниця доступу може містити одну або більше одиниць декодування. Час видалення може бути визначений для кожної DU в AU. Час видалення з CPB може бути сигналізований для AU і для однієї або більше одиниць DU в межах AU. Повідомлення SEI для AU може включати в себе час видалення з CPB для AU безпосередньо, який також відповідає часу видалення з CPB для останньої DU в межах AU. [0047] Буфер кодованих картинок може працювати на двох рівнях: рівні одиниці доступу і рівні субкартинок. Коли CPB працює на рівні субкартинок (тобто, коли SubPicCpbFlag дорівнює 1), сигналізація і виведення часів видалення з CPB одиниці декодування (DU), які основані на повідомленнях SEI тактування картинок, можуть не бути стійкими до помилок в обставинах, коли інформація втрачена від попередньої AU в порядку декодування. Наприклад, інформація тактування, яка сигналізується для поточної AU, включає в себе тривалість між часом видалення з CPB для першої DU в поточній AU і останньої DU в попередній AU. Таким чином, якщо інформація тактування для останньої DU в попередній AU втрачена, то декодер не може визначити час видалення для першої DU в поточній AU, тому що час видалення для першої DU залежить від втраченої інформації тактування. [0048] Іншими словами, сигналізація тривалості між часами видалення з CPB першої одиниці декодування в поточній AU і останньої DU в попередній AU в порядку декодування, так само як використання такої сигналізації у виведенні часу видалення з CPB, робить систему або кодер вразливими до втраченої інформації тактування. Наприклад, якщо інформація видалення з CPB (тобто повідомлення SEI тактування картинок) попередньої AU втрачена, то час видалення з CPB першої DU в поточній AU не може бути правильно виведений. Крім того, за винятком останньої DU поточної AU, для якої час видалення з CPB виведений як рівний такому з поточної AU, кожний з часів видалення з CPB всіх інших одиниць DU в поточній AU використовує час видалення з CPB попередньої DU в порядку декодування. Таким чином, якщо вищезазначена втрата трапляється, час видалення з CPB кожної DU в поточній AU, за винятком останньої DU, не може бути правильно виведений. [0049] Навпаки, тут описані способи, які можуть зменшити вразливість системи або кодера до втраченої інформації тактування. Наприклад, способи надані для того, щоб визначити час видалення з буфера кодованих картинок для DU в AU, який є незалежним від часів видалення 5 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 60 будь-якої іншої одиниці доступу. Наприклад, відеокодер буде сигналізувати, в повідомленні SEI тактування картинок, часи видалення з CPB для DU в AU, яка повинна бути прийнята відеодекодером, на основі або тривалості часу між поточною DU і або часом видалення з CPB наступної DU в порядку декодування в AU, або часом видалення з CPB останньої DU в AU. Таким чином, дане розкриття описує способи для забезпечення більшої стійкості до помилок і ефективної сигналізації і виведення часів видалення з CPB закодованих блоків даних при кодуванні відео, тому що інформація тактування для кожної DU в AU не залежить від інформації тактування від іншої, відмінної AU. [0050] Інша проблема, асоційована з існуючими способами для сигналізації і виведення часів видалення з CPB, є тією, що інформація тактування в повідомленнях SEI тактування субкартинок не може бути використана навіть при її наявності. Наприклад, повідомлення SEI тактування субкартинок, що несуть інформацію затримки видалення з CPB DU, можуть бути присутні. Однак, робота CPB на рівні субкартинок задана способом, яким відеодекодер завжди використовує повідомлення SEI тактування картинок і ніколи не використовує повідомлення SEI тактування субкартинок. Таким чином, біти, використані для представлення повідомлень SEI тактування субкартинок, можуть бути витрачені даремно. Крім того, затримка видалення з CPB DU, сигналізована в повідомленні SEI тактування субкартинок, є різницею між часом видалення з CPB асоційованої DU і часом видалення з CPB першої DU попередньої AU, асоційованої з повідомленням SEI періоду буферизації. У той час як це може бути частково стійким до помилок, це може бути також неефективним, оскільки різниця у часі може бути суттєвим значенням. [0051] Однак, способи надані в даному розкритті для того, щоб задати виведення часу видалення з CPB способом, який може використовувати інформацію, що переноситься в повідомленні додаткової інформації розширення (SEI) тактування субкартинок. Наприклад, виведення часу видалення з CPB задане способом, який може використовувати інформацію, що переноситься в повідомленнях SEI тактування субкартинок, і відеокодер може сигналізувати тривалість між видаленням з CPB останньої DU в AU в порядку декодування і DU, асоційованої з повідомленням (SEI) тактування субкартинок, роблячи сигналізацію кодера і виведення декодера як більш ефективними, так і стійкими до помилок. [0052] Інша проблема, асоційована з існуючими способами для сигналізації і виведення часів видалення з CPB, є тією, що параметри CPB рівня субкартинок в повідомленнях SEI тактування картинок і повідомленнях SEI тактування субкартинок можуть бути обидва присутні для одних і тих же функціональних можливостей. Ці функціональні можливості можуть бути надані, щоб підтримувати основану на субкартинках операцію CPB. Дублювання цих параметрів для одних і тих же функціональних можливостей може бути неефективним. Може бути можливо, що тільки один набір параметрів CPB рівня субкартинок, в будь-якому типі повідомлень SEI, є достатнім. В даному документі описані способи, які конфігурують відеокодер, щоб забезпечити прапор рівня послідовності, який може бути сигналізований, щоб вказувати присутність параметрів CPB рівня субкартинок в тільки одному з повідомлень SEI тактування картинок або повідомлень SEI тактування субкартинок, але не обох. Використовуючи цей прапор рівня послідовності, відеодекодер визначає, чи знайти параметри CPB рівня субкартинок, такі як параметри затримки видалення з CPB на рівні субкартинок, в повідомленні SEI тактування картинок або в повідомленні SEI тактування субкартинок. [0053] Ще одна проблема, асоційована з існуючими способами для сигналізації і виведення часів видалення з CPB, є тією, що визначення одиниць декодування не розглядало одиниці NAL не-VCL з nal_unit_type, що дорівнює UNSPEC0, EOS_NUT, EOB_NUT, в діапазоні RSV_NVCL44RSV_NVCL47 або в діапазоні UNSPEC48-UNSPEC63. Таким чином, коли деякі з цих одиниць NAL не-VCL присутні, несподівана поведінка CPB рівня субкартинок може мати місце. Навпаки, дане розкриття забезпечує способи для розширення визначення одиниці декодування, щоб включати в себе одиниці NAL не-VCL з nal_unit_type, що дорівнює UNSPEC0, EOS_NUT, EOB_NUT, в діапазоні RSV_NVCL44-RSV_NVCL47 або в діапазоні UNSPEC48-UNSPEC63. [0054] Інша потенційна проблема, асоційована з існуючими способами для сигналізації і виведення часів видалення з CPB, є тією, що повідомлення SEI періоду буферизації і повідомлення SEI точки відновлення можуть бути асоційовані з одиницями AU з будь-яким значенням часового значення ідентифікаційної інформації (TemporalId). Таким чином, кодер може ініціалізувати HRD в AU з TemporalId, більшим ніж 0. В цьому випадку, коли часова масштабованість підтримується, час видалення з CPB AU з меншим значенням TemporalId в одному і тому ж періоді буферизації може залежати від інформації в AU з більшим значенням TemporalId. Однак, для того, щоб часова масштабованість працювала, процес декодування будь-якої AU може не залежати від іншої AU з більшим TemporalId. Дане розкриття також 6 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 60 забезпечує способи для обмеження повідомлень SEI періоду буферизації і повідомлень SEI точки відновлення таким чином, що вони не можуть бути асоційовані з одиницями AU з TemporalId, більшим ніж 0. [0055] Часове значення ідентифікаційної інформації (TemporalId) може бути ієрархічним значенням, яке вказує, які картинки можуть використовуватися для кодування поточної картинки. Взагалі, картинка з конкретним значенням TemporalId можливо може бути опорною картинкою для картинок з рівними або більшими значеннями TemporalId, але не навпаки. Наприклад, картинка зі значенням TemporalId, що дорівнює 1, можливо може бути опорною картинкою для картинок зі значеннями TemporalId, що дорівнюють 1, 2, 3, …, але не для картинки зі значенням TemporalId, що дорівнює 0. [0056] Найнижче значення TemporalId може також вказувати найнижчу частоту відображення. Наприклад, якщо відеодекодер декодує тільки картинки зі значеннями TemporalId 0, частота відображення може бути 7.5 картинок на секунду. Якщо відеодекодер декодує тільки картинки зі значеннями TemporalId 0 і 1, частота відображення може бути 15 картинок на секунду, і т. д. [0057] Додаткова потенційна проблема, асоційована з існуючими способами для сигналізації і виведення часів видалення з CPB, полягає в процесі виведення часу видалення з CPB, коли sub_pic_cpb_params_present_flag дорівнює 1, виведення часу видалення з CPB використовує кінцевий час надходження і номінальні часи видалення для обох випадків з SubPicCpbFlag, що дорівнює 0 (коли CPB працює на рівні AU), і з SubPicCpbFlag, що дорівнює 1 (коли CPB працює на рівні субкартинок). Однак, ці використовувані значення для кінцевого часу надходження і номінальних часів видалення можуть бути виведені тільки для одного з цих двох випадків (наприклад, або для SubPicCPBFlag, що дорівнює 0, або для SubPicCPBFlag, що дорівнює 1) і, отже, не доступні для іншого випадку. Описані тут способи передбачають прапор, щоб сигналізувати, чи повинен декодер вивести часи видалення з CPB на рівні AU або рівні субкартинок. Наприклад, декодер виводить часи надходження в CPB і номінальні часи видалення і для рівня AU, і для рівня субкартинок незалежно від значення SubPicCpbFlag, в той час як декодер виводить часи видалення з CPB тільки для рівня AU, коли SubPicCpbFlag дорівнює 0, і тільки для рівня субкартинок, коли SubPicCpbFlag дорівнює 1, згідно зі способами, описаними в даному документі. Як описано в даному документі, номінальний час видалення з CPB може бути значенням за умовчанням для часу видалення з CPB. У деяких прикладах з типовими умовами час видалення з CPB дорівнює номінальному часу видалення з CPB. Однак, при деяких умовах вони різні, і час видалення з CPB може трохи відрізнятися від значення за умовчанням. [0058] Наступні способи, описані в даному розкритті, можуть стосуватися проблем, описаних вище. Наприклад, способи, описані в даному розкритті, можуть забезпечити більш стійке до помилок визначення часу видалення з буфера кодованих картинок. Крім того, на доповнення до поліпшеної стійкості до помилок, способи можуть сприяти ефективності сигналізації, яка зменшує смугу пропускання, службові витрати сигналізації і збільшує ефективність кодування. Крім того, способи, описані в даному розкритті, можуть врахувати належну часову масштабованість. [0059] Такі способи можуть включати в себе, наприклад, визначення часу видалення з буфера кодованих картинок для одиниці декодування (DU) одиниці доступу (AU), який є незалежним від часів видалення будь-якої іншої одиниці доступу. Наприклад, часи видалення з CPB для DU в AU будуть сигналізовані на основі тривалості між поточною DU і або часом видалення з CPB наступної DU в порядку декодування в AU, або часом видалення з CPB останньої DU в AU. Способи можуть також включати в себе сигналізацію прапора рівня послідовності, щоб керувати присутністю параметрів CPB рівня субкартинок в тільки одному з повідомлень SEI тактування картинок або повідомлень SEI тактування субкартинок згідно зі способами, описаними в даному документі. Способи можуть також включати в себе розширення визначення одиниці декодування. Додаткові способи забезпечують обмеження повідомлень SEI періоду буферизації і повідомлень SEI точки відновлення таким чином, що вони не можуть бути асоційовані з одиницями AU із змінною TemporalId, більшою ніж 0. Способи можуть також включати в себе забезпечення прапора, щоб сигналізувати, чи вивести часи видалення з CPB на рівні AU або рівні субкартинок. [0060] Подробиці для реалізації цих способів описані більш детально нижче. Інші частини, не згадані, можуть бути тими ж самими, як в HEVC WD8. [0061] Фіг. 1 є блок-схемою, що ілюструє зразкову систему 10 кодування і декодування відео, яка може використовувати способи, описані в даному розкритті. Як показано на фіг. 1, система 10 включає в себе вихідний пристрій 12, який генерує закодовані відеодані, які повинні бути 7 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 60 декодовані в більш пізній час пристроєм 14 призначення. Вихідний пристрій 12 і пристрій 14 призначення можуть містити будь-який з широкого діапазону пристроїв, включаючи настільні комп'ютери, портативні (наприклад, ноутбук) комп'ютери, планшетні комп'ютери, телевізійні приставки, телефонні трубки, такі як так звані смартфони, так звані "смарт-"клавіатури, телевізори, камери, пристрої відображення, цифрові медіаплеєри, пульти відеоігор, пристрій потокової передачі відео або подібне. У деяких випадках вихідний пристрій 12 і пристрій 14 призначення можуть бути обладнані для бездротового зв'язку. [0062] У прикладі згідно з фіг. 1 вихідний пристрій 12 включає в себе відеоджерело 18, відеокодер 20 і інтерфейс 22 виведення. У деяких випадках інтерфейс 22 виведення може включати в себе модулятор/демодулятор (модем) і/або передавач. У вихідному пристрої 12 відеоджерело 18 може включати в себе джерело, таке як пристрій захоплення відео, наприклад відеокамеру, відеоархів, що містить раніше захоплене відео, інтерфейс подачі відео, щоб прийняти відео від постачальника відеоконтенту, і/або систему комп'ютерної графіки для того, щоб генерувати дані комп'ютерної графіки як вихідне відео, або комбінацію таких джерел. Як один приклад, якщо відеоджерело 18 є відеокамерою, вихідний пристрій 12 і пристрій 14 призначення можуть сформувати так звані камерофони або відеотелефони. Однак, способи, описані в даному розкритті, можуть бути застосовні до кодування відео взагалі і можуть бути застосовані до бездротових і/або дротових додатків. [0063] Захоплене, попередньо захоплене або машинно-генероване відео може бути закодоване відеокодером 20. Закодовані відеодані можуть бути передані безпосередньо до пристрою 14 призначення через інтерфейс 22 виведення з вихідного пристрою 12. Закодовані відеодані можуть також (або альтернативно) зберігатися на пристрої 32 зберігання для більш пізнього доступу пристроєм 14 призначення або іншими пристроями для декодування і/або відтворення. [0064] Пристрій 14 призначення включає в себе інтерфейс 28 введення, відеодекодер 30 і пристрій 32 відображення. У деяких випадках інтерфейс 28 введення може включати в себе приймач і/або модем. Інтерфейс 28 введення з пристрою 14 призначення приймає закодовані відеодані по лінії 16 зв'язку. Закодовані відеодані, передані по лінії 16 зв'язку, або надані на пристрої 32 зберігання, можуть включати в себе множину елементів синтаксису, генерованих відеокодером 20, для використання відеодекодером, таким як відеодекодер 30, при декодуванні відеоданих. Такі елементи синтаксису можуть бути включені в закодовані відеодані, передані на комунікаційному носії, збережені на запам'ятовуючому носії або збережені файловим сервером. [0065] Пристрій 32 відображення може бути інтегрованим з або бути зовнішнім до пристрою 14 призначення. У деяких прикладах пристрій 14 призначення може включати в себе інтегрований пристрій відображення і також конфігуруватися, щоб сполучатися із зовнішнім пристроєм відображення. У інших прикладах пристрій 14 призначення може бути пристроєм відображення. Взагалі, пристрій 32 відображення відображає декодовані відеодані користувачу і може містити будь-який з множини пристроїв відображення, таких як рідкокристалічний дисплей (LCD), плазмовий дисплей, дисплей з матрицею точок, дисплей на органічних світловипромінюючих (OLED) діодах, електронне чорнило або інший тип пристрою відображення. [0066] Пристрій 14 призначення може прийняти закодовані відеодані, які повинні бути декодовані, через лінію 16 зв'язку. Лінія 16 зв'язку може містити будь-який тип носія або пристрою, здатного до переміщення закодованих відеоданих від вихідного пристрою 12 до пристрою 14 призначення. У одному прикладі лінія 16 зв'язку може містити комунікаційний носій, щоб дозволити вихідному пристрою 12 передавати закодовані відеодані безпосередньо до пристрою 14 призначення в реальному часі. Закодовані відеодані можуть модулюватися згідно зі стандартом зв'язку, таким як протокол бездротового зв'язку, і передаватися до пристрою 14 призначення. Комунікаційний носій може містити будь-який бездротового або дротовий комунікаційний носій, такий як радіочастотний (RF) спектр або одна або більше фізичних ліній передачі. Комунікаційний носій може бути частиною основаної на пакетній передачі мережі, такої як локальна мережа, регіональна мережа або глобальна мережа, така як Інтернет. Комунікаційний носій може включати в себе маршрутизатори, перемикачі, базові станції або будь-яке інше обладнання, яке може бути корисним, щоб полегшити зв'язок від вихідного пристрою 12 до пристрою 14 призначення. [0067] Альтернативно, закодовані дані можуть бути виведені з інтерфейсу 22 виведення на пристрій 32 зберігання. Аналогічно, до закодованих даних можна одержати доступ від пристрою 32 зберігання через інтерфейс введення. Пристрій 32 зберігання може включати в себе будьякий з множини розподілених або запам'ятовуючих носіїв даних, до яких локально одержують доступ, такий як накопичувач на жорстких дисках, диски Blu-ray, DVD, CD-ROM, флеш-пам'ять, 8 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 60 енергозалежна або енергонезалежна пам'ять, або будь-які інші придатні цифрові запам'ятовуючі носії для того, щоб зберігати закодовані відеодані. У подальшому прикладі пристрій 32 зберігання може відповідати файловому серверу або іншому проміжному пристрою зберігання, який може зберігати закодоване відео, генероване вихідним пристроєм 12. Пристрій 14 призначення може одержати доступ до збережених відеоданих від пристрою 32 зберігання за допомогою потокової передачі або завантаження. Файловий сервер може бути будь-яким типом сервера, здатного до того, щоб зберігати закодовані відеодані і передавати ці закодовані відеодані до пристрою 14 призначення. Зразкові файлові сервери включають в себе web-сервер (наприклад, для веб-сайта), сервер FTP, пристрої сполучених з мережею пристроїв зберігання (NAS) або локальний дисковод. Пристрій 14 призначення може одержати доступ до закодованих відеоданих через будь-яке стандартне з'єднання даних, включаючи Інтернетз'єднання. Це може включати в себе бездротовий канал (наприклад, з'єднання Wi-Fi), дротове з'єднання (наприклад, DSL, кабельний модем і т. д.) або комбінацію обох, яка є придатною для того, щоб одержати доступ до закодованих відеоданих, що зберігаються на файловому сервері. Передача закодованих відеоданих від пристрою 32 зберігання може бути потоковою передачею, передачею завантаження або комбінацією обох. [0068] Способи даного розкриття не обов'язково обмежені бездротовими додатками або параметрами настройки. Способи можуть бути застосовані до кодування відео на підтримання будь-якого з множини мультимедійних додатків, таких як ефірне телебачення, передачі кабельного телебачення, передачі супутникового телебачення, потокові передачі відео, наприклад через Інтернет, кодування цифрового відео для збереження на запам'ятовуючому носії даних, декодування цифрового відео, збереженого на запам'ятовуючому носії даних, або інших додатків. У деяких прикладах система 10 може бути сконфігурована, щоб підтримувати односторонню або двосторонню відеопередачу, щоб підтримувати додатки, такі як потокова передача відео, відтворення відео, мовлення відео і/або відеотелефонія. [0069] Відеокодер 20 і відеодекодер 30 можуть працювати згідно зі стандартом стиснення відео, таким як стандарт високоефективного кодування відео (HEVC), що на даний час розвивається об'єднаною командою співпраці по кодуванню відео (JCT-VC) групи експертів по кодуванню відео ITU-T (VCEG) і ISO/IEC групи експертів по рухомих зображеннях (MPEG). Відеокодер 20 і відеодекодер 30 можуть працювати згідно з HEVC WD8. Альтернативно, відеокодер 20 і відеодекодер 30 можуть працювати згідно з іншими стандартами, що складають власність, або стандартами промисловості, такими як ITU-T H.261, ISO/IEC MPEG-1 Visual, ITUT H.262 або ISO/IEC MPEG-2 Visual, ITU-T H.263, ISO/IEC MPEG-4 Visual і ITU-T H.264 (також відомий як ISO/IEC MPEG-4 AVC), включаючи його розширення масштабованого кодування відео (SVC) і кодування відео з множинними видами (MVC), або розширення таких стандартів. Способи даного розкриття, однак, не обмежені ніяким конкретним стандартом кодування. [0070] У деяких прикладах відеокодер 20 і відеодекодер 30 можуть, кожний, бути інтегровані з аудіокодером і -декодером і можуть включати в себе відповідні блоки MUX-DEMUX (мультиплексор-демультиплексор) або інше апаратне забезпечення і програмне забезпечення, щоб обробляти кодування і аудіо, і відео в загальному потоці даних або окремих потоках даних. Якщо застосовно, в деяких прикладах блоки MUX-DEMUX можуть відповідати протоколу мультиплексора ITU H.223 або іншим протоколам, таким як протокол дейтаграм користувача (UDP). [0071] Відеокодер 20 і відеодекодер 30, кожний, можуть бути реалізовані як будь-яке з множини придатних схем кодера, таких як один або більше мікропроцесорів, цифрові сигнальні процесори (DSPs), спеціалізовані інтегральні схеми (ASICs), програмовані користувачем вентильні матриці (FPGAs), дискретна логіка, програмне забезпечення, апаратне забезпечення, програмно-апаратні засоби або будь-які їх комбінації. Коли способи реалізовані частково в програмному забезпеченні, пристрій може зберегти інструкції для програмного забезпечення у придатному постійному зчитуваному комп'ютером носії і виконувати інструкції в апаратному забезпеченні, використовуючи один або більше процесорів, щоб виконати способи даного розкриття. Кожний з відеокодера 20 і відеодекодера 30 може бути включений в один або більше кодерів або декодерів, будь-який з яких може бути інтегрований як частина об'єднаного кодера/декодера (кодек) у відповідному пристрої. [0072] JCT-VC працює над розвитком стандарту HEVC. Зусилля по стандартизації HEVC основані на моделі, що розвивається, пристрою кодування відео, званої тестовою моделлю HEVC (HM). HM передбачає декілька додаткових можливостей пристроїв кодування відео відносно існуючих пристроїв згідно, наприклад, з ITU-T H.264/AVC. Наприклад, тоді як H.264 забезпечує дев'ять режимів кодування з внутрішнім прогнозуванням, HM може забезпечити цілих тридцять три режими кодування з внутрішнім прогнозуванням. 9 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 60 [0073] Взагалі, робоча модель HM описує, що відеокадр або картинка можуть бути розділені на послідовність блоків дерева або найбільших одиниць кодування (LCU), які включають в себе вибірки як яскравості, так і насиченості кольору. Блок дерева має аналогічну мету, що і макроблок в стандарті H.264. Вирізка включає в себе ряд послідовних блоків дерева в порядку кодування. Відеокадр або картинка можуть бути розділені на одну або більше вирізок. Кожний блок дерева може бути розділений на одиниці кодування (CUs) згідно з квадродеревом. Наприклад, блок дерева, як кореневий вузол квадродерева, може бути розділений на чотири дочірніх вузли, і кожний дочірній вузол може, в свою чергу, бути батьківським вузлом і бути розділений ще на чотири дочірніх вузли. Кінцевий, нерозділений дочірній вузол, як листовий вузол квадродерева, містить вузол кодування, тобто закодований блок відео. Дані синтаксису, асоційовані із закодованим потоком бітів, можуть визначити максимальну кількість разів, скільки блок дерева може бути розділений, і може також визначити мінімальний розмір вузлів кодування. [0074] CU включає в себе вузол кодування і одиниці прогнозування (PU) і одиниці перетворення (TU), асоційовані з вузлом кодування. Розмір CU звичайно відповідає розміру вузла кодування і є типово квадратним за формою. Розмір CU може ранжуватися від 8×8 пікселів до розміру блока дерева з максимумом 64×64 пікселів або більше. Кожна CU може містити одну або більше одиниць PU і одну або більше одиниць TU. Дані синтаксису, асоційовані з CU, можуть описувати, наприклад, розділення CU в одну або більше одиниць PU. Режими розділення можуть відрізнятися між тим, чи є CU закодованою в режимі пропуску або прямому режимі, закодованою в режимі внутрішнього прогнозування або закодованою в режимі зовнішнього прогнозування. Одиниці PU можуть бути розділені, щоб бути неквадратними за формою. Дані синтаксису, асоційовані з CU, можуть також описувати, наприклад, розділення CU в одну або більше одиниць TU згідно з квадродеревом. TU може бути квадратною або неквадратною за формою. [0075] Стандарт HEVC враховує перетворення згідно з одиницями TU, які можуть бути різними для різних одиниць CU. Одиниці TU типово мають розміри на основі розміру одиниць PU в межах заданої CU, визначеної для розділеної LCU, хоч це може не завжди мати місце. Одиниці TU типово мають той же розмір або менший, що і одиниці PU. У деяких прикладах залишкові вибірки, відповідні CU, можуть бути розділені на менші блоки, використовуючи структуру квадродерева, відому як "залишкове квадродерево" (RQT). Листові вузли RQT можуть згадуватися як одиниці перетворення (одиниці TU). Значення піксельної різниці, асоційовані з одиницями TU, можуть бути перетворені, щоб сформувати коефіцієнти перетворення, які можуть бути квантовані. [0076] Взагалі, PU включає в себе дані, що належать до процесу прогнозування. Наприклад, коли PU є закодованою у внутрішньому режимі, PU може включати в себе дані, що описують режим внутрішнього прогнозування для PU. Як інший приклад, коли PU є закодованою у зовнішньому режимі, PU може включати в себе дані, що визначають вектор руху для PU. Дані, що визначають вектор руху для PU, можуть описувати, наприклад, горизонтальний компонент вектора руху, вертикальний компонент вектора руху, розрізнення для вектора руху (наприклад, піксельну точність в одну чверть або піксельну точність в одну восьму), опорну картинку, на яку вектор руху вказує, і/або список опорних картинок (наприклад, Список 0, Список 1 або Список С) для вектора руху. [0077] Взагалі, TU використовується для процесів квантування і перетворення. Задана CU, що має одну або більше одиниць PU, може також включати в себе одну або більше одиниць перетворення (одиниць TU). Услід за прогнозуванням, відеокодер 20 може обчислити залишкові значення від блока відео, ідентифікованого вузлом кодування згідно з PU. Вузол кодування потім оновлюється, щоб послатися на залишкові значення, а не на первинний блок відео. Залишкові значення містять значення піксельної різниці, які можуть бути перетворені в коефіцієнти перетворення, квантовані і скановані з використанням перетворення і іншої інформації перетворення, заданої в одиницях TU, щоб сформувати перетворені в послідовну форму коефіцієнти перетворення для ентропійного кодування. Вузол кодування може ще раз бути оновлений, щоб посилатися на ці перетворені в послідовну форму коефіцієнти перетворення. Дане розкриття типово використовує термін "блок відео", щоб посилатися на вузол кодування CU. У деяких конкретних випадках дане розкриття може також використовувати термін "блок відео", щоб посилатися на блок дерева, тобто LCU, або CU, яка включає в себе вузол кодування і одиниці PU і одиниці TU. [0078] Відеопослідовність типово включає в себе послідовність відеокадрів або картинок. Група картинок (GOP) взагалі містить послідовність з однієї або більше відеокартинок. GOP може включати дані синтаксису в заголовок GOP, заголовок однієї або більше картинок або в 10 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 інше місце, яке описує множину картинок, включених в GOP. Кожна вирізка картинки може включати в себе дані синтаксису вирізки, які описують режим кодування для відповідної вирізки. Відеокодер 20 типово оперує над блоками відео в межах індивідуальних відеовирізок, щоб закодувати відеодані. Блок відео може відповідати вузлу кодування в межах CU. Блоки відео можуть мати фіксований або змінний розмір і можуть відрізнятися за розміром згідно з вказаним стандартом кодування. [0079] Як приклад, HM підтримує прогнозування в PU різних розмірів. Передбачаючи, що розмір конкретної CU дорівнює 2N×2N, HM підтримує внутрішнє прогнозування в розмірах PU, що дорівнюють 2N×2N або N×N, і зовнішнє прогнозування в симетричних розмірах PU, що дорівнюють 2N×2N, 2N×N, N×2N або N×N. HM також підтримує асиметричне розділення для зовнішнього прогнозування в розмірах PU, що дорівнюють 2N×nU, 2N×nD, nL×2N і nR×2N. При асиметричному розділенні один напрямок CU не розділяється, в той час як інший напрямок розділяється на 25% і 75%. Частина CU, відповідна 25%-ому розділенню, позначена "n", супроводжується індикацією "верхній", "нижній", "лівий" або "правий". Таким чином, наприклад, "2N×nU" належить до CU розміром 2N×2N, яка розділена горизонтально з 2N×0.5N PU зверху і 2N×1.5N PU знизу. [0080] У даному розкритті "N×N" і "N на N" можуть використовуватися взаємозамінно, щоб стосуватися піксельних вимірювань блока відео в термінах вертикального і горизонтального вимірювань, наприклад 16×16 пікселів або 16 на 16 пікселів. Взагалі, блок 16×16 має 16 пікселів у вертикальному напрямку (у=16) і 16 пікселів в горизонтальному напрямку (х=16). Аналогічно, блок N×N звичайно має N пікселів у вертикальному напрямку і N пікселів в горизонтальному напрямку, де N представляє ненегативне цілочислове значення. Пікселі в блоці можуть бути розміщені в рядах і колонках. Крім того, блоки повинні не обов'язково мати ту ж кількість пікселів в горизонтальному напрямку, як у вертикальному напрямку. Наприклад, блоки можуть містити N×M пікселів, де М не обов'язково дорівнює N. [0081] Після кодування з внутрішнім прогнозуванням або з зовнішнім прогнозуванням, використовуючи одиниці PU в CU, відеокодер 20 може обчислити залишкові дані, до яких перетворення, задані одиницями TU в CU, застосовуються. Залишкові дані можуть відповідати піксельним різницям між пікселями незакодованої картинки і значеннями прогнозування, відповідними одиницям CU. Відеокодер 20 може сформувати залишкові дані для CU і потім перетворити залишкові дані, щоб сформувати коефіцієнти перетворення. [0082] Після будь-якого перетворення, щоб сформувати коефіцієнти перетворення, відеокодер 20 може виконати квантування коефіцієнтів перетворення. Квантування звичайно належить до процесу, в якому коефіцієнти перетворення квантуються, щоб можливо зменшити об'єм даних, використаних для представлення коефіцієнтів, забезпечуючи подальше стиснення. Процес квантування може зменшити бітову глибину, асоційовану з деякими або всіма коефіцієнтами. Наприклад, n-бітове значення може бути округлене в меншу сторону до mбітового значення під час квантування, де n більше, ніж m. [0083] У деяких прикладах відеокодер 20 може використовувати попередньо заданий порядок сканування, щоб сканувати квантовані коефіцієнти перетворення, щоб сформувати перетворений в послідовну форму вектор, який може бути ентропійно кодований. У інших прикладах відеокодер 20 може виконати адаптивне сканування. Після сканування квантованих коефіцієнтів перетворення, щоб сформувати одновимірний вектор, відеокодер 20 може ентропійно кодувати одновимірний вектор, наприклад, згідно з контекстно-адаптивним кодуванням зі змінною довжиною коду (CAVLC), контекстно-адаптивним двійковим арифметичним кодуванням (CABAC), основаним на синтаксисі контекстно-адаптивним двійковим арифметичним кодуванням (SBAC), ентропійним кодуванням з розділенням інтервалу імовірності (PIPE) або іншою методологією ентропійного кодування. Відеокодер 20 може також ентропійно кодувати елементи синтаксису, асоційовані з закодованими відеоданими, для використання відеодекодером 30 при декодуванні відеоданих. [0084] Щоб виконати CABAC, відеокодер 20 може призначити контекст в межах контекстної моделі символу, який повинен бути переданий. Контекст може стосуватися, наприклад, того, чи є сусідні значення символу ненульовими, чи ні. Щоб виконати CAVLC, відеокодер 20 може вибрати код із змінною довжиною слова для символу, який повинен бути переданий. Кодові слова в VLC можуть бути побудовані таким чином, що відносно більш короткі коди відповідають більш імовірним символам, в той час як більш довгі коди відповідають менш імовірним символам. Таким чином, використання VLC може досягнути економії бітів, наприклад, використовуючи кодові слова рівної довжини для кожного символу, який повинен бути переданий. Визначення імовірності може бути основане на контексті, призначеному на символ. 11 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 60 [0085] У деяких прикладах відеокодер 20 і відеодекодер 30 можуть бути сконфігуровані, щоб реалізувати один або більше зразкових способів, описаних в даному розкритті. Відеокодер 20 може закодувати відеодані у формі одиниці доступу, яка розділена на одну або більше одиниць декодування. Ці одиниці доступу можуть бути тимчасово збережені в буфері кодованих картинок. Відеодекодер 30 може витягнути одиниці DU для декодування в порядку декодування на основі інформації тактування, включеної в елементи синтаксису для відповідної AU або DU. [0086] Згідно зі способами, описаними в даному розкритті, термін "одиниця декодування" може бути визначений наступним чином. Одиниця декодування є одиницею доступу або піднабором одиниць доступу. Якщо елемент синтаксису SubPicCpbFlag дорівнює 0, одиниця декодування є одиницею доступу. Інакше, DU включає в себе одну або більше одиниць NAL VCL в AU і асоційовані одиниці NAL не-VCL. Якщо одиниця NAL не-VCL має nal_unit_type, що дорівнює UNSPEC0, EOS_NUT, EOB_NUT, FD_NUT, в діапазоні RSV_NVCL44-RSV_NVCL47 або в діапазоні UNSPEC48-UNSPEC63, одиниця NAL не-VCL асоційована з найбільш нещодавньою попередньою одиницею NAL VCL в порядку декодування, інакше одиниця NAL не-VCL асоційована з першою подальшою одиницею NAL VCL в порядку декодування. Для того, щоб коректно розглянути одиниці NAL не-VLC згідно зі способами, описаними в даному документі, DU може бути визначена, щоб розглядати одиниці NAL не-VCL з nal_unit_type, що дорівнює UNSPEC0, EOS_NUT, EOB_NUT, в діапазоні RSV_NVCL44-RSV_NVCL47 або в діапазоні UNSPEC48-UNSPEC63. [0087] Згідно зі способами, описаними в даному розкритті, термін "точка операції" може бути визначений наступним чином. Точка операції ідентифікується набором nuh_reserved_zero_6bits значень (позначених як OpLayerIdSet) і значенням TemporalId (позначеним як OpTid), і асоційованим піднабором потоку бітів, виведеним як результат процесу витягання підпотоку бітів, як визначено в підпункті 10.1 в HEVC WD8. Елементи синтаксису OpTid і OpLayerIdSet можуть функціонувати як вхідні дані і бути незалежно декодованими. [0088] Деякі зразкові потоки бітів, генеровані згідно зі способами, описаними в даному документі, можуть мати рівень відповідності потоку бітів. Підпункт 10.1 HEVC WD8 описує, що може мати місце вимога відповідності (узгодження) потоку бітів, що будь-який підпотік бітів, який включений у вихідних даних процесу, визначеного в підпункті 10.1, з tIdTarget, що дорівнює будь-якому значенню в діапазоні від 0 до 6, включно, і з targetDecLayerIdSet, що містить значення 0, може відповідати HEVC. [0089] У деяких прикладах відповідний (узгоджуваний) потік бітів може містити одну або більше закодованих одиниць NAL вирізки з nuh_reserved_zero_6bits, що дорівнює 0, і TemporalId, що дорівнює 0. [0090] Вхідними даними до процесу, описаного тут, можуть бути змінна tIdTarget і список targetDecLayerIdSet. Вихідні дані включають в себе підпотік бітів. Підпотік бітів може бути виведений за допомогою видалення з потоку бітів всіх одиниць NAL з TemporalId, більшим ніж tIdTarget або nuh_reserved_zero_6bits не серед значень в targetDecLayerIdSet. [0091] Кожна одиниця NAL може бути асоційована з інформацією заголовка. Для семантики заголовка одиниці NAL може бути визначене наступне. Під час декодування декодер 30 може проігнорувати (наприклад, видалити з потоку бітів і відкинути) вміст всіх одиниць NAL, які використовують збережені значення nal_unit_type. У операціях HRD, як визначено в Додатку С в HEVC WD8, залежно від вибраної точки операції, що піддається тесту, одиниці NAL із збереженими значеннями nal_unit_type можуть бути розглянуті при виведенні часів надходження і видалення з CPB, але під час декодування вони можуть бути безпечно проігноровані (видалені і відкинуті). [0092] Під час декодування декодери можуть проігнорувати (наприклад, видалити з потоку бітів і відкинути) всі одиниці NAL зі значеннями nuh_reserved_zero_6bits, що не дорівнюють 0. В операціях HRD, як визначено в Додатку С в HEVC WD8, залежно від вибраної точки операції, що піддається тесту, одиниці NAL із збереженими значеннями nuh_reserved_zero_6bits можуть бути розглянуті при виведенні тактування надходження і видалення з CPB, але під час декодування вони можуть бути безпечно проігноровані (видалені і відкинуті). [0093] Часи надходження і часи видалення з буфера кодованих картинок можуть бути основані на двох рівнях: рівень одиниці доступу і рівень субкартинок. Відеокодер (наприклад, відеокодер 20 або відеодекодер 30) може бути сконфігурований, щоб вивести час надходження в CPB і номінальний час видалення з CPB і для рівня одиниці доступу, і для рівня субкартинок, незалежно від значення елемента синтаксису, який визначає, чи знаходиться DU в AU (наприклад, чи включає AU в себе тільки одну DU). Елементом синтаксису може бути SubPicCpbFlag, який може бути сигналізований для кожної AU. Як описано вище, коли SubPicCpbFlag дорівнює 0, DU складає всю AU. Інакше, коли SubPicCpbFlag дорівнює 12 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 ненульовому значенню, DU включає в себе одну або більше одиниць NAL VCL в AU і асоційовані одиниці NAL не-VCL. У деяких прикладах відеокодер може бути сконфігурований, щоб також вивести часи видалення з CPB для рівня AU, коли елемент синтаксису вказує, що DU є одиницею AU. У деяких з цих прикладів відеокодер може бути сконфігурований, щоб вивести часи видалення з CPB тільки для рівня AU, коли елемент синтаксису вказує, що DU є одиницею AU. [0094] У деяких прикладах відеокодер (наприклад, відеокодер 20 або відеодекодер 30) може бути сконфігурований, щоб також вивести часи видалення з CPB для рівня субкартинок, коли елемент синтаксису вказує, що DU не є одиницею AU. У деяких з цих прикладів відеокодер може бути сконфігурований, щоб вивести часи видалення з CPB тільки для рівня субкартинок, коли елемент синтаксису вказує, що DU не є AU. [0095] Відеокодер може бути сконфігурований, щоб вивести час надходження в CPB і номінальний час видалення з CPB, коли другий елемент синтаксису визначає, що параметри затримки видалення з CPB на рівні субкартинок присутні, і CPB може працювати на рівні AU або рівні субкартинок. Другий елемент синтаксису може бути sub_pic_cpb_params_present_flag. Коли sub_pic_cpb_params_present_flag дорівнює 1, параметри затримки видалення з CPB на рівні субкартинок присутні, і CPB може працювати на рівні одиниці доступу або рівні субкартинок, і, коли sub_pic_cpb_params_present_flag дорівнює 0, параметри затримки видалення з CPB на рівні субкартинок не присутні, і CPB працює на рівні одиниці доступу. [0096] У деяких з прикладів, де sub_pic_cpb_params_present_flag дорівнює 1, відеокодер може бути сконфігурований, щоб встановити змінну subPicParamsPresentFlag рівною 0 і вивести початковий і кінцевий час надходження AU. Потім відеокодер може бути сконфігурований, щоб встановити змінну subPicParamsPresentFlag рівною 1 і вивести початковий і кінцевий час надходження DU для одиниці DU в межах AU. [0097] Крім того, в деяких прикладах відеокодер (наприклад, відеокодер 20 або відеодекодер 30) може бути сконфігурований, щоб закодувати (наприклад, закодувати або декодувати) тривалість часу між видаленням з CPB першої одиниці декодування в одиниці доступу і другої DU в одиниці доступу. У цьому прикладі друга DU є наступною за першою DU в порядку декодування і в тій же самій AU, що і DU. Відеокодер може бути сконфігурований, щоб визначити час видалення першої DU на основі щонайменше закодованої тривалості. У деяких способах відеокодер може визначити час видалення першої DU без кодування початкової затримки видалення з CPB і зміщення. У деяких прикладах друга DU є безпосередньо наступною за першою DU в одиниці доступу. У деяких прикладах друга DU є останньою DU в одиниці доступу в порядку декодування. [0098] Відеокодер (наприклад, відеокодер 20 або відеодекодер 30) може також бути сконфігурований, щоб закодувати параметри CPB рівня субкартинок. У цих прикладах відеокодер може визначити час видалення першої DU на основі щонайменше одного із закодованої тривалості і параметрів CPB рівня субкартинок. Наприклад, параметри CPB рівня субкартинок можуть бути повідомленням SEI тактування субкартинок, яке асоційоване з першою DU. У деяких прикладах відеокодер може закодувати тривалість між часом видалення останньої DU в AU в порядку декодування і першої DU в повідомленні SEI субкартинок. У деяких прикладах відеокодер може закодувати прапор рівня послідовності, щоб вказувати присутність параметрів CPB рівня субкартинок або в повідомленнях SEI тактування картинок, або в повідомленнях SEI тактування субкартинок. [0099] Наприклад, відеокодер 20 може бути сконфігурований, щоб закодувати тривалість часу між видаленням з CPB першої DU в AU і другої DU в AU. Відеокодер 20 може закодувати параметри CPB рівня субкартинок, такі як параметри затримки видалення з CPB на рівні субкартинок, в одному з повідомлення SEI тактування картинок або повідомлення SEI тактування субкартинок. Відеокодер 20 може закодувати прапор, sub_pic_cpb_params_in_pic_timing_sei_flag, щоб указати, чи присутні параметри CPB рівня субкартинок в повідомленні SEI тактування картинок або в повідомленні SEI тактування субкартинок. [0100] Наприклад, відеодекодер 30 може декодувати тривалість часу між видаленням з CPB першої DU в AU і другої DU в цій AU. Відеодекодер 30 може бути сконфігурований, щоб визначити час видалення першої DU на основі щонайменше декодованої тривалості. У деяких способах відеокодер може визначити час видалення першої DU без декодування початкової затримки видалення з CPB і зміщення. Відеодекодер 30 може декодувати параметри CPB рівня субкартинок з повідомлення SEI тактування картинок або повідомлення SEI тактування субкартинок, прийнятого від відеокодера 20. Відеодекодер 30 може визначити, в якому 13 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 60 повідомленні SEI шукати параметри CPB рівня субкартинок, на основі присутності прапора, sub_pic_cpb_params_in_pic_timing_sei_flag. [0101] У деяких із зразкових способів, описаних в даному розкритті, часове значення ідентифікаційної інформації (TemporalId) другої DU може не бути більшим, ніж TemporalId першої DU. У деяких прикладах TemporalId другої DU може не бути більше, ніж нуль. [0102] Наприклад, способи, описані в даному розкритті, можуть забезпечити більш стійке до помилок визначення часу видалення буфера кодованих картинок. Крім того, на доповнення до поліпшеної стійкості до помилок, способи можуть сприяти ефективності сигналізації, яка зменшує смугу пропускання, службові витрати сигналізації і збільшує час кодування. Крім того, способи, описані в даному розкритті, можуть врахувати поліпшену часову масштабованість. [0103] Фіг. 2 є блок-схемою, що ілюструє зразковий кодер відео 20, який може реалізувати способи, описані в даному розкритті. Відеокодер 20 може виконувати внутрішнє і зовнішнє кодування блоків відео в межах відеовирізок. Внутрішнє кодування використовує просторове прогнозування, щоб зменшити або видалити просторову надмірність у відео в межах заданого відеокадру або картинки. Зовнішнє кодування використовує часове прогнозування, щоб зменшити або видалити часову надмірність у відео в межах суміжних кадрів або картинок відеопослідовності. Внутрішній режим (I-режим) може належати до будь-якого з декількох основаних на просторі режимів стиснення. Зовнішні режими, такі як однонаправлене прогнозування (Р-режим) або біпрогнозування (В-режим), можуть належати до будь-якого з декількох основаних на часі режимів стиснення. [0104] У прикладі згідно з фіг. 2, відеокодер 20 включає в себе модуль 35 розділення, модуль 41 обробки прогнозування, суматор 50, модуль 52 обробки перетворення, модуль 54 квантування і модуль 56 ентропійного кодування. Модуль 41 обробки прогнозування включає в себе модуль 42 оцінки руху, модуль 44 компенсації руху і модуль 46 обробки внутрішнього прогнозування. Для реконструкції блока відео, відеокодер 20 також включає в себе модуль 58 зворотного квантування, модуль 60 обробки зворотного перетворення, суматор 62, модуль 64 фільтрів і буфер декодованих картинок (DPB) 66. Буфер 66 декодованих картинок може також згадуватися як пам'ять опорних картинок. У інших прикладах відеокодер 20 може включати в себе більше, менше або інші функціональні компоненти. [0105] Як показано на фіг. 2, відеокодер 20 приймає відеодані і модуль 35 розділення розділяє дані на блоки відео. Це розділення відеоданих може також включати в себе розділення відеоданих на вирізки, мозаїчні елементи (плитки) або інші великі блоки, а також розділення блока відео, наприклад, згідно зі структурою квадродерева одиниць LCU і одиниць CU. Відеокодер 20 звичайно ілюструє компоненти, які кодують блоки відео в межах відеовирізки, яка повинна бути закодована. Вирізка може бути розділена на множинні блоки відео (і можливо на набори блоків відео, званих "мозаїчні елементи"). [0106] Модуль 41 обробки прогнозування може вибрати один з множини можливих режимів кодування, таких як один з множини режимів внутрішнього кодування або один з множини зовнішніх режимів кодування, для поточного блока відео, на основі результатів помилок (наприклад, швидкість кодування і рівень спотворення). Модуль 41 обробки прогнозування може видати результуючий кодований внутрішньо або зовнішньо блок до суматора 50, щоб генерувати залишкові дані блока, і до суматора 62, щоб відновити закодований блок для використання як опорної картинки. [0107] Модуль 46 обробки внутрішнього прогнозування, що знаходиться в межах модуля 41 обробки прогнозування, може виконати кодування з внутрішнім прогнозуванням поточного блока відео відносно одного або більше сусідніх блоків в тому ж самому кадрі або вирізці, як і поточний блок, який повинен бути закодований, щоб забезпечити просторове стиснення. Модуль 42 оцінки руху і модуль 44 компенсації руху в межах модуля 41 обробки прогнозування виконують кодування з зовнішнім прогнозуванням поточного блока відео відносно одного або більше прогнозуючих блоків в одній або більше опорних картинках, щоб забезпечити часове стиснення. [0108] Модуль 42 оцінки руху може бути сконфігурований, щоб визначити режим зовнішнього прогнозування для відеовирізки згідно із попередньо визначеним шаблоном для відеопослідовності. Попередньо визначений шаблон може визначати відеовирізки в послідовності як Р-вирізки, В-вирізки або вирізки GPB. Модуль 42 оцінки руху і модуль 44 компенсації руху можуть бути інтегрованими, але ілюстровані окремо в концептуальних цілях. Оцінка руху, виконана модулем 42 оцінки руху, є процесом генерування векторів руху, які оцінюють руху для блоків відео. Вектор руху, наприклад, може вказувати зміщення PU блока відео в межах поточного відеокадру або картинки відносно прогнозуючого блока в межах опорної картинки. 14 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 [0109] Прогнозуючий блок є блоком, який, як знаходять, близько відповідає PU блока відео, який повинен бути закодований, в термінах піксельної різниці, яка може бути визначена сумою абсолютних різниць (SAD), сумою різниць квадратів (SSD) або іншими метриками відмінності. У деяких прикладах відеокодер 20 може обчислити значення для субцілочислових піксельних позицій опорних картинок, збережених в буфері 66 декодованих картинок. Наприклад, відеокодер 20 може інтерполювати значення піксельних позицій в одну чверть, піксельних позицій в одну восьму або інших фракційних піксельних позицій опорної картинки. Тому модуль 42 оцінки руху може виконати пошук руху відносно повних піксельних позицій і фракційних піксельних позицій і вивести вектор руху з фракційною піксельною точністю. [0110] Модуль 42 оцінки руху обчислює вектор руху для PU блока відео у кодованій зовнішньо вирізці, порівнюючи позицію PU з позицією прогнозуючого блока опорної картинки. Опорна картинка може бути вибрана з першого списку опорних картинок (Список 0) або другого списку опорних картинок (Список 1), кожний з яких ідентифікує одну або більше опорних картинок, збережених в буфері 66 декодованих картинок. Модуль 42 оцінки руху відправляє обчислений вектор руху в модуль 56 ентропійного кодування і модуль 44 компенсації руху. [0111] Компенсація руху, виконана модулем 44 компенсації руху, може включати в себе установлення або генерування прогнозуючого блока на основі вектора руху, визначеного за допомогою оцінки руху, можливо виконуючи інтерполяції до субпіксельної точності. Після прийому вектора руху для PU поточного блока відео модуль 44 компенсації руху може визначити місцезнаходження прогнозуючого блока, на який вектор руху вказує в одному зі списків опорних картинок. Відеокодер 20 формує залишковий блок відео, віднімаючи піксельні значення прогнозуючого блока з піксельних значень поточного закодованого блока відео, формуючи значення піксельної різниці. Значення піксельної різниці формують залишкові дані для блока і можуть включати в себе різницеві компоненти як яскравості, так і насиченості кольору. Суматор 50 представляє компонент або компоненти, які виконують цю операцію віднімання. Модуль 44 компенсації руху може також генерувати елементи синтаксису, асоційовані з блоками відео і відеовирізкою, для використання відеодекодером 30 при декодуванні блоків відео у відеовирізці. [0112] Модуль 46 обробки внутрішнього прогнозування може внутрішньо прогнозувати поточний блок, як альтернатива зовнішньому прогнозуванню, виконаному модулем 42 оцінки руху і модулем 44 компенсації руху, як описано вище. Зокрема, модуль 46 обробки внутрішнього прогнозування може визначити режим внутрішнього прогнозування, щоб використовувати для кодування поточного блока. У деяких прикладах модуль 46 обробки внутрішнього прогнозування може закодувати поточний блок, використовуючи різні режими внутрішнього прогнозування, наприклад під час окремих проходів кодування, і модуль 46 обробки внутрішнього прогнозування (або модуль 40 вибору режиму, в деяких прикладах) може вибрати відповідний режим внутрішнього прогнозування для використання з протестованих режимів. Наприклад, модуль 46 обробки внутрішнього прогнозування може обчислити значення "швидкість передачі - спотворення", використовуючи аналіз "швидкість передачі - спотворення" для різних протестованих режимів внутрішнього прогнозування, і вибрати режим внутрішнього прогнозування, що має кращі характеристики швидкості передачі - спотворення серед протестованих режимів. Аналіз "швидкість передачі - спотворення" взагалі визначає величину спотворення (або помилку) між закодованим блоком і первинним, незакодованим блоком, який був закодований, щоб сформувати закодований блок, а також частоту проходження бітів (тобто кількість бітів), використану для формування закодованого блока. Модуль 46 обробки внутрішнього прогнозування може обчислити відношення зі спотворень і швидкостей передачі для різних закодованих блоків, щоб визначити, який режим внутрішнього прогнозування показує краще значення "швидкість передачі - спотворення" для блока. [0113] У будь-якому випадку після вибору режиму внутрішнього прогнозування для блока модуль 46 обробки внутрішнього прогнозування може надати інформацію, що вказує вибраний режим внутрішнього прогнозування для блока, до модуля 56 ентропійного кодування. Модуль 56 ентропійного кодування може закодувати інформацію, що вказує вибраний режим внутрішнього прогнозування, згідно зі способами даного розкриття. Відеокодер 20 може включати в передані дані конфігурацію потоку бітів, яка може включати в себе множину таблиць індексу режиму внутрішнього прогнозування, і множину модифікованих таблиць індексу режиму внутрішнього прогнозування (також званих таблицями відображення кодових слів), визначення контекстів кодування для різних блоків, і індикації найбільш імовірного режиму внутрішнього прогнозування, таблиці індексу режиму внутрішнього прогнозування, і модифіковані таблиці індексу режиму внутрішнього прогнозування, щоб використовувати для кожного з контекстів. 15 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 60 [0114] Після того, як модуль 41 обробки прогнозування генерує прогнозуючий блок для поточного блока відео або через зовнішнє прогнозування, або через внутрішнє прогнозування, відеокодер 20 формує залишковий блок відео, віднімаючи прогнозуючий блок з поточного блока відео. Залишкові відеодані в залишковому блоці можуть бути включені в одну або більше одиниць TU і надані на модуль 52 обробки перетворення. Модуль 52 обробки перетворення перетворює залишкові відеодані в залишкові коефіцієнти перетворення, використовуючи перетворення, таке як дискретне косинусне перетворення (DCT) або концептуально подібне перетворення. Модуль 52 обробки перетворення може перетворити залишкові відеодані з піксельної області в область перетворення, таку як частотна область. [0115] Модуль 52 обробки перетворення може відправити результуючі коефіцієнти перетворення в модуль 54 квантування. Модуль 54 квантування квантує коефіцієнти перетворення, щоб далі зменшити частоту проходження бітів. Процес квантування може зменшити бітову глибину, асоційовану з деякими або всіма коефіцієнтами. Міра квантування може бути модифікована, регулюючи параметр квантування. У деяких прикладах модуль 54 квантування може потім виконати сканування матриці, що включає в себе квантовані коефіцієнти перетворення. Альтернативно, модуль 56 ентропійного кодування може виконати сканування. [0116] Услід за квантуванням модуль 56 ентропійного кодування може ентропійно кодувати квантовані коефіцієнти перетворення. Наприклад, модуль 56 ентропійного кодування може виконати контекстно-адаптивне кодування зі змінною довжиною коду (CAVLC), контекстноадаптивне двійкове арифметичне кодування (CABAC), основане на синтаксисі контекстноадаптивне двійкове арифметичне кодування (SBAC), ентропійне кодування з розділенням інтервалу імовірності (PIPE) або іншу методологію ентропійного кодування або спосіб. Після ентропійного кодування модулем 56 ентропійного кодування закодований потік бітів може бути переданий до відеодекодера 30 або заархівований для більш пізньої передачі або пошуку відеодекодером 30. Модуль 56 ентропійного кодування може також ентропійно кодувати вектори руху і інші елементи синтаксису для поточної закодованої відеовирізки. [0117] Модуль 58 зворотного квантування і модуль 60 обробки зворотного перетворення застосовують зворотне квантування і зворотне перетворення, відповідно, щоб відновити залишковий блок в піксельній області для більш пізнього використання як опорного блока опорної картинки. Модуль 44 компенсації руху може обчислити опорний блок, додаючи залишковий блок до прогнозуючого блока однієї з опорних картинок в межах одного зі списків опорних картинок. Модуль 44 компенсації руху може також застосувати один або більше фільтрів інтерполяції до відновленого залишкового блока, щоб обчислити субцілочислові піксельні значення для використання в оцінці руху. Суматор 62 додає відновлений залишковий блок до блока прогнозування зі скомпенсованим рухом, сформованого модулем 44 компенсації руху, щоб сформувати опорний блок, для збереження в буфері 66 декодованих картинок. Опорний блок може використовуватися модулем 42 оцінки руху і модулем 44 компенсації руху як опорний блок, щоб зовнішньо прогнозувати блок в подальшому відеокадрі або картинці. [0118] Відеокодер 20 також включає в себе модуль 64 фільтрів, який може фільтрувати границі блока, щоб видалити артефакти блоковості з відновленого відео. Таким чином, модуль 64 фільтрів може виконувати одну або більше операцій видалення блоковості, щоб зменшити артефакти блоковості в блоках кодування, асоційованих з CU. Модуль 64 фільтрів може бути фільтром видалення блоковості і фільтрує вихідний сигнал суматора 62. Додаткові контурні фільтри (в контурі або після контуру) можуть також використовуватися на доповнення до модуля 64 фільтрів. [0119] Буфер 66 декодованих картинок може зберігати відновлені блоки кодування після того, як модуль 64 фільтрів виконує одну або більше операцій видаленняблоковості відносно відновлених блоків кодування. Модуль 41 обробки прогнозування може використовувати опорну картинку, яка містить відновлені блоки кодування, щоб виконати зовнішнє прогнозування відносно одиниць PU інших картинок. Крім того, модуль 46 обробки внутрішнього прогнозування може використовувати відновлені блоки кодування в буфері 66 декодованих картинок, щоб виконати внутрішнє прогнозування відносно інших одиниць PU в тій же картинці, як CU. [0120] Відеокодер 20 може генерувати елементи синтаксису, що належать до часів видалення з CPB одиниці DU в межах AU згідно зі способами, описаними в даному документі. Як тільки ці елементи синтаксису генеруються, відеокодер 20 кодує їх в один або більше потоків бітів і виводить ці потоки бітів. [0121] Відповідно до даного розкриття, модуль 41 обробки прогнозування представляє один зразковий модуль для того, щоб виконати зразкові функції, описані вище. У інших прикладах модуль, відмінний від модуля 41 обробки прогнозування, може реалізувати приклади, описані 16 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 60 вище. У деяких інших прикладах модуль 41 обробки прогнозування в з'єднанні з одним або більше іншими модулями відеокодера 20 можуть реалізувати приклади, описані вище. У ще деяких інших прикладах процесор або модуль відеокодера 20 може, один або в з'єднанні з іншими блоками відеокодера 20, реалізовувати приклади, описані вище. [0122] Фіг. 3 є блок-схемою, що ілюструє зразковий декодер відео 30, який може реалізувати способи, описані в даному розкритті. У прикладі згідно з фіг. 3, відеодекодер 30 включає в себе модуль 80 ентропійного декодування, модуль 81 обробки прогнозування, модуль 86 зворотного квантування, модуль 88 зворотного перетворення, суматор 90 і буфер 92 декодованих картинок (DPB). Модуль 81 обробки прогнозування включає в себе модуль 82 компенсації руху і модуль 84 обробки внутрішнього прогнозування. Буфер 94 кодованих картинок (CPB) показаний як вхід у відеодекодер 30. Однак, в деяких прикладах CPB 94 може бути частиною відеодекодера 30. Відеодекодер 30 в деяких прикладах може виконати прохід декодування, загалом зворотний проходу кодування, описаному відносно відеокодера 20 на фіг. 2. [0123] Під час процесу декодування відеодекодер 30 приймає закодований відеопотік бітів, який представляє блоки відео закодованої відеовирізки, і асоційовані елементи синтаксису від відеокодера 20. Блоки відео закодованої відеовирізки і асоційовані елементи синтаксису від відеокодера 20 можуть бути витягнуті з буфера 94 кодованих картинок. Закодоване відео з CPB 94 може включати в себе, наприклад, одиниці доступу (AU), що містять одиниці декодування (одиниці DU). Елементи синтаксису можуть включати в себе змінні і прапори, що вказують часи видалення з CPB для одиниць доступу і одиниць декодування. [0124] Модуль 80 ентропійного декодування відеодекодера 30 ентропійно декодує потік бітів, щоб генерувати квантовані коефіцієнти, вектори руху і інші елементи синтаксису. Модуль 80 ентропійного декодування направляє вектори руху і інші елементи синтаксису до модуля 81 обробки прогнозування. Відеодекодер 30 може прийняти елементи синтаксису на рівні вирізки відео і/або рівні блока відео. [0125] Коли відеовирізка закодована як кодована внутрішньо (I) вирізка, модуль 84 обробки внутрішнього прогнозування з модуля 81 обробки прогнозування може генерувати дані прогнозування для блока відео поточної відеовирізки на основі сигналізованого режиму внутрішнього прогнозування і даних від раніше декодованих блоків поточного кадру або картинки. Коли відеокадр закодований як кодована зовнішньо (тобто В, Р або GPB) вирізка, модуль 82 компенсації руху з модуля 81 обробки прогнозування формує прогнозуючі блоки для блока відео поточної відеовирізки на основі вектора руху і інших елементів синтаксису, прийнятих від модуля 80 ентропійного декодування. Прогнозуючі блоки можуть бути сформовані з однієї з опорних картинок в межах одного зі списків опорних картинок. Відеодекодер 30 може побудувати списки опорних кадрів, Список 0 і Список 1, використовуючи способи конструювання за умовчанням, на основі опорних картинок, збережених в буфері 92 декодованих картинок. [0126] Модуль 82 компенсації руху визначає інформацію прогнозування для блока відео поточної відеовирізки за допомогою синтаксичного розбору векторів руху і інших елементів синтаксису, і використовує інформацію прогнозування, щоб сформувати прогнозуючі блоки для поточного декодованого блока відео. Наприклад, модуль 82 компенсації руху використовує деякі з прийнятих елементів синтаксису, щоб визначити режим прогнозування (наприклад, внутрішнє або зовнішнє прогнозування), використаний для кодування блоків відео для відеовирізки, тип вирізки зовнішнього прогнозування (наприклад, В-вирізка, Р-вирізка або вирізка GPB), інформацію конструювання для одного або більше списків опорних картинок для вирізки, вектори руху для кожного кодованого зовнішньо блока відеовирізки, статус зовнішнього прогнозування для кожного кодованого зовнішньо блока відеовирізки і іншу інформацію, щоб декодувати блоки відео в поточній відеовирізці. [0127] Модуль 82 компенсації руху може також виконати інтерполяцію на основі фільтрів інтерполяції. Модуль 82 компенсації руху може використовувати фільтри інтерполяції, які використовуються відеокодером 20 під час кодування блоків відео, щоб обчислити інтерпольовані значення для субцілочислових пікселів опорних блоків. У цьому випадку модуль 82 компенсації руху може визначити фільтри інтерполяції, використовувані відеокодером 20, з прийнятих елементів синтаксису, і використовувати ці фільтри інтерполяції, щоб сформувати прогнозуючі блоки. [0128] Модуль 86 зворотного квантування зворотно квантує, тобто деквантує, квантовані коефіцієнти перетворення, надані в потоці бітів і декодовані модулем 80 ентропійного декодування. Процес зворотного квантування може включати в себе використання параметра квантування, обчисленого відеокодером 20 для кожного блока відео у відеовирізці, щоб визначити міру квантування і, аналогічно, міру зворотного квантування, яка повинна бути 17 UA 114004 C2 5 10 15 20 25 30 35 40 45 50 55 60 застосована. Модуль 88 обробки зворотного перетворення застосовує зворотне перетворення, наприклад зворотне DCT, зворотне цілочислове перетворення або концептуально подібний процес зворотного перетворення, до коефіцієнтів перетворення, щоб сформувати залишкові блоки в піксельній області. [0129] Після того, як модуль 82 компенсації руху генерує прогнозуючий блок для поточного блока відео на основі вектора руху і інших елементів синтаксису, відеодекодер 30 формує декодований блок відео, підсумовуючи залишкові блоки від модуля 88 обробки зворотного перетворення з відповідними прогнозуючими блоками, генерованими модулем 82 компенсації руху. Суматор 90 представляє компонент або компоненти, які виконують цю операцію підсумовування. Якщо бажано, фільтр видалення блоковості може також бути застосований, щоб фільтрувати декодовані блоки, щоб видалити артефакти блоковості. Інші контурні фільтри (або в контурі кодування, або після контуру кодування) можуть також бути використані для згладжування піксельних переходів або іншого поліпшення якості відео. Декодовані блоки відео в заданому кадрі або картинці потім зберігають в DPB 92, який зберігає опорні картинки, використовувані для подальшої компенсації руху. DPB 92 також зберігає декодоване відео для більш пізнього представлення на пристрої відображення, такому як пристрій 32 відображення на фіг. 1. [0130] Відповідно до даного розкриття модуль 81 обробки прогнозування представляє один зразковий модуль для того, щоб виконати зразкові функції, описані вище. У інших прикладах модуль, відмінний від модуля 81 обробки прогнозування, може реалізувати приклади, описані вище. У деяких інших прикладах модуль 81 обробки прогнозування в з'єднанні з одним або більше іншими модулями відеодекодера 30 може реалізувати приклади, описані вище. У ще деяких інших прикладах процесор або модуль відеодекодера 30 може, один або в з'єднанні з іншими модулями відеодекодера 30, реалізовувати приклади, описані вище. [0131] Відеодекодер 30 може зберегти прийняті відеодані у формі потоку бітів, що включає в себе одиниці AU і одиниці DU, в буфері 94 кодованих картинок (CPB). Відеодекодер 30 може витягнути одиниці DU і одиниці AU з CPB 94 у часи видалення, визначені з елементів синтаксису відеодекодером 30, прийнятих в потоці бітів. Прапори і змінні, присутні в повідомленнях SEI, можуть інформувати відеодекодер 30, коли видалити одиниці DU з CPB 94. У визначений час видалення для поточної DU, відеодекодер 30 витягує поточну DU з CPB 94 і декодує DU. У деяких прикладах відеодекодер 30 також витягує AU, коли поточна DU є останньою DU цієї AU. [0132] Нижченаведене описує роботу CPB 94. Цей опис може застосуватися незалежно до кожного з параметрів CPB, який присутній, і до обох точок узгодження Типу I і Типу II, показаних на фіг. С-1 в HEVC WD8, де набір параметрів CPB вибраний так, як визначено в підпункті C.1 HEVC WD8. Робота CPB 94 може включати в себе тактування надходження потоку бітів і тактування видалення одиниці декодування і декодування одиниці декодування. Кожне описане по черзі. [0133] Спочатку буде описане тактування надходження потоку бітів. Для тактування надходження потоку бітів, до ініціалізації HRD, CPB 94 пустий. У деяких прикладах після ініціалізації HRD не може ініціалізуватися знов подальшим повідомленням SEI періоду буферизації. [0134] У прикладах, описаних в даному розкритті, кожна одиниця доступу згадується як одиниця доступу "n", де номер "n" ідентифікує конкретну одиницю доступу. Одиниця доступу, яка асоційована з повідомленням SEI періоду буферизації, яке ініціалізує CPB 94, згадується як одиниця доступу 0. Значення n збільшується на 1 для кожної подальшої одиниці доступу в порядку декодування. [0135] Кожна одиниця декодування згадується як одиниця декодування "m", де номер "m" ідентифікує конкретну одиницю декодування. Перша одиниця декодування в порядку декодування в одиниці доступу 0 згадується як одиниця декодування 0. Значення m збільшується на 1 для кожної подальшої одиниці декодування в порядку декодування. [0136] Коли sub_pic_cpb_params_present_flag дорівнює 1, наступний процес викликається спочатку, зі змінною subPicParamsPresentFlag, встановленою рівною 0, для виведення початкового і кінцевого часів надходження одиниці доступу (AU) для одиниці доступу n. Потім наступний процес викликається з subPicParamsPresentFlag, встановленим рівним 1, для виведення початкового і кінцевого часів надходження одиниці декодування для одиниць декодування в одиниці доступу n. [0137] Змінні InitCpbRemovalDelay[SchedSelIdx] і InitCpbRemovalDelayOffset[SchedSelIdx] можуть бути встановлені наступним чином. Якщо одна з наступних трьох умов вірна, InitCpbRemovalDelay[SchedSelIdx] і InitCpbRemovalDelayOffset[SchedSelIdx] встановлені в 18 UA 114004 C2 5 10 15 20 25 значення initial_alt_cpb_removal_delay[SchedSelIdx] і initial_alt_cpb_removal_delay_offset[SchedSelIdx], відповідні NalHrdModeFlag, відповідно, в повідомленні SEI періоду буферизації. Перша умова може мати місце, коли одиниця доступу 0 є одиницею доступу з розірваним посиланням (BLA), для якого закодована картинка має nal_unit_type, що дорівнює BLA_W_DLP або BLA_N_LP, і значення rap_cpb_params_present_flag повідомлення SEI періоду буферизації дорівнює 1. Друга умова може полягати в тому, що DefaultInitCpbParamsFlag дорівнює 0. Третя умова може полягати в тому, що subPicParamsPresentFlag дорівнює 1. Потрібно зазначити, що в деяких прикладах, коли sub_pic_cpb_params_present_flag дорівнює 1, закодована відеопослідовність може не мати картинок чистого довільного доступу (CRA) або BLA, і таким чином перші дві умови можуть обидві бути хибними. [0138] Інакше, якщо жодна з вищезазначених трьох умов не вірна, InitCpbRemovalDelay[SchedSelIdx] і InitCpbRemovalDelayOffset[SchedSelIdx] встановлені в значення initial_cpb_removal_delay[SchedSelIdx] і initial_cpb_removal_delay_offset[SchedSelIdx], відповідні NalHrdModeFlag, відповідно, в асоційованому повідомленні SEI періоду буферизації, вибраному так, як визначено в підпункті C.1 в HEVC WD8. [0139] У прикладах, описаних в даному розкритті, час, в який перший біт одиниці декодування m починає входити в CPB 94, згадується як початковий час надходження tai(m). Початковий час надходження одиниці декодування m виводиться наступним чином. Якщо одиниця декодування є одиницею декодування 0 (тобто m=0), tai(0)=0. Таким чином, перша одиниця декодування надходить у час 0. Інакше, для одиниць декодування після першої одиниці декодування (одиниця декодування m з m>0), застосовується наступне. [0140] Якщо cbr_flag[SchedSelIdx] дорівнює 1, початковий час надходження для одиниці декодування m дорівнює кінцевому часу надходження (tai, виведеному нижче) одиниці декодування m-1, попередньої одиниці декодування. Рівняння 1 забезпечує відношення: . Інакше (наприклад, cbr_flag[SchedSelIdx] дорівнює 0), початковий час надходження для одиниці декодування m (наприклад, для m>0) виводиться Рівнянням 2: . 30 [0141] Час надходження одиниці декодування виводиться наступним чином. Якщо одиниця декодування m не є першою одиницею декодування подальшого періоду буферизації, виводиться, як показано в Рівнянні 3: , 35 де є номінальним часом видалення одиниці декодування m з CPB 94. [0142] Кінцевий час надходження для одиниці декодування m виводиться за допомогою Рівняння 4: , де є розміром в бітах одиниці декодування m. Якщо точка узгодження Типу I застосовується, 40 45 включає в себе підрахунок бітів одиниць NAL VCL і одиниць NAL даних заповнення. Якщо точка узгодження Типу II застосовується, включає в себе підрахунок всіх бітів потоків бітів Типу II для точок узгодження Типу II. Точки узгодження Типу I і Типу II знаходяться, як показано на фігурі С-1 Додатка С в HEVC WD8. [0143] Значення, , і обмежені наступним чином. Якщо вміст вибраної синтаксичної структури hrd_parameters() для AU, що містить одиницю декодування m, і попередньої AU в порядку декодування (в порядку декодування) відрізняються, планувальник доставки (HSS) вибирає значення із з числа значень , наданих у вибраній синтаксичній структурі hrd_parameters() для одиниці доступу, що містить одиницю декодування m, що приводить до або для одиниці доступу, що містить 19 UA 114004 C2 одиницю декодування m. Значення або відрізнятися від значення може або для значення з , яке використовувалося для попередньої одиниці доступу. Інакше, якщо вміст вибраної синтаксичної структури hrd_parameters() для двох одиниць AU є 5 однаковим, HSS продовжує працювати з і попередніми значеннями , . [0144] Коли HSS вибирає значення або , які відрізняються від таких з попередньої одиниці доступу, застосовується наступне. Змінна набуває сили у час 10 . Змінна набуває сили при деяких умовах. [0145] Якщо нове значення набуває більше, ніж старий розмір CPB, сили у час . Інакше, якщо нове значення менше ніж або дорівнює старому розміру CPB, нове значення 15 набуває сили під час видалення з CPB останньої одиниці декодування одиниці доступу, що містить одиницю декодування m. [0146] Коли SubPicCpbFlag дорівнює 1, початковий час надходження в CPB одиниці доступу n, 20 , встановлений в початковий час надходження в CPB першої одиниці декодування в одиниці доступу n. Кінцевий час надходження в CPB одиниці доступу n, , встановлений в кінцевий час надходження в CPB останньої одиниці декодування в одиниці доступу n. Коли SubPicCpbFlag дорівнює 0, кожна DU є AU, отже початковий і кінцевий час надходження в CPB одиниці доступу n є початковим і кінцевим часом надходження в CPB одиниці декодування n. [0147] Дане розкриття тепер звертається до опису роботи CPB 94 відносно тактування видалення одиниці декодування і декодування одиниць декодування. [0148] Змінні 25 дві 30 35 змінні встановлені наступним і використовуються для часів видалення DU. Ці чином. Якщо будь-яка з двох умов вірна, і встановлені, в повідомленні SEI періоду буферизації, в значення Initial_alt_cpb_removal_delay_delay[SchedSelldx] і Initial_alt_cpb_removal_delay_offset[SchedSelldx], відповідні NalHrdModeFlag, відповідно. Перша умова полягає в тому, що одиниця доступу 0 є одиницею доступу BLA, для якої закодована картинка має nal_unit_type, що дорівнює BLA_W_DLP або BLA_N_LP, і значення rap_cpb_params_present_flag повідомлення SEI періоду буферизації дорівнює 1. Друга умова полягає в тому, що DefaultInitCpbParamsFlag дорівнює 0. [0149] Якщо жодна з цих двох умов не вірна, і встановлені в значення Initial_cpb_removal_delay_delay[SchedSelldx] і Initial_cpb_removal_delay_offset[SchedSelldx], відповідні NalHrdModeFlag, відповідно, в асоційованому повідомленні SEI періоду буферизації, вибраному, як визначено в підпункті C.1 Додатка С в HEVC WD8. 40 45 [0150] Змінна , що належить до часу затримки видалення одиниці декодування m з CPB 94, може бути виведена наступним чином, коли sub_pic_cpb_params_present_flag дорівнює 1. Якщо sub_pic_cpb_params_in_pic_timing_sei_flag дорівнює 0, встановлена в du_spt_cpb_removal_delay в повідомленні SEI тактування субкартинок, асоційованому з одиницею декодування m. Повідомлення SEI тактування субкартинок може бути вибране, як задано в підпункті C.1 Додатка С в HEVC WD8. [0151] Якщо du_common_cpb_removal_delay_flag дорівнює 0, змінна встановлена в значення du_cpb_removal_delay_minus1[i]+1 для одиниці декодування m в повідомленні SEI тактування картинок, вибраному так, як визначено в підпункті C.1 Додатка С в 20 UA 114004 C2 5 10 15 HEVC WD8, асоційованому з одиницею доступу, яка містить одиницю декодування m. Значення i дорівнює 0 для першої num_nalus_in_du_minus1[0]+1 послідовної одиниці декодування в одиниці доступу, яка містить одиницю декодування m, 1 для подальшої num_nalus_in_du_minus1[1]+1 одиниці декодування в тій же самій одиниці доступу, 2 для подальших num_nalus_in_du_minus1[2]+1 одиниць декодування в тій же самій одиниці доступу, і т. д. [0152] Інакше, якщо ні sub_pic_cpb_params_present_flag не дорівнює 1, ні du_common_cpb_removal_delay_flag не дорівнює 0, встановлений в значення du_common_cpb_removal_delay_minus1+1 в повідомленні SEI тактування картинок, вибраному так, як визначено в підпункті C.1 Додатка С в HEVC WD8, асоційованому з одиницею доступу, яка містить одиницю декодування m. [0153] Номінальний час видалення одиниці доступу n з CPB 94 може також бути визначений наступним чином. Якщо одиниця доступу n є одиницею доступу 0 (тобто одиницею доступу, яка ініціалізує HRD), номінальний час видалення одиниці доступу 0 з CPB 94, Рівнянням 5: , визначений . [0154] Інакше, для одиниці доступу n, де n є ненульовим або не ініціалізований HRD, застосовується наступне. Коли одиниця доступу n є першою одиницею доступу періоду буферизації, яка не ініціалізує HRD, номінальний час видалення одиниці доступу n з CPB 94, 20 , визначений Рівнянням 6: , 25 де - номінальний час видалення першої одиниці доступу попереднього періоду буферизації, і au_cpd_removal_delay_minus1(n) є значенням au_cpd_removal_delay_plus1 в повідомленні SEI тактування картинок, вибраному, як задано в HEVC WD8, Додаток С, підпункт C.1, асоційованому з одиницею доступу n. Коли одиниця доступу n є першою одиницею доступу періоду буферизації, nb встановлене рівним n при номінальному часі видалення одиниці доступу n. Коли одиниця доступу n не є першою одиницею доступу періоду буферизації, 30 задається Рівнянням 6, де - номінальний час видалення першої одиниці доступу поточного періоду буферизації. [0155] Коли sub_pic_cpb_params_present_flag дорівнює 1, номінальний час видалення для того, щоб видалити одиницю декодування m з CPB 94, задається наступним чином, де номінальний час видалення одиниці доступу n. Якщо одиниця декодування m є останньою одиницею декодування в одиниці доступу n, номінальний час видалення одиниці декодування m 35 встановлений в . Таким чином, одиниця доступу і її остання одиниця декодування видаляються з CPB 94 в приблизно один і той же час. Інакше (тобто одиниця декодування m не є останньою одиницею декодування в одиниці доступу n), номінальний час видалення одиниці декодування m, , виводиться, як показано в Рівнянні 7, де номінальний час видалення одиниці доступу n. 40 . [0156] Час видалення одиниці доступу n з CPB 94 заданий наступним чином в Рівнянні 8, де і - кінцевий час надходження і номінальний час видалення, відповідно, останньої одиниці декодування в одиниці доступу n. 21 UA 114004 C2 . [0157] Коли SubPicCpbFlag дорівнює 1, час видалення одиниці декодування m з CPB 94 5 задається наступним чином. Якщо low_delay_hrd_flag дорівнює 0 або видалення одиниці декодування m задається Рівнянням 9: , час . Інакше, якщо одиниця декодування m не є останньою одиницею декодування одиниці доступу n, час видалення одиниці декодування m задається Рівнянням 10: 10 . Інакше, якщо одиниця декодування m є останньою одиницею декодування одиниці доступу n, час видалення одиниці декодування m задається Рівнянням 11: . 15 20 25 30 [0158] У деяких прикладах, коли low_delay_hrd_flag дорівнює 1 і , розмір одиниці декодування m, b(m), є настільки великим, що це запобігає видаленню в номінальний час видалення. [0159] Під час видалення з CPB одиниці декодування m миттєво декодується одиниця декодування. Картинку n розглядають як декодовану після того, як остання одиниця декодування картинки декодована. [0160] Нижченаведені таблиці ілюструють синтаксис і семантику, які можуть бути використані для реалізації зразкових способів, описаних в даному розкритті. Таблиця 1 забезпечує зразкові синтаксис і семантику для повідомлення SEI періоду буферизації. Таблиця 2 забезпечує зразкові синтаксис і семантику для повідомлення SEI тактування картинок. Функціональні можливості CPB 94 можуть бути визначені синтаксисом і семантикою повідомлень SEI. Наприклад, відеодекодер 30 витягує одиниці DU з CPB 94 на основі, щонайменше частково, повідомлень SEI тактування картинок і періоду буферизації. [0161] Повідомлення додаткової інформації розширення (SEI) періоду буферизації надає інформацію початкової затримки видалення з CPB і початкового зміщення затримки видалення з CPB. Синтаксис повідомлення SEI періоду буферизації може бути тим же самим, як синтаксис повідомлення SEI періоду буферизації в попередній заявці на патент США № 61/705,102, поданій 24 вересня 2012, і семантики змінені наступним чином. Синтаксис повідомлення SEI періоду буферизації наданий в Таблиці 1, показаній нижче. 22 UA 114004 C2 Таблиця 1 Синтаксис повідомлення SEI періоду буферизації buffering_period(payloadSize) { Дескриптор seq_parameter_set_id ue(v) applicable_operation_points() if(!sub_pic_cpb_params_present_flag) rap_cpb_params_present_flag u(1) if(NalHrdBpPresentFlag) { for( SchedSelIdx=0; SchedSelIdx