Описание характеристик агрегированных блоков медиаданных с обратной совместимостью

Описание характеристик агрегированных блоков медиаданных с обратной совместимостью

Иллюстрации

Показать все

Реферат

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

[0001] Настоящее изобретение относится в целом к переносу и хранению видеоданных. Более конкретно, настоящее изобретение относится к предоставлению информации с целью помочь блоку в принятии решения, следует ли передавать или обрабатывать кодированные данные.

ПРЕДПОСЫЛКИ СОЗДАНИЯ ИЗОБРЕТЕНИЯ

[0002] Этот раздел предназначен для описания предпосылок создания или контекста изобретения, которое раскрыто в формуле изобретения. Настоящее описание может включать концепции, которые могли рассматриваться, но не обязательно те, которые были задуманы или реализованы ранее. Поэтому, если не сказано иначе, содержание настоящего раздела не является изложением известного уровня техники.

[0003] Усовершенствованное кодирование видеосигналов (AVC, Advance Video Coding), известное также как H.264/AVC, представляет собой стандарт кодирования видеосигналов, разработанный Объединенной группой по разработке видеостандартов (JVT, Joint Video Team), состоящей из Экспертной группы по кодированию видеосигналов ITU-T (VCEG, Video-coding Expert Group) и Экспертной группы по кинематографии (MPEG, Motion Pictures Experts Group) ISO/IEC. Стандарт AVC включает концепции уровня кодирования видеосигнала (VCL, Video Coding Layer) и уровня сетевой абстракции (NAL, Network Abstraction Layer). Уровень VCL содержит функции по обработке для механизмов кодека, например преобразование, квантование, предсказание с компенсацией движения и петлевые фильтры. Кодированное изображение состоит из одного или нескольких слайсов. Уровень NAL инкапсулирует каждый слайс, генерированный уровнем VCL, в один или несколько блоков NAL. Блок NAL состоит из заголовка блока NAL и полезной нагрузки блока NAL. Заголовок блока NAL содержит, помимо прочего, тип блока NAL, указывающий, содержит ли блок NAL кодированный слайс, разбиение данных кодированного слайса, набор параметров последовательности или изображения и т.д. Поток блоков NAL представляет собой просто соединение множества блоков NAL. Кодированный битовый поток, согласно стандарту H.264/AVC или его расширениям, например SVC, является или потоком блоков NAL, или потоком байтов с предваряющим стартовым кодом для каждого блока NAL в потоке блоков NAL.

[0004] Масштабируемое видеокодирование (SVC, Scalable Video Coding) обеспечивает масштабируемые битовые потоки видеоданных. Масштабируемый битовый поток видеоданных содержит немасштабируемый базовый уровень и один или несколько уровней расширения. Уровень расширения может повысить временное разрешение (то есть частоту кадров), пространственное разрешение, или качество видеоконтента, представленного более низким уровнем или его частью. В расширении SVC стандарта AVC были унаследованы концепции уровней VCL и NAL.

[0005] Еще одним расширением AVC является многоракурсное кодирование видеоданных (MVC, multi-view Video Coding). На вход кодера MVC поступают входные видеопоследовательности (называемые различными ракурсами, или видами) для одной и той же сцены, полученные от множества камер, и выводит один битовый поток, содержащий все закодированные ракурсы. Кодирование MVC также унаследовало концепции уровней VCL и NAL.

[0006] Транспортный протокол реального времени (RTP, Real-time Transport Protocol) широко используется для переноса в реальном времени синхронизированных видеоданных, например аудио- и видеоданных. При переносе с использованием протокола RTP медиаданные встраивают в множество пакетов RTP. Формат полезной нагрузки RTP для транспорта RTP видеоданных AVC определен в запросе на комментарии (RFC, Request for Comments) рабочей группы по инженерным проблемам Интернета (IEFT) 3984, который доступен по адресу и содержание которого включено в настоящее описание путем ссылки. Для транспортировки видеоданных AVC с использованием протокола RTP каждый пакет RTP содержит один или несколько блоков NAL.

