ЗАПИСЬ ПОТОКА МУЛЬТИМЕДИЙНЫХ ДАННЫХ В ТРЕК УКАЗАНИЙ О ПРИЕМЕ КОНТЕЙНЕРНОГО МЕДИАФАЙЛА Российский патент 2011 года по МПК G06F17/30 

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

[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), шлюзы между видеотелефонией с коммутацией каналов и коммутацией пакетов, серверы системы «нажми и говори в сотовой сети» (Push-to-talk over Cellular servers, Рос), инкапсуляторы IP в портативных широковещательных системах цифрового видео (digital video broadcasting-handheld, DVB-H), или приставки, перенаправляющие широковещательные передачи локально в домашние беспроводные сети. В случае, когда используется RTP, шлюз 140 называется микшером RTP или транслятором RTP и выполняет функции конечной точки соединения RTP.

[0052] Система содержит один или несколько приемников 150, способных, как правило, к приему, демодуляции и декапсулированию переданного сигнала в кодированный битовый поток мультимедийных данных. Этот кодированный битовый поток мультимедийных данных передается на записывающее устройство 155 хранения. Записывающее устройство 155 хранения может включать любой тип памяти большого объема для хранения кодированного битового потока мультимедийных данных. Вместо этого, или в качестве дополнения, записывающее устройство хранения может включать вычислительную память, например память с произвольным доступом. Формат кодированного битового потока мультимедийных данных в записывающем устройстве 155 хранения может быть простым автономным форматом или же один или несколько кодированных битовых потоков мультимедийных данных могут инкапсулироваться в контейнерный файл. В случае нескольких связанных между собой битовых потоков мультимедийных данных, например видеопотока и аудиопотока, обычно используется контейнерный файл, при этом в состав приемника 150 входит генератор контейнерных файлов (или приемник 150 является подключенным к нему) для формирования контейнерного файла из входных потоков. Некоторые системы функционируют в режиме «на лету», т.е., минуя записывающее устройство 155 хранения, передают кодированный битовый поток мультимедийных данных непосредственно декодеру 160.

[0053] Кодированный битовый поток мультимедийных данных из записывающего устройства 155 хранения передается декодеру 160. В случае нескольких связанных между собой битовых потоков мультимедийных данных, например видеопотока и аудиопотока, инкапсулированных при этом в контейнерный файл, для извлечения каждого кодированного битового потока мультимедийных данных из указанного контейнерного файла применяется анализатор (parser) файлов (не показан на фиг.) Анализатор файлов может входить в состав записывающего устройства 155 хранения или декодера 160 или же быть подключенным к любому из этих устройств.

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

[0055] Далее описывается, как реализуется индикация записанных треков указаний в базовом формате медиафайлов ISO. В рассматриваемой реализации записанные треки указаний отмечают типом записи сэмплов, отличным от соответствующей записи сэмплов серверных треков указаний. Например, треки указаний RTP, предназначенные для сервера, являются треками указаний (указаниями обработчику мультимедийных данных) с форматом записи (entry) в описании сэмпла, имеющим значение "rtp". Записанный трек указаний RTP имеет значение формата записи "rrtp" в описании сэмпла. Обе записи сэмплов описываются идентично:

[0056] Для каждого протокола, для которого могут существовать указания, определяется пара серверного и записанного форматов записей сэмплов, примерами таких протоколов могут служить SRTP и транспортный поток MPEG-2. Сэмпл указаний может идентично определяться для каждой пары серверного и записанного формата треков указаний для любого протокола. Одинаковое описание формата сэмплов указаний в каждой паре серверного и записанного форматов треков указаний для любого протокола может, например, уменьшить размер программной реализации, измеряемой в строках кода языка программирования или в количестве машинно-выполняемых инструкций. Однако также может быть выгодно определять формат сэмпла записанного трека указаний способом, отличным от формата серверного трека указаний того же протокола. Например, может не иметь смысла включение поля continuity_counter (счетчик непрерывности) заголовка пакета TS MPEG-2 для формата серверных сэмплов указаний, так как серверы обычно просто увеличивают значение на 1 (арифметическая операция по модулю) после каждого переданного пакета. Однако поле continuity_counter требуется в формате записанных сэмплов указаний, так как заключения о потере пакетов делаются по разрыву в значениях continuity_counter последовательно принятых пакетов. Также может иметь смысл определение формата записанных треков указаний на уровне стека протоколов, отличном от уровня, используемого в серверных треках указаний. Например, если записанный сэмпл указаний соответствует пакету протокола Интернета, анализатор файлов может использовать контрольную сумму заголовка протокола пользовательских дейтаграмм для вывода заключения о присутствии битовых ошибок в принятом пакете, т.е. о целостности принятого пакета. В качестве варианта или в качестве дополнения записанный сэмпл указаний может содержать поля, отсутствующие в соответствующем формате пакетов. Такие поля могут использоваться для сообщения информации, например, от нижележащих уровней стека протоколов. Одним из примеров такого поля может быть поле указателя битовой ошибки для записанного сэмпла указаний RTP. Приемник может установить значение поля указателя битовой ошибки на основе контрольной суммы UDP или любых кодов CRC и контрольных сумм любого нижележащего уровня стека протоколов.

