Способ и устройство для переупорядочивания и мультиплексирования мультимедийных пакетов из мультимедийных потоков, принадлежащих взаимосвязанным сеансам

Способ и устройство для переупорядочивания и мультиплексирования мультимедийных пакетов из мультимедийных потоков, принадлежащих взаимосвязанным сеансам

Иллюстрации

Показать все

Реферат

Настоящее изобретение относится к способу и устройству для переупорядочивания и мультиплексирования мультимедийных пакетов из потоков мультимедийных данных, принадлежащих взаимосвязанным сеансам.

Такие способы, например, важны для потоков данных, закодированных кодеком масштабируемого видео, которые транспортируются с помощью транспортного протокола реального времени.

Масштабируемость в кодировании и передаче видео становится все более и более важной в последние годы. Масштабируемое кодирование видео, здесь и далее обозначенное аббревиатурой SVC, специфицировано в приложении G стандарта H.264/AVC, который может быть найден в рекомендации ITU-T H.264/ISO/IEC IS 14496-10 AVC, 2005 г., редакция 3. В самой основной форме SVC видеосигнал представляется одним базовым слоем и одним или более улучшающими слоями. Улучшающий слой может увеличивать временное разрешение (т.е. частоту кадров), пространственное разрешение или качество видеоконтента, по сравнению с тем, что доступно при декодировании только слоя, на котором основан улучшающий слой. Улучшающие слои могут быть "сложены" поверх друг друга. В SVC даже возможно сделать улучшающий слой непосредственно зависящим от более чем одного "более низкого слоя", и довольно сложные схемы зависимостей слоев могут быть реализованы, однако учитывая ограничение, что в одном блоке доступа, как правило, соответствующем видеокадру, изображение слоя может непосредственно зависеть только от одного более низкого слоя. Каждый слой, вместе со всеми более низкими слоями, от которых он зависит, формирует одно представление видеосигнала с определенным пространственным разрешением, временным разрешением и уровнем качества. В этом документе масштабируемое представление слоя упоминается как один данный слой вместе со всеми более низкими слоями, от которых он непосредственно или косвенно зависит. Один масштабируемый битовый поток вмещает в себя слои, которые формируют, по меньшей мере, два, но иногда намного больше, масштабируемых представлений слоя.

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

Для транспортирования закодированных видеосигналов широко используется транспортный протокол реального времени, здесь и далее обозначенный аббревиатурой RTP. Основной RTP-протокол, как специфицировано в RFC3550 стандарта IETF, используется в Интернете для приложений потоковой передачи и трансляции видео DVB-H/SH. Поскольку только основные функции RTP определены в RFC3550, необходимы дополняющие RFC, чтобы определять транспорт особых закодированных видеоданных в RTP. В этом отношении RFC3984 был определен для спецификации транспорта NAL-блоков H.264 AVC.

Новые предложенные расширения для спецификаций полезной нагрузки RTP, такие как предложенные для RFC3984 для объединения закодированного SVC-видео, поддерживают инкапсуляцию одного NAL-блока, более чем одного NAL-блока или фрагмента NAL-блока в одном RTP-пакете. Один NAL-блок, как специфицировано в H.264/AVC, может быть включен в пакет RTP "как есть", и заголовок NAL-блока совместно служит в качестве заголовка полезной нагрузки. Специфицированы четыре типа объединения NAL-блоков. Два типа однократного объединения пакетов, STAP-A и STAP-B, допускают инкапсуляцию более чем одного NAL-блока в один RTP-пакет, который происходит из одного изображения (идентифицированного идентичной временной RTP-меткой). Два типа многократного объединения пакета (MTAP) могут использоваться, чтобы объединять NAL-блоки из различных изображений в один RTP-пакет. RFC 3984 также поддерживает два типа фрагментации блоков, FU-A и FU-B, которые позволяют фрагментацию одного NAL-блока во множестве RTP-пакетов.

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

Как определено в IETF RFC3550, RTP поддерживает переупорядочивание пакетов посредством последовательного номера RTP, а синхронизацию по времени между различными RTP-сеансами - посредством временной метки RTP и отчетов RTCP-отправителя.

