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

Изобретение относится к хранению и/или чтению пакетов данных транспортных протоколов и дополнительной информации, связанной с ними, и/или файла, имеющего контейнер медиа данных и контейнер метаданных, как например файл, основанный на ISO (Международная организация по Стандартизации) базовом медиа формате файла. Техническим результатом является обеспечить мгновенный точный хронометраж синхронизации между различными записанными медиа потоками без сложной обработки во время каждого воспроизведения записанных медиапотоков. Указанный технический результат достигается тем, что устройство (600) для обработки сохраненных пакет данных (110; 112) в контейнере медиа данных (104) и сохраненной связанной мета информации в контейнере метаданных (106); связанная мета информация, включающая информацию о хронометраже транспортировки и информацию о местоположении, указывающую местоположение хранения сохраненных пакетов данных в контейнере медиа данных (104); устройство, включающее процессор (602) для определения, основанный на сохраненных пакетов данных (110; 112) и сохраненной связанной мета информации (124; 128); информация о декодировании (604; 704) для медиа полезной нагрузки сохраненных пакетов данных (110; 112), где информация о декодировании (604; 704) указывает, в какой момент времени повторно воспроизводить, какую полезную нагрузку сохраненных пакетов данных. 6 н. и 15 з.п. ф-лы, 12 ил.

 

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

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

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

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

Согласно осуществлению данного изобретения файл основан на ISO медиа формате файла.

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

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

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

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

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

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

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

фиг.1 - схематическая блок-схема устройства для записи файла согласно осуществлению данного изобретения;

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

фиг.3 показывает схематическую структуру файла, основанного на ISO базовом медиа формате файла;

фиг.4 показывает блок-схему способа записи файла согласно осуществлению данного изобретения;

фиг.5 показывает блок-схему дальнейшего способа записи файла согласно дальнейшему осуществлению данного изобретения;

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

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

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

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

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

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

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

Фиг.1 показывает схематическую блок-схему устройства 100 для записи файла 102, имеющего связанный контейнер медиа данных 104 и контейнер метаданных 106.

Устройство 100 включает приемник 108 для приема первых пакетов данных 110, включающих пакетированные первые образцы медиа данных, и для приема вторых пакетов данных 112, включающих вторые образцы медиа данных, основанные на отличном от первого тактового генератора, где вторые образцы медиа данных связаны с первыми образцами медиа данных. Далее, приемник 108 служит для приема первых пакетов управления 114, включающих информацию, показывающую отношение первого тактового генератора к исходному тактовому генератору, и для приема вторых пакетов управления 115, включающих информацию, показывающую отношение второго тактового генератора к исходному тактовому генератору. Далее, устройство 100 включает записывающее устройство 116 для хранения полученных первых и вторых пакетов данных 110, 112 и, по крайней мере, части полученных первых и вторых пакетов управления 114, 115 в контейнере медиа данных 104, и для хранения связанных метаданных в контейнере метаданных 106. Связанные метаданные включают информацию о хронометраже полученных первых и вторых пакетов данных 110, 112 и полученных первых и вторых пакетов управления 114, 115. Далее, связанные метаданные включают информацию о местоположении, указывающую местоположение сохраненных первых и вторых пакетов данных 110, 112 и сохраненных первых и вторых пакетов управления 114, 115 в контейнере медиа данных 104.

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

Файл 102 может быть файлом, основанным на ISO базовом медиа формате файла, согласно осуществлению данного изобретения. Например, формат файла может быть форматом файла, совместимым с MPEG-4, то есть файл 102 может быть так называемым файлом МР4, определенным ISO/IEC 14496-14. Формат файла МР4 состоит из метаданных, сохраненных в контейнере метаданных 106; описательная информации метаданных обычно связана с медиа, сохраненными в контейнере медиа данных 104. Контейнер медиа данных 104 может также находиться вне файла 102. Например, контейнер медиа данных 104 может быть отдельной ячейкой памяти, на которую могут делаться ссылки в файле 102. Обычно медиа данные, хранящиеся в контейнере медиа данных 104, являются закодированными видео и/или аудиоданными. Контейнеры 104 и 106 являются структурами данных, называемыми «блоками» (или «атомами») в родственных спецификациях.

Как правило, блок состоит из поля размера, поля типа и поля данных. Размер всего блока, то есть число байтов, включая поле размера, содержится в поле размера. Идентификатор блока, обычно четыре буквы, хранится в поле типа блока. Фактические данные заголовка и медиа данные хранятся в поле данных. Контейнер метаданных 106, который формирует формат файла МР4, описанный выше, использующий такую структуру блока, обычно называют блоком кино «moov». Точно также контейнер медиа данных 104 называют блоком медиа данных, в дальнейшем «mdat».

Контейнер медиа данных mdat 104 обычно состоит из последовательности единиц данных или образцов, которые сгруппированы в так называемые участки памяти. Участки памяти могут иметь различные размеры, и образцы в пределах участка памяти могут иметь различные размеры.

Согласно осуществлениям данного изобретения записывающее устройство 116 приспособлено, чтобы сохранять первые и вторые полученные пакеты данных 110, 112 как образцы в первых участках памяти 118 контейнера медиа данных 104. Записывающее устройство 116 далее приспособлено для хранения, по крайней мере, части полученных связанных первых и вторых пакетов управления 114, 115 как образцы во вторых участках памяти 122 контейнера медиа данных 104, как видно на фиг.2.

Хранение участков памяти 118, 122 может осуществляться методом чередования.

Образец участка памяти может, таким образом, включать один или несколько полученных пакетов данных. То есть образец первого участка памяти 118 может включать один или несколько полученных первых и/или вторых пакетов RTP 110, 112, А образец второго участка памяти 122 может включать один или несколько первых и/или вторых сообщений отправителя RTCP полученных первых и/или вторых пакетов управления 114, 115.

Множество первых участков памяти 118 может рассматриваться как часть медиа данных хинтинговой дорожки приема (RTP). Аналогично, множество вторых участков памяти 122 может рассматриваться как часть медиа данных связанной хинтинговой дорожки приема (RTCP) для хинтинговой дорожки приема. То есть, в случае фиг.1 или фиг.2, имеется одна хинтинговая дорожка приема RTP для всех полученных пакетов RTP 110, 112 и одна связанная хинтинговая дорожка приема RTCP для всех полученных пакетов RTCP 114, 115 или сообщений отправителя RTCP. Это означает минимальную сложность при записи.

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

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

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