[0057] Фиг.5 является блок-схемой алгоритма, демонстрирующей функционирование упрощенного варианта приемника в соответствии с различными вариантами осуществления настоящего изобретения. Следует тем не менее отметить, что приемник может быть различных видов и может иметь различную конфигурацию. Процесс, изображенный на фиг.5, начинается с извлечения транспортного пакета на шаге 510 из приемного буфера хранения принятых транспортных пакетов. При этом транспортный пакет записывается также и во второй буфер, называемый в настоящем документе буфером кратковременного хранения пакетов. Транспортный пакет может включать пакет RTP, пакет транспортного потока MPEG-2 или пакет любого другого транспортного протокола. На шаге 520 проверяется непрерывность нумерации последовательности пакетов, при этом производится определение наличия разрыва в нумерации последовательности. Если транспортные пакеты форматированы в соответствии с протоколом RTP, порядковый номер (sequence number, SN) размещается в заголовке RTP. В случае, если транспортные пакеты форматированы в соответствии с транспортным потоком MPEG-2, порядковый номер называется continuity_counter и размещается в заголовке пакета TS.

[0058] Если в нумерации последовательности отсутствуют разрывы и установлено, что ни один из пакетов в буфере кратковременного хранения пакетов не содержит битовых ошибок, на шаге 530 выполняется проверка на предмет того, содержатся ли в текущем пакете последние байты полезной нагрузки видеокадра, или в более общем случае, блока видеодоступа, пакеты которого находятся в настоящее время в буфере кратковременного хранения пакетов. Для большинства типов полезной нагрузки видеоданных RTP в заголовке RTP устанавливается бит М для указания того, что пакет содержит последние биты кодированного видеокадра. Другим способом обнаружения последнего пакета видеокадра является проверка временной отметки (timestamp) следующего пакета. Если временная отметка RTP следующего пакета отличается от текущей временной отметки RTP, значит текущий пакет содержит последние байты полезной нагрузки текущего кодированного видеокадра. При использовании инкапсуляции в транспортный поток MPEG-2, значение payload_unit_start_indicator (указатель начала блока полезной нагрузки) в следующем пакете транспортного потока указывает, что текущий пакет TS содержит последние байты полезной нагрузки кодированного видеокадра. Если текущий пакет не является последним пакетом видеокадра, процесс возвращается к шагу 510. Следует заметить, что процедуры шагов 520 и 530 выполняются, только если порядок передачи кодированных видеоданных идентичен порядку их декодирования. Обнаружение потерь и конца кадра для передачи с перемежением требует, как правило, анализа принятых блоков данных. Пример обнаружения потерь для передачи видео H.264/AVC с перемежением приведен в разделе 8 технических рекомендаций 3GPP 26.964 (выпуск 6) "Службы широковещательной/многоадресной передачи мультимедийных данных. Указания по пользовательским службам." Обнаружение границы кадра описывается в разделе 7.4.1.2.4. H.264/AVC (т.е. Рекомендации Н.264 ITU-T).

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

[0060] Если текущий пакет является последним пакетом кодированного видеокадра, значит на шаге 540 из полезной нагрузки пакетов, собранной в буфере кратковременного хранения пакетов, будет получен сэмпл видеоданных. Указанный процесс может включать простое объединение полезной нагрузки пакетов. Сгенерированный сэмпл видеоданных затем записывается в файл. Следует отметить, что вследствие наличия метаданных (боксы moov или moof), обычно предшествующих мультимедийным данным, сэмпл видеоданных может сначала записываться во временный файл и копироваться в фактический файл, создаваемый после завершения всех соответствующих метаданных.