Порядок декодирования NAL-блоков, однако, необязательно идентичен порядку передачи или порядку RTP-пакетов. Например, когда используется режим чередующегося пакетирования RFC 3984, иногда невозможно предположить правильное упорядочивание NAL-блоков из вышеупомянутой информации. При транспортировании H.264/SVC-слоев в различных RTP-сеансах, упоминаемых как мультиплексирование RTP-сеансов, ситуация получается еще более усложненной. Ранние версии проекта полезной нагрузки SVC пытались специфицировать алгоритм для этого процесса переупорядочивания NAL, но сложности спецификации и реализации считались чрезмерно высокими.

Альтернативой этому подходу является явная передача сигналов порядка NAL-блоков в потоке пакетов. Это требует, чтобы использовался чередующийся режим RFC3984, и поле DON (порядковый номер декодирования) STAP-B, FU-B и MTAP-пакетов явно использовалось, чтобы указывать порядок декодирования NAL-блоков между всеми слоями и RTP-сеансами.

В нечередующемся режиме, где пакеты, вмещающие в себя поле DON, не допускаются, существует другой подход, чтобы явно указывать порядок декодирования NAL-блоков между всеми слоями (межслойный DON или CL-DON) посредством использования поля DONC в PACSI NAL-блоке в объединенном пакете (STAP-A). Это довольно сложно и требует дополнительной пропускной способности.

В нечередующемся режиме или режиме одного NAL-блока другой подход подразумевает концепцию точки синхронизации, полагающуюся на знание одномерного тракта зависимости RTP-сеансов, определенного в протоколе описания сеанса (SDP). Он в основном содержит анализ взаимосвязей временных меток пакетов и распределения между RTP-сеансами, чтобы идентифицировать и восстанавливать порядок блоков доступа в порядке декодирования. Порядок блоков доступа восстанавливается посредством поиска точки синхронизации сеанса от наиболее зависимого сеанса до наименее зависимого, точка синхронизации сеанса Sx (определенная как TS_Sx) определяется как временно выстроенный в ряд набор RTP-пакетов (т.е. все имеют одинаковую временную метку) с, по меньшей мере, одним RTP-пакетом в каждом сеансе Sy, где Sy выше или равно Sx согласно порядку зависимости сеансов. В основном, этот подход подразумевает анализ взаимосвязи временных меток пакетов и распределения между сеансами, чтобы идентифицировать и восстанавливать порядок блоков доступа в порядке декодирования, и знание тракта зависимости сеансов, определенного в SDP, чтобы восстанавливать порядок NAL-блоков в каждом блоке доступа.

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

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

Целью настоящего изобретения является предоставление способа вышеупомянутого известного типа, но который может решать вышеупомянутые проблемы вычислительной сложности, увеличенной пропускной способности или необходимости справляться с различными частотами кадров для восстановления пакетов, например, RTP/SVC-сеансов в нечередующемся режиме и/или режиме одного NAL-блока. Подобным образом, целью настоящего изобретения является предоставление устройства, которое выполнено с возможностью размещать различные пакеты в правильном порядке перед предоставлением их декодеру.

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

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

Дополнительный характерный признак настоящего изобретения изложен в пункте 2.

Это будет, вдобавок, решать другую характерную проблему предшествующего уровня техники, когда в случае потери пакетов способ предшествующего уровня, основанный на точках синхронизации, может не иметь возможности выводить все хорошо принятые пакеты. Так, этот способ предшествующего уровня останавливал процесс переупорядочивания в сеансе, где была обнаружена первая потеря пакета; и пакеты более высоких сеансов в настоящем и следующих блоках доступа не выводились до тех пор, пока следующий блок доступа, соответствующий точке синхронизации TS_S0, не был найден. Следствием является то, что успешно принятые пакеты/NAL-блоки более высоких сеансов теряются в течение возможно многих блоков доступа, несмотря на тот факт, что видеопроигрыватель может реализовывать хорошие технические приемы маскировки SVC с помощью этих удачно принятых NAL-блоков. Не учитывая RTP-сеансы, где потеря пакетов была обнаружена при поиске сеанса с самой высокой частотой кадров, и не прерывая процесс переупорядочивания между слоями, когда ошибка обнаруживается в сеансе, настоящий способ переупорядочивания пакетов является более устойчивым к потере пакетов, поскольку пакеты переупорядочиваются даже после обнаружения потери в более низких сеансах. Следовательно, видеопроигрыватели, реализующие маскировку SVC, имеют максимально доступную информацию на входе.

