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

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

Иллюстрации

Показать все

Реферат

Изобретение имеет отношение к хранению и/или чтению пакетов данных транспортных протоколов и дополнительной информации, связанной с ними, и/или файла, имеющего хранилище медиа данных и хранилище метаданных, например файл, основанный на 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, которые обеспечивают связь и ключа и медиа потоков. Только после этого анализа становится ясно, какой ключ используется для какого блока доступа или видео структуры.

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

Эта цель достигается при помощи устройства для записи файла, способа записи файла и устройства для чтения файла и способа чтения файла.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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