[0061] На шаге 550 из каждого пакета, хранящегося в буфере кратковременного хранения пакетов, генерируется сэмпл указаний. Так как сэмпл видеоданных, генерированный на шаге 540, уже содержит кодированные видеоданные, сэмплы указаний просто ссылаются на трек видеоданных, сгенерированный сэмпл видеоданных и соответствующий диапазон байтов внутри сэмпла видеоданных. Когда для всех пакетов в буфере кратковременного хранения пакетов генерированы сэмплы указаний, буфер очищается и процесс возвращается к шагу 510.

[0062] Если на шаге 520 обнаружен разрыв в нумерации последовательности пакетов или обнаружена битовая ошибка в любом из пакетов буфера кратковременного хранения пакетов, тогда на шаге 560 сэмпл указаний генерируется из каждого пакета, хранящегося в буфере кратковременного хранения пакетов. Однако, так как полезная нагрузка пакетов буфера кратковременного хранения пакетов несвободна от ошибок, сэмпл видеоданных не формируется в трек видеоданных. Таким образом, полезная нагрузка пакетов по существу включается в сэмплы указаний с использованием или механизма "непосредственных конструкторов" (immediate constructors), или механизма "толстых" треков указаний ("fat" hint track). При использовании непосредственных конструкторов копия данных полезной нагрузки включается в инструкции по пакетированию. Когда же используется механизм "толстых" треков указаний, полезная нагрузка пакетов включается в раздел mdat треков указаний, и на нее осуществляются ссылки из конструкторов трека указаний. Когда для всех пакетов в буфере кратковременного хранения пакетов генерированы сэмплы указаний, буфер очищается.

[0063] После шага 560 из приемного буфера для принятых пакетов получают следующий пакет (шаг 570). Затем следующий пакет анализируют с целью определить, является ли он началом кодированного видеокадра, обеспечивающим точку произвольного доступа к потоку. Начало кодированного видеокадра может быть обнаружено в соответствии с процедурой шага 530. Способ обнаружения точек произвольного доступа зависит от формата видеоданных и формата его полезной нагрузки. Например, для H.264/AVC кадр независимого обновления декодирования может быть определен по заголовку блока уровня сетевой абстракции, который легко получить из полезной нагрузки пакетов. Другой механизм определения точки произвольного доступа, обеспечиваемый H.264/AVC, - сообщение с информацией дополнительного улучшения (supplemental enhancement information, SEI), пригодное для указания различных типов последовательных позиций произвольного доступа. Другой пример указания точки произвольного доступа включен в формат полезной нагрузки RTP для кодека VC-1, для этих целей он имеет специальный флаг. Если выявлена точка произвольного доступа, процесс продолжается с шага 530. В обратном случае, процесс продолжается с шага 560.

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

[0065] Другие варианты реализации включают запись в промежуточном формате во время приема. Промежуточный формат может включать простой формат хранения принятых пакетов. Например, транспортный поток MPEG-2 может сохраняться в файле без изменений, а пакеты RTP могут храниться с включением в файл также некоторого обрамления, указывающего размер пакетов. Файл, соответствующий указанному промежуточному формату, может быть позднее преобразован к более структурированному формату файлов, например какой-либо версии базового формата медиафайлов ISO или производному формату. В процессе преобразования может применяться операция, аналогичная описанной выше. Что касается фиг.4, такая реализация может потребовать двух дополнительных блоков, получающих входную информацию из записывающего устройства 155 хранения и осуществляющих вывод в декодер 160. Первый (в последовательности обработки данных) блок может быть назван переписчиком файлов, он получает на вход файл, соответствующий промежуточному формату, и выдает файл в соответствии с более структурированным форматом файлов. Второй в последовательности обработки данных блок носит название второго записывающего устройства хранения, его свойства могут быть аналогичны записывающему устройству 155 хранения.

[0066] Упомянутые выше переписчик файлов и второе записывающее устройство хранения могут размещаться в том же устройстве, что и приемник 150, записывающее устройство 155 хранения и декодер 160, или в отдельном устройстве. При этом переписчик файлов и вторичное записывающее устройство хранения могут входить в состав одного устройства или в состав отдельных друг от друга устройств.

