Кодування відео множинних видів

 

[0001] Даний розкриття просить пріоритет попередньої заявки на патент США № 61/512,771 поданої 28 липня 2011, вміст якої повністю включено допомогою посилання.

ОБЛАСТЬ ТЕХНІКИ

[0002] Даний розкриття ставиться до кодування відео.

РІВЕНЬ ТЕХНІКИ

[0003] Цифрові можливості відео можуть бути включені в широкий діапазон пристроїв, включаючи цифрові телевізори, цифрові системи прямого мовлення, бездротові системи мовлення, персональні цифрові помічники (PDA), портативні або настільні комп'ютери, планшетні комп'ютери, зчитувачі електронних книг, цифрові камери, цифрові пристрої реєстрації, цифрові медіа плеєри, відео та ігрові пристрої, пульти відеоігор, стільникові або супутникові радіотелефони, так звані "смартфони", пристрої відео організації телеконференцій, пристрої потокової передачі відео і т. п. Цифрові відео пристрої реалізують способи стиснення відео, такі як описані в стандартах, визначених за допомогою MPEG-2, MPEG-4, ITU-T H. 263 або ITU-T H. 264/MPEG-4 Part 10, Advanced Video Coding (AVC), стандарту високоефективного кодування відео (HEVC), що розвивається в даний час, і розширення таких стандартів. Відео пристрої можуть передавати, приймати, ко�атія відео.

[0004] Способи стиснення відео виконують просторове (всередині картинки) передбачення та/або тимчасове (між картинками) передбачення, щоб зменшити або видалити надмірність, притаманну відео послідовності. Для заснованого на блоках кодування відео вирізка відео (тобто, відео кадр або частину відео кадру) може бути розділена на відео блоки, які можуть згадуватися як блоки дерева, одиниці кодування (CU) та/або вузли кодування. Відео блоки у внутрішньо кодованої (I) вирізці картинки кодують, використовуючи просторове прогноз щодо опорних вибірок в сусідніх блоках в тій же самій картинці. Відео блоки під зовні кодованої (P або B) вирізці картинки можуть використовувати просторове прогноз щодо опорних вибірок в сусідніх блоках в тій же самій картинці або тимчасове прогноз щодо опорних вибірок в інших опорних картинках.

[0005] Просторове або часове передбачення призводить до предсказивающему блоку для блоку, який повинен бути закодований. Залишкові дані представляють піксельні різниці між початковим блоком, який повинен бути закодований, і пророкує блоком. Зовні кодований блок блок, і залишковим даними, вказує різниця між закодованим блоком і пророкує блоком. Внутрішньо кодований блок кодують відповідно до режиму внутрішнього кодування і залишковим даними. Для подальшого стиснення залишкові дані можуть бути перетворені з піксельної області в область перетворення, приводячи до залишковим коефіцієнтів перетворення, які потім можуть квантоваться. Квантовані коефіцієнти перетворення, спочатку розміщені в двовимірному масиві, можуть бути скановані, щоб сформувати одновимірний вектор коефіцієнтів перетворення, і энтропийное кодування може бути застосоване, щоб досягти ще більшою мірою стиснення.

СУТНІСТЬ ВИНАХОДУ

[0006] В цілому даний розкриття описує методи кодування відео даних. Наприклад, даний розкриття описує способи для виконання кодування відео множинних видів (MVC), і для MVC-розширення стандарту кодування відео HEVC, що знаходиться в даний час у розвитку. Таким чином, MVC є методом кодування відео для інкапсуляції множинних видів відео даних. Кожен вид може відповідати різної перспективі, або кутку, під яким були захоплені соотвня абстракції мережі (NAL) MVC, наборів параметрів MVC, і т. п.

[0007] В одному прикладі аспекти цього розкриття відносяться до способу декодування відео даних, який включає в себе отримання, закодованого потоку бітів, однієї або більше одиниць рівня абстракції мережі (NAL) для кожного компонента виду з безлічі компонентів виду закодованих відео даних, при цьому кожен компонент виду з безлічі компонентів виду відповідає загальному тимчасового розташування, і при цьому одна чи більше одиниць NAL інкапсулюють принаймні частина закодованих відео даних для відповідних компонентів виду і включають в себе інформацію, що вказує порядок декодування відповідних компонентів виду; отримання інформації, з закодованого потоку бітів і окремою від одиниць NAL, що вказує відносини між ідентифікаторами виду для цих видів і порядок декодування компонентів виду; і декодування закодованих відео даних з безлічі компонентів виду в порядку декодування на підставі прийнятої інформації.

[0008] В іншому прикладі аспекти цього розкриття відносяться до пристрою для декодування відео даних, яке включає в себе один або більше процесорів, сконфігурованих, щоб пента виду з безлічі компонентів виду закодованих відео даних, при цьому кожен компонент виду з безлічі компонентів виду відповідає загальному тимчасового розташування, і в якому одна або більше одиниць NAL інкапсулюють принаймні частина закодованих відео даних для відповідних компонентів виду і включають в себе інформацію, що вказує порядок декодування відповідних компонентів виду; отримати інформацію, закодованого потоку бітів і окрему від одиниць NAL, що вказує відносини між ідентифікаторами виду для цих видів і порядок декодування компонентів виду; і розшифрувати закодовані відео даних з безлічі компонентів виду в порядку декодування на підставі прийнятої інформації.

[0009] В іншому прикладі аспекти цього розкриття відносяться до пристрою для декодування відео даних, яке включає в себе засіб для отримання, закодованого потоку бітів, однієї або більше одиниць рівня абстракції мережі (NAL) для кожного компонента виду з безлічі компонентів виду закодованих відео даних, при цьому кожен компонент виду з безлічі компонентів виду відповідає загальному тимчасового розташування, і в якому одна або більше одиниць NAL інкапсулюють принаймні частина закодованих�ования відповідних компонентів виду; засіб для отримання інформації, закодованого потоку бітів і окремою від одиниць NAL, що вказує відносини між ідентифікаторами виду для цих видів і порядок декодування компонентів виду; і засіб для декодування закодованих відео даних з безлічі компонентів виду в порядку декодування на підставі прийнятої інформації.

[0010] В іншому прикладі аспекти цього розкриття відносяться до невременному считиваемому комп'ютером запам'ятовуючого носієві, що має інструкції, збережені на ньому, які, коли виконуються, змушують один або більше процесорів отримувати, закодованого потоку бітів, одну або більше одиниць рівня абстракції мережі (NAL) для кожного компонента виду з безлічі компонентів виду закодованих відео даних, при цьому кожен компонент виду з безлічі компонентів виду відповідає загальному тимчасового розташування, і при цьому одна чи більше одиниць NAL інкапсулюють принаймні частина закодованих відео даних для відповідних компонентів виду і включають в себе інформацію, що вказує порядок декодування відповідних компонентів виду; отримувати інформацію, закодованого потоку бітів і окрему від одиниць NAL, указ�одировать закодовані відео дані з безлічі компонентів виду в порядку декодування на підставі прийнятої інформації.

[0011] В іншому прикладі аспекти цього розкриття відносяться до способу кодування відео даних, який включає в себе кодування відео даних для безлічі компонентів виду для відповідних видів відео даних, в якому кожен з безлічі компонентів виду відповідає загальному тимчасового розташування; формування, в якості частини закодованого потоку бітів, однієї або більше одиниць рівня абстракції мережі (NAL) для закодованих відео даних кожного з компонентів виду таким чином, що одиниці NAL включають в себе інформацію, що вказує порядок декодування відео даних відповідних компонентів виду, і інкапсулюють принаймні частина закодованих відео даних для відповідних компонентів виду; та надання інформації у закодованому потоці бітів, окремої від одиниць NAL, що вказує відносини між ідентифікаторами виду для цих видів і порядок декодування компонентів виду.

[0012] В іншому прикладі аспекти цього розкриття відносяться до пристрою для кодування відео даних, причому пристрій містить один або більше процесорів, сконфігурованих, щоб кодувати відео дані для безлічі компонентів виду для відповідних виднию; формувати, як частини закодованого потоку бітів, одну або більше одиниць рівня абстракції мережі (NAL) для закодованих відео даних кожного з компонентів виду таким чином, що одиниці NAL включають в себе інформацію, що вказує порядок декодування відео даних відповідних компонентів виду, і інкапсулюють принаймні частина закодованих відео даних для відповідних компонентів виду; і надавати інформацію в закодованому потоці бітів, окрему від одиниць NAL, що вказує відносини між ідентифікаторами виду для цих видів і порядок декодування компонентів виду.

[0013] В іншому прикладі аспекти цього розкриття відносяться до пристрою для кодування відео даних, яке включає в себе засіб для кодування відео даних для безлічі компонентів виду для відповідних видів відео даних, в якому кожен з безлічі компонентів виду відповідає загальному тимчасового розташування; засіб для формування, в якості частини закодованого потоку бітів, однієї або більше одиниць рівня абстракції мережі (NAL) для закодованих відео даних кожного з компонентів виду таким чином, що одиниці NAL включають в себе інформацію, указивающть закодованих відео даних для відповідних компонентів виду; і засіб для надання інформації у закодованому потоці бітів, окремої від одиниць NAL, що вказує відносини між ідентифікаторами виду для цих видів і порядок декодування компонентів виду.

[0014] В іншому прикладі аспекти цього розкриття відносяться до невременному считиваемому комп'ютером запам'ятовуючого носієві, що має інструкції, збережені на ньому, які, коли виконуються, змушують один або більше процесорів кодувати відео дані для безлічі компонентів виду для відповідних видів відео даних, в якому кожен з безлічі компонентів виду відповідає загальному тимчасового розташування; формувати, як частини закодованого потоку бітів, одну або більше одиниць рівня абстракції мережі (NAL) для закодованих відео даних кожного з компонентів виду таким чином, що одиниці NAL включають в себе інформацію, вказує порядок декодування відео даних відповідних компонентів виду, і інкапсулюють принаймні частина закодованих відео даних для відповідних компонентів виду; і надавати інформацію в закодованому потоці бітів, окрему від одиниць NAL, що вказує відносини між ідентифікаторами виду для цих видів�до способу декодування відео даних, який включає в себе отримання, закодованого потоку бітів і для будь-якого компонента виду першого виду інформації опорного виду, вказує один або більше опорних видів для передбачення компонентів виду першого виду; включення, для декодування першого компонента виду в одиниці доступу і в першому виді, одного або більше опорних кандидатів у списку опорних картинок, в якому один або більше кандидатів опорних містять компоненти виду в одиниці доступу і в опорних видах, зазначених інформацією опорного виду, при цьому кількість опорних кандидатів дорівнює кількості опорних видів; і декодування першого компонента виду на підставі одного або більше опорних кандидатів у списку опорних картинок.

[0016] В іншому прикладі аспекти цього розкриття відносяться до пристрою для декодування відео даних, причому пристрій містить один або більше процесорів, сконфігурованих, щоб отримати, закодованого потоку бітів і для будь-якого компонента виду першого виду, інформацію опорного виду, вказує один або більше опорних видів для передбачення компонентів виду першого виду; включити для декодування першого компонента виду в одиниці доступу і в першому виді, одного і�мпоненти виду в одиниці доступу і в опорних видах, зазначених інформацією опорного виду, при цьому кількість опорних кандидатів дорівнює кількості опорних видів; і декодувати перший компонент виду на підставі одного або більше опорних кандидатів у списку опорних картинок.

[0017] В іншому прикладі аспекти цього розкриття відносяться до пристрою для декодування відео даних, причому пристрій містить засіб для отримання, закодованого потоку бітів і для будь-якого компонента виду першого виду інформації опорного виду, вказує один або більше опорних видів для передбачення компонентів виду першого виду; засіб для вмикання, для декодування першого компонента виду в одиниці доступу і в першому виді, одного або більше опорних кандидатів у список опорних картинок, в якому один або більше кандидатів опорних містять компоненти виду в одиниці доступу і в опорних видах, зазначених інформацією опорного виду, при цьому кількість опорних кандидатів дорівнює кількості опорних видів; і засіб для декодування першого компонента виду на підставі одного або більше опорних кандидатів у списку опорних картинок.

[0018] В іншому прикладі аспекти цього розкриття відносяться до невременному считиваемому комп'ютером запомлее процесорів отримувати, з закодованого потоку бітів і для будь-якого компонента виду першого виду, інформацію опорного виду, вказує один або більше опорних видів для передбачення компонентів виду першого виду; включати, для декодування першого компонента виду в одиниці доступу і в першому виді, один або більше опорних кандидатів у список опорних картинок, при цьому один або більше кандидатів опорних містять компоненти виду в одиниці доступу і в опорних видах, зазначених інформацією опорного виду, при цьому кількість опорних кандидатів дорівнює кількості опорних видів; і декодувати перший компонент виду на підставі одного або більше опорних кандидатів у списку опорних картинок.

[0019] В іншому прикладі аспекти цього розкриття відносяться до способу кодування відео даних, що містить визначення, для будь-якого компонента виду першого виду інформації опорного виду, вказує один або більше опорних видів для передбачення компонентів виду першого виду; включення, для кодування першого компонента виду в одиниці доступу і в першому виді, одного або більше опорних кандидатів у список опорних картинок, при цьому один або більше кандидатів опорних містять компоненти виду в одиниці доступу і в опорних ві�дов; кодування першого компонента виду на підставі одного або більше опорних кандидатів у списку опорних картинок; забезпечення закодованого першого компонента виду з певною інформацією опорного виду в закодованому потоці бітів.

[0020] В іншому прикладі аспекти цього розкриття відносяться до пристрою для кодування відео даних, що містить один або більше процесорів, сконфігурованих, щоб визначити, для будь-якого компонента виду першого виду, інформацію опорного виду, вказує один або більше опорних видів для передбачення компонентів виду першого виду; включити, для кодування першого компонента виду в одиниці доступу і в першому виді, один або більше опорних кандидатів у список опорних картинок, в якому один або більше кандидатів опорних містять компоненти виду в одиниці доступу і в опорних видах, зазначених інформацією опорного виду, при цьому кількість опорних кандидатів дорівнює кількості опорних видів; кодувати перший компонент виду на підставі одного або більше опорних кандидатів у списку опорних картинок; і надавати кодований перший компонент виду з певною опорною інформацією виду в закодований потік бітів.

[0021] В іншому псодержит засіб для визначення, для будь-якого компонента виду першого виду інформації опорного виду, вказує один або більше опорних видів для передбачення компонентів виду першого виду; засіб для вмикання, для кодування першого компонента виду в одиниці доступу і в першому виді, одного або більше опорних кандидатів у списку опорних картинок, в якому один або більше кандидатів опорних містять компоненти виду в одиниці доступу і в опорних видах, зазначених інформацією опорного виду, при цьому кількість опорних кандидатів дорівнює кількості опорних видів; засіб для кодування першого компонента виду на підставі одного або більше опорних кандидатів у списку опорних картинок; і засіб для надання закодованого першого компонента виду з певною опорною інформацією виду в закодованому потоці бітів.

[0022] В іншому прикладі аспекти цього розкриття відносяться до невременному считиваемому комп'ютером запам'ятовуючого носієві, що має інструкції, збережені на ньому, які, коли виконуються, змушують один або більше процесорів визначати, для будь-якого компонента виду першого виду, інформацію опорного виду, вказує один або більше опорних видів для передбачення компонентів виду припинення її створення опорних кандидатів у список опорних картинок, при цьому один або більше кандидатів опорних містять компоненти виду в одиниці доступу і в опорних видах, зазначених інформацією опорного виду, при цьому кількість опорних кандидатів дорівнює кількості опорних видів; кодувати перший компонент виду на підставі одного або більше опорних кандидатів у списку опорних картинок; і надавати кодований перший компонент виду з певною опорною інформацією виду в закодованому потоці бітів.

[0023] Деталі одного або більше аспектів розкриття сформульовані в доданих кресленнях і описах нижче. Інші ознаки, об'єкти і переваги способів, описаних у цьому розкритті, будуть очевидні з опису та креслень, і з формули винаходу.

КОРОТКИЙ ОПИС КРЕСЛЕНЬ

[0024] ФІГ. 1 є блок-схема, що ілюструє приблизну систему кодування і декодування відео, яка може використовувати способи, описані в цьому розкритті.

[0025] ФІГ. 2 є блок-схема, що ілюструє зразковий відео кодер, який може реалізувати способи, описані в цьому розкритті.

[0026] ФІГ. 3 є блок-схема, що ілюструє приблизний декодер відео, який може реалізувати способи, описані в цьому розкритті.