Оба принципа могут быть объединены в один итерационный процесс.

Другой характерный признак настоящего изобретения изложен в пункте 5. Использование знания частоты кадров, вмещающихся в каждом сеансе, используя информацию сигнализации, которая в случае SVC/RTP-потоков может быть протоколом описания сеанса, обозначенным аббревиатурой SDP, для обнаружения потоков с самой высокой частотой кадров, ведет к очень простой реализации.

Дополнительные признаки могут быть найдены в прилагаемой формуле изобретения.

Настоящее изобретение относится также к устройству, которое выполнено с возможностью выполнять заявленный способ, и к видеоприемнику, который включает в себя такое устройство.

Следует отметить, что термин 'подсоединенный', используемый в формуле изобретения, не должен интерпретироваться как ограничивающийся только прямыми соединениями. Таким образом, контекст выражения 'устройство A, подсоединенное к устройству B' не должен ограничиваться устройствами или системами, где вывод устройства A непосредственно подсоединен к входу устройства B. Это означает, что существует маршрут между выводом A и входом B, который может быть маршрутом, включающим в себя другие устройства или средства.

Следует отметить, что термин 'содержащий', используемый в формуле изобретения, не должен интерпретироваться как ограниченный значениями, перечисленными впоследствии. Таким образом, контекст выражения 'устройство содержит средство A и B' не должен ограничиваться устройствами, состоящими только из компонентов A и B. Это означает, что относительно настоящего изобретения только значимыми компонентами устройства являются A и B.

Вышеописанные и другие объекты и признаки изобретения станут более очевидными, а само изобретение будет лучше понято посредством ссылки на последующее описание варианта осуществления, взятого вместе с сопровождающими чертежами, на которых:

Фиг. 1 показывает основную архитектуру системы передачи видео,

Фиг. 2a-c показывают детали процесса кодирования в примере с SVC/AVC-кодированными кадрами,

Фиг. 3a-c показывают дополнительные детали процесса инкапсуляции и передачи для примера на фиг. 2,

Фиг. 4 показывает часть процесса приема по примерам на фиг. 2 и 3,

Фиг. 5 показывает пример подробной блок-схемы последовательности операций для выполнения способа согласно изобретению, и

Фиг. 6 показывает результат после операции переупорядочивания и мультиплексирования в соответствии с изобретением по примерам, изложенным на фиг. 2, 3 и 4.

Настоящее изобретение может использоваться в кодировании мультимедиа, таком как устройства кодирования видео и/или аудио. Более конкретно, это изобретение может использоваться вместе с масштабируемым видеокодеком, обозначенным аббревиатурой SVC, закодированные посредством которого элементарные блоки, называемые NAL-блоками, инкапсулируются и транспортируются с помощью RTP, являющимся протоколом реального времени, использующим нечередующийся режим и режим одного NAL-блока. Однако оно может использоваться во всех областях, где пакеты из потоков мультимедийных данных, принадлежащих взаимосвязанным сеансам, необходимо переупорядочивать с тем, чтобы согласовывать с предварительно определенным порядком, который запрашивается декодером. В целом, эта последовательность соответствует последовательности, сгенерированной кодером.

Способ SVC-кодирования стандартизирован стандартом MPEG-4 AVC (часть 10 ISO/IEC 14496). Чтобы транспортировать H.264 AVC, полезная нагрузка RTP (транспортного протокола реального времени), предназначенная для H.264 AVC, стандартизирована IETF RFC3984. SVC охватывает все диапазоны применения H.264/AVC, начиная от приложений потоковой передачи в Интернете с низкой скоростью передачи битов до HDTV-вещания и цифрового кинотеатра с почти не имеющим потерь кодированием и требующим десятки или сотни Мбит/с.

