将媒体流记录到多媒体容器文件的接收索引轨道中

摘要

公开了一种用于将接收到的实时媒体流存储到多媒体容器文件(1200)中的系统和方法。依照一种提供了用于构造媒体分组的指令的文件格式来将媒体内容记录到文件中。使用用于构造媒体分组的指令来在文件中表示至少一个接收媒体分组。在该文件中，所述至少一个接收媒体分组还与一个表明它有可能包含差错的指示相关联。该技术承载了错误传送的分组易于检测的优点，其被应用以防止中继设备的崩溃。

说明书

技术领域

本发明主要涉及多媒体容器文件格式。具体而言，本发明涉及的是多媒体容器文件格式中的接收索引轨道(hint track)的使用和处理。

背景技术

本节旨在提供权利要求中所述的本发明的背景或上下文。这里的描述可以包括将要实行的概念，但其未必是先前已被构想或实行的概念。因此，除非在这里以别的方式加以指示，否则，本节描述的内容并非本申请的说明书和权利要求书的现有技术，并且不能因为包含在本节之中就承认它们是现有技术。

在多媒体内容的生成、处理、传输和消费链中，多媒体容器文件格式是一个重要因素。在此上下文中，编码格式(即基本流格式)涉及的是用于将内容信息编码到比特流的特定编码算法的动作。容器文件格式包含了一种机制，所述机制用于组织所生成的比特流以使得所生成的比特流可被访问，以用于在本地解码和回放，以及作为文件进行传送或是进行流式传输，所有这些处理都使用了多种存储和传送架构。容器文件格式还可以有助于交换和编辑媒体，以及将所接收的实时流编码成文件。就此而言，编码格式与容器文件格式之间存在很大不同。

在图1的1000处概括描述了多媒体文件格式的层次结构。基本流格式1100代表的是一个单独的独立流。依照基本流格式来构造诸如.amr和.aac文件之类的音频文件。容器文件格式1200是一种可以同时将音频和视频流容纳在单个文件中的格式。关于容器文件格式族1200的示例是以ISO基本媒体文件格式为基础的。处于层次结构1000中的容器文件格式1200下方的是复用格式1300。与依照容器文件格式1200构造的音频/视频(AV)文件相比，该复用格式1300通常不太灵活并且更为紧凑。依照复用格式1300构造的文件通常只用于回放目的。运动图像专家组(MPEG)-2节目流是依照复用格式1300构造的流的一个示例。演示语言格式1400被用于诸如布局、交互、AV与离散媒体的同步等目的。由万维网联盟(W3C)规定的同步多媒体集成语言(SMIL)和可缩放视频图形(SVG)即为演示语言格式1400的示例。演示文件格式1500被表征成在同一个文件中具有所有演示部分。依照演示文件格式构造的对象的示例是PowerPoint文件以及符合3GP文件格式的扩展演示简档的文件。

可用的媒体和容器文件格式标准包括ISO基本媒体文件格式(ISO/IEC 14496-12)、MPEG-4文件格式(ISO/IEC 14496-14，也被称为MP4格式)、高级视频编码(AVC)文件格式(ISO/IEC14496-15)以及3GPP文件格式(3GPP TS 26.244，也被称为3GP格式)。此外，在MPEG中还具有用于发展可缩放视频编码(SVC)文件格式的项目，该项目将成为对高级视频编码(AVC)文件格式的修正。与此同时还在努力的是，MPEG正在定义一种用于在单向文件传输协议(FLUTE)和异步分层编码(ALC)会话上进行文件递送的索引轨道格式，而这将成为对ISO基本媒体文件格式的修正。

数字视频广播(DVB)组织当前正处于规定DVB文件格式的处理中。定义DVB文件格式的主要目的是为DVB技术的实施之间的内容互操作性提供便利，其中DVB技术的实施可以是依照当前(DVB-T、DVB-C、DVB-B)和未来DVB标准的机顶盒、网际协议(IP)电视接收机、以及依照手持DVB(DVB-H)及其未来演进的移动电视接收机。DVB文件格式将允许在来自不同制造商的设备之间交换记录(只读)媒体、使用USB大容量存储器或类似读/写设备来交换内容、共享访问家庭网络上的公共磁盘存储器、以及其他功能。作为开发DVB文件格式的基础，ISO基本媒体文件格式是当前最强的候选。ISO文件格式是所有上面提及的容器文件格式的派生物(除了ISO文件格式本身)的基础。这些文件格式(包括ISO文件格式本身)被称为ISO文件格式族。

ISO基本媒体文件格式中的基本构建块被称为盒(box)。每个盒都包括报头和净荷。盒报头指示盒类型和用字节衡量的盒大小。盒可以封闭其他盒，并且ISO文件格式规定了某种类型的盒内允许哪些类型的盒。此外，某些盒在每一个文件中都是强制存在的，而其他盒则是可选的。另外，对某些盒类型来说，在文件中可存在一个以上的盒。因此，ISO基本媒体文件格式主要规定了盒的层次结构。

