Запись потока мультимедийных данных в трек указаний о приеме контейнерного медиафайла

Запись потока мультимедийных данных в трек указаний о приеме контейнерного медиафайла

Иллюстрации

Показать все

Реферат

Область техники

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

Предпосылки создания изобретения

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

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

[0004] Иерархия форматов медиафайлов в общих чертах описана в блоке 100 фиг.1. Формат 1100 элементарного потока представляет единичный, независимый поток. Аудиофайлы, например *.amr и *.аас, строятся в соответствии с форматом элементарного потока. Формат 1200 контейнерных файлов является форматом, позволяющим помещать в один файл потоки одновременно аудиоданных и видеоданных. Представитель семейства форматов контейнерных файлов - формат 1200 - основан на базовом формате медиафайлов ISO (ISO base media file format). Непосредственно под форматом 1200 контейнерных файлов в иерархии 1000 располагается формат 1300 мультиплексирования. Формат 1300 мультиплексирования, как правило, менее гибок и упаковывается более плотно, нежели аудио/видеофайл (audio/video AV), построенный в соответствии с форматом 1200 контейнерных файлов. Файлы, сформированные в соответствии с форматом 1300 мультиплексирования, обычно используются только для целей воспроизведения. Программный поток MPEG-2 является примером потока, сформированного в соответствии с форматом 1300 мультиплексирования. Формат 1400 языка презентаций используется для таких целей, как разметка, интерактивность, синхронизация AV и дискретных данных и т.д. Язык интеграции синхронизированных мультимедийных данных (Synchronized multimedia integration language, SMIL) и язык масштабируемой видеографики (scalable video graphics, SVG), описанные Консорциумом Всемирной сети (World Wide Web Consortium, W3C), являются примерами формата 1400 языков презентаций. Формат 1500 файлов презентаций характеризуется включением всех частей презентации в один файл. Примерами объектов, сформированных в соответствии с форматом файлов презентаций, являются файлы PowerPoint и файлы, отвечающие расширенному профилю презентаций формата файлов 3GP.

[0005] Существующие стандарты форматов медиафайлов и форматов контейнерных файлов включают базовый формат медиафайлов ISO (ISO/IEC 14496-2), формат файлов MPEG-4 (ISO/IEC 14496-14, известный также как формат МР4), формат файлов усовершенствованного видеокодирования (Advanced Video Coding, AVC) (ISO/IEC 14496-15) и формат файлов 3GPP (3GPP TS 26.244, известный также, как формат 3GP). В группе MPEG существует также проект по разработке формата файлов с масштабируемым видеокодированием (scalable video coding, SVC), который станет дополнением к формату файлов усовершенствованного видеокодирования (advanced video coding, AVC). Параллельно MPEG разрабатывает формат треков указаний (hint track format) для сеансов доставки файлов по однонаправленной линии передачи (file delivery over unidirectional transport, FLUTE) и сеансов асинхронного многоуровнего кодирования (asynchronous layered coding, ALC), который станет дополнением к базовому формату медиафайлов ISO.

[0006] В настоящее время организация по вопросам цифрового видеовещания (Digital Video Broadcasting, DVB) работает над созданием спецификации формата файлов DVB. Основной целью определения формата файлов DVB является упрощение обеспечения совместимости в отношении контента между такими реализациями технологий DVB как приставки, соответствующие нынешним (DVT-T, DVB-C, DVB-S) и будущим стандартам DVB, телевизионные приемники на основе протокола Интернета (Internet Protocol, IP) и приемники мобильного телевидения, соответствующие стандарту DVB-Handheld (карманный DVB), а также его будущим стадиям развития. Формат файлов DVB позволит осуществлять обмен записанными мультимедийными данными (в режиме "только чтение") между устройствами различных производителей, обмен контентом с использованием USB-накопителей или аналогичных записывающих/считывающих устройств, а также обеспечит возможность совместного доступа к разделяемому дисковому хранилищу в домашней сети и другую функциональность. В настоящее время наиболее вероятным кандидатом, претендующим стать основой разработки формата файлов DVB, является базовый формат медиафайлов ISO. Формат файлов ISO является основой для всех вышеуказанных производных из него форматов контейнерных файлов (за исключением самого формата файлов ISO). Такие форматы файлов (включая сам формат файлов ISO) называют семейством форматов файлов ISO.

