Устройство и способ для обработки и чтения файла, имеющего хранилище медиаданных и хранилище метаданных

Устройство и способ для обработки и чтения файла, имеющего хранилище медиаданных и хранилище метаданных

Иллюстрации

Показать все

Реферат

Изобретение имеет отношение к хранению и/или чтению пакетов данных транспортных протоколов и дополнительной информации, связанной с ними, и/или файла, имеющего контейнер медиа данных и контейнер метаданных, как например файл, основанный на ISO (Международная организация по Стандартизации) базовом медиа формате файла.

Различные электронные устройства используются для получения и воспроизведения потоков медиа данных. Такие потоки медиа данных могут, например, быть получены из цифровой видео широковещательной сети, которая передает медиа потоки в соответствии с, например, Стандартом DVB-H (Цифровое Мобильное Видео- и Телевещание) или Стандартом DVB-T (Цифровое Наземное ТВ-вещание).

DVB-T использует модульный MPEG-2 (MPEG = Экспертная Группа по Кинематографии) транспортный поток, содержащий элементарные видео и аудио потоки MPEG-2 согласно международному стандартному ISO/IEC 13818 (IEC = Международная Электротехническая Комиссия). Транспортный поток MPEG-2 - мультиплексный, используется во многих современных системах теле- и радиовещания. Это - мультиплексный поток одной или нескольких медиа программ, типично аудио и видео, но также и других данных. Транспортные потоки MPEG-2 делят общий тактовый генератор и используют медиа образцы с временной меткой (Блоки Доступа, AUs) во всех медиа потоках. Это делает возможной синхронизацию передающих и принимающих тактовых генераторов и синхронное озвучивание аудио- и видео потоков.

Для DVB-H элементарные аудио- и видео потоки инкапсулированы в RTP (Транспортный Протокол в Реальном Времени), UDP (Пользовательский Дейтаграммный Протокол), IP (Интернет-Протокол), и МРЕ (Многопротокольная инкапсуляция) для IP преобразования типов данных. RTP используется для эффективной поставки мультимедийных данных по IP сетям в реальном времени. Мультиплексирование типично осуществляется привязыванием различных сетевых портов к каждому конкретному медиа потоку, например, один сетевой порт для видео и другой для аудио. Различные медиа данные обычно происходят от различных источников, имеющих различные тактовые генераторы или тактовые частоты. Например, аудиообразцы имеют норму отбора, зависящую от тактовой частоты устройства дискретизации аудиоматериала, в котором частота кадров видеоструктур зависит от тактовой частоты видеоструктуры захватного устройства. Такие тактовые генераторы могут иметь свойственные погрешности частоты, больше чем несколько сотен частей на миллион, что приводит к накоплению погрешностей в количестве десятков секунд в день. Термин «расфазировка синхронизирующих импульсов» определяется как отличие фактической частоты генератора тактовых импульсов от его номинальной частоты. Если передающий тактовый генератор работает быстрее, чем принимающий тактовый генератор, это может привести к накоплению пакетов в приемнике. Если передающий тактовый генератор работает медленнее, чем принимающий тактовый генератор, это приведет к неполной загруженности буферов приемника. Таким образом, если тактовая частота приемника отличается от тактовой частоты отправителя, то буфер(ы) приемника будет или постепенно заполняться или будет пустым. Далее, расфазировка синхронизирующих импульсов может привести к де-синхронизации между связанными аудио- и видеообразцами в приемнике.

RTCP (Транспортный Протокол Управления Передачей в Реальном Времени) позволяет обеспечить восстановление и синхронизацию тактового генератора для потоков RTP. Канал RTCP связан с каждым потоком RTP и включает управляющую информацию от отправителя на приемник в форме сообщений отправителя (SR) и наоборот. Каждое RTCP сообщение отправителя включает две временные метки: NTP (Протокол Сетевого Времени) временная метка системы тактового генератора отправителя (опорная метка времени) и соответствующая медиа временная метка связанного потока RTP. Эти RTCP сообщения отправителя посылают и для аудио и для видео. Из величин RTP и времени NTP пакеты RTP могут быть установлены на временной линии, и медиа могут быть отлично синхронизированы.