图2显示的是一个依照ISO基本媒体文件格式的简化文件结构。依照ISO文件格式族，文件200包括分别封闭在独立盒、即媒体数据(mdat)盒210和电影(moov)盒220中的媒体数据和元数据。对于可操作文件来说，这两种盒都必须存在。媒体数据盒210包括可以被交织和按时间排序的视频和音频帧。电影盒220可以包括一条或多条轨道，并且每条轨道都驻留在一个轨道盒240中。通常，一条轨道被选择以演示一种媒体类型。

应该指出，ISO基本媒体文件格式并未将演示限制成只包含在一个文件中。实际上，演示可以包含在若干文件中。在这种情况下，一个文件包含了用于整个演示的元数据。该文件还可以包含所有媒体数据，在这种情况下，该演示是自包含的。如果使用了其他文件，则不必按照ISO基本媒体文件格式来对这些文件进行格式化。这些其他文件用于包含媒体数据，并且它们还可以包含未使用的媒体数据或其他信息。ISO基本媒体文件格式只涉及包含元数据的文件的结构。媒体数据文件的格式受到ISO基本媒体文件格式或是其衍生格式的限制仅在于：媒体文件必须像ISO基本媒体文件格式或是其衍生格式所规定的那样被格式化。

除了定时的轨道之外，ISO文件还可以在元盒中包含任何非定时的二进制对象。元盒可以驻留在文件顶层、电影盒220内部、以及轨道盒240内部，但在文件级、电影级或轨道级中的每一个级别中至多只出现一个元盒。元盒必需包含“hdlr”盒，由此指示“元”盒内容的结构或格式。该元盒可以包含能够查阅的任意数量的二进制项目，并且每一个二进制项目都可以与一个文件名相关联。

一个文件可以与ISO文件格式族中一个以上的格式兼容，因此并不是始终都可以依照该文件的单个“类型”或“种类(brand)”来陈述。所有ISO文件都包含了文件类型盒，它指示的是哪一种文件格式规定了文件的“最佳应用”以及文件所遵从的一组其他规范。文件的“最佳应用”的格式被称为文件的主种类，而其他兼容格式则被称为兼容种类。

某个种类在文件类型盒的兼容种类列表中的存在性构成了要求权和许可权二者。所述存在性是一个文件符合该种类的所有需求的要求权，并且该存在性还代表了允许读取器仅仅潜在地实施该种类以读取文件的许可权。通常，除非应用了下列步骤之一，否则需要读取器实施针对某个种类所记载的所有特征：

1.读取器正在使用的媒体不使用或不需要某个特征。例如，I帧视频不需要同步采样表，并且如果没有使用复合重排序，则不需要复合时间偏移表。同样，如果不需要内容保护，则不需要对内容保护的结构提供支持。

2.文件所遵从的另一个规范禁止某个特征的使用。举个例子，某些衍生的规范明显禁止使用电影片段。

3.产品工作时所在的上下文意味着某些结构是不相关的。例如，索引轨道结构只涉及为索引轨道中的协议预备内容或执行文件递送(例如流式传输)的产品。

实施某个种类的文件读取器应该尝试读取被标记成与该种类兼容的文件。

索引轨道是一个通常不包含媒体数据的特殊轨道。相反，索引轨道包含了用于封装一个或多个轨道以通过某种通信协议进行递送的指令。发送分组的处理是基于时间的，并且实际上等同于基于时间的数据的显示，因此用轨道来适当地对其进行描述。由于存在索引轨道，因此，发送机的操作负载可以减小，并且发送机的实施可以在没有任何提示的情况下很简单地与来自媒体采样的发送机构造协议数据单元相比较。

ISO基本媒体文件格式包含了用于实时协议(RTP)和安全实时传输协议(SRTP)协议的索引轨道定义，并且即将来临的ISO基本媒体文件格式的第2修改稿将会包含用于FLUTE和ALC协议的索引轨道定义。用于MPEG-2传输流(TS)的索引轨道格式还可以例如作为DVB文件格式的一部分而被规定。

图2中描述的mdat盒包含了用于轨道的采样。在非索引轨道中，采样是单个视频帧、视频帧的时间连续序列，或是音频的时间连续压缩部分。在索引轨道中，采样定义的是依照索引轨道报头中标识的通信协议进行格式化的一个或多个分组的格式。

索引轨道继承了常规媒体轨道的所有特征，例如采样定时和同步采样指示。索引采样包含了用于帮助发送机构成传输分组的指令。这些指令可以包括要发送的即时数据(例如报头信息)或是媒体数据的参考分段。换句话说，媒体轨道中的媒体采样不需要被复制成索引轨道的采样，而是被复制成指向对媒体轨道采样的索引采样。因此，媒体数据自身不需要以任何方式进行重新格式化。与需要将媒体信息划分成针对给定传送和媒体格式进行传送的实际数据单元的方法相比，这种方法的空间效率更高。依照这种方法，本地回放需要重新装配来自分组的媒体，或者具有该媒体的两个拷贝——一个用于本地回放，一个用于传送。类似地，使用该方法通过多种协议的此类媒体传输需要用于每一个递送协议的媒体数据的多个拷贝。除非数据被大量转换来进行传送(例如通过应用纠错编码技术或是通过加密)，否则这种处理的空间效率是很低的。