[0007] Элементарный строительный блок базового формата медиафайлов ISO называется "боксом" (box). Каждый бокс включает заголовок и полезную нагрузку. В заголовке бокса указывается тип бокса и размер бокса, выраженный в байтах. Бокс может заключать внутри себя другие боксы, при этом в формате файлов ISO определены типы боксов, которые могут находиться внутри бокса каждого типа. Также, некоторые боксы должны присутствовать в каждом файле обязательно, тогда как другие боксы могут быть опциональными. При этом боксов некоторых типов в файле может быть несколько. Таким образом, в базовом формате медиафайлов ISO по существу определена иерархическая структура боксов.

[0008] На фиг.2 показана упрощенная структура файла, соответствующая базовому формату медиафайлов ISO. В соответствии с форматом файлов семейства ISO файл 200 включает мультимедийные данные и метаданные, размещенные в различных боксах - боксе 210 метаданных (mdat) и боксе 220 фильма (moov), соответственно. Для того, чтобы файл мог быть обработан, обязательно должны присутствовать оба указанных бокса. Бокс 210 мультимедийных данных содержит видео- и аудиокадры, которые могут чередоваться и быть упорядоченными по времени. Бокс 220 фильма может содержать один или несколько треков ("дорожек"), при этом каждый трек занимает один бокс 240 трека. Для представления одного типа мультимедийных данных выбирается, как правило, один трек.

[0009] Следует отметить, что базовый формат медиафайлов ISO не ограничивает презентацию одним файлом. Фактически, презентация может храниться в нескольких файлах. При таком сценарии один из файлов содержит метаданные всей презентации. Такой файл может содержать также и все мультимедийные данные, в таком случае презентация будет автономной (самодостаточной). При использовании (если требуется) других файлов им не обязательно иметь базовый формат медиафайлов ISO. Другие файлы используются для хранения мультимедийных данных, при этом они могут также содержать неиспользуемые мультимедийные данные или другую информацию. Базовый формат медиафайлов ISO определяет только структуру файла, содержащего метаданные. Базовый формат медиафайлов ISO и его производные ограничивают формат файлов с мультимедийными данными только в том отношении, что форматирование мультимедийных данных в этих файлах должно соответствовать базовому формату медиафайлов ISO или производным форматам.

[0010] В дополнение к синхронизированным трекам файлы ISO могут содержать любые несинхронизированные бинарные объекты в боксе метаданных (meta box). Бокс метаданных может находиться на верхнем уровне файла, в боксе 220 фильма или в боксе 240 треков, но не более одного бокса метаданных должно появляться на уровне файла, на уровне фильма и на уровне трека, соответственно. Бокс метаданных должен содержать бокс 'hdlr', задающий структуру или формат содержимого бокса метаданных. Бокс метаданных может содержать любое число бинарных объектов, на которые допускается осуществлять ссылки, при этом каждый из этих бинарных объектов может быть связан с некоторым именем файла.

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

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

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

[0014] 2. Другая спецификация, которой файл также соответствует, запрещает использование некоторой функции. Например, некоторые производные спецификации прямо запрещают использование фрагментов фильма.

[0015] 3. Из контекста, в котором функционирует продукт, ясно, что некоторые структуры неуместны. Например, структуры треков указаний уместны только в продуктах, подготавливающих контент для доставки файлов (например, потоковой) для протокола из трека указаний или осуществляющих такую доставку.

[0016] Считыватели файлов, осуществляющие чтение файлов определенного вида, должны также предпринимать попытку чтения файлов, отмеченных как совместимые с этим видом.

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

