МНОГОВИДОВОЕ ВИДЕО КОДИРОВАНИЕ В СИСТЕМАХ МРЕG-2

Связанные заявки

[0001] Настоящая заявка испрашивает приоритет Предварительных заявок США №61/221449, поданной 29 июня 2009, и 61/186613, поданной 12 июня 2009, все содержание которых во всей их полноте настоящим явно включено в данный документ посредством ссылки.

Перекрестная ссылка на связанные заявки

[0002] Настоящая заявка на патент связана со следующей находящейся на рассмотрении патентной заявкой США: “Assembling Multiview Video Coding Sub-Bitstreams in MPEG-2 Systems” автора Ying Chen, номер дела поверенного №092652, поданный одновременно с настоящей заявкой, переуступленной заявителю настоящей заявки и явно включенной посредством ссылки в настоящий документ.

Область техники

[0003] Настоящее раскрытие имеет отношение к транспорту кодированных видео данных.

Предшествующий уровень техники

[0004] Цифровые видео функциональные возможности могут быть включены в широкий диапазон устройств, включая цифровые телевизоры, цифровые системы прямого вещания, беспроводные системы вещания, персональные цифровые помощники (PDA), ноутбуки или настольные компьютеры, цифровые фотокамеры, устройства цифровой записи, цифровые медиаплееры, видео игровые устройства, игровые приставки, сотовые или спутниковые радиотелефоны, устройства видео телеконференций и т.п. Цифровые видео устройства реализуют методы видео сжатия, такие как описанные в стандартах, определенных MPEG-2, MPEG-4, ITU-T H.263 или ITU-T H.264/MPEG-4, Часть 10, Усовершенствованное Видео Кодирование (AVC), и расширениях таких стандартов, чтобы передавать и принимать цифровую видео информацию более эффективно.

[0005] Методы видео сжатия выполняют пространственное предсказание и/или временное предсказание, чтобы уменьшить или удалить избыточность, присущую видео последовательностям. Для блочного видео кодирования, видео кадр или вырезка могут быть разделены в макроблоки. Каждый макроблок может быть дополнительно разделен. Макроблоки в интра-(«внутри») кодированном (I) кадре или вырезке кодируются с использованием пространственного предсказания относительно соседних макроблоков. Макроблоки в интер-(«между»)кодированном (P или B) кадре или вырезке могут использовать пространственное предсказание относительно соседних макроблоков в том же самом кадре или вырезке или временное предсказание относительно других опорных кадров.

[0006] После того, как видео данные закодированы, видео данные могут пакетироваться мультиплексором для передачи или хранения. MPEG-2 содержит секцию "Системы", которая определяет транспортный уровень для многих стандартов видео кодирования. Системы транспортного уровня MPEG-2 могут использоваться видео кодерами MPEG-2 или другими видео кодерами, соответствующими различным стандартам видео кодирования. Например, MPEG-4 предписывает различные методы кодирования и декодирования, иные чем в MPEG-2, но видео кодеры, реализующие методы стандарта MPEG-4, могут все еще использовать методологии транспортного уровня MPEG-2. В общем случае, ссылки на “MPEG-2 системы” относятся к транспортному уровню видео данных, предписанному MPEG-2. Транспортный уровень, предписанный MPEG-2, также упоминается в настоящем раскрытии как “транспортный поток MPEG-2” или просто “транспортный поток”. Аналогично, транспортный уровень систем MPEG-2 также содержит потоки программы. Транспортные потоки и потоки программы в общем случае включают различные форматы для доставки подобных данных, где транспортный поток содержит одну или более “программ”, включающих как аудио, так и видео данные, в то время как потоки программы включают одну программу, содержащий как аудио, так и видео данные.

[0007] Спецификация MPEG-2 систем описывает, как сжатые мультимедиа (видео и аудио) потоки данных могут мультиплексироваться вместе с другими данными, чтобы сформировать единственный поток данных, подходящий для цифровой передачи или хранения. Последняя спецификация систем MPEG-2 определена в документе "Информационная технология - родовое кодирование движущихся изображений и ассоциированной аудио информации: Системы, Рекомендация H.222.0; Международная Организация по Стандартизации, ISO/IEC JTC1/SC29/WG11; Кодирование движущихся изображений и ассоциированной аудио информации", май 2006. MPEG недавно выпустила транспортный стандарт MVC по MPEG-2 системам, и последней версией этой спецификации является: "Study of ISO/IEC 13818-1:2007/FPDAM4 Trabsport of MVC", MPEG doc. N10572, MPEG of ISO/IEC JTCl/SC29/WG11, Maui, Hawaii, USA, April 2009.

Сущность изобретения

[0008] В общем, настоящее раскрытие описывает методы для усовершенствования многовидового видео кодирования в системах MPEG-2 (Экспертная группа по движущимся изображениям). Способы настоящего раскрытия в принципе расширяют возможности транспортного уровня MPEG-2, например, MPEG-2 транспортных потоков и потоков программы MPEG-2, относительно многовидового видео кодирования (MVC). Например, способы настоящего раскрытия обеспечивают возможность передачи непоследовательных видов (представлений) видео потока MVC, подлежащего передаче на транспортном уровне. Методы настоящего раскрытия далее обеспечивают возможность того, что подпотоки битов транспортного потока (или программы), каждый, включают в себя непоследовательные виды. Эти методы также позволяют устройству приема, после приема потока транспортного уровня, содержащего множество подпотоков битов, каждый из которых имеет непоследовательные виды, переупорядочивать виды в подпотоках битов таким образом, что транспортный поток упорядочивается должным образом, то есть в возрастающем порядке с точки зрения порядковых индексов видов, так что декодер может должным образом декодировать кадры каждого из видов.

[0009] В одном примере способ содержит формирование, устройством источника, структуры данных для сигнализации, что соответствующий поток битов стандарта MPEG-2 систем содержит первый вид сцены, ассоциированный с первым порядковым индексом вида, и второй вид сцены, ассоциированный с вторым порядковым индексом вида, причем первый порядковый индекс вида и второй порядковый индекс вида являются непоследовательными. Способ также содержит вывод структуры данных, например, передачу структуры данных к устройству назначения или сохранение структуры данных на машиночитаемом носителе.

[0010] В другом примере устройство содержит видео кодер, который кодирует множество видов сцены, мультиплексор, который формирует структуру данных для сигнализации, что соответствующий поток битов стандарта MPEG-2 систем содержит первый вид сцены, ассоциированный с первым порядковым индексом вида, и второй вид сцены, ассоциированный с вторым порядковым индексом вида, причем первый порядковый индекс вида и второй порядковый индекс вида являются непоследовательными, и выходной интерфейс для вывода структуры данных.

[0011] В другом примере устройство содержит средство для формирования, устройством источника, структуры данных для сигнализации, что соответствующий поток битов стандарта MPEG-2 систем содержит первый вид сцены, ассоциированный с первым порядковым индексом вида, и второй вид сцены, ассоциированный с вторым порядковым индексом вида, причем первый порядковый индекс вида и второй порядковый индекс вида являются непоследовательными, и средство для вывода структуры данных.

[0012] В другом примере считываемый компьютером носитель данных закодирован инструкциями, которые побуждают процессор формировать структуру данных для сигнализации, что соответствующий поток битов стандарта MPEG-2 систем содержит первый вид сцены, ассоциированный с первым порядковым индексом вида, и второй вид сцены, ассоциированный с вторым порядковым индексом вида, причем первый порядковый индекс вида и второй порядковый индекс вида являются непоследовательными, и выводить структуру данных.

[0013] В еще одном примере способ содержит формирование, клиентским устройством, потока битов, совместимого со стандартом многовидового видео кодирования (MVC) из принятого потока битов, содержащего основной подпоток битов и вложенный подпоток битов основного подпотока битов, причем формирование потока битов, совместимого со стандартом MVC, содержит определение, имеет ли компонент вида основного подпотока битов порядковый индекс вида, который больше, чем порядковый индекс вида компонента вида вложенного подпотока битов; если порядковый индекс вида компонента вида основного подпотока битов больше, чем порядковый индекс вида компонента вида вложенного подпотока битов, то добавление компонента вида вложенного подпотока битов к формируемому потоку битов, а если порядковый индекс вида компонента вида основного подпоток битов не больше, чем порядковый индекс вида компонента вида вложенного подпотока битов, то добавление компонента вида основного подпотока битов к формируемому потоку битов. Способ далее содержит вывод сформированного потока битов в видео декодер.

[0014] В другом примере устройство содержит приемник, который принимает поток битов, содержащий основной подпоток битов и вложенный подпоток битов основного подпотока битов, демультиплексор, который формирует поток битов, совместимый со стандартом MVC, из принятого потока битов, причем для формирования потока битов, совместимого со стандартом MVC, демультиплексор определяет, имеет ли компонент вида основного подпотока битов порядковый индекс вида, который больше, чем порядковый индекс вида компонента вида вложенного подпотока битов, и добавляет компонент вида вложенного подпотока битов к формируемому потоку битов, когда порядковый индекс вида компонента вида основного подпотока битов больше, чем порядковый индекс вида компонента вида вложенного подпотока битов, и добавляет компонент вида основного подпотока битов к формируемому потоку битов, когда порядковый индекс вида компонента вида основного подпотока битов не больше, чем порядковый индекс вида компонента вида вложенного подпотока битов, и видео декодер, который декодирует поток битов, сформированный демультиплексором.

[0015] В другом примере устройство содержит средство для формирования потока битов, совместимого со стандартом многовидового видео кодирования (MVC) из принятого потока битов, содержащего основной подпоток битов и вложенный подпоток битов основного подпотока битов, средство для определения, имеет ли компонент вида основного подпотока битов порядковый индекс вида, который больше, чем порядковый индекс вида компонента вида вложенного подпотока битов; средство для добавления компонента вида вложенного подпотока битов к формируемому потоку битов, если порядковый индекс вида компонента вида основного подпотока битов больше, чем порядковый индекс вида компонента вида вложенного подпотока битов, и средство для добавления компонента вида основного подпотока битов к формируемому потоку битов, если порядковый индекс вида компонента вида основного подпотока битов не больше, чем порядковый индекс вида компонента вида вложенного подпотока битов, и средство для вывода сформированного потока битов в видео декодер.

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

[0017] Детали одного или более примеров изложены на иллюстрирующих чертежах и в описании, приведенном ниже. Другие признаки, объекты и преимущества будут очевидны из описания и чертежей, а также из формулы изобретения.

Краткое описание чертежей

[0018] Фиг.1 - блок-схема, иллюстрирующая систему в качестве примера, в которой устройство источника аудио/видео (A/V) транспортирует аудио и видео данные к устройству назначения A/V.

[0019] Фиг.2 - блок-схема, иллюстрирующая примерную конфигурацию компонентов мультиплексора.

[0020] Фиг.3 - блок-схема, иллюстрирующая примерный набор таблиц специфической для программы информации.

[0021] Фиг.4 - блок-схема, иллюстрирующая примерный набор данных, которые могут быть включены в дескриптор расширения многовидового видео кодирования (MVC).

[0022] Фиг.5 - блок-схема, иллюстрирующая примерный набор данных, которые могут быть включены в дескриптор иерархии.

[0023] Фиг.6 - концептуальная диаграмма, иллюстрирующая примерный шаблон предсказания MVC.

[0024] Фиг.7 - блок-схема, иллюстрирующая примерный способ посылки потока MPEG-2 систем, имеющего поднабор видов с непоследовательными порядковыми индексами видов, от сервера к клиенту.

[0025] Фиг.8 - блок-схема, иллюстрирующая примерный способ сборки компонентов видов двух или более подпотоков битов, чтобы сформировать поток битов таким образом, что компоненты видов имеют возрастающие порядковые индексы видов.

Подробное описание

[0026] Методы настоящего раскрытия в общем направлены на усовершенствование многовидового видео кодирования (MVC) в MPEG-2 системах, то есть системах, которые соответствуют MPEG-2 относительно деталей транспортного уровня. MPEG-4, например, обеспечивает стандарты для видео кодирования, но в принципе предполагает, что видео кодеры, соответствующие стандарту MPEG-4, будут использовать системы транспортного уровня MPEG-2. Соответственно, методы настоящего раскрытия применимы к видео кодерам, которые соответствуют MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4 или любому другому стандарту кодирования видео, который использует транспортные потоки MPEG-2 и/или потоки программы.