[0007] Документ IEFT RFC 3984 определяет несколько режимов пакетирования, одним из которых является режим с чередованием. При использовании режима пакетирования с чередованием блоки NAL от более чем одного устройства доступа могут быть пакетированы в пакеты RTP. Запрос RFV 3984 также определяет концепцию порядкового номера декодирования (DON, decoding order number), который показывает порядок декодирования блоков NAL, переданных в потоке RTP.

[0008] В проекте формата полезной нагрузки SVG RTP документ draft-wenger-avt-rtp-svc-03 (доступный по адресу http:/wenger-avt-rtp-svc-03) определяет новый тип блока NAL, называемый блоком NAL с информацией о масштабируемости контента полезной нагрузки (PACSI, payload content scalability information). Блок PACSI NAL, если таковой присутствует, является первым блоком NAL в агрегированном пакете и не присутствует в пакетах других типов. Блок PACSI NAL указывает характеристики масштабируемости, которые являются общими для всех оставшихся блоков NAL в полезной нагрузке, что облегчает сетевому элементу, реагирующему на медиаданные (MANE, media aware network element), принятие решения о дальнейшей передаче/обработке/отбраковке агрегированного пакета. Передатчики могут создавать блоки PACSI NAL. Приемники могут игнорировать блоки PACSI NAL или использовать их как подсказки для проведения эффективной обработки агрегированных пакетов. Когда первый агрегированный блок агрегированного пакета содержит блок PACSI NAL, имеется по меньшей мере один дополнительный агрегированный блок, присутствующий в том же самом пакете. Поля заголовка RTP устанавливаются согласно остальным блокам NAL в агрегированном пакете. Когда блок PACSI NAL включен в мультивременной агрегированный пакет, порядковый номер декодирования для блока PACSI NAL устанавливают для индикации того, что блок PACSI NAL является первым блоком NAL в порядке декодирования среди блоков NAL в агрегированном пакете, или PACSI NAL блок имеет порядковый номер декодирования, идентичный первому блоку NAL в порядке декодирования среди оставшихся блоков NAL в агрегированном пакете.

[0009] Принятие решения о том, какие блоки NAL должны быть переданы и/или обработаны, в общем случае требуется для нескольких разных целей. Например, в многосторонних системах связи в реальном времени, например, при проведении видеоконференции с многими участниками, передатчик (передатчики) может не знать возможностей всех приемников, например, когда количество приемников велико или когда приемники могут присоединяться к многостороннему сеансу связи без уведомления передатчика (передатчиков). По возможности передатчики не должны быть ограничены параметрами самого слабого приемника, поскольку это снижает качество обслуживания, которое может быть предоставлено другим приемникам. Следовательно, было бы полезно, если бы промежуточный блок (middlebox), например блок управления многосторонней связью (MCU, Multipoint Control Unit) для проведения мультимедийной конференц-связи, мог эффективно регулировать передаваемые потоки согласно возможностям приемников.

[0010] Другая ситуация, в которой должны приниматься такие решения, возникает при воспроизведении в устройстве файла или при использовании программного обеспечения, которое способно декодировать только некий поднабор из потока, например базовый уровень, совместимый с H.264/AVC, или ракурс из битовых потоков SVC или MVC, соответственно. Поэтому нужно обработать только поднабор блоков NAL. Видеоданные, воспроизводимые медиаплейером, могут быть представлены в формате, соответствующем формату носителя файла, или в формате потока RTP. В любом из этих двух случаев желателен свободный доступ ко всей информации, чтобы принять решение, какие из блоков NAL следует обработать.