[0018] Базовый формат медиафайлов ISO содержит определение треков указаний для протокола реального времени (Real-Time Protocol) и безопасного протокола передачи данных в реальном времени (Secure Real-Time Transport Protocol, SRTP), а готовящаяся поправка 2 к базовому формату медиафайлов ISO будет включать определение треков указаний для протоколов FLUTE и ALC. Для транспортного потока (transport stream, TS) MPEG-2, формат треков указаний также может быть описан, например, как часть формата файлов DVB.

[0019] Бокс mdat, изображенный на фиг.2, содержит сэмплы, соответствующие трекам. В обычных треках (не треках указаний) сэмпл является одиночным видеокадром, непрерывной временной последовательностью видеокадров или непрерывным во времени фрагментом сжатых аудиоданных. В треках указаний сэмпл задает структуру одного или нескольких пакетов, форматированных в соответствии с протоколом связи, указанным в заголовке трека указаний.

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

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

[0022] Фиг.3 является изображением стандартной системы видеосвязи. По причине того, что несжатое видео требует огромной полосы пропускания, входные видеоданные 300 сжимаются кодером 305 источника до требуемого битрейта. Кодер 305 источника может быть разделен на две составные части: кодер 310 формы сигнала и энтропийный кодер 315. Кодер 310 формы сигнала выполняет сжатие видеосигнала с потерями, тогда как энтропийный кодер 315 без потерь преобразует выходные данные кодера 310 формы сигнала в двоичную последовательность. Транспортный кодер 320 инкапсулирует сжатые видеоданные в соответствии с транспортными протоколами, используемыми, например, для перемежения и модуляции данных. Данные передаются принимающей стороне посредством канала 325 передачи. Приемник выполняет обратные операции для получения восстановленного видеосигнала, предназначенного для отображения. Обратные операции включают использование транспортного декодера 330 и декодера 335 источника, который может быть разделен на энтропийный декодер 340 и декодер 345 формы сигнала, и имеют результатом выходные видеоданные 350.

[0023] Большинство реальных каналов подвержены ошибкам передачи. Ошибки передачи могут быть грубо разделены на две категории - битовые ошибки и ошибки стирания. Причинами битовых ошибок являются физические явления в канале передачи, например шумы и помехи. В стеках протоколов передачи мультимедийных данных реального времени, как правило, существуют механизмы обнаружения битовых ошибок, например, циклические избыточные проверочные коды (CRC). Общепринятой практикой является отбрасывание полезной нагрузки протокола, содержащей ошибку, в транспортном декодере. Трудности декодирования полезной нагрузки протокола с ошибкой заключаются в вероятности того, что могла произойти последовательность ошибок, в точном определении позиции ошибки и в применении кодирования с переменной длиной (variable length coding, VLC) энтропийным кодером. Вследствие пакетного характера ошибок, очень вероятно, что большую часть полезной нагрузки протокола все равно не удастся декодировать, и поэтому отбрасывание всей полезной нагрузки протокола не приводит к слишком большим дополнительным потерям данных. Механизмы обнаружения ошибок, предлагаемые протоколами связи, обычно способны сформировать двоичное заключение о пакете - является ли он целым или поврежденным. Следовательно, определение точного положения ошибок осуществляют механизмы уровня кодирования. Несмотря на то, что существуют способы определения положения ошибок, основанные на выявлении нарушений синтаксиса и семантики и неестественных структурных нарушений, ложное обнаружение битовых ошибок может привести к раздражающему потребителя видеоряду. Вследствие кодирования с переменной длиной, одиночная битовая ошибка легко может изменить интерпретацию кодового слова, в котором она произошла, и вызвать потерю синхронизации последующих кодовых слов. Даже если синхронизация кодовых слов будет восстановлена, может оказаться невозможным определение пространственного или временного положения декодированных данных.

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

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

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