[002 з численними видами (MVC).

[0028] ФІГ. 5A є концептуальною діаграму, що ілюструє приклад структури потоку бітів, яка може використовуватися в реалізації одного або більше способів цього розкриття.

[0029] ФІГ. 5B є концептуальною діаграму, що ілюструє приклад виду, який може бути включений у структуру потоку бітів згідно ФІГ. 5A.

[0030] ФІГ. 5C є концептуальною діаграму, що ілюструє приклад одиниці рівня абстракції мережі (NAL), який може бути включений у структуру потоку бітів на фіг. 5A.

[0031] ФІГ. 5D є концептуальною діаграму, що ілюструє інший приклад одиниці NAL, яка може бути включена в структуру потоку бітів згідно ФІГ. 5A.

[0032] ФІГ. 6 є блок-схема, що ілюструє приблизний спосіб кодування потоку бітів множинних видів.

[0033] ФІГ. 7 є блок-схема, що ілюструє приблизний спосіб декодування потоку бітів множинних видів.

[0034] ФІГ. 8 є блок-схема, що ілюструє приблизний спосіб кодування потоку бітів множинних видів.

[0035] ФІГ. 9 є блок-схема, що ілюструє приблизний спосіб декодування потоку бітів множинних видів.

ДЕТАЛЬНИЙ ОПИС

[0036] Згідно з деякими систем кодиточности у відео послідовності, щоб досягти стиснення даних. У цьому випадку може генеруватися вектор руху, який ідентифікує пророкує блок відео даних, наприклад, блок з іншої картинки або відео вирізки, яка може бути використана для передбачення значення поточного кодованого відео блоку. Значення предсказивающего відео блоку віднімають із значень поточного відео блоку, щоб сформувати блок залишкових даних. Інформація руху (наприклад, вектор руху, індекси вектора руху, напрями передбачення, або інша інформація) передається від відео кодера до відео декодера, поряд із залишковими даними. Декодер може визначити той же пророкує блок (на підставі вектора руху) і відновити закодований відео блок, комбінуючи залишкові дані з даними предсказивающего блоку.

[0037] Кодування відео множинних видів (MVC) є стандартом кодування відео для інкапсуляції множинних видів відео даних. Зазвичай кожен вид відповідає різній перспективі, або кутку, під яким були захоплені відповідні відео дані загальної сцени. Кодовані види можуть використовуватися для тривимірного (3D) відео даних. Наприклад, два види (наприклад, вльзуя різні поляризації світла, і глядач може носити пасивні поляризовані окуляри таким чином, що кожен з очей глядача приймає відповідний з видів. Альтернативно, глядач може носити активні окуляри, які закривають кожне око незалежно, і відображення може швидко чергуватися між зображеннями кожного ока в синхронізації з окулярами.

[0038] MVC конкретна картинка конкретного виду згадується як компонент виду. Тобто, компонент виду деякого виду відповідає конкретному тимчасовому примірнику виду. Відео з численними видами може містити відносно велику величину між видами статистичних залежностей, коли всі камери, використані для захоплення даних численних видів, захоплюють одну і ту ж сцену з різних точок огляду. Такі залежності можуть використовуватися для об'єднаного тимчасового та/або передбачення між видами, де зображення не тільки предсказиваются від сусідніх у часі зображень, але також і від відповідних зображень від інших видів. Таким чином, передбачення між видами може бути виконано серед картинок в одній і тій же одиниці доступу (тобто, в межах одного і того ж моменту часу).

[0039] Передбачення між видами зви�про того, щоб використовувати вектори "руху" для передбачення, пророкування між видами використовує вектори "зміщення", які концептуально подібні векторів руху, але описують зміщення, а не рух. Потенційні міжвидові опорні посилання сигналізуються в розширенні MVC набору параметрів послідовності (SPS) і можуть бути модифіковані процесом побудови списку опорних зображень, який дозволяє гнучкий порядок зовнішнього передбачення або опорних посилань передбачення між видами.

[0040] Відео дані, включаючи дані відео MVC, можуть бути організовані в одиниці рівня абстракції мережі (NAL), які забезпечують "дружнє для мережі" уявлення відео, щоб забезпечити додатки, такі як відео телефонія, зберігання, мовлення або потокова передача. Наприклад, відео кодер зазвичай кодує кожну картинку відео даних як одну або більше незалежно декодуємих вирізок. Вирізки можуть бути упаковані в одиниці NAL для передачі через мережу. Одиниці NAL, що включають у себе дані рівня кодування відео (VCL), можуть включати в себе дані для зображення або дані для вирізки картинки. Наприклад, одиниці NAL можуть включати в себе інформацію синтаксису, таку як значення шаблону кодированногвирезка, блок, або послідовність), або іншу інформацію.

[0041] Кожна одиниця NAL включає в себе заголовок, який ідентифікує тип даних, що зберігаються в одиниці NAL. Приблизний заголовок одиниці NAL MVC може включати в себе елементи синтаксису, що вказують ідентифікатор виду для виду, до якого належить одиниця NAL, належить одиниця NAL так званої картинці з прив'язкою, яка може використовуватися як точка довільного доступу (для посилання допомогою інших компонентів виду), використовується одиниця NAL для передбачення між видами для одиниць NAL в інших видах, і безліч іншої інформації. Як описано тут, картинка з прив'язкою може зазвичай відповідати картинці довільного доступу, і такі терміни можуть бути використані як взаємозамінні. Таким чином, "довільний доступ" зазвичай відноситься до акта початку процесу декодування потоку бітів у точці, відмінною від початку потоку. Картинка довільного доступу зазвичай відноситься до картинці, яка містить тільки внутрішньо кодовані вирізки (I-вирізки). Кодовані картинки, які слідують за картинкою довільного доступу як в порядку декодування так і порядку виведення, не предсказиваются з картинок, пр одиниця доступу може включати в себе всі компоненти виду конкретного моменту часу. Конкретний компонент виду включає в себе всі одиниці NAL конкретного виду в конкретний момент часу. Одиниця NAL MVC може містити однобайтний заголовок одиниці NAL (включаючи тип одиниці NAL) і може також включати в себе розширення заголовка одиниці NAL MVC.

[0043] В той час як H. 264/AVC включає в себе підтримку MVC, поточне розширення MVC до H. 264/AVC може містити деякі неефективності щодо інших стандартів кодування відео. Крім того, як описано більш докладно нижче, прямий імпорт MVC з H. 264/AVC в інші стандарти кодування, таких як майбутній стандарт HEVC, може бути не виконаємо. Способи справжнього розкриття зазвичай стосуються формування належать до MVC одиниць NAL, що належать до MVC наборів параметрів і т. п. Деякі способи розкриття цього можуть забезпечити ефективне MVC кодування для майбутнього стандарту HEVC.

[0044] ФІГ. 1 є блок-схема, що ілюструє приблизну 10 систему кодування і декодування відео, яка може використовувати способи для передбачення вектора руху при кодуванні множинних видів. Як показано на фіг. 1, система 10 включає в себе пристрій-джерело 12, яке видає закодовані відео дані, які повинні бути декодування�ойству 14 призначення через зчитувальний комп'ютером носій 16. Пристрій-джерело 12 і пристрій 14 призначення можуть містити будь-які із широкого діапазону пристроїв, включаючи настільні комп'ютери, портативні комп'ютери (тобто, ноутбуки), планшетні комп'ютери, телевізійні приставки, телефонні трубки, такі як так звані "смартфони", так звані "інтелектуальні" клавіатури, телевізори, камери, пристрої відображення, цифрові медіа плеєри, пульти відеоігор, пристрій потокової передачі відео, або подібні. У деяких випадках пристрій-джерело 12 і пристрій 14 призначення можуть бути обладнані для бездротового зв'язку.

[0045] Пристрій 14 призначення може прийняти закодовані відео дані, які повинні бути декодованими, через зчитувальний комп'ютером носій 16. Зчитаний комп'ютером носій 16 може містити будь-який тип носія або пристрою, здатного до переміщення закодованих відео даних від пристрою-джерела 12 до пристрою 14 призначення. В одному прикладі зчитаний комп'ютером носій 16 може містити комунікаційний носій, щоб дозволити вихідного пристрою 12 передати закодовані відео дані безпосередньо до пристрою 14 призначення в реальному часі.

[0046] Закодовані відео та�стройству 14 призначення. Комунікаційний носій може містити будь безпровідний чи провідний комунікаційний носій, такий як радіочастотного (RF, РЧ) спектру або одна або більше фізичних ліній передачі. Комунікаційний носій може бути частиною заснованої на пакетної передачі мережі, такий як локальна мережа, регіональна мережа, або глобальна мережа, така як Інтернет. Комунікаційний носій може включати в себе маршрутизатори, перемикачі, базові станції, або будь-яке інше обладнання, яке може бути корисним, щоб полегшити зв'язок від пристрою-джерела 12 до пристрою 14 призначення.

[0047] У деяких прикладах закодовані дані можуть бути виведені з інтерфейсу 22 виведення на пристрій зберігання. Точно так само, до закодованих даних можна отримати доступ до пристрою зберігання допомогою інтерфейсу вводу. Пристрій зберігання може включати в себе будь-який з безлічі розподілених або локально доступних носіїв зберігання даних, таких як накопичувач на жорстких дисках, диски Blu-ray, DVD, CD-ROM, флеш-пам'ять, енергозалежна або енергонезалежна пам'ять, або будь-які інші відповідні цифрові носії зберігання для того, щоб зберігати закодовані відео дані. Надалі прим�ения, яке може зберігати кодоване відео, що генерується пристроєм-джерелом 12.

[0048] Пристрій 14 призначення може отримати доступ до збережених відео даних від пристрою зберігання через потокову передачу або завантаження. Файловий сервер може бути будь-яким типом сервера, здатного до того, щоб зберігати закодовані відео дані і передавати ці кодовані відео дані до пристрою 14 призначення. Зразкові файлові сервери включають в себе веб-сервер (наприклад, для вебсайту), FTP сервер, пристрої мережевих сховищ даних (NAS), або локальний дисковий накопичувач. Пристрій 14 призначення може отримати доступ до кодованих відео даних через будь-яке стандартне з'єднання даних, включаючи інтернет-з'єднання. Воно може включати в себе бездротовий канал (наприклад, з'єднання Wi-Fi), дротове з'єднання (наприклад, DSL, кабельний модем, тощо), або комбінацію обох, яке є відповідним для того, щоб отримати доступ до закодованим відео даних, що зберігаються на файловому сервері. Передача кодованих відео даних від пристрою зберігання може бути потоковою передачею, передачею завантаження або комбінацією обох.

[0049] Способи розкриття цього не обов'язково обмежені без�ржку будь-якого з безлічі мультимедійних додатків, таких як радіомовлення телевізійних передач, передач кабельного телебачення, передач супутникового телебачення, потокових передач відео з Інтернету, такі як динамічна адаптивна потокова передача по HTTP (DASH), цифрове відео, яке закодовано на носії зберігання даних, декодування цифрового відео, що зберігається на носії зберігання даних або інших додатків. В деяких прикладах система 10 може бути налаштована підтримувати односторонню або двосторонню передачу відео, щоб підтримувати програми, такі як потокова передача відео, відтворення відео, мовлення відео, та/або відео телефонія.

[0050] У прикладі згідно ФІГ. 1 пристрій-джерело 12 включає в себе відео джерело 18, відео кодер 20 і інтерфейс 22 висновки. Пристрій 14 призначення включає в себе інтерфейс 28 введення, відео декодер 30, і пристрій 32 відображення. У відповідності з цим розкриттям відео кодер 20 пристрої-джерела 12 може бути налаштований, щоб застосувати способи для передбачення вектора руху при кодуванні множинних видів. В інших прикладах пристрій-джерело і пристрій призначення можуть включати в себе інші компоненти або компонування. Наприклад, устгично, пристрій 14 призначення може взаємодіяти із зовнішнім пристроєм відображення, замість включення інтегрованого пристрої відображення.

[0051] Ілюстрована система 10 згідно ФІГ. 1 є просто одним прикладом. Способи для передбачення вектора руху при кодуванні множинних видів можуть бути виконані будь-яким цифровим пристроєм кодування та/або декодування відео. Хоча зазвичай способи справжнього розкриття виконуються пристроєм кодування відео, способи можуть бути виконані відео кодером/декодером, типово званим як "кодек". Крім того, способи розкриття цього можуть бути виконані препроцесором відео. Пристрій-джерело 12 і пристрій 14 призначення є просто прикладами таких пристроїв кодування, у яких пристрій-джерело 12 генерує закодовані відео дані для передачі до пристрою 14 призначення. В деяких прикладах пристрою 12, 14 можуть працювати по суті симетричним способом таким чином, що кожне з пристроїв 12, 14 включають в себе компоненти кодування і декодування відео. Отже, система 10 може підтримувати односторонню або двосторонню передачу відео між відео пристроями 12, 14, написточник 18 пристрої-джерела 12 може включати в себе пристрій захоплення відео, таке як відео камера, відео архів, що містить раніше захоплене відео, та/або інтерфейс подачі відео, щоб приймати відео від постачальника відео контенту. В якості подальшої альтернативи, відео джерело 18 може генерувати засновані на комп'ютерній графіці дані в якості вихідного відео або комбінацію живого відео, які заархівовані відео, і генерується комп'ютером відео. У деяких випадках якщо відео джерело 18 є відео камерою, пристрій-джерело 12 і пристрій 14 призначення можуть сформувати так звані камерофони або відео телефони. Як згадано вище, однак, способи, описані в цьому розкритті, можуть бути застосовними до кодування відео в цілому і можуть бути застосовані до безпроводових та/або дротовим додатками. У кожному разі захоплене, попередньо захоплене, або генерується комп'ютером відео може бути закодовано відео кодером 20. Закодована відео інформація може бути виведена інтерфейсом 22 виведення на зчитувальний комп'ютером носій 16.

[0053] Зчитаний комп'ютером носій 16 може включати в себе тимчасові носії, такі як бездротовий мовлення або передача провідної мережі, або носії зберігання (тобто, невременни інший зчитаний комп'ютером носій. В деяких прикладах web-сервер (не показаний) може прийняти закодовані відео дані від пристрою-джерела 12 і видати закодовані відео дані пристрою 14 призначення, наприклад, з допомогою передачі. Точно так само обчислювальний пристрій засоби виробництва носіїв, таких як засіб штампування дисків, може прийняти закодовані відео дані від пристрою-джерела 12 і виробляти диск, що містить закодовані відео дані. Тому, зчитаний комп'ютером носій 16, як можна розуміти, включає в себе один або більше прочитуваних комп'ютером носіїв різних форм, у різних прикладах.

[0054] Інтерфейс 28 вводу з пристрою 14 призначення приймає інформацію від считиваемого комп'ютером носія 16. Інформація считиваемого комп'ютером носія 16 може включати в себе інформацію синтаксису, визначену відео кодером 20, яка також використовується відео декодером 30, яка включає в себе елементи синтаксису, які описують характеристики та/або обробку блоків та інших закодованих одиниць, наприклад, GOP. Пристрій 32 відображення відображає декодированние відео дані користувачу, і може містити будь-яку з безлічі пристроїв відображення, такиѵских світлодіодах (OLED), або інший тип пристрою відображення.

[0055] Відео кодер 20 і відео декодер 30 кожен може бути реалізований як будь-яка з безлічі відповідних схем кодера або декодера, як застосовно, таких як один або декілька мікропроцесорів, цифрових сигнальних процесорів (DSPs), спеціалізованих інтегральних схем (ASIC), програмованих користувачем вентильних матриць (FPGA), дискретної логіки, програмного забезпечення, апаратного забезпечення, програмно-апаратних засобів або будь-яких їх комбінацій. Кожен з відео кодера 20 і відео декодера 30 може бути включений в один або більше кодерів або декодерів, кожний з яких може бути інтегрованим як частина об'єднаного кодера/декодера (кодек) відео. Пристрій, що включає в себе відео кодер 20 і/або відео декодер 30, може містити інтегральну схему, мікропроцесор, і/або пристрій бездротового зв'язку, таке як стільниковий телефон.

[0056] Хоча не показано на фіг. 1, в деяких аспектах відео кодер 20 і відео декодер 30 можуть інтегруватися з аудіо кодером і декодером, і можуть включати в себе відповідні блоки MUX-DEMUX (мультиплексорів-демультиплексоров), або інше апаратне забезпечення і програмне забезпечення, щоб виконувати кодування як тствовать протоколу мультиплексора ITU H. 223, або іншими протоколами, таким як протокол дейтаграм користувача UDP).

[0057] У прикладі, показаному на фіг. 1, система 10 також включає в себе сервер/мережа 34 доставки контенту, має маршрутизатор 36. В деяких прикладах пристрій-джерело 12 може зв'язуватися з сервером/мережею 34 доставки контенту через безліч бездротових і/або дротяних передач або запам'ятовуючих носіїв, як описано вище. Крім того, в той час як показано окремими у прикладі на ФІГ. 1, в деяких прикладах, пристрій-джерело 12 і сервер/мережа 34 доставки контенту містять одне і те ж пристрій. Сервер/мережа 34 доставки контенту може зберігати одну або більше версій закодованих відео даних (від відео кодера 20 пристрої-джерела 12), і може зробити такі закодовані відео дані доступними для доступу для пристрою 14 призначення і відео декодера 30. В деяких прикладах маршрутизатор 36 може бути відповідальним за видачу закодованих відео даних пристрою 14 призначення в необхідному форматі.

[0058] Відео кодер 20 і відео декодер 30 можуть працювати згідно стандарту стиснення відео, такого як стандарт високоефективного кодування відео (HEVC), що знаходиться зараз в розвитку, і можуть відповідати Тестово�ність стандартів або стандартів промисловості, таким як стандарт ITU-T H. 264, альтернативно званий MPEG-4 Part 10, Advanced Video Coding (AVC), або розширень таких стандартів. Способи розкриття цього, однак, не обмежені жодним конкретним стандартом кодування. Інші приклади включають в себе MPEG-2, ITU-T H. 263.

[0059] Стандарт ITU-T H. 264/MPEG-4 (AVC) був сформульований Групою Експертів з Кодування відео ITU-T (VCEG) разом з Групою експертів по рухомих зображень ISO/IEC (MPEG) як продукт колективного товариства, відомого як Об'єднана Команда Відео (JVT). У деяких аспектах способи, описані в цьому розкритті, можуть бути застосовані до пристроїв, які зазвичай відповідають стандарту H. 264. Стандарт H. 264 описаний в рекомендації H. 264 ITU-T, Вдосконаленому відео кодування для родових аудіовізуальних послуг, Групою по вивченню ITU-T, і датований березнем 2005, який може бути згаданий тут як стандарт H. 264 або специфікація H. 264, або стандарт або специфікація H. 264/AVC. Об'єднана Відео Команда (JVT) продовжує працювати над розширеннями до H. 264/MPEG-4 AVC.

[0060] JCT-VC працює над розвитком стандарту HEVC. Зусилля по стандартизації HEVC засновані на розвивається моделі пристрою кодування відео, званої Тестова Модель HEVC (HM). HM передбачає кілька�єр, ITU-T H. 264/AVC. Наприклад, тоді як H. 264 забезпечує дев'ять режимів кодування з внутрішнім пророкуванням, HM забезпечує цілих тридцять три режими кодування з внутрішнім пророкуванням.

[0061] Зазвичай робоча модель HM описує, що відео картинка може бути розділена на послідовність блоків дерева або найбільших одиниць кодування (LCU), які включають в себе вибірки як яскравості так і кольоровості. Дані синтаксису в межах потоку бітів можуть визначити розмір для LCU, яка є найбільшою одиницею кодування в термінах кількості пікселів. Вирізка включає в себе багато послідовні блоки дерева в порядку кодування. Картинка може бути розділена на одну або більше вирізок. Кожен блок дерева може бути поділений в одиниці кодування (CUs) згідно квадродереву. В цілому структура даних квадродерева включає в себе один вузол для кожної CU, з кореневим вузлом, відповідним блоку дерева. Якщо CU розділена на чотири суб-CU, вузол, відповідний цієї CU, включає в себе чотири листових вузла, кожен з яких відповідає одній із суб-CU.

[0062] Кожен вузол структури даних квадродерева може забезпечити дані синтаксису для відповідної CU. Наприклад, вузол в квадродер�и синтаксису для CU можуть бути визначені рекурсивно, і можуть залежати від того, розділена чи CU на одиниці суб-CU. Якщо CU не поділяється далі, вона називається як листова CU. У цьому розкритті чотири суб-CU листової CU будуть згадуватися як листові CU, навіть якщо не буде явного поділу первісної листової CU. Наприклад, якщо CU розміром 16x16 не буде розділена далі, то чотири 8x8 суб-CU будуть згадуватися як листові CU, хоча CU 16x16 ніколи не була розділена.

[0063] CU має аналогічну мету, що і макроблок стандарту H. 264, за винятком того, що CU не має відмінності в розмірі. Наприклад, блок дерева може бути розділений на чотири дочірніх вузла (також званих суб-CU), і кожний дочірній вузол може в свою чергу бути батьківським вузлом і бути розділений ще на чотири дочірніх сайту. Заключний, неподілений дочірній вузол, званий листовим вузлом квадродерева, містить вузол кодування, також званий листової CU. Дані синтаксису, асоційовані з закодованим потоком бітів, можуть визначити максимальну кількість разів, скільки блок дерева може бути розділений, зване максимальною глибиною цієї CU, і може також визначити мінімальний розмір вузлів кодування. Відповідно, потік бітів може також визначити наименьш, � контексті HEVC, або подібним структурам даних в контексті інших стандартів (наприклад, макроблоки та його суб-блоки в H. 264/AVC).

[0064] CU включає в себе вузол кодування та одиниці передбачення (PU) і одиниці перетворення (TU), асоційовані з вузлом кодування. Розмір CU відповідає розміру вузла кодування і має бути квадратним за формою. Розмір CU може ранжуватися від 8x8 пікселів аж до розміру блоку дерева з максимум 64x64 пікселів або більше. Кожна CU може містити одну або більше PU і одну або більше TU. Дані синтаксису, асоційовані з CU, можуть описувати, наприклад, поділ CU в одну або більше одиниць PU. Режими розділення можуть відрізнятися між тим, є CU кодованої в режимі пропуску або прямому режимі, кодованої в режимі внутрішнього передбачення або кодованої в режимі зовнішнього передбачення. PU можуть бути розділені, щоб бути неквадратними за формою. Дані синтаксису, асоційовані з CU, можуть також описувати, наприклад, поділ CU в одну або більше TU згідно квадродереву. TU може бути квадратної або неквадратной (наприклад, прямокутної) за формою.

[0065] Стандарт HEVC враховує перетворення згідно одиницям TU, які можуть бути різними для різних CU.�то може не завжди мати місце. TU типово мають однаковий розмір або менший, ніж PU. В деяких прикладах залишкові вибірки, відповідні CU, можуть бути поділені на менші одиниці, використовуючи структуру квадродерева, відому як "залишковий квадродерево" (RQT). Листові вузли RQT можуть згадуватися як одиниці перетворення (TUs). Значення піксельних різниць, асоційовані з TU, можуть бути перетворені, щоб сформувати коефіцієнти перетворення, які можуть бути квантовани.

[0066] Листова CU може включати в себе одну або більше одиниць передбачення (PU). В цілому PU являє просторову область, що відповідає всім або частини відповідної CU, і може включати в себе дані для того, щоб отримати опорну вибірку для PU. Крім того, PU включає в себе дані, що відносяться до прогнозу. Наприклад, коли PU є кодованої у зовнішньому режимі, дані для PU можуть бути включені в залишкове квадродерево (RQT), яке може включати в себе дані, що описують режим внутрішнього передбачення для TU, відповідної цій PU. В якості іншого прикладу, коли PU є кодованої у зовнішньому режимі, PU може включати в себе дані, що визначають один або більше векторів руху для цієї PU. Дані, що визначають�омпоненту вектора руху, дозвіл для вектора руху (наприклад, піксельна точність в одну чверть або піксельна точність в одну восьму), опорну картинку, на яку вектор руху вказує, та/або перелік опорних картинок (наприклад, Список 0, Список 1, Список або C) для вектора руху.

[0067] Листова CU, має одну або більше PU, може також включати в себе одну або більше одиниць перетворення (TU). Одиниці перетворення можуть бути визначені, використовуючи RQT (також відому структурою квадродерева TU), як описано вище. Наприклад, прапор поділу може вказувати, розділена чи листова CU в чотири одиниці перетворення. Потім, кожна одиниця перетворення може бути розділена далі в наступні суб-TU. Коли TU не розділена далі, вона може згадуватися як листова TU. В цілому для внутрішнього кодування, всі листові TU, належать листової CU, спільно використовують один і той же режим внутрішнього передбачення. Таким чином, один і той же режим внутрішнього передбачення зазвичай застосовується, щоб обчислити передбачені значення для всіх TU листової CU. Для внутрішнього кодування відео кодер 20 може обчислити остаточне значення для кожної листової TU, використовуючи режим внутрішнього передбачення, як різниця �зом, TU можуть бути більшими або меншими ніж PU. Для внутрішнього кодування PU може бути спільно розташована з відповідною листової TU для однієї і тієї ж CU. В деяких прикладах максимальний розмір листової TU може відповідати розміру відповідної листової CU.

[0068] Крім того, одиниці TU листових CU можуть бути асоційовані з відповідними структурами даних квадродерева, званих залишковими квадродеревьями (RQT). Таким чином, листова CU може включати в себе квадродерево, що вказує, як листова CU розділена на одиниці TU. Кореневий вузол квадродерева TU зазвичай відповідає листової CU, в той час як кореневий вузол квадродерева CU зазвичай відповідає блок дерева (або LCU). Одиниці TU згаданої RQT, які не розділені, згадуються як листові TU. В цілому даний розкриття використовує терміни CU і TU, щоб посилатися на листові CU і листові TU, відповідно, якщо не зазначено інакше.

[0069] Відео послідовність типово включає в себе послідовність картинок. Як описано тут, "картинка" і "кадр" можуть використовуватися як взаємозамінні. Таким чином, картинка, що містить відео дані, може згадуватися як відео кадр, або просто "кадр". Група картинок (GOP) зазвичай аголовке GOP, заголовок однієї чи більше картинок, або в іншому місці, яке описує ряд картинок, включених в GOP. Кожна вирізка (слайс) картинки може включати в себе дані синтаксису вирізки, які описують режим кодування для відповідної вирізки. Відео кодер 20 типово оперує над відео блоками в межах індивідуальних відео вирізок, щоб кодувати відео дані. Відео блок може відповідати вузла кодування в межах CU. Відео блоки можуть мати фіксовані та змінні розміри, і можуть відрізнятися за розміром згідно з вказаним стандартом кодування.

[0070] як приклад, HM підтримує передбачення в різних розмірах PU. Припускаючи, що розмір конкретної CU дорівнює 2Nx2N, HM підтримує внутрішнє передбачення в розмірах PU 2Nx2N або NxN, і зовнішнє передбачення в симетричних розмірах PU 2Nx2N, 2NxN, Nx2N, або NxN. HM також підтримує асиметричний поділ для зовнішнього передбачення в розмірах PU 2NxnU, 2NxnD, nLx2N, і nRx2N. При асиметричному розподілі один напрямок CU не поділяється, в той час як інший напрям поділяється на 25% і 75%. Частина CU, відповідна 25%-ому поділу, указується за допомогою "n", супроводжуваним індикацією "Верхня" (Up), "Нижня" (Down), "Ліва" (Left), або "ПравЅу і PU 2Nx1.5N внизу.

[0071] У цьому описі "NxN" і "N на N" можуть використовуватися як взаємозамінні, щоб посилатися на піксельні розмірності блоку в термінах вертикального і горизонтального вимірів, наприклад, 16x16 пікселів або 16 на 16 пікселів. Зазвичай блок 16x16 буде мати 16 пікселів у вертикальному напрямку (y=16) і 16 пікселів в горизонтальному напрямі (x=16). Аналогічно, блок NxN зазвичай має N пікселів у вертикальному напрямку та N пікселів в горизонтальному напрямі, де N-невід'ємне ціле число. Пікселі в блоці можуть бути розміщені в рядках та колонках. Крім того, блоки не обов'язково повинні мати однакову кількість пікселів в горизонтальному напрямі як у вертикальному напрямку. Наприклад, блоки можуть містити NxM пікселів, де М не обов'язково дорівнює N.

[0072] Після кодування з внутрішнім передбаченням або з зовнішнім пророкуванням, використовуючи одиниці PU в CU, відео кодер 20 може обчислити залишкові дані для одиниць TU в CU. Одиниці PU можуть містити дані синтаксису, описують спосіб, або режим генерування пророкують піксельних даних в просторовій області (також званих піксельної областю), і одиниці TU можуть містити коефіцієнти областочисленного перетворення, вейвлет перетворення, або концептуально подібного перетворення до залишковим відео даних. Залишкові дані можуть відповідати піксельною різницями між пікселями незакодированной картинки і значеннями передбачення, відповідними одиницям PU. Відео кодер 20 може сформувати одиниці TU, включаючи залишкові дані для CU, і потім перетворити одиниці TU, щоб сформувати коефіцієнти перетворення для цієї CU.

[0073] Після будь-якого перетворення, щоб сформувати коефіцієнти перетворення, відео кодер 20 може виконати квантування коефіцієнтів перетворення. Квантування зазвичай відноситься до процесу, в якому коефіцієнти перетворення квантуются, щоб можливо зменшити обсяг даних, використовуваних, щоб представити коефіцієнти, що забезпечують подальше стиснення. Процес квантування може зменшити глибину в бітах, асоційовану з деякими або всіма коефіцієнтами. Наприклад, n-бітове значення може бути заокруглюється в меншу сторону до m-бітового значення під час квантування, де n більше ніж m.

[0074] Після квантування відео кодер може сканувати коефіцієнти перетворення, формуючи одновимірний вектор з двовимірної матриці, що включає в себе кв�більш високою енергією (і тому більш низькою частотою) на початку масиву і помістити коефіцієнти з більш низькою енергією (і тому більш високою частотою) в кінці масиву. В деяких прикладах відео кодер 20 може використовувати заздалегідь заданий порядок сканування, щоб сканувати квантовані коефіцієнти перетворення, щоб сформувати перетворений в послідовну форму вектор, який може бути ентропійно кодирован. В інших прикладах відео кодер 20 може виконати адаптивне сканування. Після сканування квантованих коефіцієнтів перетворення, щоб сформувати одновимірний вектор, відео кодер 20 може ентропійно кодувати одновимірний вектор, наприклад, згідно контекстно адаптивного кодування із змінною довжиною коду (CAVLC), контекстно адаптивного двійковому арифметичного кодування (CABAC), заснованому на синтаксисі контекстно адаптивного двійковому арифметичного кодування (SBAC), энтропийному кодування з поділом інтервалу ймовірності (PIPE) або іншими методиками ентропійного кодування. Відео кодер 20 може також ентропійно кодувати елементи синтаксису, асоційовані з закодованими відео даними для використання відео декодером 30 при декодуванні відео даних.

[0075] Щоб виконати CABAC, відео кодер 20 може привласнити контекст в межах контекстної моделі символу, який повинен бути переданий. Контеить CAVLC, відео кодер 20 може вибрати код із змінною довжиною слова символу, який повинен бути переданий. Кодові слова в VLC можуть бути побудовані таким чином, що відносно більш короткі коди відповідають більш вірогідним символів, в той час як більш довгі коди відповідають менш імовірним символів. Таким чином, використання VLC може досягати економії бітів, наприклад, при використанні кодових слів рівної довжини для кожного символу, який повинен бути переданий. Визначення ймовірності може бути засноване на контексті, призначеному на символ.

[0076] Відео кодер 20 може також послати дані синтаксису, такі як засновані на блоці дані синтаксису, засновані на картинці дані синтаксису, і засновані на GOP дані синтаксису, відео декодера 30, наприклад, у заголовку картинки, заголовку блоку, заголовку вирізки або заголовку GOP. Дані синтаксису GOP можуть описувати ряд картинок у відповідній GOP, і дані синтаксису картинки можуть вказувати режим кодування/передбачення, використаний для кодування відповідної картинки.

[0077] У деяких прикладах відео кодер 20 може генерувати, і відео декодер 30 може прийняти, деякі набори параметрів, які можуть ісп�а рівня послідовності (в наборах параметрів послідовності (SPS)) і нечасто змінну інформацію заголовка рівня картинки (наборах параметрів картинки (PPS)). З наборами параметрів (наприклад, PPS і SPS), нечасто змінюється інформація не потрібно повторювати для кожної послідовності (наприклад, послідовності картинок) або картинки, отже ефективність кодування може бути покращено. Крім того, використання наборів параметрів може дозволити передачу поза частотного діапазону інформації заголовка, уникаючи потреби в надлишкових передачах для стійкості до помилок. У прикладах передачі поза частотного діапазону одиниці NAL набору параметрів можуть бути передані по відмінному каналі, ніж інші одиниці NAL, такі як одиниці NAL інформації додаткового розширення (SEI).

[0078] Одиниці NAL SEI (звані повідомленнями SEI) можуть містити інформацію, яка не є необхідною для декодування кодованих вибірки картинки з одиниць NAL VCL, але може допомогти в процесах, що належать до декодуванню, відображенню, стійкості до помилок, та іншим цілям. Повідомлення SEI можуть міститися в одиницях NAL не-VCL. Повідомлення SEI можуть бути включені в нормативну частину деяких специфікацій стандартів, і таким чином не завжди є обов'язковими для реалізації декодера, сумісний зі стандартом. Повідомлення SEI можуть бути повідо�яльності може міститися в повідомленнях SEI, така повідомлення SEI інформації масштабованості в прикладі SVC і повідомлення SEI інформації масштабованості виду в MVC.

[0079] У деяких прикладах відео кодер 20 може кодувати потік бітів MVC, який відповідає розширенню MVC до H. 264/AVC. Аналогічно, відео декодер 30 може декодувати потік бітів MVC, який відповідає розширенню MVC до H. 264/AVC. Останній об'єднаний проект MVC описаний в JVT-AD007, AD007, AD007, “Editors' draft revision to ITU-T Rec. H. 264 | ISO/IEC 14496-10 Advanced Video Coding," 30thJVT meeting, Geneva, Switzerland, Jan.-Feb. 2008, публічно доступною за адресою http://wftp3.itu.int/av-arch/jvt-site/2009_01_Geneva/JVT-AD007.

[0080] масштабованому розширенні H. 264/AVC елементи синтаксису можуть бути додані в розширення заголовка одиниці NAL, щоб розширити заголовок одиниці NAL від одного байта до чотирьох байтів, щоб описати характеристики одиниці NAL VCL у багатьох вимірах. Таким чином, одиниці NAL VCL в HEVC може включати в себе більш довгий заголовок одиниці NAL, ніж заголовок одиниці NAL в стандарті H. 264/AVC. Розширення MVC до H. 264/AVC може бути згадано в цьому розкритті як "MVC/AVC".

[0081] Одиниця NAL MVC/AVC може містити однобайтний заголовок одиниці NAL, який включає в себе тип одиниці NAL, так само як розширення заголовка одиниці NAL MVC/AVC. В якості прикладу, раh="90%" border="1" cellpadding="0" cellspacing="0" frame="all">Таблиця 1СИНТАКСИС РОЗШИРЕННЯ ЗАГОЛОВКА ОДИНИЦІ NALnal_unit_header_extension(){CДескрипторreserved_zero_bitВсіu(1)idr_flagВсіu(1)priority_idВсіu(6)view_idВсіu(10)temporal_idВсіu(3)anchor_pic_flagВсіu(1)inter_view_flagВсіu(1)reserved_one_bitВсіu(1)}

[0082] В Таблиці 1 вище елемент idr_flag може укожет використовуватися як точка довільного доступу до закритої GOP. Наприклад, картинка IDR і всі картинки, наступні за картинкою IDR у порядку відображення і в порядку потоку бітів, можуть бути належним чином декодованими, не декодуючи попередні картинки або в порядку потоку бітів або порядку відображення. Елемент priority_id може використовуватися з процесом адаптації потоку бітів, який змінює потік бітів відповідно до мінливих умов мережі та/або можливостей відео декодера 30 та/або пристрої 32 відображення (наприклад, таким як процес адаптації за єдиний прохід). Елемент view_id може бути використаний для вказівки ідентифікатор виду для виду, до якого належить одиниця NAL, який може використовуватися в декодері MVC, наприклад, для передбачення між видами і поза декодера, наприклад, для відтворення. У деяких випадках view_id може бути встановлений рівним заздалегідь заданому id камери, і може бути відносно великим. Елемент temporal_id може бути використаний для вказівки тимчасового рівня поточної одиниці NAL, який може відповідати конкретній швидкості передачі кадру.

[0083] Елемент anchor_pic_flag може бути використаний для визначення, чи належить одиниця NAL картинці з прив'язкою, яка може використовуватися як точка довільного доступображения, можуть бути належним чином декодованими, не декодуючи попередні картинки в порядку декодування (тобто порядку потоку бітів) і таким чином можуть використовуватися як випадкові точки доступу. Картинки з прив'язкою і картинки без прив'язки можуть мати різні залежно видів, обидві з яких можуть бути сигнализировани в SPS. Таким чином, як описано тут, залежність видів може зазвичай ставитися до виду, від якого залежить в даний час кодований вигляд. Іншими словами, залежно видів можуть формулювати, від яких видів може бути передбачений в даний час кодований вигляд. Згідно з деякими прикладами залежність видів може бути сигнализирована в розширенні MVC SPS. У таких прикладах всі передбачення між видами може бути зроблено в межах області, певної розширенням MVC SPS. Елемент inter_view_flag може бути використаний для вказівки, використовується одиниця NAL для передбачення між видами для одиниць NAL в інших видах.

[0084] Щоб передати вищезгадану 4-байтовую інформацію заголовка одиниці NAL для основного виду потоку бітів MVC, одиниця NAL префікса може бути визначена в MVC. У контексті MVC одиниця доступу базового виду може включати в себе одиниці NAL VCL поточного мом�тримати тільки заголовок одиниці NAL. Якщо одиниця NAL префікса не потрібно для декодування (наприклад, такого як декодування єдиного виду), декодер може проігнорувати і/або відмовитися від одиниці NAL префікса.

[0085] Щодо розширення MVC/AVC SPS, згадане MVC SPS може вказувати види, які можуть використовуватися в цілях передбачення між видами. Наприклад, потенційні опорні посилання між видами можуть бути сигнализировани та розширенні MVC/AVC SPS, і можуть бути змінені процесом конструювання списку опорних зображень, який забезпечує гнучке упорядкування зовнішнього передбачення або опорних посилань передбачення між видами. Приклад MVC/AVC SPS сформульований у Таблиці 2 нижче:

Таблиця 2
ПРИКЛАД MVC SPS
seq_parameter_set_mvc_extension(){CДескриптор
num_views_minus10ue(v)
for(i=0; i<=num_views_minus1; i++)
view_id[i]
num_anchor_refs_l0[ i ]0ue(v)
for(j=0; j< num_anchor_refs_l0[i]; j++)
anchor_ref_l0[i][j]0ue(v)
num_anchor_refs_l1[i]0ue(v)
for(j=0; j<num_anchor_refs_l1[i]; j++)
anchor_ref_l1[i][j]0ue(v)
}
for(i=1; i < =num_views_minus1; i++){
num_non_anchor_refs_l0[i]0ue(v)
for(j=0; j<num_non_anchor_refs_l0[i]; j++)
non_anchor_ref_l0[i][j]0ue(v)
for(j=0; j<num_non_anchor_refs_l1[i]; j++)
non_anchor_ref_l1[i][j]0ue(v)
}
num_level_values_signalled_minus10ue(v)
for(i=0; i<=num_level_values_signalled_minus1; i++){
level_idc[i]0u(8)
num_applicable_ops_minus1[i]0ue(v)
for(j=0; j<=num_applicable_ops_minus1[i]; j++){
applicable_op_temporal_id[i][j]0u(3)
applicable_op_num_target_views_minus1[i][j0ue(v)
for(k=0; k<=applicable_op_num_target_views_minus1[i][j]; k++)
a>applicable_op_num_views_minus1[i][j]0ue(v)
}
}
}

[0086] Згідно з деякими прикладами, залежність видів може бути сигнализирована в розширенні MVC SPS. Всі передбачення між видами може бути зроблено в межах області, певної розширенням MVC SPS. Таким чином, SPS може формулювати, які види можуть бути згадані в цілях передбачення допомогою виду, кодованого в даний час. У Таблиці 2 вище елемент num_anchor_refs_l0 [i] може задавати кількість компонентів виду для передбачення між видами в инициализированном списку опорних елементів Списку 0 (наприклад, RefPicList0). Крім того, елемент anchor_ref_l0 [i] [j] може задавати view_id j-го компонента виду для передбачення між видами в инициализированном RefPicList0. Елемент num_anchor_refs_l1 [i] може задавати кількість компонентів виду для передбачення між видами в инициализированном списку опорних елементів списку (наприклад, RefPicList1). Елем�PicList1. Елемент num_non_anchor_refs_l0 [i] може задавати кількість компонентів виду для передбачення між видами в инициализированном RefPicList0. Елемент non_anchor_ref_l0 [i] [j] може задавати view_id j-го компонента виду для передбачення між видами в инициализированном RefPicList0. Елемент num_non_anchor_refs_l1 [i] може задавати кількість компонентів виду для передбачення між видами в инициализированном RefPicList1. Елемент non_anchor_ref_l1 [i] [j] може задавати view_id j-го компонента виду для передбачення між видами в инициализированном RefPicList.

[0087] Инициализировавший, або "початковий", список опорних картинок може бути однаковим або відрізняється від остаточного списку опорних картинок, що використовується в цілях передбачення між видами компонентів виду. Таким чином, деякі опорні кандидати (тобто, опорні картинки, які можуть використовуватися для передбачення між видами) можуть бути вилучені з початкового списку опорних картинок (наприклад, надлишкові картинки). Крім того, як описано більш докладно нижче, опорні кандидати можуть бути переупорядочени з початкового списку опорних картинок, щоб сформувати остаточний список опорних картинок.

[0088] У цьому прикладі, згідно MVC/AVC, залежно видів для картинок з прзадавать в загальній складності чотири списку опорних картинок (наприклад, Список 0, картинки без прив'язки; Список 1, картинки без прив'язки; Список 0, картинки з прив'язкою; Список 1, картинки з прив'язкою). Крім того, як показано в Таблиці 2 вище, окрема сигналізація вимагається для вказівки залежності видів відео декодера 30. Таким чином, SPS повинен включати в себе окрему сигналізацію 0 Списку та Списку 1 і для anchor_refs і для non_anchor_refs.

[0089] Крім того, згідно Таблиці 2, залежність між видами для компонентів виду без прив'язки є поднабором його компонентів виду з прив'язкою. Таким чином, наприклад, компонент виду для виду з прив'язкою може бути передбачений з більше ніж одного іншого виду, такого як вид 3 і 4. Вид без прив'язки, однак, може бути передбачений з картинок види 3 (підмножиною виду з прив'язкою). Таким чином, залежно видів та компонентів виду з прив'язкою без прив'язки окремо підтримуються.

[0090] Крім того, у Таблиці 2, num_level_values_signalled може задавати кількість значень рівня, сигнализированних для закодованої відео послідовності. Елемент level_idc [i] може задавати i-е значення рівня, сигнализированное для закодованої відео послідовності. Елемент num_applicable_ops_minus1 [i] плюс 1 може задавати кількість робочих точе�_id j-ї робочої точки, до якої рівень, зазначений допомогою level_idc [i], що застосовується. Елемент applicable_op_num_target_views_minus1 [i] [j] може задавати кількість цільових видів виводу для j-ї робочої точки, до якої рівень, зазначений допомогою level_idc [i], що застосовується. Елемент applicable_op_target_view_id [i] [j] [k] може задавати k-ї цільової вид висновку для j-ї робочої точки, до якої рівень, зазначений допомогою level_idc [i], що застосовується. Елемент applicable_op_num_views_minus1 [i] [j] може задавати кількість видів, включаючи види, які залежать від цільових видів виводу, але які не належать цільовим видами висновку, j-th робочій точці, до якої рівень, зазначений допомогою level_idc [i], що застосовується.

[0091] Відповідно, у розширенні MVC SPS для кожного виду кількість видів, які можуть бути використані для формування списку 0 опорних картинок та списку 1 опорних картинок, може бути сигналізується. Крім того, відносини передбачення для картинки з прив'язкою, як сигналізується в розширенні MVC SPS, можуть відрізнятися від відносин передбачення для картинки без прив'язки (викладених у розширенні MVC SPS) того ж виду.

[0092] Як описано більш докладно нижче, відео кодер 20 і відео декодер 30 можуть гнучко компонувати тимчасовий і опорні посилання передбачення видів, при посу ефективності кодування, але також і стійкість до помилок, так як секція опорних картинок і механізми надлишкових картинок можуть бути розширені до розміру виду. Відео кодер 20 і/або відео декодер 30, в одному прикладі, можуть конструювати список опорних картинок згідно з наступних етапів:

1) Ініціалізувати список опорних картинок для тимчасових (тобто, всередині виду) опорних картинок, таким чином що опорні картинки від інших видів не розглядаються.

2) Додати опорні картинки між видами до кінця списку в порядку, в якому картинки мають місце в розширенні SPS MVC.

