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

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

Info

Publication number
RU2492587C2
RU2492587C2 RU2009148647/07A RU2009148647A RU2492587C2 RU 2492587 C2 RU2492587 C2 RU 2492587C2 RU 2009148647/07 A RU2009148647/07 A RU 2009148647/07A RU 2009148647 A RU2009148647 A RU 2009148647A RU 2492587 C2 RU2492587 C2 RU 2492587C2
Authority
RU
Russia
Prior art keywords
packets
media
information
rtp
stored
Prior art date
Application number
RU2009148647/07A
Other languages
English (en)
Other versions
RU2009148647A (ru
Inventor
Стефан ДОЕХЛА
Стефан КРАЙГЕЛОХ
Николаус ФАЕРБЕР
Харальд ФУКС
Original Assignee
Фраунхофер-Гезелльшафт цур Фёрдерунг дер ангевандтен Форшунг Е.Ф.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Фраунхофер-Гезелльшафт цур Фёрдерунг дер ангевандтен Форшунг Е.Ф. filed Critical Фраунхофер-Гезелльшафт цур Фёрдерунг дер ангевандтен Форшунг Е.Ф.
Publication of RU2009148647A publication Critical patent/RU2009148647A/ru
Application granted granted Critical
Publication of RU2492587C2 publication Critical patent/RU2492587C2/ru

Links

Images

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2368—Multiplexing of audio and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2389—Multiplex stream processing, e.g. multiplex stream encrypting
    • H04N21/23895—Multiplex stream processing, e.g. multiplex stream encrypting involving multiplex stream encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43072—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of multiple content streams on the same device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4334—Recording operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4341—Demultiplexing of audio and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4381—Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H04N21/6334—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key
    • H04N21/63345—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key by transmitting keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/167—Systems rendering the television signal unintelligible and subsequently intelligible
    • H04N7/1675—Providing digital key or authorisation information for generation or regeneration of the scrambling sequence
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/0021—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier
    • G11B20/00485—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier characterised by a specific kind of data which is encrypted and recorded on and/or reproduced from the record carrier
    • G11B20/00492—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving encryption or decryption of contents recorded on or reproduced from a record carrier characterised by a specific kind of data which is encrypted and recorded on and/or reproduced from the record carrier wherein content or user data is encrypted
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/00086—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy
    • G11B20/00731—Circuits for prevention of unauthorised reproduction or copying, e.g. piracy involving a digital rights management system for enforcing a usage restriction

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Television Signal Processing For Recording (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Automatic Disk Changers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Abstract

Изобретение относится к хранению и/или чтению пакетов данных транспортных протоколов и дополнительной информации. Техническим результатом является эффективное хранение и обработка пакетов, например точная синхронизации озвучивания и расшифровки во время воспроизведения записанных медиа потоков. Предложено устройство (100) записи файла (102), имеющего связанные хранилище медиа данных (104) и хранилище метаданных (106), содержащее: приемник (108) для получения первых пакетов данных (110), включающий пакетизированные первые выборки медиа данных, основанные на первом тактовом генераторе, и для получения вторых пакетов данных (112), включающих вторые выборки медиа данных, основанные на втором тактовом генераторе, отличном от первого тактового генератора, где вторые выборки медиа данных связаны с первыми выборками медиа данных; и для получения первых пакетов управления (114), включающих информацию, указывающую на отношение первого тактового генератора к исходному тактовому генератору, и для получения вторых пакетов управления (115), включающих информацию, указывающую на отношение второго тактового генератора к исходному тактовому генератору; и записывающее устройство (116) для хранения полученных первых и вторых пакетов данных (110; 112) и, по крайней мере, части полученных первых и вторых пакетов управления (114; 115) в хранилище медиа данных (104) и для хранения связанных метаданных (124; 128) в хранилище метаданных (106). 6 н. и 15 з.п. ф-лы, 12 ил.

Description

Изобретение имеет отношение к хранению и/или чтению пакетов данных транспортных протоколов и дополнительной информации, связанной с ними, и/или файла, имеющего хранилище медиа данных и хранилище метаданных, например файл, основанный на ISO (Международная организация по Стандартизации) базовом медиа формате файла.
Различные электронные устройства используются для приема и воспроизведения потоков медиа данных. Такие потоки медиа данных могут быть получены, например, из цифровой видео широковещательной сети, которая передает медиа потоки, например, в соответствии со Стандартом DVB-H (Цифровое Мобильное Видео- и Телевещание) или Стандартом DVB-T (Цифровое Наземное ТВ-вещание).
Стандарт DVB-T использует модульный MPEG-2 (MPEG = Экспертная Группа по Кинематографии) транспортный поток, содержащий элементарные видео и аудио потоки MPEG-2 согласно международному стандартному ISO/IEC 13818 (IEC = Международная Электротехническая Комиссия). Транспортный поток MPEG-2, являющийся мультиплексным, используется во многих современных системах теле- и радиовещания. Это - мультиплексный поток одной или нескольких медиа программ, обычно аудио и видео, но также и других данных. Транспортные потоки MPEG-2 делят общий тактовый генератор и используют медиа выборки с временной меткой (Блоки Доступа, AUs) во всех медиа потоках. Это делает возможной синхронизацию передающих и принимающих тактовых генераторов и синхронное озвучивание аудио и видео потоков.
Для стандарта DVB-H элементарные аудио и видео потоки инкапсулированы в RTP (Транспортный Протокол в Реальном Времени), UDP (Пользовательский Дейтаграммный Протокол), IP (Интернет-Протокол), и МРЕ (Многопротокольная инкапсуляция) для IP преобразования типов данных. RTP используется для эффективной поставки мультимедийных данных по IP сетям в реальном времени. Мультиплексирование обычно осуществляется привязыванием различных сетевых портов к каждому конкретному медиа потоку, например, один сетевой порт для видео и другой для аудио. Различные медиа данные обычно происходят от различных источников, имеющих различные тактовые генераторы или тактовые частоты. Например, аудио выборки имеют норму отбора, зависящую от тактовой частоты устройства дискретизации аудиоматериала, в котором частота кадров видео структур зависит от тактовой частоты видео структуры захватного устройства. Такие тактовые генераторы могут иметь свойственные погрешности частоты, больше чем несколько сотен частей на миллион, что приводит к накоплению погрешностей в количестве десятков секунд в день. Термин «расфазировка синхронизирующих импульсов» определяется как отличие фактической частоты генератора тактовых импульсов от его номинальной частоты. Если передающий тактовый генератор работает быстрее, чем принимающий тактовый генератор, это может привести к накоплению пакетов в приемнике. Если передающий тактовый генератор работает медленнее, чем принимающий тактовый генератор, это приведет к неполной загруженности буферов приемника. Таким образом, если тактовая частота приемника отличается от тактовой частоты отправителя, то буфер(ы) приемника будет постепенно заполняться или будет пустым. Далее, расфазировка синхронизирующих импульсов может привести к десинхронизации между связанными аудио и видео выборками в приемнике.
RTCP (Транспортный Протокол Управления Передачей в Реальном Времени) позволяет обеспечить восстановление и синхронизацию тактового генератора для потоков RTP. Канал RTCP связан с каждым потоком RTP и включает управляющую информацию от отправителя на приемник в форме сообщений отправителя (SR) и наоборот. Каждое RTCP сообщение отправителя включает две временные метки: NTP (Протокол Сетевого Времени) временная метка системы тактового генератора отправителя (опорная метка времени) и соответствующая медиа временная метка связанного потока RTP. Эти RTCP сообщения отправителя посылаются и для аудио и для видео. Из величин времени RTP и NTP пакеты RTP могут быть размещены на временной линии, и медиа могут быть отлично синхронизированы.
Потоковое обслуживание определяется как ряд синхронизированных медиа потоков, поставленных способом, ограниченном во времени или неограниченном, для непосредственного потребления во время приема. Каждый потоковый сеанс может включать аудио, видео и/или медиа данные в реальном времени, такие как синхронизированный текст. Пользовательские медиа данные, получаемые для кино посредством мобильного телевидения, например, могут просматривать кино и/или записывать его в файл. Обычно, с этой целью полученные пакеты данных полученного медиа потока депакетируются, чтобы хранить необработанные медиа данные в файле. Таким образом, полученные пакеты RTP или пакеты MPEG-2 должны сначала депакетироваться, чтобы получить свою полезную информацию в форме выборки медиа данных. Затем, после депакетирования полученные выборки медиа данных воспроизводятся или хранятся в файле. Полученные медиа выборки обычно сжимаются форматами подобными H.264/AVC (AVC = Расширенное Видео Кодирование) видео формату и/или MPEG-4 EH-AACV2 (EH-AACV2 = Высокоэффективное Расширенное Аудио Кодирование - версия 2) аудио формату. Когда выборки медиа данных, имеющие такие видео и/или аудио форматы, должны храниться, они могут быть сохранены в так называемом 3GP формате файла, также известном как 3GPP (Партнерский Проект 3-его Поколения) формат файла, или в МР4 (MPEG-4) формате файла. И 3GP и МР4 получены из ISO базового медиа формата файла, который определен в ISO/IEC международном стандарте 14496-12:2005 «Техника кодирования информации аудиовизуальных объектов - часть 12: ISO базовый медиа формат файла». Файл этого формата включает медиа данные и метаданные. Чтобы такой файл работал, должны присутствовать и те и другие данные. Медиа данные хранятся в хранилище медиа данных (mdat), связанном с файлом, а метаданные хранятся в хранилище метаданных (moov) файла. Традиционно, хранилище медиа данных включает фактические медиа выборки. То есть, он может включать, например, перемежающиеся, упорядоченные по времени видео и/или аудио структуры. Таким образом, каждое из медиа данных имеет свою собственную дорожку метаданных (trak) в хранилище метаданных moov, которая описывает свойства медиа информационного наполнения. Дополнительные хранилища (также называемые блоками) в хранилище метаданных moov могут включать информацию о свойствах файла, содержании файла, и т.д.
Недавно, так называемые хинтинговые (хинтовые) дорожки приема для файлов, основанные на ISO базовом медиа формате файла, были определены международными группами стандартизации. Эти хинтинговые дорожки приема могут использоваться для хранения мультиплексных и/или пакетизированных потоков, таких как, например, полученный транспортный поток MPEG-2 или пакеты RTP. Хинтинговые дорожки приема могут использоваться для хранения со стороны клиента и воспроизведения полученных пакетов данных. Таким образом, полученные MPEG-2 TS или RTP пакеты одного потока непосредственно хранятся на хинтинговых дорожках приема, таких как, например, заранее вычисленные выборки или конструкторы.
У этого подхода есть два преимущества по сравнению с демультиплексированием и/или депакетированием пакетов данных и последующим записыванием отдельных медиа дорожек для каждого элементарного медиа потока (аудио и/или видео). Во-первых, он снижает требуемую сложность приемного устройства во время хранения, потому что не требуется никакого демультиплексирования или другой обработки полученных пакетов данных. Выполняется только хранение файла полученных пакетов данных в неизмененной форме. Во-вторых, в некоторых случаях невозможно уплотнить полученные пакеты данных, чтобы отделить медиа дорожки, особенно, если медиа данные зашифрованы на транспортном/мультиплексном уровне, или схема пакетирования неизвестна. В-третьих, облегчается сдвиг по времени, то есть запись в файл и немедленное считывание этого же самого файла с переменным смещением времени, в PVR (PVR = Персональный Видеомагнитофон), благодаря первым двум пунктам.
Воспроизведение с хинтинговых дорожек приема может быть выполнено путем эмуляции нормального приема потока и считывания сохраненных пакетов данных с хинтинговых дорожек приема, поскольку они были получены по IP. Хинтинговые дорожки приема, как и все хинтинговые дорожки, имеют хронометраж пересылки, в отличие от медиа дорожек, имеющих медиа хронометраж воспроизведения. Поэтому, временная метка приема приемного устройства связана с каждым пакетом данных, хранящимся на хинтинговой дорожке приема.
RTP хинтинговые дорожки в серверных файлах сохраняют только RTP пакеты медиа данных из одного потока и не содержат соответствующую дополнительную - или управляющую информацию, такую как, например, информация RTCP или ключевые сообщения. Информация RTCP производится на ходу потоковым сервером, потому что она описывает текущее состояние потоковой ситуации, например, хронометраж.
Потоковые приемники могут восстанавливать системный тактовый генератор отправителя из времени приема сообщения и выравнивать системный тактовый генератор приемника с системным тактовым генератором отправителя, чтобы избежать буферного переполнения соответственно недогрузки для прямого воспроизведения. В результате дрожания в момент поступления (дрожание сети) пакетов RTP или пакетов сообщений отправителя RTCP, в зависимости от того, которые из них используются для восстановления тактового генератора, мгновенное восстановление тактового генератора не возможно. Независимые аудио и видео единицы захвата с несинхронизированной дискретизацией тактовых генераторов могут привести к отклонению тактовых генераторов RTP, хотя медиа временные метки постоянно увеличиваются с фиксированной скоростью. RTCP сообщения отправителя несут NTP и RTP временные метки для каждого потока, и поэтому могут использоваться, чтобы ликвидировать отклонения привлеченных устройств. Во многих системах происходит дрожание при создании сообщений отправителя RTCP, в частности во взаимоотношениях между тактовыми генераторами RTP и NTP. Поэтому часто встречается ситуация, когда потоковые клиенты не достигают полной синхронизации озвучивания сразу после запуска, но должны принять во внимание определенное число сообщений отправителя RTCP прежде, чем будет получена точная синхронизация озвучивания между видео и аудио потоками. Если системный тактовый генератор отправителя должен быть восстановлен и имеется высокая степень колебания сети, то бывает также необходимо определенное число пакетов RTP или пакетов сообщений отправителя RTCP, в зависимости от того, которые из них используется для восстановления тактового генератора. Колебание сети и отклонение тактового генератора могут быть повторно вычислены во время приема потока в реальном времени, используя информацию многократных сообщений отправителя RTCP, как описано выше, в дополнение к RTP временным меткам, связанных пакетов данных.
В настоящее время хинтинговые дорожки приема RTP определены только для хранения полученных пакетов данных медиа потока и не содержат соответствующих сообщений отправителя RTCP, соответственно информации о хронометраже из сообщений отправителя. RTP временная метка одного только полученного пакета RTP недостаточна для того, чтобы синхронизировать медиа данные, полученные из различных потоков. Это происходит потому, что обычно каждый медиа поток присваивает случайные значения его начальной временной метке и начальный порядковый номер, и частота тактового генератора временной метки зависит от формата приведенных медиа данных. Время поступления или приема пакетов RTP может использоваться, чтобы синхронизировать потоки. Проблема этого подхода, однако, состоит в том, что RTP не гарантирует доставку пакета, и не предотвращает доставку вне диапазона. В результате синхронизация, основанная на одном только времени прихода сообщения, не может гарантировать точность.
Как описано выше, самый точный метод синхронизации между различными потоками RTP требует ожидания связанных сообщений отправителя RTCP, которые содержат информацию, позволяющую осуществлять преобразование между RTP временной меткой и общей временной меткой потоков в формате временной метки NTP. Эти сообщения отправителя RTCP обычно посылаются каждые пять секунд для каждого потока для определенной скорости передачи битов, где временной интервал между двумя сообщениями отправителя RTCP зависит от скорости передачи битов.
Следовательно, воспроизведение хинтинговых дорожек приема RTP с точным хронометражем и синхронизацией озвучивания возможно только в следующих двух случаях: Во-первых, если нет никакого отклонения тактового генератора между различными медиа тактовыми генераторами, и данные синхронизации межпотока в сообщении отправителя RTCP доступны для каждого полученного пакета RTP. Это, однако, соответствует идеальной ситуации, которая вряд ли произойдет в реальном окружении. Во-вторых, приемное устройство должно принимать во внимание информацию о хронометраже сообщений отправителя RTCP во время хранения, регулируя RTP временные метки полученных пакетов RTP прежде, чем сохранить их.
Первый случай - это только теоретический случай и не встречается на практике. Второй случай создает высокую нагрузку на приемнике, как например, буферизация полученных потоков на нескольких секунд была бы необходима, чтобы принять во внимание несколько сообщений отправителей RTCP для регулирования хронометража. Это также повлияло бы на возможность мгновенного считывания с того же самого файла для использования временной манипуляции. Кроме того, исходная ситуация приема не может быть обновлена после хранения, то есть долгосрочное дрожание не может быть ликвидировано на стадии обработки после получения и записи полного потока.
Современные системы теле- радиовещания используют ключевые потоки (в диапазоне или вне диапазона) для транспортировки защищенных ключей, таких как дополнительная информация, которые используются для расшифровки медиа данных, связанных пакетов данных. Обычно имеется только слабая связь между ключевым потоком и зашифрованным потоком медиа данных, а не хронометражная связь.
В стандарте DVB-H и OMA-BCAST (Открытый Мобильный Альянс - Мобильные Услуги Теле- Радиовещания) ключевой поток определен как отдельный поток ключевых сообщений, посланных на порт UDP, отличный от того, на который послан связанный медиа поток. Каждое ключевое сообщение посылается как единый пакет UDP. OMA-BCAST называет эти сообщения краткосрочными ключевыми сообщениями (STKM), DVB-H называет их ключевыми потоковыми сообщениями (KSM). Хранение ключевых сообщений не вредит безопасности потоковой системы, потому что каждое ключевое сообщение связано с подписанием потокового обслуживания, и поэтому доступ к нему могут иметь только уполномоченные подписчики/устройства. Фактический шифровальный ключ в ключевом сообщении защищен программным или обслуживающим ключом.
Каждый ключ имеет связанный ключевой индикатор (ключ идентификатор - ID), который также указан в связанном зашифрованном медиа блоке доступа. Расшифровщик проверяет на существование ключа, связанного с ключом ID в зашифрованном блоке доступа.
Синхронизация зашифрованных медиа блоков доступа и связанных ключевых сообщений регулируется частой отправкой ключей с перекрывающимися периодами достоверности. Ключ посылается до зашифрованного видео пакета, отмеченного соответствующим ключевым индикатором. Тогда ключ остается достоверным до тех пор, по крайней мере, пока медиа данные используют конкретно этот ключ.
Сохранение ключей как медиа дорожки во время записи файла не реально, так как никакой медиа хронометраж не связан с ключевыми сообщениями в потоке. Медиа хронометражная связь между ключами и соответствующими зашифрованными блоками доступа может быть получена только после обработки и анализа ключей ID, которые обеспечивают связь и ключа и медиа потоков. Только после этого анализа становится ясно, какой ключ используется для какого блока доступа или видео структуры.
Следовательно, цель данного изобретения - обеспечить концепцию эффективного хранения и обработки полученных пакетов и связанной дополнительной информации в файле, так, например, точная синхронизации озвучивания и расшифровки во время воспроизведения записанных медиа потоков возможна без значительного усложнения во время процесса записи или хранения.
Эта цель достигается при помощи устройства для записи файла, способа записи файла и устройства для чтения файла и способа чтения файла.
Для достижения вышеупомянутой цели осуществления данного изобретения также предлагают компьютерные программы для реализации способов изобретения.
Данное изобретение основано на том, что вышеупомянутые проблемы могут быть решены в то же самое время, не только при помощи сохраненных полученных потоковых пакетов медиа данных, но также и при помощи связанных данных во время приема передаваемой дополнительной информации, в особенности всех связанных данных, которые доставляются параллельно медиа потокам, как например, сообщения RTCP, включая сообщения отправителя RTCP, или посредством записи связанных полученных ключевых сообщений, включающих шифровальные ключи, связанные с медиа данными, составленными полученными потоковыми пакетами медиа данных.
Эти полученные связанные данные или дополнительная информация сохраняется в файле, включающем хранилище медиа данных и хранилище метаданных в форме так называемой связанной хинтинговой дорожки приема ("arht"). Эта дорожка связана с соответствующей хинтинговой дорожкой приема, которая содержит связанные медиа пакеты, использующие, например, механизм исходной дорожки ISO/IEC 14496-12. Как и связанная хинтинговая дорожка приема, связанная хинтинговая дорожка приема также хранит хронометраж пересылки в форме, например, временных меток системного тактового генератора приемника. Это может позволить восстановление условий хронометража приема исходного пакета на более поздней стадии во время воспроизведения.
Хинтинговые дорожки приема и связанные хинтинговые дорожки приема включают части данных пакета в хранилище медиа данных и части метаданных в хранилище метаданных файла.
Согласно осуществлениям данного изобретения, сообщения, такие как сообщения отправителя RTCP и связанная транспортная хронометражная информация сохраняется во время записи связанной рекомендованной дорожки приема. Параллельно, полученные медиа пакеты RTP и связанный хронометраж пересылки хранятся непосредственно на хинтинговой дорожке приема. Во время записи не выполняется ни процесс устранения дрожания, ни синхронизация озвучивания.
С этой целью осуществление данного изобретения обеспечивает устройство для записи файла, имеющего хранилище связанных медиа данных и хранилище метаданных. Устройство включает приемник для приема первых пакетов данных, включающих пакетизированные первые выборки медиа данных, основанные на первом тактовом генераторе, и для приема вторых пакетов данных, включающих вторые выборки медиа данных, основанные на втором тактовом генераторе, отличном от первого тактового генератора, где вторые выборки медиа данных связаны с первыми выборками медиа данных. Приемник далее приспособлен для приема первых пакетов управления, включающих информацию, указывающую на взаимоотношение первого тактового генератора с исходным тактовым генератором, и для приема вторых пакетов управления, включающих информацию, указывающую на взаимоотношение второго тактового генератора с исходным тактовым генератором. Устройство также включает записывающее устройство для хранения полученных первых и вторых пакетов данных, и, по крайней мере, части полученных первых и вторых пакетов управления в хранилище медиа данных, и для хранения связанных метаданных в хранилище метаданных; связанные метаданные, включающие информацию о хронометраже полученных первых и вторых пакетов данных, и полученные первые и вторые пакеты управления и включающие информацию о местоположении, указывающую местоположение сохраненных первых и вторых пакетов данных и сохраненных первых и вторых пакетов управления в хранилище медиа данных.
Согласно осуществлению данного изобретения, записывающее устройство приспособлено для хранения первых и вторых полученные пакетов данных как выборок на первых участках памяти хранилище медиа данных, и для хранения, по крайней мере, части полученных связанных первых и вторых пакетов управления как выборок на вторых участках памяти хранилище медиа данных.
Согласно осуществлению данного изобретения записывающее устройство приспособлено для хранения информации о хронометраже и информации о местоположении первых и вторых пакетов данных на первой дорожке хранилища метаданных, и для хранения информации о хронометраже и информации о местоположении первых и вторых пакетов управления на второй дорожке хранилища метаданных файла.
Согласно осуществлению данного изобретения файл основан на ISO базовом медиа формате файла. Согласно предпочтительному осуществлению данного изобретения файл является 3GР- или МР4-файлом.
Согласно осуществлению данного изобретения первыми пакетами данных являются первые потоковые пакеты RTP, включающие пакетизированные первые медиа выборки (например, сжатое видеоизображение), а первыми пакетами управления являются пакеты RTCP, связанные с первыми потоковыми пакетами RTP, включающими первые сообщения отправителя RTCP. Вторые пакеты данных являются вторыми потоковыми пакетами RTP, включающими пакетизированные вторые выборки медиа данных (например, сжатые аудиоданные, связанные с видеоданными) и вторыми пакетами управления являются пакеты RTCP, связанные со вторыми потоковыми пакетами RTP, включающими вторые сообщения отправителя RTCP.
Параллельное хранение первых и вторых пакетов данных и связанных пакетов управления имеет то преимущество, что процесс записи все еще является облегченным и может захватывать всю информацию, необходимую для воспроизведения медиа потоков из записанного файла на более поздней стадии. Связанные хинтинговые дорожки приема, то есть сохраненные пакеты управления в хранилище медиа данных и связанная мета информация в хранилище метаданных, используется во время воспроизведения хинтинговых дорожек приема, то есть сохраненных первых и/или вторых пакетов данных в хранилище медиа данных и связанной мета информации, сохраненной в хранилище метаданных файла.
С целью воспроизведения записанного файла осуществления данного изобретения предлагают устройство для чтения файла; файл, сохраненный в хранилище медиа данных, связанном с файлом; первые пакеты данных, включающие пакетизированные первые выборки медиа данных, основанные на первом тактовом генераторе, и вторые пакеты данных, включающие пакетизированные вторые выборки медиа данных, основанные на втором тактовом генераторе, отличном от первого тактового генератора. Файл также сохраняет, по крайней мере, части связанных первых пакетов управления, включающих информацию, указывающую на взаимоотношения первого тактового генератора и исходного тактового генератора и, по крайней мере, части связанных вторых пакетов управления, включающих информацию, указывающую на взаимоотношения второго тактового генератора и исходного тактового генератора. Файл сохраняет связанные метаданные в хранилище метаданных файла; связанный хранилище метаданных, включающий информацию о хронометраже принятых первых и вторых пакетов данных и принятых первых и вторых пакетов управления; и информацию о местоположении, указывающую местоположение сохраненных первых и вторых пакетов данных и местоположение сохраненных первых и вторых пакетов управления в хранилище медиа данных. Устройство для чтения файла включает процессор для определения графика вывода сохраненных первых и вторых пакетов данных посредством получения доступа к хранилищу метаданных и посредством интерпретации информации о хронометраже сохраненных первых и вторых пакетов данных и сохраненных первых и вторых пакетов управления в хранилище медиа данных. Устройство далее включает выходной контроллер для вывода первых и вторых пакетов данных в соответствии с определенным графиком вывода, посредством получения доступа к хранилищу медиа данных и посредством чтения пакетов данных хранилище медиа данных.
В соответствии с осуществлениями данного изобретения, сохраненные первые и вторые пакеты данных и связанные сохраненные первые и вторые пакеты управления могут быть обработаны на ходу для синхронизации озвучивания, восстановления тактового генератора и/или регулировки отклонения тактового генератора. Этот вид воспроизведения эквивалентен моделируемому прямому приему записанных медиа потоков.
Записанные хинтинговые дорожки приема (первые/вторые пакеты данных) и записанные связанные хинтинговые дорожки приема (первые/вторые пакеты управления) охватывают всю запись. Во время воспроизведения или повторного воспроизведения управляющие данные связанной хинтинговой дорожки приема, например, в форме сообщений отправителя RTCP, могут быть предварительно выбраны, например, для точной синхронизации озвучивания, учитывая многократные будущие сообщения отправителя RTCP, где будущие сообщения отправителя RTCP связаны с будущими временными моментами текущего момента времени воспроизведения.
Преимущество данного изобретения состоит в том, что понятие связанных хинтинговых дорожек приема, то есть запись управляющей информации во время приема медиа потоков, обеспечивает легкий процесс записи всей информации, важной для синхронизированного воспроизведения потоков из файла просто без дополнительных сложностей.
В случае, если записанный файл предназначен для длительного хранения и будет, в конечном счете, воспроизведен много раз, может быть желательно избежать анализирования сохраненных первых/вторых пакетов данных и сохраненных первых/вторых пакетов управления вместе со связанными метаданными, соответственно, во время каждого воспроизведения и, вместо него, для получения медиа хронометража, то есть хронометража для повторного воспроизведения первых/вторых образцов медиа данных, составленных из первых/вторых сохраненных пакетов данных, непосредственно доступных без дальнейшей обработки.
Обычно, это подразумевало бы депакетирование сохраненных пакетов данных из хинтинговой дорожки приема и сохранение их на медиа дорожках в связанных хранилищах медиа данных с одним элементарным потоком на одну дорожку. Это не всегда возможно или желательно, например, если проводилось транспортное шифрование потоковых пакетов или, если емкость запоминающего устройства ограничена.
В дополнение к точному хронометражу транспортных пакетов желательно расширить доступную информацию о хинтинговых дорожках приема (сохраненные первые/вторые пакеты данных плюс мета информация), особенно информацию относительно образцов медиа данных в первых/вторых пакетах данных, например, покадровые SMPTE временные метки (SMPTE = Общество Инженеров Кино, Видео и Телевидения) или подзаголовки для видеодорожки.
С этой целью осуществления данного изобретения также обеспечивают устройство для обработки пакетов данных, связанных с протоколом пересылки, сохраненным в хранилище медиа данных, связанном с файлом, и для обработки сохраненной, связанной мета информации в хранилище метаданных файла; связанная мета информация, включающая информацию о хронометраже пересылки и информацию о местоположении, указывающую местоположение сохраненных пакетов данных в медиа хранилище. Устройство включает процессор для определения, основанный на сохраненных пакетах данных и сохраненной связанной мета информации, информации о декодировании для полезной информации сохраненных пакетов данных, где информация о декодировании указывает, в какой момент времени повторно воспроизводить какую полезную информацию сохраненных пакетов данных. Устройство для обработки может быть автономным устройством, а так же устройством, интегрированным в вышеупомянутое устройство для хранения файла.
Согласно осуществлению сохраненные пакеты данных могут включать транспортные потоковые пакеты MPEG-2. Согласно другому осуществлению сохраненные пакеты данных могут включать пакеты RTP, включающие пакетизированные медиа данные.
Согласно осуществлениям данного изобретения информация о декодировании определяется на основе медиа блока доступа. То есть, для каждого блока доступа, например, медиа структуры, образец информации о декодировании хранится в хранилище медиа данных файла, где образец информации о декодировании указывает, из каких частей сохраненных пакетов данных следует взять какие выборки медиа данных, чтобы получить медиа структуры (например, видео/аудио). Мета информация, связанная с образцами информации о декодировании, хранится на дорожке метаданных информации о декодировании в хранилище метаданных. Дорожка метаданных информации о декодировании ("trak" блок/атом ISO базового медиа формата файла), таким образом, включает хронометраж и информацию о местоположении для образцов информации о декодировании.
Сохраненные выборки информации о декодировании и связанная с ними дорожка метаданных информации о декодировании, также называемая «виртуальной медиа дорожкой» в дальнейшем, строится на идее связанных хинтинговых дорожек приема и предлагает вышеописанные преимущества для воспроизведения. В части метаданных виртуальной медиа дорожки предоставлен медиа хронометраж для связанных образцов информации о декодировании в хранилище медиа данных. Выборки информации о декодировании предоставляют информацию, из которой сохраненные пакеты данных или транспортные блоки получают медиа данные для связанного медиа блока доступа, который делает ненужным депакетирование медиа пакетов. Виртуальные медиа дорожки могут быть созданы после заключительного приема медиа потоков, при использовании информации из хинтинговых дорожек приема и, в случае необходимости, связанных хинтинговых дорожек приема. Это осуществляется в «процессе обратной модификации», и получающийся файл позволяет устройству воспроизведения осуществлять поиск в файле и выполнять произвольный доступ к медиа, основанным на медиа хронометраже.
Виртуальные медиа дорожки могут наблюдаться в виде неполных медиа дорожек. Поэтому, может применяться и восстановленный хронометраж из RTP и хинтинговые дорожки приема RTCP и все индексы (обычно при использовании «таблиц выборок») медиа дорожек. Дополнительно, хронометрированные дорожки метаданных могут ссылаться на виртуальные медиа дорожки и расширять их.
Виртуальные медиа дорожки могут быть созданы из образцов информации о декодировании (виртуальные медиа выборки), которые могут содержать конструкторы для реконструкции блоков доступа из транспортных блоков хинтинговых дорожек приема. Далее, выборки информации о декодировании могут содержать ссылки на один или несколько существенных блоков пересылки, важных для реконструкции блока доступа (неполный конструктор). Кроме того, выборки информации о декодировании или виртуальные медиа выборки виртуальной медиа дорожки могут быть пустыми, например, в случае потери пакета во время процесса приема. Альтернативно, выборки информации о декодировании виртуальной дорожки, на которые в дальнейшем также ссылаются как на виртуальные медиа выборки, могут содержать полностью распакованные медиа выборки, как в случае классической медиа дорожки.
Информация из индексов в таблицах выборок виртуальной медиа дорожки (и любая связанная информация из, например, хронометрированных дорожек метаданных) может быть логически применена к исходной хинтинговой дорожке приема со ссылкой на соответствующий блок пересылки хинтинговой дорожки приема.
Виртуальные медиа дорожки могут содержать приблизительные и неполные описания виртуальных медиа выборок, если описания не могут быть точно восстановлены из потока. Это, в частности, применяется, когда пакеты данных зашифрованы, или схема депакетирования не полностью известна.
Для повторного воспроизведения виртуальных медиа дорожек осуществления данного изобретения предусматривают устройство для чтения файла; файл, хранящийся в хранилище медиа данных, связан с файлом, пакетами данных, включающими полезную информацию, и хранящаяся в хранилище медиа данных информация о декодировании для полезной информации сохраненных пакетов данных, где информация о декодировании указывает, в какой момент времени повторно воспроизводить какую полезную информацию сохраненных пакетов данных; файл, хранящий связанные метаданные в хранилище медиа данных; связанные метаданные, указывающие время декодирования и местоположение информации о декодировании в хранилище медиа данных. Устройство включает процессор для определения графика вывода полезной информации сохраненных пакетов данных посредством организации доступа к связанным метаданным в хранилище медиа данных и посредством организации доступа, основанного на метаданных, информации о декодировании в хранилище медиа данных, и посредством организации доступа, основанного на информации о декодировании полезной информации сохраненных пакетов данных. Контроллер вывода служит для вывода полезной информации в соответствии с определенным графиком вывода.
В отличие от выполняемого на ходу преобразования полученных пакетов данных в медиа дорожки во время записи, виртуальные медиа дорожки обеспечивают медиа хронометраж и метаданные без необходимости депакетирования медиа данных (сохраненные пакеты данных) и, таким образом, могут сэкономить область памяти. Они позволяют устройству воспроизведения осуществлять поиск в файле, основанном на медиа хронометраже. Виртуальные медиа дорожки объединяют преимущества медиа дорожек и хинтинговых дорожек приема, не удваивая размер файла, что имело бы место, если бы классические медиа дорожки были добавлены к файлу. Исходя из понятия виртуальных медиа дорожек, вся информация исходного процесса приема сохраняется; например, информация о потерянных пакетах, которая помогает маскировать ошибки, и информация о хронометраже приема, которая помогает синхронизировать озвучивание. В то же самое время изобретенные виртуальные медиа дорожки предлагают все возможности обычных медиа дорожек для медиа доступа. Предлагается даже большая гибкость по сравнению с обычными медиа дорожками. На основании последовательной выборки можно решить, полностью ли распакованы сохраненные транспортные блоки (пакеты данных) до блоков доступа (медиа структур) или сохранены только конструкторы или связи для реконструкции блоков доступа, например, чтобы сэкономить область памяти. Далее, все возможности могут быть соединены в одной виртуальной медиа дорожке, то есть выборки информации о декодировании или виртуальные медиа выборки, включающие полные блоки доступа, конструкторы, ссылки, или являющиеся пустым.
Множественные виртуальные медиа дорожки могут ссылаться на блоки пересылки или пакеты данных из той же самой хинтинговой дорожки приема, дающей возможность использовать различные индексы того же самого записанного потока пакета данных. Например, две виртуальные медиа дорожки с произвольным доступом, одна связана с аудио, другая с видео, точечные индексы для аудио и видео того же самого транспортного потока MPEG-2 хинтинговой дорожки приема.
Чтобы обеспечить воспроизведение или повторное воспроизведение зашифрованных выборок медиа данных в полученных и сохраненных пакетах данных, связанные ключевые потоковые сообщения могут также сохраняться - отдельно от пакетов данных - в хранилище медиа данных файла. Ключевые потоковые сообщения хранятся в образцах ключевых потоковых хинтинговых дорожек приема, согласно осуществлениям данного изобретения. Время приема (время пересылки) может использоваться как временная метка ключевых выборок потока для выравнивания ключевых сообщений и зашифрованных медиа пакетов на соответствующей хинтинговой дорожке приема. Ссылка на дорожку используется для соединения ключевого потока хинтинговой дорожки приема и медиа хинтинговой дорожки приема.
Для записи файла осуществления данного изобретения предусматривают устройство для записи файла, имеющего связанные хранилище медиа данных и хранилище метаданных. Устройство включает приемник для приема пакетов данных, каждый из которых включает полезную информацию, и для приема пакетов ключевых потоков, включающих множество шифровальных ключей, где каждый шифровальный ключ связан с полезной информацией пакетов данных. Устройство включает записывающее устройство для хранения полученных пакетов данных, и полученные пакеты ключевых потоков в хранилище медиа данных, и для хранения связанных метаданных в хранилище метаданных; связанные метаданные, включающие информацию о хронометраже пересылки полученных пакетов данных и полученных пакетов ключевых потоков и информацию о местоположении, указывающую местоположение сохраненных пакетов данных и сохраненных пакетов ключевых потоков в хранилище медиа данных. Устройство для записи пакетов данных и пакетов ключевых потоков может быть автономным устройством, а так же устройством, интегрированным в или объединенным с вышеупомянутым устройством для хранения и/или обработки.
Согласно осуществлениям данного изобретения, записывающее устройство приспособлено для хранения полученных пакетов данных как образцов на первых участках памяти хранилище медиа данных и для хранения полученных связанных пакетов ключевых потоков как образцов на вторых участках памяти хранилище медиа данных. Согласно осуществлениям данного изобретения, записывающее устройство приспособлено для хранения информации о хронометраже пересылки и информации о местоположении пакетов данных на первой дорожке хранилище медиа данных и для хранения информации о хронометраже пересылки и информации о местоположении пакетов ключевых потоков на второй дорожке хранилище метаданных.
Согласно осуществлению данного изобретения файл основан на 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 и опорный блок обработчика «hdlr» 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+l)=RT(n)+stts(n), где RT(n) обозначает время приема для пакета n и stts (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 изменяется, чтобы показывать число выборок в существующем участке памяти. Если выборка записывается в новый участок памяти, новый элемент добавляется к блоку stco (или со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 (ConfigurationRecord - запись конфигурации) в блоке 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 каждый включает заголовок HI, Н2, НЗ и полезную информацию PL1, PL2, PL3, включающую выборки медиа данных. Типичный размер заголовка - А биты, соответственно, размер полезной информации - (В-А) биты. Данные первой медиа структуры, которая может быть видео или аудио структурой, разделены между полезной информацией первого RTP пакета RTP1 и второго RTP пакета RTP2. Обычно, медиа данные первой медиа структуры идут от байта A RTP пакета RTP1 к байту A+Y пакета данных RTP2. Медиа данные второй медиа структуры разделены между пакетом данных RTP2, начинающемся в байтовом адресе A+Y, и пакетом данных RTP3, заканчивающемся в байтовом адресе A+Z пакета данных RTP3.
Виртуальные медиа выборки VMS 1 и 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Т включает пакеты данных A1-А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 и размеров Кi всех предыдущих Pi выборок внутри участка памяти.
Тогда данные становятся доступными в положении (F+sum (Кi)) в файле и имеют размер L.
Время, когда данные должны быть воспроизведены до конца, определяется информацией, доступной в блоке stts. Этот блок содержит неравномерно закодированные длины Dj для каждой индивидуальной выборки j. Время воспроизведения для k-ой выборки S тогда является суммой всех Dj длин, при j<k.
В случае, если имеется виртуальная медиа дорожка, осуществления данного изобретения обеспечивают устройство для чтения файла; файл, сохраненный в хранилище медиа данных; пакеты данных, включающие полезную информацию, и сохраненные в хранилище медиа данных 104; информацию о декодировании для полезной информации сохраненных пакетов данных, где информация о декодировании указывает, в какой момент времени повторно воспроизводить какую полезную информацию сохраненных пакетов данных. Файл сохраняет связанные метаданные в хранилище метаданных 106; связанные метаданные, указывающие время декодирования и местоположение информации о декодировании в хранилище медиа данных. Устройство, согласно осуществлению данного изобретения, включает процессор для определения графика вывода полезной информации сохраненных пакетов данных посредством доступа к связанным метаданным в хранилище метаданных 106, и посредством доступа к основанной на метаданных информации о декодировании в хранилище медиа данных, и посредством доступа к основанной на информации о декодировании полезной информации для сохраненных пакетов данных; и контроллер вывода полезной информации в соответствии с определенным графиком вывода.
Как упомянуто во вводной части описания, другой аспект данного изобретения заключается в сохранении, в дополнение к полученным пакетам данных, сообщений ключевого потока.
Право доступа к данным или пакетам данных может контролироваться через систему управления правами. Получение содержания данных через цифровую систему коммуникаций может быть разрешено определенным конечным пользователям и ограничено для других пользователей. Например, пользователь может купить доступ к программе, заплатив за нее. Если пользователь вносит плату, ему может быть предоставлен доступ к программе на указанный промежуток времени, в то время как пользователь, который не внес плату, может не получить доступ к программе. Доступ к программе может быть отрегулирован шифрованием переданных данных. Данные могут быть зашифрованы любым числом стандартов шифрования с помощью шифровального ключа. В приемнике или пользовательском терминале ключ может использоваться, чтобы расшифровать зашифрованные данные таким образом, что содержание может быть видимым в пользовательском терминале или приемнике. Ключ для расшифровки (декодирования) зашифрованных пакетов данных может быть также получен через ту же самую цифровую систему коммуникаций и также может быть зашифрован. Для получения одного или более ключей также могут использоваться другие цифровые системы коммуникаций. Таким образом, конечный пользователь, желающий получить доступ или просмотреть программу или сервис, должен получить права на ключи.
Транспортные шифровальные ключи, связанные с зашифрованной программой или сервисом, могут быть переданы в ключевом потоке на пользовательский терминал. Ключевой поток может включать сообщения ключевого потока, которые передаются с предопределенной частотой, когда зашифрованный поток данных получен в приемнике или пользовательском терминале, сообщения ключевого потока также могут быть получены.
Фиг.12 показывает потоковые пакеты данных 1302-1, 1302-2, 1302-3, каждый из которых имеет полезную информацию, зашифрованную с шифровальными ключами k0, k1, k2. Имеется ключевой поток, включающий пакеты ключевого потока 1304-1, 1304-2, 1304-3 и 1304-4 и связанный с пакетами данных 1302. Пакет ключевого потока 1304-1, который передается прежде, чем связанный с ним пакет данных 1302-1, включает ключ к шифру ко для декодирования зашифрованной полезной информации пакета данных 1302-1. Таким образом, у шифровального ключа k0 имеется срок службы d0, связанный с ним, гарантирующий то, что связанные пакеты данных могут быть зашифрованы. То же самое справедливо для второго пакета ключевого потока 1304-2 и его шифровального ключа k1, который может использоваться для расшифровки полезной информации связанного пакета данных 1302-2. Также здесь связанный пакет ключевого потока 1304-2 передается значительно раньше пакета данных 1302-2, и у шифровального ключа k1 имеется срок службы d1, гарантирующий правильное декодирование полезной информации пакета данных 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. Следует упомянуть, что осуществления данного изобретения могут также быть применены к упомянутым фрагментам кинофильма.
В зависимости от обстоятельств методы изобретения могут быть реализованы в устройствоных средствах или в программном обеспечении. Реализация может быть осуществлена на цифровом носителе данных, в частности, на диске или компакт-диске с электронным чтением управляющих сигналов, которые могут взаимодействовать с программируемой компьютерной системой для осуществления метода. Таким образом, изобретение также заключается в компьютерном программном продукте с управляющей программой, сохраненной на машиночитаемом носителе для осуществления метода изобретения, когда компьютерный программный продукт запущен на компьютере. Другими словами, изобретение, таким образом, может быть реализовано как компьютерная программа с управляющей программой для осуществления метода, когда компьютерная программа запущена на компьютере.
В то время как это изобретение описывалось в терминах нескольких предпочтительных осуществлений, существуют изменения, перестановки, и эквиваленты, которые находятся в рамках этого изобретения. Следует также отметить, что существует много альтернативных способов осуществления методов и структур данного изобретения. Поэтому предполагается, что следующие прилагаемые формулы изобретения будут интерпретироваться как формулы, включающие все изменения, перестановки, и эквиваленты, находящиеся в рамках истинной сущности и объема данного изобретения.

Claims (21)

1. Устройство (100) для записи файла (102), имеющего связанные хранилище медиа данных (104) и хранилище метаданных (106), включающее приемник (108) для получения первых потоковых пакетов RTP (пакеты транспортного протокола реального времени) (110), включающих пакетизированные первые выборки медиа данных, основанные на первом тактовом генераторе, и для получения вторых потоковых пакетов RTP (112), включающих вторые выборки медиа данных, основанные на втором тактовом генераторе, отличном от первого тактового генератора, где вторые выборки медиа данных связаны с первыми выборками медиа данных; и для получения первых пакетов RTCP (пакеты протокола управления передачей в реальном времени) (114), связанных с первыми потоковыми пакетами RTP (110) и включающих информацию, указывающую на отношение первого тактового генератора к исходному тактовому генератору; и для получения вторых пакетов RTCP (115), связанных со вторыми потоковыми пакетами RTP (112) и включающими информацию, указывающую на отношение второго тактового генератора к исходному тактовому генератору; и записывающее устройство (116) для сохранения полученных первых и вторых потоковых пакетов RTP (110; 112) и, по крайней мере, сообщений отправителя RTCP полученных первых и вторых пакетов RTCP (114; 115) в хранилище медиа данных (104); и для сохранения связанных метаданных (124; 128) в хранилище метаданных (106); связанные метаданные включают информацию о времени приема и/или временной метке транспортного протокола полученных первых и вторых потоковых пакетов RTP и полученных первых и вторых пакетов RTCP и информацию о местоположении, указывающую местоположение сохраненных первых и вторых пакетов RТP и сохраненных первых и вторых пакетов RTCP в хранилище медиа данных.
2. Устройство по п.1, где записывающее устройство (116) приспособлено для сохранения первых и вторых потоковых пакетов RTP как выборок на первых участках памяти (118) хранилища медиа данных (104); и для сохранения сообщений отправителя RTCP, полученных первых и вторых пакетов RTCP (114; 115), как выборок на вторых участках памяти (122) хранилища медиа данных (104).
3. Устройство по п.2, где записывающее устройство (116) приспособлено для сохранения первых и вторых участков памяти (118; 122) способом чередования в хранилище медиа данных (104).
4. Устройство по п.1, где записывающее устройство (116) приспособлено для сохранения информации о времени приема и/или временной метке транспортного протокола и информации о местоположении первых и вторых пакетов RTP (110; 112) на первой дорожке (124) хранилища метаданных (106); и для сохранения информации о времени приема и/или временной метке транспортного протокола и информации о местоположении первых и вторых пакетов RTCP (114; 115) на второй дорожке (128) хранилища метаданных (106).
5. Устройство по п.1, где записывающее устройство (116) приспособлено для сохранения информации о времени приема и/или временной метке транспортного протокола первых и вторых пакетов RTP (110; 112) в первом блоке таблицы выборок (stts), позволяющей осуществлять индексацию от хронометража приема первого и/или второго пакета RTP до связанного с ним числа выборок на первых участках памяти (118); и для сохранения информации о хронометраже приема первых и вторых пакетов RTCP (114; 115) во втором блоке таблицы выборок (stts), позволяющей осуществлять индексацию от хронометража приема первого и/или второго пакета RTCP до связанного с ним числа выборок на вторых участках памяти (122).
6. Устройство по п.5, где записывающее устройство (116) приспособлено для сохранения первой таблицы смещения участка памяти (stco; co64), указывающей индекс каждого первого участка памяти (118) в файл (102); и для сохранения второй таблицы смещения участка памяти (stco; co64), указывающей индекс каждого второго участка памяти (122) в файл (102).
7. Устройство по п.1, где устройство (100) включает процессор (602) для определения информации о синхронизации для синхронизации первых и вторых выборок медиа данных, основанных на сохраненной информации о времени приема и/или временной метке транспортного протокола первых и вторых пакетов RTP (110; 112) и временных метках NTP (протокол сетевого времени), содержащихся в сохраненных первых и вторых пакетах RTCP (114; 115), связанных с первыми и вторыми пакетами RTP.
8. Устройство по п.7, где процессор (602), сконфигурированный для определения, основан на сохраненных первых и вторых пакетах RTP (110; 112), сохраненных первых и вторых пакетах RTCP (114; 115) и основан на сохраненной связанной метаинформации (124; 128), информации о декодировании (604; 606; 704; 706) для полезной информации сохраненных пакетов RTP (110; 112), где информация о декодировании указывает, в какой момент времени повторно воспроизводить какую полезную информацию сохраненных пакетов RTP.
9. Устройство по п.8, где процессор приспособлен для определения того, какой из сохраненных пакетов RTP (110; 112) связан с первой или второй выборками медиа данных, и для сохранения первых выборок информации о декодировании (602; 702), связанных с первыми выборками медиа данных в хранилище медиа данных (104); и для сохранения первой метаинформации о декодировании (604; 704) в хранилище метаданных (106); первая метаинформация о декодировании (604; 704) указывает местоположение первых выборок информации о декодировании (602; 702) в медиа хранилище (104); и для сохранения вторых выборок информации о декодировании (602; 702), связанных со вторыми выборками медиа данных в хранилище медиа данных (104) и для сохранения второй метаинформации о декодировании (604; 704) в хранилище метаданных (106); вторая метаинформация о декодировании (604; 704) указывает местоположение вторых выборок информации о декодировании (602; 702) в медиа хранилище (104).
10. Устройство по п.1, где приемник (108; 1108) приспособлен далее для получения пакетов ключевого потока (1112), включающих множество шифровальных ключей (kn), где каждый шифровальный ключ связан с полезной информацией, по крайней мере, одного из первых и/или вторых пакетов RTP (110; 112; 1110), и где записывающее устройство приспособлено для сохранения полученных пакетов ключевого потока в хранилище медиа данных (104; 1104) и для сохранения связанной информации о хронометраже пересылки в хранилище метаданных (106; 1106).
11. Устройство по п.10, где записывающее устройство (116; 1116) приспособлено для сохранения пакетов ключевого потока (1112) как выборки на ключевых участках памяти (1120) хранилище медиа данных (104; 1104) и для сохранения связанный информации о хронометраже пересылки и информации о местоположении, указывающей местоположение пакетов ключевого потока в хранилище медиа данных на ключевой дорожке (1128) хранилище метаданных (106; 1106).
12. Устройство по п.10, где записывающее устройство (116; 1116) приспособлено для сохранения информации о хронометраже пересылки в ключевом блоке таблицы выборок (stts), позволяющей индексировать от хронометража пересылки пакета ключевого потока до связанного с ним числа выборок на ключевых участках памяти (1120).
13. Устройство по п.10, где записывающее устройство (116; 1116) приспособлено для сохранения индекса времени приема пакета ключевого потока как связанной информации о хронометраже пересылки или для сохранения временной метки пакета RTP пакета, полученного в предопределенный временной интервал около времени приема пакета ключевого потока как связанной информации о хронометраже пакета ключевого потока.
14. Устройство по п.10, где процессор (602), приспособленный для присваивания, основан на сохраненных первых и вторых пакетах RTP (110; 112), основан на сохраненных первых и вторых пакетах RTCP (114; 115), основан на связанной метаинформации (124; 128) и основан на сохраненных пакетах ключевого потока (1112) и на связанной метаинформации ключевого потока (1128), на информации о декодировании для полезной информации сохраненных первых и/или вторых пакетов RTP (110; 112), где информация о декодировании указывает, какой шифровальный ключ использовать в какой момент времени для повторного воспроизведения полезной информации сохраненных первых и/или вторых пакетов RTP.
15. Устройство по п.14, где процессор (602) приспособлен для сохранения информации о декодировании в выборках информации о декодировании в хранилище медиа данных (104) и для сохранения связанной метаинформации о декодировании команды в хранилище метаданных (106).
16. Способ записи файла (102), имеющего связанные хранилище медиа данных (104) и хранилище метаданных (106), включающий получение первых потоковых пакетов RTP (110), включающих пакетизированные первые выборки медиа данных, основанные на первом тактовом генераторе; получение вторых потоковых пакетов RTP (112), включающих вторые выборки медиа данных, основанные на втором тактовом генераторе, отличном от первого тактового генератора, где вторые выборки медиа данных связаны с первыми выборками медиа данных; и получение первых пакетов RTCP (114), включающих информацию, указывающую на отношение первого тактового генератора к исходному тактовому генератору, и получение вторых пакетов RTCP (115), включающих информацию, указывающую на отношение второго тактового генератора к исходному тактовому генератору; и хранение полученных первых и вторых потоковых пакетов RTP (110; 112) и, по крайней мере, сообщений отправителя RTCP полученных первых и вторых пакетов RTCP (114; 115) в хранилище медиа данных (104); хранение связанных мегаданных (124; 128) в хранилище метаданных (106); связанные метаданные включают информацию о времени приема и/или временной метке транспортного протокола полученных первых и вторых потоковых пакетов RТP и полученных первых и вторых пакетов RTCP и информацию о местоположении, указывающую местоположение сохраненных первых и вторых пакетов RTP и сохраненных первых и вторых пакетов RTCP в хранилище медиа данных.
17. Машиночитаемый носитель информации с сохраненной на нем компьютерной программой для реализации способа по п.16, когда компьютерная программа запущена на компьютере или микроконтроллере.
18. Устройство для чтения файла (102); в котором файл, сохраненный в хранилище медиа данных (104), связан с файлом первых потоковых пакетов RTP (110), включающих пакетизированные первые выборки медиа данных, основанные на первом тактовом генераторе и вторых потоковых пакетах RTP (112), включающих пакетизированные вторые выборки медиа данных, основанные на втором тактовом генераторе, отличном от первого тактового генератора; и файл, сохраняющий, по крайней мере, сообщения отправителя RTCP, связан с первыми пакетами RTCP (114), включающими информацию, указывающую на отношение первого тактового генератора к исходному тактовому генератору, и сохраняющий, по крайней мере, сообщение отправителя RTCP, связанное со вторыми пакетами RTCP (115), включающими информацию, указывающую на отношение второго тактового генератора к исходному тактовому генератору; файл, сохраняющий связанные метаданные (124; 128) в хранилище метаданных (106) файла; связанные метаданные включают информацию о времени приема и/или временной метке транспортного протокола полученных первых и вторых потоковых пакетов RTP (110; 112) и полученных первых и вторых пакетов RTCP (114; 115) и информацию о местоположении, указывающую местоположение сохраненных первых и вторых пакетов RТP и сохраненных первых и вторых пакетов RTCP в хранилище медиа данных; включающее процессор для определения графика вывода сохраненных первых и вторых пакетов RTP (110; 112) посредством доступа к хранилищу метаданных (106) и посредством интерпретации информации о времени приема и/или временной метке транспортного протокола сохраненных первых и вторых пакетов RTP и сохраненных первых и вторых пакетов RTCP (114; 115) в хранилище медиа данных (104), где процессор приспособлен для определения информации о синхронизации, основанной на сохраненной информации о времени приема и/или временной метке транспортного протокола первых и вторых пакетов RTP (110; 112), и опорных временных метках, содержащихся в сообщениях отправителя RTCP сохраненных первых и вторых пакетов RTCP (114; 115), таким образом, что график вывода первых пакетов RTP синхронизирован с графиком вывода вторых пакетов RTP с учетом медиа хронометража об опорной отметке времени; и контроллер вывода для вывода первых и вторых пакетов RTP (110; 112) в соответствии с определенным графиком вывода посредством доступа к хранилищу метаданных (106) и посредством считывания пакетов RTP из хранилища медиа данных (104).
19. Устройство по п.19, где процессор приспособлен для определения графика вывода таким образом, что график вывода отражает порядок приема первых и вторых пакетов RTP (110; 112), где порядок приема определяется сохраненной информацией о хронометраже приема полученных первых и вторых пакетов RTP.
20. Способ чтения файла (102); в котором файл, сохраненный в хранилище медиа данных (104), связан с файлом первых потоковых пакетов RTP (110), включающих пакетизированные первые выборки медиа данных, основанные на первом тактовом генераторе и вторых потоковых пакетах RTP (112), включающих пакетизированные вторые выборки медиа данных, основанные на втором тактовом генераторе, отличном от первого тактового генератора, и на файле, сохраняющем, по крайней мере, сообщение отправителя RTCP связанных первых пакетов RTCP (114), включающих информацию, указывающую на отношение первого тактового генератора к исходному тактовому генератору и сохраняющую, по крайней мере, сообщение отправителя RTCP связанных вторых пакетов RTCP (115), включающих информацию, указывающую на отношение второго тактового генератора к исходному тактовому генератору; файл, сохраняющий связанные метаданные (124; 128) в хранилище метаданных (106) файла; связанные метаданные включают информацию о времени приема и/или временной метке транспортного протокола полученных первых и вторых потоковых пакетов RTP (110; 112) и полученных первых и вторых пакетов RTCP (114; 115) и информацию о местоположении, указывающую местоположение сохраненных первых и вторых пакетов RTP и сохраненных первых и вторых пакетов RTCP в хранилище медиа данных; включающий определение графика вывода сохраненных первых и вторых пакетов RTP (110; 112) посредством доступа к хранилищу метаданных (106) и посредством интерпретации информации о времени приема и/или временной метке транспортного протокола сохраненных первых и вторых пакетов RTP и сохраненных первых и вторых пакетов RTCP (114; 115) в хранилище медиа данных (104), где информация о синхронизации определяется на основании сохраненной информации о времени приема и/или временной метке транспортного протокола первых и вторых пакетов RTP (110; 112) и опорной временной метке, содержащейся в сообщениях отправителя RTCP сохраненных первых и вторых пакетов RTCP (114; 115), таким образом, что график вывода первых пакетов RTP синхронизирован с графиком вывода вторых пакетов RTP с учетом медиа хронометража первых и вторых выборок медиа данных, где медиа хронометраж основан на информации об опорной отметке времени; и вывод первых и вторых пакетов RTP (110; 112) в соответствии с определенным графиком вывода посредством доступа к хранилищу метаданных (106) и посредством считывания пакетов RTP из хранилища медиа данных (104).
21. Машиночитаемый носитель информации с сохраненной на нем компьютерной программой для реализации способа по п.20, когда компьютерная программа запущена на компьютере или микроконтроллере.
RU2009148647/07A 2007-07-02 2008-07-01 Устройство и способ для хранения и чтения файла, имеющего хранилище медиа данных и хранилище метаданных RU2492587C2 (ru)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US94753907P 2007-07-02 2007-07-02
US60/947,539 2007-07-02
PCT/EP2008/005374 WO2009003684A1 (en) 2007-07-02 2008-07-01 Apparatus and method for storing and reading a file having a media data container and a metadata container

Publications (2)

Publication Number Publication Date
RU2009148647A RU2009148647A (ru) 2011-08-10
RU2492587C2 true RU2492587C2 (ru) 2013-09-10

Family

ID=39865600

Family Applications (2)

Application Number Title Priority Date Filing Date
RU2009147728/07A RU2459378C2 (ru) 2007-07-02 2008-07-01 Устройство и способ для обработки и чтения файла, имеющего хранилище медиаданных и хранилище метаданных
RU2009148647/07A RU2492587C2 (ru) 2007-07-02 2008-07-01 Устройство и способ для хранения и чтения файла, имеющего хранилище медиа данных и хранилище метаданных

Family Applications Before (1)

Application Number Title Priority Date Filing Date
RU2009147728/07A RU2459378C2 (ru) 2007-07-02 2008-07-01 Устройство и способ для обработки и чтения файла, имеющего хранилище медиаданных и хранилище метаданных

Country Status (12)

Country Link
US (2) US8462946B2 (ru)
EP (2) EP2160899B1 (ru)
JP (2) JP5334335B2 (ru)
KR (2) KR101074585B1 (ru)
CN (2) CN101731013B (ru)
AT (1) ATE495631T1 (ru)
BR (2) BRPI0811821B1 (ru)
DE (1) DE602008004502D1 (ru)
HK (1) HK1136726A1 (ru)
RU (2) RU2459378C2 (ru)
TW (3) TWI371204B (ru)
WO (3) WO2009003685A1 (ru)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2690439C2 (ru) * 2014-06-20 2019-06-03 Сони Корпорейшн Устройство и способ кодирования изображений и устройство и способ декодирования изображений

Families Citing this family (73)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7617278B1 (en) 2003-01-29 2009-11-10 Adobe Systems Incorporated Client controllable server-side playlists
DE102007004951A1 (de) * 2007-01-26 2008-07-31 Deutsche Thomson Ohg Verfahren zum paketvermittelten Übertragen von Mediendaten sowie Vorrichtung zum Bearbeiten von Mediendaten
WO2009003685A1 (en) * 2007-07-02 2009-01-08 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Apparatus and method for storing and reading a file having a media data container and a metadata container
US7941399B2 (en) 2007-11-09 2011-05-10 Microsoft Corporation Collaborative authoring
US8825758B2 (en) 2007-12-14 2014-09-02 Microsoft Corporation Collaborative authoring modes
US8300823B2 (en) * 2008-01-28 2012-10-30 Netapp, Inc. Encryption and compression of data for storage
FR2927208B1 (fr) * 2008-01-31 2010-02-12 Airbus France Procede et dispositif de mesure de la derive temporelle d'un equipement electronique relie a un reseau
US8077736B2 (en) * 2008-02-25 2011-12-13 Newport Media, Inc. Fast audio/visual reception in DVB-H systems
US8352870B2 (en) 2008-04-28 2013-01-08 Microsoft Corporation Conflict resolution
EP2114027A1 (en) * 2008-04-30 2009-11-04 Gemplus Method of detecting TV off event on a mobile terminal
US8825594B2 (en) 2008-05-08 2014-09-02 Microsoft Corporation Caching infrastructure
US8261312B2 (en) * 2008-06-27 2012-09-04 Cisco Technology, Inc. Linear hint video streaming
US8776144B2 (en) * 2008-10-16 2014-07-08 Industrial Technology Research Institute Mobile TV system and method for synchronizing the rendering of streaming services thereof
JP2010181800A (ja) * 2009-02-09 2010-08-19 Mitsubishi Electric Corp 暗号化メディアファイルのデータ構造、暗号化メディア作成方法、暗号化メディア復号方法、暗号化メディア分割方法及び暗号化メディア結合方法並びに装置
JP5169947B2 (ja) * 2009-03-31 2013-03-27 富士通モバイルコミュニケーションズ株式会社 情報処理装置
US8346768B2 (en) * 2009-04-30 2013-01-01 Microsoft Corporation Fast merge support for legacy documents
US8166191B1 (en) * 2009-08-17 2012-04-24 Adobe Systems Incorporated Hint based media content streaming
EP2497269A1 (en) 2009-11-06 2012-09-12 Telefonaktiebolaget LM Ericsson (publ) File format for synchronized media
WO2011074398A1 (ja) * 2009-12-14 2011-06-23 住友電工ネットワークス株式会社 コンテンツ受信装置、コンテンツ再生装置、コンテンツ受信再生装置、コンテンツ受信方法、及びプログラム
WO2011127312A1 (en) * 2010-04-07 2011-10-13 Apple Inc. Real-time or near real-time streaming
WO2011132882A2 (ko) * 2010-04-19 2011-10-27 엘지전자 주식회사 인터넷 기반 컨텐츠 송수신 방법 및 그를 이용한 송수신 장치
KR20110117033A (ko) 2010-04-20 2011-10-26 삼성전자주식회사 미디어 데이터를 송수신하기 위한 인터페이스 장치 및 방법
KR101294542B1 (ko) * 2010-12-09 2013-08-07 한국전자통신연구원 데이터 변경 장치 및 방법
KR101920439B1 (ko) * 2011-04-28 2019-02-14 삼성전자주식회사 공용 인터페이스를 통해 수신 제한 모듈로 암호화된 데이터를 전송하기 위한 데이터 전송 장치 및 그에 적용되는 방법, 수신 제한 모듈 그리고 시스템.
US8731597B1 (en) * 2011-05-26 2014-05-20 Sprint Spectrum L.P. Method and system of transmitting power control commands
US8938625B2 (en) 2011-06-29 2015-01-20 Sonic Ip, Inc. Systems and methods for securing cryptographic data using timestamps
US9451313B2 (en) 2011-06-29 2016-09-20 Harman International Industries, Incorporated Network media adapter
US20130004142A1 (en) * 2011-06-29 2013-01-03 Rovi Corp. Systems and methods for device authentication including timestamp validation
KR102023788B1 (ko) * 2011-07-29 2019-09-20 소니 주식회사 스트리밍 배신 장치 및 방법, 스트리밍 수신 장치 및 방법, 스트리밍 시스템, 프로그램과 기록 매체
KR101885852B1 (ko) * 2011-09-29 2018-08-08 삼성전자주식회사 컨텐트 전송 및 수신 방법 및 장치
JP5917123B2 (ja) * 2011-12-14 2016-05-11 キヤノン株式会社 記録装置
JP5848594B2 (ja) * 2011-12-14 2016-01-27 キヤノン株式会社 記録装置
US8824680B2 (en) * 2012-08-08 2014-09-02 Verizon Patent And Licensing Inc. Centralized key generation
US9319878B2 (en) * 2012-09-14 2016-04-19 Qualcomm Incorporated Streaming alignment of key stream to unaligned data stream
DE102012022064A1 (de) 2012-11-09 2014-05-15 Thomas Klimpel System und Verfahren zur Wiedergabe von Musikstücken und/oder Multimediadaten
US11290510B2 (en) 2012-11-29 2022-03-29 Samsung Electronics Co., Ltd. Method and apparatus for encapsulation of motion picture experts group media transport assets in international organization for standardization base media files
WO2014084666A1 (en) * 2012-11-30 2014-06-05 Samsung Electronics Co., Ltd. Information storage medium storing content, content providing method, content reproducing method and apparatus therefor
KR102179384B1 (ko) * 2012-11-30 2020-11-16 삼성전자주식회사 컨텐트를 저장한 정보저장매체, 컨텐트 제공 방법, 컨테트 재생 방법 및 그 장치
US9648299B2 (en) 2013-01-04 2017-05-09 Qualcomm Incorporated Indication of presence of texture and depth views in tracks for multiview coding plus depth
CN109587573B (zh) * 2013-01-18 2022-03-18 佳能株式会社 生成设备和方法、显示设备和方法以及存储介质
SG11201502405RA (en) * 2013-01-21 2015-04-29 Dolby Lab Licensing Corp Audio encoder and decoder with program loudness and boundary metadata
JP5641090B2 (ja) * 2013-03-14 2014-12-17 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
KR101484843B1 (ko) 2013-04-19 2015-01-20 삼성전자주식회사 멀티미디어 전송 시스템에서 미디어 전송 패킷 전송 방법 및 장치
JP2014230154A (ja) * 2013-05-23 2014-12-08 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
US9674569B2 (en) * 2013-05-29 2017-06-06 Avago Technologies General Ip (Singapore) Pte. Ltd. Clock recovery in transponder-bonded systems using BCRs and marker packets at a set-top box
WO2014200280A2 (en) 2013-06-12 2014-12-18 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
JP2015012580A (ja) * 2013-07-02 2015-01-19 キヤノン株式会社 受信装置、受信方法及びプログラム
US20160173556A1 (en) * 2013-07-05 2016-06-16 Lg Electronics Inc. Method and apparatus for transmitting/receiving media broadcasting signal in real time transport protocol-based broadcasting system
EP3050304A4 (en) * 2013-09-27 2017-05-31 LG Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
JP6652320B2 (ja) * 2013-12-16 2020-02-19 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 送信方法、受信方法、送信装置及び受信装置
EP3095245A4 (en) 2014-01-13 2017-11-08 LG Electronics Inc. Apparatuses and methods for transmitting or receiving a broadcast content via one or more networks
KR101788066B1 (ko) 2014-01-13 2017-11-15 엘지전자 주식회사 하나 이상의 네트워크를 통해 방송 컨텐츠를 송수신하는 장치 및 방법
WO2015108309A1 (en) * 2014-01-14 2015-07-23 Lg Electronics Inc. Broadcast transmission device and operating method thereof, broadcast reception device and operating method thereof
JP2016027512A (ja) * 2014-06-30 2016-02-18 ソニー株式会社 情報処理装置、情報記録媒体、および情報処理方法、並びにプログラム
KR102271811B1 (ko) 2014-10-22 2021-07-01 삼성전자주식회사 전자장치 및 전자장치의 컨텐트 제어 방법
KR101555792B1 (ko) 2014-11-28 2015-09-25 주식회사 엘지유플러스 멀티미디어 청크(chunk)를 수신하는 통신 단말기의 제어방법과, 그 제어방법을 실행하기 위한 프로그램을 기록한 기록 매체
CN107615395B (zh) * 2015-03-26 2021-02-05 外科安全技术公司 用于事件和差错预测的手术室黑盒设备、系统、方法和计算机可读介质
US9916458B2 (en) * 2015-03-31 2018-03-13 EMC IP Holding Company LLC Secure cloud-based storage of data shared across file system objects and clients
US10191914B2 (en) 2015-03-31 2019-01-29 EMC IP Holding Company LLC De-duplicating distributed file system using cloud-based object store
US11212333B1 (en) * 2015-05-29 2021-12-28 Ribbon Communications Operating Company, Inc. Methods and apparatus for synchronizing transcoded and/or transrated RTP packets
EP4216556A1 (en) * 2016-05-20 2023-07-26 Lg Electronics, Inc. Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
KR101853441B1 (ko) * 2016-09-23 2018-05-02 재단법인 실감교류인체감응솔루션연구단 클라이언트 장치 및 그 로컬 클럭 스큐 보정 방법
RU172157U1 (ru) * 2017-03-22 2017-06-29 Акционерное общество "МЦСТ" Контроллер межпроцессорного канала обмена данными второго поколения (IPCC2)
WO2019195037A1 (en) 2018-04-03 2019-10-10 Futurewei Technologies, Inc. Bitstream signaling of error mitigation in sub-picture bitstream based viewport dependent video coding
EP3830713A1 (en) * 2018-07-31 2021-06-09 Marvell Asia Pte, Ltd. Metadata generation at the storage edge
CN110866127A (zh) * 2018-08-27 2020-03-06 华为技术有限公司 建立索引的方法以及相关装置
US11743003B2 (en) 2018-09-24 2023-08-29 Telefonaktiebolaget Lm Ericsson (Publ) Transmitting and receiving packets wirelessly with time based packet data portion positioning
US11457231B2 (en) 2019-03-15 2022-09-27 Mediatek Singapore Pte. Ltd. Methods and apparatus for signaling spatial relationships for point cloud multimedia data tracks
US11245926B2 (en) * 2019-03-19 2022-02-08 Mediatek Singapore Pte. Ltd. Methods and apparatus for track derivation for immersive media data tracks
US11482005B2 (en) * 2019-05-28 2022-10-25 Apple Inc. Techniques for secure video frame management
CN111756818B (zh) * 2020-06-05 2022-01-14 腾讯科技（深圳）有限公司 一种文件传送方法、装置、设备及存储介质
CN111966473B (zh) * 2020-07-24 2024-02-06 支付宝(杭州)信息技术有限公司 一种线性回归任务的运行方法及装置、电子设备
US20220360853A1 (en) * 2021-05-05 2022-11-10 Samsung Electronics Co., Ltd. Mmt based drm operation for atsc 3.0

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5765164A (en) * 1995-12-21 1998-06-09 Intel Corporation Apparatus and method for management of discontinuous segments of multiple audio, video, and data streams
US6169843B1 (en) * 1995-12-01 2001-01-02 Harmonic, Inc. Recording and playback of audio-video transport streams
WO2005045704A1 (en) * 2003-10-24 2005-05-19 Microsoft Corporation Embedding a session dession description message in a real-time control protocol (rtcp) message
US6912010B2 (en) * 2002-04-15 2005-06-28 Tektronix, Inc. Automated lip sync error correction
RU2004120267A (ru) * 2003-07-03 2006-01-10 Майкрософт Корпорейшн (Us) Формат полезных данных транспортного протокола реального времени
RU2006113934A (ru) * 2003-09-25 2006-08-27 Самсунг Электроникс Ко., Лтд. (KR) Устройство и способ для воспроизведения аудио- и видеоданных, а также носитель данных с записанной на нем программой для выполнения способа воспроизведения

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6377966B1 (en) 1997-10-22 2002-04-23 Flashpoint Technology, Inc. Graphical interface to select characters representing phonetic articulation and no articulation groups
US6396874B1 (en) * 1997-11-12 2002-05-28 Sony Corporation Decoding method and apparatus and recording method and apparatus for moving picture data
US6311221B1 (en) 1998-07-22 2001-10-30 Appstream Inc. Streaming modules
JP2000078197A (ja) 1998-09-03 2000-03-14 Toshiba Corp 通信ノード及びパケット転送方法
US6549922B1 (en) 1999-10-01 2003-04-15 Alok Srivastava System for collecting, transforming and managing media metadata
WO2001055877A1 (en) 2000-01-28 2001-08-02 Diva Systems Corporation A system for preprocessing content for streaming server
AU2001251341A1 (en) * 2000-04-08 2001-10-23 Sun Microsystems, Inc. Resynchronizing media during streaming
GB2366926A (en) 2000-09-06 2002-03-20 Sony Uk Ltd Combining material and data
GB0103381D0 (en) * 2001-02-12 2001-03-28 Eyretel Ltd Packet data recording method and system
JP3946965B2 (ja) * 2001-04-09 2007-07-18 ソニー株式会社 無体財産権を保護する情報を記録する記録装置、記録方法、記録媒体、およびプログラム
US7162479B2 (en) 2001-08-15 2007-01-09 Bentley Systens, Incorporated Method and system for storing large data files
JP3925218B2 (ja) * 2002-01-30 2007-06-06 ソニー株式会社 ストリーミングシステム及びストリーミング方法、ストリーミングサーバ及びデータ配信方法、クライアント端末及びデータ復号方法、並びにプログラム及び記録媒体
US7143132B2 (en) * 2002-05-31 2006-11-28 Microsoft Corporation Distributing files from a single server to multiple clients via cyclical multicasting
US7313236B2 (en) 2003-04-09 2007-12-25 International Business Machines Corporation Methods and apparatus for secure and adaptive delivery of multimedia content
US7586938B2 (en) 2003-10-24 2009-09-08 Microsoft Corporation Methods and systems for self-describing multicasting of multimedia presentations
US7480382B2 (en) 2003-09-30 2009-01-20 Microsoft Corporation Image file container
KR101244308B1 (ko) * 2003-12-08 2013-03-18 삼성전자주식회사 동영상 파일의 암호화 방법 및 그를 이용한 디지털 저작권관리방법
US8472792B2 (en) 2003-12-08 2013-06-25 Divx, Llc Multimedia distribution system
EP1542488A1 (en) 2003-12-12 2005-06-15 Telefonaktiebolaget LM Ericsson (publ) Method and apparatus for allocating a pilot signal adapted to the channel characteristics
JP2006164378A (ja) 2004-12-06 2006-06-22 Toshiba Corp 情報記録媒体、情報記録方法、情報再生方法、情報記録装置、情報再生装置
US20060227813A1 (en) 2005-04-11 2006-10-12 Mavrogeanes Richard A Method and system for synchronized video recording/delivery
MX2007012564A (es) 2005-04-13 2007-11-15 Nokia Corp Codificacion, almacenamiento y senalizacion de informacion de escalabilidad.
US20060293077A1 (en) * 2005-06-27 2006-12-28 Nokia Corporation System, terminal, method, and computer program product for allocating memory for storage of content
US7843974B2 (en) 2005-06-30 2010-11-30 Nokia Corporation Audio and video synchronization
US20070022215A1 (en) 2005-07-19 2007-01-25 Singer David W Method and apparatus for media data transmission
KR100927978B1 (ko) * 2005-09-01 2009-11-24 노키아 코포레이션 리치 미디어 콘텐츠의 프로그레시브 다운로딩 및스트리밍을 위해 ｉｓｏ 기반 미디어 파일 포맷으로 ｓｖｇ콘텐츠를 임베딩 하는 방법
DE102005062468A1 (de) 2005-12-27 2007-07-05 Robert Bosch Gmbh Verfahren zur Synchronisation von Datenströmen
US7995143B2 (en) * 2006-02-10 2011-08-09 Qualcomm Incorporated Wireless video link synchronization
JP2008061010A (ja) * 2006-08-31 2008-03-13 Toshiba Corp 映像音声送信装置
US8065672B2 (en) * 2007-01-23 2011-11-22 Oracle International Corporation Simplifying rollback to prior versions of patches used to fix errors in pre-installed software
WO2009003685A1 (en) * 2007-07-02 2009-01-08 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Apparatus and method for storing and reading a file having a media data container and a metadata container
US20090169001A1 (en) * 2007-12-28 2009-07-02 Cisco Technology, Inc. System and Method for Encryption and Secure Transmission of Compressed Media

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6169843B1 (en) * 1995-12-01 2001-01-02 Harmonic, Inc. Recording and playback of audio-video transport streams
US5765164A (en) * 1995-12-21 1998-06-09 Intel Corporation Apparatus and method for management of discontinuous segments of multiple audio, video, and data streams
US6912010B2 (en) * 2002-04-15 2005-06-28 Tektronix, Inc. Automated lip sync error correction
RU2004120267A (ru) * 2003-07-03 2006-01-10 Майкрософт Корпорейшн (Us) Формат полезных данных транспортного протокола реального времени
RU2006113934A (ru) * 2003-09-25 2006-08-27 Самсунг Электроникс Ко., Лтд. (KR) Устройство и способ для воспроизведения аудио- и видеоданных, а также носитель данных с записанной на нем программой для выполнения способа воспроизведения
WO2005045704A1 (en) * 2003-10-24 2005-05-19 Microsoft Corporation Embedding a session dession description message in a real-time control protocol (rtcp) message

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
H. SCHULZRINNE et al. RTP: A Transport Protocol for Real-Time Applications; rfc3550.txt, IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 01 July 2003. INTERNET STREAMING MEDIA ALLIANCE, Implementation Specification, ISMA Encryption and Authentication, Version 1.1, AREA/Task Force: DRM, 15 September 2006. INTERNATIONAL STANDARD, ISO/IEC 14496-12, Information technology - Coding of audio-visual objects - Part 12: ISO base media file format. Second edition 2005-04-01, Corrected version 2005-10-01. *
INTERNET STREAMING MEDIA ALLIANCE. Internet Streaming Media Alliance Implementation Specification Version 1.0 + Corrigenda, 03 June 2004. INTERNATIONAL STANDARD, ISO/IEC 14496-14, Information technology - Coding of audio-visual objects - Part 14: MP4 file format, First edition, 15.11.2003. *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2690439C2 (ru) * 2014-06-20 2019-06-03 Сони Корпорейшн Устройство и способ кодирования изображений и устройство и способ декодирования изображений

Also Published As

Publication number Publication date
JP4766473B2 (ja) 2011-09-07
RU2009148647A (ru) 2011-08-10
EP2149264B1 (en) 2011-01-12
WO2009003684A1 (en) 2009-01-08
TWI371204B (en) 2012-08-21
HK1136726A1 (en) 2010-07-02
ATE495631T1 (de) 2011-01-15
CN101731013A (zh) 2010-06-09
US20100189256A1 (en) 2010-07-29
US8462946B2 (en) 2013-06-11
TW200908652A (en) 2009-02-16
EP2160899B1 (en) 2019-05-08
US20100189424A1 (en) 2010-07-29
EP2149264A1 (en) 2010-02-03
BRPI0811833B1 (pt) 2020-12-29
TW200910880A (en) 2009-03-01
US9236091B2 (en) 2016-01-12
JP2010531590A (ja) 2010-09-24
KR101074585B1 (ko) 2011-10-17
KR20100029137A (ko) 2010-03-15
BRPI0811821A2 (pt) 2014-11-04
CN101790886B (zh) 2012-12-05
JP2010532605A (ja) 2010-10-07
BRPI0811833A2 (pt) 2014-11-18
RU2459378C2 (ru) 2012-08-20
KR20100025018A (ko) 2010-03-08
JP5334335B2 (ja) 2013-11-06
TWI430665B (zh) 2014-03-11
CN101731013B (zh) 2013-06-12
WO2009003685A1 (en) 2009-01-08
CN101790886A (zh) 2010-07-28
KR101199732B1 (ko) 2012-11-08
EP2160899A1 (en) 2010-03-10
WO2009003683A1 (en) 2009-01-08
TW200910970A (en) 2009-03-01
DE602008004502D1 (de) 2011-02-24
BRPI0811821B1 (pt) 2019-11-12
TWI446773B (zh) 2014-07-21
RU2009147728A (ru) 2011-08-10

Similar Documents

Publication Publication Date Title
RU2492587C2 (ru) Устройство и способ для хранения и чтения файла, имеющего хранилище медиа данных и хранилище метаданных
KR101254385B1 (ko) 미디어 데이터 및 멀티미디어 데이터 중 적어도 하나를 적어도 하나의 파일 내에서 구성화하는 방법 및 장치, 액세스 방법, 컴퓨터 판독가능 저장 매체
KR101107815B1 (ko) 멀티미디어 컨테이너 파일의 수신 힌트 트랙으로의 미디어 스트림 기록 방법 및 장치, 컴퓨터 판독가능 매체
CA2695645C (en) Segmented metadata and indexes for streamed multimedia data
EP2195952B1 (en) Apparatus and method for storing and reading a file having a media data container and a metadata container
KR20030017325A (ko) 데이터스트림의 ｄｖｄ 레코딩 방법 및 ｄｖｄ 레코더
Murray Broadcasting beyond the TV: The Importance and Impact of Files in Broadcasting