[0011] Проект стандарта формата файлов SVC, изложенный в документе MPEG N8663, поддерживает агрегацию множества блоков NAL в один агрегированный блок NAL. Ожидается, что она будет также поддержана в будущем формате файлов MVC. Агрегированные блоки NAL могут агрегироваться как включением блоков NAL внутрь себя (в пределах размера, указанного их длиной), так и включением путем ссылки на блоки NAL, которые следуют за ними (в пределах области, обозначенной полем additional_bytes, внутри них). Когда поток сканируется считывающим устройством файлов AVC, "внутри" агрегатора видны только включенные блоки NAL. Это, например, позволяет считывающему устройству файлов AVC игнорировать целый набор ненужных блоков SVC или MVC NAL. Блоки SVC NAL относятся к специфическим для SVC блокам NAL, для которых значения типа блока NAL зарезервированы в стандарте AVC. Блоки MVC NAL относятся к специфическим для MVC блокам NAL, для которых значения типа блока NAL зарезервированы в стандарте AVC. Точно так же, если блоки AVC NAL агрегированы путем ссылки, считывающее устройство AVC не будет их игнорировать, и они остаются для этого считывающего устройства «в потоке». Этот механизм агрегации добавляет сложности к информации о доступе, необходимой для принятия решения, какой блок NAL должен обрабатывать медиаплейер.

[0012] Еще одна ситуация, в которой должны быть приняты такие решения, возникает, когда конечный пользователь, принимающий масштабируемый или многоракурсный поток, принимает решение переключить уровни или ракурсы соответственно, которые он хочет декодировать и воспроизвести. Соответствующий запрос передается, например, посредством Протокола идентификации сеанса связи (SIP, Session Identification Protocol) или Протокола потоковой передачи в реальном времени (RTSP, Real-Time Streaming Protocol). Предполагается, что в качестве реакции приемник запроса, например сервер или промежуточный блок, должен выбрать уровни или ракурсы для передачи. Из-за межуровневого и межракурсного предсказания немедленные изменения в передаваемых уровнях или ракурсах нежелательны, поскольку (1) полученные в результате потоки, возможно, окажутся несовместимы со стандартом, поскольку какие-либо межуровневые и межракурсные ссылки могут отсутствовать в декодере; (2) некоторые из переданных данных, возможно, не смогут быть декодированы и, следовательно, использованы для приемников; и (3) недекодируемые данные приводят к напрасной трате скорости передачи данных в канале и могут вызвать перегрузку и потерю пакетов, а также увеличение задержки при передаче сигналов. Поэтому передатчик должен реагировать на запрос в следующей точке возможного переключения уровней или ракурсов.

[0013] Кроме того, следует отметить, что избыточные изображения обеспечивают для системы механизм восстановления при ошибках в передаче при повреждении соответствующих кодированных изображений. Однако передача избыточных изображений не нужна, если сами избыточные изображения невозможно правильно декодировать, соответствующие первичные кодированные изображения декодированы правильно или декодирование избыточных изображений не поддерживается приемником. Поэтому передатчик или промежуточный блок может в некоторых случаях отказаться от передачи избыточных изображений или их частей. Первый такой случай имеет место, когда опорные изображения для избыточных изображений декодированы неправильно. Это можно быть выявлено, например, из общей обратной связи NACK для RTP/AVPF или обратной связи по потерям слайса для аудиовидеопрофиля с обратной связью RTP (RTP/AVPF, RTP Audio-Visual Profile With Feedback). Второй случай имеет место, когда избыточное изображение, поступающее в промежуточный блок, не является цельным, то есть некий слайс избыточного изображения оказывается потерян в канале между передатчиком и промежуточным блоком. Это может быть выявлено в промежуточном блоке, например, на основе порядковых номеров RTP входящих пакетов и контента предыдущего и последующего, относительно потерянного, пакетов RTP. Третий случай имеет место, когда для передачи используется надежный протокол связи, когда имеется достаточно времени для избирательных повторных передач поврежденных первичных кодированных изображений, или когда обнаружено, что в сети нет потерь. Четвертое условие имеет место, когда приемник сигнализирует, что не поддерживает никакие избыточные изображения: либо неявно посредством поддерживаемых профилей, либо явно - например, с использованием параметра redundant-pic-cap MIME/SDP.