Потоковое обслуживание определяется как ряд синхронизированных медиа потоков, поставленных способом, ограниченном во времени или неограниченном, для непосредственного потребления во время приема. Каждый потоковый сеанс может включать аудио, видео и/или медиа данные в реальном времени, такие как синхронизированный текст. Пользовательские медиа данные, получаемые для кино посредством мобильного телевидения, например, могут просматривать кино и/или записывать его в файл. Обычно, с этой целью полученные пакеты данных полученного медиа потока депакетируются, чтобы хранить необработанные медиа данные в файле. Таким образом, полученные пакеты RTP или пакеты MPEG-2 должны сначала депакетироваться, чтобы получить свою полезную нагрузку в форме образцов медиа данных. Затем, после депакетирования полученные образцы медиа данных воспроизводятся или хранятся в файле. Полученные медиа образцы обычно сжимаются форматами подобными H.264/AVC (AVC=Расширенное Видео Кодирование) видеоформату и/или MPEG-4 EH-AACV2 (EH-AACV2=Высокоэффективное Расширенное АудиоКодирование - версия 2) аудиоформату. Когда образцы медиа данных, имеющие такие видео- и/или аудиоформаты, должны храниться, они могут быть сохранены в так называемом 3GP формате файла, также известном как 3GPP (Партнерский Проект 3-его Поколения) формат файла, или в МР4 (MPEG-4) формате файла. И 3GP и МР4 получены из ISO базового медиа формата файла, который определен в ISO/IEC международном стандарте 14496-12:2005 «Техника кодирования информации аудиовизуальных объектов - часть 12: ISO базовый медиа формат файла». Файл этого формата включает медиа данные и метаданные. Чтобы такой файл работал, должны присутствовать и те и другие данные. Медиа данные хранятся в контейнере медиа данных (mdat), связанном с файлом, а метаданные хранятся в контейнере метаданных (moov) файла. Традиционно, контейнер медиа данных включает фактические медиа образцы. То есть он может включать, например, перемежающиеся, упорядоченные по времени видео- и/или аудиоструктуры. Таким образом, каждое из медиа данных имеет свою собственную дорожку метаданных (trak) в контейнере метаданных moov, которая описывает свойства медиа информационного наполнения. Дополнительные контейнеры (также называемые блоками) в контейнере метаданных moov могут включать информацию о свойствах файла, содержании файла и т.д.

Недавно, так называемые хинтинговые дорожки приема для файлов, основанные на ISO базовом медиа формате файла, были определены международными группами стандартизации. Эти хинтинговые дорожки приема могут использоваться для хранения мультиплексных и/или пакетированных потоков, таких как, например, полученный транспортный поток MPEG-2 или пакеты RTP. Хинтинговые дорожки приема могут использоваться для хранения со стороны клиента и воспроизведения полученных пакетов данных. Таким образом, полученные MPEG-2 TS или RTP пакеты одного потока непосредственно хранятся на хинтинговых дорожках приема, таких как, например, заранее вычисленные образцы или конструкторы.

Есть два преимущества этого подхода по сравнению с демультиплексированием и/или депакетированием пакетов данных и последующим записыванием отдельных медиа дорожек для каждого элементарного медиа потока (аудио и/или видео). Во-первых, он снижает требуемую сложность приемного устройства во время хранения, потому что не требуется никакого демультиплексирования или другой обработки полученных пакетов данных. Выполняется только хранение файла полученных пакетов данных в неизмененной форме. Во-вторых, в некоторых случаях полностью невозможно уплотнить полученные пакеты данных, отделить медиа дорожки, особенно, если медиа данные зашифрованы на транспортном/мультиплексном уровне, или схема пакетирования неизвестна. В-третьих, облегчается сдвиг по времени, то есть запись в файл и немедленное считывание этого же самого файла с переменным смещением времени, в PVR (PVR = Персональный Видеомагнитофон), благодаря первым двум пунктам.

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

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

