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

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

Info

Publication number
RU2510908C2
RU2510908C2 RU2009134515/07A RU2009134515A RU2510908C2 RU 2510908 C2 RU2510908 C2 RU 2510908C2 RU 2009134515/07 A RU2009134515/07 A RU 2009134515/07A RU 2009134515 A RU2009134515 A RU 2009134515A RU 2510908 C2 RU2510908 C2 RU 2510908C2
Authority
RU
Russia
Prior art keywords
nal
blocks
nal data
images
indication
Prior art date
Application number
RU2009134515/07A
Other languages
English (en)
Other versions
RU2009134515A (ru
Inventor
Миска ХАННУКСЕЛА
Йе-Куи ВАНГ
Original Assignee
Нокиа Корпорейшн
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Нокиа Корпорейшн filed Critical Нокиа Корпорейшн
Publication of RU2009134515A publication Critical patent/RU2009134515A/ru
Application granted granted Critical
Publication of RU2510908C2 publication Critical patent/RU2510908C2/ru

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/70Media network packetisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]

Abstract

Изобретение относится к системам передачи аудио-видео данных на основе транспортного протокола реального времени (RTP). Техническим результатом является создание усовершенствованной технологии предоставления в транспортных пакетах или в агрегированных блоках уровня сетевой абстракции (NAL) файлового формата информации, на основе которой сетевой промежуточный блок или медиаплейер может принять решение, какой блок кодированных данных следует передать и/или обработать. Указанный технический результат достигается тем, что в системе и способе передачи данных используется механизм для указания таких элементов, как избыточные кодированные изображения, точки переключения временных уровней, точки доступа к постепенному обновлению декодирования, идентификаторы ракурса и точки произвольного доступа к ракурсу. Затем промежуточный блок и/или приемник могут использовать эту информацию для определения, следует ли передавать и/или обрабатывать конкретные блоки кодированных данных. 6 н .и 4 з.п. ф-лы, 3 ил.

Description