[0014] Еще одной ситуацией, в которой должно быть принято решение, какой блок NAL должен быть передан и/или обработан, включает ситуацию, когда требуется адаптация скорости передачи данных для подстройки скорости передачи данных под пропускную способность самого узкого канала связи с целью предотвращения перегрузки или для регулировки сетевых или клиентских буферов. В этом случае передатчик или промежуточный блок должны принять непростое решение, какие блоки NAL не передавать. Одной из функций шлюзов для медиаданных или микшеров RTP (которые могут быть, например, блоками для проведения многосторонних конференций, шлюзами для переключения между телефонной связью на основе коммутации пакетов или на основе коммутации каналов, серверами РоС, инкапсуляторами IP в системе DVB-H или абонентскими приставками, которые локально направляют транслируемые данные в домашнюю беспроводную сеть) является управление скоростью передачи данных передаваемого потока согласно преобладающим условиям в нисходящей сети. Желательно управлять скоростью передачи данных без значительной обработки входящих данных, то есть путем простого пропуска пакетов или легко идентифицируемых частей пакетов.

[0015] При использовании режимов пакетирования без чередования и с чередованием для форматов полезной нагрузки RTP H.264/AVC и SVC некоторые из общих характеристик блоков NAL, содержащихся в пакете, могут быть идентифицированы только тогда, когда исследован каждый содержащийся в пакете блок NAL. Исследование может потребовать частичного декодирования блока NAL. Например, для выявления точек переключения временных уровней необходимо декодировать сообщение SEI с информацией о подпоследовательности, а для того, чтобы узнать, принадлежит ли кодированный слайс первичному кодированному изображению или избыточному кодированному изображению, необходимо декодировать заголовок слайса.

[0016] Промежуточные блоки обычно должны отбрасывать полные изображения или последовательности изображений так, чтобы результирующий поток оставался годным. Режим пакетирования с чередованием для стандарта полезной нагрузки H.264/AVC RTP позволяет осуществлять инкапсулирование практически любых блоков NAL для любых устройств доступа в ту же самую полезную нагрузку RTP (называемую агрегированным пакетом). В частности, не обязано инкапсулировать все кодированные изображения в одну полезную нагрузку RTP, а вместо этого блоки NAL кодированного изображения могут быть разбиты на множество пакетов RTP. Хотя такая свобода полезна для многих приложений, она вызывает следующие осложнения в работе промежуточного блока. Во-первых, для заданного агрегированного пакета неизвестно, к каким изображениям относились его блоки NAL, до анализа заголовка каждого блока NAL, содержащегося в агрегированном пакете. Таким образом, при использовании режима пакетирования с чередованием каждый заголовок агрегированного блока и заголовок блока NAL должны быть проанализированы для отнесения их к правильным изображениям. Когда присутствуют избыточные изображения, необходим дополнительный анализ заголовков слайсов. Во-вторых, возможно, не удастся идентифицировать характеристику блока NAL без присутствия некоторых других блоков NAL для того же самого устройства доступа. Например, чтобы узнать, является ли кодированный слайс частью блока доступа, к которому можно получить произвольный доступ, прежде всего, необходимо выявить и декодировать сообщение SEI с точкой восстановления для этого блока доступа.

[0017] Поэтому имеется потребность в предоставлении в транспортных пакетах или в агрегированных блоках NAL файлового формата легкодоступной информации, на основе которой сетевой промежуточный блок или медиаплейер может принять решение, какой блок кодированных данных следует передать и/или обработать. В заявке на патент США №11/622430, поданной 11 января 2007 года и включенной в настоящее описание путем ссылки, раскрыт непрямой агрегированный блок NAL для файлового формата SVC и формата полезной нагрузки RTP для индикации характеристик масштабируемости определенных блоков NAL, следующих за непрямым агрегированным блоком NAL. Однако в этом документе не рассматриваются другие характеристики, помимо информации о масштабируемости для SVC, включая, являются ли блоки кодированных данных, содержащихся в транспортном пакете: (1) частями избыточных изображений, 2) частями точек переключения временных уровней, (3) частями точек произвольного доступа к ракурсам, (4) частями точек произвольного доступа, которые не являются изображениями мгновенного обновления кодирования (IDR, instantaneous decoding refresh), и (5) частями изображений определенного ракурса, идентифицированного идентификатором ракурса.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[0018] Различные варианты выполнения настоящего изобретения обеспечивают создание системы и способа передачи информации, которые являются полезными для сетевого промежуточного блока или медиаплейера для принятия решения относительно того, какие блоки кодированных данных в пределах полезной нагрузки RTP или блока данных файлового формата передавать и/или обрабатывать, при обеспечении легкости доступа. В различных вариантах выполнения настоящего изобретения этот механизм может использоваться для обеспечения индикации таких элементов, как избыточные кодированные изображения, точки переключения временных уровней, точки доступа к постепенному обновлению декодирования, идентификаторы ракурса и точки произвольного доступа к ракурсам. Промежуточный блок и/или приемник могут затем использовать эту информацию для определения, должны ли некоторые блоки кодированных данных быть обработаны и/или переданы. Кроме того, может предоставляться также индикация элементов, например точек произвольного доступа, для не разбитых на уровни одноракурсных битовых потоков и индикация типа изображения.

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

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