[0027] Альтернативная приведенной выше классификация алгоритмов исправления и скрытия ошибок отталкивается от уровня стека протоколов, на котором функционирует рассматриваемый алгоритм. Способы физического уровня могут, например, интеллектуально использовать модуляцию и чередование передаваемых битов данных. На канальном уровне ошибочно принятые блоки данных могут быть, например, выборочно переданы повторно. Вообще, способы, включающие кодер или декодер источника, называются медийно-осведомленными алгоритмами коррекции и скрытия ошибок, тогда как способы, функционирующие исключительно в транспортном кодере или декодере, являются медийно-независимыми. Способы, требующие взаимодействия различных уровней стека протоколов, подпадают под категорию алгоритмов межуровневой оптимизации. Термин "объединенное кодирование источника-канала" применяют в случае безразрывной работы кодирования источника и транспортного кодирования для предотвращения ошибок передачи совместными усилиями.

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

[0029] Большинство (если не все) форматов контейнерных файлов предназначены для воспроизведения свободных от ошибок файлов, которые надежно передаются на устройство воспроизведения, и/или для обеспечения серверов потоковой отправки или других передающих устройств, мультимедийным контентом для передачи. Следовательно, форматы контейнерных файлов не обеспечивают механизмов указания на ошибки передачи и не гарантируют способность существующих проигрывателей легко справляться с ошибочными потоками мультимедийных данных. Наоборот, проигрыватели могут давать сбои или иным образом вести себя непредсказуемо. Следовательно, желательно, чтобы генерированные из принятого потока мультимедийных данных файлы воспроизводились существующими медиапроигрывателями и были совместимы с существующими форматами файлов. Также было бы желательно, чтобы усовершенствованные проигрыватели и декодеры включали механизмы эффективного скрытия ошибок передачи в принимаемых потоках, которые записываются в файл.

[0030] Существует несколько общепринятых подходов к устранению вышеописанных затруднений. В первом подходе, принятый транспортный поток включается в неизменном виде в файл, или транспортный поток сохраняется в отдельном файле, и на этот отельный файл осуществляются ссылки из файла презентации (т.е. файла, содержащего метаданные). При такой схеме, транспортным потоком называют поток, относящийся к самому нижнему из являющихся актуальными для конкретного приложения уровню стека протоколов. При передаче мультимедийных данных на основе протокола RTP транспортным потоком, как правило, называют поток пакетов RTP. Если элементарные потоки мультимедийных данных инкапсулируются в транспортный поток MPEG-2 (как в стандартах DVB-T, DVB-C и DVB-S), транспортным потоком называют транспортный поток MPEG-2. В структуре базового формата медиафайлов ISO транспортный поток может включаться в трек мультимедийных данных в качестве единственного сэмпла. Таким образом транспортные потоки MPEG-2 включаются в файлы QuickTime. Характерные для заданного транспортного потока метаданные могут храниться в новой структуре формата файлов; в базовом формате медиафайлов ISO подобные структуры могут размещаться в боксе метаинформации.

[0031] Во втором подходе принятый транспортный поток преобразуется в элементарные треки данных. Характерные для данного транспортного потока метаданные хранятся в другой структуре формата файлов; в базовом формате медиафайлов ISO подобные структуры могут размещаться в боксе метаинформации.

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

[0033] То обстоятельство, что бокс moov может быть заполнен только после приема всех мультимедийных данных, делает невозможной непрерывную запись в один файл во втором и третьем из рассмотренных выше подходов. Это затруднение можно обойти путем использования функции фрагментов фильма для разбиения записываемого файла, как это описано в заявке на патент США №11/292,786, поданной 1 декабря 2005 года. В качестве варианта, мультимедийные данные принимаемого потока могут записываться в отдельные (от файла метаданных) файлы. Таким образом, если требуется одновременное воспроизведение записываемого файла со сдвигом времени, следует использовать фрагменты фильма, как описано в заявке на патент США №11/292,786.

Сущность изобретения

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

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

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

Краткое описание чертежей

[0037] Фиг.1 является изображением иерархии форматов медиафайлов;

[0038] Фиг.2 является представлением упрощенной структуры файла ISO;

[0039] Фиг.3 является представлением типовой системы видеосвязи;

[0040] Фиг.4 является представлением типовой системы мультимедийной связи для использования с различными вариантами осуществления настоящего изобретения;