Формат полезной нагрузки RTP допускает пакетирование части или одного или более блоков сетевого уровня абстракции (NAL), созданных SVC-видеокодером, в полезной нагрузке каждого RTP-пакета. Формат полезной нагрузки имеет широкую применимость, в диапазоне от диалогового с низкой скоростью передачи битов, через потоковую передачу Интернет-видео, до видео со зрелищным качеством с высокой скоростью передачи битов.

Хорошо известным образом, один SVC-поток, заключающий различные точки представления или представления масштабируемого слоя, транспортируется по нескольким транспортным каналам с использованием протокола RTP. Это означает, что SVC-поток состоит из нескольких масштабируемых слоев, на основании чего, каждый слой транспортируется по одному отдельному RTP-каналу. Эти различные точки представления принадлежат одному и тому же контенту, но предлагают различный формат или качество видео, чтобы принимать во внимание конкретные требования приемника. Это, например, случай, когда один и тот же видеоконтент должен предназначаться для различных размеров экрана, например QVGA для карманных устройств, HDTV для плоского экрана высшего класса, VGA для экрана PDA. Это представляется с помощью SVC-концепции наслоения, где один масштабируемый битовый поток вмещает в себя слои, которые формируют, по меньшей мере, два, но иногда много больше представлений масштабируемого слоя. В этом случае, каждый SVC-слой будет транспортироваться через выделенный RTP-сеанс с возможно отличающимся сетевым маршрутом, где каждый SVC-слой, улучшающий формат или качество видео, может быть восстановлен из более низких зависимых слоев. Каждый SVC-слой, транспортируемый в одном конкретном RPT-потоке, должен быть декодирован в комбинации со всеми зависимыми более низкими слоями в других RTP-потоках, чтобы восстанавливать заданную точку представления или представление SVC-слоя. Соотношение между RTP-потоками, принадлежащими одному и тому же SVC-видеоконтенту, указывается посредством протокола сигнализации, являющегося SDP-протоколом в случае RTP-потоков. В этом конкретном случае, использование стандартизированных проектом линий "a=зависеть" каждого сеанса будет указывать RTP-сеансы, подходящие друг другу. Используя полезную нагрузку RTP для транспортирования таких SVC-закодированных видеопотоков, каждый из которых состоит из последовательности NAL-блоков, возможно, что все эти потоки прибудут в другом порядке в приемник. Как упомянуто ранее, важная проблема состоит из повторной синхронизации этих NAL-блоков в приемнике. Это важно, поскольку декодеру нужно иметь их в правильной последовательности с тем, чтобы позволять декодирование с помощью SVC/H.264. Проблема еще больше затрудняется, когда эти различные SVC-потоки могут, таким образом, транспортироваться по различным RTP-сеансам, через различные каналы, имеющие различные слои.

Известные процедуры, чтобы решать этот механизм синхронизации между слоями, обсуждались в предыдущих параграфах этого документа и полагаются на взаимосвязь между "синхронизированными временными метками" (точками синхронизации), учитывая либо соответствия времени таймера/временной метки в отчетах RTCP-отправителя для каждого RTP-сеанса, либо непосредственно общее указание на временные метки и масштаб для всех RTP-сеансов. Еще одно использование концепции номера порядка декодирования между слоями (CL-DON) или DON (чередующийся режим), которая использует концепцию одного последовательного номера среди различных RTP-сеансов, позволяет находить правильную последовательность пакетов, разбросанных по различным сеансам.

На фиг. 1 изображена основная архитектура такой глобальной системы передачи видео, а основные этапы кодирования с помощью AVC/SVC-протокола будут объяснены посредством фиг. 2 и 3.

Фиг. 1 изображает видеопередатчик VT для передачи пакетированного потока, вмещающего в себя закодированные видеоданные, видеоприемнику VR через сеть PN пакетной передачи, такую как сеть Интернет.