[0021] Эти и другие преимущества и особенности изобретения, совместно с устройством и особенностями его работы, станут очевидными из последующего подробного описания со ссылками на сопровождающие чертежи, где на всех чертежах одинаковые элементы обозначены одинаковыми позициями.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0022] На фиг.1 показана типичная система для мультимедиасвязи, используемая вместе с настоящим изобретением;

[0023] на фиг.2 показан вид в перспективе электронного устройства, которое может использоваться при реализации настоящего изобретения; и

[0024] на фиг.3 схематично показана схема электронного устройства, изображенного на фиг.2.

ПОДРОБНОЕ ОПИСАНИЕ РАЗЛИЧНЫХ ВАРИАНТОВ ВЫПОЛНЕНИЯ ИЗОБРЕТЕНИЯ

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

[0026] Индикация избыточных кодированных изображений. Эта индикация может сопровождаться списком опорных изображений, необходимых для декодирования агрегированных избыточных кодированных слайсов и индикацией пространственных границ агрегированных избыточных кодированных слайсов. Имеются моменты времени, когда можно агрегировать и охарактеризовать слайсы только одного избыточного кодированного изображения.

[0027] Индикация точек переключения временного уровня. Начиная с точки переключения временного уровня, декодер может правильно декодировать все последующие кодированные изображения с этим временным уровнем, если перед точкой переключения временного уровня декодировались только изображения более низких временных уровней. Эта индикация может сопровождаться списком опорных изображений, указанных, например, значениями frame_num, которые должны быть правильно декодированы для правильной работы переключателя временных уровней. Отметим, что отбросить это количество декодированных/переданных временных уровней обычно можно в любой точке.

[0028] Индикация точек доступа к постепенному обновлению декодирования. Если декодер начинает декодирование с такой точки, то контент изображения будет постепенно корректироваться в пределах ряда последовательных изображений. В некоторых вариантах выполнения эта индикация должна сопровождаться числом изображений или пакетов, декодирование которых необходимо для достижения изображений, контент которых является корректным.

[0029] Индикация ракурсов. Эта индикация сигнализирует о ракурсах (например, в терминах идентификаторов ракурса), к которым относится агрегированный блок NAL.

[0030] Индикация изображений произвольного доступа к ракурсу. Вследствие использования межракурсного предсказания невозможно начать декодирование ракурса в произвольных точках. Поэтому данная индикация используется для сигнализации о том, что декодер может запустить декодирование с данного места. Эта индикация может сопровождаться числом изображений или пакетов, декодирование которых необходимо для достижения изображений, контент которых является корректным. Другие типы точек произвольного доступа к ракурсу обсуждаются в заявке на патент США №60/852223, поданной 16 октября 2006 г. и включенной в настоящее описание путем ссылки.