Потоковые приемники могут восстанавливать системный тактовый генератор отправителя из времени приема сообщения и выравнивать системный тактовый генератор приемника с системным тактовым генератором отправителя, чтобы избежать буферного переполнения соответственно недогрузки для прямого воспроизведения. В результате дрожания в момент поступления (дрожание сети) пакетов RTP или пакетов сообщений отправителя RTCP, в зависимости от того, которые из них используются для восстановления тактового генератора, мгновенное восстановление тактового генератора не возможно. Независимые аудио- и видеоединицы захвата с несинхронизированной дискретизацией тактовых генераторов могут привести к отклонению тактовых генераторов RTP, хотя медиа временные метки постоянно увеличиваются с фиксированной скоростью. RTCP сообщения отправителя несут NTP и RTP временные метки для каждого потока, и поэтому могут использоваться, чтобы ликвидировать отклонения привлеченных устройств. Во многих системах происходит дрожание при создании сообщений отправителя RTCP, в частности во взаимоотношениях между тактовыми генераторами RTP и NTP. Поэтому часто встречается ситуация, когда потоковые клиенты не достигают полной синхронизации озвучивания сразу после запуска, но должны принять во внимание определенное число сообщений отправителя RTCP прежде, чем будет получена точная синхронизация озвучивания между видео- и аудиопотоками. Если системный тактовый генератор отправителя должен быть восстановлен и имеется высокая степень колебания сети, то бывает также необходимо определенное число пакетов RTP или пакетов сообщений отправителя RTCP, в зависимости от того, которые из них используются для восстановления тактового генератора. Колебание сети и отклонение тактового генератора могут быть повторно вычислены во время приема потока в реальном времени, используя информацию многократных сообщений отправителя RTCP, как описано выше, в дополнение к RTP временным меткам, связанных пакетов данных.

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

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

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

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

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

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

В DVB-H и OMA-BCAST (Открытый Мобильный Альянс - Мобильные Услуги Телерадиовещания) ключевой поток определен как отдельный поток ключевых сообщений, посланных на порт UDP, отличный от того, на который послан связанный медиа поток. Каждое ключевое сообщение посылается как единый пакет UDP. OMA-BCAST называет эти сообщения краткосрочными ключевыми сообщениями (STKM), DVB-H называет их ключевыми потоковыми сообщениями (KSM). Хранение ключевых сообщений не вредит безопасности потоковой системы, потому что каждое ключевое сообщение связано с подписанием потокового обслуживания, и поэтому доступ к нему могут иметь только уполномоченные подписчики/устройства. Фактический шифровальный ключ в ключевом сообщении защищен программным или обслуживающим ключом.

Каждый ключ имеет связанный ключевой индикатор (ключ идентификатор - ID), который также указан в связанном зашифрованном медиа блоке доступа. Расшифровщик проверяет на существование ключа, связанного с ключом ID в зашифрованном блоке доступа.

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

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

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

Эта цель достигается при помощи устройства для обработки сохраненных пакетов данных согласно п.1 формулы, способа обработки сохраненных пакетов данных согласно п.20 формулы, устройства для чтения файла согласно пункту 22 формулы и способа чтения файла согласно пункту 23.

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

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

Эти полученные связанные данные или дополнительная информация сохраняется в файле, включающем контейнер медиа данных и контейнер метаданных в форме, так называемой, связанной хинтинговой дорожки приема ("arht"). Эта дорожка связана с соответствующей хинтинговой дорожкой приема, которая содержит связанные медиа пакеты, использующие, например, механизм исходной дорожки ISO/IEC 14496-12. Как и связанная хинтинговая дорожка приема, связанная хинтинговая дорожка приема, также хранит транспортный хронометраж в форме, например, временных меток системного тактового генератора приемника. Это может позволить восстановление условий хронометража приема исходного пакета на более поздней стадии во время воспроизведения.