Видеопередатчик VT типично содержит типичное устройство 1 захвата видео, видеокодер 2, устройство 3 инкапсуляции, устройства 4 сигнализации и сетевое устройство 5 передачи. Реализации или варианты осуществления всех устройств будут теперь обсуждаться для примера, использующего AVC/SVC-кодирование с помощью RTP-инкапсуляции и потоковой передачи.

Видеопередатчик VT на фиг. 1 содержит устройство 1 захвата видео, такое как видеокамера, способное генерировать видеокадры с ассоциированными с ними моментами дискретизации. Поток, сгенерированный этим устройством захвата, изображен на фиг. 2a, и состоит из множества кадров, идентифицированных индексом (F1, F2, F3,…), ассоциированным с моментами дискретизации (t1, t2, t3,…). Время дискретизации, как правило, выводится из таймера дискретизации, который является локальным по отношению к устройству захвата и который запускает оптический датчик камеры. Для устройств захвата, работающих с постоянной частотой кадров, получается фиксированный период времени между последовательными кадрами. Кадры на выходе этого устройства захвата доставляются в возрастающем порядке времени дискретизации, как показано на фиг. 2a, этот возрастающий порядок является таким же, что и порядок индексов кадров, который также является требуемым порядком отображения. Такие устройства захвата не только ограничены устройствами камер, доставляющих сцены видео в реальном времени, но могут состоять из любого устройства, способного доставлять кадры в возрастающем порядке времени дискретизации, с моментами дискретизации, ассоциированными с каждым кадром, в том числе любого устройства, доставляющего сохраненный видеоконтент или видеоконтент в реальном времени (канал в реальном времени, VoD-платформа), локально сгенерированный или приходящий от внешнего поставщика видеоконтента. Моменты дискретизации, ассоциированные с кадрами, пересылаются кодеру 2 видео, в этом примере являющемуся SVC-кодером, чтобы запускать процесс кодирования кадров, и устройству 3 инкапсуляции, в этом примере являющемуся устройством потоковой RTP-передачи, которое будет использовать эту информацию, чтобы устанавливать временные метки RTP в случае устройства потоковой RTP-передачи.

Кодер 2 видео H.264 SVC, также включенный в видеопередатчик VT, выполнен с возможностью кодировать поток кадров, который принимается от устройства 1 захвата, в набор из, по меньшей мере, двух масштабируемых слоев, которые взаимосвязаны, чтобы формировать набор точек представления, предоставляющих другой пространственный/временной/качественный видеоформат. На фиг. 2b показан пример конфигурации SVC-видеокодера. В этом примере показан SVC-поток, включающий в себя два слоя L0 и L1, так что декодирование только L0 ведет к точке представления в QCIF, являющейся форматом размера экрана 176×144 пикселей, и в этом примере выбрана частота кадров, равная 15 кадров в секунду, и декодирование L0 вместе с L1 ведет к точке представления в CIF, соответствующей 352×288 пикселей, что является другим примером другого формата отображения с выбранной частотой кадров в 30 кадров в секунду. С такой конфигурацией и, как правило, с конфигурациями, полагающимися на масштабируемость на основе иерархических B-кадров, порядок кадров на входе кодера, который связан с порядком моментом дискретизации и равен индексу кадров на фиг. 2a и показан линией "кадр/AU-индекс" на фиг. 2b, отличается от порядка кодирования кадров/блоков доступа на выходе видеокодера, который показан линией "порядок кодирования AU" на фиг. 2b. Согласно схеме SVC/AVC-кодирования видеокодер генерирует на своем выходе поток NAL-блоков, упорядоченных по порядку кодирования NAL-блоков, изображенному на фиг. 2c. Этот чертеж указывает для каждого NAL-блока слой и индекс кадра, на который ссылается NAL; например, первый NAL 1 относится к содержимому масштабируемого слоя L0, индексу F1 кадра, второй NAL 2 относится к содержимому масштабируемого слоя L1, индексу F1 кадра, третий NAL 3 относится к слою L0, индексу F3 кадра и т.д.

Видеокодер также генерирует набор параметров кодирования, обозначенный PS, который будет дополнительно доставляться устройству 4 сигнализации, которое будет обсуждаться в дополнительном параграфе.

