Многовидовое видео кодирование в системах мреg-2

Иллюстрации

Показать все

Изобретение относится к области передачи кодированных видео данных для усовершенствования многовидового видеокодирования (MVC) в системах MPEG-2 (Экспертная группа по движущимся изображениям). Техническим результатом является обеспечение возможности устройству приема, после приема потока транспортного уровня, содержащего множество подпотоков битов, каждый из которых имеет непоследовательные виды, переупорядочивать виды в подпотоках битов таким образом, что транспортный поток упорядочивается должным образом, то есть в возрастающем порядке с точки зрения порядковых индексов видов, так что декодер может должным образом декодировать кадры каждого из видов. Указанный технический результат достигается тем, что устройство содержит видеокодер, который кодирует множество видов сцены, мультиплексор, который формирует структуру данных для сигнализации, что соответствующий поток битов стандарта MPEG-2 содержит первый вид сцены, ассоциированный с первым порядковым индексом вида, и второй вид сцены, ассоциированный со вторым порядковым индексом вида, причем первый порядковый индекс вида и второй порядковый индекс вида являются непоследовательными, и выходной интерфейс для вывода структуры данных. 4 н. и 28 з.п. ф-лы, 7 табл., 8 ил.

Реферат

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

[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 и все картины, следующие за