ОБЛАСТЬ ТЕХНИКИ
[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, определяемые ниже.
Figure 00000001
[0035] Значения полей в блоке PACSI NAL установлены следующим образом. Бит F устанавливают в 1, если бит F по меньшей мере в одном из оставшихся блоков NAL в полезной нагрузке равен 1. В противном случае бит F устанавливают в 0. Значение в поле NRI устанавливают равным самому высокому значению поля NRI среди всех оставшихся блоков NAL в полезной нагрузке. Поле Type устанавливают равным 30.
[0036] Заголовок CI содержит флаги, индицирующие наличие различных типов информации контента следующим образом:
Figure 00000002
[0037] Бит S, равный 1, указывает на присутствие информации о масштабируемости контента, определенной в проекте документа Интернет draft-wenger-avt-rtp-svc-03 (доступен по адресу wenger-avt-rtp-svc-03 и включен в настоящее описание путем ссылки) и приведенной ниже:
Figure 00000003
[0038] Когда бит M равен 1, в полезной нагрузке CI присутствует следующая информация о многоракурсном контенте:
Figure 00000004
[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 присутствует следующая информация о временном уровне:
Figure 00000005
[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, расширен с добавлением еще одного восьмибитового байта следующим образом.
Figure 00000006
[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 инкапсулирует двоичный поток кодированных медиаданных в пакеты RTP согласно формату полезной нагрузки RTP. Как правило, каждый вид медиаданных имеет специфический формат полезной нагрузки RTP. Вновь следует подчеркнуть, что система может содержать больше одного передатчика 130, но, для простоты, в последующем описании рассматривается только один передатчик 130.
[0059] Передатчик 130 может быть связан со шлюзом 140 через систему связи, но может и не иметь такой связи. Шлюз 140 может выполнять различные функции, например преобразование пакетного потока из стека одного протокола связи в стек другого протокола связи, слияние и разбиение потоков данных и преобразование потока данных согласно возможностям нисходящей связи и/или приемника, например управление скоростью передачи данных передаваемого потока согласно преобладающим условиям нисходящей связи в сети. Примеры шлюзов 140 включают блоки управления многосторонней конференц-связью (MCU, Multipoint Conference Control Unit), шлюзы для переключения между телефонной связью на основе коммутации пакетов или на основе коммутации каналов, серверы типа «нажал-говори по сотовой связи» (РоС, Push-to talk over Cellular), инкапсуляторы протокола Интернет в системах цифрового стандарта передачи цифрового телевидения на мобильные устройства (DVB-H) или абонентские приставки, которые локально направляют транслируемые данные в домашние беспроводные сети. При использовании протокола транспортного уровня шлюз 140 называется микшером RTP и действует как конечная точка соединения RTP.
[0060] Система включает один или несколько приемников 150, обычно способных принимать, демодулировать и декапсулировать переданный сигнал в двоичный поток кодированных медиаданных. Двоичный поток кодированных медиаданных обычно затем обрабатывают декодером 160, на выходе которого формируется один или несколько потоков несжатых медиаданных. Наконец, рендерер 170 может воспроизвести потоки несжатых медиаданных, например, с помощью громкоговорителя или дисплея. Приемник 150, декодер 160 и рендерер 170 могут быть размещены в одном физическом устройстве, или они могут быть включены в отдельные устройства.
[0061] Следует отметить, что двоичный поток для декодирования может быть принят от удаленного устройства, расположенного в пределах сети фактически любого типа. Кроме того, двоичный поток может быть принят из локальных аппаратных средств или программного обеспечения.
[0062] Желательным свойством при наличии неоднородных и подверженных ошибкам сред является масштабируемость в отношении скорости передачи данных, сложности декодирования и размера изображения. Это свойство желательно для преодоления ограничений, таких как ограничения на скорость передачи данных, разрешение дисплея, пропускную способность сети и вычислительную мощность приемного устройства.
[0063] Устройства связи в рамках настоящего изобретения могут осуществлять связь с использованием различной техники передачи, включая, но этим не ограничиваясь, множественный доступ с кодовым разделением (CDMA, Code Division Multiple Access), глобальную систему для мобильной связи (GSM, Global System for Mobile Communications), универсальную систему мобильной связи (UMTS, Universal Mobile Telecommunications System), множественный доступ с временным разделением каналов (TDMA, Time Division Multiple Access), множественный доступ с частотным разделением каналов (FDMA, Frequency Division Multiple Access), Протокол управления передачей/Протокол Интернет (TCP/IP, Transmission Control Protocol/Internet Protocol), Службу обмена короткими сообщениями (SMS, Short Messaging Service), Службу передачи мультимедиа-сообщений (MMS, Multimedia Message Service), электронную почту, Службу передачи мгновенных сообщений (IMS, Instant Messaging Service), стандарты Bluetooth, IEEE 802.11 и т.д. Устройство связи может осуществлять связь с использованием различных сред, включая, но не ограничиваясь этим, радиосвязь, инфракрасное излучение, лазерное излучение, кабельное соединение и т.п.
[0064] На фиг.2 и 3 показано одно репрезентативное электронное устройство 50, в котором может быть реализовано настоящее изобретение. Однако должно быть понятно, что настоящее изобретение не ограничено одним конкретным типом устройства. Электронное устройство 50 на фиг.2 и 3 включает корпус 30, дисплей 32 в виде жидкокристаллического дисплея, клавиатуру 34, микрофон 36, телефон 38, батарею 40, инфракрасный порт 42, антенну 44, смарт-карту 46 в стандарте UICC согласно одному из вариантов выполнения настоящего изобретения, считывающее устройство 48 для карты, схему 52 радиоинтерфейса, схему 54 кодека, контроллер 56 и память 58. Все отдельные схемы и элементы являются известными в данной области техники, например используются в мобильных телефонах фирмы Nokia.
[0065] Различные варианты выполнения настоящего изобретения, рассмотренные выше, были описаны в контексте шагов или процессов в рамках способа, который может быть реализован в одном из вариантов выполнения настоящего изобретения в виде компьютерного программного продукта, записанного на машиночитаемом носителе и содержащего выполняемые на компьютере инструкции, например программные коды, выполняемые компьютерами, включенными в сеть. Машиночитаемый носитель может включать съемные и несъемные запоминающие устройства, включая, но этим не ограничиваясь, постоянное запоминающее устройство (ROM, Read Only Memory), оперативное запоминающее устройство (RAM, Random Access Memory), компакт-диски (CD, compact disc), цифровые универсальные диски (DVD, Digital versatile disc) и т.д. В общем случае, программные модули могут включать процедуры, программы, объекты, компоненты, структуры данных и т.д., которые выполняют конкретные задачи или реализуют конкретные абстрактные типы данных. Выполняемые на компьютере инструкции, ассоциированные структуры данных и программные модули представляют собой примеры программного кода, предназначенного для выполнения шагов для способов, раскрытых выше. Конкретная последовательность таких выполняемых инструкций или ассоциированных структур данных представляет примеры соответствующих действий, предназначенных для выполнения функций, описанных в таких шагах или процессах.
[0066] Варианты выполнения настоящего изобретения могут быть реализованы в программном обеспечении, аппаратных средствах, прикладной логике или комбинации программного обеспечения, аппаратных средств и прикладной логики. Программное обеспечение, прикладная логика и/или аппаратные средства могут быть реализованы, например, в виде набора микросхем, мобильного устройства, рабочего места, портативного компьютера или сервера. Программное обеспечение и интегрирование в сеть различных вариантов выполнения настоящего изобретения может быть достигнуто с помощью стандартных методов программирования с использованием логики на основе правил и другой логики, обеспечивающей различные шаги и процессы поиска в базе данных, шаги или процессы корреляции, шаги или процессы сравнения и шаги или процессы принятия решения. Различные варианты выполнения настоящего изобретения могут также быть полностью или частично реализованы в пределах сетевых элементов или модулей. Следует отметить, что слова "компонент" и "модуль" в контексте настоящего описания и в последующих пунктах формулы изобретения призваны охватить выполнение с использованием одной или нескольких строк программного кода, и/или аппаратных средств, и/или оборудования для приема данных, вводимых вручную.
[0067] Предыдущее изложение вариантов выполнения настоящего изобретения было дано только с целью иллюстрации и описания. Предыдущее описание не предполагается исчерпывающим или ограничивающим варианты выполнения настоящего изобретения точными раскрытыми формами, и поэтому возможны изменения и вариации в рамках вышеупомянутого описания или знаний, полученных из практического использования различных вариантов выполнения настоящего изобретения. Варианты выполнения настоящего изобретения, обсуждаемые выше, были выбраны и описаны для пояснения настоящего изобретения и его практического приложения, что позволит специалистам в данной области техники использовать настоящее изобретение в его различных вариантах и с различными изменениями для конкретных целей. Описанные выше особенности вариантов выполнения настоящего изобретения могут быть объединены во всевозможные комбинации способов, устройств, модулей, систем и компьютерных программных продуктов.

Claims (10)

1. Способ пакетирования кодированного представления видеопоследовательности, включающий:
пакетирование множества блоков данных уровня сетевой абстракции (NAL, Network Abstraction Layer) в пакет транспортного протокола реального времени (RTP, Real-time Transport Protocol) для передачи видеопоследовательности в реальном времени,
при этом первый блок данных NAL из множества блоков данных NAL включает по меньшей мере часть кодированных видеоданных, а второй блок данных NAL из множества блоков данных NAL включает информацию, резюмирующую контент этой части кодированных видеоданных, причем второй блок данных NAL помещают перед любым другим блоком данных NAL из множества блоков данных NAL в пакете RTP; и
предоставление во втором блоке данных NAL индикации характеристики кодированного представления упомянутой видеопоследовательности, при этом указанная индикация включает по меньшей мере одно из следующего:
индикацию избыточных кодированных изображений в пределах множества блоков данных NAL, указывающую на то, что все блоки множества блоков данных NAL в пакете RTP содержат только избыточные кодированные изображения;
индикацию изображений произвольного доступа к ракурсу в пределах множества блоков данных NAL, указывающую на то, что все блоки множества блоков данных NAL в пакете RTP содержат только якорные (опорные) изображения;
индикацию изображений произвольного доступа в пределах множества блоков данных NAL, указывающую на то, что все блоки множества блоков NAL в пакете RTP содержат только изображения с внутренним кодированием.
2. Способ по п.1, дополнительно включающий предоставление во втором блоке данных NAL индикации характеристики, которая является общей для всех блоков множества блоков данных NAL.
3. Машиночитаемый носитель, содержащий программный код, исполнение которого в компьютере осуществляет способ по п.1 или 2.
4. Устройство для пакетирования кодированного представления видеопоследовательности, содержащее:
процессор; и
блок памяти, связанный с процессором с возможностью обмена данными, при этом процессор сконфигурирован так, чтобы заставить устройство:
пакетировать множество блоков данных NAL в пакет RTP для передачи видеопоследовательности в реальном времени,
при этом первый блок данных NAL из множества блоков данных NAL включает по меньшей мере часть кодированных видеоданных, а второй блок данных NAL из множества блоков данных NAL включает информацию, резюмирующую контент этой части кодированных видеоданных, причем второй блок данных NAL помещен перед любым другим блоком данных NAL из множества блоков данных NAL в пакете RTP; и
предоставлять во втором блоке данных NAL индикацию характеристики кодированного представления упомянутой видеопоследовательности, при этом указанная индикация включает по меньшей мере одно из следующего: индикацию избыточных кодированных изображений в пределах множества блоков данных NAL, указывающую на то, что все блоки множества блоков данных NAL в пакете RTP содержат только избыточные кодированные изображения; индикацию изображений произвольного доступа к ракурсу в пределах множества блоков данных NAL, указывающую на то, что все блоки множества блоков данных NAL в пакете RTP содержат только якорные изображения; индикацию изображений произвольного доступа в пределах множества блоков данных NAL, указывающую на то, что все блоки множества блоков NAL в пакете RTP содержат только изображения с внутренним кодированием.
5. Устройство по п.4, в котором процессор дополнительно сконфигурирован так, чтобы заставить устройство предоставлять во втором блоке данных NAL индикацию характеристики, которая является общей для всех блоков множества блоков данных NAL.
6. Способ обработки пакетированного битового потока, представляющего видеопоследовательность, включающий:
извлечение множества блоков данных NAL из пакета RTP, принятого при передаче видеопоследовательности в реальном времени, при этом первый блок данных NAL из множества блоков данных NAL включает по меньшей мере часть кодированных видеоданных, а второй блок данных NAL из множества блоков данных NAL включает информацию, резюмирующую контент этой части кодированных видеоданных, причем второй блок данных NAL расположен перед любым другим блоком данных NAL из множества блоков данных NAL в пакете RTP;
извлечение из второго блока данных NAL индикации характеристики кодированного представления упомянутой видеопоследовательности, при этом указанная индикация включает по меньшей мере одно из следующего:
индикацию избыточных кодированных изображений в пределах множества блоков данных NAL, указывающую на то, что все блоки множества блоков данных NAL в пакете RTP содержат только избыточные кодированные изображения;
индикацию изображений произвольного доступа к ракурсу в пределах множества блоков данных NAL, указывающую на то, что все блоки множества блоков данных NAL в пакете RTP содержат только якорные изображения;
индикацию изображений произвольного доступа в пределах множества блоков данных NAL, указывающую на то, что все блоки множества блоков NAL в пакете RTP содержат только изображения с внутренним кодированием; и
обработку множества блоков данных NAL на основе информации, содержащейся внутри второго блока данных NAL.
7. Способ по п.6, в котором второй блок данных NAL включает индикацию характеристики, которая является общей для всех блоков множества блоков данных NAL.
8. Машиночитаемый носитель, содержащий программный код, исполнение которого в компьютере осуществляет способ по п.6 или 7.
9. Устройство для обработки пакетированного битового потока, представляющего видеопоследовательность, содержащее:
процессор; и
блок памяти, связанный с процессором с возможностью обмена данными, при этом процессор сконфигурирован так, чтобы заставить устройство:
извлекать множество блоков данных NAL из пакета RTP, принятого при передаче видеопоследовательности в реальном времени, при этом первый блок данных NAL из множества блоков данных NAL включает по меньшей мере часть кодированных видеоданных, а второй блок данных NAL из множества блоков данных NAL включает информацию, резюмирующую контент этой части кодированных видеоданных, причем второй блок данных NAL расположен перед любым другим блоком данных NAL из множества блоков данных NAL в пакете RTP;
извлекать из второго блока данных NAL индикацию характеристики кодированного представления упомянутой видеопоследовательности, при этом указанная индикация включает по меньшей мере одно из следующего:
индикацию избыточных кодированных изображений в пределах множества блоков данных NAL, указывающую на то, что все блоки множества блоков данных NAL в пакете RTP содержат только избыточные кодированные изображения;
индикацию изображений произвольного доступа к ракурсу в пределах множества блоков данных NAL, указывающую на то, что все блоки множества блоков данных NAL в пакете RTP содержат только якорные изображения;
индикацию изображений произвольного доступа в пределах множества блоков данных NAL, указывающую на то, что все блоки множества блоков NAL в пакете RTP содержат только изображения с внутренним кодированием; и
обрабатывать множество блоков данных NAL на основе информации, содержащейся внутри второго блока данных NAL.
10. Устройство по п.9, в котором второй блок данных NAL включает индикацию характеристики, которая является общей для всех блоков множества блоков данных NAL.
RU2009134515/07A 2007-02-23 2008-02-22 Описание характеристик агрегированных блоков медиаданных с обратной совместимостью RU2510908C2 (ru)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US89148507P 2007-02-23 2007-02-23
US60/891,485 2007-02-23
PCT/IB2008/050642 WO2008102323A2 (en) 2007-02-23 2008-02-22 Backward-compatible characterization of aggregated media data units

Publications (2)

Publication Number Publication Date
RU2009134515A RU2009134515A (ru) 2011-04-10
RU2510908C2 true RU2510908C2 (ru) 2014-04-10

Family

ID=39710591

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2009134515/07A RU2510908C2 (ru) 2007-02-23 2008-02-22 Описание характеристик агрегированных блоков медиаданных с обратной совместимостью

Country Status (11)

Country Link
US (1) US8619868B2 (ru)
EP (1) EP2119187B1 (ru)
KR (1) KR101087379B1 (ru)
CN (1) CN101611612A (ru)
AR (1) AR065465A1 (ru)
CA (1) CA2676195C (ru)
MY (1) MY160436A (ru)
RU (1) RU2510908C2 (ru)
SG (1) SG179403A1 (ru)
TW (1) TWI435612B (ru)
WO (1) WO2008102323A2 (ru)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
WO2008047258A2 (en) * 2006-10-20 2008-04-24 Nokia Corporation System and method for implementing low-complexity multi-view video coding
EP2123049B1 (en) 2007-01-18 2016-12-28 Nokia Technologies Oy Carriage of sei messages in rtp payload format
WO2008102323A2 (en) * 2007-02-23 2008-08-28 Nokia Corporation Backward-compatible characterization of aggregated media data units
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
US20130097334A1 (en) * 2010-06-14 2013-04-18 Thomson Licensing Method and apparatus for encapsulating coded multi-component video
US8520080B2 (en) 2011-01-31 2013-08-27 Hand Held Products, Inc. Apparatus, system, and method of use of imaging assembly on mobile terminal
US9706227B2 (en) * 2011-03-10 2017-07-11 Qualcomm Incorporated Video coding techniques for coding dependent pictures after random access
KR101885852B1 (ko) * 2011-09-29 2018-08-08 삼성전자주식회사 컨텐트 전송 및 수신 방법 및 장치
CN104221390B (zh) * 2012-04-26 2018-10-02 高通股份有限公司 用于处置低等待时间流送的增强型块请求流送系统
US20140241439A1 (en) * 2012-06-29 2014-08-28 Telefonaktiebolaget L M Ericsson (pulb) Transmitting Apparatus and Method Thereof for Video Processing
US9667959B2 (en) 2013-03-29 2017-05-30 Qualcomm Incorporated RTP payload format designs
US10516718B2 (en) * 2015-06-10 2019-12-24 Google Llc Platform for multiple device playout
KR102477964B1 (ko) * 2015-10-12 2022-12-16 삼성전자주식회사 미디어 전송 시스템에서 비디오 비트스트림의 임의 접근 및 재생을 가능하게 하는 기법
US10958988B2 (en) * 2017-03-24 2021-03-23 Mediatek Inc. Methods and apparatus for media content asset changes
TWI690202B (zh) * 2018-12-28 2020-04-01 瑞昱半導體股份有限公司 用於控制媒體播放器中之串流緩衝器的方法與相關的緩衝裝置
KR20210134390A (ko) * 2019-03-11 2021-11-09 후아웨이 테크놀러지 컴퍼니 리미티드 인코더, 디코더 및 대응 방법
CN114097238A (zh) * 2019-05-06 2022-02-25 华为技术有限公司 视频译码中开始新编码视频序列的图像的先前图像的输出
CN113453006B (zh) * 2020-03-25 2024-04-16 腾讯美国有限责任公司 一种图片封装方法、设备以及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999037072A2 (en) * 1998-01-15 1999-07-22 Apple Computer, Inc. Method and apparatus for media data transmission
WO2003098475A1 (en) * 2002-04-29 2003-11-27 Sony Electronics, Inc. Supporting advanced coding formats in media files
WO2004036916A1 (en) * 2002-10-15 2004-04-29 Koninklijke Philips Electronics N.V. System and method for transmitting scalable coded video over an ip network
RU2005115469A (ru) * 2002-10-22 2005-10-27 Конинклейке Филипс Электроникс Н.В. (Nl) Сигнализация внедренных данных

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2352350B (en) * 1999-07-19 2003-11-05 Nokia Mobile Phones Ltd Video coding
KR100560843B1 (ko) * 2003-04-10 2006-03-13 에스케이 텔레콤주식회사 비디오 부호기에서 적응 움직임 벡터의 탐색 영역을결정하는 방법 및 장치
US20040218669A1 (en) * 2003-04-30 2004-11-04 Nokia Corporation Picture coding method
US20050008240A1 (en) * 2003-05-02 2005-01-13 Ashish Banerji Stitching of video for continuous presence multipoint video conferencing
CN101686365B (zh) 2004-04-28 2011-12-07 松下电器产业株式会社 流产生装置和方法,流再现装置、方法和系统,流记录方法
US7903737B2 (en) * 2005-11-30 2011-03-08 Mitsubishi Electric Research Laboratories, Inc. Method and system for randomly accessing multiview videos with known prediction dependency
US8767818B2 (en) * 2006-01-11 2014-07-01 Nokia Corporation Backward-compatible aggregation of pictures in scalable video coding
KR101120648B1 (ko) * 2006-10-16 2012-03-23 노키아 코포레이션 멀티뷰 비디오 코딩에서 효율적인 디코딩된 버퍼 관리를 구현하기 위한 시스템 및 방법
WO2008102323A2 (en) * 2007-02-23 2008-08-28 Nokia Corporation Backward-compatible characterization of aggregated media data units

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999037072A2 (en) * 1998-01-15 1999-07-22 Apple Computer, Inc. Method and apparatus for media data transmission
WO2003098475A1 (en) * 2002-04-29 2003-11-27 Sony Electronics, Inc. Supporting advanced coding formats in media files
WO2004036916A1 (en) * 2002-10-15 2004-04-29 Koninklijke Philips Electronics N.V. System and method for transmitting scalable coded video over an ip network
RU2005115469A (ru) * 2002-10-22 2005-10-27 Конинклейке Филипс Электроникс Н.В. (Nl) Сигнализация внедренных данных

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANTHONY VETRO et al, Joint Draft 2.0 on Multiview Video Coding, Joint Video Team (JVT) of ISO/IEC MPEG & ITU-T VCEG, JVT-V209, Marrakech, January 13-19, 2007. WENGER M. et al, RTP Payload Format for H.264 Video; rfc3984.txt, IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1 February 2005 . S. WENGER, Y.-K. WANG, RTP Payload Format for SVC Video, Versions 00, draft-wenger-avt-rtp-svc-02.txt, найдено в Интернет на http://tools.ietf.org/html/draft-wenger-avt-rtp-svc-02, June 2006. A. ARGYRIOU et al, Streaming H.264/AVC video over the Internet, Consumer Communications and Networking Conference,CCNC 2004. First IEEE (2004), c.c.169-174, найдено в Интернет http://citeseerx. ist. psu.edu/viewdoc/summary?doi=10.1.1.60.6587. WENXIAN YANG et al, Efficient Multiview Video Coding Based on MPEG-4, Advances in Multimedia Information Processing - PCM 2004, Lecture Notes in Computer Science, Volume 3333, Springer Berlin/Heidelberg, 2004, abstract *

Also Published As

Publication number Publication date
CN101611612A (zh) 2009-12-23
EP2119187A2 (en) 2009-11-18
CA2676195C (en) 2013-07-23
TW200843520A (en) 2008-11-01
RU2009134515A (ru) 2011-04-10
CA2676195A1 (en) 2008-08-28
WO2008102323A2 (en) 2008-08-28
MY160436A (en) 2017-03-15
TWI435612B (zh) 2014-04-21
EP2119187B1 (en) 2017-07-19
KR20090123908A (ko) 2009-12-02
KR101087379B1 (ko) 2011-11-25
AR065465A1 (es) 2009-06-10
SG179403A1 (en) 2012-04-27
US8619868B2 (en) 2013-12-31
US20080205511A1 (en) 2008-08-28
WO2008102323A3 (en) 2008-11-13

Similar Documents

Publication Publication Date Title
RU2510908C2 (ru) Описание характеристик агрегированных блоков медиаданных с обратной совместимостью
KR102127702B1 (ko) 미디어 데이터를 송수신하기 위한 인터페이스 장치 및 방법
TWI528733B (zh) 用於提供及使用供轉碼媒體串流用之交互操作性點的預定發訊的系統及方法
TWI432035B (zh) 可縮放視訊編碼之圖像反向相容聚合技術
KR100556911B1 (ko) 무선 동영상 스트리밍 서비스를 위한 동영상 데이터의 구조
US20160337424A1 (en) Transferring media data using a websocket subprotocol
US20080267287A1 (en) System and method for implementing fast tune-in with intra-coded redundant pictures
WO2011030811A1 (ja) 配信システム、ゲートウェイ、配信方法及びプログラム
US20100183033A1 (en) Method and apparatus for encapsulation of scalable media
Gualdi et al. Low-latency live video streaming over low-capacity networks
KR101656193B1 (ko) 이기종 망에서의 uhd 비디오 전송을 위한 mmt 기반 방송 시스템 및 방법
Buchowicz Video coding and transmission standards for 3D television—a survey
Luis et al. Scalable streaming of JPEG 2000 live video using RTP over UDP
Banerjee Study of H. 264 Video Streaming Over Wireless Channel Using GStreamer
KR100713363B1 (ko) 이동통신 시스템에서 엠펙 전송 장치 및 방법
WO2024064005A1 (en) Automatic generation of video content in response to network interruption
Chung A novel selective frame discard method for 3D video over IP networks
Wang Multimedia Communications–Applications, Systems, and Methods

Legal Events

Date Code Title Description
PC41 Official registration of the transfer of exclusive right

Effective date: 20160602