[0027] В частности, методы настоящего раскрытия могут использоваться, чтобы изменять элементы синтаксиса на транспортном уровне для транспортных потоков MPEG-2 и потоков программы. Например, методы настоящего раскрытия включают дескриптор, который передается в транспортном потоке, чтобы специально идентифицировать каждый вид многовидовых видео данных, которые посылаются в транспортном потоке. Серверное устройство, например, может предоставлять различные услуги, каждая из которых содержит соответствующие подмножества конкретных видов многовидового кодирования видео данных, где подмножество видов услуги может быть выбрано на основе приложения, выполняемого клиентским устройством, возможностей декодеров, функционирующих на клиентском устройстве, предпочтений, выраженных клиентским устройством, или других критериев выбора.

[0028] В соответствии с методами настоящего раскрытия, серверное устройство может обеспечить подмножество видов, имеющих непоследовательные порядковые индексы видов. В одном примере серверное устройство конкретно сигнализирует каждый из видов, которые будут включены в транспортный поток, в дескрипторе расширения MVC, который может быть включен в таблицу карты программы (PMT) или карту потока программы (PSM).

[0029] В некоторых примерах серверное устройство может послать множество подпотоков битов в единственном транспортном потоке или потоке программы. Позволяя видам потока битов быть непоследовательными, методы настоящего раскрытия также позволяют порядковым индексам видов, соответствующим видам каждого подпотока битов, быть непоследовательными. Хотя эти методы допускают непоследовательные порядковые индексы видов в каждом подпотоке битов, порядковые индексы видов все еще должны быть возрастающими в подпотоке битов, чтобы соответствовать существующим стандартам потоков битов, например, стандарту MPEG-2 систем. Поскольку виды первого подпотока битов и второго подпотока битов могут, каждый, быть непоследовательными, виды могут поступать на клиентское устройство не в порядке относительно порядковых индексов видов. Методы настоящего раскрытия также позволяют клиентскому устройству обрабатывать такой транспортный поток, чтобы эффективно переупорядочить виды первого подпотока битов и второго подпотока битов, таким образом, что порядковые индексы вида для видов увеличиваются. Комбинации видов, имеющие непоследовательные порядковые индексы видов, могут использоваться для масштабируемости видов, которая может быть полезной для адаптации ширины полосы, эффективности декодера и обеспечения других таких преимуществ. Например, в противоположность обычным методам, которые потребовали бы посылки всех видов на клиентское устройство клиента, и чтобы клиентское устройство декодировало каждый вид, имеющих последовательные порядковые индексы видов, методы настоящего раскрытия позволяют посылать только те виды, которые конкретно требуются клиентскому устройству, даже когда это приводит к видам, имеющим непоследовательные порядковые индексы видов. Таким способом клиентское устройство может принимать только те виды, которые необходимы для конкретной услуги, а не все виды с промежуточными порядковыми индексами видов.

[0030] Хотя в различных разделах настоящего раскрытия могут упоминаться индивидуально “транспортный поток” или “поток программы”, нужно подразумевать, что способы настоящего раскрытия в общем случае применимы к любому или обоим из транспортных потоков MPEG-2 и потоков программы. В общем случае, настоящее раскрытие описывает примерные дескрипторы для выполнения методов настоящего раскрытия. Дескрипторы используются, чтобы расширить функциональность потока. Дескрипторы настоящего раскрытия могут использоваться и транспортными потоками и потоками программы, чтобы осуществить методы настоящего раскрытия.

[0031] Настоящее раскрытие также использует следующие термины и предлагает включить эти термины в версию текущего стандарта систем MPEG-2, вместе с семантикой терминов, как указано:

AVC подпоток битов видео: базовый вид MVC потока битов.

AVC подпоток битов видео MVC: базовый вид MVC потока битов с отбрасыванием префиксных единиц NAL.

Базовый подпоток битов видео MVC: AVC подпоток битов видео или AVC подпоток битов видео MVC.

Поднабор компонентов вида MVC: единицы NAL одного компонента вида.

Поднабор view_id MVC: единицы NAL одного вида.

Подпоток видов видео MVC: единицы NAL не-базовых видов.

[0032] Фиг.1 - блок-схема, иллюстрирующая приведенную для примера систему 10, в который устройство 20 источника аудио/видео (A/V) транспортируют аудио и видео данные к устройству 40 назначения A/V. Система 10 по фиг.1 может соответствовать системе видео телеконференции, системе сервер/клиент, системе службы вещания/приемника или любой другой системе, в которой видео данные посылают из устройства источника, такого как устройство 20 источника A/V, к устройству назначения, такому как устройство 40 A/V назначения. В некоторых примерах устройство 20 источника A/V и устройство 40 назначения A/V могут выполнять двунаправленный информационный обмен. То есть, устройство 20 источника A/V и устройство 40 назначения A/V могут иметь возможность кодирования и декодирования (и передачи и приема) аудио и видео данных. В некоторых примерах аудио кодер 26 может содержать голосовой кодер, также называемый вокодером.

[0033] Устройство 20 источника A/V, в примере фиг.1, содержит источник 22 аудио и источник 24 видео. Источник 22 аудио может содержать, например, микрофон, который формирует электрические сигналы, характеризующие захваченные аудиоданные, которые должны кодироваться аудио кодером 26. Альтернативно, источник 22 аудио может содержать носитель данных, хранящий ранее зарегистрированные аудиоданные, генератор аудиоданных, такой как компьютеризированный синтезатор, или любой другой источник аудиоданных. Источник 24 видео может содержать видеокамеру, которая формирует видеоданные, которые должны кодироваться видео кодером 28, носитель данных, кодированный ранее записанными видеоданными, блок генерации видеоданных, или любой другой источник видеоданных. Исходные аудио- и видеоданные могут содержать аналоговые или цифровые данные. Аналоговые данные могут быть преобразованы в цифровую форму, прежде чем кодироваться аудио кодером 26 и/или видео кодером 28. Источник 22 аудио может получать аудиоданные от говорящего участника, в то время как говорящий участник говорит, и источник 24 видео может одновременно получать видеоданные говорящего участника. В других примерах источник 22 аудио может содержать считываемый компьютером носитель данных, содержащий сохраненные аудиоданные, и источник 24 видео может содержать считываемый компьютером носитель данных, содержащий сохраненные видеоданные. Таким образом, методы, описанные в настоящем раскрытии, могут быть применены к живым (прямого эфира), потоковым аудио- и видеоданным в реальном времени или к заархивированным, записанным заранее аудио- и видеоданным.

[0034] Аудио кадры, которые соответствуют видео кадрам, являются обычно аудио кадрами, содержащими аудиоданные, которые были захвачены источником 22 аудио одновременно с видеоданными, захваченными источником 24 видео, которые содержатся в видео кадрах. Например, в то время как говорящий участник обычным образом формирует аудиоданные, источник 22 аудио захватывает аудиоданные, и источник 24 видео захватывает видеоданные говорящего участника в то же самое время, то есть, когда источник 22 аудио захватывает аудиоданные. Следовательно, аудио кадр может во времени соответствовать одному или более конкретным видео кадрам. Соответственно, аудио кадр, соответствующий видео кадру, в общем случае соответствует ситуации, в которой аудиоданные и видеоданные были захвачены в то же самое время и для которой аудио кадр и видео кадр содержат, соответственно, аудиоданные и видеоданные, которые были захвачены в то же самое время.

[0035] В некоторых примерах аудио кодер 26 может кодировать временную метку в каждом закодированном аудио кадре, которая представляет время, в которое были зарегистрированы аудиоданные для закодированного аудио кадра, и точно так же видео кодер 28 может закодировать временную метку в каждом закодированном видео кадре, которая представляет время, в которое были записаны видеоданные для закодированного видео кадра. В таких примерах аудио кадр, соответствующий видео кадру, может содержать аудио кадр, содержащий временную метку, и видео кадр, содержащий ту же самую временную метку. Устройство 20 источника A/V может содержать внутренние часы, из которых аудио кодер 26 и/или видео кодер 28 могут сформировать временную метку, или источник 22 аудио и источник 24 видео могут использовать ее, чтобы ассоциировать аудио- и видеоданные, соответственно, с временной меткой. В некоторых примерах источник 22 аудио может послать данные в аудио кодер 26 соответственно времени, в которое были записаны аудиоданные, и видео источник 24 может послать данные в видео кодер 28 соответственно времени, в которое были записаны видеоданные. В некоторых примерах аудио кодер 26 может кодировать идентификатор последовательности в кодированных аудиоданных, чтобы указать относительное временное упорядочение кодированных аудиоданных, но без необходимости указания абсолютного времени, в которое были записаны аудиоданные, и точно так же видео кодер 28 может также использовать идентификаторы последовательности, чтобы указать относительное временное упорядочение кодированных видеоданных. Аналогично, в некоторых примерах, идентификатор последовательности может быть отображен или иным образом коррелирован с временной меткой.

[0036] Методы настоящего раскрытия в общем направлены на транспорт кодированных мультимедийных (например, аудио и видео) данных и прием и последующую интерпретацию и декодирование транспортируемых мультимедийных данных. Методы настоящего раскрытия особенно применимы к транспорту данных многовидового видео кодирования (MVC), то есть видеоданных, содержащих множество видов. Как показано в примере Фиг.1, источник 24 видео может предоставить множество видов сцены на видео кодер 28. MVC может быть полезным для генерации трехмерных видеоданных, которые будут использоваться трехмерным устройством отображения, таким как стереоскопический или автостереоскопический трехмерный дисплей.

[0037] Устройство 20 источника A/V может предоставить “услугу” устройству 60 назначения A/V. Услуга в общем случае соответствует подмножеству доступных видов данных MVC. Например, данные MVC могут быть доступными для восьми видов, упорядоченных как от нуля до семи. Одна услуга может соответствовать стерео видео, имеющему два вида, в то время как другая услуга может соответствовать четырем видам, и еще одна услуга может соответствовать всем восьми видам. В общем случае, услуга соответствует любой комбинации (то есть, любому поднабору) доступных видов. Услуга может также соответствовать комбинации доступных видов, а также аудиоданных.

[0038] Устройство 20 источника A/V, в соответствии с методами этого раскрытия, может предоставлять услуги, которые соответствуют поднабору видов, которые включают непоследовательные порядковые индексы видов. В общем случае, вид представлен идентификатором вида, также называемым “view_id”. Идентификаторы вида в общем случае включают элементы синтаксиса, которые могут использоваться, чтобы идентифицировать вид. Кодер MVC обеспечивает view_id вида, когда вид кодируется. view_id может использоваться декодером MVC для межвидового предсказания или другими блоками в других целях, например, для воспроизведения.

[0039] Межвидовое предсказание представляет метод для кодирования видеоданных MVC кадра по отношению к одному или более кадрам в общем временном местоположении как кодированным кадрам различных видов. Фиг.6, которая обсуждена более подробно ниже, представляет пример схемы кодирования для межвидового предсказания. В общем случае кодированный кадр видеоданных MVC может быть предиктивно (с прогнозированием) закодирован по пространству, времени и/или по отношению к кадрам других видов в общем временном местоположении. Соответственно, опорные виды, из которых предсказываются другие виды, в общем случае декодируются перед видами, для которых опорные виды действуют в качестве опоры, так что эти декодированные виды могут использоваться как опора при декодировании ссылающихся видов. Порядок декодирования не обязательно соответствует порядку view_id. Поэтому порядок декодирования видов описан с использованием порядковых индексов видов. Порядковые индексы видов представляют индексы, которые указывают на порядок декодирования соответствующих компонентов вида в единице доступа.