Видеопередатчик VT на фиг. 1 дополнительно включает в себя устройство 3 потоковой RTP-передачи для инкапсуляции входящих NAL-блоков в RTP-пакеты согласно одному из режимов пакетирования, определенных в RTP SVC-спецификации RFC3984. Как ранее упомянуто, эти режимы пакетирования содержат режим "одного NAL-блока", "нечередующийся" режим или "чередующийся" режим. В примере, изображенном на фиг. 3a, только способ "одного NAL-блока" рассматривается в качестве объяснения способа. Специалист в данной области техники, конечно, знает, как расширить способ переупорядочивания согласно изобретению для пакетов, инкапсулированных с помощью нечередующегося режима.

Режим одного NAL-блока использует только один NAL-блок для каждого RTP-пакета, как изображено на фиг. 3a. Во время этапа инкапсуляции каждый RTP-заголовок, как изображено на фиг. 3b и стандартизировано в RFC3550, должен быть инициализирован в соответствии со следующими правилами:

1) последовательный номер увеличивается для каждого RTP-пакета, каждый RTP-сеанс, имеющий независимые последовательные номера, начинается со случайных значений. Для ясности на чертежах случайные значения, однако, не используются, а последовательные номера начинаются со значения 1.

2) временная метка (TS) устанавливается согласно моменту дискретизации данных, вмещающихся в пакете, т.е., моменту дискретизации (на фиг. 2a) кадра, к которому относится инкапсулированный NAL. Значение TS вычисляется с помощью следующей формулы: TS=время_дискретизации*частота_TS+ случайное_значение, где частота_TS определена равной 90 кГц для кодека H.264 AVC/SVC. Существуют две возможности: синхронизированная временная метка масштабируется для всех RTP-сеансов (одинаковые случайные значения) или независимая несинхронизированная временная метка масштабируется для каждого из RTP-сеансов (это означает выбор различных случайных значений). Это будет иметь слабое указание на процесс переупорядочивания, который будет объяснен в дальнейшем параграфе этого документа.

3) SSRC (источник синхронизации) идентифицирует уникально каждый RTP-сеанс. На практике, SSRC-значения устанавливаются с помощью неперекрывающихся случайных значений (S0, S1).

Как следствие, устройство 3 потоковой RTP-передачи выполнено с возможностью сопоставлять различные инкапсулированные NAL-блоки на фиг. 2c согласно их индексу масштабируемого слоя (L0, L1) с различными RTP-сеансами с SSRC S0 и S1, как показано на фиг. 3c. Например, NAL-блоки из масштабируемого слоя L0 должны транспортироваться в RTP-сеансе с SSRC=S0, NAL-блоки из масштабируемого слоя L1 должны транспортироваться в RTP-сеансе с SSRC=S1. Как правило, N+1 различных RTP-сеансов от S0 до SN генерируются устройством потоковой RTP-передачи, как показано на фиг. 1.

В нашем примере, вывод устройства 3 потоковой RTP-передачи предоставляет два RTP-сеанса S0 и S1, означающих, что два потока RTP-пакетов, как изображено на фиг. 3c и идентифицировано посредством SSRC S0 и SSRC S1, будут выводиться. RTP-пакеты упорядочиваются согласно порядку передачи, который эквивалентен порядку кодирования блоков доступа. Таким образом, изучение NAL-блоков RTP-пакетов в порядке передачи будет обнаруживать порядок кадров или блоков доступа на фиг. 2b.

Видеопередатчик VT на фиг. 1 дополнительно включает в себя устройство 4 сигнализации, способное генерировать описание мультимедийной услуги, в примере SVC/AVC используя текстовое описание, определенное протоколом описания сеанса (SDP). Этот протокол, в частности, определяет отношение зависимости SVC-слоев/RTP-сеансов, частоту кадров, вмещающихся в каждом SVC-слое/RTP-сеансе, связанные UDP/IP-адрес и порты, на основе информации о наборе H.264-параметров, восстановленной из видеокодера 2. Это устройство сигнализации также отвечает за реализацию транспортного протокола сигнализации, чтобы обмениваться сигнализацией с приемником через IP-сеть. Такими транспортными протоколами сигнализации могут быть, например, RTSP, SAP или просто HTTP. Выходной сигнал, сгенерированный устройством сигнализации, обозначен как SDP на фиг. 1.