如果ISO文件包含索引轨道，那么对于引用了媒体数据(根据该媒体数据构建索引)的媒体轨道来说，即使其内的数据并没有被索引轨道直接引用，该媒体轨道也还是保留在文件中。在删除了所有索引轨道之后，整个无索引的演示将会保留。

图3是一般视频通信系统的表示。由于未经压缩的视频需要巨大带宽，因此，源编码器305将输入视频300压缩到预期比特率。源编码器305可以分成两个组件——波形编码器310和熵编码器315。波形编码器310执行有损视频信号压缩，而熵编码器315则将波形编码器310的输出无损地转换成二进制序列。传送编码器320依照所使用的传送协议例如通过交织和调制数据来封装压缩视频。数据经由传输信道325被传送到接收机端。该接收机执行反向操作以获取重新构建的视频信号以供显示。所述反向操作包括使用传送解码器330和源解码器335，以最终获得输出视频350，其中所述源解码器330可以分成熵解码器340和波形解码器345。

大多数现实世界中的信道很容易受到传输差错的影响。传输差错大致可以分成两类——比特差错和擦除错误。比特错误是由在传输信道上出现的物理事件、例如噪声和干扰而引起的。用于实时媒体传送的协议堆栈通常提供了诸如循环冗余校验(CRC)码之类用于检测比特差错的机制。一种常见的实践是在传送解码器中丢弃差错协议净荷。在差错视频数据的解码处理中出现的挑战是突发比特差错的可能性、关于差错位置的准确检测、以及熵编码器使用的可变长度编码(VLC)。由于比特差错的突发性，因此，协议净荷的很大一部分很可能是无论怎样都无法解码的，由此，丢弃整个协议净荷不会导致排除非常不必要的数据。通信协议提供的差错检测机制通常能够产生二元结论——要么分组受到破坏，要么分组是正确的。由此，确定确切的差错位置取决于源编码层机制。即使存在基于语法和语音扰乱以及反常纹理破裂用于检测差错位置的方法，关于比特差错的错误检测也有可能导致对视频进行主观干扰。由于可变长度编码，单个比特差错很可能改变出现该比特差错的那个码字的解释，并且可能导致后续码字失步。即使重新建立了码字同步，解码数据的空间或时间位置也未必能够确定。

就擦除差错而言，此类差错有两个主要来源。首先，路由器之类的拥塞网络部件中的队列溢出导致分组丢失。其次，传送解码器通常通过移除出现了比特差错的整个分组来处理比特差错。

一般来说，接收机首先应该检测到所引入的传输差错，然后则校正或隐藏所述差错。如上所述，通常使用CRC或类似的码来检测比特差错，而受到破坏的分组则会被丢弃。用于实时媒体传送的通信协议通常会附着一个序列号，其中用于所传送的每一个分组的序列号将会逐一递增，由此，可以根据连续分组的序列号值中的间隙检测到分组丢失。差错校正指的是就像在一开始就没有引入差错一样来完美恢复错误数据的能力。差错隐藏指的是隐藏传输错误的影响以使其很难在重新构建的视频中被看到的能力。通常，在源或传送编码中添加了一定量的冗余度，以便在差错检测、纠正和隐藏处理中提供帮助。

差错纠正和隐藏技术可以大致分成三类——前向差错隐藏、借助后期处理的差错隐藏，以及交互式差错隐藏。前向差错隐藏指的是那些由发射机端向发射数据添加冗余度，以使接收机即便在有传输差错的情况下也很容易恢复发射数据的技术。借助后期处理的差错隐藏完全是面向接收机的。这些方法尝试估计接收有误的数据的正确表示。发射机和接收机还可以通过协作来将传输差错的影响减至最小。这些方法大量使用了接收机给出的反馈信息。借助后期处理的差错隐藏也被称为被动差错隐藏，而其他两类则代表的是主动差错隐藏的形式。

与上文介绍的分类相比，差错校正和隐藏算法的正交分类是以所论述的算法工作在其中的协议堆栈层为基础的。物理层中的方法例如可以智能地使用调制或者交织所要传送的数据比特。在链路层，例如可以有选择地重传接收有误的数据块。通常，涉及源编码器或源解码器的方法被称为媒体感知差错纠正和隐藏算法，而仅仅在传送编码器和解码器中操作的方法则是独立于媒体的。需要若干协议堆栈层互操作的方法落入跨层优化算法的类别中。当源和传送编码无缝操作以共同努力处理传输差错时使用术语“联合源-信道编码”。

对很多的实时多媒体通信应用来说，较为理想的是并不是将多媒体文件作为文件来传送，而是将媒体数据封装到通信协议分组中。此外，对于现有媒体播放器来说，较为理想的是能够解析、解码和播放从接收到的媒体流中生成的任何多媒体文件。如果现有媒体播放器能够播放任何被记录的多媒体文件，那么将不再需要更新或更换媒体播放器。