[0040] Каждый отдельный поток данных (аудио или видео) упоминается как элементарный поток. Элементарный поток является одиночным, в цифровой форме кодированным (возможно, сжатым) компонентом программы. Например, кодированная видео или аудио часть программы может быть элементарным потоком. Элементарный поток может быть преобразован в пакетированный элементарный поток (PES), прежде чем мультиплексироваться в поток программы или транспортный поток. В пределах той же самой программы идентификатор потока используется, чтобы отличить пакеты PES, принадлежащие одному элементарному потоку, от других. Базовой единицей данных элементарного потока является пакет пакетированного элементарного потока (PES). Таким образом, каждый вид видеоданных MVC соответствует соответствующим элементарным потокам. Точно так же аудиоданные соответствуют соответствующему элементарному потоку. В примере Фиг.1 мультиплексор 30 получает элементарные потоки, содержащие видеоданные, от видео кодера 28, и элементарные потоки, содержащие аудиоданные, от аудио кодера 26. В некоторых примерах видео кодер 28 и аудио кодер 26 могут каждый содержать формирователи пакетов, чтобы формировать пакеты PES из кодированных данных. В других примерах видео кодер 28 и аудио кодер 26 могут каждый взаимодействовать с соответствующим формирователем пакетов, чтобы формировать пакеты PES из кодированных данных. В других примерах мультиплексор 30 может содержать формирователи пакетов, чтобы формировать пакеты PES из кодированных аудио и видео данных.

[0041] “Программа”, как используется в настоящем раскрытии, может содержать комбинацию аудиоданных и видеоданных, например, элементарный поток аудио и подмножества доступных видов, доставленных услугой устройства 20 источника A/V. Каждый пакет PES содержит идентификатор потока stream_id, который идентифицирует элементарный поток, которому принадлежит пакет PES. Мультиплексор 30 ответственен за сборку элементарных потоков в компонентные потоки программы или транспортные потоки. Поток программы и транспортный поток - это две альтернативы мультиплексирования, нацеленные на различные приложения.

[0042] В общем случае, поток программы состоит из данных для одной программы, в то время как транспортный поток может содержать данные для одной или более программ. Мультиплексор 30 может кодировать любой или оба из потока программы или транспортного потока, основываясь на предоставляемой услуге, среде, в которую поток будет передаваться, числе программ, которые должны посылаться, или других факторах. Например, когда видеоданные должны быть закодированы на носителе данных, мультиплексор 30 может более вероятно формировать поток программы, а когда видео данные должны передаваться потоком по сети, широковещательно передаваться или посылаться как часть видео телефонии, мультиплексор 30 может более вероятно использовать транспортный поток.

[0043] Мультиплексор 30 может сделать выбор в пользу использования потока программы для хранения и отображения единственной программы из услуги цифрового хранения. Поток программы предназначен для использования в не подверженной ошибкам среде или среде, менее восприимчивой к возникающим ошибкам, потому что потоки программы довольно восприимчивы к ошибкам. Поток программы просто содержит элементарные потоки, принадлежащие ему, и обычно содержит пакеты с переменными длинами. В потоке программы PES-пакеты, которые получены из компонентных элементарных потоков, организованы в “пачки”. Пачка содержит заголовок пачки, опциональный системный заголовок и любое число пакетов PES, взятых из любого из компонентных элементарных потоков, в любом порядке. Системный заголовок содержит сводку характеристик потока программы, таких как его максимальная скорость передачи данных, число компонентных видео и аудио элементарных потоков, дополнительная информация синхронизации или другая информация. Декодер может использовать информацию, содержащуюся в системном заголовке, чтобы определить, способен ли декодер декодировать поток программы или нет.

[0044] Мультиплексор 30 может использовать транспортный поток для одновременной доставки множества программ по потенциально подверженным ошибкам каналам. Транспортный поток - это мультиплекс (объединение), предназначенный для многопрограммных приложений, таких как радиовещание, так что единственный транспортный поток может вместить много независимых программ. Транспортный поток содержит последовательность транспортных пакетов, каждый из транспортных пакетов имеет длину 188 байт. Использование коротких пакетов фиксированной длины означает, что транспортный поток менее восприимчив к ошибкам, чем поток программы. Далее, каждому транспортному пакету длиной 188 байтов может быть предоставлена дополнительная защита от ошибок путем обработки пакета посредством стандартного процесса защиты от ошибок, такого как кодирование Рида-Соломона. Улучшенная устойчивость к ошибкам транспортного потока означает, что он имеет лучший шанс выживания в каналах, подверженных ошибкам, имеющихся, например, в среде вещания.

[0045] Могло бы показаться, что транспортный поток явно лучший из двух мультиплексов, с его увеличенной стойкостью к ошибкам и способностью переносить много одновременных программ. Однако транспортный поток является более сложным мультиплексом, чем поток программы, и является, следовательно, более трудным для создания и демультиплексирования. Первый байт транспортного пакета - это байт синхронизации, имеющий значение 0x47 (шестнадцатеричное 47, двоичное 01000111, десятичное 71). Единственный транспортный поток может переносить много различных программ, причем каждая программа содержит много пакетированных элементарных потоков. Мультиплексор 30 может использовать 13-битовое поле Идентификатора Пакета (PID), чтобы отличить транспортные пакеты, содержащие данные одного элементарного потока, от тех, которые несут данные других элементарных потоков. Обязанностью мультиплексора является гарантировать, что каждый элементарный поток снабжен уникальным значением PID. Последний байт транспортного пакета - поле счета непрерывности. Мультиплексор 30 дает приращение значению поля счета непрерывности между последовательными транспортными пакетами, принадлежащими тому же самому элементарному потоку. Это позволяет декодеру или другому блоку устройства назначения, такого как устройство 40 назначения A/V, обнаружить потерю или усиление транспортного пакета и, надо надеяться, скрыть ошибки, которые могли бы иначе быть результатом такого события.

[0046] Мультиплексор 30 получает пакеты PES для элементарных потоков программы от аудио кодера 26 и видео кодера 28 и формирует соответствующие единицы слоя сетевой абстракции (NAL) из пакетов PES. В примере H.264/AVC (усовершенствованное видео кодирование) кодированные видео сегменты организованы в единицы NAL, которые обеспечивают "дружественное для сети" представление видео, адресуемое приложениям, таким как видео телефония, хранение, вещание или потоковая передача. Единицы NAL могут быть категоризированы на единицы NAL слоя видео кодирования (VCL) и единицы NAL не-VCL. Блоки VCL содержат основной механизм сжатия и могут содержать уровни блоков, макроблоков и/или вырезок. Другие единицы NAL являются не-VCL единицами NAL.

[0047] Мультиплексор 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.

[0048] Элемент priority_id заголовка NAL может использоваться для простого процесса адаптации одноканального потока битов. Элемент temporal_id может использоваться для определения временного уровня соответствующей единицы NAL, где различные временные уровни соответствуют различным скоростям кадров. Элемент anchor_pic_flag может указать, является ли картина картиной привязки (опорной картиной) или не-опорной картиной.

[0049] Опорные картины и все картины, следующие за ними в порядке вывода (то есть, порядке отображения), могут быть правильно декодированы без декодирования предыдущих картин в порядке декодирования (то есть, порядке потока битов), и таким образом могут использоваться в качестве точек произвольного доступа. Опорные картины и не-опорные картины могут иметь различные зависимости, которые сигнализируются в наборе параметров последовательности. Другие флаги будут обсуждаться и использоваться в следующих разделах. Такая опорная картина может также упоминаться как открытая точка доступа GOP (группы картин), в то время как закрытая точка доступа GOP также поддерживается, когда элемент non_idr_flag равен нулю. Элемент non_idr_flag указывает, является ли картина картиной мгновенного обновления декодера (IDR) или картиной IDR вида (V-IDR). В общем случае, картина IDR и все картины, следующие за ней в порядке вывода или порядке потока битов, могут быть правильно декодированы без декодирования предыдущих картин в порядке декодирования или в порядке отображения.

[0050] Элемент view_id содержит информацию синтаксиса, которая может использоваться, чтобы идентифицировать вид, который может использоваться для интерактивности данных в декодере MVC, например, для межвидового предсказания, и вне декодера, например, для рендеринга (визуализации). Элемент inter_view_flag может определять, используется ли соответствующая единица NAL другими видами для межвидового предсказания. Чтобы переносить 4-байтовую информацию заголовка единицы NAL для базового вида, которая может быть совместима с AVC, префиксная единица NAL определена в MVC. В контексте MVC единица доступа базового вида содержит VCL NAL единицы текущего момента времени вида, а также его префиксную единицу NAL, которая содержит только головную часть единицы NAL. H.264/AVC декодер может игнорировать префиксную единицу NAL.

[0051] Единица NAL, включающая видео данные в своей полезной нагрузке, может содержать различные уровни гранулярности видеоданных. Например, единица NAL может содержать блок видеоданных, макроблок, множество макроблоков, вырезку (slice) видеоданных или весь кадр видеоданных. Мультиплексор 30 может получить кодированные видеоданные от видео кодера 28 в форме пакетов PES элементарных потоков. Мультиплексор 30 может ассоциировать каждый элементарный поток с соответствующей программой путем отображения идентификаторов потока stream_id на соответствующие программы, например, в базе данных или другой структуре данных, такой как Таблица Карты Программы (PMT) или Карта Потока Программы (PSM).

[0052] Мультиплексор 30 может также собрать единицы доступа из множества единиц NAL. В общем случае, единица доступа может содержать одну или более единиц NAL для представления структуры видеоданных, а также аудиоданных, соответствующих кадру, когда такие аудиоданные доступны. В примере, соответствующем H.264/AVC, единица доступа может содержать кодированную картину в один момент времени, что может быть представлено как основная кодированная картина. Соответственно, единица доступа может содержать все аудио и видео кадры общего момента времени, например, все виды, соответствующие времени X. Настоящее раскрытие также ссылается на кодированную картину конкретного вида как на "компонент вида". Таким образом, компонент вида содержит кодированную картину (или кадр) для конкретного вида в конкретное время. Соответственно, единица доступа может быть определена как содержащая все компоненты вида общего момента времени.

[0053] Мультиплексор 30 может также встраивать данные относительно программы в единице NAL. Например, мультиплексор 30 может создать единицу NAL, содержащую Таблицу Карты Программы (PMT) или Карту Потока Программы (PSM). В общем случае, PMT используется для описания транспортного потока, в то время как PSM используется для описания потока программы. Как описано более подробно относительно примера ФИГ.2 ниже, мультиплексор 30 может содержать или взаимодействовать с модулем хранения данных, который ассоциирует элементарные потоки, полученные от аудио кодера 26 и видео кодера 28, с программами и соответственно с соответствующими транспортными потоками и/или потоками программы.

[0054] Стандарт Систем MPEG-2 учитывает расширения системы посредством “дескрипторов”. PMT и PSM включают циклы дескрипторов, в которые могут быть вставлены один или более дескрипторов. В общем случае, дескриптор содержит структуру, которая может использоваться, чтобы расширить определение программ и/или элементов программ. Настоящее раскрытие описывает два дескриптора для выполнения методов настоящего раскрытия: дескриптор расширения MVC и дескриптор иерархии. В общем случае, дескриптор расширения MVC настоящего раскрытия усиливает обычный дескриптор расширения MVC путем конкретной идентификации порядковых индексов вида для видов, которые включены в поток программы или транспортный поток, в то время как дескриптор иерархии настоящего раскрытия содержит флаг, который указывает, увеличивает ли ассоциированный элемент программы число видов потока битов являющееся результатом элемента программы, на который ссылается элемент дескриптора иерархии.

[0055] Стандарты сжатия видео, такие как ITU-T H.261, H.263, MPEG-I, MPEG-2 и H.264/MPEG-4, часть 10, используют скомпенсированное по движению временное предсказание, чтобы уменьшить временную избыточность. Кодер использует скомпенсированное по движению предсказание из некоторых ранее кодированных картин (также упоминаемых здесь как кадры), чтобы предсказать текущие кодированные картины согласно векторам движения. В типичном видео кодировании есть три главных типа картин. К ним относятся: интра-(«внутри»)кодированная картина (“I-картины” или “I-кадры”), предсказанные картины (“P-картины” или “P-кадры”) и двунаправленные предсказанные картины (“В-картины” или “B-кадры”). P-картины используют только опорную картину перед текущей картиной во временном порядке. В В-картине каждый блок В-картины может быть предсказан из одной или двух опорных картин. Эти опорные картины могут быть расположены перед или после текущей картины во временном порядке.