Как показано на Фиг.1 и 2, записывающее устройство 116 может быть приспособлено для хранения информации о хронометраже и информации о местоположении первых и вторых полученных пакетов данных 110, 112 на первой дорожке метаданных 124 контейнера медиа данных 106, и для хранения информации о хронометраже и информации о местоположении полученных первых и вторых пакетов управления 114, 115, связанной с первыми и вторыми пакетами данных 110, 112 на второй дорожке метаданных 128 контейнера медиа данных 106. Более детальное описание процесса хранения будет дано со ссылкой на фиг.3.

Первая дорожка метаданных 124 может рассматриваться как часть метаданных хинтинговой дорожки приема RTP. Аналогично, вторая дорожка метаданных 124 может рассматриваться как часть метаданных связанной дорожки приема RTCP для хинтинговой дорожки приема.

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

Фиг.2 показывает структуру ISO медиа файла 102 с хинтинговой дорожкой приема RTP и связанной хинтинговой дорожкой приема RTCP.

Как описано выше, файл 102 включает контейнер метаданных 106, где контейнер метаданных 106 включает хинтинговую дорожку приема RTP 124, включающую информацию о хронометраже, связанную с полученными пакетами RTP, хранящимися как образцы в первых участках памяти 118-1, 118-2, и т.д., в контейнере медиа данных 104. То есть хинтинговая дорожка приема RTP 124 включает информацию о хронометраже транспортировки сохраненных (первых и вторых) пакетов RTP во время приема.

Этот хронометраж транспортировки может быть временной меткой приемного тактового генератора приемника 108, и/или он может быть RTP временной меткой полученных пакетов RTP 110, 112. То есть каждый пакет RTP или образец части метаданных 124 хинтинговой дорожки приема RTP включает указание на то, когда был принят соответствующий пакет RTP 110, 112 и, дополнительно, информацию относительно того, где был сохранен соответствующий пакет RTP в контейнере медиа данных 104.

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

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

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

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

Образец участка памяти может, таким образом, включать один или несколько полученных пакетов данных. То есть образец первого участка памяти может включать один или несколько полученных первых пакетов данных 110, образец второго участка памяти может включать один или несколько полученных вторых пакетов данных 112, образец третьего участка памяти может включать один или несколько первых сообщений отправителя RTCP полученных первых пакетов управления 114, и образец четвертого участка памяти может включать один или несколько вторых сообщений отправителя RTCP полученных вторых пакетов управления 115.

Множество первых участков памяти может рассматриваться как часть медиа данных первой хинтинговой дорожки приема, связанной с медиа первых пакетов 110. Множество вторых участков памяти может рассматриваться как часть медиа данных второй хинтинговой дорожки приема, связанной с медиа вторых пакетов 112. Множество третьих участков памяти может рассматриваться как часть медиа данных связанной хинтинговой дорожки для первой хинтинговой дорожки приема. Аналогично, множество четвертых участков памяти может рассматриваться как часть медиа данных связанной хинтинговой дорожки для второй хинтинговой дорожки приема. То есть, в случае хинтинговых дорожек приема RTP и связанных хинтинговые дорожек приема RTCP, хинтинговая дорожка приема может быть записана для каждой идентифицированной сессии RTP, и связанная хинтинговая дорожка приема может быть записана для каждой из записанных хинтинговых дорожек приема RTP.

Согласно осуществлению данного изобретения записывающее устройство 116 приспособлено для хранения информации о хронометраже и информации о местоположении первых полученных пакетов данных 110 на первой дорожке метаданных контейнера медиа данных 106, и для хранения информации о хронометраже и информации о местоположении вторых полученных пакетов данных 112 на второй дорожке метаданных контейнера метаданных 106. Записывающее устройство 116 приспособлено для хранения информации о хронометраже и информации о местоположении полученных первых пакетов управления 114, связанных с первыми пакетами данных 110 на третьей дорожке метаданных контейнера медиа данных 106 и для хранения информации о хронометраже и информации о местоположении полученных вторых пакетов управления 115, связанных со вторыми пакетами данных 112 на четвертой дорожке метаданных контейнера медиа данных 106.

Теперь обратимся к фиг.3, где будет дано более детальное описание контейнера метаданных 106 файла, основанного на ISO базовом медиа формате.

Контейнер медиа данных 106, называемый «moov» для файла, основанного на ISO базовом медиа формате, в дальнейшем размещается слоями в блоках с необходимым блоком 302 в форме блока кинозаголовка «mvhd», который содержит информацию о заголовке в целом, и множество «trak» блоков 304 (только один показан на фиг.3). Блок trak 304 в дальнейшем размещается слоями в двух блоках, где дорожка блока заголовка «tkhd» 306 определяет характеристики дорожки.

Блок trak 304 далее включает медиа блок «mdia» 308, содержащий все объекты, то есть декларационную информацию о пакетах данных (обычно медиа данные) в пределах дорожки. Блок mdia 308 включает блок медиа заголовка «mdhd» 310 и опорный блок обработчика «hdir» 312. Блок медиа заголовка mdhd 310 включает полную информацию, независимую от медиа и важную для покрытия характеристик «медиа», то есть пакетов данных на хинтинговой дорожке приема. Опорный блок обработчика hdlr 312 заявляет процесс, при помощи которого «медиа данные» представляются на дорожке, и соответственно, сущность «медиа» на дорожке, например, хинтинговая дорожка приема.

Далее, медиа блок mdia 308 включает блок медиа информации «minf» 314. Этот блок содержит все объекты, которые заявляют информацию о «медиа» характеристиках (пакеты данных) на хинтинговой дорожке. Блок медиа информации minf 314 далее включает хинтинговый медиа блок заголовка «hmhd» 316, содержащий общую информацию для хинтинговых дорожек. Далее, блок информационных данных «dinf» 318 состоит из блока медиа информации minf 314. Блок информационных данных dinf 318 содержит объекты, которые заявляют местоположение медиа информации на дорожке.

Далее, блок таблицы образцов «stbl» 320 состоит из блока медиа информации minf 314. Данные, по крайней мере, одного из участков памяти и образцов контейнера медиа данных mdat 104 содержатся в этом блоке, связанном с каждым элементом. Чтобы описать элементы в stbl 320, следует заметить, что блок stts 322 состоит из длины одного образца, блок stsd 324 состоит из деталей образца, блок stsz 326 состоит из размера образца, блок stsc 328 состоит из ряда образцов, включенных в участок памяти, то есть ряда пакетов данных, и блок stco 330 состоит из смещения участка памяти, каждый связан с образцами/пакетами в контейнере медиа данных 104.

