Агрегация изображений с обратной совместимостью при масштабируемом видеокодировании

Агрегация изображений с обратной совместимостью при масштабируемом видеокодировании

Иллюстрации

Показать все

Реферат

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

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

УРОВЕНЬ ТЕХНИКИ

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

[0003] Масштабируемое кодирование видеосигнала (SVC) обеспечивает масштабируемые битовые видеопотоки. Масштабируемый битовый видеопоток содержит немасштабируемый базовый уровень и один или более улучшающих уровней. Улучшающий уровень может улучшать временную разрешающую способность (т.е. частоту кадров), пространственную разрешающую способность или качество видеоконтента, представленного нижележащим уровнем или его частью. Масштабируемые уровни могут агрегироваться в один поток транспортного протокола реального времени (RTP) или передаваться независимо.

[0004] Идея уровня кодирования видеосигнала (VCL) и уровня абстракции сети (NAL) взята из принципа усовершенствованного кодирования видеосигнала (AVC). VCL включает функциональные средства кодека для обработки сигнала и механизмы, такие как преобразование, дискретизацию, предсказание с компенсацией движения, контурный фильтр, межуровневое предсказание. Кодированное изображение базового или улучшающего уровня состоит из одной или более частей. NAL инкапсулирует каждую часть, сформированную VCL, в один или более блоков NAL.

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

SVC устанавливает порядок декодирования этих блоков NAL.

[0006] Идея масштабирования качества визуального контента за счет пренебрежения передачей и декодированием всех улучшающих уровней называется крупнозернистой масштабируемостью (CGS).

[0007] В некоторых случаях скорость передачи битов указанного улучающего уровня может быть снижена за счет отбрасывания битов из отдельных блоков NAL. Отбрасывание приводит к постепенному ухудшению качества видео в воспроизводимых улучшающих уровнях. Данная идея известна как мелкозернистая (гранулярная) масштабируемость (FGS).

[0008] В соответствии со стандартом кодирования видеосигнала H.264/AVC основное кодированное изображение содержится в блоке доступа. В некоторых системах обнаружение пакетов блоков доступа может быть упрощено посредством включения в битовый поток блока NAL -разделителя блоков доступа. В SVC блок доступа может содержать несколько основных кодированных изображений, но максимум одно изображение на каждую уникальную комбинацию dependency-id (идентификатор зависимости), temporal-ievel (временной уровень) и quality-ievel (уровень качества).

[0009] Масштабируемое кодирование видеосигнала приводит к кодированию «базового уровня» с некоторым минимальным качеством, а также к кодированию корректирующей информации, которая увеличивает качество до максимального уровня. Базовый уровень потоков SVC обычно совместим с усовершенствованным кодированием видеосигнала (AVC). Другими словами, декодеры AVC могут декодировать базовый уровень потока SVC и игнорировать специальные данные SVC. Эта особенность реализована посредством указания типов кодированных блоков NAL, характерных для SVC. Они зарезервированы для дальнейшего использования в AVC и должны пропускаться в соответствии со спецификациями AVC.

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

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

[0012] Так как данная свобода в агрегировании пакетов может использоваться во многих приложениях, это может вызвать определенные трудности в работе шлюзов. Во-первых, при передаче агрегированного пакета неизвестно, к каким изображениям принадлежат его блоки NAL, пока не будет произведен анализ заголовков каждого из блоков NAL, содержащихся в агрегированном пакете. Следовательно, когда в SVC применяется режим чередующегося пакетирования, уровни, к которым принадлежат содержащиеся блоки NAL, неизвестны до осуществления анализа заголовков каждого блока NAL в пакете. Поэтому перед определением того, какие блоки NAL перенаправляются (ни один, все или некоторые), шлюз должен анализировать заголовок каждого блока NAL. Во-вторых, для некоторых блоков NAL, таких как «дополнительная корректирующая информация» (SEI) и блоки NAL с набором параметров, определение блоков доступа, к которым они принадлежат, невозможно до приема блоков NAL уровня кодирования сигнала (VCL) того же блока доступа. Поэтому для принятия решения о соответствии не-VCL блоков NAL со связанными с ними изображениями шлюзу может потребоваться иметь буфер и некоторую информацию о состоянии.

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