[0056] В соответствии со стандартом кодирования H.264, в качестве примера, В-картины используют два списка ранее кодированных опорных картин, список 0 и список 1. Эти два списка могут каждый содержать прошлые и/или будущие кодированные картины во временном порядке. Блоки в В-картине могут быть предсказаны одним из нескольких способов: скомпенсированное по движению предсказание из опорной картины списка 0, скомпенсированное по движению предсказание из опорной картины списка 1 или скомпенсированное по движению предсказание из комбинации опорных картин из списка 0 и списка 1. Чтобы получить комбинацию опорных картин из списка 0 и списка 1, две скомпенсированные по движению опорные области получают из опорных картин списка 0 и списка 1 соответственно. Их комбинация будет использоваться, чтобы предсказать текущий блок.

[0057] Стандарт 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” и “на” может использоваться взаимозаменяемым образом при ссылках на измерения в пикселах блока, для вертикальных и горизонтальных измерений, например, 16×16 пикселов или 16 на 16 пикселов. В общем случае, блок 16×16 будет иметь 16 пикселов в вертикальном направлении (y=16) и 16 пикселов в горизонтальном направлении (x=16). Аналогично, блок NxN в общем случае имеет N пикселов в вертикальном направлении и N пикселов в горизонтальном направлении, где N представляет неотрицательное целочисленное значение. Пикселы в блоке могут быть упорядочены в строки и столбцы.

[0058] Размеры блока, которые являются меньшими, чем 16 на 16, могут упоминаться как части “16 на 16” макроблока. Видео блоки могут содержать блоки пиксельных данных в пиксельной области или блоки коэффициентов преобразования в области преобразования, например, следуя применению преобразования, такого как дискретное косинусное преобразование (DCT), целочисленное преобразование, вейвлетное преобразование или концептуально подобное преобразование, к остаточным данным видео блока, представляющим различия в пикселах между кодированными видео блоками и прогнозированными (предиктивными) видео блоками. В некоторых случаях, видео блок может содержать блоки квантованных коэффициентов преобразования в области преобразования.

[0059] Меньшие видео блоки могут обеспечить лучшее разрешение и могут использоваться для определения местоположений видео кадра, которые включают высокие уровни детальности. В общем случае, макроблоки и различные части, иногда называемые подблоками, могут рассматриваться как видео блоки. Кроме того, вырезка (slice) может рассматриваться как множество видео блоков, таких как макроблоки и/или подблоки. Каждая вырезка может быть независимо декодируемой единицей видео кадров. Альтернативно, сами кадры могут быть декодируемыми единицами, или другие части кадра могут быть определены как декодируемые единицы. Термин “кодированная единица” или “единица кодирования” может относиться к любой независимо декодируемой единице видео кадра, такой как весь кадр, вырезка кадра, группа картин (GOP), также называемая последовательностью, или другая независимо декодируемая единица, определенная согласно применимым методам кодирования.