Хинтинговые дорожки приема и связанные хинтинговые дорожки приема включают части данных пакета в контейнере медиа данных и части метаданных в контейнере метаданных файла.

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

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

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

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

Согласно осуществлению данного изобретения файл основан на ISO базовом медиа формате файла. Согласно предпочтительному осуществлению данного изобретения файл является 3GP- или МР4-файлом.

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

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

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

В соответствии с осуществлениями данного изобретения сохраненные первые и вторые пакеты данных и связанные сохраненные первые и вторые пакеты управления могут быть обработаны на ходу для синхронизации озвучивания, восстановления тактового генератора и/или регулировки отклонения тактового генератора. Этот вид воспроизведения эквивалентен моделируемому прямому приему записанных медиа потоков.

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

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

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

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

В дополнение к точному хронометражу транспортных пакетов желательно расширить доступную информацию о хинтинговых дорожках приема (сохраненные первые/вторые пакеты данных плюс мета информация), особенно информацию относительно образцов медиа данных в первых/вторых пакетах данных, например, покадровые SMPTE временные метки (SMPTE = Общество Инженеров Кино, Видео и Телевидения) или подзаголовки для видеодорожки.

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

Согласно осуществлению сохраненные пакеты данных могут включать пакеты потокового транспорта MPEG-2. Согласно другому осуществлению сохраненные пакеты данных могут включать пакеты RTP, включающие пакетированные медиа данные.

Согласно осуществлениям данного изобретения информация о декодировании определяется на основе медиа блока доступа. То есть для каждого блока доступа, например, медиа структуры, образец информации о декодировании хранится в контейнере медиа данных файла, где образец информации о декодировании указывает, из каких частей сохраненных пакетов данных следует взять какие образцы медиа данных, чтобы получить медиа структуры (например, видео/аудио). Мета информация, связанная с образцами информации о декодировании, хранится на дорожке метаданных информации о декодировании в контейнере метаданных. Дорожка метаданных информации о декодировании ("trak" блок/атом ISO базового медиа формата файла), таким образом, включает хронометраж и информацию о местоположении для образцов информации о декодировании.

Сохраненные образцы информации о декодировании и связанная с ними дорожка метаданных информации о декодировании, также называемая «виртуальной медиа дорожкой» в дальнейшем, строится на идее связанных хинтинговых дорожек приема и предлагает вышеописанные преимущества для воспроизведения. В части метаданных виртуальной медиа дорожки предоставлен медиа хронометраж для связанных образцов информации о декодировании в контейнере медиа данных. Образцы информации о декодировании предоставляют информацию, из которой сохраненные пакеты данных или транспортные блоки получают медиа данные для связанного медиа блока доступа, который делает ненужным депакетирование медиа пакетов. Виртуальные медиа дорожки могут быть созданы после заключительного приема медиа потоков, при использовании информации из хинтинговых дорожек приема и, в случае необходимости, связанных хинтинговых дорожек приема. Это осуществляется в «процессе обратной модификации», и получающийся файл позволяет устройству воспроизведения осуществлять поиск в файле и выполнять произвольный доступ к медиа, основанным на медиа хронометраже.

Виртуальные медиа дорожки могут наблюдаться в виде неполных медиа дорожек. Поэтому могут применяться и восстановленный хронометраж из RTP и хинтинговые дорожки приема RTCP и все индексы (обычно при использовании «таблиц образцов») медиа дорожек. Дополнительно хронометрированные дорожки метаданных могут ссылаться на виртуальные медиа дорожки и расширять их.

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

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

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

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

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

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

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