[0014] В дополнение к вышесказанному в модели проверки формата файла SVC ранее был предложен агрегирующий блок NAL (документ MPEG М7586). В этой системе агрегирующий блок NAL является контейнером, который включает в свою полезную нагрузку связанные блоки NAL. Агрегирующий блок NAL имеет тип, не соответствующий техническим условиям H.264/AVC и SVC, и должен игнорироваться декодерами H.264/AVC и SVC. Однако, когда изображение базового уровня, соответствующее стандарту H.264/AVC, содержится в агрегирующем элементе NAL, оно больше не сможет быть декодировано декодером H.264/AVC, а также проанализировано устройством удаления полезной нагрузки H.264/AVC RTP или анализатором формата AVC.

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

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

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

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

[0017] Фиг.1 является схематическим изображением схемы электронного устройства, которая для реализации функциональных возможностей настоящего изобретения может работать как кодер и декодер.

[0018] Фиг.2 показывает обобщенную систему мультимедийной связи для использования с настоящим изобретением; и

[0019] Фиг.3 показывает устройство групповой передачи по протоколу IP, где каждый маршрутизатор может обрабатывать поток битов в зависимости от своих возможностей.

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

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

[0021] Структура косвенного блока NAL в настоящем изобретении помимо этого содержит информацию о свойствах или характеристиках, которая является общей для всех связанных блоков NAL. Общая информация о свойствах или характеристиках включает информацию о масштабируемости и о том, образуют ли связанные блоки NAL точку переключения масштабируемого уровня, в которой другой масштабируемый уровень может переключиться на текущий уровень, но помимо этого она может включать и другую информацию. Информация о масштабируемости может содержать по меньшей мере «расширенный» заголовок блока NAL, оговоренный в спецификации SVC, включая блоки синтаксиса simplejpriorityjd, discardable_flag, dependencyjd, temporal_level и quality-level.

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

[0023] В терминах формата файлов SVC агрегирующие блоки NAL обеспечивают, чтобы записи группы отображения NALU были последовательным и периодически повторяющимися. Агрегирующие блоки NAL используются для группировки блоков SVC NAL, принадлежащих одному сэмплу и имеющих одинаковую информацию о масштабируемости. Агрегирующие блоки NAL используют такой же заголовок, как и масштабируемые расширяющие блоки NAL (блоки SVC NAL), но при этом тип блоков NAL новый. Агрегирующий блок NAL может содержать блоки NAL экстрактора. Блок NAL экстрактора может ссылаться на агрегирующие блоки NAL.

[0024] Если при сканировании потока агрегирующий NALU не требуется (т.е. принадлежит к нежелательному уровню), он и его компоненты просто отбрасываются (используя его поле длины). Если агрегирующий NALU нужен, его заголовок отбрасывается, а содержимое сохраняется.

[0025] Агрегирующий блок NAL инкапсулирует два или более блоков SVC NAL в новый блок NAL. Агрегирующий блок NAL использует заголовок блока NAL с таким же синтаксисом, как и у блоков SVC NAL (указан в спецификации SVC). Агрегирующий блок NAL хранится в рамках сэмпла, как и любой другой блок NAL.

[0026] Все блоки NAL находятся в агрегирующем элементе NAL в порядке декодирования. Если сгруппированы блоки NAL, принадлежащие одному уровню качества (quality-level), то порядок блоков NAL с quality_level>0 может меняться. Синтаксис агрегирующего блока NAL является следующим:

[0027] class aligned(S) AggregatorNALUnit(AggregatorNALUnitSize) {unsigned int i=2;

/*NALUnitHeader как указано в спецификации SVC */

bit (I) forbidden_zero_bit;

bit (2)NAL_ref_idc;

bit (5) NAL_unit_type=AggregatorNALUnitType=const(30);

bit (6) simple_dependency_ID;

bit (f) discardable_flag;

bit (1) extension_flag;

if (extension_flag) {

qualityJevef=simplejIependencyJD; bit (3) temporaljevet; bit (3) dependencyID; bit (2) quality-ID;

i++;

}

/*конец заголовка блока NAL*/

do{

unsigned int((lengthSizeMinusOne+l)*8) NALUnitLength;

bit (NALUnitLength * 8) SVCNALUnit;

i+=(lengthSizeMinusOne+l)+NALUnitLength;}while (RAggregatorNALUnitSize);

}