Как было описано выше, записывающее устройство 116 приспособлено для хранения (транспортировки) информации о хронометраже и информации о местоположении полученных пакетов данных 110, 112 в частях метаданных 124, 128 связанных хинтинговых дорожек приема. В частности, информация о хронометраже, которая может быть информацией о хронометраже, выведенной из временной метки приема, или которая может быть связанной информацией о хронометраже, выведенной из полученных впоследствии пакетов данных/управления, хранится в связанном блоке таблицы образцов stbl 320 дорожек 124, 128.

Блок-схема, показывающая процесс приема и хранения зависимой от времени мета информации полученных пакетов данных в блоке таблицы образцов stbl 320, состоящем из дорожки метаданных 124; дорожка 128 показана на Фиг.4.

На первой ступени 402 пакет данных, который может быть пакетом RTP или пакетом RTCP, получается приемником 108. На второй ступени 404 информация о хронометраже, связанная с полученным пакетом данных, принимается системой тактового генератора приемника 108 в форме временной метки приема или из RTP временной метки полученного пакета данных. На следующей ступени 406 вычисляется разница во времени от получения предыдущего пакета данных. На ступени 408 вычисленная разница во времени записывается в блок stts 322 соответствующей дорожки метаданных, где stts позволяет осуществить индексацию от времени приема до соответствующего числа образцов, то есть полученного и сохраненного пакета. То есть, согласно осуществлениям данного изобретения время расшифровки для блока образцов stts 322 содержит дельты времени приема: RT(n+1)=RT(n)+stts(n), где RT(n) обозначает время приема для пакета n и stts (n) является разархивированным элементом таблицы для пакета n.

Как было упомянуто выше, образцы (пакеты) в пределах контейнера медиа данных 104 сгруппированы в участки памяти 110, 112. Эти участки памяти могут иметь различные размеры, и также и образцы в пределах участка памяти могут иметь различные размеры. Образец для блока участка памяти stsc 328 может использоваться, чтобы найти участок памяти, который содержит определенный образец, его положение, и описание связанного образца. Каждый элемент дает индекс первого участка памяти серии участков памяти с теми же самыми характеристиками. Вычитая один элемент из предыдущего, можно вычислить, сколько участков памяти находится в соответствующей серии. Это может быть преобразовано в подсчет образцов, посредством увеличения соответствующих образцов на участок памяти.

Таблица смещения участка памяти stco или со64 330 дает индекс каждого участка памяти в контейнере медиа данных 104. Существует два варианта, позволяющих использовать 32-битовое или 64-битовое смещения. Последнее используется при управлении очень большими файлами 102. Смещения обычно являются смещениями файла, а не смещениями какого-то блока в пределах файла, например, контейнер медиа данных. Это позволяет обращаться к медиа данным в файлах без использования любой структуры блока.

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

После приема пакета данных приемником 108 на первой ступени 502 полученный пакет данных 110, 112 сохраняется в контейнере медиа данных 104, связанном с файлом 102 на второй ступени 504. Таким образом, полученный пакет данных 110, 112 сохраняется как образец в адресе ячейки в контейнере медиа данных 104. На третьей ступени 506 вычисляется смещение адреса ячейки к началу файла 102 (если контейнер медиа данных 104 составлен файлом 102), или к началу контейнера медиа данных 104 (если контейнер медиа данных 104 отмечает отдельный файл). После этого вычисленное смещение записывается в stco или со64 блока 330 связанной дорожки метаданных 124.

То же самое справедливо для хранения пакетов управления 114, 115 и связанной с ними дорожки метаданных 128.

Чтобы суммировать все вышесказанное, следует дать краткий обзор операций, выполняемых для создания хинтинговой дорожки приема или связанной хинтинговой дорожки приема, как, например, хинтинговые дорожки приема RTP/RTCP или хинтинговые дорожки приема ключевых потоков, которые далее будут описаны более подробно. То же самое справедливо для виртуальных медиа дорожек, что будет объяснено ниже. Когда нужно добавить дорожку к файлу 102, основанному на ISO базовом медиа формате файла, обычно осуществляются следующие операции в устройстве 100 согласно осуществлениям данного изобретения.

- Добавление нового блока trak к блоку moov.

- Добавление нового блока tkhd к недавно созданному блоку trak. Этот блок будет содержать характеристики дорожки, например, время создания, дорожка ID, размеры «медиа» дорожки и длина.

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

- Добавление нового блока mdia к недавно созданному блоку trak.

- Добавление нового блока mdhd к недавно созданному блоку mdia. Этот блок будет содержать характеристики медиа на дорожке, например, длина медиа и язык.

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

- Добавление нового блока minf к недавно созданному блоку mdia.

- Добавление нового блока hmhd к недавно созданному блоку minf. Этот блок будет содержать информацию о заголовке для хинтинговых дорожек.

- Добавление нового блока dinf к недавно созданному блоку mdia.

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

- Добавление нового блока stbl к недавно созданному блоку minf. Этот блок является контейнером для блоков, которые содержат хронометраж и индексацию данных образцов (например, RTP/RTCP или пакеты ключевых потоков, виртуальные медиа образцы) на дорожке.

- Добавление нового блока stsd к недавно созданному блоку stbl. Этот блок содержит медиа идентификацию (обычно называемую 4СС) и внеполосную конфигурацию образцов.

- Добавление нового блока stts к недавно созданному блоку stbl. Этот блок будет содержать информацию о длине каждого отдельного медиа образца (например, RTP/RTCP или пакеты ключевых потоков, виртуальные медиа образцы) на дорожке.

- Добавление нового блока stsc к недавно созданному блоку stbl. Этот блок будет содержать информацию о числе образцов (например, RTP/RTCP или пакеты ключевых потоков, виртуальные медиаобразцы), сгруппированных в участок памяти.

- Добавление нового блока stsz к недавно созданному блоку stbl. Этот блок будет содержать информацию о размере каждого отдельного медиа образца (например, RTP/RTCP или пакеты ключевых потоков, виртуальные медиа образцы) на дорожке.

- Добавление нового stco или со64 блока к недавно созданному блоку stbl. Этот блок будет содержать информацию о смещении файла первого байта каждого участка памяти.

- Произвольное добавление других блоков, разрешенных в таблице образцов, например, блок stss, который индексирует образцы (например, RTP/RTCP или пакеты ключевых потоков, виртуальные медиа образцы), которые могут быть использованы для произвольного смещения.