[0060] Термин «макроблок» относится к структуре данных для кодирования картины и/или видео данных согласно двумерному массиву пикселов, который содержит 16×16 пикселов. Каждый пиксел содержит компонент цветности и компонент яркости. Соответственно, макроблок может определить четыре блока яркости, каждый из которых включает двумерный массив 8×8 пикселов, два блока цветности, каждый из которых включает двумерный массив 16x16 пикселов, и заголовок, включающий информацию синтаксиса, такую как шаблон кодированного блока (CBP), режим кодирования (например, режимы кодирования “интра” - (I) или “интер” (P или B), размер части для частей интра-кодированного блока (например, 16×16, 16×8, 8×16, 8×8, 8×4, 4×8 или 4×4) или один или более векторов движения для интер-кодированного макроблока.

[0061] Видео кодер 28, видео декодер 48, аудио кодер 26, аудио декодер 46, мультиплексор 30 и демультиплексор 38 каждый может быть осуществлен как любая из множества подходящих схем кодера или декодера, как применимо, таких как один или более микропроцессоров, процессоров цифрового сигнала (DSP), специализированных интегральных схем (ASIC), программируемых вентильных матрица (FPGA), дискретных логических схем, программное обеспечение, аппаратные средства, программируемое оборудование или любые комбинации указанного. Каждый из видео кодера 28 и видео декодера 48 может быть включен в один или более кодеров или декодеров, любой из которых может быть интегрирован как часть объединенного видео кодера/декодера (кодека). Аналогично, каждый из аудио кодера 26 и аудио декодера 46 может быть включен в один или более кодеров или декодеров, любой из которых может быть интегрирован как часть объединенного аудио кодера/декодера (кодека). Устройство, содержащее видео кодер 28, видео декодер 48, аудио кодер 26, аудио декодер 46, мультиплексор 30 и/или демультиплексор 38, может содержать интегральную схему, микропроцессор и/или устройство беспроводной связи, такое как мобильный телефон.

[0062] Способы настоящего раскрытия могут обеспечить определенные преимущества перед обычными методами для MVC подпотоков битов, которые не поддерживают характеристики сигнализации для некоторых операционных точек. В отличие от обычных методов, элементы синтаксиса и семантика дополнительного дескриптора MVC настоящего раскрытия допускают значения порядковых индексов непоследовательных видов, таким образом, позволяя поддерживать поток битов или подпоток битов, соответствующий MVC и со значениями порядковых индексов видов, которые являются непоследовательными. Настоящее раскрытие также предлагает дескриптор иерархии для сигнализации усовершенствования вида, что позволяет декодеру определить, что MVC подпоток битов основывается на других видах, для успешного декодирования.

[0063] Чтобы обеспечить лучшую поддержку сигнализации характеристик, значения порядкового индекса вида, как сигнализируется в предложенном дескрипторе расширения MVC, могут опционально быть непоследовательными. Кроме того, значения порядкового индекса вида или значения view_id могут быть сигнализированы в дескрипторе расширения MVC.

[0064] Как альтернатива, может использоваться механизм переотображения порядкового индекса вида, который отображает значения порядкового индекса вида для видов соответствующего 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 имеет последовательные порядковые индексы видов.

[0065] Дополнительно, чтобы избежать дублирований префиксной единицы NAL, когда присутствует AVC подпоток битов видео MVC, настоящее раскрытие предлагает, что должен быть определен префиксный подпоток битов MVC и что в некоторых примерах такой префиксный подпоток битов MVC включается, когда имеется по меньшей мере один подпоток битов MVC. Кроме того, настоящее раскрытие предлагает, что специфические для MVC сообщения SEI, то есть сообщения SEI, которые определены в Приложении H спецификации AVC, принадлежащие в базовому виду, или MVC SEI сообщения, применимые для всех видов потока битов MVC, могут быть ассоциированы в рамках этого “префиксного подпотока битов MVC”, чтобы обеспечить эффективное хранение и транспорт с точки зрения размера хранения или оптимизации ширины полосы. Настоящее раскрытие также предлагает, что та же самая идея может быть применена к транспорту масштабируемого видео в MPEG-2 системах, также упоминаемому в контексте Поправки 3 к стандарту “Информационная технология - родовое кодирование движущихся изображений и ассоциированной аудио информации: Системы” (в настоящем раскрытии упоминается как “MPEG-2 Системы” или “стандарт MPEG-2 Систем”).

[0066] После того как мультиплексор 30 выполнил сбор единицы NAL и/или единицы доступа из полученных данных, мультиплексор 30 передает эту единицу на выходной интерфейс 32 для вывода. Выходной интерфейс 32 может содержать, например, передатчик, приемопередатчик, устройство для записи данных на считываемый компьютером носитель, такой как, например, накопитель на оптических дисках, накопитель на магнитных носителях (например, накопитель на гибких дисках), порт универсальной последовательной шины (USB), сетевой интерфейс, или другой выходной интерфейс. Выходной интерфейс 32 выводит единицу NAL или единицу доступа на считываемый компьютером носитель 34, такой как, например, сигнал передачи, магнитный носитель, оптический носитель, память, флэш-память или другой считываемый компьютером носитель.

[0067] В конечном счете, входной интерфейс 36 извлекает данные из считываемых компьютером носителей 34. Входной интерфейс 36 может содержать, например, накопитель на оптических дисках, накопитель на магнитных носителях, USB порт, приемник, приемопередатчик или другой интерфейс считываемого компьютером носителя. Входной интерфейс 36 может предоставить единицу NAL или единицу доступа на демультиплексор 38. Демультиплексор 38 может демультиплексировать транспортный поток или поток программы на компонентные потоки PES, распаковывать потоки PES, чтобы восстановить кодированные данные, и послать кодированные данные в аудио декодер 46 или в видео декодер 48, в зависимости от того, являются ли кодированные данные частью аудио или видео потока, например, как указано заголовками пакетов PES потока. Аудио декодер 46 декодирует кодированные аудиоданные и посылает декодированные аудиоданные на аудио выход 42, в то время как видео декодер 48 декодирует кодированные видеоданные и посылает декодированные видеоданные, которые могут содержать множество видов потока, на видео выход 44. Видео выход 44 может содержать устройство отображения, которое использует множество видов сцены, например, стереоскопический или автостереоскопический дисплей, который представляет каждый вид сцены одновременно.

[0068] Кроме того, демультиплексор 38 может переупорядочивать виды из одного или более подпотоков битов, так что порядковые индексы видов потока имеют строго увеличивающийся порядок, например, когда по меньшей мере один вид вложенного подпотока битов имеет вид с порядковым индексом вида, который меньше, чем порядковый индекс вида для вида основного подпотока битов, в который включен вложенный подпоток битов. Таким способом устройство 40 назначения A/V может соответствовать устройству, содержащему демультиплексор, который формирует поток битов, совместимый со стандартом MVC, из полученного потока битов.

[0069] На Фиг.2 показана блок-схема, иллюстрирующая примерную конфигурацию компонентов мультиплексора 30 (Фиг.1). В примере фиг.2 мультиплексор 30 содержит блок 60 управления потоком, входной интерфейс 80 видео, входной интерфейс 82 аудио, выходной интерфейс 84 мультиплексированного потока и таблицу 88 специфической для программы информации. Блок 60 управления потоком содержит формирователь 62 единицы NAL, формирователь PMT 64, блок 66 поиска идентификатора потока (ID потока) и блок 68 назначения идентификатора программы (PID).

[0070] В примере фиг.2, входной интерфейс 80 видео и входной интерфейс 82 аудио включают соответствующие формирователи пакетов для формирования единиц PES из кодированных видеоданных и кодированных аудиоданных. В других примерах видео и/или аудио формирователи пакетов могут быть внешними для мультиплексора 30. Относительно примера фиг.2, входной интерфейс 80 видео может формировать пакеты PES из кодированных видеоданных, полученных от видео кодера 28, и входной интерфейс 82 аудио может формировать пакеты PES из кодированных аудиоданных, полученных от аудио кодера 26.

[0071] Блок 60 управления потоком получает пакеты PES от входного интерфейса 80 видео и входного интерфейса 82 аудио. Каждый пакет PES содержит идентификатор потока, идентифицирующий элементарный поток, которому принадлежит пакет PES. Блок 66 поиска идентификатора потока может определить программу, которой соответствует пакет PES, путем запроса таблиц 88 специфической для программы информации. Таким образом, блок 60 управления потоком может определить, какой программе соответствует полученный пакет PES. Каждая программа может содержать множество элементарных потоков, в то время как в общем случае, один элементарный поток соответствует только одной программе. Однако, в некоторых примерах, элементарный поток может быть включен во множество программ. Каждый пакет PES может быть включен во множество потоков, выводимых из мультиплексора 30, так как различные услуги могут содержать, каждая, различные поднаборы доступных аудио и видео потоков. Соответственно, блок 66 поиска идентификатора потока может определить, должен ли пакет PES быть включен в один или более выходных потоков (например, один или более транспортных потоков или потоков программы), и, в частности, в какой из выходных потоков включать пакет PES.

[0072] В одном примере каждый элементарный поток соответствует программе. Мультиплексор 30 может быть ответственным за обеспечение, что каждый элементарный поток ассоциирован с конкретной программой и, соответственно, идентификатором программы (PID). Когда принят пакет PES, включающий идентификатор пакета, который не распознан мультиплексором 30 (например, идентификатор потока не сохранен в таблице 88 специфической для программы информации), блок 68 назначения идентификатора программы создает одну или более новых записей в таблице 88 специфической для программы информации, чтобы ассоциировать новый идентификатор потока с неиспользованным PID.

[0073] После определения программы, которой соответствует пакет PES, формирователь 62 единицы NAL формирует единицу NAL, содержащую пакет PES, например, инкапсулируя пакет PES с заголовком единицы NAL, включая PID программы, которой соответствует идентификатор потока пакета PES. В некоторых примерах формирователь 62 единицы NAL или другой блок 60 управления потоком может сформировать единицу доступа, содержащую множество единиц NAL.

[0074] Формирователь 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.

[0075] Выходной интерфейс 84 мультиплексированного потока может получить одну или более единиц NAL и/или единиц доступа от блока 60 управления потоком, например, единицы NAL, включающие пакеты PES (например, аудио- или видеоданные), и/или единицы NAL, включающие PMT. В некоторых примерах выходной интерфейс 84 мультиплексированного потока может сформировать единицы доступа из одной или более единиц NAL, соответствующих общему временному местоположению, после того как единицы NAL приняты от блока 60 управления потоком. Выходной интерфейс 84 мультиплексированного потока передает единицы NAL или единицы доступа как выход в соответствующем транспортном потоке или потоке программы.

[0076] На фиг.3 показана блок-схема, иллюстрирующая примерный набор таблиц 88 специфической для программы информации. Элементарный поток, которому принадлежит транспортный пакет, может быть определен на основе значения PID транспортного пакета. Для того чтобы декодер должным образом декодировал полученные данные, декодер должен быть в состоянии определить, какие элементарные потоки принадлежат каждой программе. Специфическая для программы информация, как включено в таблицу 88 специфической для программы информации, может явно определять отношения между программами и компонентными элементарными потоками. В примере фиг.3 таблицы 88 специфической для программы информации включают таблицу 100 сетевой информации, таблицу 102 условного доступа, таблицу 104 доступа к программе и таблицу 106 карты программы. Для примера фиг.3 предполагается, что выходной поток содержит транспортный поток MPEG-2. В альтернативном примере выходной поток может содержать поток программы, и в этом случае таблица 106 карты программы может быть заменена картой потока программы.

[0077] Спецификация Систем MPEG-2 определяет, что каждая программа, переносимая в транспортном потоке, имеет таблицу карты программы, такую как таблица 106 карты программы, ассоциированная с ней. Таблица 106 карты программы может содержать детали о программе и элементарных потоках, которые содержит программа. В качестве примера, программа, идентифицированная как программа номер 3, может содержать элементарный поток видео с PID 33, поток PID 57 и поток аудио с PID 60. Для PMT разрешается содержать более чем одну программу.

[0078] Базовая таблица карты программы, определенная спецификацией систем MPEG-2, может быть снабжена некоторыми из множества дескрипторов, например, дескрипторами 108, определенными в спецификации систем MPEG-2. Дескрипторы 108 могут содержать любые или все из определенных дескрипторов спецификации систем MPEG-2. В общем случае, дескрипторы, такие как дескрипторы 108, передают дополнительную информацию о программе или ее компонентных элементарных потоках. Дескрипторы могут содержать параметры кодирования видео, параметры кодирования аудио, языковую идентификацию, информацию панорамирования и сканирования, детали условного доступа, информацию об авторском праве или другую такую информацию. Вещательная станция или другой пользователь могут определить дополнительные частные дескрипторы.

[0079] Настоящее раскрытие использует два дескриптора, чтобы позволить переносить непоследовательные порядковые индексы видов в выходном потоке, таком как транспортный поток или поток программы. Как показано на фиг.2, два дескриптора этого раскрытия включают дескриптор 110 расширения MVC и дескриптор 112 иерархии. В связанных с видео компонентных элементарных потоках также имеется дескриптор иерархии, который предоставляет информацию, чтобы идентифицировать элементы программы, содержащие компоненты иерархически кодированного видео, аудио и частных потоков.

[0080] В примере, в котором выход мультиплексора 30 содержит поток программы, таблицы 88 специфической для программы информации могут содержать карту потока программы (PSM). PSM может обеспечить описание элементарных потоков в соответствующем потоке программы и соотношения элементарных потоков друг к другу. В некоторых примерах карта потока программы может также соответствовать транспортному потоку. При переносе в соответствующем транспортном потоке, структура PSM не должна изменяться. Мультиплексор 30 может указать, что PSM присутствует в пакете PES, устанавливая значение view_id пакета PES на 0×BC, то есть, шестнадцатеричное значение ВС, которое соответствует двоичному значению 10111100 или десятичному значению 188.

[0081] Мультиплексор 30 поддерживает полный список всех программ, доступных в транспортном потоке, в таблице 104 ассоциации программ. Мультиплексор 30 также может включать таблицы ассоциации программы в единицы NAL. Мультиплексор 30 может указать, что единица NAL содержит таблицу ассоциации программ, путем назначения единице NAL значения PID, равного 0. Мультиплексор 30 может перечислить каждую программу, вместе со значением PID транспортных пакетов, которые содержит соответствующая таблица карты программы, в таблице 104 ассоциации программ. Для упомянутого выше примера, примерная таблица карты программы, которая определяет элементарные потоки программы номер 3, имеет PID 1001, а другая PMT имеет другой PID 1002. Этот набор информации может быть включен в таблицу 104 ассоциации программ.

[0082] Таблица сетевой информации (NIT) и таблица условного доступа (CAT): Программа номер нуль, определенная в РАТ, имеет специальное значение. В частности, программа номер нуль используется для указания пути к таблице сетевой информации. Таблица является опциональной и, если присутствует, предназначена, чтобы предоставлять информацию о физической сети, несущей транспортный поток, такую как частоты каналов, детальные особенности спутникового приемоответчика, характеристики модуляции, источник услуг, имя услуг и детали альтернативных доступных сетей.

[0083] Если какие-либо элементарные потоки в транспортном потоке скремблируются, то должна присутствовать таблица условного доступа. Таблица обеспечивает детали используемой системы скремблирования и обеспечивает значения PID транспортных пакетов, которые содержат информацию управления и предоставления права в отношении условного доступа. Формат этой информации не определен в рамках MPEG-2.

[0084] На фиг.4 показана блок-схема, иллюстрирующая примерный набор данных, которые могут быть включены в дескриптор расширения MVC 110. В примере фиг.4 дескриптор 110 расширения MVC содержит поле 120 тега дескриптора, поле 122 длины дескриптора, поле 124 средней битовой скорости, поле 126 максимальной битовой скорости, зарезервированное поле 128, поле 130 начала временного идентификатора, поле 132 конца временного идентификатора, поле 134 отсутствия единиц NAL дополнительной информации расширения (SEI), одно или более полей 136 порядкового индекса вида и одно или более полей 138 зарезервированных замыкающих битов. Дескриптор 110 расширения MVC также определяет операционную точку, которая соответствует подпотоку битов MVC. Битовые глубины полей дескриптора 110 расширения MVC ниже соответствуют одному примеру для дескриптора расширения MVC. Другие примеры могут содержать другие битовые глубины, значения или диапазоны, чтобы индивидуально сигнализировать каждый порядковый индекс вида каждого вида, включенного в соответствующий поток битов или подпоток битов.

[0085] Поле 120 тега дескриптора соответствует восьмибитовому полю тега дескриптора, которое включено в каждый дескриптор, как установлено стандартом MPEG-2 Систем, чтобы конкретно идентифицировать дескриптор. Стандарт MPEG-2 Систем определяет определенные теги дескрипторов и маркирует другие значения тегов дескрипторов, например, значения 36-63, как “зарезервированные”. Способы настоящего раскрытия предлагают устанавливать значение поля 120 тега дескриптора для дескриптора 110 расширения MVC на “49”, что соответствует одному из зарезервированных тегов дескриптора, как определено в спецификации MPEG-2 Систем.

[0086] Поле 122 длины дескриптора соответствует восьмибитовому полю длины дескриптора, которое также включено в каждый дескриптор, как указано стандартом MPEG-2 Систем. Мультиплексор 30 может установить значение поля 122 длины дескриптора равным числу байтов дескриптора 110 расширения MVC непосредственно после поля 122 длины дескриптора. Поскольку дескриптор 110 расширения MVC может содержать переменную длину, например, на основе числа порядковых индексов вида 136, включенного в конкретный экземпляр дескриптора 110 расширения MVC, мультиплексор 30 вычисляет размер экземпляра дескриптора 110 расширения MVC и устанавливает значение поля 122 длины дескриптора экземпляра дескриптора соответственно.

[0087] Поле 124 средней битовой скорости содержит шестнадцатибитовое поле, которая указывает среднюю битовую скорость, в килобитах в секунду, повторно собранного видео потока AVC. Таким образом, поле 124 средней битовой скорости описывает среднюю битовую скорость для видео потока, когда видео поток собран от составных частей транспортного потока или потока программы, которому соответствует дескриптор 110 расширения MVC. В некоторых примерах мультиплексор 30 может установить значение поля 124 средней битовой скорости в нуль для указания, что средняя битовая скорость не указана дескриптором 110 расширения MVC.

[0088] Поле 126 максимальной битовой скорости содержит шестнадцатибитовое поле, которая указывает максимальную битовую скорость, в килобитах в секунду, повторно собранного видео потока AVC. Таким образом, поле 126 максимальной битовой скорости описывает максимальную битовую скорость для видео потока, когда видео поток собран из составных частей транспортного потока или потока программы, которому соответствует дескриптор 110 расширения MVC. В некоторых примерах мультиплексор 30 может установить значение поля 126 максимальной битовой скорости в нуль для указания, что максимальная битовая скорость не указана дескриптором 110 расширения MVC.

[0089] Поле 130 начала временного идентификатора содержит трехбитовое поле, которое указывает минимальное значение temporal_id элемента синтаксиса заголовка единицы NAL всех единиц NAL, содержащихся в ассоциированном подпотоке битов видео MVC. Таким образом, значение временного идентификатора включено в заголовок для каждой единицы NAL. В общем случае, значение временного идентификатора соответствует конкретной скорости кадров, где относительно большие значения временного идентификатора соответствуют более высоким скоростям кадров. Например, значение '0' для временного идентификатора может соответствовать скорости кадров 15 кадров в секунду (к/с), значение '1' для временного идентификатора может соответствовать скорости кадров 30 к/с. Таким способом, сбор всех картин, имеющих временной идентификатор 0, в этом примере, в набор, может использоваться, чтобы сформировать видео сегмент, имеющий скорость кадров 15 к/с, а сбор всех картин, имеющих временной идентификатор 0, и всех картин, имеющих временной идентификатор 1, в другой набор, может использоваться, чтобы сформировать другой видео сегмент, имеющий скорость кадров 30 к/с. Мультиплексор 30 определяет наименьший временной идентификатор всех единиц NAL подпотока битов видео MVC и устанавливает значение поля 130 начала временного идентификатора равным этому определенному наименьшему значению временного идентификатора.

[0090] Поле 132 конца временного идентификатора содержит трехбитовое поле, которое указывает максимальное значение временного идентификатора элемента синтаксиса заголовка единицы NAL всех единиц NAL, содержащихся в ассоциированном подпотоке битов видео MVC. Соответственно, мультиплексор 30 определяет наибольший временной идентификатор всех единиц NAL подпотока битов видео MVC и устанавливает значение поля 130 начала временного идентификатора равным этому определенному наибольшему значению временного идентификатора.

[0091] Поле 134 отсутствия единиц NAL дополнительной информации расширения (SEI) содержит однобитовый флаг, который, когда установлен в '1', указывает, что никакие единицы NAL дополнительной информации расширения не присутствует в ассоциированном подпотоке битов видео. Мультиплексор 30 может определить, помещены ли одна или более единиц NAL дополнительной информации расширения в поток битов, и установить значение поля 134 отсутствия единиц NAL дополнительной информации расширения (SEI) в значение '1', когда нет никаких SEI NAL единиц в потоке битов, но может установить значение поля 134 отсутствия единиц NAL дополнительной информации расширения (SEI) в значение '0', когда по меньшей мере одна SEI NAL единица присутствует в потоке битов.

[0092] В одном аспекте, способы настоящего раскрытия описывают модификацию обычных дескрипторов расширения MVC, чтобы включать одно или более полей 136 порядкового индекса вида, представленных с использованием цикла, как показано в Таблице 1 ниже. Каждое из полей 136 порядкового индекса вида содержит 10-битовое поле, которое указывает значение порядкового индекса вида соответствующей одной из единиц NAL, содержащихся в ассоциированном подпотоке битов видео MVC. Мультиплексор 30 может установить значение полей 136 порядкового индекса вида согласно порядковым индексам вида для видов, включенных в подпоток битов видео MVC. Кроме того, значения полей 136 порядкового индекса вида могут сигнализироваться в порядке возрастания. Этим способом дескриптор 110 расширения MVC может описать непоследовательные порядковые индексы вида для видов, включенных в подпоток битов видео MVC.

[0093] В примере фиг.4, дескриптор 110 расширения MVC также содержит поля 138 зарезервированных замыкающих битов. Настоящее раскрытие описывает резервирование этих битов для будущей цели, не определяя, как эти значения должны обязательно использоваться. В различных примерах зарезервированные замыкающие биты могут быть представлены как единственный, непрерывный зарезервированный сохраненный сегмент битов дескриптора расширения MVC 110, или как цикл по множеству отдельных битов.

[0094] Таблица 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 Систем, содержит первый вид сцены, ассоциированный с первым порядковым индексом вида, и второй вид сцены, ассоциированный со вторым порядковым индексом вида, причем первый порядковый индекс вида и второй порядковый индекс вида непоследовательны.

[0095] В другом примере зарезервированные замыкающие биты могут вместо этого индивидуально сигнализироваться. Таблица 2 ниже иллюстрирует пример дескриптора расширения MVC, который сигнализирует каждый из зарезервированных замыкающих битов индивидуально.

[0096] На фиг.5 показана блок-схема, иллюстрирующая примерный набор данных, которые могут быть включены в дескриптор 112 иерархии. В примере фиг.5 дескриптор 112 иерархии содержит поле 150 тега дескриптора, поле 152 длины дескриптора, поле 154 флага усиления вида, поле 156 флага временной масштабируемости, поле 158 флага пространственной масштабируемости, поле 160 флага масштабирования качества, поле 162 типа иерархии, зарезервированное поле 164, поле 166 индекса слоя иерархии, поле 168 флага присутствия TREF, зарезервированное поле 170, поле 172 индекса вложенного слоя иерархии, зарезервированное поле 174 и поле 176 канала иерархии. Чтобы улучшить сигнализацию, масштабируемость вида и/или отношение зависимости видов, способы настоящего раскрытия могут обеспечить, что один флаг сигнализируется в дескрипторе иерархии, который указывает, увеличивает ли ассоциированный элемент программы число видов потока битов, следующее из элемента программы, на который ссылается индекс слоя вложенной иерархии.

[0097] Как отмечено выше, спецификация MPEG-2 Систем определяет, что каждый дескриптор содержит поле тега дескриптора и поле длины дескриптора. Соответственно, дескриптор 112 иерархии 112 содержит поле 150 тега дескриптора и поле 152 длины дескриптора. В соответствии со спецификацией MPEG-2 Систем, мультиплексор 30 может установить значение поля 150 тега дескриптора в значение “4” для дескриптора 112 иерархии 112.

[0098] Длина дескриптора 112 иерархии может быть определена априорно, потому что каждый экземпляр дескриптора 112 иерархии должен содержать тот же самый объем данных. В одном примере, относительно Таблицы 3, приведенной ниже, мультиплексор 30 может установить значение поля 152 длины дескриптора в значение 32, указывающее число битов в экземпляре дескриптора 112 иерархии, после конца поля 152 длины дескриптора.

[0099] Способы настоящего раскрытия предлагают добавить поле 154 флага усиления вида к обычному дескриптору иерархии. В соответствии с методами этого раскрытия, поле 154 флага усиления вида может содержать однобитовый флаг, который, когда установлен в '0', указывает, что ассоциированный элемент программы увеличивает число видов битового потока, следующих из элемента программы, на который ссылается индекс слоя вложенной иерархии. Способы настоящего раскрытия также предлагают резервирование значения '1' для поля 154 флага усиления вида.

[00100] Поле 162 типа иерархии описывает иерархическое отношение между ассоциированным слоем иерархии и его вложенным слоем иерархии. В одном примере, мультиплексор 30 устанавливает значение поля 162 типа иерархии на основе иерархического отношения, например, как описано Таблицей 4, приведенной ниже. В качестве примера, когда масштабируемость применяется больше чем в одном измерении, мультиплексор 30 может установить поле 162 типа иерархии в значение “8” (“Объединенная Масштабируемость” как показано в таблице 4), и мультиплексор 30 устанавливает значения поля 156 флага временной масштабируемости, поля 158 флага пространственной масштабируемости и поля 160 флага масштабируемости качества согласно данным, извлеченным из пакетов PES и заголовков пакетов PES соответствующих потоков. В общем случае, мультиплексор 30 может определить зависимости между различными потоками, соответствующими различным видам и/или потокам аудиоданных. Мультиплексор 30 может также определить, является ли зависимый поток, который содержит слой расширения, пространственным слоем, слоем улучшения отношения сигнал/шум (SNR), слоем повышения качества или другим типом слоя расширения.

[00101] В качестве другого примера, для подпотока битов видео 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'.

[00102] Поле 166 индекса слоя иерархии может содержать шестибитовое поле, которое определяет уникальный индекс ассоциированного элемента программы в таблице иерархий слоев кодирования. Индексы могут быть уникальными в пределах единственного определения программы. Для подпотока битов видео AVC, потоков видео, соответствующих одному или более профилям, определенным в Приложении G ITU-T Rec. H.264 | ISO/IEC 14496-10, это индекс элемента программы, который назначен таким образом, что порядок потока битов будет корректным, если ассоциированные представления зависимости SVC подпотоков битов видео той же самой точки доступа повторно компонуются в увеличивающемся порядке индекса слоя иерархии. Для подпотоков битов видео MVC потоков видео AVC, соответствующих одному или более профилям, определенным в Приложении H ITU-T Rec. H.264 | ISO/IEC 14496-10, это индекс элемента программы, который назначен таким образом, что любое из этих значений больше, чем значение индекса слоя иерархии (hierarchy_layer_index), определенное в дескрипторе иерархии для префиксного подпотока битов MVC.

[00103] Поле 172 индекса вложенного слоя иерархии может содержать шестибитовое поле, которое определяет индекс таблицы иерархии элемента программы, к которому нужно получить доступ, прежде чем декодировать элементарный поток, ассоциированный с соответствующим экземпляром дескриптора 112 иерархии. Настоящее раскрытие оставляет значение для поля 172 индекса вложенного слоя иерархии неопределенным для случая, когда поле 162 типа иерархии 162 имеет значение 15 (то есть, значение, соответствующее базовому слою).

[00104] Поле 176 канала иерархии может содержать шестибитовое поле, которое указывает номер предусмотренного канала для ассоциированного элемента программы в упорядоченном наборе каналов передачи. Наиболее надежный канал передачи определен самым низким значением поля 176 канала иерархии, относительно полного определения иерархии передачи. Отметим, что данный канал иерархии может в то же самое время быть назначен нескольким элементам программы.

[00105] Зарезервированные поля 164, 170 и 174 зарезервированы для будущего использования будущим развитием стандартов. Способы настоящего раскрытия не предлагают в настоящее время присваивать семантическое значение значениям зарезервированных полей 164, 170 и 174.

[00106] Поле 168 флага присутствия опорной временной метки (TREF) является однобитовым полем, которое указывает, присутствует ли поле TREF в соответствующем заголовке пакета PES. Поле TREF в пакете PES является 33-битовым числом, кодированным в трех отдельных полях. Поле TREF указывает значение времени декодирования в системном целевом декодере, как указано посредством DTS или, в отсутствие DTS, посредством PTS заголовка PES той же самой j-ой единицы доступа в соответствующем элементарном потоке n.

[00107] Таблица 3 ниже описывает элементы синтаксиса дескриптора 112 иерархии настоящего раскрытия. Таблица 3 также обеспечивает, для каждого элемента синтаксиса, число битов, используемых для представления элемента синтаксиса, и мнемонику, описывающую тип для элемента синтаксиса. Число битов соответствует числу битов, которые выделены соответствующему элементу синтаксиса, когда дескриптор 112 иерархии передается в кодированном потоке битов. Мнемоника используется в стандарте MPEG-2 Систем, чтобы описывать различные типы данных, которые используются в кодированном потоке битов. Мнемоника, используемая в настоящем раскрытии, содержит “uimsbf”, который стандарт MPEG-2 Систем определяет как целое число без знака, имеющее старший бит сначала, и “bslbf”, который стандарт MPEG-2 Систем определяет как битовую строку с левым битом сначала, где "левый" является порядком, в котором битовые строки записываются в стандарте MPEG-2 Систем. Каждый из элементов синтаксиса в примере Таблицы 3 соответствует соответствующему одному из элементов синтаксиса, описанных выше относительно дескриптора 112 иерархии.

[00108] Таблица 4 ниже описывает различные возможные значения для поля 162 типа иерархии дескриптора 112 иерархии, а также описание для каждого значения. Настоящее раскрытие предлагает добавить возможное значение “14” для поля 162 типа иерархии, которое содержит описание “Префиксного подпотока битов MVC” как описание соответствующего потока битов. Способы настоящего раскрытия определяют префиксный подпоток битов MVC, чтобы содержать все префиксные единицы NAL с nal_unit_type (то есть, значение типа единицы NAL) равным 20, и ассоциированные не-VCL NAL единицы, которые, после повторной сборки с AVC видео подпотоком битов MVC, соответствует одному или более профилям, определенным в Приложении H ITU-T Rec. H.264 | ISO/IEC 14496-10. Способы настоящего раскрытия также предлагают, что когда присутствует AVC видео подпоток битов MVC, префиксный подпоток битов MVC должен также присутствовать.

[00109] В некоторых примерах дескриптор 112 иерархии может использоваться, чтобы сигнализировать подпоток битов MVC, сигнализированный инкрементным подпотоком битов и вложенными подпотоками битов. Вложенные подпотоки битов включают непосредственно зависимый подпоток битов, соответствующий индексу вложенного слоя иерархии, и все вложенные подпотоки битов этого непосредственно зависимого подпотока битов. В настоящем раскрытии виды, которые содержатся явно, называются видами усиления, в то время как виды, которые вложены, называются зависимыми видами.

[00110] На фиг.6 представлена концептуальная диаграмма, иллюстрирующая примерный шаблон предсказания MVC. В примере ФИГ.6 проиллюстрированы восемь видов (имеющие идентификаторы вида от “S0” до “S7”), и двенадцать временных местоположений (от “Т0” до “Т11”) проиллюстрированы для каждого вида. Таким образом, каждая строка на фиг.6 соответствует виду, в то время как каждый столбец указывает на временное местоположение.

[00111] Хотя MVC имеет так называемый базовый вид, который является декодируемым декодерами H.264/AVC, и стерео пара видов также могла бы поддерживаться посредством MVC, преимущество MVC состоит в том, что оно может поддерживать пример, который использует больше чем два вида в качестве трехмерного (3D) видео входа и декодирует это 3D видео, представленное множественными видами. Рендерер клиента, имеющего декодер MVC, может ожидать 3D видео контент с множественными видами.

[00112] Кадры на фиг.6 обозначены при указании каждой строки и столбца на фиг.6 с использованием заштрихованного блока с буквой, обозначающей, является ли соответствующий кадр интра-кодированным (то есть, I-кадр) или интер-кодированным в одном направлении (то есть, P-кадр) или во множестве направлений (то есть, B-кадр). В общем случае, предсказания обозначены стрелками, где указываемый кадр использует исходный объект (откуда исходит указание стрелкой) в качестве опорного для предсказания. Например, P-кадр вида S2 во временном местоположении Т0 предсказан из I-кадра вида S0 во временном местоположении Т0.

[00113] Как при одновидовом кодировании видео, кадры видео последовательности многовидового кодирования видео, могут предиктивно кодироваться относительно кадров в различных временных местоположениях. Например, b-кадр вида S0 во временном местоположении T1, имеет стрелку, указывающую на него из I-кадра вида S0 во временном местоположении, указывая, что b-кадр предсказан из I-кадра. Дополнительно, однако, в контексте многовидового кодирования видео, кадры могут предсказываться межвидовым способом. Таким образом, компонент вида может использовать компоненты вида в других видах в качестве опоры. В MVC, например, межвидовое предсказание реализуется, как если бы компонент вида в другом виде был опорой для интер-предсказания. Потенциальные межвидовые опоры сигнализируются в расширении Набора Параметров Последовательности (SPS) MVC и могут быть модифицированы процессом формирования списка опорных картин, что обеспечивает возможность гибкого упорядочивания опор для интер-предсказания и межвидового предсказания. Таблица 5 ниже обеспечивает примерное определение набора параметров последовательности расширения MVC.

[00114] Фиг.6 обеспечивает различные примеры межвидового предсказания. Кадры вида S1, в примере фиг.6, проиллюстрированы как предсказываемые из кадров в различных временных местоположениях вида S1, а также как предсказываемые межвидовым образом из кадров видов S0 и S2 в тех же самых временных местоположениях. Например, b-кадр вида S1 во временном местоположении T1 предсказан из каждого из B-кадров вида S1 во временных местоположениях Т0 и T2, а также b-кадров видов S0 и S2 во временном местоположении T1.

[00115] В примере фиг.6 заглавная буква “B” и строчная буква “b” предназначены, чтобы указывать на различные иерархические отношения между кадрами, а не на различные методологии кодирования. В общем случае, “B”-кадры относительно выше в иерархии предсказания, чем “b”-кадры. Фиг.6 также иллюстрирует изменения в иерархии предсказания с использованием разных уровней штриховки, где кадры с большей степенью штриховки (то есть, относительно более темные) выше в иерархии предсказания, чем кадры с меньшей степенью штриховки (то есть, относительно светлые). Например, все I-кадры на фиг.6 проиллюстрированы с полной штриховкой, в то время как P-кадры имеют несколько более светлую штриховку, а B-кадры (и b-кадры) имеют различные уровни штриховки относительно друг друга, но всегда светлее, чем штриховка P-кадров и I-кадров.

[00116] В общем случае, иерархия предсказания связана с порядковыми индексами видов, при этом кадры относительно более высокие в иерархии предсказания должны декодироваться перед декодированием кадров, которые относительно ниже в иерархии, так что кадры относительно более высокие в иерархии могут использоваться как опорные кадры при декодировании кадров относительно ниже в иерархии. Порядковый индекс вида - это индекс, который указывает порядок декодирования компонентов вида в единице доступа. Порядковые индексы видов подразумеваются в расширении SPS MVC, как определено в Приложении H стандарта H.264/AVC (поправка MVC). В SPS, для каждого индекса i, сигнализируется соответствующий идентификатор вида (view_id). Декодирование компонентов вида должно следовать в порядке возрастания порядкового индекса вида. Если все виды представлены, то порядковые индексы видов находятся в последовательном порядке от 0 до num_views__minus_1.

[00117] Этим способом кадры, используемые как опорные кадры, могут декодироваться перед декодированием кадров, которые кодированы на основе опорных кадров. Порядковый индекс вида - это индекс, который указывает на порядок декодирования компонентов вида в единице доступа. Для каждого порядкового индекса i вида сигнализируется соответствующий view_id. Декодирование компонентов вида следует в порядке возрастания порядковых индексов вида. Если все виды представлены, то набор порядковых индексов видов содержит упорядоченный набор от нуля до меньшего на единицу полного числа видов.

[00118] Для некоторых кадров на равных уровнях иерархии, порядок декодирования может не иметь значения по отношению друг к другу. Например, I-кадр вида S0 во временном местоположении Т0 используется в качестве опорного кадра для P-кадра вида S2 во временном местоположении Т0, который в свою очередь используется в качестве опорного кадра для P-кадра вида S4 во временном местоположении Т0. Соответственно, I-кадр вида S0 во временном местоположении Т0 должен декодироваться перед P-кадром вида S2 во временном местоположении Т0, который должен декодироваться перед P-кадром вида S4 во временном местоположении Т0. Однако между видами S1 и S3 порядок декодирования не имеет значения, потому что виды S1 и S3 не основываются друг на друге для предсказания, а вместо этого предсказываются только из видов, которые выше в иерархии предсказания. Кроме того, вид S1 может декодироваться перед видом S4, если вид S1 декодируется после видов S0 и S2.

[00119] Таким способом иерархическое упорядочение может использоваться для описания видов от 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 ниже, виды декодируются как можно скорее.

[00120] Пример таблицы 6 показывает, что вид S1 может декодироваться непосредственно после того, как виды S0 и S2 декодированы, вид S3 может декодироваться непосредственно после того, как виды S2 и S4 декодированы, и вид S5 может декодироваться непосредственно после того, как виды S4 и S6 декодированы.

[00121] Таблица 7 ниже обеспечивает другой порядок декодирования в качестве примера, в котором порядок декодирования таков, что любой вид, который используется в качестве опоры для другого вида, декодируется перед видами, которые не используются в качестве опоры ни для какого другого вида.

[00122] Пример таблицы 7 показывает, что кадры видов S1, S3, S5 и S7 не действуют как опорные кадры для кадров любых других видов, и поэтому виды S1, S3, S5 и S7 декодируются после кадров тех видов, которые используются как опорные кадры, то есть видов S0, S2, S4 и S6 в примере фиг.6. Относительно друг друга, виды S1, S3, S5 и S7 могут декодироваться в любом порядке. Соответственно, в примере таблицы 7, вид S7 декодируется перед каждым из видов S1, S3 и S5.

[00123] Ясно, что может иметься иерархическое отношение между кадрами каждого вида, а также временными местоположениями кадров каждого вида. Согласно примеру фиг.6, кадры во временном местоположении Т0 являются интра-предсказанными или предсказанными межвидовым образом из кадров других видов во временном местоположении Т0. Точно так же, кадры во временном местоположении T8 являются интра-предсказанными или предсказанными межвидовым образом из кадров других видов во временном местоположении T8. Соответственно, относительно временной иерархии, временные местоположения Т0 и T8 находятся наверху временной иерархии.

[00124] Кадры во временном местоположении T4, в примере Фиг.6, ниже во временной иерархии, чем кадры временных местоположений Т0 и T8, потому что кадры временного местоположения T4 являются B-кодированными с опорой на кадры временных местоположений Т0 и T8. Кадры во временных местоположениях T2 и T6 ниже во временной иерархии, чем кадры во временном местоположении T4. Наконец, кадры во временных местоположениях T1, T3, T5 и T7 ниже во временной иерархии, чем кадры временных местоположений T2 и T6.

[00125] В MVC поднабор всего потока битов может быть извлечен, чтобы сформировать подпоток битов, который все еще соответствует MVC. Имеется много возможных подпотоков битов, которых могут потребовать конкретные приложения, например, на основе услуги, предоставляемой сервером, емкости, поддержки и функциональных возможностей декодеров одного или более клиентов и/или предпочтений одного или более клиентов. Например, клиент мог бы потребовать только трех видов, и могло бы иметься два сценария. В одном примере один клиент может потребовать плавного восприятия просмотра и мог бы предпочесть виды со значениями view_id S0, S1 и S2, в то время как другой клиент может потребовать масштабируемости вида и предпочесть виды со значениями view_id S0, S2 и S4. Если первоначально view_id упорядочены относительно примеров таблицы 6, значениями порядковых индексов видов являются {0, 1, 2} и {0, 1, 4} в этих двух примерах, соответственно. Отметим, что оба этих подпотока битов могут декодироваться как независимые потоки битов MVC и могут поддерживаться одновременно.

[00126] На фиг.7 показана блок-схема, иллюстрирующая примерный способ посылки потока MPEG-2 Систем, имеющего поднабор видов с непоследовательными порядковыми индексами видов, от сервера на клиент. Способ по фиг.7 описан, в целях примера, относительно устройства 20 источника A/V и устройства 40 назначения A/V, хотя понятно, что другие примеры могут выполнять способ по фиг.7. В примере фиг.7 действия, предписанные “серверу”, могут выполняться устройством 20 источника A/V, в то время как действия, выполняемые "клиентом", могут быть выполнены устройством 40 назначения A/V.

[00127] В примере фиг.7 устройство 20 источника A/V первоначально определяет подмножество доступных видов для посылки в устройство 40 назначения A/V на основе услуги, предоставляемой устройством 20 источника A/V (200). Как обсуждено выше, услуга в общем случае содержит отбор видов. Относительно примера фиг.6, услуга может содержать виды S0, S2 и S4. Предполагая, что порядковые индексы видов для этих видов являются порядковыми индексами видов, предписанными Таблицей 6, в качестве примера, порядковые индексы видов для видов S0, S2 и S4 могут содержать порядковые индексы 0, 1 и 3 видов. Обсуждение способа по фиг.7 использует эти идентификаторы видов и порядковые индексы видов для примера в целях объяснения.

[00128] Устройство 20 источника A/V может затем подготовить Таблицу Карты Программы (PMT) на основе видов, которые были определены для посылки как часть предоставления услуги (202). В частности, формирователь PMT 64 мультиплексора 30 может подготовить PMT на основе информации, извлеченной из таблиц 88 специфической для программы информации для одной или более программ, соответствующих услуге, предоставляемой устройством 20 источника A/V 20. В соответствии с методами настоящего раскрытия, подготовка PMT содержит генерацию дескриптора 110 расширения MVC и дескриптора 112 иерархии.

[00129] Для генерации дескриптора 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, который индивидуально указывает на каждый порядковый индекс вида для видов программы. Кроме того, поскольку порядковый индекс “2” вида пропущен, этот пример является примером, в котором порядковые индексы видов непоследовательны.

[00130] Для генерации дескриптора 112 иерархии, формирователь PMT 64 устанавливает значения полей дескриптора 112 иерархии согласно таблицам 88 специфической для программы информации. В соответствии с методами настоящего раскрытия, формирователь PMT 64 может также установить значение поля 154 флага усиления вида в значение '0', чтобы указать, что ассоциированный элемент программы увеличивает число видов битового потока, следующих из элемента программы, на который ссылается значение поля 172 индекса вложенного слоя иерархии.

[00131] После генерации PMT устройство 20 источника A/V может передать PMT к устройству 40 назначения A/V, например, в форме единицы NAL (204). В некоторых примерах устройство 20 источника A/V может периодически отправлять PMT к устройству 40 назначения A/V, например, после предопределенного временного интервала или после того, как послан конкретный объем данных. Устройство 40 A/V назначения может записать информацию программы из PMT на носитель хранения клиентской стороны (208), который может по существу отражать таблицы 88 специфической для программы информации мультиплексора 30. Например, демультиплексор 38 может содержать набор таблиц специфической для программы информации, подобных таблицам 88 специфической для программы информации мультиплексора 30. После приема специфической для программы информации, такой как переданная PMT, демультиплексор 38 может обновить таблицы специфической для программы информации демультиплексора 38.

[00132] Мультиплексор 30 может затем принять пакеты PES одной или более программ, связанных с услугой, предоставляемой устройством 20 источника A/V 20 (210). Мультиплексор 30 может определить, что пакеты PES должны быть включены в транспортный поток к устройству 40 назначения A/V, путем выполнения поиска по идентификаторам потоков пакетов PES. Когда идентификатор потока пакета PES соответствует виду, который должен быть включен в транспортный поток, мультиплексор 30 может сформировать единицу NAL из пакета PES, например, путем инкапсулирования пакета PES с идентификатором программы (PID), соответствующим программе (212). Мультиплексор 30 может также сформировать единицу доступа из множества таких единиц NAL (214) и послать единицу доступа в устройство 40 назначения AV (216).

[00133] Устройство 40 назначения A/V может затем принять единицу доступа от устройства 20 источника A/V (218) и ассоциировать единицу доступа с программой (220), например, путем обращения к PID из единицы доступа. Демультиплексор 38 устройства 40 назначения A/V может демультиплексировать единицу доступа в компонентные единицы NAL и, соответственно, пакеты PES, которые демультиплексор 38 может в конечном счете передать к аудио декодеру 46 и/или видео декодеру 48. Видео декодер 48 может декодировать каждое из видов и послать декодированные виды на видео вывод 44, который может содержать стереоскопический или автостереоскопический видео дисплей или другое устройство отображения, требующее множества видов. Аналогично, аудио декодер 46 может декодировать аудио кадры, чтобы сформировать декодированные аудиоданные и послать аудиоданные на аудио выход 42, например, динамик. Таким образом, устройство 40 A/V назначения может декодировать и отображать принятые данные (222).

[00134] На фиг.8 показана блок-схема, иллюстрирующая примерный способ для сборки компонентов видов двух или более подпотоков битов, чтобы сгенерировать поток битов таким образом, чтобы компоненты вида имели возрастающие порядковые индексы видов. Способ может упорядочивать подпотоки битов, не обращаясь к идентификаторам видов соответствующих подпотоков битов и компонентов вида. Предположим, относительно примера фиг.6, что первый подпоток битов транспортного потока (или потока программы) содержит компоненты вида для видов S0, S2 и S4, в то время как второй подпоток битов транспортного потока (соответствующий вложенному подпотоку битов первого подпотока битов) содержит компоненты вида для видов S1 и S3. Настоящее раскрытие может также ссылаться на вложенные подпотоки битов как “зависимые подпотоки битов.” Аналогично, настоящее раскрытие может ссылаться на подпотоки битов, в которые вложены зависимые подпотоки битов, как на основные подпотоки битов. Соответственно, первый подпоток битов на фиг.8 может упоминаться как основной подпоток битов, в то время как второй подпоток битов может упоминаться как вложенный или зависимый подпоток битов.

[00135] Предполагая, что порядковые индексы видов для этого примера таковы, как определено в таблице 6, порядковые индексы видов компонентов вида в первом подпотоке битов равны 0, 1 и 3 (соответственно), в то время как порядковые индексы видов для второго подпотока битов равны 2 и 4. Соответственно, если компоненты вида первого потока битов в этом примере были полностью декодированы перед компонентами вида второго подпотока битов, порядок декодирования, с точки зрения порядковых индексов видов, будет соответствовать 0, 1, 3, 2, 4. Поскольку порядковые индексы видов должны описывать порядок декодирования, такой порядок декодирования вызвал бы нарушение спецификации MVC. Соответственно, способ по фиг.8 может использоваться, чтобы переупорядочить компоненты вида, с точки зрения порядковых индексов видов, чтобы порядок декодирования компонентов вида соответствовал спецификации MVC.

[00136] Способ по фиг.8 в общем случае соответствует примерному способу, в котором, при сборке подпотоков битов, компоненты вида в каждой единице доступа должны следовать возрастающему порядку порядковых индексов видов, как переносится в текущем подпотоке битов и его вложенных подпотоках битов. Способы настоящего раскрытия обеспечивают возможность сборки согласующегося подпотока битов MVC без проверки элемента синтаксиса view_id в заголовке единицы NAL единиц NAL и его отображения на порядковый индекс вида. Способ по фиг.8 может использоваться для формирования списка, называемого “списком индексов слоев иерархии” (HLI), который содержит индексы, соответствующие view_ID подпотоков битов в порядке, соответствующем стандарту MVC.

[00137] Первоначально, клиентское устройство, такое как устройство 40 A/V назначения, получает единицу доступа, имеющую компоненты вида двух подпотоков битов (250). Предполагается, в целях примера, что второй подпоток битов содержит вложенный или зависимый подпоток битов первого подпотока битов. Примерный способ по фиг.8 описан относительно двух подпотоков битов. Однако методы по фиг.8 также применимы к примерам, имеющим более двух подпотоков битов. Кроме того, способ по фиг.8 описан в целях примера для пояснений относительно демультиплексора 38 устройства 40 назначения A/V. Однако понятно, что способ по фиг.8 может быть выполнен любым устройством, модулем, блоком или комбинацией программируемого оборудования, аппаратных средств и/или компонентов программного обеспечения, чтобы реорганизовать виды двух или более подпотоков битов для соответствия стандарту MVC.

[00138] Предполагается, что компоненты вида каждого подпотока битов упорядочены согласно стандарту MVC. Поэтому демультиплексор 38 определяет, какой из компонентов вида подпотоков битов имеет наименьший порядковый индекс вида (252). Демультиплексор 38 может добавить индекс компонента вида (который может содержать одну или более единиц NAL) к списку HLI в следующем доступном положении (254). В некоторых примерах компонент вида может содержать одну или более единиц NAL, включающих мультимедийные данные, а также разделитель единица NAL, которая может использоваться, чтобы отличить компонент вида от другого, последующего компонента вида. Демультиплексор 38 может затем определить, остаются ли какие-либо компоненты вида для первого подпотока битов (256).

[00139] Если компоненты вида остаются для первого подпотока битов (ветвь “ДА” от 256), демультиплексор 38 может определить, остаются ли компоненты вида также для второго подпотока битов (258). Когда первый подпоток битов и второй подпоток битов включают по меньшей мере один компонент вида (ветвь “ДА” от 258), демультиплексор 38 возвращается к этапу 252, чтобы определить наименьший порядковый индекс вида компонентов вида и добавить индекс вида наименьшего компонента вида к списку HLI. Однако когда компоненты вида остаются только для первого подпотока битов, но не второго (ветвь “НЕТ” от 258), демультиплексор 38 может добавить остающиеся компоненты вида первого подпотока битов к списку HLI (260).

[00140] С другой стороны, когда никакие компоненты вида не остаются для первого подпотока битов (ветвь “НЕТ” от 256), демультиплексор 38 может определить, остаются ли компоненты вида для второго подпотока битов (262). Когда второй подпоток битов имеет остающиеся компоненты вида, демультиплексор 38 может добавить остающиеся компоненты вида второго подпотока битов к списку HLI (264).

[00141] После того, как список HLI содержит идентификаторы видов в порядке соответствующих порядковых индексов видов (например, после завершения этапа 260, 264, или ветвь “НЕТ” от 262), демультиплексор 38 может сформировать новый поток битов, содержащий подпотоки битов в порядке, определенном согласно списку HLI. Таким образом, для единицы доступа нового потока битов, где единица доступа содержит множество компонентов вида, компоненты вида упорядочены в новом потоке битов таким образом, что порядковый индекс вида каждого компонента вида больше, чем все предыдущие порядковые индексы вида, и меньше, чем все последующие порядковые индексы вида. Этот поток битов может тогда быть отправлен, например, на видео декодер 48, чтобы декодировать компоненты вида и, в конечном счете, отображать компоненты вида.

[00142] Примерные алгоритмы, приведенные в качестве примера ниже, обеспечивают примерный процесс упорядочения подпотоков битов для соответствия стандарту MVC. В примерах имеется список значений индекса слоя иерархии (HLIList), который или соответствует текущему подпотоку битов MVC или вложенным подпотокам битов. Как отмечено выше, компонент вида может содержать множество единиц NAL. Аналогично, в некоторых примерах, компонент вида может содержать, или за ним может следовать, разделитель единиц NAL, чтобы дифференцировать каждый компонент вида от другого компонента вида.

[00143] Процесс для сборки нового потока битов может быть определен следующим образом:

1) Установить зависимый подпоток битов как подпоток битов, который не имеет вложенного подпотока битов.