大多数容器文件格式(如果不是全部)的目的是播放那些可靠传送到播放设备的无差错文件，和/或提供用于在流式传输服务器或其他发送设备中传输的媒体内容。因此，容器文件格式没有提供用于指示传输差错的机制，并且无法保证现有播放器能够得体地应对出错的媒体流。取而代之的是，此类播放器有可能会崩溃或者另外以非预期的方式运作。由此，较为理想的是用现有媒体播放器来播放从接收媒体流生成的文件，并且所述文件将与现有文件格式相兼容。此外，对于复杂的播放器和解码器来说，较为理想的是包含用于有效隐藏那些来自将被记录到文件的接收流的传输差错的机制。

已有很多种常规方法能解决如上所述的至少某些问题。在第一个方法中，接收到的传送流本身包含在文件中，或者传输流存储在单个文件中，并且所述单个文件是从演示文件(即，包括元数据的文件)中查阅。在这个方案中，传送流指的是在应用中被认为相关的最低协议堆栈层。对基于RTP的媒体传输来说，传送流通常指的是RTP分组流。在将基本媒体流封装于MPEG-2传送流时(与DVB-T、DVB-C以及DVB-S中一样)，传送流指的是MPEG-2传送流。在ISO基本媒体文件格式结构中，传送流可以作为单个采样包含在媒体轨道中。而这也正是如何将MPEG-2传送流包含在QuickTime文件中的方式。特定于传送流的元数据可以存储在新的文件格式结构中；在ISO基本媒体文件格式中，该结构可以驻留在元盒中。

在第二个方法中，接收到的传送流被转换成基本数据轨道。特定于传送流的元数据被存储在新的文件格式结构中；在ISO基本媒体文件格式中，该结构驻留在元盒中。

在第三个方法中，接收到的流传送分组本身被写入所记录的文件的索引轨道。但是，索引轨道的使用在逻辑上并不是一个有效的解决方案，这是因为索引轨道为服务器或者更一般的是为发送机提供了分组化指令。此外，所记录的索引轨道未必提供有效的重传流。例如，在所发送的流中需要RTP序列号是连续的，但是在所记录的流中，遗漏的分组将会导致RTP序列号不连续。

由于moov盒只能在接收到所有媒体数据之后才能完成，因此，在如上所述的第二和第三种方法中，这种情况将会导致无法连续记录到单个文件。当使用电影片段特征来对所记录的文件进行分段时可以避免这个问题，如在2005年12月1日提交的美国专利申请11/2982,786中描述的那样。作为替换，与元数据相比，接收到的流媒体数据可以记录到单独的文件中。但是，如果期望同时以时间偏移的方式来回放所记录的文件，则应该使用美国专利申请No.11/292,786中描述的电影片段。

发明内容

本发明的各个实施例提供了一种用于接收媒体分组流以及记录媒体内容的系统和方法。该媒体内容依照某种文件格式记录到文件中，其中所述文件格式提供了用于构造媒体分组的指令。使用构造媒体分组的指令来在文件中表示至少一个接收媒体分组。在文件中的至少一个接收媒体分组还与一个表明其可能包含差错的指示相关联。

本发明的各个实施例提供了一种后向兼容机制来将接收到的实时媒体流存储到多媒体容器文件中。在实践中，这意味着现有播放器可以正确地播放接收流的可恢复部分。在接收流中的传输差错的标识和定位被启用，由此，复杂播放器可以有效隐藏传输差错。此外，本发明的各个实施例用于避免所记录的文件中任何媒体数据的重复。本发明的各个实施例可以与近乎所有根据DVB文件格式的接收机结合使用。

从以下结合附图的详细描述中可以清楚了解本发明的这些和其他优点、特征及其操作的组织和方式，其中相同的部件在如下所述的若干附图中都具有相同的数字。

附图说明

图1是多媒体文件格式的层次结构的描述；

图2是ISO文件简化结构的表示；

图3是一般视频通信系统的表示；

图4是与本发明的各个实施例一起使用的通用多媒体通信系统的表示；

图5是示出了根据本发明各个实施例的简化版接收机操作的流程图；

图6是可以与本发明各个实施例的实施方式结合使用的电子设备的透视图；以及

图7是可以包含在图6的电子设备中的电路的示意表示。

具体实施方式

本发明的各个实施例提供了一种用于接收媒体分组流以及记录媒体内容的系统和方法。该媒体内容依照某种文件格式记录到文件中，其中所述文件格式提供了用于构造媒体分组的指令。使用构造媒体分组的指令来在文件中表示至少一个接收媒体分组。在文件中的至少一个接收媒体分组还与一个表明其可能包含差错的指示相关联。

根据本发明的一个实施例，流被记录到文件格式的一个或多个索引轨道，并且在索引轨道中特别表明所述索引轨道是从接收到的流中生成。索引轨道精确对应于接收到的流，由此为媒体播放器提供了尽可能有效地处理传输差错的所有机制。例如，索引轨道的采样结构(即分组结构)包含了分组序列号，从中可以识别遗漏的分组。如果将ISO基本媒体文件格式的RTP索引轨道结构重新用于本发明各个实施例的接收索引轨道，那么该序列号将驻留在RTP分组数据结构的RTP排序语法元素中。