Образцы группируются в участках памяти, которые являются последовательным блоком образцов без промежутков. Когда образец должен быть добавлен к файлу, он или присоединяется к существующему участку памяти, или начинает новый участок памяти. Для каждого нового образца добавляются элементы к блокам stts и stsz, а блок stsc изменяется, чтобы показывать число образцов в существующем участке памяти. Если образец записывается в новый участок памяти, новый элемент добавляется к блоку stoo (или со64), а блок stsc изменяется, чтобы показывать число образцов в новом участке памяти. Участок памяти, то есть сами необработанные выборочные данные, записывается в файл или внутри блока mdat или во внешний файл (на который можно сослаться в рамках файла).

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

Параллельное хранение полученных пакетов данных 110, 112 и связанные сообщения управления 114, 115 на хинтинговых дорожках приема и связанные хинтинговые дорожки приема является идеальным решением во время записи и/или применения временного сдвига. Однако, если записанный файл 102 предназначен для длительного хранения и будет в конечном счете воспроизведен много раз, может быть желательно избежать анализирования сохраненных данных во время каждого воспроизведения и иметь непосредственно доступное время носителя без дальнейших вычислений. Обычно это будет подразумевать депакетирование полезной нагрузки пакетов данных из хинтинговой дорожки приема (RTP) и сохранение ее для дополнительных медиа дорожек с одним элементарным потоком на дорожку. Это не всегда возможно или желательно, например, если транспортное шифрование было применено к потоковым пакетам данных, если емкость запоминающего устройства ограничена. В дополнение к точному хронометражу транспортных пакетов, хранящихся в контейнере медиа данных 104, желательно иметь доступ к расширенной информации о хинтинговых дорожках приема, в частности к информации о медиа потоках внутри, например, покадровые SMPTE временные метки или подзаголовки для видеодорожки.

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

Устройство 600 отличается от устройства 100, показанного на Фиг.1 в процессоре 602 для определения, основанном на сохраненных пакетах данных и сохраненной связанной мета информации, информации о декодировании для полезной нагрузки сохраненных пакетов данных, где информация о декодировании указывает, в какой момент времени повторно воспроизводить какую полезную нагрузку сохраненных пакетов данных. Устройство 600 может быть расширением устройства 100, однако, устройство 600 может также рассматриваться отдельно, в особенности, если оно используется для обработки сохраненных не-RTP/RTCP пакетов, как, например, MPEG-2 TS пакеты.

В осуществлении, показанном на Фиг.6, пакеты данных сохранены в контейнере медиа данных 104, связанном с файлом 102. Мета информация хранится в контейнере метаданных 106 файла 102, как было объяснено выше. Сохраненные пакеты данных могут сохраняться как образцы на участках памяти 118, 122 контейнера медиа данных 104. На образцы и/или участки памяти ссылаются посредством связанных дорожек метаданных 124, 128 в контейнере метаданных 106.

Согласно осуществлению данного изобретения сохраненные пакеты данных могут включать первые и вторые пакеты RTP 110, 112 включающие первые и вторые пакетированные медиаданные и связанные первые и вторые пакеты RTCP 114, 115, как описано выше.

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

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

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

Процессор 602 может получить доступ к контейнеру медиа данных 104, чтобы сохранить образец информации о декодировании как виртуальный медиа образец на участке памяти 604 в контейнере медиа данных 104. Далее, процессор 602 может получить доступ к контейнеру медиа данных 106, чтобы сохранить мета информацию о декодировании, связанную с образцом информации о декодировании (виртуальный медиа образец) и указывающую на время декодирования и местоположение образца информации о декодировании на дорожке метаданных 606 в контейнере медиа данных 104. Как было ранее объяснено, образцы информации о декодировании могут рассматриваться как виртуальные медиа образцы, при отнесении каждого из них к блоку доступа связанного видео- или аудиопотока. Виртуальные медиа образцы включает информацию о том, как восстановить связанную аудио/видео структуру из сохраненных пакетов данных в контейнере медиа данных 104.

Теперь обратимся к фиг.7, на котором показан файл 702, включающий виртуальные медиа образцы 704 в контейнере медиа данных 104 и связанную дорожку метаданных 706 в контейнере метаданных 106.

Файл 702 также сохраняет пакеты RTP на участках памяти 708, составленных контейнером медиа данных 104, и пакеты RTCP, составленные участками памяти 710. С сохраненными пакетами RTP связана RTP дорожка метаданных 712. С сохраненными пакетами RTCP связана RTCP дорожка метаданных 714 в контейнере метаданных 106.

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

Общие данные о конфигурации полезной нагрузки виртуального медиа образца включают общие данные о конфигурации полезной нагрузки невиртуальной медиа дорожки того же типа, например, виртуальная медиа дорожка для закодированного видео Н.264 будет также содержать AVCC (Configuration Record - запись конфигурации) в блоке avcC в описании образца. Кроме того, они могут включать информацию о процессе дехинтинга хинтинговой дорожки приема, например, максимальный размер медиа образца после повторного ассемблирования из хинтинговой дорожки приема при использовании информации, предоставленной в образце полезной нагрузки виртуальной медиа дорожки.

Полезная нагрузка образца виртуальной медиа дорожки состоит из «команд», которые описывают процесс извлечения образца медиа данных из хинтинговой дорожки приема. Эти команды получены из конструкторов пакетов для хинтинговых дорожек и включают «непосредственный конструктор», «выборочный конструктора» и «конструктор описания образца». Непосредственный конструктор состоит из полей «длины», «данных» и «клавиатуры». «Длина» указывает длину поля «данных». «Клавиатура» может использоваться, чтобы заполнить избыточное место.

Выборочный конструктор состоит из полей исходного индекса дорожки (trackrefindex), длины, числа образцов (samplenumber) и смещения образцов (sampleoffset). Исходный индекс дорожки (trackrefindex) указывает хинтинговую дорожку приема, из которой извлечены данные; число образцов (samplenumber) указывает число образцов хинтинговой дорожки приема. Поле смещения образцов (sampleoffset) определяет начало блока данных длины; «длина», которая должна быть извлечена.

При использовании конструкторов образцов компактное представление медиа образца возможно без копирования данных.

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

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

Фиг.8 показывает блок-схему записи потока и автономной оптимизации файла.