[0067] Анализатор файлов, входящий в состав декодера 160 или подключенный к нему, а также сам декодер 160 могут функционировать так, как будто анализу и декодированию подвергается обычный фал, т.е. так, как будто анализируются и декодируются только треки мультимедийных данных и сэмплы мультимедийных данных, а треки указаний и сэмплы указаний опускаются. В качестве варианта, анализатор файлов и декодер 160 могут функционировать таким образом, как будто битовый поток кодированных мультимедииных данных принимается в режиме реального времени. Другими словами, анализатор файлов может собирать пакеты в соответствии с инструкциями сэмплов указаний и передавать пакеты декодеру 160. При этом, темп передачи пакетов декодеру 160 может соответствовать графику приема пакетов. Формат пакетов может быть идентичен получаемым от отправителя 130 пакетам или может включать практически те же порции информации, что и полученные от отправителя 130 пакеты, которые могут сопровождаться данными нижележащих стеков протоколов. Декодер 160 обнаруживает недостающие или поврежденные пакеты описанным выше со ссылками на фиг.5 способом. Декодер 160 может реагировать на недостачу или повреждение пакетов путем применения алгоритмов скрытия и/или отслеживания ошибок. При этом декодер может запрашивать у отправителя 130 восстановление или скрытие недостающих или поврежденных пакетов по протоколу обратной связи. Возможны и другие конфигурации анализатора файлов и декодера 160. Например, декодер 160 может давать заключение о возможности корректного декодирования пакета, если его данные содержатся, соответственно, в сэмпле трека мультимедийных данных или сэмпле указаний.

[0068] Следует также отметить, что трек указаний может содержать один или несколько потоков/типов мультимедийных данных и связанные с ними метаданные. Например, если аудио- и видеоданные передаются в качестве элементарных потоков транспортного потока MPEG-2, аудио- и видеоданные могут записываться в один и тот же трек указаний. При этом специфическая сигнализация MPEG-2 также может быть включена в тот же самый трек указаний.

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

[0070] Устройства связи, осуществляющие и реализующие различные варианты настоящего изобретения, могут осуществлять связь с использованием различных технологий передачи данных, включая (но не ограничиваясь этим): множественный доступ с кодовым разделением (Code Division Multiple Access, CDMA), глобальную систему для мобильной связи (Global System for Mobile Communications, GSM), универсальную систему мобильной связи (Universal Mobile Telecommunication System, UMTS), множественный доступ с разделением по времени (Time Division Multiple Access, TDMA), множественный доступ с разделением по частоте (Frequency Division Multiple Access, FDMA), протокол управления передачей/протокол Интернета (Transmission Control Protocol/Internet Protocol, TCP/IP), службу коротких сообщений (Short Messaging Service, SMS), службу мультимедийных сообщений (Multimedia Messaging Service, MMS), электронную почту, сервис мгновенной передачи сообщений (Instant Messaging Service, IMS), Bluetooth, IEEE 802.11 и др. Устройство связи может осуществлять связь с использованием различных средств, включая (но не обязательно ограничиваясь данным списком) радио, инфракрасные, лазерные, кабельное соединение и т.п.

[0071] На фиг.6 и 7 изображено типовое электронное устройство 12, на основе которого может быть реализовано настоящее изобретение. Необходимо, тем не менее, понимать, что настоящее изобретение не является ограниченным одним конкретным видом электронного устройства 12. Электронное устройство 12 на фиг.6 и 7 включает: корпус 30, дисплей 32 в виде дисплея на жидких кристаллах, клавиатуру 34, микрофон 36, динамик 38, аккумулятор 40, инфракрасный порт 42, антенну 44, смарт-карту 46 в виде UICC в соответствии с одним из вариантов осуществления изобретения, устройство 48 чтения карт, электронные цепи радиоинтерфейса 52, электронные цепи кодека, контроллер 56, память 58 и аккумулятор 80. Все отдельно взятые цепи и элементы известны на данном уровне развития техники и применяются, например, в модельном ряде мобильных телефонов Nokia.

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

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

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

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

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

2. Способ по п.1, в котором сэмпл указаний включает указание о потере по меньшей мере одного пакета из потока пакетов мультимедийных данных.

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

4. Способ по п.1, в котором ошибки представляют собой битовые ошибки и/или потери пакетов во время передачи потока пакетов мультимедийных данных.

5. Машиночитаемый носитель с хранящейся на нем компьютерной программой, включающей инструкции, заставляющие процессор выполнять способ по любому из пп.1-4.

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

7. Устройство по п.6, в котором сэмпл указаний включает указание на потерю по меньшей мере одного пакета.

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

9. Устройство по п.6, в котором ошибки представляют собой битовые ошибки и/или потери пакетов во время передачи потока пакетов мультимедийных данных.

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