CN101911693A - 用于以iso基本媒体文件格式存储通知消息的系统和方法 - Google Patents

用于以iso基本媒体文件格式存储通知消息的系统和方法 Download PDF

Info

Publication number
CN101911693A
CN101911693A CN2008801235562A CN200880123556A CN101911693A CN 101911693 A CN101911693 A CN 101911693A CN 2008801235562 A CN2008801235562 A CN 2008801235562A CN 200880123556 A CN200880123556 A CN 200880123556A CN 101911693 A CN101911693 A CN 101911693A
Authority
CN
China
Prior art keywords
metadata
file
notification message
track
notify object
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN2008801235562A
Other languages
English (en)
Inventor
M·M·安尼克塞拉
I·鲍阿齐齐
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Oyj
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 Nokia Oyj filed Critical Nokia Oyj
Publication of CN101911693A publication Critical patent/CN101911693A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/4344—Remultiplexing of multiplex streams, e.g. by modifying time stamps or remapping the packet identifiers
    • 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/23608—Remultiplexing multiplex streams, e.g. involving modifying time stamps or remapping the packet identifiers
    • 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
    • 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/8545—Content authoring for generating interactive applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

提供了一种用于在ISO基本媒体文件中存储通知消息的系统和方法，其中解决了将存储通知消息时的不同传送情况。该系统和方法支持将通过RTP递送的通知消息部分与通过单向传送文件递送(FLUTE)或某些其他协议承载的通知消息的其他部分联系起来。该系统和方法的各种实现可以是通用的，并且允许媒体和提示轨道引用带外递送的对象。此外，可以在文件中再生通知对象的生命周期而无需解析文件所需的定时器。

Description