На первой ступени 802 хинтинговые дорожки приема и произвольно связанные хинтинговые дорожки приема (например, RTP и RTCP) сохраняются в файле 102, как объяснено выше. После завершения записи, то есть, когда пакеты данных сохранены в файле 102 в форме хинтинговой дорожки приема и в конечном счете связанные пакеты управления сохранены в файле на связанной хинтинговой дорожке приема, различные медиа потоки определяются в пределах записанной хинтинговой дорожки приема на ступени 804. Это означает, что ступень 804 включает определение, например, аудио- и видео потоков или пакетов данных, связанных с аудио- и видеопотоками, соответственно, в пределах записанной хинтинговой дорожки приема. Это может быть сделано путем извлечения соответствующей информации из протокола сеанса описания (SDP), как было объяснено выше.

Следовательно, процессор 602 приспособлен, чтобы определить, какие из сохраненных пакетов данных связаны с первыми или вторыми образцами медиа данных, и чтобы определить вторые образцы информации о декодировании (вторые виртуальные медиа образцы), связанные со вторыми образцами медиа данных в контейнере медиа данных 104.

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

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

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

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

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

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

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

Фиг.9 показывает ряд сохраненных RTP пакетов RTP1, RTP2, RTP3. RTP пакеты RTP1, RTP2, RTP3 сохраняются как образцы в виртуальном медиа контейнере 104. RTP пакеты RTP1, RTP2, RTP3 каждый включает заголовок H1, H2, Н3 и полезную нагрузку PL1, PL2, PL3, включающую образцы медиа данных. Типичный размер заголовка - А биты, соответственно, размер полезной нагрузки - (В-А) биты. Данные первой медиа структуры, которая может быть видео- или аудиоструктурой, разделены между полезными нагрузками первого RTP пакета RTP1 и второго RTP пакета RTP2. Типично, медиа данные первой медиа структуры доходят от байта A RTP пакета RTP1 до байта A+Y пакета данных RTP2. Медиа данные второй медиа структуры разделены между пакетом данных RTP2, начинающемся в байтовом адресе A+Y, и пакетом данных RTP3, заканчивающемся в байтовом адресе A+Z пакета данных RTP3.

Виртуальные медиа образцы VMS1 и VMS2 связаны с первой медиа структурой и второй медиа структурой, соответственно. Согласно осуществлению данного изобретения виртуальные медиа образцы VMS1, VMS2 включают информацию о том, где найти медиа данные первой и второй медиа структуры в сохраненных пакетах данных RTP1, RTP2, RTP3. То есть виртуальный медиа пакет VMS1 включает информацию о том, что медиа данные структуры 1 могут быть получены посредством доступа к пакету данных RTP1 из байтового адреса А в байтовый адрес В, и посредством обращения к пакету данных RTP2 из байтового адреса А в байтовый адрес A+Y. Виртуальный медиа образец 2 включает информацию о том, где получить медиа образцы для медиа структуры 2. То есть он хранит информацию о том, что медиа структура 2 начинается в пакете данных RTP2, байтовый адрес от A+Y до байтового адреса В, и что последующие медиа образцы структуры 2 могут быть найдены в пакете данных RTP3, достигаемом от байтового адреса А до байтового адреса A+Z.

На оба виртуальных медиа образца VMS1 и VMS2, которые формируют части медиа данных виртуальной медиа дорожки, ссылается часть метаданных виртуальной медиа дорожки в контейнере метаданных 106. Информация о времени декодирования образца может быть найдена в блоке stts для каждого виртуального медиа образца VMS1, VMS2. Таким образом, информация о времени декодирования образца отражает медиа хронометраж, который может быть определен посредством оценки сохраненных RTCP пакеты, связанных с RTP пакетами RTP1, RTP2, RTP3, как объяснено выше.

Фиг.10 иллюстрирует картирование образцов хинтинговой дорожки приема до образцов виртуальных медиа дорожек.

В отличие от фиг.9, фиг.10 показывает сохраненные пакеты данных MPEG-2 транспортного потока М2Т. Транспортный поток М2Т включает пакеты данных А1-А7, включающие аудиообразцы, и пакеты данных V1-V7, включающие видеообразцы.

Виртуальный медиа образец VMSA1 связан с первой аудиоструктурой, которая разделена между полезными нагрузками аудиопакетов А1 и А2.

Виртуальный медиа образец VMSA1 указывает, какую часть полезной нагрузки А1 и А2 следует взять, чтобы получить аудиоструктуру 1. Аналогично, виртуальный медиа образец VMSA2 связан со второй аудиоструктурой, медиа данные которой могут быть найдены в полезных нагрузках аудиопакета А2 и A3. Виртуальный медиаобразец VMSA3 ссылается на аудиопакет А4 и части аудиопакета А5 для получения третьей аудиоструктуры. Виртуальный медиаобразец VMSA4 ссылается на оставшуюся часть аудиопакета А5 и полезную нагрузку аудиопакетов А6 и А7 для аудиоструктуры 4.

Аналогично, виртуальный медиа образец VMSV1, связанный с первой видеоструктурой, ссылается на полезные нагрузки видеопакета V1, V2 и V3 для первой видеоструктуры. Виртуальный медиа образец VMSV2 ссылается на полезные нагрузки видеопакетов V4, V5 и V6 для получения медиаобразцов для второй видеоструктуры.

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

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

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

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

- Анализ блока ftyp для определения, могут ли потенциально быть проанализированы содержание файла и его структура. Если файл не может быть проанализирован, прерывается операция чтения файла.

- Анализ блока moov и определение числа блоков trak внутри. Если нет дорожек, прерывается операция чтения файла.

- Анализ блока hdlr внутри блока minf каждой дорожки для определения, имеется ли программа обработки, пригодная для типа обработчика, определенного в блоке hdlr. Если обработчик не распознан, прерывается операция чтения файла для этой следа.

- Анализ блока stbl и блока stsd внутри блока minf каждой дорожки. Блок stsd содержит идентификацию содержания дорожки и описывает ее содержание. Если содержание не понято, прерывается операция чтения файла следа.

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

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

- Для виртуальных медиа дорожек, виртуальная медиа дорожка используется вместо RTP или MPEG-2 TS хинтинговой дорожки приема. Эта дорожка уже содержит данные для реверсирования операции хинтинга, то есть, какие данные хинтинговой дорожки приема должны быть извлечены и расширены другими данными, чтобы создать блок данных элементарного потока, которые декодер может распознать.

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

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

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

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

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

- Определения участка памяти С, образец S располагается внутри при использовании данных блока stsc.

- Анализ блока stco (или со64) для определения смещения файла F участка памяти С

- Анализ блока stsz для получения размера L образца S и размеров K_i всех предыдущих P_i образцов внутри участка памяти.

Тогда данные становятся доступными в положении (F+sum (K_i)) в файле и имеют размер L.