根据本发明的第二实施例，接收到的流被转换成有效媒体轨道，也就是可以在没有非标准化传输差错检测和处理机制的情况下被解码的轨道。创建有效媒体轨道确保了现有媒体播放器能够播放所记录的文件。还创建了一个或多个特定索引轨道。只要可能，索引采样将会包含针对媒体轨道采样的引用而不是分组净荷的拷贝，由此减少对于文件的存储空间需求。

创建有效媒体轨道有时还可以总共省略一些分组。例如，当编码视频流中的参考画面丢失时，媒体轨道应该跳过从所述丢失的参考画面直接或间接预测得到的任何画面。由此，索引采样可能包含了不存在于对应媒体轨道之中的分组净荷的拷贝。

图4是在其中可以实施本发明各个实施例的常规多媒体通信系统的图示。如图4所示，数据源100提供的是采用了模拟、未压缩数字或压缩数字格式，或这些格式的任意组合的源信号。编码器110将源信号编码成编码媒体比特流。应该指出的是，所要解码的比特流可以直接或间接从位于近乎任何类型的网络内部的远端设备接收。此外，该比特流也可以从本地硬件或软件接收。编码器110有可能能够编码一种以上的媒体类型，例如音频和视频，或者有可能需要一种以上的编码器110来编码不同媒体类型的源信号。编码器110还可以获取合成产生的输入，例如图形和文本，或者它有可能能够产生合成媒体的编码比特流。在下文中，为了简化描述，仅仅考虑对一种媒体类型的一个编码媒体比特流的处理。但是应该指出，通常，实时广播服务包含了若干个流(通常是至少一个音频、视频和文本字幕流)。此外还应该指出，该系统可以包括很多编码器，但在图4中只显示了一个编码器110，以便在不丧失一般性的情况下简化描述。应该进一步理解的是，虽然这里包含的文本和示例可能具体描述了编码处理，但是本领域技术人员将会理解，相同的概念和原理同样适用于相应的解码处理，反之亦然。

编码媒体比特流被传送到储存器120。储存器120可以包括任何类型的大容量存储器，以便存储编码媒体比特流。在储存器120中，编码媒体比特流的格式可以是基本的自包含比特流格式，或者也可以将一个或多个编码媒体比特流封装到一个容器文件中。某些系统是“以实况方式”工作的，也就是说，这些系统将会省略储存器，并且将编码媒体比特流直接从编码器110传送到发送机130。然后，编码媒体比特流根据需要而被传送到发送机130，其中所述发送机也被称为服务器。传输中使用的格式可以是基本的自包含比特流格式、分组流格式，或者也可以将一个或多个编码媒体比特流封装到一个容器文件中。编码器110、储存器120以及服务器130可以驻留在同一物理设备中，或者它们也可以包含在独立设备中。编码器110和服务器130可以结合实况的实时内容来工作，在这种情况下，编码媒体比特流通常不被永久存储，相反，它们在内容编码器110和/或服务器130中只被缓存很短一段时间，以便平滑掉处理延迟中、传送延迟中以及编码媒体比特流中的变化。

服务器130使用通信协议堆栈来发送编码媒体比特流。所述堆栈可以包括但不局限于实时传输协议(RTP)、用户数据报协议(UDP)以及网际协议(IP)。当通信协议堆栈是面向分组的时，服务器130将编码媒体比特流封装成分组。举个例子，在使用RTP时，服务器130根据RTP净荷格式而将编码媒体比特流封装成RTP分组。通常，每一个媒体类型都具有专用的RTP净荷格式。应该再次指出的是，系统可以包含一个以上的服务器130，但是为了简单起见，以下描述仅仅考虑了一个服务器130。

服务器130可以或者可以不通过通信网络连接到网关140。网关140可以执行不同类型的功能，例如将根据一个通信协议栈的分组流变换成根据另一通信协议栈的分组流，合并和分拆数据流，以及根据下行链路和/或接收机能力来操控数据流，例如根据主导下行链路网络条件来控制转发的流的比特速率。网关140的示例包括多点会议控制单元(MCU)、介于电路交换与分组交换视频电话之间的网关、蜂窝一键通(PoC)服务器、手持数字视频广播(DVB-H)系统中的IP封装器或者将广播传输本地转发到归属无线网络的机顶盒。当使用RTP时，网关140被称为RTP混合器或者RTP翻译器并且充当RTP连接的端点。

该系统包括通常一个或者多个接收机150，所述接收机能够接收发送信号、将该信号解调和解封装成编码媒体比特流。编码比特流被传送到记录储存器155。该记录储存器155可以包括任何类型的大容量存储器，以便存储编码媒体比特流。作为替换或补充，该记录储存器155可以包括计算存储器，例如随机存取存储器。在记录储存器155中，编码媒体比特流的格式可以是基本的自包含比特流格式，或者也可以将一个或多个编码媒体比特流封装到一个容器文件中。如果有很多相互关联的编码媒体比特流，例如音频流和视频流，那么通常会使用容器文件，并且接收机150将包含或者附着于一个从输入流中产生容器文件的容器文件生成器。某些系统是“以实况方式”工作的，也就是说，这些系统将会省略记录储存器155，并且将编码媒体比特流直接从接收机150传送到解码器160。在一些系统中，在记录储存器155中只保留所记录的流中的最近的部分，例如所记录的流的最近10分钟摘录，而任何早先记录的数据都会从记录储存器155中被丢弃。