Видеопередатчик VT на фиг. 1 дополнительно содержит передающее сетевое устройство 5 для мультиплексирования всех входящих RTP и сигнализационных потоков, для инкапсуляции мультиплексированных пакетов в пакеты для передачи через пакетную сеть, например IP-пакеты для передачи по IP-сети, такой как Интернет, возможно с различными адресами назначения, если используется доставка видео в многоадресном режиме.

Такая пакетная сеть PN, например IP-сеть, отвечает за маршрутизацию и передачу пакетов по адресу назначения. Каждый пакет может следовать по отличающемуся сетевому маршруту, следовательно, подвергаясь переменным задержкам, подвергаясь потерям пакетов и без гарантии сохранения порядка передачи в приемнике. Реальное время передачи каждого RTP-пакета в качестве вывода посредством RTP-устройства будет, таким образом, зависеть от используемого сетевого интерфейса, который возможно будет реализовывать некое управление потоком или механизмы выравнивания трафика. Следовательно, в общем смысле, передача должна рассматриваться как асинхронный процесс, потребляющий RTP-пакеты каждого RTP-сеанса в неопределенные моменты времени.

На стороне приемника, типичный видеоприемник VR, способный восстанавливать поток пакетов, такой как IP-поток из пакетной сети, такой как IP-сеть, как правило, содержит сетевой интерфейс 6, буферы B0-BN, сигнальное устройство 7, декодер 8 и устройство 9 отображения. В зависимости от конкретных использованных протоколов кодирования/инкапсуляции переупорядочивающее устройство R также может быть необходимо, как, например, в случае этого документа. Опять все блоки будут кратко описаны, имея варианты осуществления для дополнительной обработки данных, как в примере на фиг. 2 и 3. Переупорядочивающее устройство R согласно настоящему изобретению будет описано более подробно.

Сетевой интерфейс 6 приемника способен демультиплексировать принятый поток пакетов в различные прикладные потоки, состоящие из RTP-потоков и транспортного потока сигнализации, для подачи в различные RTP-буферы B0-BN в соответствии со значениями SSRC, включенными в RTP-заголовок каждого входящего RTP-пакета, и подавать на устройство 7 сигнализации приемника пакеты сигнализации. Демультиплексирование выполняется с помощью существующих процедур, таких как маршрутизация IP-пакетов согласно их IP-адресам назначения при многоадресной передаче в случае принятых IP-пакетов или согласно их UDP-порту назначения или согласно их RTP SSRC.

RTP-буферы могут хранить последовательно принятые RTP-пакеты, относящиеся к каждому RTP-сеансу S1-SN, которые доставлены сетевым RX-интерфейсом. Эти буферы заполняются асинхронным образом, следуя реальным моментам времени приема каждого RTP-пакета. Буферы также отвечают за хранение RTP-пакетов согласно их последовательным номерам с тем, чтобы переупорядочивать RTP-пакеты, поскольку пакетная сеть, как правило, не гарантирует правильный порядок передачи. RTP-буферы также поглощают различные переменные задержки, вносимые сетью, таким образом, они также называются устраняющими "дрожание" RTP-буферами. Следуя нашему примеру передачи двух слоев/RTP-сеансов, после приема последних переданных пакетов на фиг. 3c, мы получаем содержимое каждого RTP-буфера B0 и B1, которые изображены на фиг. 4. Эти буферы вмещают в себя RTP-пакеты в порядке передачи, идентифицированные своим последовательным номером, значением временной метки (TS) и SSRC, сохраненными в различных сегментах памяти/буферов. Фиг. 4 также показывает для каждого буфера, какие RTP-пакеты будут выводиться первым и последним, что служит в качестве ввода для переупорядочивающего устройства R, этот порядок является эквивалентным порядку последовательных номеров RTP каждого RTP-сеанса.