Время, когда данные должны быть воспроизведены до конца, определяется информацией, доступной в блоке stts. Этот блок содержит неравномерно закодированные длины и D_j для каждого индивидуального образца j. Время воспроизведения для k-го образца S тогда является суммой всех D_j длин, при j<k.

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

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

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

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

Фиг.12 показывает потоковые пакеты данных 1302-1, 1302-2, 1302-3, каждый из которых имеет полезную нагрузку, зашифрованную с шифровальными ключами k₀, k₁, k₂. Имеется ключевой поток, включающий пакеты ключевого потока 1304-1, 1304-2, 1304-3 и 1304-4 и связанный с пакетами данных 1302. Пакет ключевого потока 1304-1, который передается прежде, чем связанный с ним пакет данных 1302-1, включает ключ к шифру k₀ для декодирования зашифрованной полезной нагрузки пакета данных 1302-1. Таким образом, у шифровального ключа k₀ имеется срок службы d₀, связанный с ним, гарантирующий то, что связанные пакеты данных могут быть зашифрованы. То же самое справедливо для второго пакета ключевого потока 1304-2 и его шифровального ключа k₁, который может использоваться для расшифровки полезной нагрузки связанного пакета данных 1302-2. Также здесь связанный пакет ключевого потока 1304-2 передается значительно раньше пакета данных 1302-2, и у шифровального ключа k₁ имеется срок службы d₁, гарантирующий правильное декодирование полезной нагрузки пакета данных 1302-2.

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

Фиг.11 показывает устройство 1100 для записи файла 1102, имеющего связанный контейнер медиа данных 1104 и контейнер метаданных 1106 согласно осуществлению данного изобретения.

Устройство 1100 включает приемник 1108 для приема пакетов данных 1110, каждый из которых включает полезную нагрузку, и для приема пакетов ключевого потока 1112, включающих множество шифровальных ключей, где каждый шифровальный ключ связан с полезной нагрузкой полученных пакетов данных. Далее, устройство 1100 включает записывающее устройство 1116 для сохранения полученных пакетов данных 1110 и полученные пакетов потока ключевого 1112 в контейнере медиа данных 1104 и для сохранения связанных метаданных в контейнере метаданных 1106; связанные метаданные, включающие информацию о транспортном хронометраже полученных пакетов данных 1110 в полученных пакетах ключевого потока 1112, и включающие информацию о местоположении, указывающую местоположение сохраненных пакетов данных 1110 и сохраненных пакетов ключевого потока 1112 в контейнере медиа данных 1104.

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

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

Как было объяснено выше, файл 1102 может быть файлом, основанным на ISO базовом медиа формате файла, например, файл МР4. Следовательно, записывающее устройство 1116 приспособлено для сохранения первых участков памяти 1118 в первой таблице смещения участков памяти stco или со64 первой дорожки метаданных 1124 контейнера метаданных moov 1106, где первая таблица смещения участков памяти показывает индекс каждого первого участка памяти 1118 в файле 1102 или контейнере медиа данных 1104, в зависимости от того, является ли контейнер медиа данных 1104 частью файла 1102 или нет. Индексы вторых участков памяти в контейнере медиа данных 1104 сохранены во второй таблице смещения участков памяти второй дорожки метаданных 1128 контейнера метаданных 1106 таким же образом, как было объяснено для первых участков памяти.

Как уже было объяснено для случая параллельного хранения пакетов данных 110, 112 и связанных пакетов управления 114, 115 на хинтинговых дорожках приема и связанных хинтинговых дорожках приема, информация о хронометраже транспортировки, то есть время приема или RTP временная метка для пакетов данных 1110 сохраняется в первом блоке stts, состоявшем из первой дорожки метаданных 1124. Аналогично, информация о хронометраже транспортировки или информация о дифференциальном хронометраже транспортировки сохраняется во втором блоке stts второй дорожки метаданных 1128, связанной со вторыми участками памяти 1120.

Далее, чтобы облегчить воспроизведение после завершения приема потока, может быть выполнена одноразовая обработка для преобразования хинтинговой дорожки приема ключевого потока в виртуальную дорожку метаданных. С этой целью устройство 1100 включает процессор (не показанный) для присваивания, основанный на сохраненных пакетах данных 1110 и связанной мета информации 1124, и основанный на сохраненных пакетах ключевого потока 1112 и связанной мета информации о ключевом потоке 1128, информации о декодировании для полезной нагрузки сохраненных пакетов данных 1110, где информация о декодировании, указывает, какой шифровальный ключ использовать, в какой момент времени, чтобы повторно воспроизвести полезную нагрузку сохраненных пакетов данных 1110.

То есть ключевые сообщения с хинтинговой дорожки приема ключевого потока с хронометражем транспортировки преобразуются в ключевые образцы на виртуальной дорожке метаданных с медиа хронометражем. Это делается на основании той же самой идеи, которая была объяснена выше для виртуальных медиа дорожек. То есть ключевые образцы созданы и сохранены в контейнере медиа данных 1104. Таким образом, каждый ключевой образец связан с блоком доступа или медиа структурой и включает информацию, на основании которой шифровальный ключ должен использоваться для связанной медиа структуры. На связанной дорожке метаданных 1128, включающей блок stts, дана информация о декодировании ключевого образца. Информация о декодировании ключевого образца указывает, в какой момент времени будет получен доступ к соответствующему ключевому образцу, который опять ссылается на данные о полезной нагрузке сохраненных пакетов данных, чтобы вывести соответствующую зашифрованную медиа структуру. В случае необходимости, ключевые образцы виртуально удваиваются таким образом, что каждый медиа образец на медиа дорожке имеет связанный ключевой образец (с тем же самым ключевым ID) на ключевой дорожке.

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

Для чтения файла 1102 (файл, сохраняющий пакеты данных 1110 и сохраняющий связанные пакеты ключевого потока 1112 в контейнере медиа данных 1104 и сохраняющий связанные метаданные в контейнере метаданных 1106) осуществления данного изобретения предлагают устройство, включающее процессор для присваивания, основанный на сохраненных пакетах данных 1110, основанный на связанном пакете мета информации 1124 и основанный на сохраненных пакетах ключевого потока 1112 и связанной мета информации о ключевом потоке 1128, зашифрованной информации о полезной нагрузке сохраненных пакетов данных, где информация о декодировании указывает, какой шифровальный ключ должен использоваться, в какое время для повторного воспроизведения полезной нагрузки сохраненных пакетов данных.

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

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

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

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

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

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

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