编码媒体比特流被从记录储存器155传送到解码器160。如果有很多相互关联并且被封装到一个容器文件中的编码媒体比特流，例如音频流和视频流，则使用文件解析器(在图中并未显示)来将每一个编码媒体比特流从容器文件中解封装。记录储存器155或解码器160可以包含文件解析器，或者该文件解析器附着于记录储存器155或解码器160。

编解码媒体比特流通常由解码器160进行进一步处理，其中所述解码器的输出则是一个或多个未压缩媒体流。最后，表现器170例如可以用扬声器或显示器来再现未压缩媒体流。接收机150、记录储存器155、解码器160和表现器170既可以驻留在同一物理设备中，也可以包含在独立设备中。

以下是如何让在ISO基本媒体文件格式中指示所记录的索引轨道的实施。在本实施中，所记录的索引轨道用一个简单条目类型来指示，并且该条目类型与用于服务器索引轨道的相应简单条目不同。举个例子，用于服务器的RTP索引轨道是以“rtp”作为采样描述中的条目格式的索引轨道(媒体句柄“hint”)。所记录的RTP索引轨道在采样描述中具有“rrtp”条目格式。这两个采样条目以相同方式规定如下：

class RtpHintSampleEntry()extends SampleEntry(′rtp′){

uint(16)hinttrackversion＝1；

uint(16)highestcompatibleversion＝1；

uint(32)maxpacketsize；

box additionaldata[]；

}

class ReceivedRtpHintSampleEntry()extends SampleEntry(′rrtp′){

uint(16)hinttrackversion＝1；

uint(16)highestcompatibleversion＝1；

uint(32)maxpacketsize；

box additional data[]；

}

为每一个可以索引的协议都规定了一对服务器和记录采样条目格式，例如SRTP和MPEG-2传送流(TS)。可以为用于任何协议的每一对服务器和记录索引轨道格式规定索引采样。在用于任何协议的每一对服务器和记录索引轨道格式中，以相同的方式定义索引采样例如可以在编码语言代码行或机器可执行指令数量方面减小软件实施的大小。但是，与同一协议的服务器索引轨道格式相比，采用不同的方式来规定记录索引轨道的采样格式同样也是非常有益的。举个例子，由于服务器被认为仅仅依据每一个发送分组而将数值递增1(在模运算中)，因此，为服务器索引采样格式包含MPEG-2TS分组报头的continuity_counter字段并不合理。但是，对于记录索引采样格式来说，continuity_counter字段是必需的，这是因为可以根据后续接收分组的continuity_counter值的间隙推断出分组丢失。此外，在与服务器索引轨道所用的层不同的协议堆栈层中规定记录索引轨道格式同样是合理的。举个例子，如果记录索引采样对应于网际协议(IP)分组，那么文件解析器可以使用用户数据报协议(UDP)报头的校验和来推导接收分组中的比特差错的存在性，也就是接收分组的完整性。作为替换或补充，记录索引采样可以包含相应分组格式中并不存在的字段。这些字段例如可以用于传达来自基础协议堆栈层的信息。关于此类字段的一个示例可以是用于所记录的RTP索引采样的比特差错指示符字段。接收机可以根据UDP校验和或是存在于任何基础协议堆栈层中的任何CRC或校验和来设置比特差错指示符字段。

图5是显示依照本发明各个实施例的简化版接收机操作的流程图。但是应该指出，接收机可以采用多种形式和配置。图5的处理开始于在510处从用于所接收的传送分组的接收方缓存器中提取传送分组。此外，该传送分组也可以写入到第二缓存器中，在这里将其称为短期分组缓存器。该传送分组可以包括RTP分组、MPEG-2传送流分组或是其他任何传送协议的分组。在520，分组序列编号的连续性被检查，并且确定在序列编号中是否存在间隙。如果传送分组是依照RTP进行格式化的，那么序列号(SN)驻留在RTP报头中。如果传送分组是依照MPEG-2流进行格式化的，那么序列号将被称为continuity_counter，并且驻留在TS分组报头中。