[0041] Фиг.5 является блок-схемой алгоритма, иллюстрирующего функционирование упрощенной версии приемника в соответствии с различными вариантами осуществления настоящего изобретения;

[0042] Фиг.6 является видом в перспективе электронного устройства, пригодного к использованию в сочетании с различными реализациями вариантов осуществления настоящего изобретения;

[0043] Фиг.7 схематично изображает электронные схемы, которые могут входить в состав электронного устройства фиг.6.

Подробное описание различных вариантов осуществления изобретения

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

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

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

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

[0048] Фиг.4 является графическим представлением типовой мультимедийной системы связи, в которой могут быть реализованы различные варианты осуществления настоящего изобретения. Как видно из фиг.4, источник данных 100 предоставляет исходный сигнал в аналоговом, несжатом цифровом, сжатом цифровом формате, или любой комбинации этих форматов. Кодер 110 кодирует исходный сигнал в кодированный битовый поток мультимедийных данных. Следует отметить, что предназначенный для декодирования битовый поток может приниматься прямо или косвенно от удаленных устройств сетей практически любых видов. При этом битовый поток может приниматься от локального аппаратного или программного обеспечения. Кодер 110 может кодировать более одного типа мультимедийных данных, например аудиоданные и видеоданные, или же более одного кодера 110 может потребоваться для кодирования различных типов мультимедийных данных исходного сигнала. Кодер 110 может также получать на вход синтезированную информацию, такую, например, как графику или текст, или быть способным создавать кодированный битовый поток синтезированных мультимедийных данных. В дальнейшем для простоты описания будет рассматриваться обработка кодированного битового потока только одного типа мультимедийных данных. Тем не менее, следует отметить, что службы вещания реального времени, как правило, содержат несколько потоков (в большинстве случаев, как минимум, по одному аудиопотоку, видеопотоку и текстовому потоку субтитров). Также следует отметить, что система может включать несколько кодеров, однако, в дальнейшем для простоты описания будет рассматриваться только один кодер 110, без нарушения общности. Необходимо также понимать, что хотя текст и примеры, содержащиеся в настоящем документе, могут описывать именно процесс кодирования, те же самые идеи и принципы применимы для соответствующего процесса декодирования, и наоборот, что очевидно специалистам в данной области.

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

[0050] Сервер 130 передает кодированный битовый поток мультимедийных данных с использованием стека протоколов передачи данных. Стек может включать (не обязательно ограничиваясь данным списком): транспортный протокол реального времени (Real-Time Transport Protocol, RTP), протокол пользовательских дейтаграмм (User Datagram Protocol, UDP), протокол Интернета (Internet Protocol, IP). В случае, если стек протоколов передачи данных пакетно-ориентирован, сервер 130 инкапсулирует кодированный битовый поток мультимедийных данных в пакеты. Например, когда используется RTP, сервер 130 инкапсулирует кодированный битовый поток мультимедийных данных в пакеты RTP в соответствии с форматом полезной нагрузки RTP. Как правило, для каждого типа мультимедийных данных имеется свой выделенный формат полезной нагрузки RTP. Следует еще раз отметить, что система может содержать более одного сервера 130, но для простоты в дальнейшем описании рассматривается случай, когда имеется только один сервер 130.

[0051] Сервер 130 может быть соединен (или не соединен) со шлюзом 140 посредством сети связи. Шлюз 140 может выполнять различные функции, такие как трансляцию потока пакетов, соответствующего одному стеку протоколов передачи данных, в другой стек протоколов передачи данных, слияние и разветвление потоков данных и обработку потоков данных в соответствии с возможностями нисходящей линии связи и/или приемника, такую, например, как управление битрейтом пересылаемого потока в соответствии с преобладающими условиями в сети нисходящей линии связи. Примерами шлюзов 140 могут служить устройства для реализации многоточечных аудио- и видеоконференций (multipoint conference control unit, MCU), шлюзы между видеотелефонией с коммутацией каналов и коммутацией пакетов, серверы системы «нажми и