В последнее время вышеупомянутый ISO базовый медиа формат файла был пополнен добавленными вызываемыми фрагментами кинофильма, которые были, например, описаны в американской заявке на патент US 2007/0130498 А1. Следует упомянуть, что осуществления данного изобретения могут также быть применены к упомянутым фрагментам кинофильма.

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

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

1. Устройство (600) для обработки сохраненных пакетов транспортных данных (110; 112) в контейнере медиаданных (104); сохраненные пакеты транспортных данных (110; 112), включающие медиаполезную информацию пакетированных медиаблоков доступа и управляющую информацию для восстановления точного медиахронометража медиаблоков доступа, и для обработки сохраненной связанной метаинформации в контейнере метаданных (106); связанная метаинформация, включающая информацию о хронометраже транспортировки и информацию о местоположении, указывающую местоположение хранения сохраненных пакетов транспортных данных в контейнере медиаданных (104); характеризующееся тем, что включает процессор (602) для определения, основанный на управляющей информации и информации о хронометраже транспортировки, на информации о времени декодирования образца (606; 706) для каждого медиаблока доступа, где информация о времени декодирования образца отражает медиахронометраж и указывает, в какой момент времени повторно воспроизводить какую полезную информацию сохраненных пакетов транспортных данных, и для определения, основанного на содержании сохраненных пакетов транспортных данных (110; 112) и сохраненной связанной метаинформации (124; 128), образцы информации о декодировании (604; 704) на основе медиаблока доступа, так что каждый образец информации о декодировании (604; 704) связан с медиаблоком доступа и содержит ссылки на один или несколько пакетов транспортных данных, важных для депакетирования медиаблоков доступа из сохраненных пакетов транспортных данных (110; 112), где процессор (602) приспособлен для определения образца информации о декодировании (604; 704), так что он указывает адрес начала и адрес конца связанного медиаблока доступа в пределах сохраненных пакетов транспортных данных (110; 112), где адрес начала обозначает местоположение образца медиаданных, указывающего начало медиаблока доступа, и где адрес конца обозначает местоположение образца медиаданных, указывающего конец медиаблока доступа, и где процессор (602) приспособлен для хранения в контейнере медиаданных (104), упомянутого образца информации о декодировании, и для хранения связанной информации о времени декодирования образца (606; 706) как метаинформации о декодировании (606; 706) в контейнере метаданных (106); метаинформация о декодировании (606; 706) указывает время декодирования и местоположение связанного образца информации о декодировании в контейнере медиаданных (104).

2. Устройство по п.1, характеризующееся тем, что процессор (602) приспособлен для хранения образца информации о декодировании на участке памяти информации о декодировании (604; 704) контейнера медиаданных (104); участок памяти информации о декодировании (604; 704), включающий, по крайней мере, один образец информации о декодировании.

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

4. Устройство по п.2 или 3, характеризующееся тем, что процессор (602) приспособлен для сохранения времени декодирования образца информации о декодировании в блоке таблицы образцов (stts), обеспечивающего индексацию от времени декодирования образца информации о декодировании до связанного с ним числа образцов на участке памяти информации о декодировании (704).

5. Устройство по п.1, характеризующееся тем, что сохраненные пакеты транспортных данных (110; 112) включают пакеты транспортного потока MPEG-2.

6. Устройство по п.1, где сохраненные пакеты транспортных данных (110; 112) включают пакеты RTP (Транспортный протокол реального времени), включающие пакетированные образцы медиаданных.

7. Устройство по п.1, характеризующееся тем, что сохраненные пакеты транспортных данных включают первые (110) и вторые пакеты транспортных данных (112), связанные с первыми и вторыми медиапотоками, и где процессор (602) приспособлен для определения, который из сохраненных пакетов транспортных данных (110; 112) связан с первым или вторым медиапотоком.

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

9. Устройство по п.8, характеризующееся тем, что процессор (602) приспособлен для хранения первого/второго образца информации о декодировании в контейнере медиаданных (104) и хранения первой/второй метаинформации о декодировании (606; 706) в контейнере метаданных (106);
первая/вторая метаинформация о декодировании (606; 706), указывающая первое/второе время декодирования и первое/второе местоположение первого/второго образца информации о декодировании в контейнере медиаданных (104).

10. Устройство по п.8 или 9, характеризующееся тем, что процессор (602) приспособлен для хранения первого/второго образца информации о декодировании на первом/втором участке памяти информации о декодировании (604; 704) контейнера медиаданных (104); первый/второй участок памяти информации о декодировании (604; 704), включающий, по крайней мере, один первый/второй образец информации о декодировании.

11. Устройство по п.10, характеризующееся тем, что процессор (602) приспособлен для хранения первого/второго времени декодирования первого/второго образца информации о декодировании в первом/втором блоке таблицы образцов (stts), позволяющем индексацию от первого/второго времени декодирования первого/второго образца информации о декодировании до связанного с ним числа образцов на первом/втором участке памяти информации о декодировании (704).

12. Устройство по п.7, характеризующееся тем, что сохраненные первые пакеты транспортных данных (110) включают первые пакеты RTP, включающие первые пакетированные медиаданные, и где сохраненные вторые пакеты транспортных данных (112) включают вторые пакеты RTP, включающие вторые пакетированные медиаданные.

13. Устройство по п.12, характеризующееся тем, что сохраненные первые и вторые пакеты RTP (110; 112) дополнительно включают, по крайней мере, части первых и вторых пакетов RTCP (Транспортный Протокол Управления Передачей в Реальном Времени) (114; 115), связанных с первыми и вторыми пакетами RTP (110; 112), и где метаинформация дополнительно включает информацию о хронометраже транспортировки и информацию о местоположении первых и вторых пакетов RTCP в контейнере метаданных (106), где части сохраненных связанных первых и вторых пакетов RTCP сохранены как образцы на участках памяти RTCP (122) контейнера медиаданных (104), и где информация о хронометраже и информация о местоположении пакетов RTCP (114; 115) сохраняется на дорожке RTCP (128) контейнера метаданных (106).

14. Устройство по п.13, характеризующееся тем, что процессор (602), сконфигурированный для определения, основывается на сохраненных первых и вторых пакетах RTP (110; 112), сохраненных первых и вторых пакетах RTCP и основывается на сохраненной связанной метаинформации (124; 128), первой и второй информации о декодировании (604; 704) соответственно, где первая и вторая информация о декодировании (604; 704) указывает, в какой момент времени повторно воспроизводить какую полезную информацию сохраненных первых и вторых пакетов RTP соответственно.