如果在序列编号中没有间隙，并且在短期分组缓存器中没有一个分组被识别为包含比特差错，那么在530检查当前分组是否包含关于视频帧、或者更为一般的是关于视频访问单元的最末净荷字节，其中所述视频访问单元的分组当前被存储在短期分组缓存器中。在大多数视频RTP净荷中，RTP报头中的M比特被规定成指示分组包含了用于编码视频帧的最末净荷字节。另一种检测视频帧的最末分组的方式是检查下一个分组的RTP时间戳。如果下一个RTP时间戳不同于当前RTP时间戳，则当前分组包含当前编码视频帧的最末净荷字节。当使用的是封装到MREG-2传送流中时，在下一个传送流分组中的、等于1的payload_unit_start_indicator值表明当前TS分组包含了当前编码视频帧的最末净荷字节。如果当前分组不是视频帧的最末分组，则处理返回到510。应该指出的是，处理520和530仅在传输顺序与编码视频数据的解码顺序相同的情况下工作。针对交织的传输顺序的丢失和结束帧检测通常需要分析接收到的数据单元。关于H.264/AVC的交织传输的丢失检测的一个示例是在3GPPTechnical Recommendation 26 946(Release 6)的第八节″MultimediaBroadcast/Multicast Service，User service guidelines”中提供。帧边界检测在H.264/AVC(即ITU-T建议H.264)的第7.4.1.2.4节中描述。

此外还应该指出，上文中参考图5的论述是依照视频流来描述的。音频通常不在多个帧上进行时间预测，并且通常在一个传送分组中包含了一个完整的音频帧。因此，在音频流中通常可以省略上述处理中致力于寻求下一个随机访问帧的那部分处理。此外，如果音频帧始终装入一个传送分组中，则可以省略写入处理530，并且可以修改步骤540，以便在将音频采样写入文件时用空帧来替换遗漏的音频帧。

如果当前分组是编码视频帧中的最末分组，则在540从短期分组缓存器收集的分组净荷中得出视频采样。这个推导处理可以包括简单地连结分组净荷。然后，所生成的视频采样被写入一个文件。应该指出的是，由于元数据(moov盒或moof盒)在出现顺序中通常领先于媒体数据，因此，视频采样可以首先被写入临时文件，然后则拷贝到在完成所有相应元数据时创建的实际文件。

在550，从存储在短期分组缓存器中的每一个分组生成索引采样。由于在540生成的视频采样已经包含了编码视频数据，因此，该索引采样仅仅是指视频轨道、所生成的视频采样以及视频采样内部的恰当比特范围。当已经针对短期分组缓存器中的所有分组生成了索引采样时，该缓存器将被清空，并且处理返回到510。

如果在520检测到短期分组缓存器中的任何分组中的比特差错或是分组序列编号中的间隙，则在560从短期分组缓存器中存储的每一个分组中生成一个索引采样。但是，由于短期分组缓存器中的分组净荷并不是没有差错的，因此，不会将视频采样生成为视频轨道。由此，使用即时构造器机制或是“胖”索引轨道机制将分组净荷实质上包含在索引采样中。当使用即时构造器时，在分组化指令中包含净荷数据拷贝。当使用“胖”索引轨道时，分组净荷将被包含在索引轨道的mdat区段中，并且是从索引轨道的构造器查阅的。当为短期分组缓存器中的所有分组生成索引采样时，该缓存器被清空。

在560之后，下一个分组在570从用于所接收的传送分组的接收方缓存器中获取。然后，下一个分组将被检查，以便确定该分组是否开始了一个用于向流提供随机访问点的编码视频帧。编码视频帧的起点可以根据处理530来检测。关于随机访问点的检测取决于视频格式及其净荷格式。举个例子，在H.264/AVC中，可以从网络抽象层(NAL)单元报头中识别独立解码刷新(IDR)帧，其中所述报头很容易从分组净荷中被访问。H.264/AVC提供的另一个随机访问点指示机制是恢复点供应补充增强信息(SEI)消息，其中该消息可以指示不同类型的梯度随机访问位置。关于随机访问点指示的另一个示例包含在用于VC-1编解码器的RTP净荷格式中，其中该格式包含了用于此目的的特定标记。如果指示了随机访问点，则处理在530继续进行。否则，该处理在560继续进行。

应该指出的是，上述处理可以采用多种方式实施。例如，在接收处理期间有可能没有创建媒体轨道，并且仅仅针对文件创建了索引轨道，那么可以在接收完了所述流之后离线创建媒体轨道。在离线生成媒体轨道的过程中，索引采样(包含媒体净荷数据)可以或者不可以改变，以便指示用于媒体轨道的采样中的数据。参考图4，媒体轨道的离线生成将会导致两个附加块，其中这两个附加块的输入来自记录储存器155，并且输出至解码器160。按照处理顺序，第一个块可以被称为文件重写器，它仅仅输入一个包含索引轨道的文件(不存在媒体轨道)并且输出具有媒体轨道的文件。按照处理顺序，第二个块可以被称为第二记录储存器，它可以与记录储存器155具有相似的属性。

另一种实施包括在接收过程中记录到中间格式中。该中间格式可以包括用于接收分组的简单存储格式。例如，MPEG-2传送流本身可以存储到文件中，并且可以在将指示了分组大小的某些组帧处理包含于文件时存储RTP分组。依照中间格式的文件随后可以转换成更为结构化的文件格式，例如ISO基本媒体文件格式版本或是其衍生版本。在转换处理期间，可以使用与上述处理相似的操作。参考图4，这种实施需要两个附加块，其中这两个附加块的输入来自记录储存器155，并且输出至解码器160。按照处理顺序，第一个块可以被称为文件重写器，它输出一个依照中间格式的文件，并且根据更为结构化的文件格式来输出所述文件。依照处理顺序，第二个块可以被称为第二记录储存器，其中该储存器与记录储存器155具有相似的属性。