用于以ISO基本媒体文件格式存储通知消息的系统和方法
技术领域
本发明一般地涉及多媒体文件格式的使用。更特别地，本发明涉及在国际标准组织(ISO)基本媒体文件中存储通知消息。
背景技术
本部分旨在为权利要求书中陈述的本发明提供背景或上下文。在此的描述可能包括可以探究的概念，但不一定是那些之前已经想到或者探究的概念。因此，除非在此指出，在本部分中描述的内容对于本申请的说明书和权利要求书而言不是现有技术，并且并不因为包括在本部分中就被认为是现有技术。
多媒体容器文件格式是多媒体内容生产、操作、传输和消费链中的一个重要元素。在该上下文中，编码格式(即基本流格式)涉及用于将内容信息编码成比特流的特定编码算法的动作。容器文件格式包括以这样的方式来组织生成的比特流的机制，即，生成的比特流可被访问以便进行本地解码和回放、作为文件进行传送、或者流式传送，所有这些都利用了各种各样的存储和传送架构。容器文件格式还可以促进媒体的交换和编辑以及将接收的实时流记录到文件。这样，在编码格式和容器文件格式之间存在显著的区别。
可用的媒体和容器文件格式标准包括ISO基本媒体文件格式(ISO/IEC 14496-12)、MPEG-4文件格式(ISO/IEC 14496-14，也称为MP4格式)、高级视频编码(AVC)文件格式(ISO/IEC 14496-15)和3GPP文件格式(3GPP TS 26.244，也称为3GP格式)。在MPEG中还存在用于开发可伸缩视频编码(SVC)文件格式的计划，其将成为对高级视频编码(AVC)文件格式的修改。在同时进行的努力中，MPEG正在定义用于单向传送文件递送(FLUTE)和异步分层编码(ALC)会话的提示轨道格式，其将成为对ISO基本媒体文件格式。
多媒体文件格式提供分层文件结构，其支持对多媒体数据和多媒体的相关信息以及关于如何传输所述多媒体数据的提示的存储。诸如针对投票或上下文广告的请求之类的通知消息可以与某些音频/可视(A/V)内容同步或可以是单独的服务。单独通知服务的一个示例是递送股价的股市行情记录器。然而，通知消息可能具有有限的生命期，例如投票请求可能仅在相关TV节目期间是有效的。
需要开发一种多媒体容器格式，从而除了音频-可视内容之外，还使得能够针对在某个之后时间点处的未来的全功能服务消费来存储通知消息。
发明内容
各种实施方式提供用于在ISO基本媒体文件中存储通知消息的系统和方法。可以解决将要存储通知消息时的不同传送情况。
各种实施方式支持将通过RTP递送的通知消息部分与通过FLUTE(或某些其他协议，例如超文本传输协议(HTTP))承载的通知消息的其他部分联系起来。各种实施方式的实现可以是通用的，并且允许媒体和提示轨道引用带外递送的对象。而且，各种实施方式提供用于有效存储接收的FLUTE会话的方法。通过提取并存储FLUTE会话的传送对象，可以减少冗余和检索时间两者，而仍旧保留时间线。此外，各种实施方式促进了将通知对象的生命周期再生到文件中而无需解析文件所需的定时器。各种实施方式的此类特征简化了诸如随机访问和文件编辑之类的操作。
本发明的这些和其他优势和特征，连同其操作的组织和方式在结合附图时从以下详细描述中变得清楚，在下述的几个附图中相同的元素具有相同的附图标记。
附图说明
图1是多媒体文件格式层级的描述；
图2示出了根据ISO基本媒体文件格式的示例性文件结构；
图3是示出了根据ISO基本媒体文件格式的采样群组的示例性框层级；
图4示出了包含包括SampletoToGroup(采样至群组)框的电影片段的示例性文件；
图5是通知消息结构的图示；
图6示出了通知对象生命周期模型；
图7示出了两个通知对象的示例生命周期；
图8示出了可以在其中实现各种实施方式的示例性多媒体通信系统的图示；
图9示出了用于根据各种实施方式联系文件内通过RTP和FLUTE递送的通知消息部分的方法；
图10示出了根据各种实施方式的在ISO基本媒体文件中对FLUTE传送对象的存储；
图11是示出了根据各种实施方式的用于将传入流存储到文件的过程的流程图。
图12是示出了用于解析和/或处理图11文件的过程的流程图；
图13是可以与各种实施方式的实现结合使用的电子设备的透视图；以及
图14是可以包括在图13的电子设备中的电路的示意图。
具体实施方式
图1以100一般性地示出了多媒体文件格式的层级。基本流格式110表示独立的单个流。根据基本流格式构造诸如.amr和.aac文件的音频文件。容器文件格式120是可以在单个文件中包含音频和视频流两者的格式。容器文件格式120的族的示例基于ISO基本媒体文件格式。层级100中恰好在容器文件格式120之下的是复用格式130。相比于根据容器文件格式120构造的音频/视频(AV)文件，复用格式130通常更不灵活而封装更紧凑。根据复用格式130构造的文件通常仅用于回放目的。移动图片专家组(MPEG)-2节目流是根据复用格式130构造的流的示例。演示语言格式140用于诸如AV和分散媒体的布局、交互、同步等之类的目的。均由万维网理事会(W3C)指定的同步多媒体集成语言(SMIL)和可伸缩视频图形(SVG)是演示语言格式140的示例。演示文件格式150的特征在于在同一文件中具有演示的所有部分。根据演示文件格式构造的对象示例是PowerPoint文件和符合3GP文件格式的扩展演示简档的文件。
可用的媒体和容器文件格式标准包括ISO基本媒体文件格式(ISO/IEC 14496-12)、MPEG-4文件格式(ISO/IEC 14496-14，也称为MP4格式)、高级视频编码(AVC)文件格式(ISO/IEC 14496-15)和3GPP文件格式(3GPP TS 26.244，也称为3GP格式)。在MPEG中还存在用于开发可伸缩视频编码(SVC)文件格式的计划，其将成为对高级视频编码(AVC)文件格式的修改。同时进行的努力中，MPEG正在定义用于单向传送文件递送(FLUTE)和异步分层编码(ALC)会话的提示轨道格式，其将成为对ISO基本媒体文件格式。
ISO基本媒体文件格式中的基础构建块称为框。每个框200包括头部和净荷。该框头部指示框的类型和以字节为单位的框的大小。框可以包含其他框，并且ISO文件格式规定了在某种类型的框中允许哪些框类型。此外，某些框是强制性出现在每个文件中，而其他框仅是可选地。而且，对于某些框类型，可以有多个框存在于文件中。因此，ISO基本媒体文件格式本质上规定了框的分层结构。
图2示出了根据ISO基本媒体文件格式的简化文件结构。根据ISO文件格式族，文件200包括分别包含在独立框中的媒体数据和元数据，其中独立框是媒体数据(mdat)框210和电影(moov)框220。对于可操作的文件而言，必定存在这两个框。媒体数据框210包含视频和音频帧，其可以是交织的和按时间顺序的。电影框220可以包含一个或多个轨道，并且每个轨道驻留在一个轨道框240中。轨道可以是下述类型之一：媒体、提示(hint)或者定时元数据。媒体轨道指的是根据媒体压缩格式格式化的采样(以及其到ISO基本媒体文件格式的封装)。提示轨道指的是提示采样，包含用于构造通过指示的通信协议传输分组的指南手册(cookbook)指令。该指南手册指令可以包含针对分组报头构造的指导，并且包括分组净荷构造。在分组净荷构造中，驻留在其他轨道或项目中的数据可以被参考(例如，参考可以指示特定轨道或项目中的哪段数据被命令在分组构造过程期间复制到分组)。定时元数据轨道指的是描述所参考的媒体和/或索引采样的采样。针对一种媒体类型的演示(presentation)，通常选择一个轨道。
此外，轨道的采样隐性地与采样号相关联，该采样号以指示的采样解码顺序以1递增。因此，轨道中的第一采样可以与采样号“1”相关联。应该指出，此类假设影响某些方程式，但是本领域的技术人员将理解针对采样号码(例如采样号码“0”)的其他“开始偏移”来相应地修改这些方程式。
应该指出，ISO基本媒体文件格式不限制将演示包含在仅一个文件中。事实上，演示可以包含在若干文件中。在该情况中，一个文件包含针对整个演示的元数据。该文件还可以包含所有的媒体数据，在该情况中，该演示是自包含的。如果使用其他文件，则不必根据ISO基本媒体文件格式格式化该其他文件。其他文件用于包含媒体数据，并且它们还可以包含未使用的媒体数据或者其他信息。ISO基本媒体文件格式仅与包含元数据的文件的结构有关。媒体数据文件的格式仅受ISO基本媒体文件格式或其派生格式的约束，其中约束仅在于媒体文件中的媒体数据必须被格式化为ISO基本媒体文件格式中指定的格式或其派生格式。
在将内容记录到ISO文件时可以使用电影片段，以便如果记录应用崩溃、盘被用完、或者某个其他事故发生时避免丢失数据。在没有电影片段的情况下，可能发生数据丢失，因为文件格式坚持所有的元数据(电影框)被写在文件的一个连续区域中。此外，当记录文件时，由于可用的存储装置的大小，可能没有足够数量的RAM来缓存电影框，并且在电影结束时重新计算电影框的内容太慢。而且，电影片段可以使用常规的ISO文件解析器来实现同步地记录和回放文件。最后，针对渐进下载，要求较小的初始缓存持续时间(例如，当电影片段被使用并且初始的电影框比具有相同媒体内容但在没有电影片段下构造的文件要小时，同时接收和回放文件)。
电影片段特征能够将常规而言驻留在moov框220中的元数据划分成多个块，每个块对应于轨道的一定时间段。因此，电影片段特征能够实现文件元数据和媒体数据的交织。因此，moov框220的大小可以被限制，并且实现上述的使用情形。
针对电影片段的媒体采样驻留在mdat框210中，如果它们在与moov框相同的文件中，则通常是这样。然而，针对电影片段的元数据，提供moof框。其包括针对回放时间中的某段持续时间的信息，该信息先前已经在moov框220中。moov框220仍然自己表示有效的电影，但是另外，其还包括mvex框，该mvex框指示同一文件中将跟有电影片段。电影片段在时间上扩展了关联到moov框的演示。
可以包括在moof框中的元数据限于可被包括在moov框220中的元数据的子集，并且在某些情况下被不同地编码。可以被包括在moof框中的框的详细情况可以从ISO基本媒体文件格式规范ISO/IEC国际标准14496-12第二版2005-04-01(包括修订1和2)中找到。
除了定时轨道之外，ISO文件还可以在元框(meta box)中包含任何非定时二进制对象，或“静态”元数据。元框可以驻留在电影框中以及在轨道框中的文件的顶层。文件层、电影层、或者轨道层中的每个处可以出现最多一个元框。需要元框来包含‘hdlr’框，该hdlr框指示“元”框内容的结构或格式。元框可以包含任何数目的二进制项目，所述项目可以被参考并且它们中的每个可以与文件名关联。
为了在层级的任一层(文件、电影或轨道)支持多于一个的元框，已经在ISO基本媒体文件格式中引入了元框容器框(“meco”)。元框容器框可以在层级的任一层(文件、电影或轨道)携带任何数目的附加元框。这允许例如同样的元数据出现在两个不同的、替换的元数据系统中。元框相关框(“mere”)支持描述不同的元框如何涉及彼此(例如，它们是否包含完全相同但是用不同的机制描述的元数据，或者是否一个表示另一个的超集)。应该指出，在针对ISO基本媒体文件格式的最新“Technologies under Consideration”文档(MPEG文档N9378)内，不再需要二进制项目位于元框内。反之，二进制项目可以驻留在文件中的任何处，例如，驻留在mdat框中，并且还可以驻留在第二文件内。
图3和图4示出了在框中的采样群组的使用。ISO基本媒体文件格式和其派生(诸如AVC文件格式和SVC文件格式)中的采样群组是基于群组规则将轨道中的每个采样分配为一个采样群组的成员。采样群组中的一个采样群组不限于连续的采样，并且可以包含非相邻的采样。因为针对轨道中的采样可能存在多于一个的采样群组，每个采样群组具有类型字段以指示群组的类型。采样群组通过以下两个链接的数据结构来表示：(1)SampleToGroup框(sbgp框)表示采样到采样群组的分配；以及(2)SampleGroupDescription(采样群组描述)框(sgpd框)包含针对每个采样群组的采样群组项目，其描述了该组的属性。基于不同的群组准则，可以存在SampleToGroup和SampleGroupDescription框的多个实例。这些通过类型字段来区分，类型字段用于指示群组的类型。
图3提供了指示用于采样群组框的嵌套结构的简化框层级。采样群组框(SampleGroupDescription框和SampleToGroup框)驻留在采样表(stbl)框中，其被包括在电影(moov)框内的媒体信息(minf)框、媒体(mdia)框和轨道(trak)框(以该顺序)中。
SampleToGroup框被允许驻留在电影片段中。因此，采样群组可以逐个片段地进行。图4图示出包含电影片段的文件的例子，该电影片断包括SampleToGroup框。
数字视频广播(DVB)组织当前正处于指定DVB文件格式的进程中。定义DVB文件格式的主要目的在于使DVB技术实现之间的内容互操作性更容易，DVB技术实现诸如是根据当前(DVB-T、DVB-C、DVB-S)和未来DVB标准的机顶盒、因特网协议(IP)电视接收机和根据DVB-手持(DVB-H)和其未来演进的移动电视接收机。DVB文件格式促进在终端侧存储所有DVB文件，并且其目的在于互换格式以确保兼容的DVB设备之间的互操作性。然而，应该指出，DVB文件格式目的不必在于用于DVB兼容设备的内部存储格式，尽管DVB文件格式应该能够处理正在由其他DVB广播规范使用的各种类型的媒体和数据。在DVB文件格式规范的需求收集阶段过程中，就DVB文件格式将提供对于以下媒体格式的支持达成了一致：H.264；移动图片和电视工程师协会(SMPTE)421M视频编解码器(VC-1)；高级音频编码(AAC)，高效(HE)-AAC，HE-AACv2；音频码3号(AC-3)，AC-3+；自适应多码率-宽带加(ARM-WB+)；如由DVB-H上的IP广播使用的定时文本；非A/V内容；字幕；同步辅助数据；交互应用；和数据。
此外，应该指出，DVB文件格式将允许在来自于不同制造商的设备间交换记录的(例如，只读)媒体，其中DVB文件格式将从ISO基本媒体文件格式中导出。此类内容交换例如可以包括使用USB大容量存储器和/或类似的读/写设备，以及对于归属网络上公共的盘存储设备的共享访问、以及其他功能。
DVB文件格式的关键特征被称为接收提示轨道，其可以在按照DVB文件格式记录一个或多个分组数据流时使用。接收提示轨道指示所接收的分组的顺序、接收定时和内容以及其他。用于DVB文件格式的播放器可以基于接收提示轨道重建过去接收到的分组流，并且处理该重建的分组流，就仿佛它是刚刚接收到的那样。接收提示轨道具有与服务器的提示轨道相比相同的结构，正如ISO基本媒体文件格式中所规定的那样。例如，接收提示轨道可以通过‘hint(提示)’类型的轨道参考链接到它们所携带的基本流轨道(即，媒体轨道)。传递媒体流的每种协议具有其自身的接收提示采样格式。
使用接收提示轨道作为用于发送所接收的流的提示的服务器应该温和地处理所接收的流的潜在的降级，诸如传输延迟抖动和分组丢失，并且无论所接收的流是否存在潜在的降级都确保遵守协议限制和包含的数据格式。
接收提示轨道的采样格式可以支持通过借助参考从其他轨道拉出数据来构建分组。这些其他轨道可以是提示轨道或者媒体轨道。这些指针的精确格式由协议的采样格式限定，但是一般它们包括四种信息：轨道参考索引、采样号、偏移以及长度。这些信息中的某些在具体的协议中可能是隐性的。这些“指针”总是指向实际的数据源。如果一个提示轨道是建立在另一个提示轨道的顶上，则第二个提示轨道必须具有指向供第一轨道使用的媒体轨道的直接参考，其中来自那些媒体轨道的数据被放置在流中。
将所接收的流转换到媒体轨道允许服从ISO基本媒体文件格式的现有播放器处理DVB文件，只要媒体格式也得到支持。然而，大多数媒体编码标准仅规定了对无错流的解码，并且因此应该确保媒体轨道中的内容能够被正确地解码。针对DVB文件格式的播放器可以利用接收提示轨道来处理传输引起的降级，即可能没有正确解码的内容仅位于接收提示轨道中。通过借助参考将来自媒体轨道的数据包括进接收提示轨道，可以不需要在媒体轨道和接收提示轨道二者中都复制正确媒体采样。
当前，规定了两种类型的接收提示轨道：MPEG-2传送流(MPEG2-TS)以及实时传送协议(RTP)接收提示轨道。MPEG2-TS接收提示轨道的采样包含MPEG2-TS分组或者指令，用以根据针对媒体轨道的参考来构成MPEG2-TS分组。MPEG-2传送流是对音频和视频节目基本流以及一些元数据信息的复用。其还可以包含若干音视频节目。RTP接收提示轨道表示一个RTP流，通常是单个媒体类型。
RTP被用于基于因特网协议(IP)在网络中传输连续的媒体数据，诸如编码的音频和视频流。实时传送控制协议(RTCP)是RTP的伙伴，即当网络和应用基础结构允许，则应该总是使用RTCP来补充RTP。RTP和RTCP通常运送在用户数据报协议(UDP)上，继而UDP运送在因特网协议(IP)上。存在两种版本的IP，IPv4和IPv6，其通过可寻址的端点数目以及其他来区分。RTCP被用于监视网络提供的服务质量，并且用于运送关于正在进行的会话的参与者的信息。RTP和RTCP被设计用于从一对一通信到几千个端点的大型多播群组范围的会话。为了控制多方会话中的RTCP分组引起的总的比特率，由单个端点传输的RTCP分组的传输间隔正比于会话中的参与者的数目。每个媒体编码格式具有特定的RTP净荷格式，其规定了媒体数据如何在RTP分组的净荷中被结构化。
针对DVB文件格式的元数据要求可以基于元数据类型被归类成四组：1)采样特定的定时元数据，诸如演示时间戳；2)索引；3)分段的元数据；以及4)用户书签(例如，内容中的最喜欢的位置的用户书签)。
采样特定定时元数据的示例是演示时间戳。可以存在不同的时间线来指示采样特定的定时元数据。时间线无需覆盖所记录的流的整个长度并且时间线可以被暂停。例如，在示例情况中，可以在电影的最终编辑阶段创建时间线A。稍后，服务提供商可以插入商业广告并且为商业广告提供时间线B。结果，在商业广告正在进行时，时间线A可以被暂停。时间线还可以在内容本身被传输之后进行传输。时间线采样携带机制在欧洲电信标准协会(ETSI)技术规范(TS)102 823“Specification for the carriage of synchronized auxiliary data”中指定。根据该规范，时间线采用可以携带在MPEG-2节目基本流(PES)中。PES运送基本的音频或视频比特流，并且因此，时间线与音频和视频帧精确地同步。
索引可以包括例如视频访问点和轨道模式支持(例如，快速前进/后退，慢动作)。这样的操作可能需要例如对可以自解码的图片的指示、解码开始点以及对参考和无参考图片的指示。
在分段的元数据的情况下，DVB服务可以利用根据特定的元数据机制(诸如广播内容指南(BCG)、TV-Anytime(TV-任何时间)、或者针对IP数据播放(IPDC)的电子服务指南(ESG))的服务指南来描述。该描述可以仅应用到流的一部分。因此，文件可以具有若干个描述性的段(例如，关于节目的特定段的描述，诸如“Holidayin Corsica near Cargese”)信息。
另外，需要DVB文件格式的元数据和编制索引的结构是可扩展的，并且需要支持用户定义的索引。
已经提出了用于执行编制位标和实现分段的元数据的各种技术，其例如包括定时元数据轨道、采样群组、DVBIndexTable(DVB索引表)、虚拟媒体轨道以及采样事件和采样特性。关于定时元数据轨道，创建一个或多个定时元数据轨道。轨道可以包含特定类型的索引或可以包含任何类型的索引。换言之，采样格式将支持不同索引类型的复用。轨道还可以包含一个节目(例如，多节目传送流的)或多个节目的索引。另外，轨道可以包含一个媒体类型或多个媒体类型的索引。
关于采样群组，一个采样群组类型可以专用于每个索引类型，其中相同数量的采用群组描述索引包括在Sample Group Description框中，因为对于特定索引类型存在不同值。Sample to Group框用于将采样与索引值相关联。采样群组方法可以与定时元数据轨道一起使用。
关于DVBIndexTable，提出了将称为DVBIndexTable框的新框引入到Sample Table框中。DVBIndexTable框包含条目的列表，其中每个条目通过其采样号与接收提示轨道中的采样相关联。每个条目进一步包括关于索引准确度，其关注多节目MPEG-2传送流中的哪个节目、其对应于哪个时间戳以及索引的值的信息。
关于虚拟媒体轨道，已经提出将通过参考接收提示轨道的采样数据从接收提示轨道组成虚拟媒体轨道。因此，用于媒体轨道的索引编制机制(诸如sync采样框)可以间接地用于接收的媒体。
最后，关于采样事件和采样特性技术，已经提出这些技术用于克服采样群组的两个固有缺点(当它们用于索引编制时)。第一，Sample to Group(采样至群组)框使用行程编码来将采样与群组描述索引相关联。换言之，提供映射至相同群组描述索引的连续采样的数量。因此，为了根据绝对采样数来解决群组描述索引，计算连续采样计数的累积和。此类计算对于某些实现而言可能是计算负担。因此，提出的技术在Sample to Event(采样至事件)以及Sample to Property(采样至特性)框中使用绝对采样数(对应于Sample to Group框)而不是使用行程编码。第二，Sample Group Description(采样群组描述)框驻留在Movie框中。因此，在记录开始时必须知道索引值(对于所有索引类型这可能是不可能的)或者在记录期间必须不断地更新Movie框以响应新的索引值。对Movie框的更新因此可能需要移动文件内的其他框(诸如mdat框)，这可能是慢的文件操作。提出的Sample to Property框包括特性值字段，其实际携带索引值，并且可以驻留在每个电影片段中。因此，原始Movie框无需因为新的索引值而更新。
根据广播和移动服务(CBMS)群组的融合，DVB-CBMS工作正在进行以定义用于DVB-H上的IP数据广播的通知框架。希望该通知框架支持通知消息的递送，因此只要发生了重要事件就向接收机和用户进行通知。通知消息可以与某些音频/可视(A/V)内容同步或者可以是独立服务。例如，同步的通知消息可以描述涉及某些A/V服务的事件，例如，针对投票或上下文广告的请求。独立通知服务例如可以备选地携带按照某些标准进行归组但不涉及A/V服务的通知消息。独立通知服务的一个示例是递送股价的股市行情记录器。
此外，通知服务可以被设置为默认或可以由用户选择。默认通知消息可能对于所有接收机而言都是感兴趣的，因此，可能希望自动接收默认通知消息，例如紧急通知服务。备选地，用户选择的通知消息例如可以仅在用户选择时被接收。根据通知服务的类型，通知消息的递送可以不同。
这里更详细地描述了通知消息的传送机制。诸如图5中500示出的通知消息可以由多个部分组成。第一部分可以称为通用消息部分510，例如可扩展标记语言(XML)片段，其包含关于通知消息的通用信息并且由通知框架消费。另一部分可以称为应用特定消息部分520，例如包含描述通知消息内容的信息的片段(通常是XML格式)。此外，应用特定消息部分可以由能够处理通知消息的应用特定部分的应用来消费。又一部分可以称为媒体对象，诸如组成通知消息一部分的一个或多个音频/剪辑530和一个或多个视频/剪辑540。
应该指出在通知消息的生命期期间，可以分别递送其一部分和对这些部分的更新。备选地，某些未改变的部分可以完全忽略。一个示例是携带用于使接收机获取其他消息部分的命令的通知消息，其中一段时间后，通知消息的更新指示将启动之前抓取的通知消息。然而，可以通过使用多部分/相关多用途因特网电子邮件扩展(MIME)封装将通知消息的所有部分作为单个传送对象来递送。该封装支持将多个通知消息聚合在单个通知消息中，而仍旧提供对每个单个消息的独立访问。
两个不同的传送协议可以用于通知消息的递送/传送，例如RTP和FLUTE。FLUTE可以用于非同步和默认通知消息的递送，而RTP可以用于同步、服务相关通知消息的递送。备选地，可以使用RTP和FLUTE的组合，其中可以使用FLUTE传送通知消息的大块净荷(即，应用特定消息部分和媒体对象，如果有的话)，而例如使用RTP仅递送通知消息的通用消息部分。
对于RTP递送而言，定义RTP净荷格式报头以指示重要信息，该重要信息支持对通知消息的修正处理和提取。而且，RTP净荷格式报头也允许基于例如通知消息的通知类型来过滤通知消息。此外，RTP净荷格式报头提供用于对超过最大传输单元(MTU)大小的通知消息进行分段和重组的功能。
定义了对FLUTE的文件递送表(FDT)的类似扩展，从而提供对选择通知消息所需的信息字段的标识和快速访问。继而可以封装通知消息部分并且将其作为单个传送对象或独立的传送对象来携带。通用通知消息部分通常可以提供组成相应通知信息的消息部分的列表。这将支持通知框架以获取通知消息的所有部分并且使它们可用于消费通知应用。对媒体对象的参考以及对使用它们的方式的描述通常由应用特定消息部分提供。然而，由于通知框架不读取应用特定消息部分，所以如果通知框架没有认识到待获得的所有消息部分，则可能发生针对重构通知消息的显著延迟。
通知对象的生命周期通常如下，其中通知对象在终端中创建，作为与特定统一资源标识符(URI)相关联的通知消息的响应。终端维持包括以下状态的、针对通知对象的状态机。“缺席”是对象的初始状态，并且一旦已经将该对象从系统(完全)移除，其还是最终状态。这是对象可以无限持续的仅有状态。没有定时器与该状态相关联，并且因此，从该状态到任何其他状态的变迁意味着加载该对象。
“加载”是已经将对象加载(预抓取)到系统中但是其还未被激活或未针对未来的某个时间对激活进行编程的状态。应该指出，如果已经接收到立即激活动作，但是尚未完全执行该激活，例如在等待应用开始时，则对象也将停留在该状态中。生命期计数器在该状态期间连续递减，并且在生命期流逝时移除该对象。
“等待”表示这样一种状态，其中当已经加载对象并且已经接收到针对未来某时激活的动作时，该对象正在等待(并且停留在该状态直到完成激活，例如启动应用)。在该等待状态中，将launch time参数与某些外部时间参考(例如，相关联的视频流的RTP演示时间戳)连续进行比较。传统上，当已经到达或超过希望的launch time时，对象变迁到活跃状态。例如，如果在传输期间启动动作发生延迟，则这可能是立即出现的情况。而且，到其他状态的变迁可以由合适的动作触发。此外，生命期计数器在该状态期间连续递减，并且在生命期流逝时移除该对象。
“活跃”表示当已经加载对象并且其变为活跃时的状态。在该活跃状态期间，活跃时间计数器和生命期计数器两者都连续递减。活跃时间的流逝触发回到加载状态的自动变迁(但是对象保持存在)。生命期的流逝将该对象从系统中完全移除(例如，触发到缺席状态的变迁)。
通知对象生命周期状态之间的变迁由如上所述的动作触发。这些动作可以通过通知消息的接收(显性的和隐形的)来发起，或在一定时间之后自动触发。不同的动作将在下面结合由这些动作传送到对象的所提议参数来讨论。
“抓取”表示这样一种动作，其中当抓取对象时，需要确定其希望的生命期(直到移除)(例如，默认值)。还可以将生命期给出为相对值(从抓取到自动移除)，或给出为绝对值(全局时间中的死亡时间)。应该指出，准确度不是关键，因为提供商应该提供足够的误差边限。一旦抓取了对象就应该确定希望的活跃时间。尽管利用启动动作传送该参数在原理上是可能的，但是这可能会浪费带宽，因为在活跃时间期间需要定期重复启动动作。应该指出，这指的是显性抓取和隐性抓取(例如，当接收到针对尚未加载对象的启动动作时触发抓取动作)。
“启动”表示启动对象时的动作。当启动对象时，定义了最大活跃时间。由于为了处理非最佳接收或稍后的信道切换，启动消息(触发)将重复，所以在每个启动消息中不重复活跃时间(即，活跃时间从抓取中是已知的)以节省带宽。活跃时间的分辨率应该小于一秒。启动动作可以立即生效(例如，尽可能快(asap))，或当已经到达动作中指示的启动时间时生效。因此，需要启动时间与某些时间参考(取决于传送机制，例如，当RTP时间戳的演示时间超过指示的启动时间时)之间的比较。
“取消”表示可以通过特定通知消息(或触发)触发的或当定时器到期触发了解激活时的动作。出于该原因，取消动作通常不携带其他参数(例如，取消动作将不修改生命期)。
“移除”是可以通过特定通知消息(或触发)触发的动作，其中在大部分情况下，在给定时间后将移除对象。这结束了对象的生命，因此不传输参数。“更新”表示可以用于允许对现有对象的生命期或活跃时间进行更新的动作。然而，这不是必需的，因为更新可以由特殊更新命令直接触发或通过接收抓取和启动动作的修改参数来触发。
为了管理生命周期状态之间的自动变迁，每个对象都需要以下的定时器：活跃时间；和生命期。剩下的活跃时间是直到自动取消为止的预期时间。其被初始化为从对象活跃到取消的相对时间，分辨率是毫秒。剩余的生命期表示直到对象自动取消为止的预期时间。其从“remove time(移除时间)”参数被初始化为目标加载时间处的相对时间，分辨率为秒。其中可以从加载对象时刻的绝对时间值或从相对时间值来完成初始化。
图6中示出了通知对象的生命周期图(又称为状态机)。参考“时间”的动作，例如“流逝的生命期”602、“实际时间≥启动时间”604、“设置生命期+活跃时间”606以及“流逝的活跃时间”608指示变迁是否可以由定时器之一触发。从缺席状态610到加载(存储)状态612的“抓取”变迁和从缺席状态610到等待状态614的“隐性抓取”(和启动)变迁也将将两个定时器设置为它们的初始值(如上所述)。这是利用变迁侧的框606指示的。对于不产生变迁(即，分别发生在加载状态和活跃状态612和616中)的“抓取”动作而言，存在两个可能的行为：两个定时器都被设置为它们的初始值或对定时器不存在影响。应该指出，利用空框618指示这些变迁。两个选择都导致有效图。短暂的“等待”状态614指示已经接收了启动动作，但是显示对象的激活直到启动时间。对象保持在一个状态中直到满足允许变迁到任何其他状态的所有条件，例如，直到在已经触发(隐性)抓取动作并且已经完全加载该对象时或在其之前，将不离开初始状态“缺席”610。该规定允许相对简单的生命周期图而不增加变迁状态，诸如“抓取对象”或“启动应用”。
图7示出了参考(隐性和显性)动作的通知对象生命周期的简化示例以及在这两种情况中通知对象的最终生命周期。第一情况/通知对象由上线700表示，例如针对处于最佳接收条件中的终端的情况/通知对象，而下线710表示第二情况/通知对象，例如针对仅在有限时间期间接收通知的终端的情况/通知对象(阴影区域720)。
在第一情况中，在抓取动作730处尽可能快地加载通知消息，例如，如果该通知对象是圆盘传送式的，则抓取动作730是隐性的。在接收到多个启动通知734-738的第一“启动”通知732时，将其激活。激活的时刻可以基于通知的接收，或者通知可以指示与伴随的音频可视流相关的激活时刻。然后，分别通过显性动作740和742解激活并且卸载对象。
在第二情况中，仅当对象已经被激活时，终端可以切换到频道。终端接收活跃消息并且在736处加载(例如，从圆盘传送或通过交互链路)，并且立即激活该对象。此时，提供足够的信息以去除对象，即使在通信中断时。因此，对象的解激活在动作744之后的某时间处由定时器激活(在其已经激活预定时间之后)。最后，在生命期计数器已经到期时746移除通知对象。
不论是否是服务相关的，通知消息组成向用户提供的服务的重要组件。通知消息的存储对于用户是重要的，因为其支持在某些稍后的点处对服务的全功能消费。保留通知消息的时间线也是重要的。然而，通知消息可以具有有限的生命期，例如投票请求可以仅在相关TV节目期间是有效的。其继而取决于用于在延迟回放期间用于过滤掉那些消息的应用。
图8是可以在其中实现本发明的各种实施方式的通用多媒体通信系统的图示。如图8所示，数据源800以模拟、未压缩数字、或压缩数字格式或这些格式的任意组合提供源信号。编码器810将源信号编码成已编码媒体比特流。应该指出，可以从位于实际上任何类型的网络内的远程设备直接或间接地接收待解码的比特流。编码器810能够对多于一个的媒体类型(诸如，音频和视频)进行编码，或者可能需要多于一个的编码器810以对源信号的不同媒体类型进行编码。编码器810还可以得到合成产生的输入，诸如图形和文本，或者其能够产生合成媒体的已编码比特流。在下文中，仅考虑对一个媒体类型的一个已编码媒体比特流进行处理，以便简化描述。然而，应当注意的是，通常实时广播服务包括若干流(通常，至少一个音频、视频和文本字幕流)。还应当注意的是，系统可以包括很多编码器，但是在图8中，不失一般性地，仅示出了一个编码器810，以简化描述。还应该理解，尽管文本和包含于其中的示例可以具体描述编码过程，但是本领域的技术人员应该理解，相同的概念和原理也用于相应的解码过程，反之亦然。
已编码媒体比特流传输至存储设备820。存储设备820可以包括任何类型的海量存储器，以存储已编码的媒体比特流。存储设备120中已编码媒体比特流的格式可以是基本自包含的(elementary self-contained)比特流格式，或者一个或多个已编码比特流可以封装至容器文件中。某些系统“直播”操作，即，省略存储设备，而直接将已编码媒体比特流从编码器810传输至服务器830。已编码媒体比特流随后传输至发送器830，根据需要，也称为服务器。在传输中使用的格式可以是基本自包含的比特流格式、分组流格式，或者一个或多个已编码媒体比特流可以封装至容器文件中。编码器810、存储设备820和服务器830可以位于同一物理设备中，或者它们可以包括在单独的设备中。编码器810和服务器830可以利用直播实时内容进行操作，在该情况下，已编码媒体比特流通常不会永久存储，而是在内容编码器810和/或服务器830中缓冲一小段时间，以平滑处理延迟、传输延迟和已编码媒体比特速率的变化。
服务器830使用通信协议栈来发送已编码媒体比特流。栈可以包括但不限于实时传输协议(RTP)、用户数据报协议(UDP)和互联网协议(IP)。当通信协议栈是面向分组的时候，服务器830将已编码媒体流封装至分组中。例如，当使用RTP时，服务器830根据RTP净荷格式将已编码媒体比特流封装至RTP分组中。通常，每个媒体类型具有专用RTP净荷格式。再次需要注意，系统可以包含多于一个的服务器830，但是为了简化，以下描述仅考虑一个服务器830。
服务器830可以或可以不通过通信网络连接至网关840。网关840可以执行不同类型的功能，诸如将根据一个通信协议栈的分组流转译成另一通信协议栈、合并以及分流数据流，以及根据下行链路和/或接收机的能力操纵数据流，诸如控制根据流行的下行链路网络条件控制转发的比特流的比特速率。网关840的示例包括多点会议控制单元(MCU)、电路交换和分组交换视频电话之间的网关、一键通话(PoC)服务器、手持数字视频广播(DVB-H)系统的IP封装器，或者将本地广播传输转发到家庭无线网络的机顶盒。当使用RTP时，网关840被称为RTP混合器或RTP翻译器，并且通常作为RTP连接的端点。
系统包括一个或者多个接收机850，其通常能够接收、解调已传输的信号，以及将其解封装为已编码的媒体比特流。将已编码的媒体比特流传送到记录存储设备855。记录存储设备855可以包括任何类型的海量存储器以存储已编码的媒体比特流。记录存储设备855可以备选地或附加地包括计算存储器，诸如随机访问存储器。记录存储设备855中的已编码媒体比特流的格式可以是基本自包含的比特流格式，或一个或多个已编码媒体比特流可以被封装到容器文件中。如果存在多个彼此相关联的已编码媒体比特流，诸如音频流和视频流，则通常使用容器文件并且接收机850包括或附接至从输入流生成容器文件的容器文件生成器。某些系统“直播”操作，即，省略记录存储设备855并且从接收机850向解码器860直接传送已编码媒体比特流。在某些系统中，仅最近部分的已记录流(例如，已记录流的最近10分钟摘录)保持在记录存储设备855中，而从记录存储设备855中丢弃任何更早的已记录数据。
已编码媒体比特流从存储设备855向解码器860传送。如果存在很多已编码媒体比特流，诸如彼此相关联并且被封装到容器文件中的音频流和视频流，则文件解析器(图中未示出)用于将每个已编码媒体比特流从该容器文件中解封装。记录存储设备855或解码器860可以包括文件解析器，或者该文件解析器附接至记录存储设备855或解码器860。
编解码器媒体比特流通常进一步由解码器860处理，其输出是一个或者多个未压缩的媒体流。最后，呈现器870可以例如通过扬声器或者显示器重现未压缩的媒体流。接收机850、存储设备855、解码器860和呈现器870可以处于同一物理设备中，或者它们可以被包含在单独的设备中。
各种实施方式提供了用于在ISO基本媒体文件中存储通知消息的系统和方法。通知消息何时被存储的不同传输情况在这里被单独解决。应当指出，在这里构思了可以应用各种实施方式的其他传送情况。
在纯RTP传送的第一情况中，RTP接收提示轨道用于存储通知消息。在RTP+FLUTE传送的第二情况中，RTP接收提示轨道用于存储包括通知消息的通用部分的RTP分组并且保留与其他轨道的同步。将通过FLUTE会话参考和获取的通知对象恢复并且存储为由元框参考的静态元数据项目。项目的位置可以在元框或文件的媒体数据框内，或在外部文件内。在纯FLUTE传送的第三情况中，FLUTE接收提示轨道用于保留通知消息的接收定时。备选地，将通过FLUTE会话获取的消息恢复并且存储为由元框参考的静态元数据项目。该静态元数据项目由保留通知消息的接收定时的定时元数据轨道参考。备选地，将通过FLUTE会话获取的消息恢复并存储为保留通知消息的接收定时的定时元数据轨道的采样。因此，这里提供用于将通过RTP递送的通知消息或消息部分链接到通过FLUTE递送的其他通知消息部分的机制。
如上所述，在接收各个通知消息时可以不激活通知对象，但是可以在特定时间将该通知对象调度为激活或由稍后的通知消息触发为激活。因此，对在媒体回放时间线中特定点处哪些通知对象处于活跃做出结论并不是一个直接的处理过程。例如，当在任意回放位置处访问文件时，应该向后遍历通知消息的接收提示轨道以确定随机访问点处和之后所有活跃的通知对象。类似地，当编辑文件时，诸如当从文件的开始处移除采样或连接两个文件时，通知对象的调度激活需要对不同轨道采样直接的依赖性进行认真的调查。因此，这里提供了用于预计算通知对象的生命周期状态时段的机制。该机制基于DVB文件格式的编制索引机制。
在一个实施方式中，将通过FLUTE递送的通知消息部分存储为项目，例如，在媒体数据(“mdat”)框中。该项目由其项目ID以及URI和版本号标识。通知框架将URI用于标识通知消息的一些部分。版本号用于在通知消息的一部分的不同版本之间进行区分。通知消息部分可以在通知消息的生命期期间被更新。为了支持通知消息的正确存储，为每个消息部分指派有版本。
当前，在ISO基本媒体文件格式中，由以下ItemInfoEntry(项目信息条目)框来描述项目：
aligned(8)class ItemInfoEntry
extends FullBox(‘infe’，version＝0，0){
        unsigned int(16)item_ID；
        unsigned int(16)item_protection_index
        string item_name；
        string content_type；
        string content_encoding；//optional
}
在“Technoligies under Consideration for the ISO Base Media FileFormat”文档中，项目由ItemInfoEntry框的修改版本(也称为ItemInfoEntry2)描述如下：
aligned(8)class ItemInfoEntry2
                extends FullBox(‘inf2’，version，0){
                unsigned int(16)          item_ID；
                unsigned int(16)          item_protection_index；
                unsigned int(32)          item_type；     //4CC
                string                                  item_name；
                if(item_type＝＝’mime’){
                        string    content_type；
                        string    content_encoding；          //optional
                }
}
在另一实施方式中，扩展关于项目的信息以指示对包括在项目中的RTP会话(使用轨道ID)和通知消息的部分的版本号的参考。换言之，上述ItemInfoEntry或ItemInfoEntry2结构附加有related_track_ID(相关轨道ID)和version_num(版本号)字段。这些附加字段的存在可以是有条件的并且由ItemInfoEntry或ItemInfoEntry2结构中的标志指示。对RTP会话的参考支持项目(其包含通知消息部分)与使用RTP携带的通知消息部分的唯一关联。如果项目的URI不是全局唯一的，而是在携带它们的通知会话或FLUTE会话的范围内是唯一的，则这特别有用。扩展项目信息条目的附加字段可以定义如下：
unsigned int(32)related_track_ID；
unsigned int(16)version_num；
在又一实施方式中，修改ItemInfoEntry2，从而除了相关轨道的轨道ID和通知消息部分的版本号之外还包含通知消息的URI。修改的ItemInfoEntry2语法如下：
aligned(8)class ItemInfoEntry2
                extends FullBox(‘inf2’，version，0){
                unsigned int(16)          item_ID；
                unsigned int(16)          item_protection_index；
                unsigned int(32)          item_type；     //4CC
                string                    item_name；
                if(item_type＝＝’mime’){
                        string content_type；
                        string content_encoding；        //optional
                }
                if(item_type＝＝’ntfc’){
                        unsigned int(32)related_track_ID；
                        unsigned int(16)version_num；
                        string uri；
}
在又一实施方式中，如上指定ItemInfoEntry2，但是认为item_name(项目名称)包含针对该项目的URI，并且因此，不包括URI字段。然而，应该指出，元数据项目可以包含片段，每个片段都与其自己的URI相关联。因此，在针对Item Information(项目信息)框的项目信息条目中的item_name对于表示项目中存在的所有URI不总是足够的。反而，item_name可以与项目的任何符号名相关联，诸如文件名而不是URI。
在另一实施方式中，称为URI-Version-Item Mapping(URI版本项目映射)框的新框被规定为包括item_ID(项目ID)、URI、related_track_ID(相关轨道ID)和version_num(版本号)字段，而ItemInfoEntry和ItemInfoEntry2保持不变。URI-Version-ItemMapping框可以发生在文件级，即，不包含在任何其他框中。备选地，URI-Version-Item Mapping框可以发生在电影级，即包含在Movie框中。通常，在文件中仅存在一个URI-Version-Item Mapping框。如果不止一个URI-Version-Item Mapping框存在于文件中，则它们各自的信息必须不矛盾。即，项目ID和相关轨道ID的相同对总是针对URI和版本号的特定对相关联，而不论哪个URI-Version-Item Mapping框包括它们。URI-Version-Item Mapping框可以规定如下：
aligned(8)class uriVersionItemMappingBox
                extends FullBox(‘uvim’，version，flags){
                unsigned int(32)entry_count；
                for(i＝1；i＜＝entry_count；i++){
                        unsigned int(16)          item_ID；
                        string uri；
                        if(flags & 1)
                                 unsigned int(16)version_num；
                        if(flags & 2)
                                 unsigned int(32)related_track_ID；
                }
}
参数item_ID规定考虑中的项目。URI字段包含指定项目中存在的URI。应该指出，在通常的情况中，针对单个项目可以存在多个URI，每个针对项目的不同部分。参数version_num规定URI指向的项目的版本。如果version_num不存在，则版本号与URI指向的项目不相关。针对通知消息项目给出参数related_track_ID，其中通用消息部分通过RTP传递。related_track_ID参数通常指向RTP接收提示轨道，该RTP接收提示轨道表示用于通知消息的通用消息部分的RTP流。related_track_ID参数还可以指向定时元数据轨道，该定时元数据轨道包含通知对象的状态改变的索引事件。因此可以随后找到RTP接收提示轨道和用于通知对象状态改变的定时元数据轨道的细节。
向文件存储传入流的接收机操作的一个示例如下，其中接收机接收用户已经选择的音频流和视频流。将这些流作为RTP接收提示轨道进行存储。此外，接收机接收与记录的RTP流相关联的任何同步通知消息(根据ESG中的信息)。包括同步通知消息的通用部分的RTP分组被作为RTP接收提示轨道记录。接收机可以过滤通知消息并且仅向文件存储所需的那些。接收机还接收包含针对所记录RTP流的应用特定部分和媒体对象的那些FLUTE会话。根据FLUTE协议(包括潜在的前向纠错(FEC)解码以纠正传输错误)获取这些对象。应用特定部分和媒体对象作为元数据项目存储在文件中。对于每个新项目，接收机利用新项目信息条目来更新项目信息框，其中该新项目信息条目将项目ID、URI、版本号以及包含通知消息通用部分的轨道彼此联系起来。备选地，接收机可以更新URI-Version-Item Mapping框。
图9中示出了用于根据本发明解析包括所存储通知的传入文件的解析器操作的一个示例。图9示出了在ISO基本媒体文件格式文件900内通过RTP和FLUTE递送的通知消息部分的联系。当解析通知服务的RTP接收轨道940时，接收机根据相同通知消息的通用消息部分来识别对对象的参考(例如URI)。接收机解析“元”框930的项目信息(“iinf”)框932以从“inf2”条目934提取对象的item_ID，针对“inf2”项目934，“inf2”的uri项目匹配于对象的URI。根据其他实施方式，可以使用“inf2”条目934的item_name和version_num字段，或者可以将URI-Version-Item Mapping框用于获得对应于项目938的item_ID，该项目938包含通知消息的应用特定部分和媒体对象。之后，在“iloc”框936中执行查找以找到文件内对象的位置，例如在“mdat”框910中。
在实施方式中，通过FLUTE递送的通知消息作为定时元数据轨道的采样存储。在图10中示出了描述FLUTE会话的对象的不同信息字段之间的联系，图10示出了包含moov框920和“mdat”框1010的文件1000。通过FLUTE递送的每个传送对象作为“mdat”框1010中的独立采样1050存储。采样包括通过FLUTE递送的传送对象并且其由针对元数据轨道的、采样描述框“stsd”1062中的采用条目1064来描述。定义新采样项目格式来扩展MetaDataSampleEntry(元数据采样条目)。ObjectMetaDataSampleEntry(对象元数据采样条目)携带关于传送对象的所需信息。ObjectSampleEntry定义如下。
class ObjectMetaDataSampleEntry()extends MetaDataSampleEntry(‘tome’){string
        content_encoding；//optional
        string mime_format；
}
content_encoding(内容编码)串规定了在参考该采样条目的对象中使用哪个内容编码算法。内容编码算法的示例包括但不限于ZLIB(德国，P.和J-L.Gailly，″ZLIB Compressed Data FormatSpecification version 3.3″，Internet Engineering Task Force RFC 1950，1996年5月)、DEFLATE(德国，P.，″DEFLATE Compressed DataFormat Specification version 1.3″，Internet Engineering Task Force RFC1951，1996年5月)和GZIP(德国，P.，″GZIP file format specificationversion 4.3″，Internet Engineering Task Force RFC 1952，1996年5月)。内容类型规定了参考该采样项目的对象的MIME类型。
参考ObjectMetaDataSampleEntry的采样1050的采样格式可以规定如下。
class ObjectSample(){
        string content_Iocation；
        unsigned int(16)version_number；
        unsigned int(8)transport_object[]；//length determined by sample size
}
这里，content_location(内容位置)串是传送对象的URI的空终止串。version_number(版本号)携带传送对象的版本号。字节数组transport_object(传送对象)是通过FLUTE携带的传送对象。字节数组包含由Sample Size(采样大小)框或Compact Sample Size(紧凑采样大小)框确定的采样的剩余字节，而不论哪个用于该轨道。
上述方法的特定益处在于本质上更容易对读取器进行处理，因为其解封装FLUTE分组以提取FLUTE会话中的文件。而且，通过移除归因于文件圆盘传送或FLUTE中的FEC数据而节省了空间。应该指出，与传送对象相关联的解码时间可以指示传送对象的第一分组或最后分组的接收时间。备选地，其可以示出声明文件的FDT实例的到期时间。
可以“预计算”通知对象生命周期。即，分别处理包括通知RTP流的流或包括通知RTP接收轨道提示的文件的接收机或文件编辑器可以利用可用于DVB文件的任何索引编制机制指示通知对象的状态。特别地，可以利用发生在动作时间处的索引事件来表示定时激活、解激活(又称为取消)以及移除动作。对通知索引的创建可以发生在记录时或作为处理所记录文件时的离线操作。
索引格式的示例如下：
aligned(8)class DVBNotificationIndex extends DVBIndexBox(`idni`){
                unsigned int(6)reserved；
                unsigned int(2)state；
                unsigned int(16)        item_ID；
}
参数“状态”等于0指示通知对象缺席。如果该状态等于1，则其指示加载了通知对象。如果该状态等于2，则其指示通知对象正在等待。如果该状态等于3，则其指示通知对象是活跃的。item_ID指示包含所参考通知对象的通用部分的元数据项目。
索引格式的另一示例如下：
aligned(8)class DVBNotificationIndex extends DVBIndexBox(`idni`){
                unsigned int(6)reserved；
                unsigned int(2)state；
                unsigned int(16)        version_num；
                string uri；
}
在该示例中，如上定义状态。URI字段提供了所参考通知对象的通用部分的URI，而version_num提供了通知对象的版本号。
向文件存储传入流的接收机操作的一个示例如下。接收机接收用户已经选择的音频流和视频流。将这些流作为RTP接收提示轨道存储。此外，接收机接收与记录的RTP流相关联的任何同步通知消息(根据ESG中的信息)。接收机可以过滤通知消息并且仅处理所需的那些。接收机根据包含经处理的通知消息的通用部分的RTP分子中提供的信息来维持针对每个经处理的通知对象的生命周期模型。任何经处理的通知对象的通用部分作为元数据项目存储在文件中。接收机还接收包含经处理的通知消息的应用特定部分和媒体对象的那些FLUTE会话。根据FLUTE协议(包括潜在的前向纠错(FEC)解码以纠正传输错误)获取这些对象。
应用特定部分和媒体对象作为元数据项目存储在文件中。对于每个新项目，接收机利用新项目信息条目来更新项目信息框，该新项目信息条目将项目ID、URI、版本号以及包含通知消息通用部分的轨道彼此联系起来。接收机还创建索引(诸如定时元数据轨道中的采用)以表示通知对象的状态改变。特别地，接收机在以下时间处创建索引事件：通知消息分组触发状态立即改变的任何时间；以及当状态改变由定时器触发时，即，当实际时间已经到达通知对象的启动时间时；当通知对象的活跃时间已经到期；或者当通知对象的生命期已经到期。
这里还描述了文件处理的一个示例。该处理将以下文件作为输入，该文件包括用于通知消息的通用部分的RTP接收提示轨道以及用于通知消息的应用特定部分和媒体对象的元数据项目(创建此类文件的接收机如上所述)。该处理输出文件，在该文件中，已经预计算了通知对象的状态。该处理实际上从输入文件向输出文件复制用于媒体流的任何媒体轨道和接收提示轨道以及相关的文件元数据。此外，该处理根据包含经处理的通知消息的通用部分的RTP分组中提供的信息来维持每个通知对象的生命周期模型。此外，该处理将任何经处理的通知对象的通用部分作为元数据项目存储在文件中。
对于每个新项目，该处理利用新项目信息条目来更新项目信息框，其中该新项目信息条目将通知消息的项目ID、URI、版本号互相联系起来。该处理还创建索引(诸如定时元数据轨道中的采样)以表示通知对象的状态改变。特别地，该处理在以下时间处创建索引事件：通知消息分组触发状态立即改变的任何时间；以及当状态改变由定时器触发时，即，当实际时间已经到达通知对象的启动时间时；当通知对象的活跃时间已经到期或当通知对象的生命期已经到期。最终，应该指出，无需从输入文件向输出文件复制包含通知消息的RTP接收提示轨道。
根据各种实施方式，可以实现URI-Version-Item Mapping(URI版本项目映射)框的其他用途。应该指出，URI-Version-Item Mapping框不仅能够将通知消息的不同部分彼此联系起来，而且还可以用于例如定位ESG的一些部分。URI通常用作用于将描述性分段的元数据与接收提示采样或媒体采样关联起来的标识符。为了分解描述性元数据的内容，文件解析器必须解决URI指向哪个项目。没有URI-Version-Item Mapping框的情况下，文件解析器可能必须遍历并解析存储在文件中的所有项目。如果URI-Version-Item Mapping框可用，则文件解析器针对URI-Version-Item Mapping框中指出的URI进行定位，并且获得各个项目ID。基于该项目ID，解析器继而使用Item Location(项目定位)框来找到文件内的各个项目。
URI-Version-Item Mapping框的又一用途是参考来自于索引事件的内容项目，其文件格式表示ETSI TS 102 323中规定的TVA_id描述符。TVA_id描述符可以嵌入在例如MPEG-2传送流中。TVA_id描述符指示一个或多个内容项目的运行状态。该运行状态可以是以下之一：还未运行、立刻开始、暂停、运行、取消。
此外，TVA_id描述符利用TVA_id标识内容项目。在内容参考信息(CRI)或TVA元数据中携带的DVB定位符中进行内容项目与特定TVA_id之间的关联。TVA_id在一定时段内在MPEG-2传送流内充当内容项目的本地标识符。因此，URI可以用于代替TVA_id来参考所记录文件内的内容项目，从而避免重用同一TVA_id值，这在两个所记录的文件被连接的情况下尤其可能发生。接收机将与TVA_id所使用的值相关的元数据作为元数据项目存储在文件中，并且将URI与该内容项目关联起来。关联的URI可以是例如内容参考标识符(CRID)，这在ETSI TS 102822-4中对其进行了规定。接收机进一步创建了URI-Version-Item Mapping框，其中将元数据项目的项目ID与相关联的URI进行耦合。对于接收的TVA_id描述符而言，接收机创建相应的索引事件，包括内容项目的运行状态和URI。代替URI，索引事件还可以包含URI-Version-Item Mapping框中对应于URI的条目索引，或者，URI-Version-Item Mapping框中的每个条目可以具有其自身的唯一标识符，其中所述框可以在索引事件中用于参考。而且，代替URI，可以使用诸如TVA_id的任何其他通用标识符，并且在文件中提供通用标识符和item_ID之间的相应映射框。
用于指示运行状态的索引事件可以规定如下：
aligned(8)class DVBIDIndex extends DVBIndexBox(`didi`){
                unsigned int(5)reserved；
                unsigned int(3)running_status；
                unsigned int(32)      entry_index；
}
如上所述，URI-Version-Item Mapping框可以用于各种目的并且URI的名称空间可以不同：在一个实施方式中，允许不止一个URI-Version-Item Mapping框，每个框都具有不同的名称空间或目的，这在框中进行了指示。该实施方式的URI-Version-Item Mapping框可以规定如下：
aligned(8)class uriVersionItemMappingBox
                extends FullBox(‘uvim’，version，flags){
                unsigned int(32)namespace_type；
                if(namespace_type＝＝‘ntfc’)//IPDC notification message
                        unsigned int(32)related_track_ID；
                else if(namespace_type＝＝‘esg‘)//ESG
                        unsigned int(16)esg_info_item_id；
                unsigned int(32)entry_count；
                for(i＝1；i＜＝entry_count；i++){
                        unsigned int(16)item_ID；
                        string uri；
                        if(flags & 1)
                                 unsigned int(16)version_num；
                }
}
namespace_type(名称空间类型)参数规定哪些字段包括在框中，以唯一地标识使用的URI的名称空间。语法示出了两个名称空间类型以对该实施方式进行举例，但是可以概括为包括任何数量的名称空间类型。related_track_ID(相关轨道ID)参数规定了包含通知消息通用部分的轨道，其中该通知消息的URI被包括在该框中。esg_info_item_id指向包含ESG的实例化信息的元数据项目，其还规定了ESG片段的URI的名称空间。
图11是示出了根据各种实施方式执行的、用于向文件存储传入比特流的过程的流程图。应该指出，如上所述的各种实施方式可以执行比包括在图11中那些或多或少的过程。此外，各种实施方式可以在例如接收机处实现，该接收机接收用户已经选择的音频/视频流。在1100，将例如音频流和视频帧的媒体数据存储在诸如ISO基本媒体文件的文件中。媒体数据与元数据的至少第一部分(例如，通知服务/消息)同步，其中元数据的第一部分可以包括包含通知消息通用部分的RTP分组净荷。在1110，元数据的第一部分也存储在文件中。在1120，在文件内指示元数据的第一部分和媒体数据之间的同步。在1130，元数据的第二部分存储在文件内，其中，该第二部分可以包括例如通知消息的应用特定部分和媒体对象(如果存在)。最后，在1140，在文件中指示元数据的第一和第二部分之间的逻辑连接。
图12示出了根据各种实施方式的、解析传入文件/处理传入文件的过程。应该指出，各种实施方式不必限于执行所示的这些过程，因为可以执行更多或更少的过程来实现各种实施方式。在1200，接收机可以接收包括通知消息的文件作为输入。在1210，解析文件以提取与通知消息相关联的通知对象信息。例如，如上所述，文件可以包括针对通知消息通用部分的RTP接收提示轨道以及用于通知消息的应用特定部分和媒体对象的元数据项目。此外，文件的解析可以包括例如标识来自于通用消息部分的针对通知对象的URI并且解析项目信息以提取对应于该通知对象的URI的ID信息。在1220，从输入文件向输出文件复制各种轨道(例如RTP接收提示轨道和媒体轨道)以及来自输入文件的媒体项目。在1230，维持每个通知对象的通知生命周期模型，并且在1240处，将经处理的通知对象的至少第一部分存储在输出文件中作为第一元数据项目。最后，在1250，各种实施方式创建存储到输出文件中的索引以反映通知对象状态改变，并且更新项目信息以将输出文件的URI和元数据项目联系起来，其与该通知对象相关联。应该指出，可以处理不止一个通知消息和/或对象。
这里所描述的各种实施方式支持将通过RTP递送的通知消息部分与通过FLUTE(或某些其他协议，例如超文本传输协议(HTTP))承载的通知消息的其他部分联系起来。各种实施方式的实现可以是通用的，并且允许媒体和提示轨道引用带外递送的对象。而且，各种实施方式提供用于有效存储接收的FLUTE会话的方法。通过提取并存储FLUTE会话的传送对象，可以减少冗余和检索时间两者，而仍旧保留时间线。此外，各种实施方式促进了将通知对象的生命周期再生到文件中而无需解析文件所需的定时器。各种实施方式的此类特征简化了诸如随机访问和文件编辑的操作。
合并并且实现本发明的各种实施方式的通信设备可以使用各种传输技术进行通信，各种传输技术包括但不限于，码分多址(CDMA)、全球移动通信系统(GSM)、通用移动通信系统(UMTS)、时分多址(TDMA)、频分多址(FDMA)、传输控制协议/因特网协议(TCP/IP)、短消息收发服务(SMS)、多媒体消息收发服务(MMS)、电子邮件、即时消息收发服务(IMS)、蓝牙、IEEE 802.11等。在实现本发明的各种实施方式中所涉及的通信设备可以使用各种介质进行通信，包括但不限于无线电、红外、激光、线缆连接等。
图13和图14示出了本发明可以在其中实现的一个代表性电子设备12。然而，应当理解，本发明不旨在限于一种特定类型的电子设备12。图13和图14的电子设备12包括外壳30、液晶显示器形式的显示器32、小键盘34、麦克风36、耳机38、电池40、红外端口42、天线44、根据本发明一个实施方式的UICC形式的智能卡46、读卡器48、无线电接口电路52、编解码器电路54、控制器56和存储器58以及电池80。单独的电路和元件可以是本领域公知的所有类型。
在方法步骤或过程的一般背景下对此处描述的各种实施方式进行了描述，在一个实施方式中，这些方法步骤或过程可以通过计算机程序产品来实现，该程序产品具体化在计算机可读介质中，包括计算机可执行指令，诸如程序代码，其可由联网环境中的计算机执行。计算机可读介质可以包括可移动和非可移动存储设备，其包括但不限于只读存储器(ROM)、随机访问存储器(RAM)、压缩盘(CD)、数字多功能盘(DVD)等。通常，程序模块可以包括例程、程序、对象、部件、数据结构等，其执行特定任务或实现特定抽象数据类型。计算机可执行指令、相关联的数据结构和程序模块代表了用于执行此处公开的方法步骤的程序代码的示例。这种可执行指令或相关联的数据结构的特定序列代表了用于实现在这种步骤或过程中描述的功能的对应动作的示例。
各种实施方式的软件和web实现能够利用具有基于规则的逻辑和其他逻辑的标准编程技术来实现，从而实现各种数据库搜索步骤或过程、相关步骤或过程、比较步骤或过程以及决策步骤或过程。应当注意，此处以及权利要求书中使用的词语“部件”和“模块”意在包括使用一行或者多行软件代码的实现和/或硬件实现和/或用于接收手动输入的设备。
出于例证和描述目的给出关于本发明实施例的上述描述。以上描述并不是穷举性的，并且也没有将本发明实施例局限于所公开的精确形式，并且根据上述教导，各种修改和变化都是可能的，或者说各种修改和变化都可以从实践本发明各种实施例的过程中获取。这里论述的实施例是为了说明本发明各种实施例的原理和特性及其实际应用而被选择和描述的，由此能使本领域技术人员在各种实施例中运用与所设想的特定用途相适应的各种修改来使用本发明。在此描述的实施方式的特征可以以方法、装置、模块、系统和计算机程序产品的全部可能组合来实现。

Claims (49)

1.一种用于组织媒体数据和元数据的方法，包括：
在文件中存储所述媒体数据；
在所述文件中存储所述元数据的第一部分，所述元数据的第一部分与所述媒体数据同步；
在所述文件中指示所述元数据的第一部分相对于所述媒体数据的同步；
在所述文件中存储所述元数据的第二部分；以及
在所述文件中指示所述元数据的第一部分与所述元数据的第二部分在逻辑上连接。
2.根据权利要求1所述的方法，其中所述元数据的第一部分包括实时传输协议分组净荷，所述实时传输协议分组净荷包括通知消息的通用部分，并且其中所述元数据的第二部分包括所述通知消息的应用特定部分与所述通知消息的媒体对象中的至少一个。
3.根据权利要求2所述的方法，其中所述元数据的第一部分在逻辑上包括在所述文件的实时传输协议接收提示轨道中。
4.根据权利要求2所述的方法，其中所述元数据的第二部分存储在所述文件的至少一个元数据项目中。
5.根据权利要求1所述的方法，其中所述元数据的第一部分包括通知对象生命周期模型的状态，并且其中所述元数据的第二部分包括通知消息。
6.根据权利要求5所述的方法，其中所述元数据的第一部分在逻辑上包括在定时元数据轨道中。
7.根据权利要求5所述的方法，其中所述元数据的第二部分存储在所述文件的至少一个元数据项目中。
8.根据权利要求1所述的方法，其中：
文件特定标识符与所述元数据的第二部分相关联；
通用标识符与所述文件特定标识符相关联，所述通用标识符配置为在所述文件中指示所述元数据的第一部分与所述元数据的第二部分在逻辑上连接；以及
在所述文件中指示所述通用标识符与所述文件特定标识符的关联。
9.根据权利要求8所述的方法，其中所述通用标识符是统一资源标识符。
10.根据权利要求8所述的方法，其中：
版本号与所述元数据的第二部分相关联；
所述通用标识符与所述版本号相关联地使用，以便在所述文件中指示所述元数据的第一部分与所述元数据的第二部分在逻辑上连接；以及
在所述文件中指示所述通用标识符和所述版本号与所述文件特定标识符的关联。
11.根据权利要求8所述的方法，其中：
所述元数据的第一部分在逻辑上包括在所述文件的轨道中；以及
所述通用标识符与所述轨道的轨道标识符相关联地使用，以便在所述文件中指示所述元数据的第一部分与所述元数据的第二部分在逻辑上连接。
12.一种包含在计算机可读介质上的计算机程序产品，其配置为执行权利要求1的过程。
13.一种装置，包括：
处理器；以及
存储器单元，其通信地连接至所述处理器并且包括：
配置为在用于组织媒体数据和元数据的文件中存储所述媒体数据的计算机代码；
配置为在所述文件中存储所述元数据的第一部分的计算机代码，所述元数据的第一部分与所述媒体数据同步；
配置为在所述文件中指示所述元数据的第一部分相对于所述媒体数据的同步的计算机代码；
配置为在所述文件中存储所述元数据的第二部分的计算机代码；以及
配置为在所述文件中指示所述元数据的第一部分与所述元数据的第二部分在逻辑上连接的计算机代码。
14.根据权利要求13所述的装置，其中所述元数据的第一部分包括实时传输协议分组净荷，所述实时传输协议分组净荷包括通知消息的通用部分，并且其中所述元数据的第二部分包括所述通知消息的应用特定部分与所述通知消息的媒体对象中的至少一个。
15.根据权利要求14所述的装置，其中所述元数据的第一部分在逻辑上包括在所述文件的实时传输协议接收提示轨道中。
16.根据权利要求14所述的装置，其中所述元数据的第二部分存储在所述文件的至少一个元数据项目中。
17.根据权利要求13所述的装置，其中所述元数据的第一部分包括通知对象生命周期模型的状态，并且其中所述元数据的第二部分包括通知消息。
18.根据权利要求17所述的装置，其中所述元数据的第一部分在逻辑上包括在定时元数据轨道中。
19.根据权利要求17所述的装置，其中所述元数据的第二部分存储在所述文件的至少一个元数据项目中。
20.根据权利要求13所述的装置，其中：
文件特定标识符与所述元数据的第二部分相关联；
通用标识符与所述文件特定标识符相关联，所述通用标识符配置为在所述文件中指示所述元数据的第一部分与所述元数据的第二部分在逻辑上连接；以及
在文件中指示所述通用标识符与所述文件特定标识符的关联。
21.根据权利要求20所述的装置，其中所述通用标识符是统一资源标识符。
22.根据权利要求20所述的装置，其中：
版本号与所述元数据的第二部分相关联；
所述通用标识符与所述版本号相关联地使用，以便在所述文件中指示所述元数据的第一部分与所述元数据的第二部分在逻辑上连接；以及
在所述文件中指示所述通用标识符和所述版本号与所述文件特定标识符的关联。
23.根据权利要求20所述的装置，其中：
所述元数据的第一部分在逻辑上包括在所述文件的轨道中；以及
所述通用标识符与所述轨道的轨道标识符相关联地使用，以便在所述文件中指示所述元数据的第一部分与所述元数据的第二部分在逻辑上连接。
24.一种设备，包括：
用于在文件中存储所述媒体数据的装置；
用于在所述文件中存储所述元数据的第一部分的装置，所述元数据的第一部分与所述媒体数据同步；
用于在所述文件中指示所述元数据的第一部分相对于所述媒体数据的同步的装置；
用于在所述文件中存储所述元数据的第二部分的装置；以及
用于在所述文件中指示所述元数据的第一部分与所述元数据的第二部分在逻辑上连接的装置。
25.根据权利要求24所述的设备，其中所述元数据的第一部分包括实时传输协议分组净荷，所述实时传输协议分组净荷包括通知消息的通用部分，并且其中所述元数据的第二部分包括所述通知消息的应用特定部分与所述通知消息的媒体对象中的至少一个。
26.一种用于处理包括至少一个通知消息的输入文件的方法，包括：
执行以下至少一项：
解析所述输入文件以提取与所述至少一个通知消息的通知对象相对应的信息；以及
产生输出文件，其中已经预先计算了所述通知对象的状态。
27.根据权利要求26所述的方法，其中对所述文件的解析进一步包括解析实时传输协议接收提示轨道，从而根据所述至少一个通知消息的通用消息部分来标识对所述通知对象的引用。
28.根据权利要求26所述的方法，进一步包括确定所述输入文件内所述至少一个通知消息的位置。
29.根据权利要求26所述的方法，进一步包括从所述输入文件向所述输出文件复制轨道和媒体项目。
30.根据权利要求26所述的方法，进一步包括维持用于所述通知对象的通知对象生命周期模型。
31.根据权利要求26所述的方法，进一步包括在处理所述通知对象时，在所述输出文件内将经处理的通知对象的第一部分存储为元数据项目。
32.根据权利要求31所述的方法，其中所述经处理的通知对象的第一部分包括所述经处理的通知对象的通用部分。
33.根据权利要求30所述的方法，进一步包括创建至少一个索引，所述至少一个索引表示对所述通知对象的所述状态的改变。
34.根据权利要求33所述的方法，其中所述至少一个索引在逻辑上连接至定时元数据轨道。
35.根据权利要求33所述的方法，其中所述至少一个索引在逻辑上连接至表示存储在所述输出文件中的媒体数据的采样的至少一个群组。
36.一种包含在计算机可读介质上的计算机程序产品，其配置为执行权利要求26的过程。
37.一种装置，包括：
处理器；以及
存储器单元，其通信地连接至所述处理器并且包括：
配置为执行以下至少一项的计算机代码：
解析包括至少一个通知消息的输入文件以提取与所述至少一个通知消息的通知对象相对应的信息；以及
产生输出文件，其中已经预先计算了所述通知对象的状态。
38.根据权利要求37所述的装置，其中包括配置为解析所述文件的计算机代码的所述存储器单元进一步包括配置为解析实时传输协议接收提示轨道从而根据所述至少一个通知消息的通用消息部分来标识对所述通知对象的引用的计算机代码。
39.根据权利要求37所述的装置，其中所述存储器单元进一步包括配置为确定所述输入文件内所述至少一个通知消息的位置的计算机代码。
40.根据权利要求37所述的装置，其中所述存储器单元进一步包括配置为从所述输入文件向所述输出文件复制轨道和媒体项目的计算机代码。
41.根据权利要求37所述的装置，其中所述存储器单元进一步包括配置为维持用于所述通知对象的通知对象生命周期模型的计算机代码。
42.根据权利要求37所述的装置，其中所述存储器单元进一步包括配置为在处理所述通知对象时，在所述输出文件内将经处理的通知对象的第一部分存储为元数据项目的计算机代码。
43.根据权利要求42所述的装置，其中所述经处理的通知对象的第一部分包括所述经处理的通知对象的通用部分。
44.根据权利要求41所述的装置，其中所述存储器单元进一步包括配置为创建至少一个索引的计算机代码，所述至少一个索引表示对所述通知对象的所述状态的改变。
45.根据权利要求44所述的装置，其中所述至少一个索引在逻辑上连接至定时元数据轨道。
46.根据权利要求44所述的装置，其中所述至少一个索引在逻辑上连接至表示存储在所述输出文件中的媒体数据的采样的至少一个群组。
47.一种设备，包括：
用于执行以下至少一项的装置：
解析包括至少一个通知消息的输入文件以提取与所述至少一个通知消息的通知对象相对应的信息；以及
产生输出文件，其中已经预先计算了所述通知对象的状态。
48.根据权利要求47所述的设备，其中对所述文件的解析进一步包括解析实时传输协议接收提示轨道，从而根据所述至少一个通知消息的通用消息部分来标识对所述通知对象的引用。
49.根据权利要求47所述的设备，进一步包括确定所述输入文件内所述至少一个通知消息的位置。
CN2008801235562A 2007-12-03 2008-12-02 用于以iso基本媒体文件格式存储通知消息的系统和方法 Pending CN101911693A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US99206407P 2007-12-03 2007-12-03
US60/992,064 2007-12-03
PCT/IB2008/003304 WO2009071978A2 (en) 2007-12-03 2008-12-02 Systems and methods for storage of notification messages in iso base media file format

Publications (1)

Publication Number Publication Date
CN101911693A true CN101911693A (zh) 2010-12-08

Family

ID=40468224

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2008801235562A Pending CN101911693A (zh) 2007-12-03 2008-12-02 用于以iso基本媒体文件格式存储通知消息的系统和方法

Country Status (4)

Country Link
US (1) US20100250633A1 (zh)
EP (1) EP2215842A2 (zh)
CN (1) CN101911693A (zh)
WO (1) WO2009071978A2 (zh)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2245769A2 (en) * 2008-02-15 2010-11-03 Nokia Corporation System and method for delivering notification messages
EP2362994A1 (en) * 2008-11-26 2011-09-07 Telefonaktiebolaget L M Ericsson (PUBL) Technique for handling media content to be accessible via multiple media tracks
US10410222B2 (en) * 2009-07-23 2019-09-10 DISH Technologies L.L.C. Messaging service for providing updates for multimedia content of a live event delivered over the internet
CN102577309A (zh) * 2009-09-29 2012-07-11 诺基亚公司 用于动态媒体文件流送的系统、方法和装置
US20110246660A1 (en) * 2009-09-29 2011-10-06 Nokia Corporation Systems, Methods, and Apparatuses for Media File Streaming
KR20120008432A (ko) * 2010-07-16 2012-01-30 한국전자통신연구원 스트리밍 서비스 송/수신 장치 및 방법
US20120213404A1 (en) 2011-02-18 2012-08-23 Google Inc. Automatic event recognition and cross-user photo clustering
US9342599B2 (en) * 2011-05-25 2016-05-17 Thomas Stetson Elliott Methods and systems for centralized audio and video news product collection, optimization, storage, and distribution
US9590814B2 (en) * 2011-08-01 2017-03-07 Qualcomm Incorporated Method and apparatus for transport of dynamic adaptive streaming over HTTP (DASH) initialization segment description fragments as user service description fragments
WO2013105965A1 (en) * 2012-01-12 2013-07-18 Thomson Licensing Method and apparatus for playing a mp4 file container while generating such a file
US20130188922A1 (en) * 2012-01-23 2013-07-25 Research In Motion Limited Multimedia File Support for Media Capture Device Position and Location Timed Metadata
US9391792B2 (en) 2012-06-27 2016-07-12 Google Inc. System and method for event content stream
US9418370B2 (en) 2012-10-23 2016-08-16 Google Inc. Obtaining event reviews
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
US9338117B2 (en) * 2013-09-16 2016-05-10 International Business Machines Corporation Electronic notification systems and methods
US20150187390A1 (en) * 2013-12-30 2015-07-02 Lyve Minds, Inc. Video metadata
CN107710197B (zh) 2015-09-28 2021-08-17 谷歌有限责任公司 在通信网络上共享图像和图像相册
WO2017117266A1 (en) 2015-12-29 2017-07-06 Echostar Technologies L.L.C Dynamic content delivery routing and related methods and systems
GB2560921B (en) 2017-03-27 2020-04-08 Canon Kk Method and apparatus for encoding media data comprising generated content
US10432728B2 (en) 2017-05-17 2019-10-01 Google Llc Automatic image sharing with designated users over a communication network
US11200196B1 (en) 2018-10-10 2021-12-14 Cigna Intellectual Property, Inc. Data archival system and method
US11589032B2 (en) * 2020-01-07 2023-02-21 Mediatek Singapore Pte. Ltd. Methods and apparatus for using track derivations to generate new tracks for network based media processing applications

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0015896D0 (en) * 2000-06-28 2000-08-23 Twi Interactive Inc Multimedia publishing system
US7200627B2 (en) * 2001-03-21 2007-04-03 Nokia Corporation Method and apparatus for generating a directory structure
US20050102371A1 (en) * 2003-11-07 2005-05-12 Emre Aksu Streaming from a server to a client
US20060004699A1 (en) * 2004-06-30 2006-01-05 Nokia Corporation Method and system for managing metadata
KR100927978B1 (ko) * 2005-09-01 2009-11-24 노키아 코포레이션 리치 미디어 콘텐츠의 프로그레시브 다운로딩 및스트리밍을 위해 ｉｓｏ 기반 미디어 파일 포맷으로 ｓｖｇ콘텐츠를 임베딩 하는 방법
WO2007047560A2 (en) * 2005-10-18 2007-04-26 Packetvideo Corp. System and method for controlling and/or managing metadata of multimedia
WO2007080500A1 (en) * 2006-01-11 2007-07-19 Nokia Corporation Extensions to rich media container format for use by mobile broadcast/multicast streaming servers
JP4645498B2 (ja) * 2006-03-27 2011-03-09 ソニー株式会社 情報処理装置および方法、並びにプログラム
US7546486B2 (en) * 2006-08-28 2009-06-09 Bycast Inc. Scalable distributed object management in a distributed fixed content storage system

Also Published As

Publication number Publication date
WO2009071978A3 (en) 2009-09-24
US20100250633A1 (en) 2010-09-30
WO2009071978A2 (en) 2009-06-11
EP2215842A2 (en) 2010-08-11

Similar Documents

Publication Publication Date Title
CN101911693A (zh) 用于以iso基本媒体文件格式存储通知消息的系统和方法
JP5130352B2 (ja) マルチメディアコンテナファイルの受信ヒントトラックに記録するメディアストリーム
JP6441521B2 (ja) 放送システムにおける制御メッセージ構成装置及び方法
US8559788B2 (en) Process for placing a multimedia object in memory, data structure and associated terminal
KR101757306B1 (ko) 방송 신호 송/수신 처리 방법 및 장치
US9043849B2 (en) Method for linking MMT media and DASH media
CN111837403B (zh) 处理用于以流传送媒体数据的交互性事件
KR101143670B1 (ko) 스트리밍된 데이터의 조직화 방법, 컴퓨터 판독가능한 저장 매체, 수신기 및 장치
JP4516082B2 (ja) サーバからクライアントへのストリーミング
JP6258856B2 (ja) 放送システムにおける制御メッセージ構成装置及び方法
KR101885852B1 (ko) 컨텐트 전송 및 수신 방법 및 장치
US20200329284A1 (en) Method, device, and computer program for transmitting portions of encapsulated media content
AU2008320436A1 (en) Fast and editing-friendly sample association method for multimedia file formats
US11356749B2 (en) Track format for carriage of event messages
US7555009B2 (en) Data processing method and apparatus, and data distribution method and information processing apparatus
US7711718B2 (en) System and method for using multiple meta boxes in the ISO base media file format
Hannuksela et al. The DVB File Format [Standards in a Nutshell]

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20101208