Видеоприемник VR дополнительно содержит устройство 7 сигнализации, которое, в варианте осуществления для обработки данных нашего примера, отвечает за получение соответствующего SDP-описания посредством любых транспортных протоколов сигнализации и за доставку информации зависимости сеанса и частот кадров для каждого сеанса переупорядочивающему устройству и наборов H.264-параметров устройству 8 SVC-декодера. На фиг. 1 эти наборы H.264-параметров указаны как PS-данные, тогда как другая SDP-информация, доставленная устройству R переупорядочивания и мультиплексирования, обозначена как I.

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

В любом случае это устройство переупорядочивания и мультиплексирования будет доставлять NAL-блоки в правильной последовательности декодеру, который будет соответственно иметь возможность восстанавливать оригинальные кадры в порядке отображения. Кадры на выходе SVC-декодера 8 запущены моментами дискретизации и окончательно доставляются устройству 9 отображения, такому как CRT или другой дисплей, способному отображать входящие кадры в порядке отображения кадров, синхронно с моментами дискретизации, ассоциированными с каждым кадром.

Устройство переупорядочивания и мультиплексирования согласно изобретению выполнено с возможностью сначала идентифицировать общую переменную тактирования, такую как синхронизированная временная метка TS, которая является временной меткой RTP-заголовка, связанной с моментом дискретизации на фиг. 2a, ассоциированным со следующим блоком доступа или кадром, посредством считывания этого TS-значения следующего пакета из буфера Ssync, Ssync является RTP-сеансом с самой высокой частотой кадров, и затем декапсулировать все RTP-пакеты между RTP-сеансами, следуя зависимости сеансов, чтобы выводить NAL-блоки в порядке декодирования NAL-блоков, как изображено на фиг. 6. Отметим, что фиг. 6 показывает подобный порядок, что и на фиг. 2c, который является порядком, который мы должны соблюдать при подаче в SVC-декодер 8. Это устройство R, таким образом, восстанавливает моменты дискретизации, ассоциированные с кадрами, посредством считывания TS, включенной в RTP-заголовки RTP-пакетов, ассоциированных с каждым AU, и дополнительно предоставляет эту информацию как SVC-декодеру 8, так и устройству 9 отображения, чтобы запускать процесс декодирования и отображения получающегося в результате кадра, так что оба устройства синхронизированы по моментам дискретизации, которые также использовались в передатчике. Таким образом, гарантируется аспект реального времени доставки видео.

Следует сделать замечание относительно ситуации, где либо общий масштаб временных RTP-меток используется для всех RTP-сеансов (синхронизированные временные метки), либо различные масштабы временных меток для RTP-сеансов (несинхронизированные временные метки) используются с другой стороны. В последнем случае, TS, включенная в RTP-заголовок каждого пакета, должна сначала быть транслирована в общую переменную тактирования, такую как общая привязка ко времени таймера, используя хорошо известные механизмы RFC3550 (соответствия RTCP/таймера) перед считыванием посредством предложенного алгоритма.

Способ и устройство согласно изобретению в основном касаются блока R из архитектуры, изображенной на фиг. 1. В целом, это устройство мультиплексирования и переупорядочивания пакетов выполнено с возможностью принимать пакеты, принадлежащие различным N+1 демультиплексированным RTP-потокам N+1 буферов S0-SN, в видеоприемнике VR и дополнительно выполнено с возможностью извлекать из них NAL-блоки и помещать их в правильной последовательности для дальнейшей доставки декодеру D в качестве единого потока.

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

Подробный вариант осуществления для реализации такого способа поясняется посредством фиг. 6. Способ начинается с приема RTP-пакетов из RTP-буферов, и параллельно определения списка действующих сеансов, на основе вывода устройства 7 SDP-сигнализации. Список действующих сеансов, таким образом, принимается от устройства 7 со всей требуемой информацией по каждому сеансу. Список действующих сеансов может быть поднабором всех сеансов, определенным в SDP, зависящим от типа терминала, например PDA, будет присоединяться только к двум действующим сеансам, поскольку третий, предоставляющий HDTV, не является полезным для PDA. Выбор т