2) В порядке возрастания индекса слоя иерархии, итеративно применять следующее:

1. Собрать подпоток битов, который соответствует MVC и описан в дескрипторе иерархии с индексом слоя иерархии, равным HLI:

2. Этот процесс имеет следующее в качестве входа:

i. подпоток битов расширения, который явно представлен;

ii. зависимый подпоток битов. Отметим, что он соответствует MVC и, таким образом, имеет компоненты вида, размещенные в возрастающем порядке порядкового индекса вида в каждой единице доступа;

iii. список порядковых индексов видов в подпотоке битов расширения;

iv. список вида порядковых индексов видов в зависимом подпотоке битов;

3. Процесс имеет следующее в качестве выхода:

i. новый подпоток битов, который имеет все собранные компоненты вида и, таким образом, соответствует MVC и формирует полную операционную точку, соответствующую HLI, определенному в дескрипторе иерархии;

ii. Список порядковых индексов видов в новом подпотоке битов;

4. Установить новый подпоток битов, сгенерированный на этапе 3 как зависимый подпоток битов;

5. Если HLI является последним в списке HLIList, установить зависимый подпоток битов как окончательный собранный подпоток битов MVC и завершить весь процесс сборки.

[00144] Следующий алгоритм описывает примерный процесс для сборки подпотока битов на основе зависимого подпотока битов и подпотока битов расширения, как требуется на этапе 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.