3) Застосувати процес переупорядочения списку опорних картинок (RPLR) і для опорних картинок всередині виду і між видами. Опорні картинки між видами можуть бути ідентифіковані в командах RPLR їх значеннями індексу, як визначено в розширенні SPS MVC.

[0093] В той час як H. 264/AVC включає в себе підтримку MVC, поточне розширення MVC до H. 264/AVC може містити кілька неэффективностей щодо інших стандартів кодування відео. Крім того, як описано більш докладно нижче, прямий імпорт MVC з H. 264/AVC в інші стандарти кодування, таких як майбутній стандарт HEVC, не може бути здійсненним. Способи справжнього розкриття в цілому стосуються фор�го розкриття не обмежені жодним конкретним стандартом кодування, деякі способи розкриття цього можуть забезпечити ефективне MVC кодування для майбутнього стандарту HEVC.

[0094] Як приклад, стандарт H. 264/MVC підтримує до 1024 видів і використовує ідентифікатор виду (view_id) в заголовку одиниці NAL, щоб ідентифікувати вид, якому належить одиниця NAL. Оскільки view_id має довжину 10 біт, більш ніж 1000 різних видів можуть бути унікально ідентифіковані значеннями view_id. Однак, багато програм тривимірного (3D) відео вимагають значно меншої кількості видів. Крім того, менше видів може вимагатися для 3D-відео додатків, які використовують синтез видів, щоб генерувати більше видів (які не вимагають кодування). Згідно розширенню MVC/AVC заголовок одиниці NAL включає в себе 10 бітовий view_id, який завжди надається. view_id може істотно збільшити кількість бітів для заголовка одиниці NAL, яке займає відносно велику частину потоку бітів.

[0095] Згідно з аспектів цього розкриття порядковий індекс виду ("view_order_index" або "view_idx") може бути повідомлений в якості частини заголовка одиниці NAL. Таким чином, відео кодер 20 може кодувати і передавати, і відео декодер 30 може прийняти і декодувати, порядковий індекс виду ообщен в заголовку одиниці NAL MVC-розширення до H. 264/AVC (надалі "MVC/AVC"). Таким чином, наприклад, view_idx може замінити view_id в заголовку одиниці NAL.

[0096] Як описано вище, MVC забезпечує передбачення між видами. Відповідно, види, використані для посилання (тобто види, які використані для передбачення інших видів), повинні мати місце в порядку кодування раніше, ніж види, які посилаються, як описано вище. Порядок видів зазвичай описує порядок видів в одиниці доступу, і порядковий індекс виду ідентифікує конкретний вид в порядку видів одиниці доступу. Таким чином, порядковий індекс виду описує порядок декодування відповідного компонента виду одиниці доступу.

[0097] SPS може забезпечити відносини між ідентифікаторами виду (view_ids) для видів і порядкові індекси виду для згаданих видів. Згідно з аспектів цього розкриття, використовуючи порядковий індекс виду і дані в SPS, відео кодер 20 і відео декодер 30 можуть замінити 10 бітовий view_id для MVC/AVC в заголовку одиниці NAL на порядковий індекс виду. Наприклад, порядковий індекс виду може включати в себе по суті менше ніж 10 біт (наприклад, 2 біта, 3 біта, або подібне). У той час як відносини між порядковим індексом виду і ідентифікаторами виду можуть зажадати деякої ассакая сигналізація. Відповідно, зменшуючи розмір заголовків одиниці NAL, способи розкриття цього можуть досягти економії бітів у порівнянні зі схемою MVC/AVC. Інформація, яка вказує це ставлення, може містити, наприклад, таблицю відображення, яка відображає значення view_id в значення порядкового індексу виду. У цьому способі відео декодер 30 може просто прийняти значення порядкового індексу виду в заголовку одиниці NAL і визначити view_id одиниці NAL, використовуючи таблицю відображення.

[0098] Згідно з деякими аспектами розкриття, порядковий індекс виду може мати динамічну довжину, залежно від того, чи він є базовим видом HEVC, профілем, або багатьма видами, підтримуваними в потоці бітів MVC. Наприклад, додаткові економії бітів можуть бути досягнуті в потоці MVC, який включає в себе лише два види (тобто, для стерео відео). У цьому прикладі порядковий індекс виду може не бути необхідним, оскільки відео декодер 30 завжди може декодувати перший вид (наприклад, вигляд 0) до декодування другого виду (наприклад, виду 1). Таким чином, згідно деяким аспектам цього розкриття базовий вид може бути призначений з порядковим індексом виду, за замовчуванням рівним 0, і тому не повинен бути базового виду (наприклад, виду 0) базового виду MVC/AVC, може більше не вимагатися при використанні порядкового індексу виду, описаного вище. Наприклад, відео декодер 30 може більше не вимагати одиниці NAL префікса для базового виду, так як порядковий індекс виду може завжди бути нулем для базового виду, і тимчасова позиція базового виду може бути визначена, використовуючи temporal_id (включений у MCV/AVC). Відповідно, відео кодер 20 може сигналізувати temporal_id в заголовку одиниці NAL, який може надати всю інформацію, необхідну для відео декодера 30, щоб асоціювати конкретний компонент виду з конкретним видом і з відповідним тимчасовим місцем розташування.

[0100] Щодо з'являється стандарту HEVC, згідно з аспектів цього розкриття, коли одиниця NAL префікса не використовується для сумісного з HEVC базового виду, прапор може бути доданий в заголовок одиниці NAL базового виду HEVC. Цей прапор може бути використаний тільки для вказівки, може компонент виду (цієї конкретної одиниці NAL) бути використаний для компонентів зовнішнього вигляду передбачення інших видів потоку бітів.

[0101] Крім того, згідно аспектів розкриття, порядковий індекс виду може бути використаний зі значенням відліку порядку�е вказує порядок декодування картинок), щоб ідентифікувати компонент виду потоку бітів.

[0102] В якості іншого прикладу, як зазначено вище, SPS MVC/AVC може вказувати залежні види (тобто, види, на які посилаються один або більше інших видів метою передбачення) окремо для кожного виду. Наприклад, anchor_pic_flag, включений у заголовок одиниці NAL MVC/AVC, може бути використаний для визначення, чи належить одиниця NAL картинці з прив'язкою, яка може бути використана як точка довільного доступу відкритої GOP. У MVC/AVC, як описано вище, залежність видів сигналізується по-різному для картинок з прив'язкою і картинок без прив'язки. Відповідно, для залежних видів, сигнализированних для кожного виду, чотири різних категорії розглядаються, кожна з яких відрізняється тим, є картинка для картинки з прив'язкою або є картинка для 0 Списку або Списку 1. Така структура не тільки вимагає, щоб відносно велика кількість бітів підтримував такі розмежування, але також може ускладнити побудова списку опорних картинок (наприклад, кожна категорія має бути підтримана під час побудови опорного списку і переупорядочения).

[0103] Згідно з аспектів цього розкриття, відео кодер 20 може�ока бітів MVC зазвичай для всіх компонентів виду, незалежно від того, призначені чи компоненти виду для картинок з прив'язкою і картинок без прив'язки. В деяких прикладах SPS включає в себе індикацію залежностей виду для компонентів виду, замість того, щоб покладатися на інформацію в заголовку одиниці NAL. У цьому способі відео кодер 20 і відео декодер 30 можуть не використовувати anchor_pic_flag, використовуваний в заголовку одиниці NAL MVC/AVC.

[0104] Компонент виду сигнализированного залежного виду може бути використаний як опорна картинка і 0 Списку і в Списку 1. Крім того, побудова списку опорних картинок і упорядкування списку опорних картинок для Списку з 0 та Списку 1 можуть також бути засновані на загальній сигналізації для картинок з прив'язкою і картинок без прив'язки. В деяких прикладах рівень послідовності, повідомлення інформації додаткового розширення (SEI) можуть бути використані для вказівки, коли картинка без прив'язки має іншу залежність видів, ніж картинка з прив'язкою.

[0105] Відповідно, деякі аспекти цього розкриття стосуються видалення картинки із прив'язкою/картинки без прив'язки і розрізнення сигналізації 0 Списку/списку 1 у MVC/AVC, таким чином спрощуючи потік бітів, а також побудова списку опорних картинок. ервий вид, інформацію опорного виду, вказує один або більше опорних видів, для передбачення компонентів виду першого виду. Таким чином, відео декодер 30 може прийняти опорну інформацію виду, що вказує залежності видів для картинок з прив'язкою виду і картинок без прив'язки виду аналогічно. Інформація опорного виду може включати в себе, наприклад, порядковий індекс виду (вказівка порядку декодування виду в одиниці доступу), асоційований з кожним опорним видом, як описано вище.

[0106] Крім того, при декодуванні конкретної картинки (одиниці доступу) конкретного виду, відео декодер 30 може включати опорних кандидатів (наприклад, компоненти виду, з яких конкретна картинка може бути передбачена) з тієї ж одиниці доступу, що і конкретна картинка, і з опорних видів, зазначених інформацією опорного виду. У деяких випадках відео декодер 30 може додати опорних кандидатів до списку опорних картинок з кожного опорного виду таким чином, що кількість опорних кандидатів дорівнює кількості опорних видів. Крім того, відео декодер 30 може додати опорних кандидатів до будь-якого зі Списку 1, 0 Списку, або обох. Відео декодер 30 може декодувати конкретну картинку на засновано�е, priority_id включений в заголовок одиниці NAL сумісного з MVC/AVC потоку бітів. Цей priority_id забезпечує індикацію пріоритету конкретної одиниці NAL. Більш детально, кожній одиниці NAL зазвичай призначають значення пріоритету. У відповідь на запит про значення P пріоритету будуть надані всі одиниці NAL, що мають значення пріоритету, менше або рівні P (тобто, одиниці NAL, що мають значення priority_id більше, ніж P, відкидаються). У цьому способі більш низькі значення пріоритету визначають більш високі пріоритети. Потрібно розуміти, що одиниці NAL одного і того ж виду можуть мати різні пріоритети, наприклад, для тимчасової масштабованості в межах виду.

[0108] Цей пріоритет може бути використаний в цілях масштабованості. Наприклад, щоб отримати відео дані, які споживають найменшу величину смуги частот (за рахунок формування уявлення щодо низької якості), відео декодер 30 (або, більш широко, пристрій 14 призначення) може запросити тільки одиниці NAL з найвищим пріоритетом для передачі з джерела, такого як пристрій-джерело 12/відео кодер 20, і priority_id може бути використаний для фільтрування одиниць NAL більш низького пріоритету. В деяких прикладах маршрутизатор 36 ие одиниці NAL від одиниць NAL більш низького пріоритету. Щоб сформувати уявлення щодо більш високої якості (за рахунок більш високого споживання смуги частот), відео декодер 30 може запросити одиниці NAL, що мають нижчий пріоритет, щоб доповнити одиниці NAL більш високого пріоритету, наприклад, за допомогою завдання більш високого значення пріоритету.

[0109] Згідно з аспектів цього розкриття, замість того, щоб сигналізувати priority_id в заголовку одиниці NAL, відео кодер 20 може забезпечити значення priority_id в SPS. Таким чином, priority_id для кожного виду з деяким часовим рівнем може бути сигналізований в рівні послідовності. Крім того, згідно з аспектів цього розкриття, адаптація з єдиним проходом може бути вирішена, поки сигналізація контексту, асоційованого з адаптацією, відома.

[0110] Як описано вище, в деяких прикладах, маршрутизатор 36, який може бути відповідальним за напрямок потоку бітів пристрою 14 призначення, може використовувати значення priority_id SPS, щоб фільтрувати деякі види. Таким чином, маршрутизатор 36 може прийняти повний потік бітів, але отримати подпоток бітів, включаючи одиниці NAL, що мають значення priority_id, рівні й нижче значення пріоритету, визначеного ѽо MVC/AVC, адаптація з єдиним проходом вимагає 6-бітового priority_id в заголовку одиниці NAL. Наприклад, як зазначено вище, SPS MVC/AVC може включати в себе індикацію рівня виду для масштабованості виду. Таким чином, кожний вид потоку бітів MVC може бути кодирован ієрархічним способом і йому може бути призначено числовий рівень виду.

[0112] Згідно з аспектів цього розкриття, SPS може включати в себе інформацію рівня виду. Таким чином, коли пристрій 14 призначення запитує види рівня виду V від сервера/34 мережі доставки контенту, пристрій 14 призначення приймає всі види, що мають рівні виду, менше або рівні V. Подібно до використання значень priority_id, описаних вище, маршрутизатор 36 з сервера/34 мережі доставки контенту може використовувати рівні виду, щоб витягти подпоток бітів, що включає в себе дані для видів, що мають рівні виду, менше або рівні запитаному клієнтом рівнем виду.

[0113] Інші аспекти цього розкриття відносяться до легкого процесу транскодування, щоб перетворити подпоток бітів більш високого профілю в потік бітів, що відповідає більш низькому профілю. Такий процес транскодування може бути виконаний, наприклад, сервером/мережею 34 доставки:

1) Переотображение значень view_idx і view_id в SPS

2) Зміна розмірів заголовка одиниці NAL з короткою довжиною view_idx

[0114] Припустимо, наприклад, що потік бітів профілю телевізора з вільною точкою огляду (FVT) містить 32 види, з view_idx рівним view_id для кожного виду. У цьому прикладі потік бітів має подпоток бітів, що містить 8 видів, з рівним view_idx 0, 4, 8, 12, 16, 20, 24, 28. Цей подпоток бітів далі містить подпоток бітів, який містить два види, зі значеннями view_id 0 і 4.

[0115] Згідно з аспектів цього розкриття, значення view_idx для подпотока бітів з 8 видами можуть бути переотображени згідно Таблиці 3 нижче:

Таблиця 3
ПЕРЕОТОБРАЖЕНИЕ VIEW_IDX
view_id0481216202428
Вихідний view_idx в профілі ftv048an="0">28
Відображений view_idx в profile 3DV01234567

[0116] Згідно з аспектів цього розкриття, значення view_idx для подпотока бітів з 2 видами можуть бути переотображени згідно Таблиці 4 нижче:

Таблиця 4
ПЕРЕОТОБРАЖЕНИЕ VIEW_IDX
view_id04
Вихідний view_idx в профілі ftv04
Відображений view_idx в профілі 3DV01
Відображений view_idx в профілі стерео01

[0117] Згідно з аспектів цього розкриття, view_idx в заголовку одиниці NAL може бути переотображен згідно Таблиці 5 нижче:

ПЕРЕОТОБРАЖЕНИЕ VIEW_IDX
Кількість бітів в NALUЗначення для view_id 4
view_idx в заголовку одиниці NAL ftvu(10)4
view_idx в заголовку одиниці NAL 3DVu(3)1
view_idx заголовку одиниці NAL стереоНе вимагається сигналізація бітів1