15. Устройство по п.1, характеризующееся тем, что контейнер медиаданных (104) включает пакеты ключевого потока (1112), каждый из которых включает шифровальный ключ, где шифровальный ключ связан с полезной информацией, по крайней мере, одного из сохраненных пакетов транспортных данных, и где информация о хронометраже транспортировки и информация о местоположении сохраненных пакетов ключевого потока (1112) сохранена в контейнере метаданных (106).

16. Устройство по п.15, характеризующееся тем, что процессор (602), приспособленный для присваивания, основан на сохраненных пакетах транспортных данных (110; 112), основан на связанной метаинформации (124; 128) и основан на сохраненных пакетах ключевого потока (1112) и на связанном ключевом потоке метаинформации (1128); информация о декодировании для полезной информации сохраненных пакетов транспортных данных (110; 112), где информация о декодировании указывает, какой шифровальный ключ использовать, в какое время повторно воспроизводить полезную информацию сохраненных пакетов транспортных данных (110; 112).

17. Способ обработки сохраненных пакетов транспортных данных (110; 112) в контейнере медиаданных (104); сохраненные пакеты транспортных данных (110; 112), включающие медиаполезную информацию пакетированных медиаблоков доступа и управляющую информацию для восстановления точного медиахронометража медиаблоков доступа и для обработки сохраненной связанной метаинформации в контейнере метаданных (106); связанная метаинформация, включающая информацию о хронометраже транспортировки и информацию о местоположении, указывающую место хранения сохраненных пакетов транспортных данных в контейнере медиаданных; характеризующийся тем, что включает:
определение, основанное на управляющей информации и информации о хронометраже транспортировки, информации о времени декодирования образца (606; 706) для каждого медиаблока доступа, где информация о времени декодирования образца отражает медиахронометраж и указывает, в какой момент времени повторно воспроизводить какую полезную нагрузку сохраненных пакетов транспортных данных, и
определение, основанное на содержании сохраненных пакетов транспортных данных (110; 112) и сохраненной связанной метаинформации (124; 128), на образцах информации о декодировании (604; 704) на основе медиаблока доступа, так что каждый образец информации о декодировании связан с медиаблоком доступа и содержит ссылки на один или несколько пакетов транспортных данных, важных для депакетирования медиаблока доступа из сохраненных пакетов транспортных данных (110; 112), где образец информации о декодировании (604; 704) определяется так, что он указывает адрес начала и адрес конца связанного медиаблока доступа в пределах сохраненных пакетов транспортных данных (110; 112), где адрес начала обозначает местоположение образца медиаданных, указывающего начало медиаблока доступа, и где адрес конца обозначает местоположение образца медиаданных, указывающего конец медиаблока доступа; и
хранение в контейнере медиаданных (104); образца информации о декодировании, и хранение связанной информации о времени декодирования образца как метаинформации о декодировании (606; 706) в контейнере метаданных (106); метаинформация о декодировании (606; 706), указывающая время декодирования и местоположение связанного образца информации о декодировании в контейнере медиаданных (104).

18. Машиночитаемый носитель информации с сохраненной на нем компьютерной программой для реализации способа по п.17, когда компьютерная программа запущена на компьютере и/или микроконтроллере.

19. Устройство для чтения файла (702); файле, сохраненном в контейнере медиаданных (104), связанном с файлом, пакетами транспортных данных (110; 112), включающими медиаполезную информацию пакетированного медиаблока доступа и сохраненными в контейнере медиаданных (104); образцы информации о декодировании (602; 702) для каждого медиаблока доступа, где образец информации о декодировании указывает адрес начала и адрес конца связанного медиаблока доступа в пределах сохраненных пакетов транспортных данных (110; 112), где адрес начала обозначает местоположение образца медиаданных, указывающего начало медиаблока доступа, и где адрес конца обозначает местоположение образца медиаданных, указывающего конец медиаблока доступа; файл, сохраненный для каждого образца информации о декодировании (602; 702); связанная информация о времени декодирования образца (606; 706) в контейнере метаданных (106) файла; связанная информация о времени декодирования образца (606; 706), указывающая время декодирования и местоположение связанного образца информации о декодировании (602; 702) в контейнере медиаданных (104); характеризующееся тем, что включает:
процессор для определения графика вывода медиаблоков доступа сохраненных пакетов транспортных данных (110; 112) посредством доступа к связанной информации о времени декодирования образца (606; 706) в контейнере метаданных (106) и посредством доступа, основанного на связанной информации о времени декодирования образца (606; 706), образцах информации о декодировании (602; 702) в контейнере медиаданных (104), и посредством доступа, основанного на образцах информации о декодировании (602; 702), связанных медиаблоках доступа сохраненных пакетов транспортных данных (110; 112); и
контроллер вывода для вывода медиаблоков доступа в соответствии с определенным графиком вывода.

20. Способ чтения файла (702), хранящийся в контейнере медиаданных (104), связан с файлом, пакетами транспортных данных (110; 112), включающими медиаполезную информацию пакетированных медиаблоков доступа, и сохраняющимися в контейнере медиаданных (104); образцы информации о декодировании (602; 702) для каждого медиаблока доступа, где образец информации о декодировании указывает адрес начала и адрес конца связанного медиаблока доступа в пределах сохраненных пакетов транспортных данных (110; 112), где адрес начала обозначает местоположение образца медиаданных, указывающих начало медиаблока доступа, и где адрес конца обозначает местоположение образца медиаданных, указывающего конец медиаблока доступа; файл, сохраняющийся для каждого образца информации о декодировании (602; 702); связанная информация о времени декодирования образца (606; 706) в контейнере метаданных (106) файла; связанная информация о времени декодирования образца (606; 706), указывающая время декодирования и местоположение связанного образца информации о декодировании (602; 702) в контейнере медиаданных (104); характеризующийся тем, что включает:
определение графика вывода медиаблоков доступа сохраненных пакетов транспортных данных (110; 112) посредством доступа к информации о времени декодирования образца (602; 702) в контейнере метаданных (106) и посредством доступа, основанного на информации о времени декодирования образца (606; 706), образцах информации о декодировании (602; 702) в контейнере медиаданных (104), и посредством депакетирования, основанного на образцах информации о декодировании (602; 702), полезной нагрузке сохраненных пакетов транспортных данных (110; 112) для получения медиаблоков доступа; и
вывод медиаблоков доступа в соответствии с определенным графиком вывода.

21. Машиночитаемый носитель информации с сохраненной на нем компьютерной программой для реализации способа по п.20, когда компьютерная программа запущена на компьютере и/или микроконтроллере.