[00145] В одном или более примерах, описанные функции могут быть осуществлены в аппаратных средствах, программном обеспечении, программируемом оборудовании или любой комбинации указанного. При осуществлении в программном обеспечении, функции могут сохраняться или передаваться как одна или более инструкций или код на машиночитаемом носителе. Машиночитаемые носители включают в себя как компьютерные носители хранения, так и коммуникационные среды, включая любую среду, которая облегчает передачу компьютерной программы от одного места в другое. Носители хранения могут быть любыми доступными носителями, к которым могут получать доступ один или более компьютеров или один или более процессоров для извлечения инструкций, кодов и/или структур данных для реализации описанных методов. В качестве примера, но не ограничения, такие машиночитаемые носители могут включать в себя RAM (ОЗУ), ROM (ПЗУ), EEPROM (электронно-стираемое программируемое ПЗУ), CD-ROM или другое ЗУ на оптическом диске, ЗУ на магнитном диске или другие магнитные ЗУ, флэш-память или любой другой носитель, который может использоваться, чтобы переносить или хранить желательный программный код в форме инструкций или структур данных, и к которому может получать доступ компьютер. Кроме того, любое соединение надлежащим образом определяется как машиночитаемая среда. Например, если программное обеспечение передается с веб-сайта, сервера или другого удаленного источника с использованием коаксиального кабеля, волоконно-оптического кабеля, витой пары, цифровой абонентской линии (DSL), или беспроводных технологий, таких как инфракрасная, радиочастотная и микроволновая, то коаксиальный кабель, волоконно-оптический кабель, витая пара, DSL или беспроводные технологии, такие как инфракрасная, радиочастотная и микроволновая, включаются в определение носителя. Диски, как используется здесь, включают в себя компакт-диск (CD), лазерный диск, оптический диск, цифровой универсальный диск (DVD), дискету (floppy disk) и blu-ray-disc, где магнитные диски (disks) обычно воспроизводят данные магнитным способом, в то время как оптические диски (discs) воспроизводят данные оптическим способом с помощью лазера. Комбинации вышеупомянутого должны также быть включены в объем машиночитаемых носителей.