[0118] Альтернативно, легкий процес транскодування, описаний вище, не може вимагати переотображения view_idx, якщо відповідав потік бітів забезпечує проміжок у порядковому індексі виду.

[0119] ФІГ. 2 є блок-схема, що ілюструє зразковий відео кодер 20, який може реалізувати способи, описані в цьому розкритті для того, щоб кодувати потік бітів множинних видів. Відео кодер 20 приймає відео дані, які повинні бути закодовані. У прикладі згідно ФІГ. 2, відео кодер 20 включає в себе модуль 40 вибору режиму, суматор 50, модуль 52 обробки перетворення, модуль 54 квантування, модуль 56 ентропійного�ки руху/диспарантности, модуль 44 компенсації руху, модуль 46 внутрішнього передбачення, і модуль 48 поділу.

[0120] Для реконструкції відео блоку відео кодер 20 також включає в себе модуль 58 зворотного квантування, модуль 60 обробки зворотного перетворення і суматор 62. Фільтр видалення блочності (не показано на фіг. 2) також може бути включений, щоб фільтрувати межі блоку, щоб видалити артефакти блочності з відновленого відео. Якщо бажано, фільтр видалення блочності типово може фільтрувати вихідний сигнал суматора 62. Додаткові фільтри контуру (в контурі або після контуру) можуть також використовуватися на додаток до фільтру, видалення блочності. Такі фільтри не показані для стислості, але якщо бажано, можуть фільтрувати вихідний сигнал суматора 50 (в якості фільтра у контурі).

[0121] Модуль 40 вибору режиму може прийняти необроблені відео дані у формі блоків від одного або більше видів. Модуль 40 вибору режиму може вибрати один з режимів кодування, внутрішній або зовнішній, наприклад, на підставі результатів помилки, і видавати результуючий всередині або зовні - кодований блок до суматора 50, щоб генерувати залишкові дані блоку, і до суматора 62, щоб відновити за�елементи синтаксису, такі як вектори руху, індикатори внутрішнього режиму, інформацію поділу, та іншу таку інформацію синтаксису, до модулю 56 ентропійного кодування.

[0122] Модуль 42 оцінки руху/диспарантности і модуль 44 компенсації руху можуть бути високо інтегровані, але ілюстровані окремо в концептуальних цілях. Оцінка руху, виконана модулем 42 оцінки руху/диспарантности, є процесом генерування векторів руху, які оцінюють рух для відео блоків. Вектор руху, наприклад, може вказувати зміщення PU відео блоку в межах поточної картинки щодо предсказивающего блоку в межах опорної картинки (або інший кодованої одиниці) щодо поточного блоку, кодованого в межах поточної картинки (або інший кодованої одиниці).

[0123] Пророкує блок є блоком, який, як вважають, близько відповідає блоку, який повинен бути закодований, в термінах піксельної різниці, яка може бути визначена сумою абсолютних різниць (SAD), сумою різниць квадратів (SSD), або іншими метриками відмінності. В деяких прикладах відео кодер 20 може обчислити значення для суб-цілочисельних позицій пікселя опорних картинимер, відео кодер 20 може інтерполювати значення піксельних позицій в одну чверть, піксельних позицій в одну восьму, або інших фракційних піксельних позицій опорної картинки. Тому блок 42 оцінки руху може виконувати пошук руху щодо повних піксельних позицій і фракційних піксельних позицій і вивести вектор руху з фракційної піксельної точністю.

[0124] Модуль 42 оцінки руху/диспарантности обчислює вектора руху для PU відео блоку у зовнішньо кодованої вирізці, за допомогою порівняння позиції PU з позицією предсказивающего блоку опорної картинки. Модуль 42 оцінки руху/диспарантности може бути налаштований, щоб виконати пророцтво між видами, у цьому випадку модуль 42 оцінки руху/диспарантности може обчислити вектори зсуву між блоками картинки одного виду (наприклад, виду 0) і відповідними блоками картинки опорного виду (наприклад, виду 1). В цілому дані для вектора руху/диспарантности можуть включати в себе список опорних картинок, індекс список (ref_idx) опорних картинок, горизонтальну компоненту, і вертикальну компоненту. Опорна картинка може бути обрана з першого списку опорних картинок (Список 0), второгентифицирует одну або більше опорних картинок, збережені в пам'яті 64 опорних картинок. Щодо об'єднаного списку, відео кодер 20 по черзі вибирає записи з двох списків (тобто, Списку з 0 та 1), щоб вставити (додати) в об'єднаний список. Коли запис вже поміщена в об'єднаний список, за допомогою перевірки числа POC, відео кодер 20 може не вставляти запис знову. Для кожного списку (тобто, 0 Списку або Списку 1), відео кодер 20 може вибрати записи на підставі зростаючого порядку опорного індексу.

[0125] Модуль 42 оцінки руху/диспарантности може генерувати і послати вектор руху/диспарантности, який ідентифікує пророкує блок опорної картинки, до модулю 56 ентропійного кодування і модулю 44 компенсації руху. Таким чином, модуль 42 оцінки руху/диспарантности може генерувати і послати дані вектора руху, які ідентифікують список опорних картинок, що містить пророкує блок, індекс в списку опорних картинок, що ідентифікує картинку предсказивающего блоку, і горизонтальну і вертикальну компоненти, щоб визначити місцезнаходження предсказивающего блоку в межах ідентифікованої картинки.

[0126] Компенсація руху, виконана модулем 44 компктора руху/диспарантности, певного модулем 42 оцінки руху/диспарантности. Знову, модуль 42 оцінки руху/диспарантности і модуль 44 компенсації руху можуть бути функціонально інтегрованими, в деяких прикладах. Після прийому вектора руху для PU поточного відео блоку модуль 44 компенсації руху може визначати місцезнаходження предсказивающего блоку, на який вектор руху вказує в одному зі списків опорних картинок.

[0127] Суматор 50 формує залишковий відео блок, віднімаючи піксельні значення предсказивающего блоку з піксельних значень поточного закодованого блоку відео, формуючи значення піксельної різниці, як описано нижче. В цілому модуль 42 оцінки руху/диспарантности виконує оцінку руху щодо компонентів яскравості, і модуль 44 модуль використовує вектора русі, обчислені на підставі компонентів яскравості як для компонентів насиченості кольору так і для компонентів яскравості. Модуль 40 вибору режиму може також генерувати елементи синтаксису, асоційовані з відео блоками і відео вирізкою для використання відео декодером 30 при декодуванні відео блоків відео вирізки.

[0128] Модуль 46 внутрішнього передбачення може внутрішньо передбачити тек�одулем 44 компенсації руху, як описано вище. Зокрема, модуль 46 внутрішнього передбачення може визначати режим внутрішнього передбачення, щоб використовувати при кодуванні поточного блоку. В деяких прикладах модуль 46 внутрішнього передбачення може кодувати поточний блок, використовуючи різні режими внутрішнього передбачення, наприклад, під час окремих проходів кодування, і модуль 46 внутрішнього передбачення (або модуль 40 вибору режиму в деяких прикладах) може вибрати відповідний режим внутрішнього передбачення для використання з перевірених режимів.

[0129] Наприклад, модуль 46 внутрішнього передбачення може обчислити значення «спотворення - швидкість передачі», використовуючи аналіз «спотворення - швидкість передачі» для різних перевірених режимів внутрішнього передбачення, і вибрати режим внутрішнього передбачення, що має найкращі характеристики «спотворення - швидкість передачі»серед перевірених режимів. Аналіз «спотворення - швидкість передачі» зазвичай визначає величину спотворення (або помилку) між кодованим блоком і початковим незакодованих блоком, який був закодований, щоб сформувати закодований блок, а також швидкість передачі в бітах (тобто, кількість бітів), ісп�з спотворень і швидкостей передачі для різних кодованих блоків, щоб визначити, який режим внутрішнього передбачення показує найкраще значення «спотворення - швидкість передачі» для блоку.

[0130] Після вибору режиму внутрішнього передбачення для блоку модуль 46 внутрішнього передбачення може надати інформацію, що вказує вибраний режим внутрішнього передбачення для блоку, до модулю 56 ентропійного кодування. Модуль 56 ентропійного кодування може кодувати інформацію, що вказує вибраний режим внутрішнього передбачення. Відео кодер 20 може включати в переданий потік бітів дані конфігурації, які можуть включати в себе безліч таблиць індексу режиму внутрішнього передбачення, і безліч таблиць модифікованого індексу режиму внутрішнього передбачення (також званих таблиці відображення кодових слів), визначення контекстів кодування для різних блоків, і індикації найбільш ймовірного режиму внутрішнього передбачення, таблиці індексу режиму внутрішнього передбачення, і таблиці модифікованого індексу режиму внутрішнього передбачення, щоб використовувати для кожного з контекстів.

[0131] Відео кодер 20 формує залишковий відео блок, віднімаючи дані передбачення від модуля 40 вибору режиму спочатку� віднімання. Модуль 52 обробки перетворення перетворення, таке як дискретне косинусне перетворення (DCT) або концептуально подібне перетворення, до залишковим блоку, формуючи відео блок, що містить залишкові значення коефіцієнта перетворення. Модуль 52 обробки перетворення може виконати інші перетворення, які концептуально подібні DCT. Вейвлет перетворення, цілочисельні перетворення, перетворення частотних піддіапазонів або інші види перетворення також можуть використовуватися. У будь-якому випадку модуль 52 обробки перетворення перетворення до залишковим блоку, формуючи блок залишкових коефіцієнтів перетворення. Перетворення може перетворити залишкову інформацію з області піксельних значень до області перетворення, такий як частотна область.

[0132] Модуль 52 обробки перетворення може послати результуючі коефіцієнти перетворення в модуль 54 квантування. Модуль 54 квантування квантует коефіцієнти перетворення, щоб далі зменшити частоту проходження бітів. Процес квантування може зменшити бітову глибину, асоційовану з деякими або всіма коефіцієнтами. Ступінь квантування може б�може потім виконати сканування матриці, включає в себе квантовані коефіцієнти перетворення. Альтернативно, модуль 56 ентропійного кодування може виконати сканування.

[0133] Після квантування модуль 56 ентропійного кодування ентропійно кодують квантовані коефіцієнти перетворення. Наприклад, модуль 56 ентропійного кодування може виконати контекстно-адаптивне кодування із змінною довжиною коду (CAVLC), контекстно-адаптивне двійкове арифметичне кодування (CABAC), заснований на синтаксисі контекстно-адаптивне двійкове арифметичне кодування (SBAC), энтропийное кодування з поділом інтервалу ймовірності (PIPE) або інші методики ентропійного кодування. У разі заснованого на контексті ентропійного кодування контекст може бути заснований на сусідніх блоках. Після ентропійного кодування модулем 56 ентропійного кодування закодований потік бітів може бути переданий на інший пристрій (наприклад, відео декодер 30) або заархіваваний для пізнішої передачі або пошуку.

[0134] Модуль 58 зворотного квантування і блок обробки зворотного перетворення 60 застосовує зворотне квантування і зворотне перетворення, відповідно, щоб відновити залишковий блок в пиксельн�ія може обчислити опорний блок, додаючи залишковий блок до предсказивающему блоку одній з картинок з пам'яті 64 опорних картинок. Модуль 44 компенсації руху може також застосувати один або більше фільтрів інтерполяції до відновленої залишковим блоку, щоб обчислити суб-цілочисельні піксельні значення для використання при оцінці руху. Суматор 62 додає відновлений залишковий блок до блоку передбачення з скомпенсированним рухом, зробленому модулем 44 компенсації руху, щоб сформувати відновлений відео блок для збереження в пам'яті 64 опорних картинок. Відновлений відео блок може бути використаний модулем 42 оцінки руху/диспарантности і модулем 44 компенсації руху як опорний блок, щоб зовні кодувати блок в наступній картинці.

[0135] Відео кодер 20 може генерувати ряд елементів синтаксису, як описано вище, який може бути закодований блоком 56 ентропійного кодування або іншим блоком кодування відео кодера 20. В деяких прикладах відео кодер 20 може генерувати і кодувати елементи синтаксису для потоку бітів MVC, як описано вище.

[0136] Як зазначено вище, ідентифікатор виду може бути включений в заголовок одиниці NAL, щоб идентифициров� NAL, який займає відносно велику частину потоку бітів. Згідно з аспектів цього розкриття, відео кодер 20 може сигналізувати порядковий індекс виду у якості частини заголовка одиниці NAL. Таким чином, відео кодер 20 може замінити id виду, який зазвичай може бути сигналізований в заголовку одиниці NAL, порядковим індексом виду. Порядковий індекс виду може описати порядок декодування відповідного компонента виду одиниці доступу. Порядковий індекс виду може бути використаний зі значенням POC або значенням кадру, щоб ідентифікувати компонент виду потоку бітів. Відео кодер 20 може також генерувати SPS, який забезпечує індикацію відносин між id видів для видів і порядкових індексів виду для згаданих видів. Наприклад, відео кодер 20 може генерувати таблицю відображення, яка відображає значення view_id в значення порядкового індексу виду, і включати таку таблицю відображення в SPS. В інших прикладах відео кодер 20 може вказувати відносини між id видів і порядкові індекси виду в альтернативному способі.

[0137] Відео кодер 20 може також уникнути кодування одиниці NAL префікса, яка може типово бути включена безпосередньо перед базовим видом. Замість�ормацию, необхідну для відео декодера 30, щоб асоціювати конкретний компонент виду з конкретним видом і з відповідним тимчасовим місцем розташування (наприклад, заданим за замовчуванням індексом порядку базових видів, рівним нулю). В деяких прикладах відео кодер 20 може додати прапор до заголовка одиниці NAL базового виду, щоб визначити, чи компонент виду (цієї конкретної одиниці NAL) бути використаний для зовнішнього передбачення компоненти вигляду інших видів потоку бітів.

[0138] Згідно з аспектів цього розкриття, відео кодер 20 може сигналізувати залежності видів для кожного виду зазвичай для всіх компонентів виду, незалежно від того, призначені чи компоненти виду для картинок з прив'язкою і картинок без прив'язки і належать компоненти виду Списком 0 або Списку 1. В деяких прикладах відео кодер 20 може включати індикацію у SPS, яка ідентифікує різні залежно видів для картинок з прив'язкою і картинок без прив'язки.

[0139] Згідно з іншим аспектам цього розкриття, замість того, щоб сигналізувати priority_id в заголовку одиниці NAL, відео кодер 20 може забезпечити значення priority_id в SPS. Таким чином, priority_id для кожного виду з деяким часовим рівнем може бия з єдиним проходом може бути дозволена, поки сигналізація контексту, асоційованого з адаптацією, відома. Крім того, відео кодер 20 може сигналізувати інформацію рівня виду в SPS.

[0140] ФІГ. 3 є блок-схема, що ілюструє приблизний декодер відео 30, який може реалізувати способи, описані в цьому розкритті для декодування потоку бітів множинних видів. У прикладі згідно ФІГ. 3, відео декодер 30 включає в себе модуль 80 ентропійного декодування, модуль 81 передбачення, що має модуль 82 компенсації руху і модуль 84 внутрішнього передбачення, модуль 86 зворотного квантування, модуль 88 зворотного перетворення, суматор 90, та пам'ять 92 опорних картинок.

[0141] Під час процесу декодування відео декодер 30 приймає закодований відео потік бітів, який представляє відео блоки закодованої відео вирізки і асоційовані елементи синтаксису, від відео кодера 20. Модуль 80 ентропійного декодування відео декодера 30 ентропійно декодує потік бітів, щоб генерувати квантовані коефіцієнти, вектора руху, і інші елементи синтаксису. Модуль 80 ентропійного декодування направляє вектора руху і інші елементи синтаксису до модулю 81 передбачення. Відео декодер 30 може п30 може прийняти ряд одиниць NAL, мають заголовок одиниці NAL, який ідентифікує тип даних, збережених в одиниці NAL (наприклад, даних VCL і не-VCL даних). Набори параметрів можуть містити інформацію заголовка рівня послідовності, таку як SPS, PPS, чи інший набір параметрів, описаний вище.

[0143] Згідно з аспектів цього розкриття, відео декодер 30 може прийняти порядковий індекс виду у якості частини заголовка одиниці NAL. Таким чином, відео декодер 30 може прийняти порядковий індекс виду, а не id виду, який зазвичай може бути сигналізований в заголовку одиниці NAL. Порядковий індекс виду може описати порядок декодування відповідного компонента виду одиниці доступу. Крім того, відео декодер 30 може прийняти інформацію, що вказує відносини між прийнятим порядковим індексом виду і відповідним id виду. Ця інформація може включати в себе, наприклад, таблицю відображення, яка відображає значення view_id, на значення порядкового індексу виду. У цьому способі відео декодер 30 може просто прийняти значення порядкового індексу виду в заголовку одиниці NAL і визначити view_id одиниці NAL, використовуючи таблицю відображення. В деяких прикладах інформація відносин може бути прийнята в SPS. Відео декодер 3�тоби ідентифікувати компонент виду потоку бітів.

[0144] У деяких прикладах, згідно з аспектів цього розкриття, відео декодер 30 може не приймати одиниці NAL префікса, який може типово бути включений безпосередньо перед базовим видом. Замість цього відео декодер 30 може прийняти temporal_id в заголовку одиниці NAL, який може надати всю інформацію, необхідну для відео декодера 30, щоб асоціювати конкретний компонент виду з конкретним видом і з відповідним тимчасовим місцем розташування (наприклад, заданий за замовчуванням індекс порядку базових видів рівний нулю). В деяких прикладах відео декодер 30 може прийняти прапор в заголовку одиниці NAL базового виду, щоб визначити, чи компонент виду (цієї конкретної одиниці NAL) бути використаний для зовнішнього передбачення компонентів вигляду інших видів потоку бітів.

[0145] Згідно з аспектів цього розкриття, відео декодер 30 може також прийняти залежності видів для кожного виду зазвичай для всіх компонентів виду, незалежно від того, призначені чи компоненти виду для картинок з прив'язкою і картинок без прив'язки, і незалежно від того, буде чи компонент виду включений в Список 0 або Список 1. В деяких прикладах відео декодер 30 може прийняти індикацію у SPS, який ідентиф�м аспектів цього розкриття, замість того, щоб сигналізувати priority_id в заголовку одиниці NAL, відео кодер 20 може забезпечити значення priority_id в SPS. Крім того, згідно з аспектів цього розкриття, адаптація з єдиним проходом може бути вирішена, поки сигнальний контекст, асоційований з адаптацією, відомий. Відео декодер 30 може також прийняти деяку інформацію рівня виду в SPS.

[0147] Коли відео вирізка закодована як внутрішньо кодований (I) вирізка, модуль 84 внутрішнього передбачення з модуля 81 передбачення може генерувати дані передбачення для відео блоку поточної відео вирізки на підставі сигнализированного режиму внутрішнього передбачення і даних від раніше декодованих блоків поточної картинки. Коли картинка закодована як зовні кодований (тобто, B, P або GPB) вирізка, модуль 84 внутрішнього передбачення з модуля 81 передбачення формує пророкує блоки для відео блоку поточної відео вирізки на підставі вектора руху та інших елементів синтаксису, прийнятих від модуля 80 ентропійного декодування. Пророкують блоки можуть бути зроблені з однією з опорних картинок в межах одного зі списків опорних картинок. Відео декодер 30 може конструювати списки �щення, на підставі опорних зображень, збережених у пам'яті 92 опорних картинок.

[0148] Модуль 82 компенсації руху визначає інформацію передбачення для відео блоку поточної відео вирізки, синтаксично розбираючи вектора руху і інші елементи синтаксису, і використовує інформацію передбачення, щоб сформувати пророкує блоки для поточного відео декодируемого блоку. Наприклад, модуль 82 компенсації руху використовує деякі з прийнятих елементів синтаксису, щоб визначити режим передбачення (наприклад, внутрішнє або зовнішнє передбачення), використаний для кодування відео блоків відео вирізки, тип вирізки зовнішнього передбачення (наприклад, B вирізка, P вирізка, або вирізка GPB), інформацію для побудови однієї чи більше списків опорних картинок для вирізки, вектори руху для кожного зовні кодованого відео блоку вирізки, статус зовнішнього передбачення для кожного зовні кодованого відео блоку вирізки, та іншу інформацію, щоб декодувати відео блоки в поточній відео вирізці.

[0149] Модуль 86 зворотного квантування назад квантует, тобто, деквантует, квантовані коефіцієнти перетворення, надані в потоці бітів і декодированние модулем 80 энтования, обчисленого відео кодером 20 для кожного відео блоку відео вирізки, щоб визначити ступінь квантування і, аналогічно, ступінь зворотного квантування, яке повинно бути застосоване.

[0150] Модуль 88 обробки зворотного перетворення зворотне перетворення, наприклад, зворотне DCT, зворотне ціле перетворення, або концептуально подібний процес зворотного перетворення, до коефіцієнтів перетворення, щоб сформувати залишкові блоки в піксельної області. Згідно з аспектів цього розкриття, модуль 88 обробки зворотного перетворення може задавати спосіб, у якому перетворення були застосовані до залишковим даними. Таким чином, наприклад, модуль 88 обробки зворотного перетворення може задавати RQT, який представляє спосіб, у якому перетворення (наприклад, DCT, цілочисельне перетворення, вейвлет перетворення, або один або більше інших перетворень), були застосовані до залишковим вибірках яскравості і залишковим вибірках насиченості кольору, асоційованих з блоком прийнятих відео даних.

[0151] Після того, як модуль 82 компенсації руху згенерував пророкує блок для поточного блоку відео на підставі вектора руху і �від модуля 88 обробки зворотного перетворення з відповідними передбачаючими блоками, генеруються модулем 82 компенсації руху. Суматор 90 являє компонент або компоненти, які виконують цю операцію підсумовування. Якщо бажано, фільтр видалення блочності може також бути застосований, щоб фільтрувати декодированние блоки, щоб видалити артефакти блочності. Інші контурні фільтри (або в контурі кодування або після кодування контуру) також можуть бути використані для згладжування піксельних переходів, або інакше поліпшити якість відео. Декодированние відео блоки в заданій картинці потім зберігають у пам'яті 92 опорних картинок, яка зберігає опорні картинки, які використовуються для подальшої компенсації руху. Пам'ять 92 опорних картинок також зберігає декодированное відео для більш пізнього подання на пристрої відображення, такі як пристрій 32 відображення згідно ФІГ. 1.

[0152] ФІГ. 4 є концептуальною діаграму, що ілюструє приклад шаблону передбачення MVC. У прикладі згідно ФІГ. 4 ілюстровані вісім видів, і дванадцять часових розташувань ілюстровані для кожного виду. В цілому кожен рядок на фіг. 4 відповідає увазі, у той час як кожна колонка вказує тимчасове розташування. Кожен із видів може бути идого розташування камери щодо інших видів. У прикладі, показаному на фіг. 4, ідентифікатори виду позначені як "S0"-"S7", хоча можуть також використовуватися числові ідентифікатори виду. Крім того, кожне з тимчасових пунктів може бути ідентифіковано, використовуючи значення відлік порядку картинки (POC), яке вказує на порядок відображення картинок. У прикладі, показаному на фіг. 4, значення POC позначені як "T0"-"T11".

[0153] Хоча MVC має так званий базовий вид, який є декодируемим декодерами H. 264/AVC, і пара стерео видів може бути підтримана за допомогою MVC, MVC може підтримувати більше ніж два види як введення 3D відео. Відповідно, модуль відтворення клієнта, має декодер MVC, може очікувати контент відео 3D з численними видами.

[0154] Картинки на фіг. 4 позначені, використовуючи заштрихований блок, що включає в себе символ, що позначає, є кодованої відповідна картинка внутрішньо (тобто I-кадр), або зовні кодованої в одному напрямі (тобто, як P-кадр) або у різноманітних напрямках (тобто, як B-кадр). В цілому передбачення позначені стрілками, де вказується картинка використовує вказівку від об'єкта для посилання передбачення. Наприклад, P-кадр виду S2 у тимчасове місце� фіг. 4, може згадуватися як компонент виду. Таким чином, компонент виду для виду відповідає конкретному тимчасовому примірнику виду.

[0155] Як і з кодуванням єдиного виду відео, картинки послідовності відео з численними видами можуть бути закодовані з прогнозом щодо картинок в різних часових розташувань. Наприклад, b-кадр виду S0 у тимчасовому розташуванні T1 має стрілку, що вказує на неї від I-кадру виду S0 у тимчасовому розташуванні T0, вказуючи, що b-кадр передбачений з I-кадру. Додатково, однак, в контексті кодування відео з численними видами картинки можуть бути передбачені між видами. Таким чином, компонент виду може використовувати компоненти виду в інших видах посилання. У MVC, наприклад, реалізується передбачення між видами, як якщо компонент виду в іншому вигляді є посиланням зовнішнього передбачення. Потенційні посилання між видами можуть бути сигнализировани в розширенні MVC SPS й можуть бути змінені процесом конструювання списку опорних зображень, який забезпечує гнучкий порядок зовнішнього передбачення або посилань передбачення між видами.

[0156] ФІГ. 4 забезпечує різні приклади передбачення між виду�енних розташування вигляду S1, так само як передбачувані між видами з картинок для картинок видів S0 і S2 в одних і тих же часових розташувань. Наприклад, b-кадр вигляду S1 у тимчасовому розташуванні T1 передбачений з кожного з B-кадрів вигляду S1 у тимчасових місцях розташування T0 і T2, так само як b-кадри видів S0 і S2 у тимчасовому розташуванні T1.

