Багатовидове відеокодування в системах mpeg-2

Реферат: Мультиплексор може формувати потік бітів стандарту MPEG-2 (Експертна група по рухомих зображеннях) Систем, що містить види з непослідовними порядковими індексами видів. У одному прикладі пристрій містить відеокодер, який кодує множину видів сцени, мультиплексор, який формує структуру даних для сигналізації, що відповідний потік бітів стандарту MPEG-2 систем містить перший вид сцени, асоційований з першим порядковим індексом виду, і другий вид сцени, асоційований з другим порядковим індексом виду, причому перший порядковий індекс виду і другий порядковий індекс виду є непослідовними, і вихідний інтерфейс для виведення даних. UA 100645 C2 (12) UA 100645 C2 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 Споріднені заявки Дана заявка вимагає пріоритет Попередніх заявок США № 61/221449, поданої 29 червня 2009, і 61/186613, поданої 12 червня 2009, весь зміст яких у всій їх повноті даним явно включений в даний документ за допомогою посилання. Перехресне посилання на споріднені заявки Дана заявка на патент пов'язана з наступною патентною заявкою, що знаходиться на розгляді США: "Assembling Multiview Video Coding Sub-Bitstreams in MPEG-2 Systems" автора Ying Chen, номер справи повіреного № 092652, поданий одночасно з даною заявкою, переуступленою заявнику даної заявки і явно включеної за допомогою посилання в даний документ. Галузь техніки Дане розкриття стосується транспорту кодованих відеоданих. Попередній рівень техніки Цифрові відео функціональні можливості можуть бути включені в широкий діапазон пристроїв, включаючи цифрові телевізори, цифрові системи прямого мовлення, бездротові системи мовлення, персональні цифрові помічники (PDA), ноутбуки або настільні комп'ютери, цифрові фотокамери, пристрої цифрового запису, цифрові медіаплеєри, відео ігрові пристрої, ігрові приставки, стільникові або супутникові радіотелефони, пристрої відео телеконференцій і т. п. Цифрові відеопристрої реалізовують методи відеостиснення, такі як описані в стандартах, визначених MPEG-2, MPEG-4, ITU-T H.263 або ITU-T H.264/MPEG-4, Частина 10, Вдосконалене Відеокодування (AVC), і розширеннях таких стандартів, щоб передавати і приймати цифрову відеоінформацію ефективніше. Методи відеостиснення виконують просторовий прогноз і/або тимчасовий прогноз, щоб зменшити або видалити надмірність, властиву відеопослідовностям. Для блочного відеокодування, відеокадр або вирізка можуть бути розділені в макроблоки. Кожний макроблок може бути додатково розділений. Макроблоки в інтра-(«всередині») кодованому (I) кадрі або вирізці кодуються з використанням просторового прогнозу відносно сусідніх макроблоків. Макроблоки в інтер-(«між»)кодованому (Р або В) кадрі або вирізці можуть використовувати просторовий прогноз відносно сусідніх макроблоків в тому ж самому кадрі або вирізці або тимчасовий прогноз відносно інших опорних кадрів. Після того, як відеодані закодовані, відеодані можуть пакетуватися мультиплексором для передачі або зберігання. MPEG-2 містить секцію "Системи", яка визначає транспортний рівень для багатьох стандартів відеокодування. Системи транспортного рівня MPEG-2 можуть використовуватися відеокодерами MPEG-2 або іншими відеокодерами, відповідними різним стандартам відеокодування. Наприклад, MPEG-4 призначає різні методи кодування і декодування, інші ніж в MPEG-2, але відеокодери, що реалізовують методи стандарту MPEG-4, можуть все ще використовувати методології транспортного рівня MPEG-2. У загальному випадку, посилання на "MPEG-2 системи" належать до транспортного рівня відеоданих, призначеного MPEG-2. Транспортний рівень, призначений MPEG-2, також згадується в даному розкритті як "транспортний потік MPEG-2" або просто "транспортний потік". Аналогічно, транспортний рівень систем MPEG-2 також містить потоки програми. Транспортні потоки і потоки програми в загальному випадку включають різні формати для доставки подібних даних, де транспортний потік містить одну або більше "програм", що включають як аудіо, так і відеодані, в той час як потоки програми включають одну програму, що містить як аудіо, так і відеодані. Специфікація MPEG-2 систем описує, як стислі мультимедіа (відео і аудіо) потоки даних можуть мультиплексуватися разом з іншими даними, щоб сформувати єдиний потік даних, відповідний для цифрової передачі або зберігання. Остання специфікація систем MPEG-2 визначена в документі "Інформаційна технологія - родове кодування рухомих зображень і асоційованої аудіоінформації: Системи, Рекомендація H.222.0; Міжнародна Організація по Стандартизації, ISO/IEC JTC1/SC29/WG11; Кодування рухомих зображень і асоційованої аудіоінформації", травень 2006. MPEG нещодавно випустила транспортний стандарт MVC по MPEG-2 системах, і останньою версією цієї специфікації є: "Study of ISO/IEC 138181:2007/FPDAM4 Trabsport of MVC", MPEG doc. N10572, MPEG of ISO/IEC JTCl/SC29/WG11, Maui, Hawaii, USA, April 2009. Суть винаходу Загалом, дане розкриття описує методи для удосконалення багатовидового відеокодування в системах MPEG-2 (Експертна група по рухомих зображеннях). Способи даного розкриття в принципі розширюють можливості транспортного рівня MPEG-2, наприклад, MPEG-2 транспортних потоків і потоків програми MPEG-2, відносно багатовидового відеокодування 1 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 (MVC). Наприклад, способи даного розкриття забезпечують можливість передачі непослідовних видів (представлень) відеопотоку MVC, що підлягає передачі на транспортному рівні. Методи даного розкриття далі забезпечують можливість того, що підпотоки бітів транспортного потоку (або програми), кожний, включають в себе непослідовні види. Ці методи також дозволяють пристрою прийому, після прийому потоку транспортного рівня, що містить множину підпотоків бітів, кожний з яких має непослідовні види, переупорядковувати види в підпотоках бітів таким чином, що транспортний потік упорядковується належно, тобто у зростаючому порядку з точки зору порядкових індексів видів, так що декодер може належно декодувати кадри кожного з видів. У одному прикладі спосіб містить формування, пристроєм джерела, структури даних для сигналізації, що відповідний потік бітів стандарту MPEG-2 систем містить перший вид сцени, асоційований з першим порядковим індексом виду, і другий вид сцени, асоційований з другим порядковим індексом виду, причому перший порядковий індекс виду і другий порядковий індекс виду є непослідовними. Спосіб також містить виведення даних, наприклад, передачу структури даних до пристрою призначення або збереження структури даних на машиночитаному носії. У іншому прикладі пристрій містить відеокодер, який кодує множину видів сцени, мультиплексор, який формує структуру даних для сигналізації, що відповідний потік бітів стандарту MPEG-2 систем містить перший вид сцени, асоційований з першим порядковим індексом виду, і другий вид сцени, асоційований з другим порядковим індексом виду, причому перший порядковий індекс виду і другий порядковий індекс виду є непослідовними, і вихідний інтерфейс для виведення даних. У іншому прикладі пристрій містить засіб для формування, пристроєм джерела, структури даних для сигналізації, що відповідний потік бітів стандарту MPEG-2 систем містить перший вид сцени, асоційований з першим порядковим індексом виду, і другий вид сцени, асоційований з другим порядковим індексом виду, причому перший порядковий індекс виду і другий порядковий індекс виду є непослідовними, і засіб для виведення даних. У іншому прикладі комп’ютерозчитуваний носій даних закодований інструкціями, які спонукають процесор формувати структуру даних для сигналізації, що відповідний потік бітів стандарту MPEG-2 систем містить перший вид сцени, асоційований з першим порядковим індексом виду, і другий вид сцени, асоційований з другим порядковим індексом виду, причому перший порядковий індекс виду і другий порядковий індекс виду є непослідовними, і виводити структуру даних. У ще одному прикладі спосіб містить формування, клієнтським пристроєм, потоку бітів, сумісного зі стандартом багатовидового відеокодування (MVC) з прийнятого потоку бітів, що містить основний підпотік бітів і вкладений підпотік бітів основного підпотоку бітів, причому формування потоку бітів, сумісного зі стандартом MVC, містить визначення, чи має компонент виду основного підпотоку бітів порядковий індекс виду, який більший, ніж порядковий індекс виду компонента виду вкладеного підпотоку бітів; якщо порядковий індекс виду компонента виду основного підпотоку бітів більший, ніж порядковий індекс виду компонента виду вкладеного підпотоку бітів, то додавання компонента виду вкладеного підпотоку бітів до потоку бітів, що формується, а якщо порядковий індекс виду компонента виду основного підпотоку бітів не більший, ніж порядковий індекс виду компонента виду вкладеного підпотоку бітів, то додавання компонента виду основного підпотоку бітів до потоку бітів, що формується. Спосіб далі містить виведення сформованого потоку бітів у відеодекодер. У іншому прикладі пристрій містить приймач, який приймає потік бітів, що містить основний підпотік бітів і вкладений підпотік бітів основного підпотоку бітів, демультиплексор, який формує потік бітів, сумісний зі стандартом MVC, з прийнятого потоку бітів, причому для формування потоку бітів, сумісного зі стандартом MVC, демультиплексор визначає, чи має компонент виду основного підпотоку бітів порядковий індекс виду, який більший, ніж порядковий індекс виду компонента виду вкладеного підпотоку бітів, і додає компонент виду вкладеного підпотоку бітів до потоку бітів, що формується, коли порядковий індекс виду компонента виду основного підпотоку бітів більший, ніж порядковий індекс виду компонента виду вкладеного підпотоку бітів, і додає компонент виду основного підпотоку бітів до потоку бітів, що формується, коли порядковий індекс виду компонента виду основного підпотоку бітів не більший, ніж порядковий індекс виду компонента виду вкладеного підпотоку бітів, і відеодекодер, який декодує потік бітів, сформований демультиплексором. У іншому прикладі пристрій містить засіб для формування потоку бітів, сумісного зі стандартом багатовидового відеокодування (MVC) з прийнятого потоку бітів, що містить основний підпотік бітів і вкладений підпотік бітів основного підпотоку бітів, засіб для визначення, чи має компонент виду основного підпотоку бітів порядковий індекс виду, який 2 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 більший, ніж порядковий індекс виду компонента виду вкладеного підпотоку бітів; засіб для додавання компонента виду вкладеного підпотоку бітів до потоку бітів, що формується, якщо порядковий індекс виду компонента виду основного підпотоку бітів більший, ніж порядковий індекс виду компонента виду вкладеного підпотоку бітів, і засіб для додавання компонента виду основного підпотоку бітів до потоку бітів, що формується, якщо порядковий індекс виду компонента виду основного підпотоку бітів не більший, ніж порядковий індекс виду компонента виду вкладеного підпотоку бітів, і засіб для виведення сформованого потоку бітів у відеодекодер. У іншому прикладі комп’ютерозчитуваний носій зберігання закодований інструкціями для спонукання програмованого процесора формувати, клієнтським пристроєм, потік бітів, сумісний зі стандартом багатовидового відеокодування (MVC) з прийнятого потоку бітів, що містить основний підпотік бітів і вкладений підпотік бітів основного підпотоку бітів, що містять інструкції, щоб визначати, чи має компонент виду основного підпотоку бітів порядковий індекс виду, який більший, ніж порядковий індекс виду компонента виду вкладеного підпотоку бітів; якщо порядковий індекс виду компонента виду основного підпотоку бітів більший, ніж порядковий індекс виду компонента виду вкладеного підпотоку бітів, то додавати компонент виду вкладеного підпотоку бітів до потоку бітів, що формується, а якщо порядковий індекс виду компонента виду основного підпотоку бітів не більший, ніж порядковий індекс виду компонента виду вкладеного підпотоку бітів, то додавати компонент виду основного підпотоку бітів до потоку бітів, що формується, і виводити сформований потік бітів у відеодекодер. Деталі одного або більше прикладів викладені на ілюстрованих кресленнях і в описі, наведеному нижче. Інші ознаки, об'єкти і переваги будуть очевидні з опису і креслень, а також з формули винаходу. Короткий опис креслень Фіг. 1 - блок-схема, що ілюструє систему як приклад, в якій пристрій джерела аудіо/відео (А/V) транспортує аудіо і відеодані до пристрою призначення А/V. Фіг. 2 - блок-схема, що ілюструє зразкову конфігурацію компонентів мультиплексора. Фіг. 3 - блок-схема, що ілюструє зразковий набір таблиць специфічної для програми інформації. Фіг. 4 - блок-схема, що ілюструє зразковий набір даних, які можуть бути включені в дескриптор розширення багатовидового відеокодування (MVC). Фіг. 5 - блок-схема, що ілюструє зразковий набір даних, які можуть бути включені в дескриптор ієрархії. Фіг. 6 - концептуальна діаграма, що ілюструє зразковий шаблон прогнозу MVC. Фіг. 7 - блок-схема, що ілюструє зразковий спосіб відправлення потоку MPEG-2 систем, що має піднабір видів з непослідовними порядковими індексами видів, від сервера до клієнта. Фіг. 8 - блок-схема, що ілюструє зразковий спосіб збирання компонентів видів двох або більше підпотоків бітів, щоб сформувати потік бітів таким чином, що компоненти видів мають зростаючі порядкові індекси видів. Докладний опис Методи даного розкриття загалом спрямовані на удосконалення багатовидового відеокодування (MVC) в MPEG-2 системах, тобто системах, які відповідають MPEG-2 відносно деталей транспортного рівня. MPEG-4, наприклад, забезпечує стандарти для відеокодування, але в принципі передбачає, що відеокодери, що відповідають стандарту MPEG-4, будуть використовувати системи транспортного рівня MPEG-2. Відповідно, методи даного розкриття застосовні до відеокодерів, які відповідають MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG4 або будь-якому іншому стандарту кодування відео, який використовує транспортні потоки MPEG-2 і/або потоки програми. Зокрема, методи даного розкриття можуть використовуватися, щоб змінювати елементи синтаксису на транспортному рівні для транспортних потоків MPEG-2 і потоків програми. Наприклад, методи даного розкриття включають дескриптор, який передається в транспортному потоці, щоб спеціально ідентифікувати кожний вид багатовидових відеоданих, які відсилаються в транспортному потоці. Серверний пристрій, наприклад, може надавати різні послуги, кожна з яких містить відповідні підмножини конкретних видів багатовидового кодування відеоданих, де підмножина видів послуги може бути вибрана на основі додатку, що виконується клієнтським пристроєм, можливостей декодерів, що функціонують на клієнтському пристрої, переваг, виражених клієнтським пристроєм, або інших критеріїв вибору. Відповідно до методів даного розкриття, серверний пристрій може забезпечити підмножину видів, що мають непослідовні порядкові індекси видів. У одному прикладі серверний пристрій конкретно сигналізує кожний з видів, які будуть включені в транспортний потік, в дескрипторі 3 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 розширення MVC, який може бути включений в таблицю карти програми (PMT) або карту потоку програми (PSM). У деяких прикладах серверний пристрій може відіслати множину підпотоків бітів в єдиному транспортному потоці або потоці програми. Дозволяючи видам потоку бітів бути непослідовними, методи даного розкриття також дозволяють порядковим індексам видів, відповідним видам кожного підпотоку бітів, бути непослідовними. Хоч ці методи допускають непослідовні порядкові індекси видів в кожному підпотоці бітів, порядкові індекси видів все ще повинні бути такими, що зростають в підпотоці бітів, щоб відповідати існуючим стандартам потоків бітів, наприклад, стандарту MPEG-2 систем. Оскільки види першого підпотоку бітів і другого підпотоку бітів можуть, кожний, бути непослідовними, види можуть надходити на клієнтський пристрій не в порядку відносно порядкових індексів видів. Методи даного розкриття також дозволяють клієнтському пристрою обробляти такий транспортний потік, щоб ефективно переупорядкувати види першого підпотоку бітів і другого підпотоку бітів, таким чином, що порядкові індекси виду для видів збільшуються. Комбінації видів, що мають непослідовні порядкові індекси видів, можуть використовуватися для масштабованості видів, яка може бути корисною для адаптації ширини смуги, ефективності декодера і забезпечення інших таких переваг. Наприклад, протилежно звичайним методам, які потребували б передачі всіх видів на клієнтський пристрій клієнта, і щоб клієнтський пристрій декодував кожний вид, що має послідовні порядкові індекси видів, методи даного розкриття дозволяють відсилати тільки ті види, які конкретно потрібні клієнтському пристрою, навіть коли це приводить до видів, що мають непослідовні порядкові індекси видів. Таким способом клієнтський пристрій може приймати тільки ті види, які необхідні для конкретної послуги, а не всі види з проміжними порядковими індексами видів. Хоч в різних розділах даного розкриття можуть згадуватися індивідуально "транспортний потік" або "потік програми", треба мати на увазі, що способи даного розкриття в загальному випадку застосовні до будь-якого або обох із транспортних потоків MPEG-2 і потоків програми. У загальному випадку, дане розкриття описує зразкові дескриптори для виконання методів даного розкриття. Дескриптори використовуються, щоб розширити функціональність потоку. Дескриптори даного розкриття можуть використовуватися і транспортними потоками і потоками програми, щоб здійснити методи даного розкриття. Дане розкриття також використовує наступні терміни і пропонує включити ці терміни у версію поточного стандарту систем MPEG-2, разом із семантикою термінів, як вказано: AVC підпотік бітів відео: базовий вид MVC потоку бітів. AVC підпотік бітів відео MVC: базовий вид MVC потоку бітів з відкиданням префіксних одиниць NAL. Базовий підпотік бітів відео MVC: AVC підпотік бітів відео або AVC підпотік бітів відео MVC. Піднабір компонентів виду MVC: одиниці NAL одного компонента виду. Піднабір view_id MVC: одиниці NAL одного виду. Підпотік видів відео MVC: одиниці NAL не-базових видів. Фіг. 1 - блок-схема, що ілюструє наведену для прикладу систему 10, в який пристрій 20 джерела аудіо/відео (А/V) транспортують аудіо і відеодані до пристрою 40 призначення А/V. Система 10 по Фіг. 1 може відповідати системі відео телеконференції, системі сервер/клієнт, системі служби мовлення/приймача або будь-якій іншій системі, в якій відеодані відсилають з пристрою джерела, такого як пристрій 20 джерела А/V, до пристрою призначення, такого як пристрій 40 А/V призначення. У деяких прикладах пристрій 20 джерела А/V і пристрій 40 призначення А/V можуть виконувати двоспрямований інформаційний обмін. Тобто, пристрій 20 джерела А/V і пристрій 40 призначення А/V можуть мати можливість кодування і декодування (і передачі, і прийому) аудіо і відеоданих. У деяких прикладах аудіокодер 26 може містити голосовий кодер, що також називається вокодером. Пристрій 20 джерела А/V, в прикладі Фіг. 1, містить джерело 22 аудіо і джерело 24 відео. Джерело 22 аудіо може містити, наприклад, мікрофон, який формує електричні сигнали, що характеризують захоплені аудіодані, які повинні кодуватися аудіокодером 26. Альтернативно, джерело 22 аудіо може містити носій даних, що зберігає раніше зареєстровані аудіодані, генератор аудіоданих, такий як комп’ютеризований синтезатор, або будь-яке інше джерело аудіоданих. Джерело 24 відео може містити відеокамеру, яка формує відеодані, які повинні кодуватися відеокодером 28, носій даних, кодований раніше записаними відеоданими, блок генерації відеоданих, або будь-яке інше джерело відеоданих. Початкові аудіо- і відеодані можуть містити аналогові або цифрові дані. Аналогові дані можуть бути перетворені в цифрову форму, перш ніж кодуватися аудіокодером 26 і/або відеокодером 28. Джерело 22 аудіо може отримувати аудіодані від учасника, що говорить, в той час як учасник, що говорить, говорить, і 4 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 джерело 24 відео може одночасно отримувати відеодані учасника, що говорить. У інших прикладах джерело 22 аудіо може містити комп’ютерозчитуваний носій даних, що містить збережені аудіодані, і джерело 24 відео може містити комп’ютерозчитуваний носій даних, що містить збережені відеодані. Таким чином, методи, описані в даному розкритті, можуть бути застосовані до живих (прямого ефіру), потокових аудіо- і відеоданих в реальному часі або до заархівованих, записаних заздалегідь аудіо- і відеоданих. Аудіокадри, які відповідають відеокадрам, є звичайно аудіокадрами, що містять аудіодані, які були захоплені джерелом 22 аудіо одночасно з відеоданими, захопленими джерелом 24 відео, яке міститься у відеокадрах. Наприклад, в той час як учасник, що говорить, звичайним чином формує аудіодані, джерело 22 аудіо захоплює аудіодані, і джерело 24 відео захоплює відеодані учасника, що говорить, в той же самий час, тобто, коли джерело 22 аудіо захоплює аудіодані. Отже, аудіокадр може у часі відповідати одному або більше конкретним відеокадрам. Відповідно, аудіокадр, відповідний відеокадру, в загальному випадку відповідає ситуації, в якій аудіодані і відеодані були захоплені в той же самий час і для якої аудіокадр і відеокадр містять, відповідно, аудіодані і відеодані, які були захоплені в той же самий час. У деяких прикладах аудіокодер 26 може кодувати часову мітку в кожному закодованому аудіокадрі, яка представляє час, в який були зареєстровані аудіодані для закодованого аудіокадру, і точно так само відеокодер 28 може закодувати часову мітку в кожному закодованому відеокадрі, яка представляє час, в який були записані відеодані для закодованого відеокадру. У таких прикладах аудіокадр, відповідний відеокадру, може містити аудіокадр, що містить часову мітку, і відеокадр, що містить ту ж саму часову мітку. Пристрій 20 джерела А/V може містити внутрішні години, з яких аудіокодер 26 і/або відеокодер 28 можуть сформувати часову мітку, або джерело 22 аудіо і джерело 24 відео можуть використати її, щоб асоціювати аудіо- і відеодані відповідно, з часовою міткою. У деяких прикладах джерело 22 аудіо може відіслати дані в аудіокодер 26 відповідно до часу, в який були записані аудіодані, і відеоджерело 24 може відіслати дані у відеокодер 28 відповідно до часу, в який були записані відеодані. У деяких прикладах аудіокодер 26 може кодувати ідентифікатор послідовності в кодованих аудіоданих, щоб вказати відносне тимчасове упорядкування кодованих аудіоданих, але без необхідності вказування абсолютного часу, в який були записані аудіодані, і точно так само відеокодер 28 може також використовувати ідентифікатори послідовності, щоб вказати відносне тимчасове упорядкування кодованих відеоданих. Аналогічно, в деяких прикладах, ідентифікатор послідовності може бути відображений або іншим чином корельований з часовою міткою. Методи даного розкриття загалом спрямовані на транспорт кодованих мультимедійних (наприклад, аудіо і відео) даних і прийом і подальшу інтерпретацію і декодування мультимедійних даних, що транспортуються. Методи даного розкриття особливо застосовні до транспорту даного багатовидового відеокодування (MVC), тобто відеоданих, що містять множину видів. Як показано в прикладі Фіг. 1, джерело 24 відео може надати множину видів сцени на відеокодер 28. MVC може бути корисним для генерації тривимірних відеоданих, які будуть використовуватися тривимірним пристроєм відображення, таким як стереоскопічний або автостереоскопічний тривимірний дисплей. Пристрій 20 джерела А/V може надати "послугу" пристрою 60 призначення А/V. Послуга в загальному випадку відповідає підмножині доступних видів даних MVC. Наприклад, дані MVC можуть бути доступними для восьми видів, впорядкованих як від нуля до семи. Одна послуга може відповідати стерео відео, що має два види, в той час як інша послуга може відповідати чотирьом видам, і ще одна послуга може відповідати всім восьми видам. У загальному випадку, послуга відповідає будь-якій комбінації (тобто, будь-якому піднабору) доступних видів. Послуга може також відповідати комбінації доступних видів, а також аудіоданих. Пристрій 20 джерела А/V, відповідно до методів цього розкриття, може надавати послуги, які відповідають піднабору видів, які включають непослідовні порядкові індекси видів. У загальному випадку, вид представлений ідентифікатором виду, що також називається "view_id". Ідентифікатори виду в загальному випадку включають елементи синтаксису, які можуть використовуватися, щоб ідентифікувати вид. Кодер MVC забезпечує view_id виду, коли вид кодується. View_id може використовуватися декодером MVC для міжвидового прогнозу або іншими блоками в інших цілях, наприклад, для відтворення. Міжвидовий прогноз представляє метод для кодування відеоданих MVC кадру відносно одного або більше кадрів в загальному тимчасовому місцеположенні як кодованих кадрів різних видів. Фіг. 6, яка обговорена детальніше нижче, представляє приклад схеми кодування для міжвидового прогнозу. У загальному випадку кодований кадр відеоданих MVC може бути предиктивно (з прогнозуванням) закодований по простору, часу і/або відносно кадрів інших 5 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 видів в загальному тимчасовому місцеположенні. Відповідно, опорні види, з яких передбачаються інші види, в загальному випадку перед видами, для яких опорні види діють як опора, так що ці декодовані види можуть використовуватися як опора при декодуванні посилальних видів. Порядок декодування не обов'язково відповідає порядку view_id. Тому порядок декодування видів описаний з використанням порядкових індексів видів. Порядкові індекси видів представляють індекси, які вказують на порядок декодування відповідних компонентів виду в одиниці доступу. Кожний окремий потік даних (аудіо або відео) згадується як елементарний потік. Елементарний потік є одиночним, в цифровій формі кодованим (можливо, стислим) компонентом програми. Наприклад, кодована відео або аудіо частина програми може бути елементарним потоком. Елементарний потік може бути перетворений в пакетований елементарний потік (PES), перш ніж мультиплексуватися в потік програми або транспортний потік. У межах тієї ж самої програми ідентифікатор потоку використовується, щоб відрізнити пакети PES, що належать одному елементарному потоку, від інших. Базовою одиницею даних елементарного потоку є пакет пакетованого елементарного потоку (PES). Таким чином, кожний вид відеоданих MVC відповідає відповідним елементарним потокам. Точно так само аудіодані відповідають відповідному елементарному потоку. У прикладі Фіг. 1 мультиплексор 30 отримує елементарні потоки, що містять відеодані, від відеокодера 28, і елементарні потоки, що містять аудіодані, від аудіокодера 26. У деяких прикладах відеокодер 28 і аудіокодер 26 можуть кожний містити формувачі пакетів, щоб формувати пакети PES з кодованих даних. У інших прикладах відеокодер 28 і аудіокодер 26 можуть кожний взаємодіяти з відповідним формувачем пакетів, щоб формувати пакети PES з кодованих даних. У інших прикладах мультиплексор 30 може містити формувачі пакетів, щоб формувати пакети PES з кодованих аудіо і відеоданих. "Програма", як використовується в даному розкритті, може містити комбінацію аудіоданих і відеоданих, наприклад, елементарний потік аудіо і підмножини доступних видів, доставлених послугою пристрою 20 джерела А/V. Кожний пакет PES містить ідентифікатор потоку stream_id, який ідентифікує елементарний потік, якому належить пакет PES. Мультиплексор 30 відповідальний за збирання елементарних потоків в компонентні потоки програми або транспортні потоки. Потік програми і транспортний потік - це дві альтернативи мультиплексування, націлені на різні додатки. У загальному випадку, потік програми складається з даних для однієї програми, в той час як транспортний потік може містити дані для однієї або більше програм. Мультиплексор 30 може кодувати будь-який або обидва з потоку програми або транспортного потоку, основуючись на послузі, що надається, середовищі, в яке потік буде передаватися, числі програм, які повинні відсилатися, або інших факторах. Наприклад, коли відеодані повинні бути закодовані на носії даних, мультиплексор 30 може ймовірніше формувати потік програми, а коли відеодані повинні передаватися потоком по мережі, широкомовно передаватися або відсилатися як частина відео телефонії, мультиплексор 30 може ймовірніше використовувати транспортний потік. Мультиплексор 30 може зробити вибір на користь використання потоку програми для зберігання і відображення єдиної програми з послуги цифрового зберігання. Потік програми призначений для використання в не схильному до помилок середовищі або середовищі, менш схильному до виникаючих помилок, тому що потоки програми досить схильні до помилок. Потік програми просто містить елементарні потоки, що належать йому, і звичайно містить пакети зі змінними довжинами. У потоці програми PES-пакети, які отримані з компонентних елементарних потоків, організовані в "пачки". Пачка містить заголовок пачки, опціональний системний заголовок і будь-яке число пакетів PES, взятих з будь-якого із компонентних елементарних потоків, в будь-якому порядку. Системний заголовок містить зведення характеристик потоку програми, таких як його максимальна швидкість передачі даних, число компонентних відео і аудіо елементарних потоків, додаткова інформація синхронізації або інша інформація. Декодер може використовувати інформацію, що міститься в системному заголовку, щоб визначити, здатний декодер декодувати потік програми чи ні. Мультиплексор 30 може використовувати транспортний потік для одночасної доставки множини програм по потенційно схильних до помилок каналах. Транспортний потік - це мультиплекс (об'єднання), призначений для багатопрограмних додатків, таких як радіомовлення, так що єдиний транспортний потік може вмістити багато незалежних програм. Транспортний потік містить послідовність транспортних пакетів, кожний з транспортних пакетів має довжину 188 байтів. Використання коротких пакетів фіксованої довжини означає, що транспортний потік менш схильний до помилок, ніж потік програми. Далі, кожному транспортному пакету довжиною 188 байтів може бути наданий додатковий захист від помилок шляхом обробки пакету за допомогою стандартного процесу захисту від помилок, такого як 6 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 кодування Ріда-Соломона. Поліпшена стійкість до помилок транспортного потоку означає, що він має кращий шанс виживання в каналах, схильних до помилок, що є, наприклад, в середовищі мовлення. Могло б здаватися, що транспортний потік явно кращий з двох мультиплексів, з його збільшеною стійкістю до помилок і здатністю переносити багато одночасних програм. Однак транспортний потік є складнішим мультиплексом, ніж потік програми, і є, важчим для створення і демультиплексування. Перший байт транспортного пакету - це байт синхронізації, що має значення 0x47 (шістнадцяткове 47, двійкове 01000111, десяткове 71). Єдиний транспортний потік може переносити багато різних програм, причому кожна програма містить багато пакетованих елементарних потоків. Мультиплексор 30 може використовувати 13-бітове поле Ідентифікатора Пакету (PID), щоб відрізнити транспортні пакети, що містять дані одного елементарного потоку, від тих, які несуть дані інших елементарних потоків. Обов'язком мультиплексора є гарантувати, що кожний елементарний потік забезпечений унікальним значенням PID. Останній байт транспортного пакету - поле рахунку безперервності. Мультиплексор 30 дає приріст значенню поля рахунку безперервності між послідовними транспортними пакетами, що належать тому ж самому елементарному потоку. Це дозволяє декодеру або іншому блоку пристрою призначення, такого як пристрій 40 призначення А/V, виявити втрату або посилення транспортного пакету і, треба сподіватися, приховати помилки, які могли б інакше бути результатом такої події. Мультиплексор 30 отримує пакети PES для елементарних потоків програми від аудіокодера 26 і відеокодера 28 і формує відповідні одиниці шару мережевої абстракції (NAL) з пакетів PES. У прикладі H.264/AVC (вдосконалене відеокодування) кодовані відеосегменти організовані в одиниці NAL, які забезпечують "дружнє для мережі" представлення відео, що адресується додаткам, таким як відео телефонія, зберігання, мовлення або потокова передача. Одиниці NAL можуть бути категоризовані на одиниці NAL шару відеокодування (VCL) і одиниці NAL неVCL. Блоки VCL містять основний механізм стиснення і можуть містити рівні блоків, макроблоків і/або вирізок. Інші одиниці NAL є не-VCL одиницями NAL. Мультиплексор 30 може сформувати одиниці NAL, що включають заголовок, який ідентифікує програму, якій належить NAL, а також корисне навантаження, наприклад, аудіодані, відеодані або дані, які описують транспортний потік або потік програми, якому відповідає одиниця NAL. Наприклад, в H.264/AVC, одиниця NAL містить 1-байтовий заголовок і корисне навантаження змінного розміру. У одному прикладі заголовок одиниці NAL містить елемент priority_id, елемент temporal_id, елемент anchor_pic_flag, елемент view_id, елемент non_idr_flag і елемент inter_view_flag. У звичайному MVC одиниця NAL, визначена H.264, збережена, за винятком префіксних одиниць NAL і MVC-кодованих одиниць NAL вирізок, які включають 4байтовий заголовок одиниці NAL MVC і корисне навантаження одиниці NAL. Елемент priority_id заголовка NAL може використовуватися для простого процесу адаптації одноканального потоку бітів. Елемент temporal_id може використовуватися для визначення тимчасового рівня відповідної одиниці NAL, де різні тимчасові рівні відповідають різним швидкостям кадрів. Елемент anchor_pic_flag може вказати, чи є картина картиною прив'язки (опорною картиною) або не-опорною картиною. Опорні картини і всі картини, що йдуть за ними в порядку виведення (тобто, порядку відображення), можуть бути правильно декодовані без декодування попередніх картин в порядку декодування (тобто, порядку потоку бітів), і таким чином можуть використовуватися як точки довільного доступу. Опорні картини і не-опорні картини можуть мати різну залежність, яка сигналізується в наборі параметрів послідовності. Інші прапори будуть обговорюватися і використовуватися в наступних розділах. Така опорна картина може також згадуватися як відкрита точка доступу GOP (групи картин), в той час як закрита точка доступу GOP також підтримується, коли елемент non_idr_flag дорівнює нулю. Елемент non_idr_flag вказує, чи є картина картиною миттєвого оновлення декодера (IDR) або картиною IDR виду (V-IDR). У загальному випадку, картина IDR і всі картини, що йдуть за нею в порядку виведення або порядку потоку бітів, можуть бути правильно декодовані без декодування попередніх картин в порядку декодування або в порядку відображення. Елемент view_id містить інформацію синтаксису, яка може використовуватися, щоб ідентифікувати вид, який може використовуватися для інтерактивності даних в декодері MVC, наприклад, для міжвидового прогнозу, і поза декодером, наприклад, для рендерингу (візуалізації). Елемент inter_view_flag може визначати, чи використовується відповідна одиниця NAL іншими видами для міжвидового прогнозу. Щоб переносити 4-байтову інформацію заголовка одиниці NAL для базового виду, яка може бути сумісна з AVC, префіксна одиниця NAL визначена в MVC. У контексті MVC одиниця доступу базового виду містить VCL NAL 7 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 одиниці поточного моменту часу виду, а також його префіксну одиницю NAL, яка містить тільки головну частину одиниці NAL. H.264/AVC декодер може ігнорувати префіксну одиницю NAL. Одиниця NAL, що включає відеодані в своєму корисному навантаженні, може містити різні рівні гранулярності відеоданих. Наприклад, одиниця NAL може містити блок відеоданих, макроблок, множину макроблоків, вирізку (slice) відеоданих або весь кадр відеоданих. Мультиплексор 30 може отримати кодовані відеодані від відеокодера 28 у формі пакетів PES елементарних потоків. Мультиплексор 30 може асоціювати кожний елементарний потік з відповідною програмою шляхом відображення ідентифікаторів потоку stream_id на відповідні програми, наприклад, в базі даних або іншій структурі даних, такій як Таблиця Карти Програми (PMT) або Карта Потоку Програми (PSM). Мультиплексор 30 може також зібрати одиниці доступу з множини одиниць NAL. У загальному випадку, одиниця доступу може містити одну або більше одиниць NAL для представлення структури відеоданих, а також аудіоданих, відповідних кадру, коли такі аудіодані доступні. У прикладі, відповідному H.264/AVC, одиниця доступу може містити кодовану картину в один момент часу, що може бути представлено як основна кодована картина. Відповідно, одиниця доступу може містити всі аудіо і відеокадри загального моменту часу, наприклад, всі види, відповідні часу X. Дане розкриття також відсилається на кодовану картину конкретного виду як на "компонент виду". Таким чином, компонент виду містить кодовану картину (або кадр) для конкретного виду в конкретний час. Відповідно одиниця доступу може бути визначена як така, що містить всі компоненти виду загального моменту часу. Мультиплексор 30 може також вбудовувати дані відносно програми в одиниці NAL. Наприклад, мультиплексор 30 може створити одиницю NAL, що містить Таблицю Карти Програми (PMT) або Карту Потоку Програми (PSM). У загальному випадку, PMT використовується для опису транспортного потоку, в той час як PSM використовується для опису потоку програми. Як описано детальніше відносно прикладу ФІГ. 2 нижче, мультиплексор 30 може містити або взаємодіяти з модулем зберігання даних, який асоціює елементарні потоки, отримані від аудіокодера 26 і відеокодера 28, з програмами і відповідно з відповідними транспортними потоками і/або потоками програми. Стандарт Систем MPEG-2 враховує розширення системи за допомогою "дескрипторів". PMT і PSM включають цикли дескрипторів, в які можуть бути вставлені один або більше дескрипторів. У загальному випадку, дескриптор містить структуру, яка може використовуватися, щоб розширити визначення програм і/або елементів програм. Дане розкриття описує два дескриптори для виконання методів даного розкриття: дескриптор розширення MVC і дескриптор ієрархії. У загальному випадку, дескриптор розширення MVC даного розкриття посилює звичайний дескриптор розширення MVC шляхом конкретної ідентифікації порядкових індексів виду для видів, які включені в потік програми або транспортний потік, в той час як дескриптор ієрархії даного розкриття містить прапор, який вказує, чи збільшує асоційований елемент програми число видів потоку бітів, що є результатом елемента програми, на який відсилається елемент дескриптора ієрархії. Стандарти стиснення відео, такі як ITU-T H.261, H.263, MPEG-I, MPEG-2 і H.264/MPEG-4, частина 10, використовують скомпенсований по руху тимчасовий прогноз, щоб зменшити тимчасову надмірність. Кодер використовує скомпенсований по руху прогноз з деяких раніше кодованих картин (що також згадуються тут як кадри), щоб передбачити поточні кодовані картини згідно з векторами руху. У типовому відеокодуванні є три головні типи картин. До них належать: інтра-(«всередині»)кодована картина ("I-картини" або "I-кадри"), передбачені картини ("Р-картини" або "Р-кадри") і двоспрямовані передбачені картини ("В-картини" або "В-кадри"). Ркартини використовують тільки опорну картину перед поточною картиною у тимчасовому порядку. У В-картині кожний блок В-картини може бути передбачений з однієї або двох опорних картин. Ці опорні картини можуть бути розташовані перед або після поточної картини у тимчасовому порядку. Відповідно до стандарту кодування H.264, як приклад, В-картини використовують два списки раніше кодованих опорних картин, список 0 і список 1. Ці два списки можуть кожний містити минулі і/або майбутні кодовані картини у тимчасовому порядку. Блоки в В-картині можуть бути передбачені одним з декількох способів: скомпенсований по руху прогноз з опорної картини списку 0, скомпенсований по руху прогноз з опорної картини списку 1 або скомпенсований по руху прогноз з комбінації опорних картин зі списку 0 і списку 1. Щоб отримати комбінацію опорних картин зі списку 0 і списку 1, дві скомпенсовані по руху опорні зони отримують з опорних картин списку 0 і списку 1 відповідно. Їх комбінація буде використовуватися, щоб передбачити поточний блок. 8 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 Стандарт ITU-T H.264 підтримує інтра-прогноз в різних розмірах блока, таких як 16 на 16, 8 на 8 або 4 на 4 для компонентів яскравості, і 8x8 для компонентів кольоровості, а також інтерпрогноз в різних розмірах блока, таких як 1616, 168, 816, 88, 84, 48 і 44 для компонентів яскравості і відповідних масштабованих розмірах для компонентів кольоровості. У цьому розкритті, "x" і “на" може використовуватися взаємозамінним чином при посиланнях на вимірювання в пікселях блока, для вертикальних і горизонтальних вимірювань, наприклад, 16x16 пікселів або 16 на 16 пікселів. У загальному випадку, блок 16x16 буде мати 16 пікселів у вертикальному напрямку (у=16) і 16 пікселів в горизонтальному напрямку (х=16). Аналогічно, блок NxN взагальному випадку має N пікселів у вертикальному напрямку і N пікселів в горизонтальному напрямку, де N представляє ненегативне цілочисельне значення. Пікселі в блоці можуть бути впорядковані в рядки і стовпці. Розміри блока, які є меншими, ніж 16 на 16, можуть згадуватися як частини “16 на 16" макроблока. Відеоблоки можуть містити блоки піксельних даних в піксельній зоні або блоки коефіцієнтів перетворення в зоні перетворення, наприклад, слідуючи застосуванню перетворення, такого як дискретне косинусне перетворення (DCT), цілочисельне перетворення, вейвлетне перетворення або концептуально подібне перетворення, до залишкових даних відеоблока, що представляє відмінності в пікселях між кодованими відеоблоками і прогнозованими (предиктивними) відеоблоками. У деяких випадках, відеоблок може містити блоки квантованих коефіцієнтів перетворення в зоні перетворення. Менші відеоблоки можуть забезпечити кращий дозвіл і можуть використовуватися для визначення місцеположень відеокадру, які включають високі рівні детальності. У загальному випадку, макроблоки і різні частини, що іноді називаються підблоками, можуть розглядатися як відеоблоки. Крім того, вирізка (slice) може розглядатися як множина відеоблоків, таких як макроблоки і/або підблоки. Кожна вирізка може бути незалежно декодованою одиницею відеокадрів. Альтернативно, самі кадри можуть бути декодованими одиницями, або інші частини кадру можуть бути визначені як декодовані одиниці. Термін "кодована одиниця" або "одиниця кодування" може належати до будь-якої незалежно декодованої одиниці відеокадру, такої як весь кадр, вирізка кадру, група картин (GOP), що також називається послідовністю, або інша незалежно декодована одиниця, визначена згідно зі застосовними методами кодування. Термін «макроблок» належить до структури даних для кодування картини і/або відеоданих згідно з двовимірним масивом пікселів, який містить 1616 пікселів. Кожний піксель містить компонент кольоровості і компонент яскравості. Відповідно, макроблок може визначити чотири блоки яскравості, кожний з яких включає двовимірний масив 8x8 пікселів, два блоки кольоровості, кожний з яких включає двовимірний масив 16x16 пікселів, і заголовок, що включає інформацію синтаксису, таку як шаблон кодованого блока (CBP), режим кодування (наприклад, режими кодування “інтра" - (I) або “інтер" (Р або В), розмір частини для частин інтра-кодованого блока (наприклад, 1616, 168, 816, 88, 84, 48 або 44) або один або більше векторів руху для інтер-кодованого макроблока. Відеокодер 28, відеодекодер 48, аудіокодер 26, аудіодекодер 46, мультиплексор 30 і демультиплексор 38 кожний може бути здійснений як будь-яка з множини відповідних схем кодера або декодера, як застосовно, таких як один або більше мікропроцесорів, процесорів цифрового сигналу (DSP), спеціалізованих інтегральних схем (ASIC), програмованих вентильних матриць (FPGA), дискретних логічних схем, програмне забезпечення, апаратні засоби, програмоване обладнання або будь-які комбінації вказаного. Кожний з відеокодера 28 і відеодекодера 48 може бути включений в один або більше кодерів або декодерів, будь-який з яких може бути інтегрований як частина об'єднаного відеокодера/декодера (кодека). Аналогічно, кожний з аудіокодера 26 і аудіодекодера 46 може бути включений в один або більше кодерів або декодерів, будь-який з яких може бути інтегрований як частина об'єднаного аудіокодера/декодера (кодека). Пристрій, що містить відеокодер 28, відеодекодер 48, аудіокодер 26, аудіодекодер 46, мультиплексор 30 і/або демультиплексор 38, може містити інтегральну схему, мікропроцесор і/або пристрій бездротового зв’язку, такий як мобільний телефон. Способи даного розкриття можуть забезпечити певні переваги перед звичайними методами для MVC підпотоків бітів, які не підтримують характеристики сигналізації для деяких операційних точок. На відміну від звичайних методів, елементи синтаксису і семантика додаткового дескриптора MVC даного розкриття допускають значення порядкових індексів непослідовних видів, таким чином, дозволяючи підтримувати потік бітів або підпотік бітів, відповідний MVC і зі значеннями порядкових індексів видів, які є непослідовними. Дане розкриття також пропонує дескриптор ієрархії для сигналізації удосконалення виду, що 9 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 дозволяє декодеру визначити, що MVC підпотік бітів основується на інших видах, для успішного декодування. Щоб забезпечити кращу підтримку сигналізації характеристик, значення порядкового індексу виду, як сигналізується взапропонованому дескрипторі розширення MVC, можуть опційно бути непослідовними. Крім того, значення порядкового індексу виду або значення view_id можуть бути сигналізовані в дескрипторі розширення MVC. Як альтернатива, може використовуватися механізм перевідображення порядкового індексу виду, який відображає значення порядкового індексу виду для видів відповідного MVC підпотоку бітів в послідовні значення порядкового індексу виду, шляхом модифікації порядку видів, визначеного в активному MVC розширенні звичайного набору параметрів послідовності, перед мультиплексуванням цього MVC підпотоку бітів. У такому механізмі дескриптор розширення звичайного MVC використовується, щоб сигналізувати ідентифікатори видів замість порядкових індексів видів, і, таким чином, кодер може бути переконфігурований, щоб кодувати види як такі, що мають різні ідентифікатори видів, в той час як декодер може бути переконфігурований, щоб інтерпретувати дескриптор розширення звичайного MVC по-іншому, згідно з переконфігурованим порядком кодування. Наприклад, передбачимо, що є три види з view_id 0, 1 і 2, що мають порядкові індекси 0, 1 і 2 видів відповідно. Передбачимо далі, що послуга вимагала тільки вид 0 і вид 2. Кодер може кодувати види в порядку, відповідному ідентифікаторам видів 0, 2, 1, так що дескриптор розширення звичайного MVC може використовуватися, щоб сигналізувати значення view_id з порядком 0, 2, 1. Таким чином, вид 2 може мати порядковий індекс виду 1, так що комбінація виду 0 і виду 2 має послідовні порядкові індекси видів. Додатково, щоб уникнути дублювань префіксної одиниці NAL, коли присутній AVC підпотік бітів відео MVC, дане розкриття пропонує, що повинен бути визначений префіксний підпотік бітів MVC і що в деяких прикладах такий префіксний підпотік бітів MVC включається, коли є щонайменше один підпотік бітів MVC. Крім того, дане розкриття пропонує, що специфічні для MVC повідомлення SEI, тобто повідомлення SEI, які визначені в Додатку Н специфікації AVC, що належать до базового виду, або MVC SEI повідомлення, застосовні для всіх видів потоку бітів MVC, можуть бути асоційовані в рамках цього "префіксного підпотоку бітів MVC", щоб забезпечити ефективне зберігання і транспорт з точки зору розміру зберігання або оптимізації ширини смуги. Дане розкриття також пропонує, що та ж сама ідея може бути застосована до транспорту відео, що масштабується в MPEG-2 системах, також що згадується в контексті Поправки 3 до стандарту "Інформаційна технологія - родове кодування рухомих зображень і асоційованої аудіоінформації: Системи" (в даному розкритті згадується як "MPEG-2 Системи" або "стандарт MPEG-2 Систем"). Після того як мультиплексор 30 виконав збір одиниці NAL і/або одиниці доступу з отриманих даних, мультиплексор 30 передає цю одиницю на вихідний інтерфейс 32 для виведення. Вихідний інтерфейс 32 може містити, наприклад, передавач, приймач-передавач, пристрій для запису даних на комп’ютерозчитуваний носій, такий як, наприклад, накопичувач на оптичних дисках, накопичувач на магнітних носіях (наприклад, накопичувач на гнучких дисках), порт універсальної послідовної шини (USB), мережевий інтерфейс, або інший вихідний інтерфейс. Вихідний інтерфейс 32 виводить одиницю NAL або одиницю доступу на комп’ютерозчитуваний носій 34, такий як, наприклад, сигнал передачі, магнітний носій, оптичний носій, пам'ять, флеш-пам'ять або інший комп’ютерозчитуваний носій. Зрештою, вхідний інтерфейс 36 витягує дані з комп’ютерозчитуваних носіїв 34. Вхідний інтерфейс 36 може містити, наприклад, накопичувач на оптичних дисках, накопичувач на магнітних носіях, USB порт, приймач, приймач-передавач або інший інтерфейс комп'ютерозчитуваного носія. Вхідний інтерфейс 36 може надати одиницю NAL або одиницю доступу на демультиплексор 38. Демультиплексор 38 може демультиплексувати транспортний потік або потік програми на компонентні потоки PES, розпаковувати потоки PES, щоб відновити кодовані дані, і відіслати кодовані дані в аудіодекодер 46 або у відеодекодер 48, залежно від того, чи є кодовані дані частиною аудіо або відеопотоку, наприклад, як вказано заголовками пакетів PES потоку. Аудіодекодер 46 декодує кодовані аудіодані і відсилає декодовані аудіодані на аудіовихід 42, в той час як відеодекодер 48 декодує кодовані відеодані і відсилає декодовані відеодані, які можуть містити множину видів потоку, на відеовихід 44. Відеовихід 44 може містити пристрій відображення, який використовує множину видів сцени, наприклад, стереоскопічний або автостереоскопічний дисплей, який представляє кожний вид сцени одночасно. Крім того, демультиплексор 38 може переупорядковувати види з одного або більше підпотоків бітів, так що порядкові індекси видів потоку мають порядок, що суворо збільшується, 10 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 наприклад, коли щонайменше один вид вкладеного підпотоку бітів має вид з порядковим індексом виду, який менший, ніж порядковий індекс виду для виду основного підпотоку бітів, в який включений вкладений підпотік бітів. Таким способом пристрій 40 призначення А/V може відповідати пристрою, що містить демультиплексор, який формує потік бітів, сумісний зі стандартом MVC, з отриманого потоку бітів. На Фіг. 2 показана блок-схема, що ілюструє зразкову конфігурацію компонентів мультиплексора 30 (Фіг. 1). У прикладі Фіг. 2 мультиплексор 30 містить блок 60 керування потоком, вхідний інтерфейс 80 відео, вхідний інтерфейс 82 аудіо, вихідний інтерфейс 84 мультиплексованого потоку і таблицю 88 специфічної для програми інформації. Блок 60 керування потоком містить формувач 62 одиниці NAL, формувач PMT 64, блок 66 пошуку ідентифікатора потоку (ID потоку) і блок 68 призначення ідентифікатора програми (PID). У прикладі Фіг. 2, вхідний інтерфейс 80 відео і вхідний інтерфейс 82 аудіо включають відповідні формувачі пакетів для формування одиниць PES з кодованих відеоданих і кодованих аудіоданих. У інших прикладах відео і/або аудіоформувачі пакетів можуть бути зовнішніми для мультиплексора 30. Відносно прикладу Фіг. 2, вхідний інтерфейс 80 відео може формувати пакети PES з кодованих відеоданих, отриманих від відеокодера 28, і вхідний інтерфейс 82 аудіо може формувати пакети PES з кодованих аудіоданих, отриманих від аудіокодера 26. Блок 60 керування потоком отримує пакети PES від вхідного інтерфейсу 80 відео і вхідного інтерфейсу 82 аудіо. Кожний пакет PES містить ідентифікатор потоку, що ідентифікує елементарний потік, якому належить пакет PES. Блок 66 пошуку ідентифікатора потоку може визначити програму, якою відповідає пакет PES, шляхом запиту таблиць 88 специфічної для програми інформації. Таким чином, блок 60 керування потоком може визначити, якій програмі відповідає отриманий пакет PES. Кожна програма може містити множину елементарних потоків, в той час як в загальному випадку, один елементарний потік відповідає тільки одній програмі. Однак, в деяких прикладах, елементарний потік може бути включений у множину програм. Кожний пакет PES може бути включений у множину потоків, що виводяться з мультиплексора 30, оскільки різні послуги можуть містити, кожна, різні піднабори доступних аудіо і відеопотоків. Відповідно, блок 66 пошуку ідентифікатора потоку може визначити, чи повинен пакет PES бути включений в один або більше вихідних потоків (наприклад, один або більше транспортних потоків або потоків програми), і, зокрема, в який з вихідних потоків включати пакет PES. У одному прикладі кожний елементарний потік відповідає програмі. Мультиплексор 30 може бути відповідальним за забезпечення, що кожний елементарний потік асоційований з конкретною програмою і, відповідно, ідентифікатором програми (PID). Коли прийнятий пакет PES, що включає ідентифікатор пакету, який не розпізнаний мультиплексором 30 (наприклад, ідентифікатор потоку не збережений в таблиці 88 специфічної для програми інформації), блок 68 призначення ідентифікатора програми створює один або більше нових записів в таблиці 88 специфічної для програми інформації, щоб асоціювати новий ідентифікатор потоку з невикористаним PID. Після визначення програми, якою відповідає пакет PES, формувач 62 одиниці NAL формує одиницю NAL, що містить пакет PES, наприклад, інкапсулюючи пакет PES із заголовком одиниці NAL, включаючи PID програми, якою відповідає ідентифікатор потоку пакету PES. У деяких прикладах формувач 62 одиниці NAL або інший блок 60 керування потоком може сформувати одиницю доступу, що містить множину одиниць NAL. Формувач PMT 64 створює Таблиці Карти Програми (PMT) для відповідного вихідного потоку мультиплексора 30 з використанням інформації з таблиць 88 специфічної для програми інформації. У іншому прикладі блок 60 керування потоком може містити формувач PSM для створення карт потоку програми для виведення програми мультиплексором 30. У деяких прикладах мультиплексор 30 може містити формувач PMT 64 і формувач і виводити один або обидва з транспортного потоку і потоку програми. У прикладі Фіг. 2 формувач PMT 64 може створити PMT, включаючи дескриптори, призначені даним розкриттям, наприклад, дескриптор розширення MVC і дескриптор ієрархії, а також будь-які інші необхідні дескриптори і дані PMT для PMT. Формувач PMT 64 може періодично, наприклад, після певного періоду часу або після того, як певна кількість даних була передана, відіслати наступну PMT для транспортного потоку. Формувач PMT 64 може передати створені PMT формувачу 62 одиниці NAL для формування одиниці NAL, що містить PMT, наприклад, шляхом інкапсулювання PMT з відповідним заголовком одиниці NAL, включаючи відповідний PID. Вихідний інтерфейс 84 мультиплексованого потоку може отримати одну або більше одиниць NAL і/або одиниць доступу від блока 60 керування потоком, наприклад, одиниці NAL, що включають пакети PES (наприклад, аудіо- або відеодані), і/або одиниці NAL, що включають 11 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 PMT. У деяких прикладах вихідний інтерфейс 84 мультиплексованого потоку може сформувати одиниці доступу з однієї або більше одиниць NAL, що відповідають загальному тимчасовому місцеположенню, після того як одиниці NAL прийняті від блока 60 керування потоком. Вихідний інтерфейс 84 мультиплексованого потоку передає одиниці NAL або одиниці доступу як вихід у відповідному транспортному потоці або потоці програми. На Фіг. 3 показана блок-схема, що ілюструє зразковий набір таблиць 88 специфічної для програми інформації. Елементарний потік, якому належить транспортний пакет, може бути визначений на основі значення PID транспортного пакету. Для того щоб декодер належно декодував отримані дані, декодер повинен бути здатним визначити, які елементарні потоки належать кожній програмі. Специфічна для програми інформація, як включено в таблицю 88 специфічної для програми інформації, може явно визначати відношення між програмами і компонентними елементарними потоками. У прикладі Фіг. 3 таблиці 88 специфічної для програми інформації включають таблицю 100 мережевої інформації, таблицю 102 умовного доступу, таблицю 104 доступу до програми і таблицю 106 карти програми. Для прикладу Фіг. 3 передбачається, що вихідний потік містить транспортний потік MPEG-2. У альтернативному прикладі вихідний потік може містити потік програми, і в цьому випадку таблиця 106 карти програми може бути замінена картою потоку програми. Специфікація Систем MPEG-2 визначає, що кожна програма, що переноситься в транспортному потоці, має таблицю карти програми, таку як таблиця 106 карти програми, асоційована з нею. Таблиця 106 карти програми може містити деталі про програму і елементарні потоки, які містить програма. Як приклад, програма, ідентифікована як програма номер 3, може містити елементарний потік відео з PID 33, потік PID 57 і потік аудіо з PID 60. Для PMT дозволяється містити більше однієї програми. Базова таблиця карти програми, визначена специфікацією систем MPEG-2, може бути забезпечена деякими з множини дескрипторів, наприклад, дескрипторами 108, визначеними в специфікації систем MPEG-2. Дескриптори 108 можуть містити будь-які або всі з певних дескрипторів специфікації систем MPEG-2. У загальному випадку, дескриптори, такі як дескриптори 108, передають додаткову інформацію про програму або її компонентні елементарні потоки. Дескриптори можуть містити параметри кодування відео, параметри кодування аудіо, мовну ідентифікацію, інформацію панорамування і сканування, деталі умовного доступу, інформацію про авторське право або іншу таку інформацію. Мовленнева станція або інший користувач можуть визначити додаткові приватні дескриптори. Дане розкриття використовує два дескриптори, щоб дозволити перенести непослідовні порядкові індекси видів у вихідному потоці, такому як транспортний потік або потік програми. Як показано на Фіг. 2, два дескриптори цього розкриття включають дескриптор 110 розширення MVC і дескриптор 112 ієрархії. У пов'язаних з відео компонентних елементарних потоках також є дескриптор ієрархії, який надає інформацію, щоб ідентифікувати елементи програми, що містять компоненти ієрархічно кодованого відео, аудіо і приватних потоків. У прикладі, в якому вихід мультиплексора 30 містить потік програми, таблиці 88 специфічної для програми інформації можуть містити карту потоку програми (PSM). PSM може забезпечити опис елементарних потоків у відповідному потоці програми і співвідношення елементарних потоків один до одного. У деяких прикладах карта потоку програми може також відповідати транспортному потоку. При перенесенні у відповідному транспортному потоці, структура PSM не повинна змінюватися. Мультиплексор 30 може вказати, що PSM присутній в пакеті PES, встановлюючи значення view_id пакету PES на 0BC, тобто, шістнадцяткове значення ВР, яке відповідає двійковому значенню 10111100 або десятковому значенню 188. Мультиплексор 30 підтримує повний список всіх програм, доступних в транспортному потоці, в таблиці 104 асоціації програм. Мультиплексор 30 також може включати таблиці асоціації програми в одиниці NAL. Мультиплексор 30 може вказати, що одиниця NAL містить таблицю асоціації програм, шляхом призначення одиниці NAL значення PID, що дорівнює 0. Мультиплексор 30 може перерахувати кожну програму, разом зі значенням PID транспортних пакетів, які містить відповідна таблиця карти програми, в таблиці 104 асоціації програм. Для згаданого вище прикладу, зразкова таблиця карти програми, яка визначає елементарні потоки програми номер 3, має PID 1001, а інша PMT має інший PID 1002. Цей набір інформації може бути включений в таблицю 104 асоціації програм. Таблиця мережевої інформації (NIT) і таблиця умовного доступу (CAT): Програма номер нуль, визначена в РАТ, має спеціальне значення. Зокрема, програма номер нуль використовується для вказування шляху до таблиці мережевої інформації. Таблиця є опціональною і, якщо є присутньою, призначена, щоб надавати інформацію про фізичну мережу, несучу транспортний потік, таку як частоти каналів, детальні особливості супутникового 12 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 приймача-відповідача, характеристики модуляції, джерело послуг, ім'я послуг і деталі альтернативних доступних мереж. Якщо які-небудь елементарні потоки в транспортному потоці скремблюються, то повинна бути присутньою таблиця умовного доступу. Таблиця забезпечує деталі використовуваної системи скремблювання і забезпечує значення PID транспортних пакетів, які містять інформацію керування і надання права відносно умовного доступу. Формат цієї інформації не визначений в рамках MPEG-2. На Фіг. 4 показана блок-схема, що ілюструє зразковий набір даних, які можуть бути включені в дескриптор розширення MVC 110. У прикладі Фіг. 4 дескриптор 110 розширення MVC містить поле 120 тегу дескриптора, поле 122 довжини дескриптора, поле 124 середньої бітової швидкості, поле 126 максимальної бітової швидкості, зарезервоване поле 128, поле 130 початку тимчасового ідентифікатора, поле 132 кінця тимчасового ідентифікатора, поле 134 відсутності одиниць NAL додаткової інформації розширення (SEI), одне або більше полів 136 порядкового індексу виду і одне або більше полів 138 зарезервованих замикаючих бітів. Дескриптор 110 розширення MVC також визначає операційну точку, яка відповідає підпотоку бітів MVC. Бітові глибини полів дескриптора 110 розширення MVC нижче відповідають одному прикладу для дескриптора розширення MVC. Інші приклади можуть містити інші бітові глибини, значення або діапазони, щоб індивідуально сигналізувати кожний порядковий індекс виду кожного виду, включеного у відповідний потік бітів або підпотік бітів. Поле 120 тегу дескриптора відповідає восьмибітовому полю тегу дескриптора, яке включене в кожний дескриптор, як встановлено стандартом MPEG-2 Систем, щоб конкретно ідентифікувати дескриптор. Стандарт MPEG-2 Систем визначає певні теги дескрипторів і маркірує інші значення тегів дескрипторів, наприклад, значення 36-63, як "зарезервовані". Способи даного розкриття пропонують встановлювати значення поля 120 тегу дескриптора для дескриптора 110 розширення MVC на "49", що відповідає одному із зарезервованих тегів дескриптора, як визначено в специфікації MPEG-2 Систем. Поле 122 довжини дескриптора відповідає восьмибітовому полю довжини дескриптора, яке також включене в кожний дескриптор, як вказано стандартом MPEG-2 Систем. Мультиплексор 30 може встановити значення поля 122 довжини дескриптора таким, що дорівнює числу байтів дескриптора 110 розширення MVC безпосередньо після поля 122 довжини дескриптора. Оскільки дескриптор 110 розширення MVC може містити змінну довжину, наприклад, на основі числа порядкових індексів виду 136, включеного в конкретний примірник дескриптора 110 розширення MVC, мультиплексор 30 обчислює розмір примірника дескриптора 110 розширення MVC і встановлює значення поля 122 довжини дескриптора примірника дескриптора відповідно. Поле 124 середньої бітової швидкості містить шістнадцятибітове поле, що вказує середню бітову швидкість, в кілобітах за секунду, повторно зібраного відеопотоку AVC. Таким чином, поле 124 середньої бітової швидкості описує середню бітову швидкість для відеопотоку, коли відеопотік зібраний від складових частин транспортного потоку або потоку програми, якому відповідає дескриптор 110 розширення MVC. У деяких прикладах мультиплексор 30 може встановити значення поля 124 середньої бітової швидкості в нуль для вказування, що середня бітова швидкість не вказана дескриптором 110 розширення MVC. Поле 126 максимальної бітової швидкості містить шістнадцятибітове поле, що вказує максимальну бітову швидкість, в кілобітах за секунду, повторно зібраного відеопотоку AVC. Таким чином, поле 126 максимальної бітової швидкості описує максимальну бітову швидкість для відеопотоку, коли відеопотік зібраний зі складових частин транспортного потоку або потоку програми, якому відповідає дескриптор 110 розширення MVC. У деяких прикладах мультиплексор 30 може встановити значення поля 126 максимальної бітової швидкості в нуль для вказування, що максимальна бітова швидкість не вказана дескриптором 110 розширення MVC. Поле 130 початку тимчасового ідентифікатора містить трибітове поле, яке вказує мінімальне значення temporal_id елемента синтаксису заголовка одиниці NAL всіх одиниць NAL, що містяться в асоційованому підпотоці бітів відео MVC. Таким чином, значення тимчасового ідентифікатора включено в заголовок для кожної одиниці NAL. У загальному випадку, значення тимчасового ідентифікатора відповідає конкретній швидкості кадрів, де відносно великі значення тимчасового ідентифікатора відповідають вищим швидкостям кадрів. Наприклад, значення '0' для тимчасового ідентифікатора може відповідати швидкості кадрів 15 кадрів за секунду (к/с), значення '1' для тимчасового ідентифікатора може відповідати швидкості кадрів 30 к/с. Таким способом, збір всіх картин, що мають тимчасовий ідентифікатор 0, в цьому прикладі, в набір, може використовуватися, щоб сформувати відеосегмент, що має швидкість кадрів 15 к/с, а збір всіх картин, що мають тимчасовий ідентифікатор 0, і всіх картин, що мають 13 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 тимчасовий ідентифікатор 1, в інший набір, може використовуватися, щоб сформувати інший відеосегмент, що має швидкість кадрів 30 к/с. Мультиплексор 30 визначає найменший тимчасовий ідентифікатор всіх одиниць NAL підпотоку бітів відео MVC і встановлює значення поля 130 початку тимчасового ідентифікатора таким, що дорівнює цьому певному найменшому значенню тимчасового ідентифікатора. Поле 132 кінця тимчасового ідентифікатора містить трьохбітове поле, що вказує максимальне значення тимчасового ідентифікатора елемента синтаксису заголовка одиниці NAL всіх одиниць NAL, що містяться в асоційованому підпотоці бітів відео MVC. Відповідно мультиплексор 30 визначає найбільший тимчасовий ідентифікатор всіх одиниць NAL підпотоку бітів відео MVC і встановлює значення поля 130 початку тимчасового ідентифікатора таким, що дорівнює цьому певному найбільшому значенню тимчасового ідентифікатора. Поле 134 відсутності одиниць NAL додаткової інформації розширення (SEI) містить однобітовий прапор, який, коли встановлений у '1', вказує, що ніякі одиниці NAL додаткової інформації розширення не присутні в асоційованому підпотоці бітів відео. Мультиплексор 30 може визначити, чи вміщені одна або більше одиниць NAL додаткової інформації розширення в потік бітів, і встановити значення поля 134 відсутності одиниць NAL додаткової інформації розширення (SEI) в значення '1', коли немає ніяких SEI NAL одиниць в потоці бітів, але може встановити значення поля 134 відсутності одиниць NAL додаткової інформації розширення (SEI) в значення '0', коли щонайменше одна SEI NAL одиниця присутня в потоці бітів. У одному аспекті, способи даного розкриття описують модифікацію звичайних дескрипторів розширення MVC, щоб включати одне або більше полів 136 порядкового індексу виду, представлених з використанням циклу, як показано в Таблиці 1 нижче. Кожне з полів 136 порядкового індексу виду містить 10-бітове поле, яке вказує значення порядкового індексу виду відповідною однією з одиниць NAL, що містяться в асоційованому підпотоці бітів відео MVC. Мультиплексор 30 може встановити значення полів 136 порядкового індексу виду згідно з порядковими індексами виду для видів, включених в підпотік бітів відео MVC. Крім того, значення полів 136 порядкового індексу виду можуть сигналізуватися в порядку зростання. Цим способом дескриптор 110 розширення MVC може описати непослідовні порядкові індекси виду для видів, включених в підпотік бітів відео MVC. У прикладі Фіг. 4, дескриптор 110 розширення MVC також містить поля 138 зарезервованих замикаючих бітів. Дане розкриття описує резервування цих бітів для майбутньої мети, не визначаючи, як ці значення повинні обов'язково використовуватися. У різних прикладах зарезервовані замикаючі біти можуть бути представлені як єдиний, безперервний зарезервований збережений сегмент бітів дескриптора розширення MVC 110, або як цикл по множині окремих бітів. Таблиця 1 нижче описує елементи синтаксису дескриптора розширення MVC 110 з даного розкриття. Таблиця 1 також описує, для кожного елемента синтаксису, кількість бітів, що використовуються для представлення елемента синтаксису, і мнемоніку, що описує тип для елемента синтаксису. Число бітів відповідає числу бітів, які виділені відповідному елементу синтаксису, коли дескриптор 110 розширення MVC передається в кодованому потоці бітів. Мнемоніка використовується в стандарті MPEG-2 Систем, щоб описувати різні типи даних, які використовуються в кодованому потоці бітів. Мнемоніка, що використовується в цьому розкритті, містить "uimsbf", який стандарт MPEG-2 Систем визначає як ціле число без знаку, що має старший біт спочатку, і "bslbf", який стандарт MPEG-2 Систем визначає як бітовий рядок з лівим бітом спочатку, де "лівий" є порядком, в якому бітові рядки записуються в стандарті MPEG-2 Систем. Кожний з елементів синтаксису в прикладі таблиці 1 відповідає відповідному одному з елементів синтаксису, описаних вище відносно дескриптора 110 розширення MVC. Зокрема, дане розкриття передбачає цикл "for" (для) в таблиці 1, щоб конкретно сигналізувати порядкові індекси виду для кожного виду потоку програми або транспортного потоку. Цим способом цикл "for" в дескрипторі розширення MVC Таблиці 1 може використовуватися, щоб сигналізувати, що потік бітів, відповідний стандарту MPEG-2 Систем, містить перший вид сцени, асоційований з першим порядковим індексом виду, і другий вид сцени, асоційований з другим порядковим індексом виду, причому перший порядковий індекс виду і другий порядковий індекс виду непослідовні. 55 14 UA 100645 C2 5 У іншому прикладі зарезервовані замикаючі біти можуть замість цього індивідуально сигналізуватися. Таблиця 2 нижче ілюструє приклад дескриптора розширення MVC, який сигналізує кожний із зарезервованих замикаючих бітів індивідуально. 15 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 На Фіг. 5 показана блок-схема, що ілюструє зразковий набір даних, які можуть бути включені в дескриптор 112 ієрархії. У прикладі Фіг. 5 дескриптор 112 ієрархії містить поле 150 тегу дескриптора, поле 152 довжини дескриптора, поле 154 прапора посилення виду, поле 156 прапора тимчасової масштабованості, поле 158 прапора просторової масштабованості, поле 160 прапора масштабування якості, поле 162 типу ієрархії, зарезервоване поле 164, поле 166 індексу шару ієрархії, поле 168 прапора присутності TREF, зарезервоване поле 170, поле 172 індексу вкладеного шару ієрархії, зарезервоване поле 174 і поле 176 каналу ієрархії. Щоб поліпшити сигналізацію, масштабованість виду і/або відношення залежності видів, способи даного розкриття можуть забезпечити, що один прапор сигналізується в дескрипторі ієрархії, який вказує, чи збільшує асоційований елемент програми число видів потоку бітів, що виходить з елемента програми, на який відсилається індекс шару вкладеної ієрархії. Як відмічено вище, специфікація MPEG-2 Систем визначає, що кожний дескриптор містить поле тегу дескриптора і поле довжини дескриптора. Відповідно, дескриптор 112 ієрархії 112 містить поле 150 тегу дескриптора і поле 152 довжини дескриптора. Відповідно до специфікації MPEG-2 Систем, мультиплексор 30 може встановити значення поля 150 тегу дескриптора в значення "4" для дескриптора 112 ієрархії 112. Довжина дескриптора 112 ієрархії може бути визначена апріорно, тому що кожний примірник дескриптора 112 ієрархії повинен містити той же самий об'єм даних. У одному прикладі, відносно Таблиці 3, наведеної нижче, мультиплексор 30 може встановити значення поля 152 довжини дескриптора в значення 32, що вказує число бітів в примірнику дескриптора 112 ієрархії, після кінця поля 152 довжини дескриптора. Способи даного розкриття пропонують додати поле 154 прапора посилення виду до звичайного дескриптора ієрархії. Відповідно до методів цього розкриття, поле 154 прапора посилення виду може містити однобітовий прапор, який, коли встановлений у '0', вказує, що асоційований елемент програми збільшує число видів бітового потоку, що виходять з елемента програми, на який відсилається індекс шару вкладеної ієрархії. Способи даного розкриття також пропонують резервування значення '1' для поля 154 прапора посилення виду. Поле 162 типу ієрархії описує ієрархічні відношення між асоційованим шаром ієрархії і його вкладеним шаром ієрархії. У одному прикладі, мультиплексор 30 встановлює значення поля 162 типу ієрархії на основі ієрархічного відношення, наприклад, як описано Таблицею 4, наведеною нижче. Як приклад, коли масштабованість застосовується більше ніж в одному вимірюванні, мультиплексор 30 може встановити поле 162 типу ієрархії в значення "8" ("Об'єднана Масштабованість" як показано в таблиці 4), і мультиплексор 30 встановлює значення поля 156 прапора тимчасової масштабованості, поля 158 прапора просторової масштабованості і поля 160 прапора масштабованості якості згідно з даними, витягнутими з пакетів PES і заголовків пакетів PES відповідних потоків. У загальному випадку, мультиплексор 30 може визначити залежність між різними потоками, відповідними різним видам і/або потокам аудіоданих. Мультиплексор 30 може також визначити, чи є залежний потік, який містить шар розширення, просторовим шаром, шаром поліпшення відношення сигнал/шум (SNR), шаром підвищення якості або іншим типом шару розширення. Як інший приклад, для підпотоку бітів відео MVC, мультиплексор 30 може встановити поле 162 типу ієрархії в значення '9' ("MVC" як показано в Таблиці 4) і може встановити значення кожного з поля 156 прапора масштабованості, поля 158 прапора просторової масштабованості і поля 160 прапора масштабованості якості в '1'. У іншому прикладі, для підпотоку бітів базового виду MVC, мультиплексор 30 може встановити значення поля 162 типу ієрархії в значення '15' і може встановити значення поля 156 прапора масштабованості, поля 158 прапора просторової масштабованості і поля 160 прапора масштабованості якості в '1'. У іншому прикладі, для префіксного підпотоку бітів MVC, мультиплексор 30 може встановити поле 162 типу ієрархії в значення '14' і може встановити поле 156 прапора масштабованості, поле 158 прапора просторової масштабованості і поле 160 прапора масштабованості якості в '1'. Поле 166 індексу шару ієрархії може містити шестибітове поле, яке визначає унікальний індекс асоційованого елемента програми в таблиці ієрархій шарів кодування. Індекси можуть бути унікальними в межах єдиного визначення програми. Для підпотоку бітів відео AVC, потоків відео, відповідних одному або більше профілям, визначеним в Додатку G ITU-T Rec. H.264 ¦ ISO/IEC 14496-10, це індекс елемента програми, який призначений таким чином, що порядок потоку бітів буде коректним, якщо асоційовані представлення залежності SVC підпотоків бітів відео тієї ж самої точки доступу повторно компонуються в порядку, що збільшується, індексу шару ієрархії. Для підпотоків бітів відео MVC потоків відео AVC, відповідних одному або більше профілям, визначеним в Додатку Н ITU-T Rec. H.264 ¦ ISO/IEC 14496-10, це індекс елемента 16 UA 100645 C2 5 10 15 20 25 30 35 програми, який призначений таким чином, що будь-яке з цих значень більше, ніж значення індексу шару ієрархії (hierarchy_layer_index), визначене в дескрипторі ієрархії для префіксного підпотоку бітів MVC. Поле 172 індексу вкладеного шару ієрархії може містити шестибітове поле, яке визначає індекс таблиці ієрархії елемента програми, до якого треба отримати доступ, перш ніж декодувати елементарний потік, асоційований з відповідним примірником дескриптора 112 ієрархії. Дане розкриття залишає значення для поля 172 індексу вкладеного шару ієрархії невизначеним для випадку, коли поле 162 типу ієрархії 162 має значення 15 (тобто, значення, відповідне базовому шару). Поле 176 каналу ієрархії може містити шестибітове поле, яке вказує номер передбаченого каналу для асоційованого елемента програми у впорядкованому наборі каналів передачі. Найбільш надійний канал передачі визначений найнижчим значенням поля 176 каналу ієрархії, відносно повного визначення ієрархії передачі. Зазначимо, що даний канал ієрархії може в той же самий час бути призначений декільком елементам програми. Зарезервовані поля 164, 170 і 174 зарезервовані для майбутнього використання майбутнім розвитком стандартів. Способи даного розкриття не пропонують в цей час привласнювати семантичне значення значенням зарезервованих полів 164, 170 і 174. Поле 168 прапора присутності опорної часової мітки (TREF) є однобітовим полем, яке вказує, чи присутнє поле TREF у відповідному заголовку пакету PES. Поле TREF в пакеті PES є 33-бітовим числом, кодованим в трьох окремих полях. Поле TREF вказує значення часу декодування в системному цільовому декодері, як вказано за допомогою DTS або, у відсутність DTS, за допомогою PTS заголовка PES тієї ж самої j-ої одиниці доступу у відповідному елементарному потоці n. Таблиця 3 нижче описує елементи синтаксису дескриптора 112 ієрархії даного розкриття. Таблиця 3 також забезпечує, для кожного елемента синтаксису, число бітів, що використовуються для представлення елемента синтаксису, і мнемоніку, що описує тип для елемента синтаксису. Число бітів відповідає числу бітів, які виділені відповідному елементу синтаксису, коли дескриптор 112 ієрархії передається в кодованому потоці бітів. Мнемоніка використовується в стандарті MPEG-2 Систем, щоб описувати різні типиданих, які використовуються в кодованому потоці бітів. Мнемоніка, що використовується в даному розкритті, містить "uimsbf", який стандарт MPEG-2 Систем визначає як ціле число без знаку, що має старший біт спочатку, і "bslbf", який стандарт MPEG-2 Систем визначає як бітовий рядок з лівим бітом спочатку, де "лівий" є порядком, в якому бітові рядки записуються в стандарті MPEG-2 Систем. Кожний з елементів синтаксису в прикладі Таблиці 3 відповідає відповідному одному з елементів синтаксису, описаних вище відносно дескриптора 112 ієрархії. 17 UA 100645 C2 5 10 Таблиця 4 нижче описує різні можливі значення для поля 162 типу ієрархії дескриптора 112 ієрархії, а також опис для кожного значення. Дане розкриття пропонує додати можливе значення "14" для поля 162 типу ієрархії, яке містить опис "Префіксного підпотоку бітів MVC" як опис відповідного потоку бітів. Способи даного розкриття визначають префіксний підпотік бітів MVC, щоб містити всі префіксні одиниці NAL з nal_unit_type (тобто, значення типу одиниці NAL) таким, що дорівнює 20, і асоційовані не-VCL NAL одиниці, які, після повторного збирання з AVC відеопідпотоком бітів MVC, відповідають одному або більше профілям, визначеним в Додатку Н ITU-T Rec. H.264 ¦ ISO/IEC 14496-10. Способи даного розкриття також пропонують, що коли присутній AVC відеопідпотік бітів MVC, префіксний підпотік бітів MVC повинен також бути присутнім. Таблиця 4 Значення поля типу ієрархії Значення 0 1 2 3 4 5 6 7 8 9 10-13 14 15 15 20 25 30 35 40 Опис Зарезервовано Просторова масштабованість SNR масштабованість Тимчасова масштабованість Розділення даних Бітовий потік розширення Приватний потік Багатовидовий профіль Комбінована масштабованість Підпотік бітів відео MVC Зарезервовано Префіксний підпотік бітів MVC Базовий шар або базовий підпотік бітів відео MVC або AVC підпотік бітів відео MVC У деяких прикладах дескриптор 112 ієрархії може використовуватися, щоб сигналізувати підпотік бітів MVC, сигналізований інкрементним підпотоком бітів і вкладеними підпотоками бітів. Вкладені підпотоки бітів включають безпосередньо залежний підпотік бітів, відповідний індексу вкладеного шару ієрархії, і всі вкладені підпотоки бітів цього безпосередньо залежного підпотоку бітів. У даному розкритті види, які містяться явно, називаються видами посилення, в той час як види, які вкладені, називаються залежними видами. На Фіг. 6 представлена концептуальна діаграма, що ілюструє зразковий шаблон прогнозу MVC. У прикладі Фіг. 6 проілюстровані вісім видів (маючі ідентифікатори виду від "S0" до "S7"), і дванадцять тимчасових місцеположень (від "Т0" до "Т11") проілюстровані для кожного виду. Таким чином, кожний рядок на Фіг. 6 відповідає виду, в той час як кожний стовпець вказує на тимчасове місцеположення. Хоч MVC має так званий базовий вид, який є декодованим декодерами H.264/AVC, і стерео пара видів також могла б підтримуватися за допомогою MVC, перевага MVC полягає в тому, що воно може підтримувати приклад, який використовує більше двох видів як тривимірний (3D) відеовхід і декодує це 3D відео, представлене множинними видами. Рендерер клієнта, що має декодер MVC, може чекати 3D відеоконтент з множинними видами. Кадри на Фіг. 6 позначені при вказуванні кожного рядка і стовпця на Фіг. 6 з використанням заштрихованого блока з буквою, що вказує, чи є відповідний кадр інтра-кодованим (тобто, Iкадр) або інтер-кодованим в одному напрямку (тобто, Р-кадр) або у множині напрямків (тобто, В-кадр). У загальному випадку, прогнози позначені стрілками, де кадр, що вказується, використовує початковий об'єкт (звідки виходить вказування стрілкою) як опорне для прогнозу. Наприклад, Р-кадр виду S2 у тимчасовому місцеположенні Т0 передбачений з I-кадру виду S0 у тимчасовому місцеположенні Т0. Як при одновидовому кодуванні відео, кадри відеопослідовності багатовидового кодування відео, можуть предиктивно кодуватися відносно кадрів в різних тимчасових місцеположеннях. Наприклад, b-кадр виду S0 у тимчасовому місцеположенні T1, має стрілку, що вказує на нього з I-кадру виду S0 у тимчасовому місцеположенні, вказуючи, що b-кадр передбачений з I-кадру. Додатково, однак, в контексті багатовидового кодування відео, кадри можуть передбачатися міжвидовим способом. Таким чином, компонент виду може використовувати компоненти виду в 18 UA 100645 C2 5 10 15 20 інших видах як опора. У MVC, наприклад, міжвидовий прогноз реалізовується, як якби компонент виду в іншому виді був опорою для інтер-прогнозу. Потенційні міжвидові опори сигналізуються в розширенні Набору Параметрів Послідовності (SPS) MVC і можуть бути модифіковані процесом формування списку опорних картин, що забезпечує можливість гнучкого впорядкування опор для інтер-прогнозу і міжвидового прогнозу. Таблиця 5 нижче забезпечує зразкове визначення набору параметрів послідовності розширення MVC. Фіг. 6 забезпечує різні приклади міжвидового прогнозу. Кадри виду S1, в прикладі Фіг. 6, проілюстровані як такі, що передбачаються з кадрів в різних тимчасових місцеположеннях виду S1, а також як такі, що передбачаються міжвидовим чином з кадрів видів S0 і S2 в тих же самих тимчасових місцеположеннях. Наприклад, b-кадр виду S1 у тимчасовому місцеположенні Tl передбачений з кожного з В-кадрів виду S1 у тимчасових місцеположеннях Т0 і T2, а також bкадрів видів S0 і S2 у тимчасовому місцеположенні T1. У прикладі Фіг. 6 велика буква "B" і мала буква "b" призначені, щоб вказувати на різні ієрархічні відношення між кадрами, а не на різні методології кодування. У загальному випадку, "B"-кадри відносно вищі в ієрархії прогнозу, ніж "b"-кадри. Фіг. 6 також ілюструє зміни в ієрархії прогнозу з використанням різних рівнів штриховки, де кадри з більшою мірою штриховки (тобто, відносно темніші) вищі в ієрархії прогнозу, ніж кадри з меншою мірою штриховки (тобто, 19 UA 100645 C2 5 10 15 20 25 30 35 відносно світлі). Наприклад, всі I-кадри на Фіг. 6 проілюстровані з повною штриховкою, в той час як Р-кадри мають трохи світлішу штриховку, а В-кадри (і b-кадри) мають різні рівні штриховки відносно один одного, але завжди світліші, ніж штриховка Р-кадрів і I-кадрів. У загальному випадку, ієрархія прогнозу пов'язана з порядковими індексами видів, при цьому кадри відносно вищі в ієрархії прогнозу повинні декодуватися перед декодуванням кадрів, які відносно нижчі в ієрархії, так що кадри відносно вищі в ієрархії можуть використовуватися як опорні кадри при декодуванні кадрів відносно нижчих в ієрархії. Порядковий індекс виду - це індекс, який вказує порядок декодування компонентів виду в одиниці доступу. Порядкові індекси видів маються на увазі в розширенні SPS MVC, як визначено в Додатку Н стандарту H.264/AVC (поправка MVC). У SPS, для кожного індексу i, сигналізується відповідний ідентифікатор виду (view_id). Декодування компонентів виду повинно йти в порядку зростання порядкового індексу виду. Якщо всі види представлені, то порядкові індекси видів знаходяться в послідовному порядку від 0 до num_views__minus_1. Цим способом кадри, що використовуються як опорні кадри, можуть декодуватися перед декодуванням кадрів, які кодовані на основі опорних кадрів. Порядковий індекс виду - це індекс, який вказує на порядок декодування компонентів виду в одиниці доступу. Для кожного порядкового індексу i виду сигналізується відповідний view_id. Декодування компонентів виду йде в порядку зростання порядкових індексів виду. Якщо всі види представлені, то набір порядкових індексів видів містить впорядкований набір від нуля до меншого на одиницю повного числа видів. Для деяких кадрів на однакових рівнях ієрархії, порядок декодування може не мати значення відносно один до одного. Наприклад, I-кадр виду S0 у тимчасовому місцеположенні Т0 використовується як опорний кадр для Р-кадру виду S2 у тимчасовому місцеположенні Т0, який в свою чергу використовується як опорний кадр для Р-кадру виду S4 у тимчасовому місцеположенні Т0. Відповідно I-кадр виду S0 у тимчасовому місцеположенні Т0 повинен декодуватися перед Р-кадром виду S2 у тимчасовому місцеположенні Т0, який повинен декодуватися перед Р-кадром виду S4 у тимчасовому місцеположенні Т0. Однак між видами S1 і S3 порядок декодування не має значення, тому що види S1 і S3 не основуються один на одному для прогнозу, а замість цього передбачаються тільки з видів, які вищі в ієрархії прогнозу. Крім того, вид S1 може декодуватися перед видом S4, якщо вид S1 декодується після видів S0 і S2. Таким способом ієрархічне упорядкування може використовуватися для опису видів від S0 до S7. Нехай запис SA>SB означає, що вид SA повинен декодуватися перед видом SB. Використовуючи цей запис, S0>S2>S4>S6>S7, в прикладі Фіг. 6. Крім того, відносно прикладу Фіг. 6, S0>S1, S2>S1, S2>S3, S4>S3, S4>S5 і S6>S5. Будь-який порядок декодування для видів, який не порушує ці вимоги, можливий. Відповідно можлива множина різних порядків декодування, тільки з деякими обмеженнями. Два порядки декодування як приклад представлені нижче, хоч зрозуміло, що можливо багато інших порядків декодування. У одному прикладі, проілюстрованому в таблиці 6 нижче, види декодуються як можна швидше. 40 Таблиця 6 ID виду Порядковий індекс виду 45 S0 0 S1 2 S2 1 S3 4 S4 3 S5 6 S6 5 S7 7 Приклад таблиці 6 показує, що вид S1 може декодуватися безпосередньо після того, як види S0 і S2 декодовані, вид S3 може декодуватися безпосередньо після того, як види S2 і S4 декодовані, і вид S5 може декодуватися безпосередньо після того, як види S4 і S6 декодовані. Таблиця 7 нижче забезпечує інший порядок декодування як приклад, в якому порядок декодування такий, що будь-який вид, який використовується як опора для іншого виду, декодується перед видами, які не використовуються як опора ні для якого іншого виду. Таблиця 7 ID виду Порядковий індекс виду S0 S1 S2 S3 S4 S5 S6 S7 0 5 1 6 2 7 3 4 Приклад таблиці 7 показує, що кадри видів S1, S3, S5 і S7 не діють як опорні кадри для кадрів будь-яких інших видів, і тому види S1, S3, S5 і S7 декодуються після кадрів тих видів, які 20 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 використовуються як опорні кадри, тобто видів S0, S2, S4 і S6 в прикладі Фіг. 6. Відносно один одного, види S1, S3, S5 і S7 можуть декодуватися в будь-якому порядку. Відповідно в прикладі таблиці 7, вид S7 декодується перед кожним з видів S1, S3 і S5. Ясно, що можуть бути ієрархічні відношення між кадрами кожного виду, а також тимчасовими місцеположеннями кадрів кожного виду. Згідно з прикладом Фіг. 6, кадри у тимчасовому місцеположенні Т0 є інтра-передбаченими або передбаченими міжвидовим чином з кадрів інших видів у тимчасовому місцеположенні Т0. Точно так само, кадри у тимчасовому місцеположенні T8 є інтра-передбаченими або передбаченими міжвидовим чином з кадрів інших видів у тимчасовому місцеположенні T8. Відповідно, відносно тимчасової ієрархії, тимчасові місцеположення Т0 і T8 знаходяться вгорі тимчасової ієрархії. Кадри у тимчасовому місцеположенні T4, в прикладі Фіг. 6, нижчі у тимчасовій ієрархії, ніж кадри тимчасових місцеположень Т0 і T8, тому що кадри тимчасового місцеположення T4 є Вкодованими з опорою на кадри тимчасових місцеположень Т0 і T8. Кадри у тимчасових місцеположеннях T2 і T6 нижчі у тимчасовій ієрархії, ніж кадри у тимчасовому місцеположенні T4. Нарешті, кадри у тимчасових місцеположеннях T1, T3, T5 і T7 нижчі у тимчасовій ієрархії, ніж кадри тимчасових місцеположень T2 і T6. У MVC піднабір всього потоку бітів може бути витягнутий, щоб сформувати підпотік бітів, який все ще відповідає MVC. Є багато можливих підпотоків бітів, яких можуть потребувати конкретні додатки, наприклад, на основі послуги, що надається сервером, ємності, підтримки і функціональних можливостей декодерів одного або більше клієнтів і/або переваги одного або більше клієнтів. Наприклад, клієнт міг би потребувати тільки три види, і могло б бути два сценарії. У одному прикладі один клієнт може потребувати плавного сприйняття перегляду і міг би віддати перевагу видам зі значеннями view_id S0, S1 і S2, в той час як інший клієнт може потребувати масштабованість виду і віддати перевагу видам зі значеннями view_id S0, S2 і S4. Якщо спочатку view_id впорядковані відносно прикладів таблиці 6, значеннями порядкових індексів видів є {0, 1, 2} і {0, 1, 4} в цих двох прикладах відповідно. Зазначимо, що обидва ці підпотоки бітів можуть декодуватися як незалежні потоки бітів MVC і можуть підтримуватися одночасно. На Фіг. 7 показана блок-схема, що ілюструє зразковий спосіб відправлення потоку MPEG-2 Систем, що має піднабір видів з непослідовними порядковими індексами видів, від сервера на клієнт. Спосіб по Фіг. 7 описаний, з метою прикладу, відносно пристрою 20 джерела А/V і пристрою 40 призначення А/V, хоч зрозуміло, що інші приклади можуть виконувати спосіб по Фіг. 7. У прикладі Фіг. 7 дії, призначені "серверу", можуть виконуватися пристроєм 20 джерела А/V, в той час як дії, що виконуються "клієнтом", можуть бути виконані пристроєм 40 призначення А/V. У прикладі Фіг. 7 пристрій 20 джерела А/V спочатку визначає підмножину доступних видів для передачі в пристрій 40 призначення А/V на основі послуги, що надається пристроєм 20 джерела А/V (200). Як обговорено вище, послуга в загальному випадку містить відбір видів. Відносно прикладу Фіг. 6, послуга може містити види S0, S2 і S4. Передбачаючи, що порядкові індекси видів для цих видів є порядковими індексами видів, призначеними Таблицею 6, як приклад, порядкові індекси видів для видів S0, S2 і S4 можуть містити порядкові індекси 0, 1 і 3 видів. Обговорення способу по Фіг. 7 використовує ці ідентифікатори видів і порядкові індекси видів для прикладу з метою пояснення. Пристрій 20 джерела А/V може потім підготувати Таблицю Карти Програми (PMT) на основі видів, які були визначені для передачі як частина надання послуги (202). Зокрема, формувач PMT 64 мультиплексора 30 може підготувати PMT на основі інформації, витягнутій з таблиць 88 специфічної для програми інформації для однієї або більше програм, що відповідають послузі, що надається пристроєм 20 джерела А/V 20. Відповідно до методів даного розкриття, підготовка PMT містить генерацію дескриптора 110 розширення MVC і дескриптора 112 ієрархії. Для генерації дескриптора 110 розширення MVC, формувач PMT 64 мультиплексора 30 встановлює поле 120 тегу дескриптора, що дорівнює "49". Формувач PMT 64 встановлює значення поля 124 середньої бітової швидкості, поля 126 максимальної бітової швидкості, поля 130 початку тимчасового ідентифікатора, поля 132 кінця тимчасового ідентифікатора і поля 134 відсутності одиниць NAL згідно зі специфічними для програми даними, як збережено в таблицях 88 специфічної для програми інформації. Формувач PMT 64 також встановлює значення полів 136 порядкового індексу виду згідно з порядковими індексами вибраних видів. У прикладі, описаному вище, формувач PMT 64 включає значення полів трьох порядкових індексів видів, що представляють порядкові індекси 0, 1 і 3. Таким чином, даний приклад забезпечує дескриптор розширення MVC, який індивідуально вказує на кожний порядковий індекс виду для 21 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 видів програми. Крім того, оскільки порядковий індекс "2" виду пропущений, цей приклад є прикладом, в якому порядкові індекси видів непослідовні. Для генерації дескриптора 112 ієрархії, формувач PMT 64 встановлює значення полів дескриптора 112 ієрархії згідно з таблицями 88 специфічної для програми інформації. Відповідно до методів даного розкриття, формувач PMT 64 може також встановити значення поля 154 прапора посилення виду в значення '0', щоб вказати, що асоційований елемент програми збільшує число видів бітового потоку, що виходять з елемента програми, на який відсилається значення поля 172 індексу вкладеного шару ієрархії. Після генерації PMT пристрій 20 джерела А/V може передати PMT до пристрою 40 призначення А/V, наприклад, у формі одиниці NAL (204). У деяких прикладах пристрій 20 джерела А/V може періодично відправляти PMT до пристрою 40 призначення А/V, наприклад, після попередньо визначеного часового інтервалу або після того, як відісланий конкретний об'єм даних. Пристрій 40 А/V призначення може записати інформацію програми з PMT на носій зберігання клієнтської сторони (208), який може по суті відображати таблиці 88 специфічної для програми інформації мультиплексора 30. Наприклад, демультиплексор 38 може містити набір таблиць специфічної для програми інформації, подібних таблицям 88 специфічної для програми інформації мультиплексора 30. Після прийому специфічної для програми інформації, такої як передана PMT, демультиплексор 38 може оновити таблиці специфічної для програми інформації демультиплексора 38. Мультиплексор 30 може потім прийняти пакети PES однієї або більше програм, пов'язані з послугою, що надається пристроєм 20 джерела А/V 20 (210). Мультиплексор 30 може визначити, що пакети PES повинні бути включені в транспортний потік до пристрою 40 призначення А/V, шляхом виконання пошуку по ідентифікаторах потоків пакетів PES. Коли ідентифікатор потоку пакету PES відповідає виду, який повинен бути включений в транспортний потік, мультиплексор 30 може сформувати одиницю NAL з пакету PES, наприклад, шляхом інкапсулювання пакету PES з ідентифікатором програми (PID), відповідним програмі (212). Мультиплексор 30 може також сформувати одиницю доступу з множини таких одиниць NAL (214) і відіслати одиницю доступу в пристрій 40 призначення AV (216). Пристрій 40 призначення А/V може потім прийняти одиницю доступу від пристрою 20 джерела А/V (218) і асоціювати одиницю доступу з програмою (220), наприклад, шляхом звертання до PID з одиниці доступу. Демультиплексор 38 пристрою 40 призначення А/V може демультиплексувати одиницю доступу в компонентні одиниці NAL і, відповідно пакети PES, які демультиплексор 38 може зрештою передати до аудіодекодеру 46 і/або відеодекодеру 48. Відеодекодер 48 може декодувати кожний із видів і відіслати декодовані види на відеовиведення 44, що може містити стереоскопічний або автостереоскопічний відеодисплей або інший пристрій відображення, що потребує множини видів. Аналогічно, аудіодекодер 46 може декодувати аудіокадри, щоб сформувати декодовані аудіодані і відіслати аудіодані на аудіовихід 42, наприклад, динамік. Таким чином, пристрій 40 А/V призначення може декодувати і відображати прийняті дані (222). На Фіг. 8 показана блок-схема, що ілюструє зразковий спосіб для збирання компонентів видів двох або більше підпотоків бітів, щоб згенерувати потік бітів таким чином, щоб компоненти виду мали зростаючі порядкові індекси видів. Спосіб може упорядковувати підпотоки бітів, не звертаючись до ідентифікаторів видів відповідних підпотоків бітів і компонентів виду. Передбачимо, відносно прикладу Фіг. 6, що перший підпотік бітів транспортного потоку (або потоку програми) містить компоненти виду для видів S0, S2 і S4, в той час як другий підпотік бітів транспортного потоку (відповідний вкладеному підпотоку бітів першого підпотоку бітів) містить компоненти виду для видів S1 і S3. Дане розкриття може також відсилатися на вкладені підпотоки бітів як "залежні підпотоки бітів." Аналогічно, дане розкриття може відсилатися на підпотоки бітів, в які вкладені залежні підпотоки бітів, як на основні підпотоки бітів. Відповідно перший підпотік бітів на Фіг. 8 може згадуватися як основний підпотік бітів, в той час як другий підпотік бітів може згадуватися як вкладений або залежний підпотік бітів. Передбачаючи, що порядкові індекси видів для цього прикладу такі, як визначено в таблиці 6, порядкові індекси видів компонентів виду в першому підпотоці бітів дорівнюють 0, 1 і 3 (відповідно), в той час як порядкові індекси видів для другого підпотоку бітів дорівнюють 2 і 4. Відповідно, якщо компоненти виду першого потоку бітів в цьому прикладі були повністю декодовані перед компонентами виду другого підпотоку бітів, порядок декодування, з точки зору порядкових індексів видів, буде відповідати 0, 1, 3, 2, 4. Оскільки порядкові індекси видів повинні описувати порядок декодування, такий порядок декодування спричинив би порушення специфікації MVC. Відповідно спосіб по Фіг. 8 може використовуватися, щоб переупорядкувати 22 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 компоненти виду, з точки зору порядкових індексів видів, щоб порядок декодування компонентів виду відповідав специфікації MVC. Спосіб по Фіг. 8 в загальному випадку відповідає зразковому способу, в якому, при збиранні підпотоків бітів, компоненти виду в кожній одиниці доступу повинні слідувати зростаючому порядку порядкових індексів видів, як переноситься в поточному підпотоці бітів і його вкладених підпотоках бітів. Способи даного розкриття забезпечують можливість збирання підпотоку, що узгоджується, бітів MVC без перевірки елемента синтаксису view_id в заголовку одиниці NAL одиниць NAL і його відображення на порядковий індекс виду. Спосіб по Фіг. 8 може використовуватися для формування списку, що називається "списком індексів шарів ієрархії" (HLI), який містить індекси, відповідні view_ID підпотоків бітів в порядку, відповідному стандарту MVC. Спочатку, клієнтський пристрій, такий як пристрій 40 А/V призначення, отримує одиницю доступу, що має компоненти виду двох підпотоків бітів (250). Передбачається, з метою прикладу, що другий підпотік бітів містить вкладений або залежний підпотік бітів першого підпотоку бітів. Зразковий спосіб по Фіг. 8 описаний відносно двох підпотоків бітів. Однак методи по Фіг. 8 також застосовні до прикладів, що мають більше двох підпотоків бітів. Крім того, спосіб по Фіг. 8 описаний з метою прикладу для пояснень відносно демультиплексора 38 пристрою 40 призначення А/V. Однак зрозуміло, що спосіб по Фіг. 8 може бути виконаний будьяким пристроєм, модулем, блоком або комбінацією програмованого обладнання, апаратних засобів і/або компонентів програмного забезпечення, щоб реорганізувати види двох або більше підпотоків бітів для відповідності стандарту MVC. Передбачається, що компоненти виду кожного підпотоку бітів впорядковані згідно зі стандартом MVC. Тому демультиплексор 38 визначає, який з компонентів виду підпотоків бітів має найменший порядковий індекс виду (252). Демультиплексор 38 може додати індекс компонента виду (який може містити одну або більше одиниць NAL) до списку HLI в наступному доступному положенні (254). У деяких прикладах компонент виду може містити одну або більше одиниць NAL, що включають мультимедійні дані, а також роздільник одиниці NAL, яка може використовуватися, щоб відрізнити компонент виду від іншого, подальшого компонента виду. Демультиплексор 38 може потім визначити, чи залишаються які-небудь компоненти виду для першого підпотоку бітів (256). Якщо компоненти виду залишаються для першого підпотоку бітів (гілка "ТАК" від 256), демультиплексор 38 може визначити, чи залишаються компоненти виду також для другого підпотоку бітів (258). Коли перший підпотік бітів і другий підпотік бітів включають щонайменше один компонент виду (гілка "ТАК" від 258), демультиплексор 38 повертається до етапу 252, щоб визначити найменший порядковий індекс виду компонентів виду і додати індекс виду найменшого компонента виду до списку HLI. Однак коли компоненти виду залишаються тільки для першого підпотоку бітів, але не другого (гілка "НІ" від 258), демультиплексор 38 може додати компоненти виду, що залишаються, першого підпотоку бітів до списку HLI (260). З іншого боку, коли ніякі компоненти виду не залишаються для першого підпотоку бітів (гілка "НІ" від 256), демультиплексор 38 може визначити, чи залишаються компоненти виду для другого підпотоку бітів (262). Коли другий підпотік бітів має компоненти виду, що залишаються, демультиплексор 38 може додати компоненти виду, що залишаються, другого підпотоку бітів до списку HLI (264). Після того, як список HLI містить ідентифікатори видів в порядку відповідних порядкових індексів видів (наприклад, після завершення етапу 260, 264, або гілка "НІ" від 262), демультиплексор 38 може сформувати новий потік бітів, що містить підпотоки бітів в порядку, визначеному згідно зі списком HLI. Таким чином, для одиниці доступу нового потоку бітів, де одиниця доступу містить множину компонентів виду, компоненти виду впорядковані в новому потоці бітів таким чином, що порядковий індекс виду кожного компонента виду більший, ніж всі попередні порядкові індекси виду, і менший, ніж всі подальші порядкові індекси виду. Цей потік бітів може тоді бути відправлений, наприклад, на відеодекодер 48, щоб декодувати компоненти виду і, зрештою, відображати компоненти виду. Зразкові алгоритми, наведені як приклад нижче, забезпечують зразковий процес упорядкування підпотоків бітів для відповідності стандарту MVC. У прикладах є список значень індексу шару ієрархії (HLIList), який або відповідає поточному підпотоку бітів MVC або вкладеним підпотокам бітів. Як відмічено вище, компонент виду може містити множину одиниць NAL. Аналогічно, в деяких прикладах, компонент виду може містити, або за ним може йти, роздільник одиниць NAL, щоб диференціювати кожний компонент виду від іншого компонента виду. Процес для збирання нового потоку бітів може бути визначений таким чином: 23 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 60 1. Встановити залежний підпотік бітів як підпотік бітів, який не має вкладеного підпотоку бітів. 2. У порядку зростання індексу шару ієрархії, ітеративно застосовувати наступне: 1. Зібрати підпотік бітів, який відповідає MVC і описаний в дескрипторі ієрархії з індексом шару ієрархії, що дорівнює HLI: 2. Цей процес має наступне як вхід: i. Підпотік бітів розширення, який явно представлений; ii. Залежний підпотік бітів. Зазначимо, що він відповідає MVC і, таким чином, має компоненти виду, розміщені в зростаючому порядку порядкового індексу виду в кожній одиниці доступу; iii. Список порядкових індексів видів в підпотоці бітів розширення; iv. Список виду порядкових індексів видів в залежному підпотоці бітів; 3. Процес має наступне як вихід: i. Новий підпотік бітів, який має всі зібрані компоненти виду і, таким чином, відповідає MVC і формує повну операційну точку, відповідну HLI, визначеному в дескрипторі ієрархії; ii. Список порядкових індексів видів в новому підпотоці бітів; 4. Встановити новий підпотік бітів, згенерований на етапі 3 як залежний підпотік бітів; 5. Якщо HLI є останнім у списку HLIList, встановити залежний підпотік бітів як остаточний зібраний підпотік бітів MVC і завершити весь процес збирання. Наступний алгоритм описує зразковий процес для збирання підпотоку бітів на основі залежного підпотоку бітів і підпотоку бітів розширення, як потрібно на етапі 2 наведеного вище зразкового алгоритму: 1. Входами процесу збирання є два списки і два підпотоки бітів, кожний з яких вже впорядкований в зростаючому порядку порядкового індексу виду. Кожний з цих двох списків містить порядкові індекси видів в зростаючому порядку, ці два списки - VOIdxListE і VOIdxListD. Два підпотоки бітів є залежним підпотоком бітів і підпотоком бітів розширення. Новим списком є VOIdxListNew, який спочатку пустий. 2. Для кожної одиниці доступу, застосувати наступне: i. Встановити VOIdxE як перше значення VOIdxListE і VOIdxD як перше значення VOIdxListD; ii. Якщо VOIdxE менше, ніж VOIdxD, зібрати один компонент виду з підпотоку бітів розширення, встановити VOIdxE в наступне значення в VOIdxListE, VOIdxCurr встановлений в VOIdxE; інакше, зібрати один компонент виду із залежного підпотоку бітів, встановити VOIdxD в наступне значення в VOIdxListD, VOIdxCurr встановлений в VOIdxD. Додати VOIdxCurr до VOIdxListNew. - При збиранні одного компонента виду з підпотоку бітів, одиниці NAL додаються, поки не буде виявлена одиниця NAL роздільника. iii. Якщо VOIdxE не в кінці VOIdxListE, і VOIdxD не в кінці VOIdxListD, завершити весь процес; інакше, перейти до етапу iv. iv. Крім того, якщо VOIdxE в кінці VOIdxListE, зібрати всі компоненти виду, що залишаються, в залежному підпотоці бітів, додати всі значення, що залишаються, в VOIdxListD в VOIdxListNew, і встановити VOIdxD в кінець VOIdxListD. v. Крім того, якщо VOIdxD в кінці VOIdxListD, зібрати всі компоненти виду, що залишаються, в підпотік бітів розширення, додати всі значення, що залишаються, в VOIdxListE в VOIdxListNew і встановити VOIdxE в кінець VOIdxListE. vi. Крім того, перейти до етапу ii. У одному або більше прикладах, описані функції можуть бути здійснені в апаратних засобах, програмному забезпеченні, програмованому обладнанні або будь-якій комбінації вказаного. При здійсненні в програмному забезпеченні, функції можуть зберігатися або передаватися як одна або більше інструкцій або код на машиночитаному носії. Машиночитані носії включають в себе як комп'ютерні носії зберігання, так і комунікаційні середовища, включаючи будь-яке середовище, яке полегшує передачу комп'ютерної програми від одного місця в інше. Носії зберігання можуть бути будь-якими доступними носіями, до яких можуть отримувати доступ один або більше комп'ютерів або один або більше процесорів для витягання інструкцій, кодів і/або структур даних для реалізації описаних методів. Як приклад, але не обмеження, такі машиночитані носії можуть включати в себе RAM (ОЗП), ROM (ПЗП), EEPROM (електрично-стираний програмований ПЗП), CD-ROM або інший ЗП на оптичному диску, ЗП на магнітному диску або інші магнітні ЗП, флеш-пам'ять або будь-який інший носій, який може використовуватися, щоб переносити або зберігати бажаний програмний код у формі інструкцій або структур даних, і до якого може отримувати доступ комп'ютер. Крім того, будь-яке з'єднання належним чином визначається як машиночитане середовище. Наприклад, якщо програмне 24 UA 100645 C2 5 10 15 20 25 забезпечення передається з веб-сайту, сервера або іншого віддаленого джерела з використанням коаксіального кабелю, волоконно-оптичного кабелю, витої пари, цифрової абонентської лінії (DSL), або бездротових технологій, таких як інфрачервона, радіочастотна і мікрохвильова, то коаксіальний кабель, волоконно-оптичний кабель, вита пара, DSL або бездротові технології, такі як інфрачервона, радіочастотна і мікрохвильова, включаються у визначення носія. Диски, як використовується тут, включають в себе компакт-диск (CD), лазерний диск, оптичний диск, цифровий універсальний диск (DVD), дискету (floppy disk) і bluray-disc, де магнітні диски (disks) звичайно відтворюють дані магнітним способом, в той час як оптичні диски (discs) відтворюють дані оптичним способом за допомогою лазера. Комбінації вищезазначеного повинні також бути включені в об'єм машиночитаних носіїв. Коди можуть виконуватися одним або більше процесорами, такими як один або більше цифрових процесорів сигналів (DSP), універсальні процесори, спеціалізовані інтегральні схеми (ASIC), програмовані вентильні матриці (FPGA) або інші еквівалентні інтегральні або дискретні логічні схеми. Відповідно термін "процесор", як використовується тут, може належати до будьякої вищезазначеної структури або будь-якої іншої структури, відповідної для виконання методів, описаних тут. Крім того, в деяких аспектах, функціональність, описана тут, може бути забезпечена спеціалізованими апаратними засобами і/або програмними модулями, конфігурованими для кодування і декодування або включеними в об'єднаний кодек. Крім того, ці методи можуть бути повністю реалізовані в одній або більше схемах або логічних елементах. Методи даного розкриття можуть бути реалізовані в різноманітних пристроях, включаючи бездротову телефонну трубку, інтегральну схему (IC) або набір IC (наприклад, чипсет). Різні компоненти, модулі або блоки описані в даному розкритті, щоб підкреслити функціональні аспекти пристроїв, що конфігуруються для виконання розкритих методів, але не обов'язково вимагають реалізації різними блоками апаратних засобів. Швидше, як описано вище, різні блоки можуть бути об'єднані в блок апаратних засобів кодека або забезпечені набором взаємодіючих блоків апаратних засобів, включаючи один або більше процесорів, як описано вище, у взаємозв'язку з відповідним програмним забезпеченням і/або програмованим обладнанням. Вище були описані різні приклади. Ці та інші приклади знаходяться в межах об'єму наступної формули винаходу. 30 ФОРМУЛА ВИНАХОДУ 35 40 45 50 55 1. Спосіб передачі MPEG-2 потоку бітів, що має множину видів, що містить: визначення піднабору доступних видів для передачі до пристрою призначення і передачу потоку бітів, що містить піднабір доступних видів, від пристрою джерела до пристрою призначення, який відрізняється формуванням, за допомогою пристрою джерела, структури даних для сигналізації, що потік бітів містить перший вид сцени, асоційований з першим порядковим індексом виду, і другий вид сцени, асоційований з другим порядковим індексом виду, причому структура даних містить дескриптор розширення багатовидового відеокодування (MVC), що містить окремі значення порядкового індексу виду для кожного виду, включеного в потік бітів, причому окремі значення порядкового індексу виду містять значення для першого порядкового індексу виду і другого порядкового індексу виду, причому перший порядковий індекс виду і другий порядковий індекс виду є непослідовними; і передачею структури даних до пристрою призначення. 2. Спосіб за п. 1, в якому структура даних містить таблицю карти програми, і потік бітів містить транспортний потік MPEG-2. 3. Спосіб за п. 1, в якому структура даних містить карту потоку програми, і потік бітів містить потік програми MPEG-2. 4. Спосіб за п. 1, в якому значення порядкового індексу виду впорядковані в зростаючому порядку. 5. Спосіб за п. 4, в якому значення порядкового індексу виду містять перше значення порядкового індексу виду і друге значення порядкового індексу виду, причому друге значення порядкового індексу виду присутнє безпосередньо після першого значення порядкового індексу виду в дескрипторі розширення MVC, і при цьому різниця між другим значенням порядкового індексу виду і першим значенням порядкового індексу виду більша ніж один. 6. Спосіб за п. 1, в якому формування структури даних додатково містить формування дескриптора ієрархії, що містить значення для поля прапора посилення виду, яке вказує, що асоційований елемент програми збільшує число видів потоку бітів, одержуване з елемента 25 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 програми, на який відсилається значення поля індексу вкладеного шару ієрархії дескриптора ієрархії. 7. Спосіб за п. 6, в якому формування дескриптора ієрархії містить встановлення значення поля прапора посилення виду в значення, що дорівнює нулю. 8. Спосіб за п. 6, що додатково містить визначення, що потік бітів містить базовий вид вдосконаленого відеокодування (AVC) MVC, причому формування дескриптора ієрархії містить встановлення значення поля типу ієрархії в дескрипторі ієрархії на значення, яке вказує, що потік бітів містить префіксний підпотік бітів MVC, що містить всі префіксні одиниці шару мережевої абстракції (NAL), що містять значення типу, що дорівнює двадцяти. 9. Спосіб за п. 8, в якому встановлення значення поля типу ієрархії містить встановлення значення поля типу ієрархії на значення, що дорівнює чотирнадцяти. 10. Спосіб за п. 1, що додатково містить: формування одиниці доступу, що містить компонент виду першого виду і компонент виду другого виду, причому компонент виду першого виду присутній в одиниці доступу безпосередньо перед компонентом виду другого виду, так що перший порядковий індекс виду і другий порядковий індекс виду для компонентів виду присутні непослідовно в одиниці доступу; і виведення одиниці доступу. 11. Пристрій для відправлення MPEG-2 потоку бітів, що має множину видів, який містить: відеокодер, який кодує множину видів сцени за допомогою визначення піднабору доступних видів для відправлення до пристрою призначення; і має засіб для відправлення потоку бітів, що містить піднабір доступних видів, від пристрою джерела до пристрою призначення, який відрізняється мультиплексором, який формує структуру даних для сигналізації, що потік бітів містить перший вид з множини видів сцени, асоційований з першим порядковим індексом виду, і другий вид з множини видів сцени, асоційований з другим порядковим індексом виду, причому структура даних містить дескриптор розширення багатовидового відеокодування (MVC), що містить окремі значення порядкового індексу виду для кожного виду, включеного в потік бітів, причому окремі значення порядкового індексу виду містять значення для першого порядкового індексу виду і другого порядкового індексу виду, причому перший порядковий індекс виду і другий порядковий індекс виду є непослідовними; і вихідний інтерфейс, який виводить структуру даних для передачі до пристрою призначення. 12. Пристрій за п. 11, в якому структура даних містить таблицю карти програми, і потік бітів містить транспортний потік MPEG-2. 13. Пристрій за п. 11, в якому структура даних містить карту потоку програми, і потік бітів містить потік програми MPEG-2. 14. Пристрій за п. 11, в якому для формування структури даних, мультиплексор формує дескриптор розширення багатовидового відеокодування (MVC), що містить окремі значення порядкового індексу виду для кожного виду, включеного в потік бітів, і при цьому значення порядкового індексу виду впорядковані в зростаючому порядку. 15. Пристрій за п. 14, в якому значення порядкового індексу виду містять перше значення порядкового індексу виду для першого порядкового індексу виду і друге значення порядкового індексу виду для другого порядкового індексу виду, причому друге значення порядкового індексу виду присутнє безпосередньо після першого значення порядкового індексу виду в дескрипторі розширення MVC, і при цьому різниця між другим значенням порядкового індексу виду і першим значенням порядкового індексу виду більша ніж один. 16. Пристрій за п. 11, в якому, для формування структури даних, мультиплексор додатково формує дескриптор ієрархії, що містить значення для поля прапора посилення виду, яке вказує, що асоційований елемент програми збільшує число видів потоку бітів, одержуване з елемента програми, на який відсилається значення поля індексу вкладеного шару ієрархії дескриптора ієрархії. 17. Пристрій за п. 16, в якому для формування дескриптора ієрархії, мультиплексор встановлює значення поля прапора посилення виду в значення, що дорівнює нулю. 18. Пристрій за п. 16, в якому мультиплексор визначає, чи містить потік бітів базовий вид вдосконаленого відеокодування (AVC) MVC, і якщо потік бітів містить базовий вид AVC MVC, мультиплексор встановлює значення поля типу ієрархії в дескрипторі ієрархії на значення, яке вказує, що потік бітів містить префіксний підпотік бітів MVC, що містить всі префіксні одиниці шару мережевої абстракції (NAL), які містять значення типу, що дорівнює двадцяти. 19. Пристрій за п. 18, в якому для встановлення значення поля типу ієрархії, мультиплексор встановлює значення поля типу ієрархії на значення, що дорівнює чотирнадцяти. 20. Пристрій за п. 11, 26 UA 100645 C2 5 10 15 20 25 30 35 40 45 50 55 в якому мультиплексор формує одиницю доступу, що містить компонент виду першого виду і компонент виду другого виду, причому компонент виду першого виду присутній в одиниці доступу безпосередньо перед компонентом виду другого виду, так що перший порядковий індекс виду і другий порядковий індекс виду для компонентів виду присутні непослідовно в одиниці доступу; і в якому вихідний інтерфейс виводить одиницю доступу. 21. Пристрій за п. 11, причому пристрій містить щонайменше одне з: інтегральної схеми; мікропроцесора і пристрою бездротового зв'язку, який містить відеокодер. 22. Пристрій для генерації багатовидових відеоданих, що містить: засіб для визначення піднабору доступних видів для відправлення до пристрою призначення і засіб для відправлення потоку бітів, що містить піднабір доступних видів, від пристрою джерела до пристрою призначення, який відрізняється засобом для формування, за допомогою пристрою джерела, структури даних для сигналізації, що потік бітів містить перший вид сцени, асоційований з першим порядковим індексом виду, і другий вид сцени, асоційований з другим порядковим індексом виду, причому структура даних містить дескриптор розширення багатовидового відеокодування (MVC), що містить окремі значення порядкового індексу виду для кожного виду, включеного в потік бітів, причому окремі значення порядкового індексу виду містять значення для першого порядкового індексу виду і другого порядкового індексу виду, причому перший порядковий індекс виду і другий порядковий індекс виду є непослідовними; і засіб для передачі структури даних до пристрою призначення. 23. Пристрій за п. 22, в якому структура даних містить таблицю карти програми, і потік бітів містить транспортний потік MPEG-2. 24. Пристрій п. 22, в якому структура даних містить карту потоку програми, і потік бітів містить потік програми MPEG-2. 25. Пристрій за п. 22, в якому засіб для формування структури даних містить засіб для формування дескриптора розширення багатовидового відеокодування (MVC), що містить окремі значення порядкового індексу виду для кожного виду, включеного в потік бітів, в якому окремі значення порядкового індексу виду містять значення для першого порядкового індексу виду і другого порядкового індексу виду, і в якому значення порядкового індексу виду впорядковані в зростаючому порядку. 26. Пристрій за п. 25, в якому значення порядкового індексу виду містять перше значення порядкового індексу виду і друге значення порядкового індексу виду, причому друге значення порядкового індексу виду присутнє безпосередньо після першого значення порядкового індексу виду в дескрипторі розширення MVC, і при цьому різниця між другим значенням порядкового індексу виду і першим значенням порядкового індексу виду більша ніж один. 27. Пристрій за п. 22, в якому засіб для формування структури даних додатково містить засіб для формування дескриптора ієрархії, що містить значення для поля прапора посилення виду, яке вказує, що асоційований елемент програми збільшує число видів потоку бітів, одержуване з елемента програми, на який відсилається значення поля індексу вкладеного шару ієрархії дескриптора ієрархії. 28. Пристрій за п. 27, в якому засіб для формування дескриптора ієрархії містить засіб для встановлення значення поля прапора посилення виду в значення, що дорівнює нулю. 29. Пристрій за п. 27, що додатково містить засіб для визначення, що потік бітів містить базовий вид вдосконаленого відеокодування (AVC) MVC, причому засіб для формування дескриптора ієрархії містить засіб для встановлення значення поля типу ієрархії в дескрипторі ієрархії на значення, яке вказує, що потік бітів містить префіксний підпотік бітів MVC, що містить всі префіксні одиниці шару мережевої абстракції (NAL), що містять значення типу, що дорівнює двадцяти. 30. Пристрій за п. 29, в якому засіб для встановлення значення поля типу ієрархії містить засіб для встановлення значення поля типу ієрархії на значення, що дорівнює чотирнадцяти. 31. Пристрій за п. 22, що додатково містить: формування одиниці доступу, що містить компонент виду першого виду і компонент виду другого виду, причому компонент виду першого виду присутній в одиниці доступу безпосередньо перед компонентом виду другого виду, так що перший порядковий індекс виду і другий порядковий індекс виду для компонентів виду присутні непослідовно в одиниці доступу; і виведення одиниці доступу. 27 UA 100645 C2 32. Комп'ютерозчитуваний носій даних, закодований інструкціями, які спонукають процесор пристрою джерела відеоданих виконувати спосіб за п. 1. 28