[00146] Коды могут исполняться одним или более процессорами, такими как один или более цифровых процессоров сигналов (DSP), универсальные процессоры, специализированные интегральные схемы (ASIC), программируемые вентильные матрицы (FPGA) или другие эквивалентные интегральные или дискретные логический схемы. Соответственно, термин “процессор”, как используется здесь, может относиться к любой вышеупомянутой структуре или любой другой структуре, подходящей для выполнения методов, описанных здесь. Кроме того, в некоторых аспектах, функциональность, описанная здесь, может быть обеспечена специализированными аппаратными средствами и/или программными модулями, конфигурированными для кодирования и декодирования или включенными в объединенный кодек. Кроме того, эти методы могут быть полностью реализованы в одной или более схем или логических элементов.

[00147] Методы настоящего раскрытия могут быть реализованы в разнообразных устройствах, включая беспроводную телефонную трубку, интегральную схему (IC) или набор IC (например, чипсет). Различные компоненты, модули или блоки описаны в настоящем раскрытии, чтобы подчеркнуть функциональные аспекты устройств, конфигурируемых для выполнения раскрытых методов, но не обязательно требуют реализации различными блоками аппаратных средств. Скорее, как описано выше, различные блоки могут быть объединены в блок аппаратных средств кодека или обеспечены набором взаимодействующих блоков аппаратных средств, включая один или более процессоров, как описано выше, во взаимосвязи с подходящим программным обеспечением и/или программируемым оборудованием.

[00148] Выше были описаны различные примеры. Эти и другие примеры находятся в пределах объема следующей формулы изобретения.