Семантика агрегирующего блока NAL является следующей:

NALUnitHeader: (8 или 116 бит), как указано в спецификации SVC:

NAL_unit_type устанавливается равным типу агрегирующего блока NAL (тип 30).

Информация о масштабируемости (NAL_ref_idc, simple_dependency_ID, discardable_flag, расширенная информация о масштабируемости) должна иметь такие же значения, как и в заголовках каждого агрегированного блока NAL. NALUnitLength: Задает размер следующего блока NAL. Размер этого поля указан элементом lengthSizeMinusOne. SVCNALUnit: Блок SVC NAL, как указано в спецификации SVC, включая заголовок блока SVC NAL. Размер блока SVC NAL задан NALUnitLength.

[0028] Предполагается, что агрегирующий блок NAL собирает блоки SVC NAL одного масштабируемого уровня. Также он может группировать блоки SVC NAL разных уровней (например, группировка всех уровней качества (фрагменты FGS), группировка всех блоков NAL с одинаковым идентификатором dependencyJD). В этом случае заголовок агрегирующего блока NAL будет указывать информацию о масштабируемости блоков SVC NAL с наименьшим идентификатором dependencyJD и/или temporal-level, quality_ID.

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

[0030] Агрегирующие блоки NAL могут привести к постоянному количеству блоков NAL для каждого уровня в любом AU. Для обеспечения постоянной структуры может быть выполнено следующее. NALU базового уровня AVC могут быть сгруппированы в агрегирующем элементе NAL (если используются в потоке SVC). В этом случае значения temporal-level, dependency-ID и quality-ID устанавливаются на 0. Ссылки на NALU базового уровня AVC могут указываться в NAL экстрактора. Если по каким-либо причинам в данном AU не содержится NALU, то в данной позиции могут находиться пустые агрегирующие NAL.

[0031] С точки зрения формата полезной нагрузки RTP для видео SVC блок NAL с информацией о масштабируемости содержимого полезной нагрузки обычно является таким, как описано далее. Блок SVC NAL включает заголовок длиной один, два или три байта и строку байтов полезной нагрузки. Заголовок указывает тип блока NAL, (возможное) наличие ошибочных битов или нарушений синтаксиса в полезной нагрузке блока NAL, информацию об относительной важности блока NAL для процесса декодирования и (опционально, когда заголовок имеет длину 3 байта) информацию о зависимости декодирования масштабируемого уровня.

[0032] Заголовок блока NAL также работает как заголовок полезной нагрузки данного формата полезной нагрузки RTP. Полезная нагрузка блока NAL следует сразу же после него. Синтаксис и семантика заголовка блока NAL указана в [SVC], а основные его свойства обобщены ниже.

[0033] Первый байт заголовка блока NAL имеет следующий формат:

[0034] forbidden_zero_bit (F): 1 бит.Спецификация Н.264 объявляет значение 1 как нарушение синтаксиса.

[0035] nal_ref_idc (NRI): 2 бита. Значение 00 указывает на то, что содержимое блока NAL не используется для восстановления привязанных изображений для предсказания между изображениями. Такие блоки NAL могут быть отброшены без угрозы повреждения целостности привязанных изображений в том же уровне. Значения, превышающие 00, показывают, что для сохранения целостности привязанных изображений необходимо декодирование блока NAL. Для слайса или блока NAL, относящегося к разделению данных слайсов, значение NRI, равное 11, показывает, что блок NAL содержит данные ключевого изображения, как указано в [SVC].

[0036] Примечание: Концепция ключевого изображения была введена в SVC и нельзя полагать, что любые изображения в битовых потоках, совместимых с 2003 и 2005 версиями Н.264, следуют этому правилу.