[0031] В различных вариантах выполнения настоящего изобретения в качестве механизма передачи вышеуказанных индикаций используется механизм непрямой агрегации блоков NAL, обсуждаемый в заявке на патент США №11/622430. Кроме того, этот же механизм агрегации может использоваться и для других индикаций. Например, этот механизм может также использоваться для индикаций точек произвольного доступа (открытых и закрытых групп изображений (GOP, Group of pictures) для не разбитых на уровни битовых потоков, относящихся к одному ракурсу, и индикаций типа изображений (например, изображение с внутренним кодированием, неопорное изображение).

[0032] Ниже описано одно из воплощений различных вариантов выполнения настоящего изобретения, конкретно - относящееся к формату полезной нагрузки RTP для SVC и MVC. В этом воплощении информация о масштабируемости контента полезной нагрузки (PACSI, payload content scalability information) блока NAL, обсуждаемая в заявке на патент США №11/622430, расширена и содержит дополнительные типы информации. Заголовок блока PACSI NAL сохранен неизменным. Альтернативно, заголовок блока PACSI NAL может быть изменен для согласования с заголовком будущего блока MVC NAL, особенно если заголовок будущего блока MVC NAL представляет собой расширенный набор заголовков блока SVC NAL. Текущий проект заголовка блока MVC NAL описан в итоговом документе встречи JVT в октябре 2006 (доступен по адресу и включен в настоящее описание путем ссылки) в структуре nal_unit_header_svc_mvc_extension. Альтернативно, для индикации информации, описанной здесь, может использоваться другой тип блока NAL, например значение 31.

[0033] Ниже дан пример блока PACSI NAL в контексте предлагаемого в качестве примера формата полезной нагрузки RTP одновременно для SVC и MVC.

[0034] Блок PACSI NAL состоит из 1-байтового заголовка блока NAL, 1-байтового заголовка информации о контенте (CI, content information) и полезной нагрузки переменной длины с информацией о контенте. 1-байтовый заголовок блока NAL содержит поля F, NRI и Type, определяемые ниже.

[0035] Значения полей в блоке PACSI NAL установлены следующим образом. Бит F устанавливают в 1, если бит F по меньшей мере в одном из оставшихся блоков NAL в полезной нагрузке равен 1. В противном случае бит F устанавливают в 0. Значение в поле NRI устанавливают равным самому высокому значению поля NRI среди всех оставшихся блоков NAL в полезной нагрузке. Поле Type устанавливают равным 30.

[0036] Заголовок CI содержит флаги, индицирующие наличие различных типов информации контента следующим образом:

[0037] Бит S, равный 1, указывает на присутствие информации о масштабируемости контента, определенной в проекте документа Интернет draft-wenger-avt-rtp-svc-03 (доступен по адресу wenger-avt-rtp-svc-03 и включен в настоящее описание путем ссылки) и приведенной ниже:

[0038] Когда бит M равен 1, в полезной нагрузке CI присутствует следующая информация о многоракурсном контенте:

[0039] Бит R зарезервирован. TL (временный уровень, temporal level) устанавливают в самое низкое значение для поля TL среди остальных блоков NAL в полезной нагрузке RTP. VL (уровень ракурса, view level) устанавливают в самое низкое значение для поля VL среди остальных блоков NAL в полезной нагрузке RTP.

[0040] Флаг A (anchor_pic_flag) устанавливают в самое высокое значение флага А среди остальных блоков NAL в полезной нагрузке RTP. Следовательно, значение бита А, равное 1, указывает, что полезная нагрузка RTP содержит по меньшей мере один блок NAL, связанный с якорным (anchor) изображением. Значение бита А, равное 0, указывает, что полезная нагрузка RTP не содержит блока NAL, ассоциированного с якорным изображением.

[0041] Параметр num_views указывает количество последующих элементов синтаксиса view_id. Параметр num_views устанавливают равным значению, которое указывает количество различных значений идентификаторов ракурса view_id среди оставшихся блоков NAL в полезной нагрузке RTP.

[0042] Каждое значение view_id указывает идентификатор view_id, присутствующий среди оставшихся блоков NAL в полезной нагрузке RTP. Значения view_id не должны быть дублированы в полезной нагрузке CI. В настоящее время значения view_id в стандарте MVC представляют собой 10-битовые целые без знака, которые преобразуют к 16-битовым целым без знака для полезной нагрузки CI.

[0043] В одном из вариантов выполнения настоящего изобретения поле num_views отсутствует, и в информацию многоракурсного контента включено только одно значение view_id. Следовательно, требуется, чтобы пакет RTP, включая блок PACSI NAL, содержал кодированные данные только для одного ракурса.

[0044] Бит R заголовка CI указывает на присутствие информации об избыточном кодированном изображении. Когда бит R равен 1, полезная нагрузка RTP не содержит никаких блоков NAL для первичных кодированных изображений. Никакой полезной нагрузки CI, соответствующей биту R, нет.

[0045] Бит A заголовка CI указывает на наличие точки произвольного доступа следующим образом. Когда бит A равен 1, бит S равен 0 и бит M равен 0, полезная нагрузка RTP содержит блок NAL, принадлежащий изображению IDR или изображению с внутренним (intra) кодированием, ассоциированному с сообщением о точке восстановления SEI со значением элемента синтаксиса recovery_frame_cnt, равным 0. Когда бит A и бит S равны 1, полезная нагрузка RTP содержит блок NAL, принадлежащий изображению IDR для кодирования SVC. Когда бит A и бит M равны 1, полезная нагрузка RTP содержит блок NAL, принадлежащий изображению произвольного доступа к ракурсу (изображение IDR или якорное изображение) MVC.

[0046] Бит T заголовка CI указывает присутствие точки переключения временного уровня. Если бит T равен 1, то или бит S, или бит M также должен быть равен 1. Когда бит Т равен 1, в полезной нагрузке CI присутствует следующая информация о временном уровне:

[0047] Элемент синтаксиса TLT указывает временный уровень, на который может быть произведено переключение, если все пакеты, содержащие временные уровни, равные или меньшие TLT, декодированы с этой точки, когда временный уровень (TLT-1) был ранее декодирован, по меньшей мере начиная с предыдущей точки переключения временного уровня для временного уровня (TLT-1), в порядке, в котором происходит передача. Альтернативно, можно включить множество значений TLT, указывающих множество значений temporal_level, на которые может быть осуществлено переключение при условиях, описанных выше.

[0048] Биты поля Reserved [Зарезервировано] зарезервированы. Биты поля Res в заголовке CI также зарезервированы. Когда более одного из нерезервированных битов в заголовке CI установлено в 1, структура синтаксиса полезной нагрузки CI появляется в том порядке, в котором соответствующие биты появляются на заголовке CI.

[0049] Ниже дана другая реализация различных вариантов выполнения настоящего изобретения, в частности, в отношении формата полезной нагрузки RTP для кодирования SVC. В этой реализации блок (PACSI) NAL с информацией о масштабируемости контента полезной нагрузки, обсуждаемый в заявке на патент США №11/622430, расширен с добавлением еще одного восьмибитового байта следующим образом.

[0050] Поле R устанавливают в 1, если все кодированные изображения, содержащие целевые блоки NAL, представляют собой якорные изображения. В противном случае бит R устанавливают равным 0. Целевые блоки NAL - это блоки NAL, содержащиеся в агрегированном пакете, но не включенные в блок PACSI NAL, которые находятся внутри блока доступа, которому принадлежит первый блок NAL, расположенный после блока PACSI NAL в агрегированном пакете. Якорное изображение - это такое изображение, для которого, если декодирование уровня начинается с этого изображения, все последующие изображения уровня могут быть в порядке выхода правильно декодированы. Отметим, что якорные изображения - это точки произвольного доступа к уровням, которым принадлежат эти якорные изображения. Однако некоторые изображения, следующие за якорным изображением в порядке декодирования, но предшествующие якорному изображению в порядке выхода, могут ссылаться на более ранние изображения, а следовательно, могут быть неправильно декодированы, если выполнить произвольный доступ в якорном изображении.

[0051] Поле Т устанавливают в 1, если все кодированные изображения, содержащие целевой блок NAL (как определено выше), - это точки переключения временных масштабируемых уровней. В противном случае бит Т устанавливают в 0. Для точки переключения временного масштабируемого уровня все кодированные изображения с тем же самым значением temporal_level в точке переключения и после нее в порядке декодирования не ссылаются на какое-либо кодированное изображение с тем же самым значением temporal_level, предшествующее точке переключения в порядке декодирования.

[0052] Поле D устанавливают в 1, если все кодированные изображения, содержащие целевой блок NAL (как определено выше) - это избыточные изображения. В противном случае поле D устанавливают в 0. Поле I устанавливают в 1, если изображение, которое имеет самое большое значение dependencyjd среди всех кодированных изображений, содержащих целевой блок NAL (как определено выше), представляет собой изображение с внутренним кодированием, то есть кодированное изображение, не относящееся ни к какому ранее кодированному изображению в порядке декодирования в том же самом уровне. Поле RES устанавливают в 0.

[0053] Кроме того, можно не передавать поля для индикации в блоке PACSI NAL, но добавлять их непосредственно к структуре полезной нагрузки перед любым блоком NAL в пакете RTP.

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

[0055] На фиг.1 показана обобщенная система мультимедийной связи, предназначенная для использования с настоящим изобретением. Как показано на фиг.1, источник 100 данных выдает исходный сигнал в аналоговом, несжатом цифровом или сжатом цифровом формате или в любой комбинации этих форматов. Кодер 110 кодирует исходный сигнал в двоичный поток кодированных медиаданных. Кодер 110 может кодировать больше одного типа медиаданных, например аудио- и видеоданные, или же для кодирования различных видов видеоданных в исходном сигнале может понадобиться более одного кодера 110. Кодер 110 может также получать синтезированный входной сигнал, например графические или текстовые данные, или он может быть способен создавать потоки кодированные двоичных сигналов из синтезированных медиаданных. Ниже для упрощения описания будет рассмотрена обработка двоичного потока кодированных медиаданных только одного вида. Однако следует отметить, что обычно трансляция в реальном времени включает несколько потоков (обычно по меньшей мере один аудио-, видео- и текстовый поток, включающий субтитры). Кроме того, следует отметить, что система может включать много кодеров, но ниже рассматривается только один кодер 110, что упрощает описание без нарушения общности.

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

[0057] Двоичный поток кодированных медиаданных поступает в память 120. Память 120 может включать любой тип памяти большой емкости, предназначенной для хранения двоичного потока кодированных медиаданных. Формат двоичного потока кодированных медиаданных в памяти 120 может быть элементарным автономным форматом двоичного потока, или же один или несколько двоичных потоков кодированных медиаданных могут быть инкапсулированы в файл. Некоторые системы работают «на лету», то есть опускают хранение и передают двоичный поток кодированных медиаданных из кодера 110 прямо в передатчик 130. Затем, по мере надобности, двоичный поток кодированных медиаданных передают в передатчик 130, также называемый сервером. Формат, используемый при передаче, может быть элементарным автономным форматом двоичного потока данных, форматом пакетированного потока или одним или несколькими двоичными потоками кодированных медиаданных, инкапсулированных в файл. Кодер 110, память 120 и передатчик 130 могут быть расположены в одном физическом устройстве, или же они могут входить в отдельные устройства. Кодер 110 и передатчик 130 могут работать с контентом в реальном времени, когда двоичный поток кодированных медиаданных обычно не хранят постоянно, а вместо этого буферируют в течение малых промежутков времени в кодере 110 контента и/или в передатчике 130, чтобы сгладить неравномерности в задержке при обработке, задержке при передаче и задержке из-за переменной скорости кодированных данных.

[0058] Передатчик 130 посылает двоичный поток кодированных медиаданных с использованием стека протоколов связи. Стек может включать, но этим не ограничивается, транспортный протокол реального времени (RTP, Real-time Transport Protocol), протокол пользовательских дейтаграмм (UDP, User Datagram Protocol) и протокол маршрутизации в среде Интернет (IP, Internet Protocol). Когда стек протоколов связи является пакетно-ориентированным, передатчик 130 инкапсулирует двоичный поток кодированных медиаданных в пакеты. Например, при использовании транспортного протокола в реальном времени передатчик 130 инкапсулирует двоичный поток к