[0157] У прикладі згідно ФІГ. 4, заголовна буква "B" і рядкові букви "b" призначені, щоб вказувати різні ієрархічні відносини між картинками, а не різні методології кодування. В цілому кадри із заголовною буквою "B" є відносно вище в ієрархії передбачення ніж кадри з рядковими літерами "b". ФІГ. 4 також ілюструє зміни в ієрархії передбачення, використовуючи різні рівні штрихування, де велика ступінь штрихування (тобто, відносно більш темні) картинки є більш високою в ієрархії передбачення, ніж картинки, мають менше штрихування (тобто, щодо світліше). Наприклад, всі I-кадри на фіг. 4 ілюстровані з заповнює штрихуванням, в той час як P-кадри мають кілька світлішу штрихування, і B-кадри (і b-кадри з рядковими літерами) мають різні рівні штрихування один відносно одного, але завжди світліше, ніж штрихування P-кадротносительно вищі в ієрархії передбачення повинні бути декодованими перш, чим декодованими картинки, які є відносно більш низькими в ієрархії, таким чином що ці картинки відносно вищі в ієрархії можуть використовуватися в якості опорних картинок під час декодування картинок щодо більш низьких в ієрархії. Порядковий індекс виду є індексом, який вказує порядок декодування компонентів виду в одиниці доступу. Порядкові індекси виду можуть матися на увазі в наборі параметрів, такому як SPS.

[0159] У цьому способі зображення, використовувані в якості опорних картинок, можуть бути декодованими перш, ніж декодованими картинки, які закодовані з посиланнями на опорні картинки. Порядковий індекс виду є індексом, який вказує порядок декодування компонентів виду в одиниці доступу. Згідно MVC/AVC, для кожного порядкового індексу i видів, сигналізується відповідний view_id. Декодування компонентів виду слід зростаючому порядку порядкових індексів виду. Якщо всі види представлені, то набір кількісних індексів виду містить послідовно впорядкований набір від нуля до менш, ніж повна кількість видів.

[0160] В деяких випадках частина всього потоку бітів може бути витягнутий, итов, які конкретні програми можуть вимагати, на підставі, наприклад, послуги, забезпеченої сервером, ємності, підтримки, і можливостями декодерів одного або більше клієнтів, та/або перевагою одного або більше клієнтів. Наприклад, клієнт може вимагати лише три види, і можуть бути два сценарії. В одному прикладі один клієнт може вимагати сприйняття гладкого перегляду і може віддати перевагу види зі значеннями view_id S0, S1, S2, у той час як інший клієнт може вимагати масштабованості виду віддати перевагу види зі значеннями view_id S0, S2, S4. Обидва з цих підпотоків бітів можуть бути декодованими як незалежні потоки бітів MVC і можуть підтримуватися одночасно.

[0161] В цілому позиція камери, орієнтація та геометричне відношення між різними видами можуть бути логічно виведені з ID Виду або Порядкового індексу виду. З цією метою і властиві і зовнішні параметри камери можуть бути включені в потік бітів, використовуючи повідомлення SEI отримання інформації множинних видів.

[0162] В той час як ФІГ. 4 показує вісім видів (S0-S7), як зазначено вище, розширення MVC/AVC підтримує до 1024 видів і використовує view_id в заголовку одиниці NAL, щоб ідентифікувати вид, якому належить одиниця NAL. Согловка одиниці NAL. Таким чином, в цілях порівняння порядковий індекс виду може замінити view_id, який сигналізований в заголовку одиниці NAL розширення MVC/AVC. Порядок видів зазвичай описує порядок видів в одиниці доступу, і порядковий індекс виду ідентифікує конкретний вид в порядку видів одиниці доступу. Таким чином, порядковий індекс виду описує порядок декодування відповідного компонента виду одиниці доступу.

[0163] Відповідно, згідно з аспектів цього розкриття, SPS може забезпечити відносини між view_ids для видів і порядкові індекси виду для згаданих видів. Використовуючи порядковий індекс виду і дані в SPS, відео кодер 20 і відео декодер 30 можуть замінити 10-бітовий view_id в MVC/AVC в заголовку одиниці NAL порядковим індексом виду, який може привести до економії бітів у порівнянні зі схемою MVC/AVC.

[0164] Приклад SPS, який забезпечує співвідношення між view_ids для видів і порядковими індексами виду, наданий в Таблиці 6 нижче:

Таблиця 6
РОЗШИРЕННЯ MVC НАБОРУ ПАРАМЕТРІВ ПОСЛІДОВНОСТІ
seq_parameter_set_mvc_extension(){0ue(v)
for(i=0; i<= num_views_minus1; i++){
view_id[i]0ue(v)
view_level[i]0ue(v)
}
for(i=1; i < = num_views_minus1; i++){
num_ref_views[i]0ue(v)
for(j=0; j<num_ref_views[i]; j++)
ref_view_idx[i][j]0ue(v)
}
num_level_values_signalled_minus10ue(v)
for(i=0; i<=num_level_values_signalled_minus1; i++){
level_idcd>0ue(v)
for(j=0; j<=num_applicable_ops_minus1[i]; j++){
applicable_op_temporal_id[i][j]0u(3)
applicable_op_num_target_views_minus1[i][j]0ue(v)
for(k=0; k<= applicable_op_num_target_views_minus1[i][j]; k++)
applicable_op_target_view_idx[i][j][k]0ue(v)
applicable_op_num_views_minus1[i][j]0ue(v)
}
}
}

[0165] У прикладі, наведеному в Таблиці 6, виділені жирним шрифтом і курсивом елементи синтаксису вказують відступу від синтаксису SPS MVC/AVC, тобто, щодо модифікації з�ганною відео послідовності. SPS також задає значення рівня для поднабора робочих точок для закодованої відео послідовності. Всі SPS, на які посилаються за допомогою кодованої відео послідовності, повинні бути ідентичними. Однак, деякі види, ідентифіковані за допомогою view_id [i], можуть не бути присутніми в цій кодованої відео послідовності. Крім того, деякі види або тимчасові поднабори, описані за допомогою SPS, можуть бути видалені з первісної закодованої відео послідовності, і таким чином, можуть не бути присутніми в кодованої відео послідовності. Інформація в SPS, однак, завжди може застосовуватися до інших видів і тимчасовим поднаборам.

[0166] В Таблиці 6 вище, елемент num_views_minus1 плюс 1 може задавати максимальну кількість закодованих видів в закодованій відео послідовності. Значення num_view_minus1 може бути в діапазоні від 0 до 31, включно. У деяких випадках фактичне кількість видів в закодованій відео послідовності може бути менше ніж num_views_minus1 плюс 1. Елемент view_id [i] може задавати ідентифікатор виду для виду з порядковим індексом виду, рівним i. Елемент view_level [i] може задавати view_level виду з порядковим індексом виду, равниируемими без декодування компонента виду з view_level більшим ніж VL.

[0167] Згідно з аспектів цього розкриття, елемент num_ref_views [i] може задавати кількість компонентів виду для передбачення між видами в початковому списку опорних картинок RefPicList0 і RefPicList1 при декодуванні компонентів виду з порядковим індексом виду, рівним i. Значення елемента num_ref_views [i] може бути не більше ніж Min(15, num_views_minus1). Значення num_ref_views [0] може бути рівним 0. Крім того, згідно з аспектів цього розкриття, елемент ref_view_idx [i] [j] може поставити порядковий індекс виду j-го компонента виду для передбачення між видами в початковому списку опорних картинок RefPicList0 і RefPicList1 при декодуванні компонента виду з порядковим індексом виду, рівним i. Значення ref_view_idx [i] [j] може бути в діапазоні від 0 до 31, включно.

[0168] Відповідно, в різних аспектах цього розкриття залежності видів для картинок з прив'язкою і картинок без прив'язки можуть більше не вимагатися бути окремо підтримуваними і сигнализированними. Таким чином, відео кодер 20 і/або відео кодер 30 можуть використовувати єдиний список опорних картинок (або підтримувати два списку опорних малюнків, Список 0 і Список 1) для картинок з прив'язкою і картинок без прив'язки аналогічно. Таким чином, як показано в Та�цього SPS включає в себе ref_view_idx, який може бути використаний для побудови і 0 Списку та Списку 1 для компонентів виду.

[0169] Згідно з таким аспектам цього розкриття, наприклад, відео декодер 30 може прийняти для будь-якого компонента виду перший вид, інформацію опорного виду, вказує один або більше опорних видів для передбачення компонентів виду першого виду. Таким чином, відео декодер 30 може прийняти опорну інформацію виду, що вказує залежності видів для картинок з прив'язкою виду і картинок без прив'язки виду аналогічно. При декодуванні конкретної картинки (одиниці доступу) конкретного виду потім відео декодер 30 може включати опорні кандидати (наприклад, компоненти виду, з яких конкретна картинка може бути передбачена) з однієї і тієї ж одиниці доступу в якості конкретної картинки і від опорних видів, зазначених інформацією опорного виду. У деяких випадках відео декодер 30 може додати опорних кандидатів до списку опорних картинок з кожного опорного виду, так що кількість опорних кандидатів дорівнює кількості опорних видів. Крім того, відео декодер 30 може додати опорних кандидатів до або Списком 1, Списком 0, або обох. Відео декодер 30 може декодувати конкретну картинку на ость між видами для компонентів виду без прив'язки може бути більше не сигнализирована в SPS як підмножину залежності між видами для компонентів виду з прив'язкою. Замість цього компонент виду для виду з прив'язкою може бути передбачений від більше ніж одного іншого виду, такого як вид 3 і 4, і вигляд без прив'язки може також бути передбачений з картинок види 3 та види 4. Якщо додаткове обмеження обмеження залежно видів бажано для картинок без прив'язки, таке обмеження може бути надано додаткової сигналізації, такий як повідомлення SEI.

[0171] Елемент num_level_values_signalled_minus1 плюс 1 може задавати кількість значень рівня, сигнализированних для закодованої відео послідовності. Значення num_level_values_signalled_minus1 може бути в діапазоні від 0 до 63, включно. Елемент level_idc [i] може задавати i-е значення рівня, сигнализированное для закодованої відео послідовності. Елемент num_applicable_ops_minus1 [i] плюс 1 може задавати кількість робочих точок, до яких рівень, зазначений допомогою level_idc [i], що застосовується. Значення елемента num_applicable_ops_minus1 [i] може бути в діапазоні від 0 до 1023, включно. Елемент applicable_op_temporal_id [i] [j] може задавати temporal_id для j-ї робочої точки, до якого рівень, зазначений допомогою level_idc [i], що застосовується. Елемент applicable_op_num_target_views_minus1 [i] [j] + 1 може задавати кількість цільових видів виводу для j-ї робочої точки, до ет бути в діапазоні від 0 до 1023, включно.

[0172] Елемент applicable_op_target_view_idx [i] [j] [k] може задавати порядковий індекс виду k-го виду цільового виводу для j-ї робочої точки, до якого рівень, зазначений допомогою level_idc [i], що застосовується. Значення елемента applicable_op_target_view_idx [i] [j] [k] може бути в діапазоні від 0 до 31, включно. applicable_op_num_views_minus1 [i] [j] + 1 може задавати кількість видів, необхідних для декодування цільових видів висновку, що відповідають j-й робочій точці, до якого рівень, зазначений допомогою level_idc [i], що застосовується. Кількість видів, визначених за допомогою applicable_op_num_views_minus1, може включати в себе цільові види виводу і краєвиди, від яких цільові види виведення залежать, як визначено процесом вилучення подпотока бітів.

[0173] В іншому прикладі, згідно з аспектів цього розкриття, значення ref_view_idx [i] [j] може вимагатися бути меншим ніж i, на підставі порядку декодування компонентів виду в одному і тому ж моменті часу.

[0174] ref_view_idx [i] [j] може бути далі зменшений в розмірі (для додаткових економій бітів порівняно з MVC/AVC). Наприклад, додаткові економії бітів можуть бути досягнуті в потоці MVC, який включає в себе лише два види (тобто, для стерео відео). У цьому прикладі порядковий індекс 0) до декодування другого виду (наприклад, вид 1). Приклад, зменшений SPS, наданий в Таблиці 7 нижче:

Таблиця 7
РОЗШИРЕННЯ MVC НАБОРУ ПАРАМЕТРА ПОСЛІДОВНОСТІ
seq_parameter_set_mvc_extension(){CДескриптор
...0ue(v)
for(i=1; i < = num_views_minus1; i++){
num_ref_views[i]0ue(v)
for(j=0; j<num_ref_views[i]; j++)
ref_view_idx_diff_minus1[i][j]0ue(v)
...

[0175] У прикладі, наведеному в Таблиці 7, елемент ref_view_idx_diff_minus1 [i] [j] плюс i+1 може задавати порядковий індекс виду j-го компонента виду для передбачення між видами в початковому списку опорних картинок RefPicList0 і Re[i] [j] може бути в діапазоні від 0 до 30-i, включно.

[0176] Інші приклади також можливі. Наприклад, замість того, щоб сигналізувати залежність видів у SPS (як у прикладах, наведених у Таблицях 6 і 7 вище), залежність видів може бути сигнализирована в PPS. В іншому прикладі залежність видів може бути сигнализирована в SPS, і залежність видів може бути далі сигнализирована в PPS, який знаходиться в області залежно від виду, повідомленого в наборі параметрів послідовності. Наприклад, у SPS, залежний вид (наприклад, вигляд 2) може бути сигналізований як є залежним від виду 0 і виду 1, в той час як в PPS залежний вид (наприклад, вигляд 2) може бути сигналізований як тільки є залежним від виду 0.

[0177] Згідно деяким аспектам цього розкриття побудова списку опорних картинок і перегрупування можуть бути змінені порівняно з MVC/AVC. Наприклад, згідно з аспектів цього розкриття, індекс (view_idx) виду, описаний вище, може бути використаний під час складання переліку опорних картинок і/або переупорядочения. Приблизний синтаксис модифікації MVC списку опорних картинок надано у Таблицях 8 і 9 нижче:

ref_pic_list_mvc_modification(){}while(modification_of_pic_nums_idc!=3)
Таблиця 8CДескриптор
if(slice_type % 5 !=2 && slice_type% 5 !=4){
ref_pic_list_modification_flag_l02u(1)
f(ref_pic_list_modification_flag_l0)
do{
modification_of_pic_nums_idc2ue(v)
if(modification_of_pic_nums_idc= =0 ||modification_of_pic_nums_idc==1)
abs_diff_pic_num_minus12ue(v)
else if(modification_of_pic_nums_idc = = 2)
long_term_pic_num2ue(v)
else if (modification_of_pic_nums_idc= =4 ||modification_of_pic_nums_idc= =5)
}
if(slice_type % 5= =1){
ref_pic_list_modification_flag_l12u(1)
if(ref_pic_list_modification_flag_l1)
do{
modification_of_pic_nums_idc2ue(v)
if(modification_of_pic_nums_idc== 0 ||modification_of_pic_nums_idc = = 1)
abs_diff_pic_num_minus12ue(v)
else if(modification_of_pic_nums_idc = = 2)
long_term_pic_num2ue(v)
else if (modification_of_pic_nums_idc= =4 ||modification_of_pic_nums_idc>td align="center">2ue(v)
}while(modification_of_pic_nums_idc !=3)
}
}

Таблиця 9
МОДИФІКАЦІЯ СПИСКУ ОПОРНИХ КАРТИНОК MVC
modification_of_pic_nums_idcМодифікація задана
4abs_diff_inter_view_minus1 представлений і відповідає різниці для вирахування із значення передбачення опорного індексу між видами
5abs_diff_inter_view_minus1 представлений і відповідає різниці для додавання до значення передбачення опорного індексу між видами

[0178] В Таблицях 8 та 9 елемент modification_of_pic_nums_idc разом з abs_diff_pic_num_minus1, long_term_pic_num, або abs_diff_view_idx_minus1 може задавати, яка з опорних картинок або опорних компонентів тільки між видами я�орним індексом між видами, щоб розмістити поточний індекс у списку опорних картинок і значенням передбачення опорного індексу між видами.

[0179] В іншому прикладі, згідно з аспектів цього розкриття, inter_view_index опорної посилання між видами може бути безпосередньо сигналізований. Такий синтаксис модифікації MVC списку опорних картинок надано у Таблицях 10 і 11 нижче:

">
Таблиця 10
МОДИФІКАЦІЯ СПИСКУ ОПОРНИХ КАРТИНОК MVC
ref_pic_list_mvc_modification(){CДескриптор
if(slice_type % 5 !=2 && slice_type % 5 !=4){
ref_pic_list_modification_flag_l02u(1)
if(ref_pic_list_modification_flag_l0)
do{
modification_of_pic_nums_idc2ue(v)
abs_diff_pic_num_minus12ue(v)
else if(modification_of_pic_nums_idc= =2)
long_term_pic_num2ue(v)
else if (modification_of_pic_nums_idc= =4)
inter_view_index2ue(v)
}while(modification_of_pic_nums_idc !=3)
}
if(slice_type % 5= =1){
ref_pic_list_modification_flag_l12u(1)
if(ref_pic_list_modification_flag_l1)
do{
modification_of_pic_nums_idc
abs_diff_pic_num_minus12ue(v)
else if(modification_of_pic_nums_idc= =2)
long_term_pic_num2ue(v)
else if (modification_of_pic_nums_idc= =4)
inter_view_index2ue(v)
}while(modification_of_pic_nums_idc !=3)
}
}

Таблиця 11
МОДИФІКАЦІЯ СПИСКУ ОПОРНИХ КАРТИНОК MVC
modification_of_pic_nums_idcМодифікація задана
[0180] У Таблицях 10 і 11 опорна картинка між видами може бути ідентифікована за допомогою inter_view_index наступним чином:

VOIdx=ref_view_idx[CurrVOIdx][inter_view_index]

де CurrVOIdx є порядковим індексом виду поточного компонента виду. Враховуючи значення POC поточної картинки, POC і VOIdx можуть бути використані для ідентифікації опорної картинки між видами.

[0181] У деяких прикладах MVC процес декодування для побудови списків опорних картинок може бути викликаний до початку процесу декодування для кожної P, SP або B вирізки. Під час виклику цього процесу тільки опорні картинки, що мають одне і те ж значення view_idx в якості поточної вирізки можуть бути розглянуті. Декодированние опорні картинки можуть бути позначені як "використовується для короткострокової посилання", або " використовується для довгострокової посилання." Короткострокові опорні картинки можуть бути ідентифіковані значеннями frame_num і view_idx, і, для опорних картинок між видами - додатково PicOrderCnt (). Довгостроковими опорним картинок можна призначити довгостроковий індекс кадру і ідентифіковані значеннями довгострокового індексу кадру, view_idx, і, для опорних картинок між видами, додатково - PicOrderCnt ().

[0182] На додаток до опорних ка�ечени під час процесу маркування опорної картинки), можуть також бути включені в список опорних картинок. Тільки опорні компоненти між видами можуть бути ідентифіковані значенням view_idx і PicOrderCnt ().

[0183] Під час виклику процесу побудови списку опорних картинок наступний процес, ідентифікований MVC/AVC як підпункт 8.2.4.1, може бути викликаний, щоб поставити:

* призначення змінних FrameNum, FrameNumWrap, і PicNum кожної з короткострокових опорних картинок, і

* призначення змінної LongTermPicNum кожної з довгострокових опорних картинок.

[0184] Опорні картинки і, коли присутні, тільки опорні компоненти між видами, адресуються з допомогою опорні індекси. Опорний індекс є індексом у список опорних картинок. При декодуванні P або SP вирізки є єдиний список опорних картинок RefPicList0. При декодуванні вирізки B, є другий незалежний список опорних картинок RefPicList1 на додаток до RefPicList0.

[0185] На початку процесу декодування для кожної вирізки список опорних картинок RefPicList0, і для вирізок B - RefPicList1, може бути отриманий як визначено наступними впорядкованими етапами:

1. Початковий список опорних картинок RefPicList0 і для вирізок B - RefPicList1 отримують як визначено у підпункті 8.2.4.2 MVC/AVC.

2. Опорні картинки між видами�ирезок B RefPicList1, як визначено у підпункті 6.4.1 (сформульований нижче).

3. Коли ref_pic_list_modification_flag_l0 дорівнює 1 або при декодуванні вирізки B, ref_pic_list_modification_flag_l1 дорівнює 1, список опорних картинок RefPicList0 і для вирізок B RefPicList1 модифікують як визначено у підпункті 6.4.2 (сформульовано нижче).

[0186] Крім того, кількість записів в модифікованому списку опорних картинок RefPicList0 одно num_ref_idx_l0_active_minus1 + 1, і для вирізок B кількість записів в модифікованому списку опорних картинок, RefPicList1, одно num_ref_idx_l1_active_minus1 + 1. Опорна картинка або тільки опорний компонент між видами може з'явитися в більш ніж одному індексі в модифікованих списках опорних картинок RefPicList0 або RefPicList1.

[0187] Під час виклику процесу, визначеного у підпункті 6.4.1, може не існувати посилання передбачення між видами, приєднана до RefPicListX (з X рівним 0 або 1). Однак, посилання передбачення між видами, що не існує, не може бути в модифікованому RefPicListX після виклику процесу, визначеного у підпункті 6.4.2 (сформульовано нижче).

[0188] В одному прикладі підпункт 6.4.1 сформульовано нижче, який включає в себе процес ініціалізації для списку опорних картинок для посилань передбачення між видами:

* Вхідними даними до пов�в, яка була декодована з seq_parameter_set_mvc_extension ().

* Вихідними даними цього процесу є можливо модифікований список опорних картинок RefPicListX, який все ще згадується як intial список опорних картинок RefPicListX.

* При i, що є значенням view_idx для поточної вирізки, опорні картинки між видами і тільки опорні компоненти між видами приєднуються до списку опорних картинок, як визначено нижче:

* Для кожного значення опорного індексу між видами j від 0 до num_ref_views [i] − 1 включно, в порядку зростання j, посилання передбачення між видами з view_idx рівним ref_view_idx [i] [j] з тієї ж одиниці доступу, як і поточна вирізка, приєднується до RefPicListX.

[0189] В одному прикладі підпункт 6.4.2 сформульовано нижче, який включає в себе процес модифікації для списків опорних картинок:

* Вхідними даними до цього процесу є список опорних картинок RefPicList0 і при декодуванні вирізки B, також список опорних картинок RefPicList1.

* Вихідними даними цього процесу є можливо модифікований список опорних картинок RefPicList0 і при декодуванні вирізки B, також можливо модифікований список опорних картинок RefPicList1.

* Коли ref_pic_list_modification_flag_l0 дорівнює 1, задаються сліду�льно встановлений рівним 0.

2. Відповідні елементи modification_of_pic_nums_idc синтаксису обробляють в порядку, в якому вони мають місце в потоці бітів. Для кожного з цих елементів синтаксису застосовується наступне:

- Якщо modification_of_pic_nums_idc дорівнює 0 або дорівнює 1, процес, визначений у підпункті 6.4.2.1 (сформульований нижче), викликається з RefPicList0 і refIdxL0, заданими як введено, і висновок призначається в RefPicList0 і refIdxL0.

- Інакше, якщо modification_of_pic_nums_idc дорівнює 2, процес, визначений у підпункті 6.4.2.2 (сформульований нижче), викликається з RefPicList0 і refIdxL0, заданими як введено, і висновок призначається в RefPicList0 і refIdxL0.

- Інакше, якщо modification_of_pic_nums_idc дорівнює 4 або дорівнює 5, процес, визначений у підпункті 6.4.2.3 (сформульований нижче), викликається з RefPicList0 і refIdxL0, заданими як введено, і висновок призначається в RefPicList0 і refIdxL0.

- Інакше (modification_of_pic_nums_idc 3), процес модифікації списку опорних картинок RefPicList0 закінчується.

* Коли ref_pic_list_modification_flag_l1 дорівнює 1, такі впорядковані етапи задаються:

1. Нехай refIdxL1 є індексом для списку опорних картинок RefPicList1. Спочатку він встановлений рівним 0.

2. Відповідні елементи синтаксису modification_of_pic_nums_idc обробляють в порядку, в якому вони мають місце в потоці бітів. Для кожного з цих ел� у підпункті 6.4.2.1 (сформульований нижче), викликається з RefPicList1 і refIdxL1, заданими як введено, і висновок призначається на RefPicList1 і refIdxL1.

- Інакше, якщо modification_of_pic_nums_idc дорівнює 2, процес, визначений у підпункті 6.4.2.2 (сформульований нижче), викликається з RefPicList1 і refIdxL1, заданими як введено, і висновок призначається на RefPicList1 і refIdxL1.

- Інакше, якщо modification_of_pic_nums_idc дорівнює 4 або дорівнює 5, процес, визначений у підпункті 6.4.2.3 (сформульований нижче), викликається з RefPicList1 і refIdxL1, заданими як введено, і висновок призначається на RefPicList1 і refIdxL1.

- Інакше (modification_of_pic_nums_idc 3), процес модифікації списку опорних картинок RefPicList1 закінчується.

[0190] У прикладі підпункт 6.4.2.1 сформульовано нижче, який включає в себе процес модифікації списку опорних картинок для короткострокових опорних картинок для зовнішнього передбачення:

* Вхідними даними до цього процесу є індекс refIdxLX і список опорних картинок RefPicListX (з X рівним 0 або 1).

* Вихідними даними цього процесу є збільшений індекс refIdxLX і модифікований список опорних картинок RefPicListX.

- змінна picNumLXNoWrap виходить наступним чином:

- Якщо modification_of_pic_nums_idc дорівнює 0,

if (picNumLXPred−(abs_diff_pic_num_minus1+1)<0)

picNumLXNoWrap=picNumLXPred−(abs_diff_pic_num_minus1+1) +MaxPicNum (h-1)

else

picNumLXNoWrap=picNumLXPred−(abs_diff_picum_minus1+1)− MaxPicNum (h-2)

else

picNumLXNoWrap=picNumLXPred+(abs_diff_pic_num_minus1+1)

де picNumLXPred є значенням передбачення для змінної picNumLXNoWrap. Коли процес, визначений у цьому підпункті, викликається перший раз для вирізки (тобто, для першого появи modification_of_pic_nums_idc рівним 0 або 1 в синтаксисі ref_pic_list_modification ()), picNumL0Pred і picNumL1Pred спочатку встановлюються рівними CurrPicNum. Після кожного присвоювання значення picNumLXNoWrap значення picNumLXNoWrap призначається на picNumLXPred.

[0191] У деяких прикладах мінлива picNumLX виходить, як визначено наступним псевдокодом:

if (picNumLXNoWrap>CurrPicNum)

picNumLX=picNumLXNoWrap-MaxPicNum (h-3)

else

picNumLX=picNumLXNoWrap

де picNumLX може бути рівним PicNum опорної картинки, яка позначена як "використовується для короткострокової посилання" і може бути рівним PicNum короткостроковій опорної картинки, яка відзначена як "неіснуюча". Наступний процес може бути виконаний, щоб помістити картинку з номером picNumLX короткостроковій картинки в позицію refIdxLX індексу, зсунути позицію будь-яких інших залишаються картинок до пізніше в списку, і збільшити значення refIdxLX:

for(cIdx=num_ref_idx_lX_active_minus1+1; cIdx>refIdxLX; cIdx − −)

RefPicListX[cIdx]=RefPicListX [cIdx−1]

RefPicListX[refIdxLX ++]=короткострокова опорна картинка з PicNum, рівним picNumLX

nIdx=refIdxLX

for(cIdx=refIdxLX[cIdx]

де функція viewIDX (refpic) повертає view_idx опорної картинки refpic, мінлива currViewIDX дорівнює view_idx поточної вирізки, і функція PicNumF (RefPicListX [cIdx]) виходить наступним чином:

- Якщо опорна картинка RefPicListX [cIdx] позначена як "використовується для короткострокової посилання", PicNumF (RefPicListX [cIdx]) дорівнює PicNum картинки RefPicListX [cIdx].

- Інакше (опорна картинка RefPicListX [cIdx] не позначена як "використовується для короткострокової посилання"), PicNumF (RefPicListX [cIdx]) дорівнює MaxPicNum.

[0192] В одному прикладі підпункт 6.4.2.2 сформульовано нижче, який включає в себе процес модифікації списку опорних картинок для довгострокових опорних картинок для зовнішнього передбачення:

* Вхідними даними до цього процесу є індекс refIdxLX (з X рівним 0 або 1) і список опорних картинок RefPicListX.

* Вихідними даними цього процесу є збільшений індекс refIdxLX і модифікований список опорних картинок RefPicListX.

* Наступна процедура проводиться, щоб помістити картинку з номером довгостроковій картинки long_term_pic_num в позицію refIdxLX індексу, зсунути позицію будь-яких інших залишаються картинок до пізніше в списку, і збільшити значення refIdxLX:

for(cIdx=num_ref_idx_lX_active_minus1+1; cIdx>refIdxLX; cIdx − −)

RefPicListX [cIdx]=RefPicListX [cIdx−1]

RefPicListX [refIdxLX ++]=довгострокова опорна картинка з L = long_term_pic_num | |

viewIDX (RefPicListX [cIdx])! = currViewIDX)

RefPicListX [nIdx ++]=RefPicListX [cIdx]

де функція viewIDX (refpic) повертає view_idx опорної картинки refpic, мінлива currViewIDX дорівнює view_idx поточної вирізки, і функція LongTermPicNumF (RefPicListX [cIdx]) може бути отримана наступним чином:

* Якщо опорна картинка RefPicListX [cIdx] відзначена як "використовується для довгострокової посилання", LongTermPicNumF (RefPicListX [cIdx]) дорівнює LongTermPicNum картинки RefPicListX [cIdx].

* Інакше (опорна картинка RefPicListX [cIdx] не позначена як "використовується для довгострокової посилання"), LongTermPicNumF (RefPicListX [cIdx]) дорівнює 2 * (MaxLongTermFrameIdx + 1).

[0193] У прикладі підпункт 6.4.2.3 сформульовано нижче, який включає в себе процес модифікації списку опорних картинок для опорних посилань передбачення між видами:

* Вхідними даними до цього процесу є список опорних картинок RefPicListX (з X рівним 0 або 1) і індекс refIdxLX у цьому списку.

* Вихідними даними цього процесу модифікований список опорних картинок RefPicListX (з X рівним 0 або 1) і збільшений індекс refIdxLX.

* Нехай currVOIdx є змінною VOIdx поточної вирізки. Змінна maxViewIdx встановлена рівною num_ref_views [currVOIdx].

* Змінна picInterViewIdxLX виходить наступним чином:

* Якщо modification_of_pic_nums_idc дорівнює 4,

if (picInterViewIdxLXPred − (abs_diff_inter_view_minus1 + 1) <0) picInterViewIdxLX=picInterVof_pic_nums_idc одно 5),

if (picInterViewIdxLXPred+(abs_diff_inter_view_minus1 + 1)> = maxViewIdx)

picInterViewIdxLX=picInterViewIdxLXPred+(abs_diff_inter_view_ minus1 + 1) − maxViewIdx (h-7)

else

picInterViewIdxLX=picInterViewIdxLXPred+(abs_diff_inter_view_minus1 + 1)

де picInterViewIdxLXPred - значення передбачення для змінної picInterViewIdxLX. Коли процес, визначений у цьому підпункті, викликається перший раз для RefPicList0 або RefPicList1 вирізки (тобто, для першого появи modification_of_pic_nums_idc, рівного 4 або 5 в синтаксисі ref_pic_list_modification ()), picInterViewIdxL0Pred і picInterViewIdxL1Pred можуть бути спочатку встановлені рівними -1. Після кожного присвоювання значення picInterViewIdxLX значення picInterViewIdxLX присвоюється до picInterViewIdxLXPred.

[0194] Потік бітів може не містити дані, які призводять до picInterViewIdxLX, рівного менше ніж 0, або picInterViewIdxLX, більшого ніж maxViewIdx. Змінна targetViewIDX може бути отримана наступним чином:

targetViewIDX=ref_view_idx [currVOIdx] [picInterViewIdxLX] (h-8)

[0195] Така процедура може бути проведена, щоб помістити посилання передбачення між видами з опорним індексом між видами, рівним picInterViewIdxLX, в позицію індексу refIdxLX і зсунути позицію будь-яких інших залишаються картинок до більш пізньої у списку:

for (cIdx=num_ref_idx_lX_active_minus1+1; cIdx> refIdxLX; cIdx − −)

RefPicListX [cIdx]=RefPicListX [cIdx − 1]

RefPicListX [refIdxLX ++] = посилання передбачення між видами з view_idx, рав�OrderCnt (RefPicListX [cIdx])! = currPOC)