[0037] nal_unit_type (Type): 5 бит.Этот компонент указывает тип полезной нагрузки блока NAL. Типы 20 и 21 блоков NAL (среди прочих) были заранее зарезервированы для будущих расширений. SVC использует эти два типа блоков NAL. Они указывают наличие еще одного байта, который полезен с транспортной точки зрения.

[0038] simple_priority_id (PRID): 6 бит.Этот компонент указывает идентификатор приоритета для блока NAL. Когда extension_flag равен 0, simple_priority_id используется для определения значений dependency-id, temporal-level и quality-level. Когда simple_priority_id отсутствует, предполагается, что он равен 0.

[0039] discardable_flag (D): 1 бит.Значение 1 указывает на то, что содержимое блока NAL (dependency-id=currDependencyld) не используется в процессе декодирования блоков NAL, у которых dependency-id > currDependencyld. Такие блоки NAL могут быть отброшены без угрозы повреждения целостности вышележащих масштабируемых уровней с более высокими значениями идентификатора dependency-id. Флаг discardable-flag, равный 0, показывает, что для сохранения целостности вышележащих масштабируемых уровней с более высокими значениями dependency-id необходимо декодирование блока NAL.

[0040] extension_flag (E): 1 бит. Значение 1 показывает, что в заголовке блока NAL присутствует третий байт. Когда бит Е второго байта равен 1, заголовок блока NAL расширяется до третьего байта:

[0041] temporal_level (TL): 3 бита. Этот компонент используется для указания временной масштабируемости частоты кадров. Уровень, состоящий из изображений с меньшим значением temporal-level, имеет меньшую частоту кадров.

[0042] dependency-ld (DID): 3 бита. Этот компонент используется для указания иерархии зависимости межуровневого кодирования. В любой временной позиции изображение с меньшим значением dependency-id может быть использовано для межуровневого предсказания для кодирования изображений с более высоким значением dependencyjd.

[0043] Quality-level (QL): 2 бита. Этот компонент используется для указания иерархии уровня FGS. В любой временной позиции и при равном значении dependency_id изображение FGS со значением quality_level, равным QL, для межуровневого предсказания использует изображение FGS или изображение базового качества (изображение не-FGS, когда QL-1=0) со значением quality_level, равным QL-1. Когда QL больше 0, блок NAL содержит уровень FGS или его часть.

[0044] В данном варианте осуществления изобретения определен новый тип блока NAL, который упоминается в тексте как блок NAL с информацией о масштабируемости содержимого полезной нагрузки (PACSI). В случае наличия блока PACSI NAL, он должен быть первым элементом NAL в агрегирующих пакетах и не должен содержаться в пакетах других типов. Блок PACSI NAL указывает характеристики масштабируемости, которые являются общими для всех остальных блоков в полезной нагрузке, и таким образом облегчает решение MANE относительно перенаправления или отказа от пакета. Отправители могут создавать блоки PACSI NAL, а получатели могут их игнорировать.

[0045] Тип блока NAL для блока PACSI NAL выбран из тех значений, которые не указаны в спецификации H.264/AVC и в RFC 3984. Таким образом, потоки SVC, имеющие базовый уровень H.264/AVC и содержащие блоки PACSI NAL, могут обрабатываться приемниками RFC 3984 и декодерами H.264/AVC.

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

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

[0048] Структура блока PACSI NAL такова:

[0049] Значения полей блока PACSI NAL могут быть заданы следующим образом:

- Бит F должен быть установлен равным 1, если бит F любого остального блока NAL в полезной нагрузке равен 1. В противном случае бит F должен быть установлен равным 0.

- Поле NRI должно быть установлено равным максимальному значению поля NRI среди всех остальных блоков NAL в полезной нагрузке.

- Поле Type должно быть установлено равным 30.

- Поле PRID должно быть установлено равным минимальному значению поля PRID среди всех остальных блоков NAL в полезной нагрузке.

Если поле PRID отсутствует в одном из остальных блоков NAL в полезной нагрузке, поле PRID блока PACSI NAL должно быть установлено равным 30.

Бит D должен быть установлен равным 0, если бит D любого из остальных блоков NAL в полезной нагрузке равен 0. В противном случае бит D должен быть установлен равным 1.