上述文件重写器和第二记录储存器可以驻留在与接收机150、记录储存器155、解码器160或是不同设备相同的设备中。此外，文件重写器和第二记录储存器彼此可以驻留在相同的设备或不同的设备中。

包含于或附着于解码器160中的文件解析器和解码器160可以像对普通文件进行解析和解码、也就是像是只对媒体轨道和媒体采样执行解析和解码那样来执行操作，而索引轨道和索引采样则会被忽略。作为替换，文件解析器和解码器160可以像是实时接收到编码媒体比特流那样执行操作。换句话说，文件解析器可以根据索引采样中的指令来构造分组，并且将分组传递到解码器160。此外，将分组传递到解码器160的步调可以对应于分组的接收调度。分组的格式可以与从发送机130传送的分组相同，或者它也可以与发送机传送的分组包括基本相同的信息，其中所述分组有可能伴有来自基础协议堆栈的数据。解码器160如上文中参考图5描述的那样检测遗漏或损坏的分组。该解码器160可以通过应用差错隐藏和/或差错追踪算法来响应遗漏或损坏的分组。此外，解码器可以使用来自发送机130的反馈协议来请求恢复或隐藏遗漏或损坏的分组。文件解析器和解码器160的其他方案也是可行的。例如，如果数据分别包含在对媒体轨道的媒体采样中或是包含在索引采样中，那么解码器160可以推断出分组是否可以正确解码。

此外还应该指出，索引轨道可以包含一种或多种媒体流/类型，并且还可以包含相关联的元数据。举个例子，如果音频和视频是作为基本流而在MPEG-2传送流上传送，则音频和视频可以记录在相同的索引轨道中。此外，MPEG-2专用信令同样可以包含在相同的索引轨道中。

应该进一步指出的是，在传送域中工作的加密/DRM系统也是存在的，也就是说，该系统能够独立或者作为与编码媒体帧相对比的分组流来对分组或分组净荷进行加密。如果所提供的DRM使用权利拒绝以解密格式来存储内容，则接收方不会再现媒体轨道，取而代之的是，它仅仅会将接收到的分组存储在特殊的索引轨道中。

引入和实施本发明各个实施例的通信设备可以使用不同传输技术来通信，这其中包括但不局限于码分多址(CDMA)、全球移动通信系统(GSM)、通用移动电信系统(UMTS)、时分多址(TDMA)、频分多址(FDMA)、传输控制协议/网际协议(TCP/IP)、短消息收发服务(SMS)、多媒体消息收发服务(MMS)、电子邮件、即时消息收发服务(IMS)、蓝牙、IEEE 802.11等等。在实施本发明各个实施例时所涉及的通信设备可以使用不同媒体来通信，这其中包括但不局限于无线电、红外线、激光、电缆连接等等。

图6和图7示出了可以实施本发明的一种有代表性的电子设备12。然而应当理解：本发明本意并非限于一个特定类型的移动设备12。图6和图7的电子设备12包括外壳30、形式为液晶显示器的显示器32、小键盘34、麦克风36、耳机38、电池40、红外线端口42、天线44、根据本发明一个实施例并采用UICC形式的智能卡46、读卡器48、无线电接口电路52、编码解码器电路54、控制器56、存储器58以及电池80。单个的电路和元件全都是在本领域中、例如在Nokia移动设备范围中众所周知的类型。

这里描述的本发明的各个实施例是在通用的方法步骤或处理的上下文中描述的，并且在一个实施例中，所述步骤或处理可以由计算机程序产品来实施，其中所述计算机程序产品包含在计算机可读介质中，并且包含了由联网环境中的计算机执行的计算机可执行指令，例如程序代码。通常，程序模块可以包括用于执行特定任务或是实施特定抽象数据类型的例程、程序、对象、组件、数据结构等等。计算机可执行指令、相关联的数据结构以及程序模块代表了用于执行这里公开的方法步骤的程序代码的示例。这些可执行指令或相关数据结构的特定序列代表的是用于实施在此类步骤或处理中描述的功能的相应动作的示例。

可以用标准编程技术实现本发明各个实施例的软件和web实施，这些编程技术具有基于规则的逻辑以及用以实现各种数据库搜索步骤或处理、相关步骤或处理、比较步骤或处理和判决步骤或处理的其他逻辑。也应当注意：在这里和在权利要求中使用的字眼“组件”和“模块”旨在于涵盖使用一行或者多行软件码的实施、和/或硬件实施和/或用于接收人工输入的设备。

已经出于图示和描述的目的而呈现对本发明实施例的前文描述。本意并非穷举本发明的实施例或者使本发明的实施例限于公开的精确形式，并且修改和变化根据上述教导是可能的或者可以从对本发明各个实施例的实施中加以获悉。选择和描述在此讨论的实施例以便说明本发明各个实施例的原理和本质及其实际应用以使本领域技术人员在各种实施例中和以与设想的特定实施例适应的各种修改来利用本发明。