RefPicListX [nIdx ++] = RefPicListX [cIdx]

де функція viewIDX (refpic) повертає view_idx опорної картинки refpic, мінлива currViewIDX дорівнює view_idx поточної вирізки, і змінна currPOC дорівнює PicOrderCnt () поточної вирізки.

[0196] У деяких прикладах процес за умовчанням може бути використаний для комбінування списків опорних картинок. Наприклад, процес комбінування списку опорних зображень за замовчуванням може включати в себе перевірку, якщо опорна картинка (або з RefPicList0 або з RefPicList1) є першою появою опорної картинки, яка додається до комбінований список. Щоб виконати таку перевірку, відео кодер (такий як відео кодер 20 або відео декодер 30) може порівняти поточну картинку CurrPic і будь-яку картинку PicA в списку, включаючи опорні картинки між видами і тимчасові опорні картинки. Порівняння може бути зроблено наступним чином.

if (ViewIDX (CurrPic)== ViewIDX (PicA) && POC (CurrPic)== POC (PicA))

return true;

else

return false;

[0197] ФІГ. 5A є концептуальною діаграму, що ілюструє приклад структури потоку бітів 100, який може бути використаний в реалізації одного або більше способів цього розкриття. Потік бітів 100 може відповідати стандарту кодування відео, такого як стандарт HEVC. Крім того, у неко�имере, показаному на фіг. 5A, потік 100 бітів включає в себе безліч одиниць доступу 102-1 - 102-N (все разом, одиниці доступу 102). Як зазначено вище, одиниці доступу 102 можуть включати в себе послідовність компонентів виду (відому як «види»), такі як види 104-1 - 104m (всі разом, види 104). В цілому одиниці доступу 102 включають в себе всі дані для загального часового моменту, наприклад, дані для одного компонента виду для кожного виду. В деяких прикладах кожна одиниця доступу з одиниць доступу 102 включає в себе однакову кількість видів 104. Декодування кожної одиниці доступу з одиниць доступу 102 може привести до однієї декодированной картинці для кожного виду. Одиниці доступу 102 можуть містити закодовані відео дані, які можуть бути використані для відтворення тривимірного відтворення відео.

[0199] ФІГ. 5B є концептуальною діаграму, що ілюструє приклад виду 104-N, який може бути включений у структуру потоку 100 бітів з ФІГ. 5A. В цілому кожен компонент виду в одиниці доступу (такому як види 104 в одиниці доступу 102-N) містить набір одиниць NAL рівня відео кодера/декодера (кодека) (VCL). Таким чином, у прикладі, показаному на фіг. 5B, вид 104-N включає в себе одиниці NAL 106-1 до 10це доступу таким чином, що k-й компонент виду в кожній одиниці доступу відповідає одному і тому ж виду. В інших прикладах вид 104-N, може включати в себе інші кількості одиниць NAL.

[0200] ФІГ. 5C є концептуальною діаграму, що ілюструє приклад одиниці NAL 108, яка може бути подібною за структурою одиницям NAL 106, показаним на фіг. 5B. Одиниця NAL 108 зазвичай включає в себе заголовок 110 одиниці NAL і корисні дані 112. Крім того, заголовок 110 одиниці NAL включає в себе першу частину 114 і розширення 116 заголовка одиниці NAL, які можуть відповідати розширенню MVC/AVC.

[0201] Наприклад, перша частина 114 включає в себе елемент ref_idc і елемент типу одиниці NAL. Елемент ref_idc може вказувати, використовується одиниця NAL як посилання для інших одиниць NAL. Наприклад, значення ref_idc 00 може вказувати, що контент NALU не використовується для відновлення збережених зображень (які можуть бути використані для наступного посилання). Такі NALU можуть бути відхилені, не ризикуючи цілісністю опорних картинок. Значення вище 00 можуть вказувати, що потрібно декодування NALU, щоб підтримувати цілісність опорних картинок. Елемент типу одиниці NAL може вказувати тип пакетів одиниці NAL 108.

[0202] Розширення 116 заголовка одиниці NAL зазвичай вклѻаг між видами (IVF). Як описано з посиланнями на фіг. 1 вище, прапор IDR може вказувати, чи належить одиниця NAL 108 картинці поточного оновлення декодування (IDR) або картинці IDR виду (V-IDR), яка може бути використана як точка довільного доступу закритій GOP. priority_id може бути використаний з процесом адаптації потоку бітів, який змінює потік бітів відповідно до мінливих умов мережі та/або можливостей відео декодера 30 та/або пристрої 32 відображення (наприклад, таким як процес адаптації з єдиним проходом). view_id може бути використаний для вказівки ідентифікатор виду для виду, до якого належить одиниця NAL. temporal_id може бути використаний для вказівки тимчасового рівня поточної одиниці NAL, яка може відповідати конкретній частоті кадрів. APF може бути використаний для визначення, чи належить одиниця NAL картинці з прив'язкою, яка може бути використана як точка довільного доступу відкритої GOP. IVF може бути використаний для вказівки, використовується одиниця NAL для передбачення між видами для одиниць NAL в інших видах.

[0203] Як описано вище, view_id MVC/AVC має довжину 10 бітів, і може бути використаний для унікальної ідентифікації більш ніж 1000 різних видів. В цілому однак, кількостей�єр, ФІГ. 4 включає в себе вісім видів для заданого мультимедійного контенту MVC. Так як заголовок 110 одиниці NAL включений для кожної одиниці NAL, view_id може споживати значну величину потоку бітів. Аспекти цього розкриття, як описано щодо прикладу, показаного на фіг. 5D, можуть видалити view_id з заголовка одиниці NAL, таким чином скорочуючи кількість бітів, необхідних для кодування відео даних MVC.

[0204] ФІГ. 5D є концептуальною діаграму, що ілюструє приблизну одиницю NAL 120, яка може бути подібною за структурою одиницям NAL 106, показаним на фіг. 5B. Приклад, показаний на фіг. 5D, ілюструє приклад одиниці NAL згідно з аспектів цього розкриття. Наприклад, одиниця NAL 120 включає в себе заголовок 122 одиниці NAL і корисні дані 124. Крім того, заголовок одиниці NAL включає в себе першу частину 126 і розширення 128 заголовка одиниці NAL.

[0205] Як у прикладі, показаному на фіг. 5C, перша частина 126 включає в себе елемент ref_idc і елемент типу одиниці NAL. Елемент ref_idc може вказувати, використовується одиниця NAL як посилання для інших одиниць NAL. Елемент типу одиниці NAL може вказувати тип пакетів одиниці NAL 120.

[0206] Як показано в прикладі згідно ФІГ. 5D, однак, замість включення view_id �готелю NAL. Таким чином, згідно з аспектів цього розкриття, порядковий індекс виду заголовка 122 одиниці NAL може замінити view_id, який сигналізований в заголовку 110 одиниці NAL (ФІГ. 5C). Як зазначено вище, порядок видів зазвичай описує упорядкування видів в одиниці доступу, таких як порядок одиниць доступу 102 (ФІГ. 5A). Порядковий індекс виду може вказувати конкретний вигляд, такий як один з видів 104, в порядку видів одиниці доступу. Таким чином, порядковий індекс виду може описати порядок декодування відповідного компонента виду одиниці доступу.

[0207] Приклад таблиця синтаксису заголовка одиниці NAL для розширення 128 представлений в Таблиці 12 нижче:

Таблиця 12
РОЗШИРЕННЯ MVC ЗАГОЛОВКА ОДИНИЦІ NAL
nal_unit_header_mvc_extension( ) {CДескриптор
non_idr_flagвсіu(1)
anchor_pic_flagвсіu(1)
view_idxВсіu(1)
}

[0208] У прикладі, показаному на фіг. 13, non_idr_flag, який дорівнює 0, може вказувати, що поточна одиниця доступу є одиницею доступу IDR. Значення non_idr_flag може бути однаковим для всіх одиниць NAL VCL одиниці доступу. У деяких випадках non_idr_flag може бути логічно виведений, щоб бути рівним 0 для одиниці NAL базового виду, який має nal_unit_type рівний 5. Крім того, non_idr_flag може бути логічно виведений, щоб бути рівним 1 для одиниці NAL базового виду, який має nal_unit_type рівний 1. Для одиниць NAL, в яких присутня non_idr_flag, мінлива IdrPicFlag може бути змінена за допомогою установки прапора рівним 1, коли non_idr_flag дорівнює 0, і встановлення рівним 0, коли non_idr_flag дорівнює 1.

[0209] Крім того, anchor_pic_flag, який дорівнює 1, може задавати, що поточна одиниця доступу є одиницею доступу з прив'язкою. У деяких випадках anchor_pic_flag може бути логічно виведена, щоб бути рівним 0 для одиниці NAL базового виду, яка має nal_unit_type рівний 1, і може бути логічно виведений, щоб бути рівним 1 для одиниці NAL базового виду, яка має nal_unit_type рівний 4 (Очистити Оновлення Декодиро�ачением view_idx належать одному і тому ж виду. Тип одиниці NAL рівний 20, може бути використаний для вказівки типу одиниці NAL для компонентів виду не в базовому вигляді.

[0211] Як показано в прикладі Таблиці 12, на відміну від прикладу, показаного на фіг. 5C, priority_id, temporal_id, і inter_view_flag були видалені, і view_id був замінений допомогою view_idx. В деяких прикладах inter_view_flag може бути переміщений з розширення 128, як показано в прикладі заголовок одиниці NAL Таблиці 13 нижче:

Таблиця 13
ЗАГОЛОВОК ОДИНИЦІ NAL ДЛЯ БАЗОВОГО ВИДУ
nal_unit(NumBytesInNALunit){Дескриптор
forbidden_zero_bitf(1)
nal_ref_idcu(2)
nal_unit_typeu(5)
NumBytesInRBSP=0
nalUnitHeaderBytes=1
if(nal_unit_type= =1 | | nal_unit_type= =5){
temporal_idu(3)
u(3)
inter_view_flagu(1)
nalUnitHeaderBytes +=1
}
for(i=alUnitHeaderBytes; i<NumBytesInNALunit; i++) {
if(i+2<NumBytesInNALunit && next_bits(24)= = 0x000003){
rbsp_byte[NumBytesInRBSP++]b(8)
rbsp_byte[NumBytesInRBSP++]b(8)
i+=2
emulation_prevention_three_byte/*equal to 0x03 */f(8)
} else
rbsp_byte[ NumBytesInRBSP++]b(8)
}
}

[0212] У прикладі, наведеному в Таблиці 13, елемент inter_view_flag, який дорівнює 0, може вказувати, що поточний компонент виду не використовується для передбачення між видами ніяким іншим компонентом виду в поточному для передбачення між видами іншими компонентами виду поточної одиниці доступу. Значення inter_view_flag може бути одним і тим же для всіх одиниць NAL VCL компонент виду.

[0213] Крім того, у прикладі, наведеному в Таблиці 13, коли nal_unit_type дорівнює 1 або 5, порядковий індекс виду може бути логічно виведений рівним 0, і view_id цього компонента виду дорівнює view_id [0]. У такому прикладі розширення заголовка одиниці NAL може не бути необхідним. Таким чином, в потоці MVC, який включає в себе лише два види (тобто, для стерео відео), може не бути необхідним порядковий індекс виду, оскільки декодер (такий як відео декодер 30) декодувати перший вид (наприклад, вигляд 0) до декодування другого виду (наприклад, виду 1).

[0214] У деяких прикладах одиниця NAL префікса може бути більше не знадобитися для базового виду (наприклад, виду 0). Наприклад, одиниця NAL префікса для базового виду більше може не бути необхідною, так як порядковий індекс виду завжди дорівнює нулю для базового виду, і тимчасова позиція базового виду може бути визначена, використовуючи temporal_id. Відповідно, temporal_id в заголовку одиниці NAL забезпечує всю інформацію, щоб асоціювати конкретний компонент виду з конкретним видом і з відповідним тимчасовим місцем розташування.

[0215] Таблиця 14 включає в себе інший зд="0" frame="all">

Таблиця 14
ЗАГОЛОВОК ОДИНИЦІ NAL
nal_unit(NumBytesInNALunit){Дескриптор
forbidden_zero_bitf(1)
nal_ref_idcu(2)
nal_unit_typeu(5)
NumBytesInRBSP=0
nalUnitHeaderBytes=1
if(nal_unit_type= = 1 | | nal_unit_type = = 5
|| nal_unit_type= = 4 || nal_unit_type = = 20) {
temporal_idu(3)
output_flagu(1)
reserved_zero_3bitsu(3)
inter_view_flagu(1)
nalUnitHeaderBytes += 1
}
if(nal_unit_type = = 20) {
}
for(i=nalUnitHeaderBytes; i< NumBytesInNALunit; i++){
if(i+2<NumBytesInNALunit && next_bits(24)= =0x000003) {
rbsp_byte[NumBytesInRBSP++]b(8)
rbsp_byte[NumBytesInRBSP++]b(8)
i+=2
emulation_prevention_three_byte/*одно 0x03*/f(8)
} else
rbsp_byte[NumBytesInRBSP++]b(8)
}
}

[0216] У прикладі, наведеному в Таблиці 14, inter_view_flag, який дорівнює 0, може вказувати, що поточний компонент виду не використовується для передбачення між видами ніяким іншим компонентом виду поточної одиниці доступу. inter_view_flag, який дорівнює 1, може вказувати, що поточний компонент виду може бути використаний для передбачення між іншими видами компо�ента виду. Крім того, nal_unit_header_mvc_extension посилається на розширення, таке як те, що показано в Таблиці 12 вище.

[0217] Згідно з іншим аспектам цього розкриття, заголовок одиниці NAL для потоку бітів MVC може бути розроблений згідно Таблиці 15 нижче:

b(8)
Таблиця 15
ЗАГОЛОВОК ОДИНИЦІ NAL
nal_unit(NumBytesInNALunit){Дескриптор
forbidden_zero_bitf(1)
nal_ref_idcu(2)
nal_unit_typeu(5)
NumBytesInRBSP=0
nalUnitHeaderBytes=1
if(nal_unit_type= = 1 | | nal_unit_type= = 5 || nal_unit_type= =4
|| nal_unit_type= = 20){
temporal_idu(3)
output_flagu(1)
inter_view_flagu(1)
u(1)
anchor_pic_flagu(1)
view_idxu(5)
reserved_zero_4bitsu(4)
nalUnitHeaderBytes +=2
}
else {
reserved_zero_3bitsu(3)
nalUnitHeaderBytes +=1
}
}
for(i=nalUnitHeaderBytes; i<NumBytesInNALunit; i++){
if(i+2<NumBytesInNALunit && next_bits(24)= = 0x000003) {
rbsp_byte[NumBytesInRBSP++]b(8)
rbsp_byte[NumBytesInRBSP++]b(8)
i+=2
emulation_prevention_three_byte/* одно 0x03*/f(8)
}
}

[0218] У прикладі, наведеному в Таблиці 15, формування заголовка одиниці NAL може залежати, наприклад, від nal_unit_type. Таким чином, наприклад, коли nal_unit_type дорівнює 20, і одиниця NAL MVC, одиниця NAL може включати в себе non_idr_flag, anchor_pic_flag, і view_idx, описані вище. Відповідно, для профілю стерео, заголовок одиниці NAL може бути розроблений згідно Таблиці 16 нижче:

Таблиця 16
ЗАГОЛОВОК ОДИНИЦІ NAL
nal_unit(NumBytesInNALunit){Дескриптор
forbidden_zero_bitf(1)
nal_ref_idcu(2)
nal_unit_typeu(5)
NumBytesInRBSP = 0
nalUnitHeaderBytes = 1
if(nal_unit_type= =1 | | nal_unit_type= = 5 || nal_unit_type= =4
|| nal_unit_type= = 20){
output_flagu(1)
inter_view_flagu(1)
if (nal_unit_type= = 20){
non_idr_flagu(1)
anchor_pic_flagu(1)
reserved_zero_1bitsu(1)
}
else {
reserved_zero_3bitsu(3)
}
nalUnitHeaderBytes += 1
}
for(i= nalUnitHeaderBytes; i< NumBytesInNALunit; i++){
if(i+2<NumBytesInNALunit && next_bits(24) = = 0x000003){
rbsp_byte[NumBytesInRBSP++]b(8)
rbsp_byte[NumBytesInRBSP++]b(8)
i+= 2
} else
rbsp_byte[ NumBytesInRBSP++ ]b(8)
}

[0219] У ще іншому прикладі, згідно іншим аспектам цього розкриття, заголовок одиниці NAL для потоку бітів MVC може бути розроблений згідно Таблиці 17 нижче:

Таблиця 17
ЗАГОЛОВОК ОДИНИЦІ NAL
nal_unit(NumBytesInNALunit){Дескриптор
forbidden_zero_bitf(1)
nal_ref_idcu(2)
nal_unit_typeu(5)
NumBytesInRBSP = 0
nalUnitHeaderBytes = 1
if(nal_unit_type= =1 | | nal_unit_type = =5 || nal_unit_type = =4
|| nal_unit_type= = 20){
temporal_idu(3)
non_idr_flagu(1)
anchor_pic_flagu(1)
reserved_zero_1bitsu(1)
nalUnitHeaderBytes += 1
}
for(i=nalUnitHeaderBytes; i<NumBytesInNALunit; i++){
if(i+2< NumBytesInNALunit && next_bits(24) = = 0x000003 ){
rbsp_byte[NumBytesInRBSP++]b(8)
rbsp_byte[NumBytesInRBSP++]b(8)
i+=2
emulation_prevention_three_byte/* одно 0x03 */f(8)
} else
rbsp_byte[NumBytesInRBSP++]b(8)
}
}

[0220] Незалежно від конкретної конфігурації заголовка одиниці між view_ids для видів і порядковими індексами виду для згаданих видів. Відповідно, використовуючи порядковий індекс виду і дані в SPS, 10-бітовий view_id MVC/AVC може бути замінений в заголовку одиниці NAL порядковим індексом виду, який може привести до економії бітів у порівнянні зі схемою MVC/AVC. Порядковий індекс виду може бути використаний зі значенням POC або значенням кадру (номер кадру), щоб ідентифікувати компонент виду потоку бітів. Наприклад, прив'язуючи сітку компонентів виду, показаних на фіг. 4 до Декартовской сітці, порядковий індекс виду може забезпечити y-координату (наприклад, S0, S1, S2 ...) конкретного компонента виду, в той час як значення POC або значення кадру може забезпечити x-координату (наприклад, T0, T1, T2 ...) конкретного компонента виду. Ідентифікація компонентів виду таким чином може бути реалізована, наприклад, в списку опорних картинок.

[0221] Згідно з іншим аспектам цього розкриття, залежність видів для кожного виду потоку бітів MVC зазвичай може бути сигнализирована для всіх компонентів виду, незалежно від того, чи є компоненти виду для картинок з прив'язкою і картинок без прив'язки. В деяких прикладах SPS може включати в себе залежно видів для компонентів виду, замість того, щоб покладатися на інформацію в заголовку единицм прикладі компонент виду сигнализированного залежного виду може бути використаний як опорна картинка і 0 Списку і в Списку 1, як описано вище, з посиланнями на фіг. 4. Крім того, побудова списку опорних картинок і упорядкування списку опорних картинок для Списку з 0 та Списку 1 можуть також бути засновані на загальній сигналізації для картинок з прив'язкою і картинок без прив'язки. В деяких прикладах, рівень послідовності, повідомлення додаткової інформації розширення (SEI) можуть бути використані для вказівки, коли картинка без прив'язки має відмінну залежність видів, ніж картинка з прив'язкою.

[0223] Згідно з іншим аспектам цього розкриття, замість того, щоб сигналізувати priority_id в заголовку одиниці NAL, відео кодер 20 може забезпечити значення priority_id в SPS. Як описано вище, в деяких прикладах маршрутизатор 36 може використовувати значення priority_id SPS, щоб відфільтрувати деякі види. Таким чином, маршрутизатор 36 може прийняти повний потік бітів, але отримати подпоток бітів, включаючи одиниці NAL, що мають значення priority_id рівні і нижче значення пріоритету, визначеного пристроєм 14 призначення, і відправити подпоток бітів пристрою призначення.

[0224] Крім того, згідно з аспектів цього розкриття, повідомлення адаптації пріоритету може бути використане для виконання адаптації. Наприклад, Табл"all">Таблиця 18ПОВІДОМЛЕННЯ SEI АДАПТАЦІЇ ПРІОРИТЕТУpriority_adaptation_SEI(payloadSize){CДескрипторnum_temproal_id_minus15u(3)for(i=0; i<=num_temproal_id_minus1; i++)for (j=0; j<=num_views_minus1; j++){same_priority_id_flag[i][j]5u(1)if (!same_priority_id_flag[i][j])priority_id[i][j]5u(6)}}

[0225] У прикладі, наведеному в Таблиці 18, num_temporal_id_minus1 плюс 1 може вказувати найвищий temporal_id для одиниць NAL по�го виду j дорівнюють раніше повідомлену priority_id, який може бути priority_id [i] [j-1], коли j>0, або priority_id [i-1] [j] коли j=0 і i>0. Елемент priority_id [i] [j] може задавати ідентифікатор пріоритету для одиниць NAL з temporal_id рівним i і порядковим індексом виду, рівним j. Більш низьке значення priority_id може вказувати більш високий пріоритет.

[0226] Адаптація може бути заснована на заголовку одиниці NAL і повідомленні SEI, такому як те, яке показано в Таблиці 18. Наприклад, процес адаптації може припустити, що temporal_id і view_idx одиниці NAL рівні TID і VIDX, і цільової priority_id дорівнює PID. У цьому прикладі, якщо priority_id [TID] [VIDX] не більше ніж PID, одиниця NAL підтримується, інакше, одиниця NAL фільтрується.

[0227] У той час як цей приклад описує інформацію пріоритету в повідомленні SEI, в інших прикладах інформація, описана як сообщаемая в повідомленні SEI, може бути сигнализирована як необов'язкова частина набору параметрів, такого як SPS MVC.

[0228] ФІГ. 6 є блок-схема, що ілюструє приблизний спосіб кодування потоку бітів множинних видів. Приклад, показаний на фіг. 6, зазвичай описаний як виконується відео кодером 20 (ФІГ. 1 і 2). Однак, потрібно мати на увазі, що процес, описаний з посиланнями на фіг. 6, може бути виконаний безліччю інших процесорів, блоків обробки, про�міру згідно ФІГ. 6, відео кодер 20 може кодувати відео дані для безлічі компонентів виду (140). Наприклад, відео кодер 20 може кодувати безліч з безлічі різних видів, з кожним виглядом, відповідним різної перспективі, або кутку, під яким були захоплені відповідні відео дані загальної сцени. Як зазначено вище, конкретна картинка конкретного виду згадується як компонент виду. Таким чином, компонент виду для виду відповідає конкретному тимчасовому примірнику виду.

[0230] Відео кодер 20 може також формувати одиниці NAL, які включають в себе індикацію порядку декодування компонентів виду (142). Наприклад, як описано з посиланнями на фіг. 5A-5D, згідно з аспектів цього розкриття, відео кодер 20 може забезпечити індикацію порядкового індексу (view_idx) видів в заголовках одиниці NAL, яка забезпечує індикацію порядку декодування компонентів виду. В цілому одиниці NAL з одним і тим же значенням view_idx належать одному і тому ж виду.

[0231] Відео кодер 20 може також надати інформацію, окрему від одиниць NAL, яка забезпечує індикацію відносин між ідентифікаторами виду і порядком (144) декодування. В деяких прикладах відео кодер 20 може генерувати наборми індексами виду для цих видів. В інших прикладах відео кодер 20 може вказувати відносини між порядковими індексами виду і ідентифікаторами виду іншим способом.

[0232] Використовуючи порядковий індекс виду і згадану окрему інформацію, відео кодер 20 може замінити 10-бітовий ідентифікатор виду, типово включений в заголовок одиниці NAL на порядковий індекс виду, який може забезпечити економію бітів. Наприклад, порядковий індекс виду може включати в себе по суті менше бітів ніж ідентифікатор виду. У той час як відео кодер 20 повинен сигналізувати відносини між порядковим індексом виду і ідентифікаторами виду, наприклад, у SPS, заголовки одиниці NAL типово споживають набагато більше бітів, ніж така сигналізація. Заміна ідентифікатора виду в заголовку одиниці NAL порядковим індексом виду може зменшити розмір заголовків одиниці NAL, таким чином досягаючи економії бітів порівняно з кодуванням ідентифікатора виду в заголовку одиниці NAL.

[0233] Треба також мати на увазі, що етапи, показані і описані з посиланнями на фіг. 6, надані як просто один приклад. Таким чином, етапи способу ФІГ. 6 не обов'язково повинні бути виконані в порядку, показаному на фіг. 6 і менше, додаткові, або альтеѺодирования потоку бітів множинних видів. Приклад, показаний на фіг. 7, в цілому описаний як виконується відео декодером 30 (ФІГ. 1 і 3). Однак, потрібно мати на увазі, що процес, описаний з посиланнями на фіг. 7, може бути виконаний безліччю інших процесорів, блоків обробки, заснованих на апаратному забезпеченні блоків кодування, таких як кодер/декодери (кодеки), і т. п.

[0235] У прикладі згідно ФІГ. 7, відео декодер 30 може прийняти одну або більше одиниці NAL для кожного компонента виду, які включають в себе інформацію, що вказує порядок декодування відповідних компонентів виду (150). Згідно з аспектів цього розкриття, як описано з посиланнями на фіг. 6, порядок декодування відповідних компонентів виду може бути позначений, використовуючи порядковий індекс виду. Відповідно, відео декодер 30 може прийняти індикацію порядкового індексу (view_idx) видів в заголовках одиниць NAL, яка забезпечує індикацію порядку декодування компонентів виду. В цілому одиниці NAL з одним і тим же значенням view_idx належать одному і тому ж виду.

[0236] Відео декодер 30 може також прийняти інформацію, що вказує відносини між ідентифікаторами виду і порядком декодування компонентів виду (152). В деяких прикладах відео декодер тих видів і порядковими індексами виду для цих видів. В інших прикладах відео декодер 30 може прийняти іншу індикацію відносин між порядковими індексами виду і ідентифікаторами виду.

[0237] Відео декодер 30 може декодувати дані відео з численними видами, використовуючи прийняту інформацію. Таким чином, наприклад, відео декодер може декодувати кожен з видів, і визначити відповідний ідентифікатор виду, використовуючи прийняту окрему інформацію. Відео декодер 30 може забезпечити 3D уявлення, використовуючи ці види, наприклад, на пристрої 32 відображення.

[0238] Треба також мати на увазі, що етапи, показані і описані з посиланнями на фіг. 7, надані як просто один приклад. Таким чином, етапи способу ФІГ. 7 не обов'язково повинні бути виконані в порядку, показаному на фіг. 7 і менше, додаткові або альтернативні етапи можуть бути виконані.

[0239] ФІГ. 8 є блок-схема, що ілюструє приблизний спосіб кодування потоку бітів множинних видів. Приклад, показаний на фіг. 8, в цілому описаний як виконується відео кодером 20 (ФІГ. 1 і 2). В інших прикладах процес, описаний з посиланнями на фіг. 8, може бути виконаний безліччю інших процесорів, блоків обробки, заснованих на апаратному забезпечення�визначити, для будь-якого компонента виду першого виду, інформацію опорного виду, вказує один або більше опорних видів для передбачення компонентів виду першого виду (160). Наприклад, як зазначено вище, залежно видів можуть бути сигнализировани одним і тим же способом для всіх компонентів виду для деякого виду, незалежно від того, чи є конкретний компонент виду конкретної одиницею доступу картинки з прив'язкою (точкою довільного доступу), чи є конкретний компонент виду конкретної одиниці доступу картинкою без прив'язки. У деяких випадках інформація опорного виду може вказувати залежності виду, використовуючи значення індексу опорного виду (значення порядкового індексу виду для опорних видів). Таким чином, інформація опорного виду може містити значення індексу опорного виду для кожного опорного виду, який може вказувати порядок декодування опорного виду в одиниці доступу. В інших прикладах інформація опорного виду може містити значення різниці індексів опорних видів, які можуть вказати різницю між порядковим індексом виду конкретного опорного виду і порядковим індексом виду компонента виду, кодованого в даний час. У прикладах, які�полнительную інформацію, яка вказує відносини між значеннями порядкового індексу виду і ідентифікаторами виду видів.

[0240] Відео кодер 20 може також при кодуванні першого компонента виду в одиниці доступу в першому виді, включати один або більше опорних кандидатів у список опорних картинок на підставі одиниці доступу, якій перший компонент виду належить, інформації опорного виду і кількості опорних видів, зазначених інформацією (162) опорного виду. Наприклад, як описано вище, відео кодер 20 може конструювати список опорних картинок, який включає в себе опорні картинки - кандидати для того, щоб передбачити перший компонент виду (опорні картинки "кандидати", так як опорні картинки можуть бути видалені з остаточного списку опорних картинок). Відео кодер 20 може ідентифікувати опорні картинки - кандидати між видами в кожному з опорних видів, зазначених інформацією опорного виду, які належать одній і тій же одиниці доступу (наприклад, мають один і той же момент часу) як перший компонент виду. Відео кодер 20 може додати всі ідентифіковані компоненти виду до списку опорних картинок.

[0241] Відповідно, у прикладі, показаному на фіг. 8, відео кодер 20 може конс�ремя, картинкою з прив'язкою або картинкою без прив'язки. Крім того, відео кодер 20 може конструювати список опорних картинок, не беручи до уваги те, включені опорні картинки - кандидати в Список 0 або Список 1. Таким чином, відео кодер 20 може конструювати список опорних картинок 0 або список опорних малюнків 1, використовуючи одну і ту ж інформацію опорного виду. Крім того, відео кодер 20 може додати ідентифіковані опорні кандидати до обох Списків 0 або Списком 1 аналогічно.

[0242] Відео кодер 20 може також кодувати перший компонент виду на підставі одного або більше опорних кандидатів у списку (164) опорних картинок. Наприклад, відео кодер 20 може ідентифікувати компонент виду в списку опорних картинок, генерувати залишкові дані, використовуючи ідентифікований компонент виду, і кодувати залишкові дані, як описано з посиланнями на фіг. 2. Відео кодер 20 може також забезпечити кодований перший компонент виду певною інформацією опорного виду в закодованому потоці бітів (166).

[0243] Слід мати на увазі, що етапи, показані і описані з посиланнями на фіг. 8, надані як просто один приклад. Таким чином, етапи способу згідно ФІГ. 8 не обов'язково повинн виконані.

[0244] ФІГ. 9 є блок-схема, що ілюструє приблизний спосіб декодування потоку бітів множинних видів. Приклад, показаний на фіг. 9, в цілому описаний як виконується відео декодером 30 (ФІГ. 1 і 3). В інших прикладах процес, описаний з посиланнями на фіг. 9, може бути виконаний безліччю інших процесорів, блоків обробки, заснованих на апаратному забезпеченні блоків кодування, таких як кодер/декодери (кодеки), і т. п.

[0245] У прикладі, показаному на фіг. 9, відео декодер 30 може отримати, з кодованого потоку бітів і для будь-якого компонента виду першого виду, інформацію опорного виду, вказує один або більше опорних видів для передбачення компонентів виду першого виду (170). Наприклад, як зазначено вище з посиланнями на фіг. 8, залежно видів можуть бути сигнализировани одним і тим же способом для всіх компонентів виду для деякого виду, незалежно від того, чи є конкретний компонент виду конкретної одиниці доступу картинкою з прив'язкою (точкою довільного доступу), чи є конкретний компонент виду конкретної одиниці доступу картинкою без прив'язки. У деяких випадках інформація опорного виду може вказувати залежності виду, використовуючи значення індексу оожет містити значення індексу опорного виду для кожного опорного виду, який може вказувати порядок декодування опорного виду в одиниці доступу. В інших прикладах інформація опорного виду може містити значення різниці індексів опорних видів, які можуть вказати різницю між порядковим індексом виду конкретного опорного виду і порядковим індексом виду компонента виду, кодованого в даний час. У прикладах, у яких значення порядкового індексу виду використовуються, як описано вище, відео декодер 30 може також отримати додаткову інформацію з закодованого потоку бітів, яка вказує відносини між значеннями порядкового індексу виду і ідентифікаторами виду видів. Така інформація може бути отримана з рівня послідовності.

[0246] Відео декодер 30 може також при декодуванні першого компонента виду в одиниці доступу в першому виді включати один або більше опорних кандидатів у список опорних картинок на підставі одиниці доступу, якій належить перший компонент виду, інформації опорного виду і кількості опорних видів, зазначених інформацією опорного виду (172). Наприклад, як описано вище, відео декодер 30 може конструювати список опорних картинок, який включає в себе опорні картинки - кандидати длядидати між видами в кожному з опорних видів, зазначених інформацією опорного виду, які належать одній і тій же одиниці доступу (наприклад, мають один і той же момент часу), що й перший компонент виду. Відео декодер 30 може додати всі ідентифіковані компоненти виду до списку опорних картинок.

[0247] Відповідно, у прикладі, показаному на фіг. 9, відео декодер 30 може конструювати список опорних картинок без відносно до того, чи є компонент виду, який кодується в даний час, картинкою з прив'язкою або картинкою без прив'язки. Крім того, відео декодер 30 може конструювати список опорних картинок, не беручи до уваги те, включені опорні картинки - кандидати в Список 0 або Список 1. Таким чином, відео декодер 30 може конструювати список опорних картинок 0 або список опорних малюнків 1 з використанням тієї ж інформації опорного виду, яка може бути отримана з закодованого потоку бітів одного разу. Крім того, відео декодер 30 може додати ідентифіковані опорні кандидати до обох Списків 0 або Списком 1 аналогічно.

[0248] Відео декодер 30 може декодувати перший компонент виду на підставі одного або більше опорних кандидатів у списку опорних картинок (174). Наприклад, відео �мпонент виду з декодированними залишковими даними (з закодованого потоку бітів), щоб генерувати компонент виду, як описано з посиланнями на фіг. 3 вище.

[0249] Слід мати на увазі, що етапи, показані і описані з посиланнями на фіг. 9, надані як просто один приклад. Таким чином, етапи способу ФІГ. 9 не обов'язково повинні бути виконані в порядку, показаному на фіг. 9 і менше, додаткові або альтернативні етапи можуть бути виконані.

[0250] У той час як деякі елементи синтаксису, описані щодо цього розкриття, забезпечені зразками назвами в цілях пояснення, потрібно мати на увазі, що поняття, описані в цьому розкритті, більш широко застосовні до будь-яких елементів синтаксису, незалежно від назви. Наприклад, у той час як деякі аспекти відносяться до "порядковому індексу виду," "view_order_index" або "view_idx," потрібно розуміти, що такого елементу синтаксису можна дати альтернативне назва в майбутньому стандарті кодування.

[0251] У той час як деякі способи справжнього розкриття описані щодо майбутнього стандарту HEVC, потрібно мати на увазі, що способи не обмежені жодним конкретним стандартом кодування. Таким чином, способи більш широко ставляться до досягнення ефективності кодування при кодиров параметрів, як описано вище.

[0252] Слід мати на увазі, що в залежності від прикладу деякі дії або події будь-якого із способів, описаних тут, можуть бути виконані в різній послідовності, можуть бути додані, злиті, або не використані спільно (наприклад, не всі описані дії або події необхідні для практичної реалізації способу). Крім того, в деяких прикладах, дії або події можуть бути виконані одночасно, наприклад, з допомогою багатопоточної обробки, обробки переривання, або множинних процесорів, а не послідовно. Крім того, в той час як деякі аспекти цього розкриття описані як виконуються єдиним модулем або блоком в цілях ясності, потрібно мати на увазі, що способи розкриття цього можуть бути виконані комбінацією блоків або модулів, асоційованих з відео кодером.

[0253] В одному або більше прикладах наведені функції можуть бути реалізовані в апаратне забезпечення, програмне забезпечення, програмно-апаратних засобах, або будь-якої їх комбінації. Якщо реалізовані в програмному забезпеченні, функції можуть бути збережені або передані як одна або більше інструкцій або код за считиваемому комп'ютером носітел� включати в себе зчитуються комп'ютером носії даних, які відповідають матеріальному носієві, такого як запам'ятовуючі носії даних або комунікаційні носії, що включають в себе будь-який носій, який полегшує передачу комп'ютерної програми від одного місця до іншого, наприклад, згідно з протоколом зв'язку.

[0254] Таким чином зчитаний комп'ютером носій в цілому може відповідати (1) матеріального считиваемому комп'ютером носієві даних, який є невременним, або (2) комунікаційному носій, такий як сигнал або несуча. Запам'ятовуючі носії даних можуть бути будь-яким доступним носієм, до якої можуть отримати доступ один або більше комп'ютерів або один або більше процесорів, щоб отримати інструкції, код та/або структури даних для реалізації способів, описаних у цьому розкритті. Комп'ютерний програмний продукт може включати в себе зчитаний комп'ютером носій.

[0255] за Допомогою прикладу, а не обмеження, такі зчитуються комп'ютером носії даних можуть містити RAM, ROM, EEPROM, CD-ROM або інше оптичне дисковий накопичувач, магнітне дисковий накопичувач, або інші магнітні пристрої зберігання флеш-пам'ять, або будь-який інший носій, який може ісп� може отримати доступ комп'ютер. Також, будь-яке з'єднання належним чином називають зчитуваним комп'ютером носієм. Наприклад, якщо інструкції передані від вебсайту, сервера, або іншого віддаленого джерела, використовуючи коаксіальний кабель, волокно-оптичний кабель, виту пару, цифрову абонентську лінію (DSL), або бездротові технології такий як інфрачервона, радіо - та мікрохвильова, то ці коаксіальний кабель, волокно-оптичний кабель, вита пара, DSL, або бездротові технології такі як інфрачервона, радіо - та мікрохвильова, включені у визначення носія.

[0256] Слід мати на увазі, однак, що зчитуються комп'ютером носії даних та запам'ятовуючі носії даних не включають в себе сполуки, що несуть, сигнали, або інші тимчасові носії, але замість цього спрямовані на нетимчасові матеріальні носії даних. Диск і диск, як використовується тут, включають в себе компакт-диск (CD), лазерний диск, оптичний диск, цифровий універсальний диск (DVD), дискета, диск blu-ray, де диски (disks) зазвичай відтворюють дані магнітним чином, у той час як диски (discs) відтворюють дані оптично з допомогою лазерів. Комбінації вищезазначеного повинні також бути включені в рамки считиваемого комп'ютером носія.

[0257] ИнѾцессоров (DSPs), мікропроцесори загального призначення, спеціалізовані інтегральні схеми (ASIC), програмовані користувачем логічні матриці (FPGA), або інші еквівалентні інтегральні або дискретні логічні схеми. Відповідно, термін "процесор", як використовується тут, може ставитися до будь-якої відомої структурі чи будь-якою іншою структурою, відповідною для реалізації способів, описаних тут. Також, в деяких аспектах функціональні можливості, описані тут, можуть бути надані в межах спеціалізованого апаратного забезпечення та/або програмних модулів, сконфігурованих для кодування і декодування, або вбудованих в об'єднаний кодек. Також, способи могли бути повністю реалізовані в одній або більше схемах або логічних елементах.

[0258] Способи розкриття цього можуть бути реалізовані в широкому розмаїтті пристроїв або апаратів, включаючи бездротову телефонну трубку, інтегральну схему (IC) або набір IC (наприклад, мікропроцесорний набір). Різні компоненти, модулі, або блоки описані в цьому описі, щоб підкреслити функціональні аспекти пристроїв, що конфігуруються, щоб виконувати розкриті способи, але не обов'язково вимагати реалі�об'єднані в блоці апаратного забезпечення кодека або надані колекцією взаємодіючих блоків апаратного забезпечення, включаючи один або більше процесорів, як описано вище, у поєднанні з відповідним програмним забезпеченням та/або програмно-апаратними засобами.

[0259] Були описані різні приклади. Ці та інші приклади знаходяться в рамках нижче наступної формули винаходу.

1. Спосіб декодування відео даних, причому спосіб містить:
отримання, закодованого потоку бітів, однієї або більше одиниць рівня абстракції мережі (NAL) для кожного компонента виду з безлічі компонентів виду закодованих відеоданих, при цьому кожен компонент виду з безлічі компонентів виду відповідає загальному тимчасового розташування, і в якому кожна одиниця NAL з однієї або більше одиниць NAL інкапсулює принаймні частина закодованих відеоданих для відповідних компонентів виду і включає в себе інформацію, що описує порядок декодування відповідних компонентів виду, і яка є окремою від ідентифікатора виду відповідних компонентів виду;
отримання інформації, закодованого потоку бітів і окремою від згаданих однієї або більше одиниць NAL, що вказує відносини між згаданими ідентифікаторами виду для видів, асоційованих із зазначеними компонентами�а компонентів виду в порядку декодування на основі отриманої інформації.

2. Спосіб за п. 1, в якому одержання інформації, що вказує відносини між ідентифікаторами виду і порядком декодування компонентів виду, містить отримання інформації з інформацією рівня послідовності закодованих відеоданих, яка вказує відносини між ідентифікаторами види і порядок декодування згаданого виду.

3. Спосіб за п. 1, в якому одержання інформації, що вказує порядок декодування відповідних компонентів виду, містить отримання значення за замовчуванням порядкового індексу виду, рівного нулю, для базового виду з безлічі компонентів виду.

4. Спосіб за п. 1, в якому одна або більше одиниць NAL також включають в себе інформацію, що вказує, використовується перший компонент виду першого виду як посилання для передбачення між видами другого компонента виду для другого відмінного вигляду.

5. Спосіб за п. 4, в якому інформація, яка вказує, використовується перший компонент виду першого виду як посилання для передбачення між видами другого компонента виду, містить однобітових прапор заголовка одиниці NAL.

6. Спосіб за п. 1, додатково містить отримання з закодованого потоку бітів значень відліку порядку картинки (РОС) для мн�вання інформації, вказує порядок декодування і значення ЗРОСТАВ.

7. Спосіб за п. 1, додатково містить отримання, закодованого потоку бітів, значень кадру для безлічі компонентів виду, і в якому декодування містить декодування кодованих відеоданих на підставі інформації, що вказує порядок декодування і значення кадру.

8. Спосіб за п. 1, в якому інформація, яка вказує порядок декодування відповідних компонентів виду, містить кількість елементів синтаксису, визначених на підставі щонайменше одного з базового виду, профілю і кількості видів, підтримуваних в потоці бітів.

9. Спосіб за п. 1, в якому інформація, яка вказує відносини між ідентифікаторами виду для цих видів і порядком декодування компонентів виду, містить таблицю відображення, яка відображає порядок декодування компонентів виду в ідентифікатори виду для згаданих видів.

10. Спосіб за п. 1, в якому інформація, яка вказує порядок декодування відповідних компонентів виду, міститься в частині заголовка одиниць NAL.

11. Спосіб за п. 1, в якому інформація, яка вказує порядок декодування відповідних компонентів виду, містить порядковий індекс місцево використовують загальний порядковий індекс виду.

13. Пристрій для декодування відео даних, причому пристрій містить один або більше процесорів, сконфігурованих, щоб:
отримувати, закодованого потоку бітів, одну або більше одиниць рівня абстракції мережі (NAL) для кожного компонента виду з безлічі компонентів виду закодованих відеоданих, при цьому кожен компонент виду з безлічі компонентів виду відповідає загальному тимчасового розташування, і в якому кожна одиниця NAL з однієї або більше одиниць NAL інкапсулює принаймні частина закодованих відеоданих для відповідних компонентів виду і включає в себе інформацію, що описує порядок декодування відповідних компонентів виду, і яка є окремою від ідентифікатора виду відповідних компонентів виду;
отримувати інформацію, закодованого потоку бітів і окрему від згаданих однієї або більше одиниць NAL, що вказує відносини між згаданими ідентифікаторами виду для видів, асоційованих із зазначеними компонентами виду, і порядком декодування компонентів виду;
декодувати кодовані відеодані з безлічі компонентів виду в порядку декодування на основі отриманої інформації.

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

15. Пристрій п. 13, в якому щоб отримати інформацію, що вказує порядок декодування відповідних компонентів виду, згадані один або більше процесорів конфігуруються, щоб отримати значення за замовчуванням порядкового індексу виду, що дорівнює нулю, для базового виду з безлічі компонентів виду.

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

17. Пристрій п. 16, в якому інформація, яка вказує, використовується перший компонент виду першого виду як посилання для передбачення між видами другого компонента виду, містить однобітових прапор заголовка одиниці NAL.

18. Пристрій п. 13, в якому згадані один або більше процесорів далі конфігуруються, щоб отримати, закодованого потоку бітів, значення отс більш процесорів конфігуруються, щоб розшифрувати закодовані відеодані на підставі інформації, що вказує порядок декодування і значення ЗРОСТАВ.

19. Пристрій п. 13, в якому згадані один або більше процесорів також конфігуруються, щоб отримати, закодованого потоку бітів, значення кадру для безлічі компонентів виду, і в якому для декодування згадані один або більше процесорів конфігуруються, щоб розшифрувати закодовані відеодані на підставі інформації, що вказує порядок декодування і значення кадру.

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

21. Пристрій п. 13, в якому інформація, яка вказує відносини між ідентифікаторами виду для цих видів і порядком декодування компонентів виду, містить таблицю відображення, яка відображає порядок декодування компонентів виду в ідентифікатори виду для згаданих видів.

22. Пристрій п. 13, в якому інформація, яка вказує порядок декодування відповідн�вказує порядок декодування відповідних компонентів виду, містить порядковий індекс виду.

24. Пристрій п. 23, в якому компоненти видів множинних часових розташувань загального виду спільно використовують загальний порядковий індекс виду.

25. Пристрій для декодування відео даних, причому пристрій містить:
засіб для отримання, закодованого потоку бітів, однієї або більше одиниць рівня абстракції мережі (NAL) для кожного компонента виду з безлічі компонентів виду закодованих відеоданих, при цьому кожен компонент виду з безлічі компонентів виду відповідає загальному тимчасового розташування, і в якому кожна одиниця NAL з однієї або більше одиниць NAL інкапсулює принаймні частина закодованих відеоданих для відповідних компонентів виду і включає в себе інформацію, що описує порядок декодування відповідних компонентів виду, і яка є окремою від ідентифікатора виду відповідних компонентів виду;
засіб для отримання інформації, закодованого потоку бітів і окремою від згаданих однієї або більше одиниць NAL, що вказує відносини між згаданими ідентифікаторами виду для видів, асоційованих із зазначеними компонентами виду, і порядком декодування ко�орядке декодування на основі отриманої інформації.

26. Пристрій п. 25, в якому засіб для отримання інформації, що вказує відносини між ідентифікаторами виду і порядком декодування компонентів виду, містить засіб для отримання інформації з інформацією рівня послідовності закодованих відеоданих, яка вказує відносини між ідентифікаторами виду і порядком декодування згаданого виду.

27. Пристрій п. 25, в якому інформація, яка вказує порядок декодування відповідних компонентів виду, містить кількість елементів синтаксису, визначених на підставі щонайменше одного з базового виду, профілю і кількості видів, підтримуваних в потоці бітів.

28. Пристрій п. 25, в якому інформація, яка вказує відносини між ідентифікаторами виду для цих видів і порядком декодування компонентів виду, містить таблицю відображення, яка відображає порядок декодування компонентів виду в ідентифікатори виду для згаданих видів.

29. Пристрій п. 25, в якому інформація, яка вказує порядок декодування відповідних компонентів виду, міститься в частині заголовка одиниць NAL.

30. Пристрій п. 25, в якому інформація, яка вказує порядок декодування соотноситель, має збережені на ньому інструкції, які, коли виконуються, змушують один або більше процесорів:
отримувати, закодованого потоку бітів, одну або більше одиниць рівня абстракції мережі (NAL) для кожного компонента виду з безлічі компонентів виду закодованих відеоданих, при цьому кожен компонент виду з безлічі компонентів виду відповідає загальному тимчасового розташування, і в якому кожна одиниця NAL з однієї або більше одиниць NAL інкапсулює принаймні частина закодованих відеоданих для відповідних компонентів виду і включає в себе інформацію, що описує порядок декодування відповідних компонентів виду, і яка є окремою від ідентифікатора виду відповідних компонентів виду;
отримувати інформацію, закодованого потоку бітів і окрему від згаданих однієї або більше одиниць NAL, що вказує відносини між згаданими ідентифікаторами виду для видів, асоційованих із зазначеними компонентами виду, і порядком декодування компонентів виду;
розшифрувати закодовані відеодані з безлічі компонентів виду в порядку декодування на основі отриманої інформації.

32. Зчитаний комп'ютером запоми�так і порядком декодування компонентів виду, інструкції змушують один або більше процесорів отримувати інформацію з інформацією рівня послідовності закодованих відеоданих, яка вказує відносини між ідентифікаторами виду і порядком декодування згаданого виду.

33. Зчитаний комп'ютером, що запам'ятовує носій по п. 31, в якому інформація, яка вказує порядок декодування відповідних компонентів виду, містить кількість елементів синтаксису, визначених на підставі щонайменше одного з базового виду, профілю і кількості видів, підтримуваних в потоці бітів.

34. Зчитаний комп'ютером, що запам'ятовує носій по п. 31, в якому інформація, яка вказує відносини між ідентифікаторами виду для цих видів і порядком декодування компонентів виду, містить таблицю відображення, яка відображає порядок декодування компонентів виду в ідентифікатори виду для згаданих видів.

35. Зчитаний комп'ютером, що запам'ятовує носій по п. 31, в якому інформація, яка вказує порядок декодування відповідних компонентів виду, міститься в частині заголовка одиниць NAL.

36. Зчитаний комп'ютером, що запам'ятовує носій по п. 31, в якому інформація, яка вказує порядок декодировЋх, причому спосіб містить:
кодування відеоданих для безлічі компонентів виду для відповідних видів відеоданих, причому кожен з безлічі компонентів виду відповідає загальному тимчасового розташування;
формування, в якості частини закодованого потоку бітів, однієї або більше одиниць рівня абстракції мережі (NAL) для закодованих відеоданих кожного з компонентів виду таким чином, що кожна з одиниць NAL включає в себе інформацію, що описує порядок декодування відео відповідних компонентів виду, яка є окремою від ідентифікатора виду відповідних компонентів виду, і інкапсулює принаймні частина закодованих відеоданих для відповідних компонентів виду;
надання інформації у закодованому потоці бітів, окремої від одиниць NAL, що вказує відносини між згаданими ідентифікаторами виду для видів, асоційованих із зазначеними компонентами виду, і порядком декодування компонентів виду.

38. Спосіб за п. 37, в якому надання інформації, що вказує відносини між ідентифікаторами виду і порядком декодування компонентів виду, містить надання інформації в рівні последовательн�ок декодування відповідних компонентів виду, містить надання значення за замовчуванням порядкового індексу виду, що дорівнює нулю, для базового виду з безлічі компонентів виду.

40. Спосіб за п. 37, в якому одна або більше одиниць NAL також включають в себе інформацію, що вказує, використовується перший компонент виду першого виду як посилання для передбачення між видами другого компонента другого виду, відмінного вигляду.

41. Спосіб за п. 40, в якому інформація, яка вказує, використовується перший компонент виду першого виду як посилання для передбачення між видами другого компонента виду, містить однобітових прапор заголовка одиниці NAL.

42. Спосіб за п. 37, в якому інформація, яка вказує порядок декодування відповідних компонентів виду, містить кількість елементів синтаксису, визначених на підставі щонайменше одного з базового виду, профілю і кількості видів, підтримуваних в потоці бітів.

43. Спосіб за п. 37, в якому інформація, яка вказує відносини між ідентифікаторами виду для цих видів і порядком декодування компонентів виду, містить таблицю відображення, яка відображає порядок декодування компонентів виду в ідентифікатори виду для згаданих видів.

44. Спосіб за п. 37, в якому іа одиниць NAL.

45. Спосіб за п. 37, в якому інформація, яка вказує порядок декодування відповідних компонентів виду, містить порядковий індекс виду.

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

47. Пристрій для кодування відеоданих, причому пристрій містить один або більше процесорів, сконфігурованих для того, щоб:
кодувати відео для безлічі компонентів виду для відповідних видів відеоданих, при цьому кожен з безлічі компонентів виду відповідає загальному тимчасового розташування;
формувати, як частини закодованого потоку бітів, одну або більше одиниць рівня абстракції мережі (NAL) для закодованих відеоданих кожного з компонентів виду таким чином, що кожна з одиниць NAL включає в себе інформацію, що описує порядок декодування відео відповідних компонентів виду, яка є окремою від ідентифікатора виду відповідних компонентів виду, і інкапсулює принаймні частина закодованих відеоданих для відповідних компонентів виду;
надавати інформацію в закодованому потоці біто�ванних із зазначеними компонентами виду, і порядком декодування компонентів виду.

48. Пристрій п. 47, в якому, щоб надати інформацію, що вказує відносини між ідентифікаторами виду і порядком декодування компонентів виду, згадані один або більше процесорів конфігуруються, щоб надати інформацію в рівні послідовності закодованих відеоданих.

49. Пристрій п. 47, в якому, щоб надати інформацію, що вказує порядок декодування відповідних компонентів виду, згадані один або більше процесорів конфігуруються, щоб забезпечити значення за замовчуванням порядкового індексу виду, що дорівнює нулю, для базового виду з безлічі компонентів виду.

50. Пристрій п. 47, в якому одна або більше одиниць NAL також включають в себе інформацію, що вказує, використовується перший компонент виду першого виду як посилання для передбачення між видами другого компонента другого виду, відмінного вигляду.

51. Пристрій п. 50, в якому інформація, яка вказує, використовується перший компонент виду першого виду як посилання для передбачення між видами другого компонента виду, містить однобітових прапор заголовка одиниці NAL.

52. Пристрій п. 47, в якому інформація, указиваюделенних на підставі щонайменше одного з базового виду, профілю, і кількості видів, підтримуваних в потоці бітів.

53. Пристрій п. 47, в якому інформація, яка вказує відносини між ідентифікаторами виду для цих видів і порядком декодування компонентів виду, містить таблицю відображення, яка відображає порядок декодування компонентів виду в ідентифікатори виду для згаданих видів.

54. Пристрій п. 47, в якому інформація, яка вказує порядок декодування відповідних компонентів виду, міститься в частині заголовка одиниць NAL.

55. Пристрій п. 47, в якому інформація, яка вказує порядок декодування відповідних компонентів виду, містить порядковий індекс виду.

56. Пристрій п. 55, в якому компоненти видів множинних часових розташувань загального виду спільно використовують загальний порядковий індекс виду.

57. Пристрій для кодування відеоданих, причому пристрій містить:
засіб для кодування відеоданих для безлічі компонентів виду для відповідних видів відеоданих, при цьому кожен з безлічі компонентів виду відповідає загальному тимчасового розташування;
засіб для формування, в якості частини закодованого потоку бітів, однієї або більше одиниць уря з одиниць NAL включає в себе інформацію, описує порядок декодування відео відповідних компонентів виду, яка є окремою від ідентифікатора виду відповідних компонентів виду, і інкапсулює принаймні частина закодованих відеоданих для відповідних компонентів виду;
засіб для надання інформації у закодованому потоці бітів, окремої від одиниць NAL, що вказує відносини між згаданими ідентифікаторами виду для видів, асоційованих із зазначеними компонентами виду, і порядком декодування компонентів виду.

58. Пристрій п. 57, в якому засіб для надання інформації, що вказує відносини між ідентифікаторами виду і порядком декодування компонентів виду, містить засіб для надання інформації в рівні послідовності закодованих відеоданих.

59. Пристрій п. 57, в якому інформація, яка вказує відносини між ідентифікаторами виду для цих видів і порядком декодування компонентів виду, містить таблицю відображення, яка відображає порядок декодування компонентів виду в ідентифікатори виду для згаданих видів.

60. Пристрій п. 57, в якому інформація, яка вказує порядок декодування відповідно�ція, вказує порядок декодування відповідних компонентів виду, містить порядковий індекс виду.

62. Пристрій п. 61, в якому компоненти видів множинних часових розташувань загального виду спільно використовують загальний порядковий індекс виду.

63. Зчитаний комп'ютером, що запам'ятовує носій, який має збережені на ньому інструкції, які, коли виконуються, змушують один або більше процесорів:
кодувати відео для безлічі компонентів виду для відповідних видів відеоданих, при цьому кожен з безлічі компонентів виду відповідає загальному тимчасового розташування;
формувати, як частини закодованого потоку бітів, одну або більше одиниць рівня абстракції мережі (NAL) для закодованих відеоданих кожного з компонентів виду таким чином, що кожна з одиниць NAL включає в себе інформацію, що описує порядок декодування відео відповідних компонентів виду, яка є окремою від ідентифікатора виду відповідних компонентів виду, і інкапсулює принаймні частина закодованих відеоданих для відповідних компонентів виду;
надавати інформацію в закодованому потоці бітів, окрему оонентами виду, і порядком декодування компонентів виду.

64. Зчитаний комп'ютером, що запам'ятовує носій по п. 63, в якому, щоб надати інформацію, що вказує відносини між ідентифікаторами виду і порядком декодування компонентів виду, згадані інструкції змушують один або більше процесорів надавати інформацію в рівні послідовності закодованих відеоданих.

65. Зчитаний комп'ютером, що запам'ятовує носій по п. 63, у якому інформація, яка вказує відносини між ідентифікаторами виду для цих видів і порядком декодування компонентів виду, містить таблицю відображення, яка відображає порядок декодування компонентів виду в ідентифікатори виду для згаданих видів.

66. Зчитаний комп'ютером, що запам'ятовує носій по п. 63, у якому інформація, яка вказує порядок декодування відповідних компонентів виду, міститься в частині заголовка одиниць NAL.

67. Зчитаний комп'ютером, що запам'ятовує носій по п. 63, у якому інформація, яка вказує порядок декодування відповідних компонентів виду, містить порядковий індекс виду.

68. Зчитаний комп'ютером, що запам'ятовує носій по п. 63, в якому компоненти видів множинних вр

 

Схожі патенти:

Статистичне кодування коефіцієнтів, використовуючи об'єднану контекстну модель

Винахід відноситься до обчислювальної техніки. Технічний результат полягає в зменшенні обсягу пам'яті, необхідної для збереження контекстів і ймовірностей на пристроях кодування і декодування відео. Спосіб кодування відео даних містить підтримка безлічі контекстних моделей для ентропійного кодування коефіцієнтів перетворення відео даних, при цьому безліч тематичних моделей включає в себе одну або більше контекстних моделей, причому кожна використовується для різного розміру одиниці перетворення, і щонайменше одну об'єднану контекстну модель, використовувану для двох або більше розмірів одиниці перетворення; вибір об'єднаної контекстної моделі, що використовується спільно першою одиницею перетворення і другий одиницею перетворення; вибір контекстів для коефіцієнтів перетворення, асоційованих з однієї з першої одиниці перетворення або другої одиниці перетворення згідно об'єднаної контекстної моделі; і энтропийное кодування коефіцієнтів перетворення згаданої однієї з одиниць перетворення, використовуючи контекстно-адаптивне двійкове арифметичне кодування (САВАС) на підставі обраних контекстів. 4

Спосіб і система для компенсації освітленості і переходу при кодуванні та обробки відеосигналу

Винахід відноситься до засобів обробки зображень. Технічним результатом є підвищення продуктивності засоби відображення зображення при кодуванні та обробки відеосигналу. У способі створюють кілька кадрів картинки і пов'язані опорні кадри передбачення; для кожного кадру і пов'язаного опорного кадру передбачення обчислюють величину інтенсивності і величину кольору в першій колірної області; для кожного кадру і пов'язаного опорного кадру передбачення обчислюють коефіцієнти підсилення зваженого передбачення; якщо зазначені коефіцієнти є неотрицательними, то визначають, що у другій колірної області відбувається глобальний перехід з нульовим зміщенням; і якщо не всі зазначені коефіцієнти є неотрицательними, то визначають, що не відбувається глобальний перехід з поступовою зміною освітленості. 15 н. і 13 з.п. ф-ли, 16 іл.

Кодування і декодування відео з підвищеною стійкістю до помилок

Винахід відноситься до області обробки цифрового сигналу і, зокрема, до області стиснення відеосигналу з використанням компенсації руху. Технічний результат - зниження просторових і тимчасових избиточностей в відеопотоків. Для цього спосіб кодування містить отримання цільового кількості провісників інформацією руху, підлягають використанню для кодованого ділянки зображення, і генерацію набору провісників руху інформації з використанням отриманого цільового кількості. Набір генерується шляхом: отримання першого набору провісників інформацією руху, кожен з яких пов'язаний з ділянкою зображення, що мають заздалегідь визначене просторове та/або тимчасове співвідношення з кодируемим ділянкою зображення; модифікації першого набору провісників інформацією руху шляхом видалення дубльованих провісників руху інформації для отримання скороченого набору провісників руху інформації, що містить перше кількість провісників інформацією руху, причому кожен провісник інформацією руху із скороченого набору відрізняється від будь-якого іншого провісника руху інформації з сокращенногои якщо перше менше кількість цільового кількості, отримання додаткового провісника інформацією руху і його додавання в скорочений набір провісників інформацією руху. 6 н. і 20 з.п. ф-ли, 8 іл.

Пристрій і спосіб передачі, пристрій і спосіб прийому і система передачі і прийому

Винахід відноситься до мовної системи для передачі цифрової телевізійної програми, зокрема, до пристрою передачі та способу передачі, в яких можна отримати вміст, який відповідає потребам. Технічним результатом є забезпечення доставки вмісту до клієнта, яка на цей момент задовольняє його потребам. Зазначений технічний результат досягається тим, що сервер генерує сценарій PDI-S для отримання PDI-A користувача боку, представляє відповіді користувача на питання про уподобання користувача; генерує інформацію пуску для виконання PDI-А; і передає інформацію пуску і PDI-S клієнту у відповідь на доставку телевізійного вмісту, і передає клієнту у відповідь на доставку посилального вмісту PDI-A поставляє боку, представляє відповідь, встановлений постачальником, на запитання. Клієнт виконує PDI-S на основі виявлення інформації пуску і здійснює зіставлення між PDI-А користувацької боку і PDI-А що поставляє боку, для визначення одержання посилального вмісту, отриманого сервером. 5 н. і 5 з.п. ф-ли, 48 іл.

Спосіб і пристрій кодування і декодування зображення з використанням внутрикадрового передбачення

Винахід відноситься до обчислювальної техніки. Технічний результат полягає в підвищенні ефективності стиснення зображень за допомогою використання режимів внутрикадрового передбачення, мають різні напрями. Пристрій для кодування зображення з використанням внутрикадрового передбачення містить блок визначення режиму внутрикадрового передбачення, який визначає режим внутрикадрового передбачення поточного блоку, що підлягає кодуванню, причому режим внутрикадрового передбачення вказує певний напрям з безлічі напрямків, при цьому певний напрям вказується за допомогою одного з числа dx в горизонтальному напрямку і постійного числа у вертикальному напрямку і числа dy у вертикальному напрямку і постійного числа в горизонтальному напрямку; і блок виконання внутрикадрового передбачення, що виконує внутрикадровое передбачення стосовно поточного блоку у відповідності з режимом внутрикадрового передбачення, причому внутрикадровое передбачення містить етап, на якому визначають позицію сусідніх пікселів допомогою операції зсуву на основі позиції поточного пікселя і одного з параметрів dx і а або на верхній стороні поточного блоку. 2 н. і 7 з.п. ф-ли, 21 іл., 4 табл.

Кодування сигналу в масштабований потік бітів і декодування такого потоку бітів

Винахід відноситься до способу кодування бітової площині сигналів, наприклад сигналу зображення або відео в області перетворення DCT. Технічний результат - підвищення продуктивності масштабованого способу стиснення вмісту сигналу. Бітові площини у блоків DCT передаються площину за площиною у порядку значущості. Оскільки кожна площина містить більше енергії сигналу, ніж менш значущі шари разом, результуючий потік бітів є масштабованим в тому сенсі, що він може бути усічений в будь-якій позиції. Чим пізніше відсікається потік бітів, тим менша залишкова помилка, коли відновлюється зображення. Для кожної бітової площині створюється зона або поділ бітової площині, яка включає в себе всі нульові біти коефіцієнтів DCT в тій бітової площині. Поділ створюється у відповідності зі стратегією, яка вибирається з певної кількості варіантів в залежності від вмісту всього сигналу і/або фактичної бітової площині. Для природних зображень може використовуватися інша стратегія зонування, ніж для графічного вмісту, і стратегія може змінюватися від бітової площині до бітової площині. Форма, а також дружимому. Двовимірні прямокутні зони та одномірні зигзагоподібні зони розгортки можуть змішуватися в межах зображення або навіть в межах блоку DCT. Обрана стратегія створення зони вбудовується в потік бітів разом з бітами коефіцієнта DCT у фактичному поділі. 4 н. і 9 з.п. ф-ли, 5 іл.

Спосіб визначення незаконного застосування пристрою обробки системи безпеки

Винахід відноситься до засобів виявлення незаконного застосування пристрою обробки системи безпеки, використовуваного для дескремблирования різних мультимедіа даних, поширюваних по кільком відповідних каналах. Технічний результат полягає в зменшенні імовірності незаконного застосування пристрою обробки. Підраховують нові повідомлення ECMj,c, прийняті пристроєм обробки системи безпеки для каналів, що відрізняються від каналу i, після останнього прийнятого повідомлення ECMi,p. Перевіряють, що повідомлення ECMi,c прийнято протягом зазначеного тимчасового інтервалу, шляхом перевірки, що кількість нових повідомлень ECMj,c, прийнятих для каналів, що відрізняються від каналу i, досягає чи перевершує заданий поріг, більший двох. Збільшують лічильник Kchi на задану величину всякий раз, коли, після перевірки, повідомлення ECMi,c прийнято протягом заданого часового інтервалу, наступного безпосередньо за повідомленням ECMi,p, і, в іншому випадку скидають лічильник Kchi у вихідне значення, виявляють незаконне застосування, як тільки лічильник Kchi досягає заданого порогу. 3 н. і 7 з.п. ф-ли, 3 іл.

Спосіб і пристрій для кодування відео і спосіб і пристрій для декодування відео допомогою компенсації піксельного значення у відповідності з групами пікселів

Винахід відноситься до обчислювальної техніки. Технічний результат полягає в підвищенні якості відновленого зображення. Спосіб декодування відео містить отримання з бітового потоку інформації про компенсації піксельного значення у відповідності з смугою піксельного значення або рівнем граничного значення, якщо інформація про компенсації піксельного значення вказує смугу, застосування значення компенсації визначеної смуги, отриманого з бітового потоку, до пікселя, включеному в зумовлену смугу, серед пікселів поточного блоку; і якщо інформація про компенсації піксельного значення вказує рівень граничного значення, застосування значення компенсації зумовленого напрямку кордону, отриманого з бітового потоку, до пікселю у визначеному напрямку кордону, серед пікселів поточного блоку, причому зумовлена смуга є однією з смуг, сформованих розбиттям повного діапазону піксельних значень. 2 з.п. ф-ли, 22 іл., 2 табл.

Вказівка вибору режиму внутрішнього передбачення для відеокодування з використанням савас

Винахід відноситься до засобів кодування і декодування відео. Технічним результатом є підвищення ефективності сигналізації режиму внутрішнього передбачення використовується для кодування блоку даних шляхом забезпечення відносної економії біт для кодованого бітового потоку. Спосіб містить визначення першого найбільш ймовірного режиму внутрішнього передбачення і другого найбільш ймовірного режиму внутрішнього передбачення для поточного блоку відеоданих на основі контексту для поточного блоку, виконання процесу контекстно-адаптивного двійкового арифметичного кодування (САВАС) для визначення прийнятого кодового слова, відповідного модифікованому індексу режиму внутрішнього передбачення, визначення індексу режиму внутрішнього передбачення, вибір режиму внутрішнього передбачення. 16 м. та 34 з.п. ф-ли, 13 іл. 7 табл.

Управління доступом користувача до мультимедійного контенту

Винахід відноситься до мультимедійного пристрою і системі для управління доступом користувача до мультимедійного контенту. Технічним результатом є управління доступом користувача до мультимедійного контенту, причому доступ дозволяється саме на обраному мультимедійному обладнанні. Запропоновано мультимедійний пристрій (100, 200) для управління доступом користувача до мультимедійного контенту, що містить: засіб виведення (102, 103, 202) ідентифікуючого коду для забезпечення ідентифікуючого коду користувачеві, причому ідентифікуючий код ідентифікує мультимедійний пристрій; генератор (104, 204) керуючого коду для генерації керуючого коду в залежності від згаданого ідентифікуючого коду і права доступу; засіб вводу (106, 107, 206) коду доступу для приймання коду доступу від користувача. Код доступу згенерований в залежності від ідентифікуючого коду і права доступу деяким пристроєм коду доступу, а контролер (108, 208) доступу забезпечує порівняння коду доступу з керуючим кодом і, коли код доступу збігається з керуючим кодом, що дозволяє доступ користувача до мультимедійного контенту у відповідності з правом доступу. 4 н. і 10 з.п. ф-ли, 6 іл.
Up!