Бит Е должен быть установлен равным 1.

Поле TL должно быть установлено равным минимальному значению поля TL среди всех остальных блоков NAL в полезной нагрузке.

Поле DID должно быть установлено равным минимальному значению поля DID среди всех остальных блоков NAL в полезной нагрузке.

Поле QL должно быть установлено равным минимальному значению поля QL среди всех остальных блоков NAL в полезной нагрузке.

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

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

[0052] Фиг.1 показывает образец электронного устройства 12, в виде которого может быть реализовано настоящее изобретение как на стороне кодирования, так и на стороне декодирования. Однако необходимо понимать, что настоящее изобретение не должно ограничиваться определенным типом электронного устройства 12. Электронное устройство 12 на фиг.1 содержит экран 32, клавиатуру 34, микрофон 36, наушники 38, инфракрасный порт 42, антенну 44, смарт-карту в форме UICC в соответствии с вариантом осуществления изобретения, устройство 48 считывания карт, схему 52 радиоинтерфейса, схему кодека 54, контроллер 56 и память 58. Типы отдельных схем и блоков хорошо известны в технике, например в линейке мобильных телефонов Nokia.

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

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

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

[0056] Сервер 130 может быть соединен или не соединен со шлюзом 140 через сеть связи. Шлюз 140 может выполнять различные функции, такие как преобразование потока пакетов, соответствующего одному стеку протоколов связи, в другой стек протоколов связи, объединение и разделение потоков данных и управление потоком данных в соответствии с возможностями нисходящей линии связи и/или приемника, например управление скоростью передачи перенаправленного потока в соответствии с доминирующими условиями сети нисходящей связи. Примеры шлюзов 140 включают устройства управления многоточечными конференциями (MCU), шлюзы между видеотелефонией с канальной и пакетной коммутацией, серверы связи «нажми и говори» по сотовой сети (РоС), инкапсуляторы IP в системах цифрового телевидения для портативных устройств (DVB-H) или приставки, которые пересылают вещательные передачи локально в домашнюю беспроводную сеть. Когда используется RTP, шлюз 140 называется смесителем RTP и работает как конечная точка соединения RTP.

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

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

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

[0060] В многоточечных и широковещательных мультимедийных системах ограничения пропускной способности сети могут прогнозироваться во время кодирования. Таким образом, должен использоваться масштабируемый битовый поток. Фиг.3 показывает устройство групповой передачи IP, где каждый маршрутизатор может обрабатывать поток битов в зависимости от своих возможностей. На фиг.3 показан сервер S, предоставляющий битовый поток некоторому количеству абонентов С1-С3. Битовые потоки направляются абонентам маршрутизаторами R1-R3. В этом примере сервер предоставляет клип, который можно масштабировать по меньшей мере с тремя скоростями передачи - 120 кбит/с, 60 кбит/с и 28 кбит/с.

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

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

[0063] Программные и сетевые варианты реализации настоящего изобретения могут быть осуществлены при помощи стандартной технологии программирования с логикой, основанной на правилах, или другой логикой для выполнения различных шагов поиска в базе данных, шагов корреляции, шагов сравнения и шагов принятия решения. Также необходимо заметить, что слова «компонент» и «модуль», используемые здесь и в формуле, охватывают варианты реализации, осуществленные при помощи одной или более строк программного кода, и/или аппаратные варианты реализации и/или оборудование для приема вводимых вручную данных.

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

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

2. Способ по п.1, в котором элементарный блок данных с информацией о масштабируемости связан с:указанным по меньшей мере одним элементарным блоком данных илимножеством элементарных блоков данных, следующих за указанным элементарным блоком данных с информацией о масштабируемости.

3. Способ по п.2, в котором, если элементарный блок данных с информацией о масштабируемости связан с множеством элементарных блоков данных, следующих за указанным элементарным блоком данных с информацией о масштабируемости, также формируют индикацию, являющуюся:количеством байтов, следующих за указанным элементарным блоком данных с информацией о масштабируемости, причем указанное количество байтов включает указанное множество элементарных блоков данных, иликоличеством указанных элементарных блоков данных, следующих за указанным элементарным блоком дан